<div dir="ltr"><a href="http://www.aim.ph/blog/the-business-guide-to-developing-a-cyber-security-incident-response-plan/" target="_blank">http://www.aim.ph/blog/the-<wbr>business-guide-to-developing-<wbr>a-cyber-security-incident-<wbr>response-plan/</a><br><br>Remember the 1995 movie, The Net? In the scene post her stolen identity, the protagonist, a computer programmer, says the most unthinkable thing, “Our whole world is sitting there on a computer. It’s in the computer, everything …  is stored in there. It’s like this little electronic shadow on each and every one of us, just, just begging for someone to screw with.”<br><br>Outside the fictional realm, we’re actually seeing how technology, amid all the IT services available, becomes a precursor of privacy concerns, data breach, and other online security threats. And without a cyber-security incident response plan (CSIRP) properly set up, organizations risk losing tons of critical data.<br><br> Implementing Your CSIRP<br><br>A CSIRP is a written plan that companies can use when dealing with potential cyber threats. Since the CSIRP describes a number of possible scenarios, the responding team’s actions become deliberate and uniform, rather than random and inconsistent. Here are important pointers to remember when building your cyber incident response plan.<br><br> Response team<br><br>Incident responders are your hardworking and skilled team members who work before, during, and after a cyber incident scenario—from developing the CSIRP to launching investigations and doing cleanup to assessing the CSIRP effectiveness as part of follow-up operations.<br><br>Who can save the day for you? A senior management rep, a systems, database or network administrator, network engineer or programmer, security officer, legal rep, and public affairs officer may be tapped as part of the response team.<br><br>Third-party vendors, consultants, or specialists may also be brought in, depending on service level agreements or on the company’s human resources.<br><br> Reporting<br><br>As soon as your team has confirmed that there’s been an unusual activity in your system, senior management needs to be notified right away. Then, just as quickly, technical members of the team assemble at the scene to perform their designated functions, as the rest of the team receive updates and give directives to address issues under their scope.<br><br>At this point, documentation needs to be done. Below is a list of the information to be included in the report:<br><br>Point-of-contact information: name, telephone, email address<br>Incident category: CAT 1-CAT 6<br>Incident date and time<br>Source IP, port, and protocol (if known or available)<br>Destination IP, port, and protocol (if known or available)<br>Location and component of the system/s involved in the incident<br>Method used to identify the incident: audit log analysis, intrusion detection system, system administrator, end-user feedback)<br>Description of the incident<br><br> Initial response<br><br>The nature of your response will have to be based on the incident category, type, or level that you’re dealing with, but the bottom line is still to contain the issue. Naturally, the initial response for security breach caused by an insider threat would be different from social engineering.<br><br>For malware attack, for example, you can call in a forensics team to do reverse-engineering tactics, provided that your team has previously created a sandbox to hold the malware for observation and containment.<br><br> Investigation<br><br>Here’s where all the dirty work comes in, trying to figure out what actually happened to your system or network. Your forensics team can now collect malware and logs onsite or remotely and try to discover hash, as well as registry values as well as its effect on the entire systems and infrastructure.<br><br>These, plus all other relevant data gathered from multiple sources (read: bit-stream copies of drives; external storage; network, system, and application logs), will be used to identify and deploy appropriate remediation methods.<br><br>Recovery and follow-up<br><br>By this time, hopefully, after receiving some beating, your network is ready to get a makeover and return to its normal state. Your disaster recovery and follow-up plan can be divided into two phases: incident recovery and post-incident recovery.<br><br>In incident recovery, you’ll be restoring your system and data, and then validating if the system is completely operational.<br><br>Post-incident recovery basically involves retrospection, asking yourself how to avoid the same misses in the future, making a record of all the lessons learned, and enhancing the CSIRP with the improvements needed. After all, nothing is perfect, right?<br> <br>Public relations<br><br>Trust your spin doctors to take the necessary steps and address public concerns through press releases or statements. The goal is to restore confidence and loyalty among end-users all throughout the crisis.<br><br> Law enforcement<br><br>In cases when criminal investigations are carried out, the designated team member, usually the Chief Compliance Officer, the Chief Security Officer or the Chief Information Officer, needs to consult law enforcement contacts to discuss the whys and wherefores of incident reporting and collection of evidence to help in the investigation and prosecution of cyber attackers.<br><br>The value of the CSIRP should never be underrated, serving as a cushion of some sort against the ugly impact of a cyber security crisis. If your organization still does not have a legit CSIRP, you better act now sooner than later. Or at the very least, be sure to have some contingency in place.<br></div>