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

Nice concept on risk management applied to Meerkat Manor. I’m missing the drama, though–the blog posting just didn’t draw me in like it should.

Oh, to be a meerkat on sentry duty performing risk management for the clan. My story would go something like this:

09 October 2007: Dear diary, I drew sentry duty for the third day this week. I know it’s my solemn duty to protect the clan, but my risk assessment has determined that, although a predator is a high-impact event, it is a low rate-of-occurance activity and so I think a better use of my time is in foraging for stray eggs. Besides, if the predators come and eat us all, it’s not like I’ll have to face the Meerkat Manor Board of Directors.

10 October 2007: Dear diary, I grow tired of the incessant looking for predators. I mean, why do us meerkats focus exclusively on detective controls which use up to 15% of our available manpower when we could just as easily reduce the sentries to 5% of our efforts and put in place corrective controls such as trap holes and punji sticks to reduce the threats to our home? The true cost savings is that the effort for corrective controls is a one-time installation where sentry duty is a recurring bill. Didn’t the alpha-pair learn anything in their Masters in Meerkat Administration classes?

11 October 2007: Dear diary, today I instituted a metrics program to gauge the effectiveness of our sentry program and to determine if we are getting the best level of risk for the time that we are investing. So far, I’ve made a bar chart to analyze the total number of predator alerts versus the total number of predator intrusions. I think I have a business case to slowly reduce the ratio of sentries to foragers during the day.

12 October 2007: Dear diary, I noticed today that the younger meerkats are ineffective at sentry duty because of their inability to stand still for long periods of time without chasing each other around the veldt. This is a problem staffing-wise because sentry duty now takes some of the best, well-trained meerkats and takes them out of other occupations. I’m not criticizing my clan leadership, but I just feel like we’re doing a bad job at meerkat time management. Maybe we need to cross-train into other skills.

13 October 2007: Dear diary, I was standing on a rockpile today and the idea hit me: why don’t we do a meerkat predator drill weekly to instill confidence in our abilities to respond to a predator incident? I brought it up to the clan’s alpha-pair and they said they would “take it under advisement”. I guess that’s what it means to be just one of the peons out here, standing in the sun. I swear, if they don’t up my salary from 80 bugs to 90 bugs, I just might leave the clan and start my own on the other side of the hill.

14 October 2007: Dear diary, today we had a visit from the Better Meerkat Bureau’s auditors. Our clan pretended to be extra-vigilant and we put out several extra sentries to try to impress them. Some days I think the auditors would be happy if we all starved to death as long as we were all on sentry duty doing our part to keep the predators at bay. I guess that’s the price of blind compliance.

15 October 2007: Dear diary, I spent 3 hours today in bark training. Apparently the auditors reported back that our barks were substandard, so now we have every-friggin-la-dee-da-merkat out in the hot sun standing in a line practicing how to bark. I mean, come on, it’s barking, we do it all day. We bark when we’re scared. We bark when we’re mad. We bark when we’re hungry. But I guess auditors know what they know, and what they know are checklists, and we didn’t do too well in the bark section of ours for some reason, so here we are practicing.

16 October 2007: Dear diary, I had a meeting today with the meerkats from the “vendor” clan. They want to trade some food for some bald eagle repellent spray and a device called “Hole Access Control” which ensures that only meerkats from my clan can crawl down our holes and into our burrows.  Needless to say, I’m a little skeptical at first, I’ll see if I can get them to throw in an inflatable lion to “sweeten the deal a little”.

Postscript: Added the 16th of October because when I read this a second time I realized that I listed all the problems in the life of today’s risk manager except for vendors. That’s now been fixed. =)

• Core Belief #2 — Risk Management Uber Alles
• Indicator Species
• When Acceptable Risk is Not Acceptable
• A Visit from DCAA
• Meerkats Join the Big 4

I helped give our auditors from the Defense Contract Audit Agency (DCAA) some education on how managed services work. We did the usual presentation–who the building tenants are, what takes place in the various floors, and what services we offer.

In case you’re not familiar with DCAA, the basic rundown is that they are the financial auditors for government contracts.  They look at your numbers and try to detect how and where you are committing financial fraud.  In our case, we have distinct service descriptions and a set of financial and operational metrics to support  the numbers (ie, each server requires 1 hour per month on average to do patching and fix outages, so the cost to us is $100, add your markup and that’s the cost per month to monitor and manage a device).

This is risk management through education for us.  When you have auditors who don’t understand why an IT operations shop would need 13K gallons of diesel fuel (I thought you did IT?), the least you can do is to educate them.

• Combatting Tool Creep
• NIST and SCAP; Busting a cap on intruders Part 1
• Reinventing FedRAMP
• Rebuilding C&A
• Guerilla CISO Tip: Get Inside the Data Center

I’ve been courting with VLANs again this week.

For those of you who don’t habla routing and switching, VLANs are a way to carve out a virtual switch. You can share the VLANs over different physical switches using a technique called trunking, which comes in way handy.

Technically, it makes sense to take most (all?) of your switches and trunk them into one huge-gantic, gi-normous switch then do all the work withVLANs.  This is the “cram everything (router, firewall, and port modules) into one Catalyst 6500 chassis and have a nice day” approach which Cisco will gladly sell you.

Until you start looking at the typical setup. For DMZ servers (just about everything I deal with is in a DMZ of some sort), it’s fairly standard to have a switch (or any number thereof) sliced up by VLANs for different functions and then each VLAN segregated by a firewall.

The problem with this is when you put untrusted/external and  trusted/internal network segments on the same switch and use VLANs to separate them.  Basically what you’ve done is taken a “moderately robust security architecture” and configured it so that the switch is a single point of security failure.  That is, if you misconfigure or compromise the switch, you can bypass the firewalls.

In either case, being able to conduct a successful attack depends on misconfigurations which can happen anyway with firewalls, servers, and any other equipment that you own.  The real problem is that single-point-of-failure that the switch becomes.

My personal rules for using VLANs:

• Don’t put untrusted/external and trusted/internal VLANs on the same switch.
• Putting untrusted/external and semi-trusted/DMZ VLANs on the same switch is on a case-by-case basis.
• Putting trusted/internal and semi-trusted/DMZ VLANs on the same switch is on a case-by-case basis.
• Don’t trunk VLANs across trust boundaries.  IE, don’t mix up customer switches with our own switches.

I think the key for today’s CISO is that when people bring you drawrings of what the network looks like, you should get both a logical network drawring and a physical network drawing.  The differences between the 2 might shock you.  Usually when you’re asked to approve a design, you get the former and not the latter, so the usual caveats apply.

Further reading:

• Cisco guide to VLAN Security
• Steve Rouiller’s paper on VLAN attacks

• In Response to “Cyber Security Coming to a Boil” Comments….
• My System Environment
• CISO Trick: Know the Hiding Places
• Et Tu, TIC?
• Internet in the Remote Desert

“…so that I can tell you which security things you do not have to do.”

There are so many rules that security people deal with on a daily basis, the best part about taking a risk-based approach to security is that you know where you can ignore/cheat/circumvent/write “N/A” on it. That’s why I like the engineers to let me know when they’re starting a big project.

If you’re stuck at denying projects at the last point possible–at the point of implementation–then you’re way too late. Security involvement in projects should be before they even get funded (ie, during feasibility studies and requirements definition) so that we can get in our abbreviated list of needs and requirements.

Just like salmon, good security managers know how to “swim upstream to spawn”.

• When Acceptable Risk is Not Acceptable
• Core Belief #4 — Compliance is a Dead-End
• SP 800-53A Now Finally Final
• White Professional Male Turned CISSP Seeks Mega-Sized Security Management Model
• In Which Our Protagonist Discovers We Need More Good Public Policy People Who Understand Security

Seth Godin has a phenomenal blog post about the honor system and how it affects the secret squirrels and the chicken littles of the security world.  I knew there was a reason we liked Seth.

• Alternative Uses for System Security Plans
• My System Environment
• It’s All About Common Controls!
• Cult Crossovers Into Information Security
• Noisy People