Skip to content ↓ | Skip to navigation ↓

In the first installment of this series, we provided a general overview of the concept of continuous security monitoring (CSM), and in the second article we explained how it can help your organization react faster and better to threats. In the third article, we examined the challenges regarding obtaining full visibility into your environment, and now continue with a discussion on classifying your network assets.

Classifying Assets

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 has been compromised. But reality says you can’t watch everything all the time, even with these new security big data analytical thingies.

The success of your security program hinges on your ability to prioritize what to do. That was the 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 Rothman’s Pragmatic CSO methodology — identifying what’s important 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, p 25.

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 (DLP) efforts, a big impediment to sustainable success is the ongoing complexity of classification. It’s just overwhelming to try putting all your organization’s data into buckets and then maintaining those buckets over time. The same issues apply to classifying computing assets for monitoring purposes.

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. One way to avoid being overwhelmed is to think about your computing devices in terms of business systems.

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, p 23

This requires aligning specific devices with the business systems they serve. Each device inherits the criticality of its most critical 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? Those PCI-relevant systems have access to protected data, which is a form of classification. Those 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 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 is largely because something like a general ledger application has hundreds of roles (R), with each role involving multiple access rules (A). Each employee (E) may have multiple roles, so RBAC requires 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 that gets you fired if breached, and the stuff that doesn’t. Maybe it’s 3 or 5 — no more. We are talking about monitoring devices in this paper, but you also need 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 you should revisit the classifications 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 are based upon your needs at particular points in time, and need to be updated periodically, this process works well.


As much as we try to focus on business systems in our classification efforts, you should still factor in the additional risk presented by Internet-facing devices. These devices are sitting ducks, open to reconnaissance and attacks by anyone with a scanner or Metasploit. If there is a hole in these devices, it will be found and exploited quickly. Therefore these devices carry more risk and likely warrant more frequent assessments.

Employees Count Too

We have been discussing 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 breached, and how do they access it — mobile vs. desktop, remote vs. on-network, etc.?

You should place very limited trust in endpoint devices and the employees that use them. We see new stories of this 0-day or that breach daily, compounded by an idiotic action taken by some employee. This should force you to apply more discipline and tighter controls to all of your computing devices.

To further illuminate this concept, there is definitely a different risk profile for a low-level employee operating on a device sitting on the corporate network, than 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. As 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. There are really two efforts here.

1. The Informal: Akin to back-room politics, you need to get to the influencers and get them on board with the idea. These are informal discussions about getting support.

2. The Formal: Here you present to some kind of task force or senior management group for approval for an enterprise-wide initiative, with the funding, resources, etc. required to make it happen.

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.

It is unwise to make a formal pitch before making sure you won’t get your hat handed to you (see, we’re trying to be polite) when you ask for approval. Unless you have recently had a breach — then nobody says much of anything about whatever you want to do.

In terms of who to approach informally, it’s the folks who run ops (since this will impact them), the IR team (who will need to investigate things the monitors find), and likely the network folks because you will consume some network resources and need to tap some areas of the network.

Once those folks are on board with the concept (and we know that is a non-trivial requirement), 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 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 the CISSP course. Once you are through this process you will consider passing healthcare reform anywhere in the world a cakewalk.

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. 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 isn’t a matter of getting rid of all exceptions — it is about minimizing them and making sure that even the special folks adhere to a certain level of security and monitoring control.

If you have too many exceptions your monitoring program becomes too complex and unwieldy. 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.

One of the key aspects of this horse trading is defining exceptions. You have special folks in your environment who play by different rules.

The Use Cases

At the highest level we generally see three discrete use cases for CSM:

  • Attacks: This is using security monitoring to identify potential attacks and/or compromise of systems. This is the general concept we have described in our monitoring-centric research for years.
  • Change control: An operations-centric use case is to monitor for changes, both to detect unplanned (possibly malicious or dangerous) changes, and to verify that planned changes complete successfully.
  • Compliance: Finally, there is the checkbox use case, where a mandate or guidance requires monitoring and/or scanning technology; less sophisticated organizations have no choice but to do something. But keep in mind that the mandated product of this initiative is documentation that you are doing something — not necessarily an improved security posture, identification of security issues, or confirmation of activity.

Notice these use cases are listed from broadest and most challenging, to narrowest and most limited. The attack use case is bigger, broader, and more difficult than change management; compliance is the least sophisticated. Obviously you can define more granular use cases, but these three cover most of what people expect from security monitoring.

This is a reversal of the order in which most organizations adopt security technologies. Many start with a demand to achieve compliance, then move to an internal control process to deal with changes — typically internal — and finally are ready to address potential attacks by analyzing aggregated data. Of course there are many paths to security and many organizations jump right to the attack use case, especially those under immediate or perpetual attack.

We made a specific decision to address the broadest use case first — largely because even if you are not yet looking for attacks, you will need to, soon enough. So we will start by laying out the entire process to monitor for attacks, and then show how you can streamline your implementation for other use cases.


In the next article in the CSM series, we will examine specific attack use cases… Stay Tuned!


Editor’s Note: This post is a series of excerpts from the Continuous Security Monitoring whitepaper developed by Mike Rothman of Securosis, and was developed independently and objectively using the Securosis Totally Transparent Research process. The entire paper is available here.


About the Author: Securosis Analyst/President Mike Rothman’s bold perspectives and irreverent style are invaluable as companies determine effective strategies to grapple with the dynamic security threatscape. Mike specializes in the sexy aspects of security — such as protecting networks and endpoints, security management, and compliance. Mike is one of the most sought-after speakers and commentators in the security business, and brings a deep background in information security. After 20 years in and around security, he’s one of the guys who “knows where the bodies are buried” in the space. Mike published The Pragmatic CSO in 2007 to introduce technically oriented security professionals to the nuances of what is required to be a senior security professional. He can be reached at mrothman (at) securosis (dot) com.


Related Articles:



picThe Executive’s Guide to the Top 20 Critical Security Controls

Tripwire has compiled an e-book, titled The Executive’s Guide to the Top 20 Critical Security Controls: Key Takeaways and Improvement Opportunities, which is available for download [registration form required].


picDefinitive Guide to Attack Surface Analytics

Also: Pre-register today for a complimentary hardcopy or e-copy of the forthcoming Definitive Guide™ to Attack Surface Analytics. You will also gain access to exclusive, unpublished content as it becomes available.


Title image courtesy of ShutterStock