I’m mulling over some ideas this week.  It’s probably the death-by-CBT that being a new hire has become over the past 5 years.

I work with a ton of accountants in my new job.  Obviously, they’re CPAs and Uber-CPAs, and for the most part, they’re proud of the valuable service that accountants bring to their community and to the US economy as a whole.  $Diety bless them, there is no way I have the patience to do what they do on a daily basis, and from what I gather, they feel the same way about what I do.  However, while learning the history of the accounting profession, I can’t help but notice a couple of things:

• CPAs have some strange ideas and a rich history, cross-training has some merit.
• Accountants are obsessed with compliance.  More on this later.
• Attestation that a company has not cooked the books and is headed into a downward Enron/Worldcom/Hindenburg-esque firey crash is a good thing.
• Accountants highly value attestation.
• Accountants are typically weak on planning and project management (yes, making a generalization here).
• Accountants understand risk, but only qualitative dollar risks that can be measured via actuarial means.
• Accountants perform unnatural acts with spreadsheets.
• I have to be very careful when I mention the word “controls” because somewhere in there an interpreter is needed.

And then somewhere around day 3 of CBT-Hell, it dawned on me:  we’re taking the models for accounting and applying them en-mass to information security management.  Explains quite a bit of things, doesn’t it?

Stop and think about the Federal government.  Who is really in charge of security?  Not NIST, they just write standards.  The correct answer is the Office of Management and Budget (OMB) and the Goverment Accountability Office (GAO).  In other words, the accountants and the auditors.  It’s one of those things that make you go “hmmmm”.

Now, some of this is a necessary evil.  Any good CISO will tell you that whoever controls the money controls the security, just ask a security manager who has had their budget taken away.  As a profession, we’re tied to the economics of security just as tightly as the accountants are tied to the security of IT systems to maintain integrity of accounting systems.  It’s scary when you think about it, although I don’t know if it’s scarier for them or for us. =)

There’s an obvious reason why we adopted the accounting models for security:  expediency.  In the typical CIO’s option of build-buy-outsource, we outsourced the creation and maintenance of our governance model to the accountants.  And just like outsourcing to a managed service provider who has in turn offshored some of their operations, we might not be getting what we planned at the very beginning.

But now we’re getting to the limitations of using that model:

• For the most part, we are an industry driven by vulnerabilities and risk management.
• Accounting is driven by law and oversight boards.
• What laws we have are very broad because the laws cannot keep pace with the technology.
• Information security is not reported to oversight agencies/boards/whatever to the same level of granularity as is financial information.  Imagine reporting your WSUS stats on your SEC filing.
• Even the accountants are starting to agree on a more risk-based model than a compliance model.  The latest guidance from the SEC on SoX 404 called AS-5 is a step in this direction.
• IT has a higher level of acceptable risk on both an organizational and personal level than accounting.
• The accounting model is focused on audit and oversight.  Typically this is at the end of development and/or annually.
• True success in information security management needs a full-SDLC approach.

So this is what I’m mulling over:  we maybe have a need for some better tailoring of what we’re doing.  What I really want is a large-scale method for security management that cuts out the parts of the accounting model that don’t work.

Not that I have an answer today, but it’s something I’m using my spare brain cycles to figure out.  Who knows, maybe I’ll come full-circle and reinvent the current state. =)

• In Search of a Better Catalog of Controls
• Workin’ for the ‘Counters: an Analysis of my Love-Hate Relationship with the CPAs
• Ack! With the Mandates!
• An Open Letter to NIST About SP 800-30
• It’s a Problem of Scale!

Tired of complaining about how FISMA doesn’t work? Well, do something about it.

Go to the NIST Publications Announcement List and get extremely low-volume (at the most, 1 post per month) email announcements on *tada* new NIST Publications.

For anything in a draft version, there are instructions on how to give NIST feedback. Now the big problem for them is that the people who have a real interest in making comments are all in the government sector.  They could use valid feedback from people outside the “inner circle” of government security.

In the words of a past leader of mine, “Don’t criticize unless you have suggestions on how to make it better.”  Well, for those FISMA-naysayers (*cough* NPO, rhymes with “CANS” *cough*), this is your chance.

• Do You Know What FISMA Is?
• On Government Employees, Culture, and Survivability
• Remembering Accreditation
• An Open Letter to NIST About SP 800-30
• Old Saint NIST: Ho Ho Hold on, what’s this?

Those cheeky devils over at NIST have an interesting read out in draft form:  NISTIR 7328 (.pdf caveat).  It’s a draft Interagency Report, but in reality it’s a how-to on being assessed and being the assessor.

I’ve given it a glance and it’s all the things that successful Security Test and Evaluation teams have been doing all along.  I know there’s some kind of “take-away” (my MBA phrase for today) that works out in the private sector.

• Help the Government, Become Literate
• How I Do the “FISMA Thang”
• Micro Digital Signatures Howto
• On SP 800-39
• SP 800-53A Now Finally Final

This blog post starts with the Data Security Lifecycle. I had a good IM conversation yesterday with Rich Mogull of Securosis fame about his recent Data Security Lifecycle theme. He’s been focusing on classifying data and from there determining what security controls he needs.

The detailed process according to Rich with how they translate to my world:

1. Design your basic classifications. I suggest no more than 3-4, and use plain English. For example, “Sensitive/Internal/Public”. If you deal with personally identifiable information (PII) that can be a separate classification, and call it PII, NPI, HIPAA, or whatever term your industry uses. (SP800-60, determine data types)
2. Pick one type of critical data that is easy to recognize. I highly recommend PII- credit card numbers, Social Security Numbers, or something similar. (FIPS-199)
3. Get executive approval/support- this has to come from as high as possible. If you can’t get it, and you care about security, update your resume. Beating your head against a wall is painful and only annoys the wall and anyone within earshot. (getting your FIPS-199 reviewed/approved by the DAA/CISO/whoever)
4. Issue a memo requiring everyone to identify any business process or IT system that contains this data within 30/60/90 days. (we don’t really do this, but it is a system boundary definition task)
5. Collect results. (write your boundary statement)
6. While collecting the results, finalize security standards for how this data is to be used, stored, and secured. This includes who is allowed to access it (based on business unit/role), approved business processes (billing only, or billing/CRM, etc.), approved applications/systems (be specific), where it can be stored (specific systems and paper repositories), and any security requirements. (grab a baseline of security controls and tailor the h*ll out of them)
7. Security requirements should be templates and standards with specific, approved configurations. Which software, which patch level, which configuration settings, how systems communicate, and so on. If you can’t do this yourself, just point to open standards like those at cisecurity.org. (hardening standards and catalog of controls–800-53 and the “new” SCAP stuff)
8. Issue the security standards. Require business units to bring systems into compliance within a specific time frame, or get an approved exception. (write your draft SSP which details all your security controls)
9. IT Security works with business units to bring systems/processes into compliance. They work with the business and do not play an enforcement role. If exceptions are requested, they must figure out how to secure the data for that business need, and the business will be required to adopt needed alternative security controls for that business process. (C&A staff work with the project team. Not a big deal, but more often than not, they don’t do it.)
10. After the time period to bring systems into compliance expires, the audit group begins random audits of business units to ensure reporting accuracy and that systems are in compliance with corporate standards. (do security test and evaluation)
11. Business units periodically report (rolling schedule) on any changes on use or storage of the now-classified data. (ongoing assessment and mitigation)
12. Security continuously evaluates security standards, issues changes where needed, and helps business units keep the data secure. (annual/periodic security review)
13. Audit plays the enforcement role of looking for exceptions. (annual/periodic security reviews)

Whoa, it’s a blast from the past! Looking back at his process, I realized that he had come full circle and reinvented certification and accreditation. Way back in June I did exactly the same thing and came to the conclusion that there is only one way to do things right, and that way is what Certification and Accreditation was meant to be.

Wait, you all need to see this picture again, this is the one that people should have tattooed on their arm for quick reference:

So the big question is, if C&A is so much nummie goodness, why is it that the conventional wisdom out there in the industry is that C&A doesn’t work? I think it’s 2 things really:

#1 C&A doesn’t work right now. And I’m going to get the locals knocking at my door with torches and pitchforks but one of the reasons we fail at this is because we put the wrong people in charge of C&A. The typical career path for a C&A person usually goes along the following route: English degree => policy and procedures writer => technical writer => security controls documenter=> C&A specialist => end of career. Nowhere in there is anything even remotely close to what a C&A specialist needs. The career path should be something like this: technology degree => IT operations (~2 years) => engineering (~2 years) => security engineering (~3 years) => Security Test and Evaluation Engineer (~2 years) => ISSO => ISSM => CISO. Somewhere around the SE/ISSO timeframe should be some business training.

Notice my second career path doesn’t have a dedicated C&A person. To be bluntfully honest, I don’t believe in a dedicated C&A specialist because all the C&A tasks are really security-in-the-SDLC tasks. So yes, I agree with the naysayers here on that point. To be brutally honest, I think that 3/4 of the dedicated C&A people need to be sleeping on a park bench off Constitution Avenue. But before you get to thinking I’m a complete hater, I also say the same thing about auditors and “those who would disagree with me.” =)

However, when you put the tech writers in charge of SDLC and risk management, they do what they know and what they know is grammar and styleguides, not threat-vulnerability-countermeasure pairings.

#2 SANS and Alan Paller. It’s one of those PR tricks: if you say something enough times, it becomes true. Paller and some of his instructors (not all, mind you) take every opportunity they can to use any news even to “prove” that C&A doesn’t work. Of course, Paller is a different blog post entirely, but truth is, he’s competing for training dollars with the policies and procedures guys and it seems like his job description involves getting as many butts in seats as he can. Hey, he even does a good job at it.  Given my reason #1 above, well, I think Paller is right.  Sometimes.  I’ll go hang my head in shame now. =)

So now I know you’re all thinking: If this C&A thing is so great, how do we fix it and turn it into something that it’s supposed to be instead of a bunch of overpaid ninnies arguing over whether a document should have 1 or 2 spaces after a period? Well, these are what I see as the keys to success:

• Recruitment of skilled engineers into security slots.  We need more clueful people, it’s that simple.
• Cross-training of senior and mid-level managers into some security knowledge.  If they keep thinking that the security people are voodoo practitioners, they can’t help us help them.
• Complimenting the technical side with the business side.  2 different worlds, and the good CISO sits in the middle of them.
• Reallocation of C&A specialist tasks to security engineer or ISSO tasks.  The only reason dedicated C&A specialists exist is because the people who should be doing the job do not understand what the job is–we’re back to peddling voodoo again.
• Understanding the mantra of “Above all, do risk management”–if what you’re doing doesn’t support reducing risk, why are you still doing it?

• Core Belief #4 — Compliance is a Dead-End
• Remembering Accreditation
• A Niche to a Niche is Still Hard to Staff
• An Open Letter to NIST About SP 800-30
• New SP 800-60 is Out, Categorize Yerselves Mo Better

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

We’re having a 2-day Certification and Accreditation seminar in September.  The material is vendor-agnostic (read: no brochures except for more seminars) and we have some good guest speakers lined up including somebody from the NIST FISMA Implementation Project and some of the CISOs around DC.

I might or might not be speaking, depending on how the final staffing works out.  No matter, I’ll catch the next one around. =)

• Another 2-Day C&A Seminar
• Build a Security Program
• FISMA Fellows Spring Cohort
• Your Friendly Neighborhood C&A Podcast Panel
• Certification and Accreditation Seminar, March 30th and 31st