Using an Incident-Focused Model for Information Security Programs

The following is a guest post from Mark-David McLaughlin, Ph.D., Director of Security and Risk Management at Acuity Brands, Inc. Acuity is a major supplier of LED, smart lighting, and IoT based systems for smart cities.  In his role as Director of Security and Risk Management at Acuity Brands Lighting, Dr. McLaughlin helps ensure security practices are an integral part of the company’s IoT offerings.

Incidents Aren’t 100 Percent Preventable: You Need a Response Plan

Organizations attempt to prevent information security incidents by embedding tools in policies and practices across business functions. Because it is not possible to completely prevent security events, organizations must also include proven response practices as part of their security program. A security model helps protect an organization by helping managers identify strengths and gaps in their security program. For example, automated intrusion-detection systems and manual reporting processes can help spot anomalies, but without a process to quickly and accurately identify events which represent serious security issues and prevent similar attacks from occurring again, these detection activities cannot effectively be deployed leaving both the business and customers at risk. 

In an article published in MIS Quarterly Executive titled “Challenges and Best Practices in Information Security Management,” I described a cycle of five interrelated functions that can be used to classify security governance and control activities. The Prepare, Prevent, Detect, Respond, and Learn (PPDRL) model uses security incidents as the focal reference point. I believe this is the ideal way to think of any security program as it keeps the actual event in sharp focus. Specifically, in the model, elements of a program are conceptualized as those which help prevent, prepare, detect, respond and learn from security incidents. The following figure provides an overview of these functions:

Figure 1: PPDRL Model

Common Steps to Prevent Security Incidents

Last year organizations spent over thirty-two billion US dollars on security software. Much of that expense was on software that attempts to prevent information security incidents (such as endpoint security, firewalls, intrusion detection/prevention systems, etc.). Many information security staff members find a significant portion of their efforts are spent on preventive efforts such as: 

• Implementing various security tools
• Setting information security policies and procedures
• Conducting education campaigns to persuade employees and other users to adopt safer behaviors (e.g., using strong passwords, complying with other policies)

While these activities are important—and the first component of the PPDRL model—they are only one aspect of a mature security program. With over fifty-three thousand security incidents reported in Verizon’s 2018 Data Breach Investigations Report, organizations must not only consider the possibility that they will experience an information security incident but take a serious look at their organization's ability to detect and respond to events that will inevitably occur.   

Common Steps to Prepare for Security Incidents

In 2018, we read about data breaches at Facebook; Panera; Under Armor; and Saks, Lord & Taylor. When it comes to cyber security, no organization is invincible; therefore, security professionals must spend time preparing for the inevitable. Organizations typically perform the following steps when preparing for events:

• Learning about attackers’ motivations and behaviors
• Calculating risks
• Forming response teams
• Holding periodic exercises (“fire drills”)

Once an incident occurs, incident responders will be ready. The next function of the model focuses on steps organization use to detect possible security incidents. 

Common Steps to Detecting a Security Incident

Once an incident occurs, it is important that organizations quickly and accurately detect potential information security incidents and limit any damage. Automated systems, end users, and engineers in security operations centers attempt to limit harm by reducing the amount of time between an event occurring and when it is identified as a security incident. In the model, organizations classify functions as they relate to:

• Detection of possible information security incidents
• Validation of Security Incidents 
• Categorization of urgent and minor security incidents 

Once these detection functions have been triggered, a security program has several response functions that are executed to respond to the event.

Common Steps to Respond after Detecting a Security Incident

Organizations respond to security incidents after clues that point to an incident are detected. Designated responders, managers, and other employees need to know how to:

• Minimize harm to operations, employees, customers and business partners
• Employ designated responders, managers and other employees to manage the aftermath
• Deploy technical resources to mitigate or resolve the incident
• Possibly disclose details of the incident to affected parties and stakeholders

Once a response plan has been performed, a comprehensive security program has a feedback loop for post-incident learning activities.

Common Steps for Post-Incident Debriefing

After an incident has been resolved, the security team and key stakeholders conduct post-incident debriefing exercises to learn by sharing lessons. The learning function of the model includes:

• Conducting post-incident debriefing that includes lessons learned
• Discussion on how to design more secure systems and processes
• Consideration of how to respond more effectively when the next incident occurs
• Adjusting system security, processes and response plan
• Making necessary adjustments to information security policies and procedures

To prepare for an industry-wide event, such as Spectre or Meltdown, there may be an opportunity for us to share best practices for response capabilities. In future blog posts, I will demonstrate how the model can be used to analyze a vulnerability management program which focuses on securing products and services. As a component of continuous improvement, I look forward to sharing more details about structuring other aspects of a security program in the upcoming months.