This is the 7th blog in a series about security and how security is about how you think.
In my last blog, I started looking into security monitoring of my house and asking the question about what I monitor. In this blog, I’m going to take a look at the overall process of security and start to tie together all of the pieces of security.
One of the best ways I’ve seen to describe security at a conceptual level is a five step program (no, not like those other twelve step programs).
Now it’s really not that hard to implement this five step program.
Step 1 – Define what should be happening. This is what we defined as the security policy (or policies). If I’m talking about my house, these policies will be “all doors will be locked when everyone is out of the house”, “all people showing up at the front door will be identified through the peephole before the front door is opened”, and “the milk should always be fresh in the refrigerator.”
If I’m talking about my computer datacenter, it will be that “all traffic will be inspected before it is allowed through the DMZ”, “all users will use two-factor authentication to access the database server”, and “all logs will be sent to the SIEM system”. Pretty straightforward, but the problem is to define what policies exactly capture what should be happening, being as specific as possible, but not *too* specific. More about this topic in a subsequent blog.
Step 2 – Discover what is really happening. This really is the toughest part of the puzzle. We have to be able to determine the events of the entire system and be able to decipher what is happening with each environment. As we talked about in a previous blog, getting the complete picture is crucial – and getting it easily is the ultimate goal.
Step 3 – Determine the differences between Step 1 and Step 2. Another hard part – how do we know where the differences are? I would be best for us to save the system policy and the system would tell us where the security alerts would be. At least, we would want the system to tell us about any security “events” (normal events which contribute to security) – but how do we know? Sometimes what seems normal (someone logging in) may not be normal (credentials were compromised and used by someone else). This step uses rules to take the data from steps 1 and 2 and sort out where the differences really lie. And these rules keep getting updated with what we know now.
Step 4 – Prioritize the list from Step 3 and fix all of the differences. This is where we fix what’s not correct. If the list is empty, then we’re secure, but more often than not, we’ve got items to address – the milk is expired or the front door was left open. Prioritizing a few events is really easy, but in the computer datacenter – how do I quantify which ones out of the firehose of events are worse than others? We’ve got to analyze which ones are the most serious to the business – business risk – and address those first. Am I making sure that all data is encrypted in transit to all suppliers? Am I ensuring that all employees and contractors are signing in with two-factor authentication and changing their passwords to a strong password every 90 days? If we look at the differences with an eye towards the business, and start with the worst first, we can fix the big problems first.
Step 5 – Go to step 1. Quickly. We should be executing this loop as fast as physically possible. With my home, it’s probably once a week. In a computer datacenter, it should be every millisecond or faster. And with a computer datacenter, doing these steps in an automated environment is key.
The biggest problem here is that if the system policy changes. If I determine that a difference isn’t really a difference, then I have to change the system policy (or provide an exception) and then I’ve got to adjust. For example, it’s okay if I leave the front door open if I’m just going to the mailbox to get the mail.
By following this simple five step program, we can be more secure.