Remember the last post I did about the Business Reference Model? If you don’t, go read it now. We’re about to get freaky on it.

Have you ever had a chance to give everybody the opportunity to categorize their business functions for confidentiality, integrity, and availability as high, moderate, and low ala FIPS-199? You’ll know the effect if you’ve ever had to build a corporate website–everybody wants a link on the front page. The purchasing team wants a link on the front page so that prospective vendors can reach them, the HR people want the entire corporate employees’ manual online.

It’s a little organizational behavior factoid: everybody thinks that the silo that they operate in makes the business run. Translate that into security and we’ll find out that, left to their own devices to determine criticality, every business department lists its IT systems as high-criticality. Don’t tell my HR department, but if the personnel management system disappeared for a week, we would still continue to monitor networks. Even if the payroll system were to implode and we had to rebuild it from scratch, it wouldn’t matter unless it happened on or just before a payday–we would still be making money as a business. Yes, have an outage for 2 weeks and our employees would pretend to work because we’re pretending to pay them, and it would be just like the Brezhnev era. =)

Add in to the mix the fact that if your system is high-criticality, you get more money (in theory, that’s how the government determines the budget, reality may be a little different), and everybody in the government has a high-criticality system. In a classic case of “NIST to the rescue”, they have developed a totally awesome document that nobody reads called Special Publication 800-60. It’s more than everything a data and system classification geek would need to fall in love with.

Don’t try to read it from cover to cover. You won’t make it through. =) Instead, SP 800-60 is a reference to determine the criticality of systems using… wait for it… the BRM. As you might expect, it’s a good reference material like a government-wide data criticality dictionary. It level-sets the security expectations and definitions of what criticality is government-wide.

How do we use this thing? Well, the SP has a “stuffy” process description complete with phrases like “provisional impact level”, this is the Guerilla’s Guide to Data Categorization, so we’ll keep it simple:

• Take a business function.
• Locate it on the BRM. It might be in as many as 15 different places.
• Find the BRM section in 800-60.
• Read the description of the data, see if it fits what you’re looking for
• Look at the criticality description. Usually it’s a “fielder’s choice”: if the data matches <this description>, then it’s <this> critical, if it matches <this description>, then it’s <this> critical.
• Assign a criticality based on the 800-60 definitions.
• Use the “Common Sense Test”–does what you’ve assigned make sense? You might have other factors such as data aggregation that might make it worth more to you. Feel free to deviate.

So now, going back to my own private list of data types, let’s assign a criticality and a justification:

• Customer Mission Data–this inherits the criticality from what the customer says it is, which is usually MMM. But then again, I rate the criticality for my company and my business unit, which might be different from what the government thinks it’s worth.
• Security Incident Data–we own the systems that this data is on, but the government says that it’s high for criticality because they do not want to expose this data to the press until they’re ready and they have high integrity requirements so they can produce it as evidence and send the perpetrator to a “Federal Pound You .* Prison”. We segregated this data type from network monitoring and performance data because doing so means that we have a smaller pool/quantity of high-criticality data. Criticality is HHM.
• Internal Purchasing Data–usually LML criticality except for the SoX separation of duty for purchasing, etc. I don’t typically deal with this kind of data and rely on my company as a support vendor, so I have trace amounts under my control. Note that if your sole business is purchasing things for other people, this is probably MMH or thereabouts.
• IT Infrastructure Management Data–network monitoring data. Usually MML but inherits some criticality from the clients’ systems in that a monitoring system for a classified system is also classified even though it has trace amounts of mission data on it.
• Contracts Collateral Data–proposals and the like. This is MLL for CIA because we work with the government and most of it is public record but we still want to be able to keep our trade secrets secret if we’re working on a bid.
• Billing Data–MML. Our rates, where they came from, and the markup is for internal use only. It’s bad manners to show the customer your financial guts. =)
• HR Data–MML only because it contains private information that is the basis for data breach nightmares.

Notice what I didn’t explicitly state but I hinted around? You can have types of data that are covered under some regulation (yes, the infamous c*mpliance buzzwords). These can become data types in itself. For example, health information covered under HIPAA should be its own category of data.

Carrying this a bit further, I have my matrix which has the data types running down the left side with the following columns across the top:

• Criticality for client, corporation, and business unit
• Location of the data by IT system type (laptops, trouble ticket system, shared files, etc)
• Governing regulations (FISMA, NISPOM, Privacy Act, specific classifications)

Here, I think it’s hard to describe, I’ve posted it online for the world to see. I’ll add this into my “Book of Death” for the next revision. No, I didn’t spill the whole cookie jar, just give you a framework to build your own. If you want to pay me obscene amounts of money to come fill out a spreadsheet for you, I would be glad to, but you shouldn’t need that much help.

So what have we accomplished with this BRM exercise? Well, for a couple hours’ worth of work, I have the following things:

• A data criticality classification guide that I can hand to the security engineers to match up with security controls
• A security business impact assessment that I can hand to managers
• An azimuth check on which assets have the most value for us as a company
• A prioritization on who gets the biggest security budget
• A governance list to tell me which data types are governed by which regulations
• A list to exclude some assets from some types of regulations (ie, smaller scope means less audit when I have to pay for one)
• The start of a way to break down my enterprise into “bite-sized pieces”

And that’s a beautiful thing.

• In This Corner, the Business Reference Model
• New SP 800-60 is Out, Categorize Yerselves Mo Better
• Blow-By-Blow Commentary
• Another Day, Another Vendor
• Database Activity Monitoring for the Government