As we discussed in Defining CSM, identifying your critical assets and monitoring them continuously is a key success factor for your security program – at least if you are interested in figuring out what’s been compromised. But reality says you can’t watch everything all the time, even with these new security big data analytical thingies.

So the success of your security program hinges your ability to prioritize what to do. That was the main focus of our Vulnerability Management Evolution research last year. Prioritizing requires you to determine how different asset classes will be monitored. You need a consistent process to classify assets. To define this process let’s borrow liberally from Mike’s Pragmatic CSO methodology – identifying what’s important to your organization is the critical first step.

So a critical step is to make sure you’ve got a clear idea about priorities and to get the senior management buy-in on what those priorities are. You don’t want to spend a lot of money protecting a system that has low perceived value to the business. That would be silly. – The Pragmatic CSO, p25.

One of the hallmarks of a mature security program is having this elusive buy-in from all levels and areas of the organization. And that doesn’t happen by itself.

Business System Focus

When you talk to folks about their data leak prevention efforts, a big impediment to sustainable success for the initiative is the ongoing complexity of classification. It’s just overwhelming to try putting all your organization’s data into buckets and then to maintain those buckets over time. The same issues apply to classifying computing assets.

Does this server fit into that bucket? What about that network security device? And that smartphone? Multiply that by a couple hundred thousand servers, endpoints, and users and you start to understand the challenges of classification. An approach that can be very helpful for overcoming this overwhelm is to think about your computing devices in terms of a business system. To understand what that means, let’s return to The Pragmatic CSO:

The key to any security program is to make sure that the most critical business systems are protected. You are not concerned about specific desktops, servers or switches. You need only be focused on fully functioning business systems. Obviously every fully functioning system consists of many servers, switches, databases, storage, and applications. All of these components need to be protected to ensure the safety of the system. – The Pragmatic CSO, p23

This requires aligning specific devices to the business systems they serve. Then those devices inherit the criticality of the business system. Simple, right? Components such as SANs and perimeter security gateways are used by multiple business systems, so they need to be classified with the most critical business system they serve.

By the way, you are doing this already if you have any regulatory oversight. You know those in-scope assets for your PCI assessment? You associated those devices with PCI-relevant systems with access to protected data. Thoey require protection in accordance with the PCI-DSS guidance. Those efforts have been based on what you need to do to understand your PCI (or other mandate) scope, and we are talking about extending that mentality across your entire environment.

Limited Buckets

To understand the difficulty of managing all these combinations, consider the inability of many organizations to implement role-based access control on their key enterprise applications. That was largely because something like a general ledger application has hundreds of roles, with each role involving multiple access rules. Each employee may have multiple roles, so RBAC required managing A * R * E entitlements. Good luck with that.

We suggest limiting the number of buckets used to classify business systems. Maybe it’s 2. You know, the stuff where you will get fired if breached, and the stuff where you won’t. Or maybe it’s 3 or 5. It’s no more than that. We are talking about monitoring devices in this series, but you needs to implement and manage different security controls for each level. It’s the concept we called Vaulting a couple years ago, also commonly known as “security enclaves”.

After identifying and classifying your business systems into a manageable number of buckets you can start to think about how to monitor each class of devices according to its criticality. Be sure to build in triggers and catalysts to revisit your classifications. For example, if a business system is opened to trading partners or you authorize a new device to access critical data. As long as you understand these classifications from a point in time and need to be updated periodically, this process works well.

Later in this series we will talk about different levels of security monitoring, based on the data sources and access you have to devices and specific use case(s) you are trying to achieve.

Employees Count Too

We have been talking about business systems and associated computing devices used to support them, but we cannot forget the weakest link in pretty much every organization: employees. You need to classify employees just like business systems. Do they have access to stuff that would be bad if it’s breached, and how are they accessing it – mobile vs. desktop, remote vs. on-network, etc.?

The reality is that you can place very limited trust in endpoint devices. We see a new story of this 0-day or that breach daily, compounded by idiotic action taken by some employee. It is no wonder no one trusts endpoints. And we have no issue with that stance. If that forces you to apply more discipline and tighter controls to devices it’s all good.

There is definitely a different risk profile to a low-level employee operating on a device sitting on the corporate network, compared to your CFO accessing unannounced financials on an Android tablet from a cafe in China. Part of your CSM process must be classifying, protecting, and monitoring employee devices. Where legally appropriate, of course.

Gaining Consensus

Now that you have bought into this classification discipline, you need to make it reality. This is where the fun begins – it requires buy-in within the organization, which is never easy. First you need to enumerate the influencers who can derail this process before it even begins. You need to get them lined up before you pitch the idea formally to anyone. Once those folks are on board with the concept (we know this is a non-trivial endeavor), you can present the different classifications and monitoring scenarios for each level of criticality, and get approval to move forward.

Of course you can monitor plenty of stuff without organizational buy-in. But not as a core function of your security program. You would be stuck doing one-off monitoring of certain assets or systems rather than taking an enterprise-wide approach to monitoring to detect issues and shorten the window of organizational exposure.

Once you get the green light to move forward, you need to start horse trading. This is one of those aspects of getting things done in the real world they don’t teach in infosec or business school. Once you are done with this process, you will think that passing healthcare reform anywhere in the world is a cake walk. All kidding aside, success is constrained by the types of compromises you are willing to make. You need to keep the big picture in mind: without a way to classify your assets you cannot really succeed with any monitoring initiative. So stay focused on the long term and get the support of the folks you need.

One of the key aspects of this horse trading is defining exceptions. You have special folks in your environment who play by different rules. You may not know who they are but they exist and you need special policies for them. Yes, it’s irritating that they don’t have to play by the same rules as everybody else, but that’s life. Again, success is a matter of getting rid of all exceptions – it is a matter of minimizing them and making sure that even the special folks have to adhere to a certain level of security and monitoring control.

If you have too many exceptions your monitoring program becomes too complex and unmanageable. Too few exceptions and you will never get the consensus you need to succeed. So go into this process understanding that a lot of work is required before you ever put your hands on a keyboard, start aggregating data, or otherwise doing anything technical.

We have focused on the process aspects of CSM, mostly to be clear that the right process is essential for your initiative. Now we are ready to dig into technology. Our next post will itemize the data sources you need to collect and aggregate for CSM, and touch on requirements for the aggregation platform.