A couple of weeks ago, Martin McKeay was in town and recorded an interview with me.  I wax poetically on my typical things–FISMA, risk assessment, anti-compliance.

The funny thing is, weeks later, I listened to myself and I actually sound like I know something…. Who woulda thunk it?  =)

• Security Assessments as Fraud, Waste, and Abuse
• No, FISMA Doesn’t Require That, Silly Product Pushers
• I’m on the OWASP Podcast
• How to Not Let FISMA Become a Paperwork Exercise
• On Why I Blog… FUD is the Reason for the Writin’

Dear <enter candidate’s name>,

Congratulations on your inauguration as the President of the United States. This is a huge accomplishment in your career.

I am writing this letter to tell you that you are inheriting a phenomenal opportunity to succeed where it comes to IT security in the Government. Your predecessors have buit a very viable framework for IT security in the US Federal Government. Arrayed around you are some of the brightest and the best people who have done extraordinary work in increasing the cyber security of the United States Government. The following people are included in their ranks:

• Ron Ross and Marianne Swanson and the rest of the staff in the NIST FISMA project who have labored long and hard to provide research, standards, and guidance not just to the Federal Government but to the nation and the rest of the world.
• Karen Evans and the rest of the staff at OMB who have set the policy that the executive branch has followed. They are not afraid to make decisions in the face of adversity.
• US-CERT and the Department of Homeland Security have made huge strides towards building a Government-wide monitoring system. Considering that they started “from scratch” 5 years ago, this is a non-trivial accomplishment.
• The people at DISA and NSA who have developed technical guidance before it was popular to do so–before FISMA, before PPD-63.

These and countless other people have “fought the good fight” in bringing IT security to the masses in such a scale that is unprecedented before in history.

But from where I, a humble servant of the public, stand, there are 2 things that you and your administration can do as a whole to increase our Government’s IT security.

#1 Please appoint an executive-branch Chief Information Officer (CIO) and a Chief Information Security Officer (CISO) with both the responsibility and the authority to secure the executive branch’s IT systems. The reason I ask for this is that the Federal Government’s IT infrastructure is a federation of individual business units that are managed separately for risk. At each level of Government, there is an IT manager and a security person to support them–all the way up the chain of command–except for at the top where there is a void wanting to be filled.

As has often been said, the answer to bureaucracy is not to throw more bureaucracy at it, and so creating new positions is not something to do lightly. What our nation needs is a pair of true technology managers at the executive branch level who can adequately manage risk instead of compliance.  This is a tremendous need for the executive branch: OMB is focused on compliance and fiscal responsibility and compliance, NIST is focused on research and developer outreach, US-CERT is focused on highly tactical IT security operations, and no one entity controls the strategic security direction of the nation.

#2 Please learn how to use the economic might of the Federal Government to allow the market to determine winners in the security space. What I mean by this is that the Government has for too long put up with inferior IT products and services because we do not present a unified front to the vendors.

Our Federal IT budget for this year is ~$75B and this is a huge force to bear on the market. This means that the Government is in a prime position to get whatever they ask for from the technology industry, all you have to do is use your fiscal power in a coordinated manner.

Once again, congratulations on the new job.

Cheers

–Rybolov

White House with a Tilt Shift by Michael Baird

• It’s a Problem of Scale!
• No, FISMA Doesn’t Require That, Silly Product Pushers
• William Jackson on FISMA: It Works, Maybe
• GAO’s 5 Steps to “Fix” FISMA
• Some Comments on SP 800-39

Second draft of NIST SP 800-39, Managing Risk from Information Systems, an Organization Perspective, is out, go have a read and see what you think. NIST really does welcome and use comments.

When 800-39 first came out, I gave it a quick scan and said to myself “meh, this is a rehash of all the things said elsewhere, especially 800-37. The general consensus between my friends was the same, but that after you get over that initial impression, you realize that the 800-39 Risk Management Framework is the stuff that fills in the gaps between everything and that this is how successful CISOs have been running their shops. One thing to think about is that NIST writes doctrine not technique, so you still have to read between the lines.

Anyway, it’s worth your time to give it a read, then drop your comments to NIST. They love it when you doo….

• Mike’s Guide to Information Security Policy
• Opportunity Costs and the 20 Critical Security Controls
• Some Comments on SP 800-39
• An Open Letter to NIST About SP 800-30
• New SP 800-60 is Out, Categorize Yerselves Mo Better

Very nice article in Military Information Technology Magazine (Online edition in case you couldn’t figure it out) about the DITSCAP to DIACAP transition.

Just looking at the concepts behind DIACAP, they’re very sound.  In some places, the article whines a bit too much.  Me, I’m glad to see DITSCAP go the way of the flesh in favor of risk registers and sharing of risk information with “business partners”.

My favorite quote this week:

“The services face a number of other challenges in implementing DIACAP, not least of which is what Lundgren called ‘significant cultural issue’ in moving from the ‘paperwork drill’ characteristic of DITSCAP, to DIACAP, ‘where you’re expected to actually go out and do the testing.'”

How can that NOT be a good thing?

Some other good quotes in the article and my random thoughts:

“Training and education of personnel is another concern faced by DoD components, according to King. ‘They must make sure they have a cadre of information assurance professionals who are in full understanding of what DIACAP is and how it differs from DITSCAP,’ he said. ‘This includes the complete realm of IA professionals, including principle certification and accreditation personnel to program managers and IA managers. There is a significant training and education tail that need to be accomplished for DIACAP to be properly implemented.'”

Well, to be very honest, I think that this was a problem with DITSCAP, is a problem with NIST 800-37, and will continue to be a problem until I work myself out of a job because everybody in the government understands risk management.

“This is going to save money and time because it allows capabilities to be put out to the field without having to be certified and accredited three or four times.”

That’s a happy thing.  Wait until DoD figures out how to do common controls, then they’ll find out how to save scads of money.

Now want to know the secret to why DIACAP will succeed?  This is a bit of brilliance that needs to be pointed out.  DIACAP became the standard in late 2007 after the DoD watched the civilian agencies go through 5 years of FISMA implementation and were able to steal the best parts and ignore the bad parts.

Future state:  civilian agencies borrowing some of the DIACAP details, like scorecards and eMASS.

Future state:  merging of DIACAP, DCID 6/3, and SP 800-37.

Future state:  adoption of the “one standard to rule them all” by anybody who trades data with the Government.

• More on Georgia’s FISMA Reporting
• Ack! With the Mandates!
• Core Belief #2 — Risk Management Uber Alles
• Where For Art Thou, 60-Day Review
• Imagine that, System Integrators Doing Security Jointly with DoD

Very nice article at Federal Times about Office of Management and Budget mandates actually interferring with agencies’ ability to provide effective security.  Of course, I think it’s well-written because it says some of the same ideas that I’ve been saying for awhile now.   =) 

So the question is, does OMB “get it” when it comes to information security?  Well, yes and no, and as a rebuttal, should they?

Let’s look at what OMB does.  In fact, go check out their web site, it has a plethora of knowledge.  It has the following mission statement:

“OMB’s predominant mission is to assist the President in overseeing the preparation of the federal budget and to supervise its administration in Executive Branch agencies. In helping to formulate the President’s spending plans, OMB evaluates the effectiveness of agency programs, policies, and procedures, assesses competing funding demands among agencies, and sets funding priorities. OMB ensures that agency reports, rules, testimony, and proposed legislation are consistent with the President’s Budget and with Administration policies.

“In addition, OMB oversees and coordinates the Administration’s procurement, financial management, information, and regulatory policies. In each of these areas, OMB’s role is to help improve administrative management, to develop better performance measures and coordinating mechanisms, and to reduce any unnecessary burdens on the public.

OK, so they are responsible for management, budget, performance, policy, and acquisition.  Hmm, sounds like the business side of the Government.  Yes, they should be in charge of security, but from the perspective of a good CFO:  that is, they know that it’s important because it’s loss reduction, but they don’t necessarily have the expertise on-hand to go into much more depth than that.

Now OMB is in a squeeze, you need to understand their pressures.  On one hand, their job is to assure compliance with all the laws, directives, policies, etc.  On the other hand, their job is to reduce the cost of the Federal budget.  In my world, these ideas are opposed to each other.

Add some political pressure and some serious security incidents into the mix, and you can easily see why OMB has been managing security by mandates and performance metrics (FISMA reporting).  The mandates are policy statements and the metrics are intended to determine how efficiently agencies are executing their compliance.  Thing is, this makes sense in a compliance-budget squeeze.

Now notice I didn’t bring up risk management anywhere in this post until now?  Well, this is where risk management comes in.  At the current burn-rate for IT security spending in the Government, the way to realize efficiencies and cost savings while still meeting the compliance drivers is to use risk management.  I’ll say this again: without risk management, everything becomes equally important and you have neither effective security nor cost-conscious security.

My big question for you is this:  who is performing true risk management for the Government as a whole?

• It’s not OMB, they just operate as the Government’s CFO
• It’s definitely not GAO, they’re just a dual-person control to keep the executive branch honest
• It’s not NIST, they just write standards and guidelines

The answer is this:  agency CISOs.  The problem with them being the highest level of risk management is the following:

• No sharing of risk with high-level stakeholders (OMB, White House)
• No sharing of risk with risk partners (Congress)
• No risk management at the national-level (strategic view)
• CISOs are given all the responsibility but none of the authority to fix things that really matter
• We all point fingers at each other when something breaks

So, how do we fix this?  That’s a hard one.  We can train OMB to do risk management.  We can extend Lines of Business so that one agency (*cough* DHS *cough*) adopts national-level risk management.  We can create a new organization that’s responsible for government-wide risk management, but then again that doesn’t make sense.

• Lines of Business, Relationships, and Trustability
• Towards Actionable Metrics
• It’s a Problem of Scale!
• An Open Letter to the Next President of the United States
• More on Georgia’s FISMA Reporting

Accreditation is the forgotten and abused poor relation to certification.

Part of the magic that makes C&A happen is this:  you have certification which is a verification that all the minimum security controls are in place, and then you have accreditation which is a formal acceptance of risk by a senior manager/executive.  You know what?  The more I think about this idea, the more I come to see the beautiful simplicity in it as a design for IT security governance.  You really are looking at two totally complete concepts:  compliance and risk management.

So far, we’ve been phenomenal at doing the certification part.  That’s easy, it’s driven by a catalog of controls and checklists.  Hey, it’s compliance after all–so easy an accountantcaveman could do it. =)

The problem we’re having is in accreditation.   Bear with me here while I illustrate the process of how accreditation works in the real world.

After certification, a list of deficiencies is turned into a Plan of Action and Milestones–basically an IOU list of how much it will cost to fix the deficiency and when you can have it done by.

Then the completed C&A package is submitted to the Authorizing Official.  It consists of the following things:

• Security Plan
• Security Testing Results
• Plan of Actions and Milestones

The accreditor looks at the C&A package and gives the system one of the following:

• Denial to Operate
• Approval to Operate
• Interim Approval to Operate (ie, limited approval)

And that’s how life goes.

There’s a critical flaw here, one that you need to understand:  what we’re giving the Authorizing Official is, more often than not, the risks associated with compliance validation testing.  In other words, audit risks that might or might not directly translate into compromised systems or serious incidents.

More often than not, the accreditation decision is based on these criteria:

• Do I trust the system owner and ISSO?
• Has my assessment staff done an adequate job at finding all the risks I’m exposed to?
• What is the extent of my political exposure?
• How much do I need this system to be up and operational right now?
• Is there something I need fixed right now but the other parts I’m OK with?

For the most part, this is risk management, but from a different angle.  We’ve unintentionally derailed what we’re trying to do with accreditation.  It’s not about total risk, it’s about audit risk.  Instead of IT security risk management, it becomes career risk management.

And the key to fix this is to get good, valid, thorough risk assessments in parallel with compliance assessments.   That requires smart people.

Smart CISOs out there in Government understand this “flaw” in the process.  The successful ones come from technical security testing backgrounds and know how to get good, valid, comprehensive risk assessments out of their staff and contractors, and that, dear readers is the primary difference between agencies that succeed and those who do not.

NIST is coming partly to the rescue here.  They’re working on an Accreditor’s Handbook that is designed to teach Authorizing Officials how to evaluate what it is they’re being given.  That’s a start.

However, as an industry, we need more people who can do security and risk assessments.  This is very crucial to us as a whole because your assessment is only as good as the people you hire to do it.  If we don’t have a long-term plan to grow people into this role, we will continually fail, and it takes at least 3-5 years to grow somebody into the role with the skills to do a good assessment, coming from a system administrator background.  In other words, you need to have the recruiting machinery of a college basketball program in order to bring in the talent that you need to meet the demand.

And this is why I have a significant case of heartburn when it comes to Alan Paller.  What SANS teaches perfectly compliments the policy, standards, regulations, and complicance side of the field.  And the SANS approach–highly-tactical and very technologically-focused–is very much needed.  Let me say that again:  we need a SANS to train the huge volume of people in order to have valid, thorough risk assessments.

There is a huge opportunity to say “you guys take care of the policy and procedures side (*cough* the CISSP side), we can give you the technical knowledge (the G.*C side) to augment your staff’s capabilities.  But for some reason, Alan sees FISMA, NIST, and C&A as a competitor and tries to undermine them whenever he can.

Instead of working with, he works against.  All the smart people in DC know this.

• The Accreditation Decision and the Authorizing Official
• Security Assessments as Fraud, Waste, and Abuse
• Some Random Thoughts on C&A SOPs
• Rebuilding C&A
• Build a Security Program