This column is available in a weekly newsletter called IT Best Practices. Click here to subscribe.
I recently had the opportunity to talk with Jeff Schmidt, founder and CEO of JAS Global Advisors, which provides a number of business and technical consulting services pertaining to information technology. Among the services offered are incident response and forensic investigations.
Schmidt has a lot of good advice based on his company's 12+ years of working with companies that have had an incident or an actual data breach:
When JAS Global Advisors gets called in to respond to an information security incident, what are some of the first steps your team takes?
Very often the first thing we do is work with the company's lawyers and senior executives to figure out their overall posture or desire with regard to the incident. What I mean by that is determining how to treat the incident. Some organizations just want to fix the problem and make it go away quickly and quietly. Many companies don't have that option because they have a regulatory requirement to report the breach to some government agency and/or to notify individuals who may be impacted by the data breach. Some organizations may be required to or have the desire to report the incident to law enforcement to seek lawful remedies. In the case where the incident is suspected to involve an insider, the company might want to investigate to be able to take HR action. We have to understand a company's position right from the outset because this affects everything we do from that point forward.
It's very important that this position be communicated to the IT department as soon as possible, as well as what procedures to take. As a technical person myself I know that technical people, by our nature, want to fix things, but this might not be the best thing to do. For example, a misconfiguration in a security device might have enabled the security incident, so the technical person wants to get it fixed. But he might not consider the need to preserve evidence and document the steps of the response. That's why it's important to communicate the desired procedures and make sure that people are following them.
Explain the importance of having to preserve evidence.
Depending on the situation of the incident, the company might face litigation—either wanting to go after someone responsible for the incident, or in case they are being sued by people affected by the breach. That makes evidence preservation, recording all the steps you take, and documenting things with thorough notes, extremely important. The company might be in court five years from now and they will need to have the proper chain of custody on all evidence, good documentation, and so on.
What else do you do early on in your investigation?
Once we understand the position that the company plans to take, we get busy trying to figure out what data was impacted. This is usually a pretty complicated task because large companies have many different systems and few people at the company – if anyone – understands all those systems. If there's any reasonable belief that personally identifiable information (PII) was impacted, the timer starts for having to make notifications to people.
One of the most valuable things a company can do – not just in preparation for a security breach but for general business purposes – is to have a data classification system. Companies should understand which pieces of their data are sensitive commercially or from a contractual standpoint, and what is protected by statute, such as PII or private health records (PHI). They also need to know where that data resides.
For example, suppose System A has PII, and System B has no sensitive data, and System C has data that is in a protected class by contract. Then if you have an incident that affects System A, you immediately know you have a PII problem. If System C has an incident you might have an uncomfortable conversation with your business partner but you don't have to worry about PII and sending out notifications to people.
That sort of inventory takes a remarkable amount of time because data is everywhere these days, but it really needs to be done.
What else can companies do to prepare for the possibility of a security event?
Companies need to have a crisis management team identified in advance. This is the level of people above an incident response team. It's important to know who can make decisions in what I'll call a non-standard situation. The CEO might not be available, so who is the one who can make decisions? I recommend that companies assign a team, empower them, and have procedures for reaching and coordinating this team, including fallback people if the primary people aren't available.
Technology-wise, what can companies do before an incident happens?
There are a couple of things I highly recommend. Compartmentalize the network infrastructure so that if an attacker does manage to get inside the network, he can't move around laterally to other areas. Companies that do this tend to be much less impacted than companies with a "candy network"—one that is hard and crunchy on the outside but once you are on the inside it is soft and gooey. That's what happened with Sony Pictures. The attackers got in and had free rein over the rest of the network. By comparison, financial services companies tend to compartmentalize. If one system is compromised, the attack can't easily spread.
Companies should consider implementing a strong multi-factor authentication (MFA) system around sensitive systems. With MFA in place, if someone has your credentials – say they were stolen in a spear phishing attack – then it's still hard for them to get into your system if they don't have that second factor of authentication. A lot of people use web mail when they are travelling. Web mail is a phisher's dream because it's so easy to steal your login credentials. Once they have your credentials, they own your email. Password resets are often done by email, so now an attacker has your login ID and password. But strong MFA can defeat this.
Can you talk about the importance of logs in your forensic investigations?
When an incident occurs, you can literally reconstruct an attacker's actions if you have the logs. You can get a remarkable amount of precision in determining what the bad guys took or did—assuming the logs are available and haven't been tampered with.
People tend to overlook the importance of logs when they have data in the cloud. I advise clients to look at their cloud provider contracts to understand what kind of logs are available, for how long, and how to get them. You might even go so far as to have a trial run of getting your logs from the cloud provider, analyzing them, and understanding what they are telling you. This can also reveal if the cloud provider is meeting its obligations that are specified in your contract.
Conclusion: No company wants to face a security event that requires activation of an incident response team. Heeding Schmidt's advice might save your company from having to call his company in to help resolve a crisis.