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