Written by Kevin McDonald, COO and CISO of Alvaka Networks. Originally published January 2016 on TechTarget. Kevin discusses steps to help you prepare a cybersecurity incident response.
When your system is compromised, you generally have one chance to get the response right. Any mistakes made in the early moments of a cybersecurity incident can have a negative, cascading impact that will be difficult — if not impossible — to recover from. Initial actions often determine whether the outcome is manageable, or chaotic and destructive. Having a predetermined plan is critical to avoiding those mistakes and mitigating damage.
There are several elements that should be included when developing and implementing a cybersecurity incident response plan. How you complete these steps is dependent on numerous variables, including your company’s unique cybersecurity vulnerabilities and regulatory compliance needs. But generally, your plan can be built by following these steps.
1. Develop goals: Carefully describe the overarching goals of the plan. Having goals for each section will help those assigned to deliver on the plan understand the context of their assignment, and the reason for their actions.
2. Determine the people involved: Be sure those expected to act are not just identified but fully informed and trained on their role in cybersecurity incident response. Describe, by role, who will do what in the event of an information security incident or data breach. Some additional recommendations:
• A single point of contact should manage policies and procedures. This person should be assigned in advance, and be tasked with ensuring that your organization has plans in place that are current and viable.
• Establish a Computer Security Incident Response Team (CSIRT). The team’s job is to quickly and effectively respond to and manage high-level incidents. CSIRT members should be empowered to make decisions and execute in the event of an incident. The CSIRT should also have the ability to assign smaller strike teams to assess the severity and potential impacts of an individual incident.
3. Identify discovery mechanisms: Be sure to identify systems, activities and events that can be monitored or reviewed on a regular basis. Constant review to identify potential information security incidents quickly is critical.
4. Determine cybersecurity incident response triggers: Identify as many common events that will trigger an investigation as you can. You don’t need to cover them all, but being thorough will help others to understand what they should look for and how to respond. Some possible triggers include:
• Theft or loss of a computing device
• Many failed attempts to gain system access
• Attempts to use old credentials
• Access attempts that are outside of normal business hours
• Unauthorized access to a system containing protected data
• Employee snooping or information capture
• Discovery of installed malware capable of data exfiltration or credential capture
5. CSIRT activation: Identify how, when and what levels of staff are to be activated depending on the type of information security incident. Loosely describe incidents that could require a response from an individual employee, a small cyber strike team and/or the full CSIRT. In smaller organizations, this may also be decided by executives on a case-by-case basis. The following are examples of moderate to severe information security incidents, and the appropriate response:
• Virus infection that only impacts one machine or host (individual with report going to CSIRT).
• Virus that impacts more than one machine or host (strike team of assigned individuals with report to CSIRT).
• Possible malware infection with data exfiltration capabilities (strike team with potential to expand to the full CSIRT).
• Known severe malware database infection/attack that is believed to have resulted in significant data exfiltration or destruction (full CSIRT with assigned strike teams based on needs).
Continue reading all 13 Steps at TechTarget Search Security…
Kevin McDonald, COO & CISO – Alvaka Networks
Kevin B. McDonald is the chief operating officer and chief information security officer at Alvaka Networks. Kevin is a trusted technology and security practitioner and public policy advisor to some of America’s most influential people and organizations. He advises corporate executives, federal and state legislators, law enforcement, high net worth individuals and other business leaders. He is a sought after consultant, writer, presenter and trainer on the issues surrounding personal, physical and cyber security, compliance and advanced technology. Kevin has written for and been interviewed by dozens of national publications and on major television, radio and digital outlets.
Chairman, Orange County Sheriff/Coroner’s Technology Advisory Council (T.A.C)
Member, OC Shield
Member, FBI InfraGard
Member, O.C. Homeland Security Advisory Council (OCHSAC)
Member, US Secret Service’s LA Electronic Crimes Task Force (LAECTF)
Smoke testing is a term used to describe the testing process for servers after patches are applied. 
Estimating an average time for patching servers and PCs can be a bit tricky. It can vary from one month to the next, depending upon the number and complexity of the patches released by your software vendors. You must consider all versions of operating systems and have a complete inventory of all your application software to do this job correctly. Our experience has shown that manual patching of systems takes on average of about 1.5 hours each.
This is a basic cost calculator for you to compute your typical monthly cost for patching your servers, PCs, laptops, tablets and associated application software. It also forms the basis for you to begin calculating your Return on Investment for software patching, or for comparison with alternatives to the manual process of patching operating systems and application software—such as Patch Management as a Service, also known as Vulnerability Management as a Service.