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.
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?"
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 :)
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.
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 :)