Wednesday, March 28, 2007

Security Operations Fundamentals

Last year I last wrote:

Marcus [Ranum] noted that the security industry is just like the diet industry. People who want to lose weight know they should eat less, eat good food, and exercise regularly. Instead, they constantly seek the latest dieting fad, pill, plan, or program -- and wonder why they don't get the results they want!

You might be wondering about the digital security equivalent to eating less, eating good food, and exercising regularly. Addressing that subject adequately would take more than this blog post, but I want to share the steps I use as a consultant when encountering a new client's enterprise.

You'll notice that these steps fit nicely within Mike Rothman's Pragmatic CSO construct. These are a little more specific and focused because I am not acting as a Chief Security Officer when I work as a consultant.

  1. Instrument sample ingress/egress points. What, monitor first? That's exactly right. Start collecting NSM data immediately (at least session, preferably alert, full content, session, and statistical). It's going to take time to progress through the rest of the steps that follow. While working on the next steps your network forensics appliance can be capturing data to be analyzed later.

  2. Understand business operations. Replace business with whatever term makes you more comfortable if you are a .gov, .mil, .edu, etc. You've got to know the purpose of the organization before you can understand the data it needs to do its job. This requires interviewing people who know this, preferably business owners and managers.

  3. Identify and prioritize business data. Once you understand the purpose of the organization, you should determine the data it needs to function. Not all data is equal, so perform a relative ranking to determine the most important down to least important. This work must be done with the cooperation of the businesses; it cannot be security- or consultant-driven.

  4. Identify and prioritize systems processing business data. By systems I mean an entire assemblage for processing data, not individual computers. Systems include payroll processing, engineering and development, finance projections, etc. Prioritize these systems as you did the data they carry. Hopefully these two sets of rankings will match, but perhaps not.

  5. Identify and prioritize resources comprising systems. Here we start dealing with individual servers, clients, and infrastructure. For example, the database containing payroll data is probably more important than the Web server offering access to clients. Here tech people are more important than managers because tech people build and maintain these devices.

  6. Define policy, profile resources, and identify violations. Steps 2-5 have gotten you to the point where you should have a good understanding of the business and its components. If you have a policy, review it to ensure it makes sense given the process thus far. If you haven't yet defined a policy for the use of your information resources, do so now.

    Next, profile how those resources behave to determine if they are supporting business operations or if they are acting suspiciously or maliciously. I recommend taking a passive, traffic-centric approach. This method has near-zero business impact, and, if executed properly, can be done without alerting anyone insider or outside the company acting maliciously. Here you use the data you started collecting in step 1.

  7. Implement short term incident containment, investigation, and remediation. I have yet to encounter an enterprise that doesn't immediately find a hot-button item in step 6. Put out those fires and score some early wins before moving on.

  8. Plan and execute instrumentation improvements. Based on step 7, you'll realize you want visibility across the entire enterprise. Increase the number of sensors to cover all of the areas you want. This step encompasses improved host-centric logging and other visibility intitiatives.

  9. Plan and execute infrastructure improvements. You'll probably decide to implement components of my Defensible Network Architecture to take a more proactive stance towards defending the network. You may be able to reconfigure existing processes, products, and people to act in a more secure manner. You may need to design, buy, or train those elements.

  10. Plan and execute server improvements. Here you decide what, if any, changes should be made to the resources offering business data to users, customers, partners, and the like. Maybe you want to encrypt data at rest as well as in motion. Maybe you decide to abandon an old Web framework for a new one... and so on.

  11. Plan and execute user platform improvements. This step changes the gear users rely upon, so it's the last step. Users are most likely to resist that which they can immediately see, so tread carefully. Improvements here involve OS upgrades or changes, moves to thin clients, removal or upgrades of software, and similar issues.

  12. Measure results and return to step 1. I recommend using metrics like those I described here. Measure Days since last compromise of type X, System-days compromised, Time for a pen testing team of [low/high] skill with [internal/external] access to obtain unauthorized [unstealthy/stealthy] access to a specified asset using [public/custom] tools and [complete/zero] target knowledge, and so on.

You may notice steps 8-11 reflect my TaoSecurity Pyramid of Trust. That is no accident.

It is also important to realize that steps 8-11 are based on data collected in step 1 and analyzed in step 6. Enterprise security improvements should not be driven by the newest products or concept. Improvements should be driven by understanding the enterprise and specifically the network. Otherwise, you are playing soccer goal security by making assumptions and not judgements.

Only when you understand what is happening in the enterprise should you consider changing it. Only when you realize existing processes, products, and/or people are deficient should you consider changes or additions. Think in terms of what problem am I trying to solve, not what new process, product, or person is now available.


Keydet89 said...

The problem with most of these excellent and often-repeated steps are that most C-level managers seem to think that they will take $$ to perform.

Another thing..."Measure Days since last compromise of type X" assumes that (a) the organization is capable of detecting compromises, and (b) that they are also capable of determining the type of the compromise. This isn't always the case.

dre said...

Also see: "hamster wheel of pain". You want securitymetrics, not Rothman banter

free ps3 said...

Thanks for the nice post!