Over all the years in security, there are a few problems, which land on my desk over and over again. One â€“ as an example â€“ is how to really, practically assess risks, one is how to measure security and one is event correlation. I know that tools are sold for each of these problems and a lot of companies claim that they have almost a silver bullet but there are hardly any really satisfying solutions for these complex problems.
When it comes to event correlation, I recently read different articles, which show the obvious: The events should be monitored according to the business processes and needs. If there is an outgoing connection from a server to a TV-site, there is most likely a violation of policy or a compromise of the server as there is hardly a business need for this (there might be exceptions).
For security people, this has different challenges: We cannot build our monitoring solely on publically available tools, which assess publically available information on indicators of compromise. If you are a skilled attacker, you work around them anyway. Not that they are not needed but this cannot be more than a start. Even worse, we as security people have to go out and understand the business. We have to look at policies the “business-way”. I wrote more than once in my blog that security shall not hinder the business to be efficient and effective â€“ we have to support them in the best possible way without exposing the company to unacceptable risks (which is, by the way, a business decision).
A few days ago, an article was published on CSO Online, which is definitely worth reading: Developing business-driven indicators of compromise.
If you read through it, there are a few remarkable statements. The key to Indicators of Compromise (IOC) is not only to understand abnormalities but
However, Constantine makes it a point to note that it isn’t just about abnormalities, but certainties as well. It’s important to identify the things that should never happen within the organization, such as access to a source code directory from a computer assigned to marketing.
“My general method for building your own organization-specific IOC’s is to look to your own security policy, then identify actions that would violate that policy, and implement alerts for the events in your logs that would indicate those violation,” he said.
Now, that’s dangerous as policies are often not written with the business in mind but with “best practices”. Therefore:
“Conversely, I’ve seen many policy entries that describe extravagant procedures regarding Administrator access to Executive Email services, but when we started looking for examples of this happening, it was occurring many times a day, usually via a request from the execs themselves. The policy did not match the reality of how business was getting done â€” and that meant the policy had to be changed to reflect that,” Constantine said.
Now we are coming to the point:
When security policies are first measured against organization-specific IOC’s, several violations will come to light. One of the harshest realities that the organization will face during this process is the fact that there’s a big difference between how the business assumes IT resources are used, and how they’re actually used.
The trick is to measure the discovered violations against the level of risk the organization can tolerate. If an IOC violates a policy, but the policy actually hinders workflow or the goals of the business, then the policy needs to change. The simple fact is, security policies “should serve the business, not the other way around,” Constantine said. So if the business chooses to do something in an insecure way, you’re going to have to design around it.
Security teams, Constantine said, have a nasty habit of designing their monitoring around an idealized model of “some theoretical ‘secure infrastructure’ â€” instead of going out and understanding how their particular organization does business and securing that.”
In my opinion, this business focus and a necessary (and possible) simplicity have to the be the goal of security going forward. This is the only way to have a real view on security and to secure the key assets.
The statements in this article seem obvious to me and I guess to you as well. But they are hard to execute. Security people have to leave the comfort zone of their policies and enter the harsh and windy world of the business. All of a sudden, we cannot hide anymore behind the policies but maybe question the policies as they hinder the business to execute.
Understanding all the needs of the policies and the complexity of a policy change, I am still convinced we need to adapt and not the business. This is a new skillset, which is needed by security people but an important one â€“ the one which helps us to be successful and not to have a wrong sense of security.
- Developing business-driven indicators of compromise (pcadvisor.co.uk)
- Developing business-driven indicators of compromise (computerworld.co.nz)
- Developing business-driven indicators of compromise (networkworld.com)
- Developing Business-Driven Indicators of Compromise (cio.com)