Questioning Information Security: A couple of examples

We've discussed the necessity in information security of asking good questions (Questioning Information Security - Part 1) and how to answer those questions using data and analytics (Questioning Information Security - Part 2).  Now apply this approach to answer two questions for a hypothetical enterprise.

Which employees have the worst security behavior?

Ever wonder which employee has the worst security behavior? New employees come in to the organization and get training in information security. They are instructed about the hazards of clicking on links in email messages from unexpected senders, the risks of using web mail and file sharing sites at work, and the potential liability of storing sensitive data on external media.

You send them out into the world to do good things, but you know that one of them is really going to cause big security problems. Looking at them as they leave the class, you are certain it is going to be one of the guys in the far left column.

 Back in the trenches, the security engineers and analysts are fighting the good fight of malware infections, bot nets, unsecured servers and hosts, broken security software, lost devices, attacks against the perimeter. Lots of activity. From whom is it stemming? If you could just get to the root ....who is causing these problems? Then you remember reading those cool posts on www.dieselcafe.com where you learned that you have all the data you need to answer your security questions.

Rolling up your sleeves, you determine that in order to identify the person who has the worst security behavior is going to require Active Directory (for employee information), the web gateway event logs (who is hitting high risk categories), the AV logs (who is getting the malware alerts), the system management logs (tells you patch levels and apps installed on systems), and the network vuln scan data.

You set up ETL jobs to periodically pull this data from its various sources in to your PostGres database and you bind the data together using hostnames and IP addresses from the DNS logs.

You crunch the data - looking at a simple count of security events by employee over the last three months and are surprised but not surprised that 90% of your security problems come from 1% of your users.

So you dive in and create the reports that will drive action in the organization and come up with something like this...

Armed with this, you know who the worst security actors are in the company. Starting with the biggest offenders, your team provides individual training to get the worst right. You see the curve flatten over time. You are proud of yourself. But then, you ask yourself, "Am I asking the right question?"

Which employees expose the organization to the greatest risk?

What you really care about is which employees expose the organization to the greatest risk. To figure that out you decide you need to tie in the security behavior score you've developed with the user access permissions and the system risk ratings. You have a centralized store of user system access permissions because you do periodic access permission certifications. And you have a database of the risk profile for each of those systems because of your risk management program.

Adding these together with the security behavior scoring that you already did...

Some tweaks to your report. Done! As it turns out, some of the people with better security behavior do need some attention, like Enoch Root, your CFO!

And by the way, it turns out that this guy is the one who was causing you all the grief :)

Questioning Information Security - It's all about the data

In Questioning Information Security Part 1, I argued that your security is only as good as the questions you ask.  If you never ask the question - is my network exposed to compromise through third party connectivity or how can my password reset function be defeated or who is using unauthorized systems on my network - you will never know the answer.

But great questions are only the seed of the answer. Just as a scientific hypothesis necessitates a quest of rigorous experimentation, an Information Security question requires data and analytics.

Data Collection

Fortunately, your environment has all the data needed to answer your security questions. Let me say it again - your environment has all the data you need to answer your security questions. The diagram below shows some of the data that is commonly available in enterprise network environments.

Mixed together properly, tour DNS activity, web logs, firewall logs, endpoint events, malware events, AD data, and net flow holds rich treasures to answer numbers of questions - ones that you are asking and ones that you haven't yet asked.

But how do you collect it? How do you process it? If your last attempt at wrangling and analyzing large amounts of data was back in 2005, you probably felt a bit like this guy.  The relational databases just didn't scale. It was expensive. It was a lot of work. And queries took forever.

The world of data processing began to change in 2005 when the Apache Software Foundation released Hadoop, an implementation of Google's MapReduce technology for parallel processing of huge data sets. As Hadoop because more accessible and associated technologies such as Hive and Pig wrangling this data wasn't so difficult any more. Now data analytics can occur on an industrial scale.

Massive data sets can be loaded in to commodity hardware running open source software and analyzed effectively, processing complex queries in reasonable time that was previously unthinkable. The shackles and overhead of relational data structures are off with the NoSQL paradigm and the structured and unstructured data can processed from all kinds of sources.

Of course, you don't have to collect all of the data in your environment to answer really meaningful security questions. Just start with the data necessary to answer well the core questions.

Data Correlation

Some cool questions can be answered by simply analyzing a single dimension of data that spans a long period of time, such as firewall or DNS logs. Things get exponentially more interesting when you correlate the different data sources together. How do you do this though with data from a variety of sources that was really never 'designed' to be together?

The common denominators of the data is an ip address or a hostname. All your data that interacts with the network can be tied pretty easily to one of these two attributes. With data collected over time and correlated, really interesting questions can start to be answered.  Take Active Directory - useful to correlate stuff to that because that is where you can tie in to the users behind the events. AD doesn't have the IP address of each user, but the domain authentication logs do. Tie that to your DNS logs and you can get down to a hostname. Similar process for just about any other data source. I have found that doing this data enrichment is useful to do during the data load processing.

Data Contextualization

Data contextualization is simply the process of taking that security data and putting it within the context of its place in the business, the environment, the overall risk of the enterprise. Then, something as lonely as a vulnerability report can be really useful. Then you can know how important that vuln is because of the risk profile of the system it resides in, and you can report vulnerabilities by business unit or, better, by business process. You can tie vulns to specific people within specific business units. Lots of places you can go with other data.

Communication

Ultimately, these answers to the questions you've asked are valuable in so much as they result in action, which requires good communication. One of the goals is to make it valuable to the business and create a meaningful business-specific dashboard that isn't color-coded based on swags.

Rather, the dashboard is based on real data such that you can dive in to its dimensions and layers, such as the data behind outsider fraudulent Transaction in the retail division. Or employee accidental data loss in the R&D group. Being driven and derived from data, you might see rates of non-compliance with use of encryption on laptops and host-based external media controls and perhaps promiscuous policies related to use of cloud storage.

In the last post in this series, I'll expand on ideas for questions to answer using data collection, correlation, and analytics.