We’re laying people off, have been for several months. It makes life interesting–IT operations has high churn anyway (over half of the NOC staff was hired in the past 9 months), much less worrying about managing attrition for all the people you are chopping off the bottom of the heap. At any rate, we’re all constantly evaluating our chances of getting the axe on the next go-around. It’s all based in morbidly fascinating metrics and superstition, like how I imagine troops were in the days before the Normandy invasion.

I was told the following today by the manager for our server team:

Rich: “We’re never going to lay you off because nobody wants your job.”

Me: “Well, what if we decide that my job doesn’t need to be here?”

Rich: “You save us more than we pay you for your salary several times over. If we get rid of you, we’ll be spending 3 times your paycheck paying for all the things we got caught on during the next audit.”

Me: “Uh, thanks.”

I’m still not sure that having a job that nobody wants to do is a good thing. =)

• Back in Leadership Training
• CISO Trick: Know the Hiding Places
• Ah, I Remember the Fun of Being an Assessor
• Rybolov is Dead, Long Live Rybolov
• Personnel Turnover

Ah, Uncyclopedia, that fountain of misinformation.  Think of what the Russians could have accomplished in the Great Patriotic War if they would have had the dezinformatsiya and maskirovka potential of Uncyclopedia at their beck and call.

Well, anyway, check out these articles:

• Zombies, including zombie man pages (it’s a Unix thing)
• Howto:Survive a Zombie Outbreak
• The Zombie War (complete with a list of ways to kill zombies)

• Training for the Zombie Pandemic
• The Next Pandemic
• Zombies on YouTube
• Wednesday Zombie Post–The Combat Guide
• Wednesday Zombie Post–The Federal Vampire and Zombie Agency

MP-52 Self-Destructing RFID Implants
Control:
The organization equips all employee-integrated storage media with self-igniting RFID devices so that they can be tracked throughout any government facility and destroyed upon command.

Supplemental Guidance:
All CISOs know that the information inside their employees’ heads is the real culprit.  When they get a new job, they take that information–all learned on the taxpayers’ dime–with them.  This is a much bigger security risk than the data on a USB drive could ever be.  Instead of denying the obvious truth, why don’t we implement security controls to minimize the impact of out-of-control employees?

Control Enhancements:
(1) The organization destroys the information inside an employee’s head when the employee leaves the organization, much like hard drives need to be degaussed before they are sent for maintenance.
Low: MP-52 Moderate: MP-52(1) High: MP-52(1)

• More Security Controls You Won’t See in SP 800-53
• Security Controls You Won’t See in SP 800-53
• More Vendor Spam
• Mike’s Guide to Information Security Policy
• In Search of a Better Catalog of Controls

Interesting article at Federal Computer Week that hints at a unified catalog of controls (read: SP 800-53, DoDI 8500.2, and DCID 6/3 combined into a huge one) that applies to all federal IT systems.  It’s coming, the big question is “how many years until it’s done?”

I know you guys know me well enough by now to reason that I’m going to tell you why we care.  And you’re right.

Well, one of the reasons where FISMA is failing (at least according to some people, my opinion differs) is that we have a shortage of people who have the necessary training and skills.  What a unified catalog of controls means is that we now have something that is standardized across the board so that I can take an IA practitioner from the DoD side, put them into a civilian agency, and have a reasonable expectation that they will succeed there.  In other words, I’ve decreased the switch costs for personnel transfers.  I’ve also made it easier for agencies to share data with each other (conspiracy buffs here can think things about Census data feeding the Total Information Awareness program and corroborated against your classified file) and to support each other as vendors under Lines of Business, which the government needs desperately.

The one downside is that I can see is that if you have a catalog of controls that runs the entire range from low-criticality to TS-plus, the tendency will be for every ISSO out there to build more controls than they actually need.  But we have that today, only not as severe.

• More on Georgia’s FISMA Reporting
• Civilians Ask “What’s With All the Privacy Act Kerfluffle?”
• Reinventing FedRAMP
• Build a Security Program
• The End is Near–FISMA to cost $29B!

You get used to seeing crazy and paranoid people tucked into the corners of DC. It’s what we have here.

Well, a couple of months ago, I was at a coffee shop (OK, it was Starbucks, my wife is a ho for their saccarine-sweet marketing, you can take away my burly-man exterior and give me a “yuppie” brand now) in Dupont Circle.

So anyway, there was this guy in there in a wheelchair and his own table who was selling pictures.  Yes, he was 95% con artist, but that’s OK.  The important part was his stories which were utterly whacked.

According to this guy, he was a colonel in the Air Force and has broken up his knee during a HALO jump.  He was an Arabic and Russian translator and was ethnically Ukranian.  Well, we can play that game, right?  Note to others:  never claim to speak a language in DC, NY, or Monterey unless you can actually speak the thing.  I probed him in Russian, all he knew was a couple standard phrases–more along the lines of tourist lingo than anything.

But now the best part is this: He claimed that Colin Powell was in actuality named “Colon” as in the Spanish version of “Christopher Columbus”.  This is a result of Powell’s Basque background which was covered up in order to appeal to the African-American vote for the Republicans.

Yes, you read right.  Basque.  Who knew? =)

• Self-Quote Time #2
• Is Myspace Satan?
• My 2 Obsessions this Week
• My System Environment
• Milestones

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