SCAP is becoming one of my favorite government acronyms: Security Content Automation Protocol. OK, what does that mean in English? Well, it’s a glue to hold together a whole slew of xml nummie data goodnesses such as the National Vulnerability Database and a standard for asset inventory management.

I was pretty skeptical on SCAP (and the Federal Desktop Core Configuration–FDCC) when it was first announced–like wow, we have yet another obscure memo from Karen Evans that we have to address.

I had a change of heart after I heard the magical phrase “We know it’s going to break things, and we don’t care”. That made me take notice. I thought about it all weekend–I was getting really riled up over such an obvious irresponsible security hard line. But then I found the magic in what they were doing and learned to stop fearing SCAP and embrace the love that it brings. I’ll tell you why.

Imagine you’re Microsoft. You can’t harden down your OS because you have all the applications vendors (including the A-V/Malware guys) raising the big anti-trust flag. And they’re right to do so. Maybe at one point, you could make your software “secure by default” but that was 20 years ago, and if you would have done so, you would have been last to market.

But that doesn’t work to plug the holes in the OS. In my opinion, it’s the lesson of Vista: if you make it stronger, it breaks applications. We all know that, so a design choice is to either leave the holes or give you a nag-screen or a combination of the two. Speaking strictly from the security side of things, that–along with continuous OS patching–is just “polishing a turd”. Yeah, you can make it all shiny on the outside, but deep down inside it’s still nothing pretty.

But now put yourselves in the Government’s shoes: You buy an OS and spend how much time and effort into OS hardening. That’s money you could spend elsewhere. The people at the top of the Government understand this, that’s why they’re always looking at ways to simplify.

OMB and others have been pushing SCAP pretty hard. So far, most of the focus has been on the databases that exist (CVE, NVD) and the desktop configuration (FDCC).

Think about a pre-hardened Government OS. What it does is break applications–applications that are poorly designed. If your application is poorly designed and doesn’t work with the FDCC, then you’re squeezed out of the public sector. The true capitalists here would say something like “let the market decide who the winners are” or something like that. Realistically, if you want a slice of the federal IT budget, then you need to make your software compatible with their hardening standard. They make it easy to do, with tools to test your software and a certification program.

The part that I like about SCAP is that it’s the Government doing what the OS vendors can’t–put pressure on the applications guys. As usual, this should have a trickle-down effect for the private sector, with the beginning being free hardening guides and the vulnerability databases and the end being a comprehensive information security management toolset.

Check out the presentations from the SCAP conference last month. The Tim Grance presentation (.ppt) alone is worth the price of admission.

Right now SCAP is at the national/CISO level. Give it 6 months and it will be at the forefront of what people are doing.

• Government Can’t Turn on a Dime, News at 11
• Comments on SCAP 2008
• Pre-Hardened Government OS
• NIST and SCAP; Busting a cap on intruders Part 1
• Ed Bellis’s Little SCAP Project

Now that we’ve talked you through building your own business reference model and building a data criticality matrix, we’re now going to tie it all together and give you the one true secret of information assurance: matching it all up with a security control baseline.

Now the way that NIST has things set up, it works like this:

• Determine the data types (BRM and SP 800-60)
• Determine the criticality for each data type (SP 800-60 and FIPS-199)
• Selecting a security control baseline (SP 800-53)
• Tailoring like a madman

We just did the first 2 steps. Now on to select a control baseline. In the NIST world, it’s easy: pick the right appendix (low, moderate, and high security control baselines) from SP 800-53 and get busy. The part that you don’t see is where NIST took all the applicable regulations and mushed them together into one solid catalog of controls to make it easy for you: do you want vanilla, chocolate, or rocky road? They added in internal controls (ala SoX), regulatory controls from laws like the Privacy Act of 1974, and controls from similar frameworks like BS7799. I should probably say “best practices” in there somewhere but I don’t believe in saying that phrase so I won’t. =)

But we’re now guerillas slaving away in the jungles of information assurance, we cut corners where we need to, and take more time than usual when we need to. We’ve gone fast and furious so far, but this is one step where we don’t need to go fast because what we do next directly determines how much money we spend. Because now we’re going to match up security needs and control requirements into something buildable. We’re going to do some regulatory c*mpliance tracing and control tailoring.

Now have a look at the data criticality matrix we made. See where I started to identify where the various data locations are? This is important, let’s take a look at these columns. Take a system, say, the Knowledge Management System. It’s Column Y, and it can be either a single server, a group of servers, or a whole DMZ set up exclusively for knowledge management–it doesn’t matter as long as we in the end tie it back into pieces of hardware and/or software. It doesn’t have client or incident data on it, which is a good thing. It does have HR data on it (really, what were we thinking when we put it there?) so the overall categorization of the system is MML and the system itself has to c*mply with SoX, Breach Laws, and our internal information security policy. That’s nice, we can deal with that–it’s better than doing Breach Laws for every IT system we have, no matter how big or small.

Need more examples? How about Column X, the Trouble Ticket System. It has trace amounts of client mission data and security incident data which happen to end up there–usually from the help desk who put it in there when a user calls in with a problem or when a tool captures the content of a TCP/IP packet when it triggers on an event like an IDS signature match. Since this is trace amounts of data, what I do is as the client if they are concerned about it. Usually they’re not–the data is not in a high enough aggregate to warrant any kind of controls above and beyond what I do for all my systems–anything else just isn’t that cost-effective to worry over.

One more trick of the trade: identify the governance drivers that apply to all the systems on your matrix. You’ve now just identified the common controls that need to be built for every system no matter what.

Now for each IT system/asset that we’ve identified (and the set of common controls), we can make a list of all the controls that that system has to have, then tailor those to engineering requirements that we can build. I have the start of an example in the CISO Book of Death under the tab “System 0001 Control Matrix”. Basically you put the control objective, where it comes from, and how you intend to build it. It’s exactly like a requirements traceability matrix only with some security words thrown in there. One pet peeve of mine: don’t call security controls requirements, you just confuse and frustrate the people who have to build them.

Now think about it for a minute. Why do we do all this? Well, somewhere in there is savings on licenses, hardware, redundancy, and audits because we just learned how to scope security controls. Less is always better, and what we’ve really done is to tell us where we need more security and where we need less.

Take a step back and guess what? We’ve now just reverse-engineered the beginning to the FISMA approach to information security:

• Break the enterprise down into bite-size pieces
• Determine criticality for each piece
• Determine security control requirements for each piece
• Determine something buildable and testable for each control requirement via tailoring and further definition
• Test to see if all the controls have been built
• Plan to fix the controls that don’t exist or are broken

But you all knew this was where we were headed with this business, didn’t you? The naysayers can now comment on how FISMA and Certification and Accreditation sucks. =)

I also think that maybe I need to spend some more time fishing because I’ve spent way too much time thinking about the BRM and data types.  Sounds like a plan for this weekend.

• And in This Corner, Special Publication 800-60
• In Search of a Better Catalog of Controls
• New SP 800-60 is Out, Categorize Yerselves Mo Better
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 1
• Some Random Thoughts on C&A SOPs

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

He’s a bit bloated but still remains the undeniable champion of business lines that the US Government operates. It’s the “business driver” of the Federal Enterprise Architecture. He’s the Business Reference Model and he’s not just for the federal-types to justify their existence. Let me explain….

The Business Reference Model is basically a hierarchy of all the functions that the US Government performs. The “short list” is the following:

• Services for Citizens
• Mode of Delivery
• Support of Delivery
• Management of Government Resources

And then underneath these broad headings is the fun things that we’re really interested in:

• User Fee Collection
• Contingency Planning
• IT Security
• Accounts Receivable

The BRM is fairly exhaustive so if you take any given government agency and what they do will fit somewhere on the chart. Every IT system I’ve seen fits somewhere, usually about 10 different places.

Now that we know how the government is supposed to work, I know what you’re thinking: how does this pass the “Dilligaf test?”

Well, to you and me, security dweebs at the core, a list of business functions means different types of information that each business activity needs. The BRM is in actuality a guide to the various data types that you’ll find throughout the government. When I say “Central Records and Statistics” what I really mean to say is “Data that supports Central Records and Statistics”.

But why do we care? We’re not the government, right? Well, we can take the same approach for a commercial enterprise.

Armed with this little bit of knowledge, I have my own business reference model and data types for what I do on a daily basis:

• Customer Mission Data
• Security Incident Data
• Internal Purchasing Data
• IT Infrastructure Management Data
• Contracts Collateral Data
• Billing Data
• HR Data

This started out as the “holy three”: customer data, contracts/collateral data, and NOC/SOC data. Then I expanded from there. You could just as easily start with something like this: purchasing, selling/marketing, and billing. Or maybe something like this: making money, spending money, and order fulfillment.

And then I have a matrix that says where this data is, here are some of the obvious locations:

• Corporate Email System
• Knowledge Management System
• Shared Directories
• Laptops
• Web Site
• Trouble Ticket System

Well, once you define what things you accomplish as a business, you can start to list where it’s at, or at least the majority of it. Occasionally you’ll get a shocker. =)

Coming up next: What you can do with BRM and Data Types and the fait accompli.

• And in This Corner, Special Publication 800-60
• New SP 800-60 is Out, Categorize Yerselves Mo Better
• Compensating Controls
• Blow-By-Blow Commentary
• DILLIGAF!!!

I spent a couple of hours today mucking around with Debian and WPA.  Yeah, yeah, you’re all thinking it’s about time I did something instead of bloviate about FISMA. =)

Anyway, I found the best resource on “The One True Debian Way” (TM) to set up WPA.  I gave myself a roaming setup using wpa_supplicant.conf

This is especially important to me now that I’m going out in areas with a ton of wifi interference–I need to be able to intelligently select which AP I’m connecting to since the neighbors have wide-open wifi that is much too easy to associate with.

• How I Became the Owner of Two Rogue WiFi APs
• Blow-By-Blow Commentary
• Stress-Test Apache with Intent to Tune: BSOFH Tip for the Software Masochist
• Assessment Cases for 800-53A Are Available
• Hack Disaster Relief

Interesting news article about some of Boeing’s problems.

This is an industry problem, one that we don’t talk about too much, and the heart of it is that it’s hard to manage security in huge organizations. Sure, there is the infosec frameworks like 7799/27001, FISMA, etc. If you look at the fairly undeveloped pieces of security, you’ll notice some trends:

• At the tactical level, we know vulnerability scanning, exploit writing, and hardening standards.
• At the operational level (Army sense of operational–we’re talking brigades and divisions here), we have risk management, certification, and my favorite whipping-boy, compliance.
• At the strategic level, we have enterprise architecture, inventory management, and capital planning.

My opinion, and it’s purely opinion, is that as you progress up the ladder to strategy, there is less and less of a knowledge base and a higher rate of opportunity for charlatans. But then again, it echoes IT management in general–everybody knows how to build a fairly secure server, not a whole lot of people know how to manage IT infrastructure for 75K users.

Purely as a sidenote, ISM-Community is working to be a player in the operational and strategic area of security, I’m just trying to figure out how to get more people involved.

• Core Belief #4 — Compliance is a Dead-End
• Lousy Security Advice
• In Which Our Protagonist Discovers We Need More Good Public Policy People Who Understand Security
• NIST’S FISMA Pase II–Who Certifies Those who Certify the Certifiers?
• Build a Security Program