Management Lessons Learned From the OpenSSL Bug Response

The explosion of cyber threats, which have increased year over year, has changed the landscape of the decision-making process for IT and security leadership in all industries. Symantec recently released a study that stated “the total number of breaches in 2013 was a 62% increase from 2012. Each of the eight top data breaches in 2013 resulted in the loss of tens of millions of data records” [1]. So security intrusions are a threat that represents the reality of the world we live in. IT and security teams need to cooperate and plan for the worst by developing a threat management program that relies onpeople, process and technology. This includes:

  1. Log analysis of all supporting, security and compensating controls
  2. Monitoring and analyzing of all collected security events data
  3. Deep packet forensics analysis
  4. Anomaly behavior from netflow collection
  5. Building correlation logic based on security research and intelligence
  6. Mining big data collection utilizing mathematical learning to determine malicious patterns and behavior
  7. Establishing a vulnerability management program
  8. Creating a security awareness plan
  9. Building an incident response strategy
  10. Developing an internal and external communication plan

So this latest incident with the OpenSSL vulnerability provides a great exercise to test the efficiency and thoroughness of your developed plans. You ask yourself some questions. Are you collecting all the right log data to correlate withyour security threat devices to find malicious activity? Were your security and IT teams able to work together to quickly follow the incident response plan to efficiently update systems and eliminate the risk cause by the OpenSSL bug? Are there changes that need to be made to the incident response plan based on lessons learned from the teams and the after-action review of the incident? These are some of the data that should have been collected and reported as part of the Incident Response process:

  1. Solid understanding of what services where exploitable by the vulnerability
  2. Discover if a breech has occurred through data collection and analysis
  3. Communicate with impacted parties – data was stolen, regulators, customers
  4. Communicate public actions – credential management AND suggest that if the same password is used in more than one service, recommend changing these passwords as well. 
  5. Communicate action plan – mitigate vulnerability OR deploy compensating controls (threat monitoring)
  6. IT to make recommendations to the business as to how the vulnerability management program performed, or the need for one and the need for a refined Incident Response process that defines business owners and the impact as a stakeholder.   

  [1] 2013 Symantec Breach Impact Report