Every day I sit down with decision makers in Fortune 2000 companies to discuss solving InfoSec problems. Much of my conversations revolve around the role of Network Behavioral Anomaly Detection (NBAD) and NetFlow Forensics in a healthy security practice. Specifically I educate on the specific product, StealthWatch.
Since the Sony breach went live several meetings start with the audience asking if I'm going to talk about it. After doing some investigation, I realized the reason they had that expectation was that every vendor ahead of me came in and talked about how their products "could have stopped the Sony breach."
Every time there is a security breach in the mainstream news cycle, this vendor dogpile starts. The vendors that had products in place point to failed operations inside their customer and vendors that didn't have products deployed make audacious claims of how they "could have" helped. I'm concerned these types of conversations have two negative results. First, they create confusion and complication in organizations that would like to change. I wrote up these hazards earlier in the year in Coaxing Heads from the Security Sand. The second issue is that it further exasperates "vendor fatigue" in the organizations.
I do think these events are good "teaching opportunities" if used correctly.
Enforcement Needs Monitoring
One productive conversation is that enforcement isn't the only pillar of security. In Before there was a Great Wall, I examine the importance of monitoring. It is a fundamental component of any security practice (cyber, physical or martial.) When I was doing product testing for InfoWorld in 2005, I observed the strange mandate for InfoSec tools to do all the work. They were expected to observe, block and respond to IT attacks. The situational awareness provided by Intrusion Detection Systems (IDS) were no longer sufficient business justification. IDS needed to become IPS and do the work of SOC teams. In It's Time to Hire a Security Team, I go over this market shift in detail. Smart people that are increasingly well funded are attacking networks. Enforcement tools are needed (no doubt about that) but the monitoring infrastructure in these breached networks are radically lacking.
Sony was detected by the hackers making a loud, visible declaration that could not be missed. The attackers took efforts to make it obvious to the company and the world that they were breached. If they would have stayed quiet we will still would not know that the attackers owned the Sony network. Target was alerted by the Secret Service. NSA detected Snowden through the Guardian. This is a shocking indictment of how miserable the industry is at knowing they are being attacked. They need someone else to tell them.
Bottom line on this point is, we need to get serious about threat detection and response. Executives are asking good questions like "Are we vulnerable to attacks like Sony?" Those are good questions. The follow up is equally important, "How do we detect and respond to these attacks today?" The actual answers are almost always horrible.
Tools Need Flowcharts
After the Target breach, I was in the Twin Cities meeting with a CISO from a customer over lunch. He started explaining his pain points and the projects he was launching to address them. It turned out his projects were all product evaluations. His team was sitting at the table with me and I asked, "What do you do when you detect an infected computer?" I received at least three different answers from different team members. The CISO looked concerned and confused. Knowing what the problem likely was, I asked, "Where do you keep the process documents?" As expected I was told that they did not exist.
Make Impossible Possible
On the paper table cloth, I drew out the process for them based on their answers. We annotated how long each task took and which ones were impossible. When we multiplied those times by frequency the weekly cost of that single would require more than 40 FTE.
From there we looked at how existing and new tools could reduce 1) the number of events (enforcement) 2) decrease the time they are unaware of the problem (MTTK) and 3) decrease the time it takes to accomplish tasks (MTTR.) In one meal we had a framework for making an impossible workload possible.
Make Training Possible
Another problem with not having documented process is that it is difficult to train. If every process is "Do Foo" that is hard to teach. If processes are well documented, they can be taught to junior personnel. This allows an organization to staff at a lower cost and with less effort. As personnel grow, they can learn new processes and help improve those they have mastered. It is a great stride in handling a talent deficiency in InfoSec - grow your super stars.
You Can Audit
Everyone has a bad day. Everyone makes mistakes. Incident response investigations should always be audited. Inspectors review incident documentation to ensure all the documented steps were completed. It's impossible to audit "Do Foo." We need process.
Last word on Process
I know building flowcharts is not a hobby anyone likes. Nearly every mature industry does it. It is done in police work. It is done in manufacturing. It is done in aircraft maintenance. If it's important, it needs a process.
Cyber Crime is Crime
Cyber criminals are criminals. They do not swear an oath that they will limit their malfeasance to computers. They can hack your computer and also kidnap your family or offer a trusted employee a bribe. It's crime. It's real crime. The dichotomy needs to be broken down.
While I'm not for a vendor dogpile every time we have these high profile breaches, I do think they present us with an opportunity to think about what the core problems are. As I meet with decision makers trying to look through the noise created in these events, I believe the best things we can do are 1) start doing serious monitoring, 2) document and fix processes and 3) stop thinking of cyber crime as "soft" or less important.