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’

I’ve said it a million times before:  I don’t care if you switch to $FooFramework, as long as you have the same people executing it with the same skillset, the results will be the same.  Last week and for the near-term, it’s a new bill to replicate the tenets of FISMA and the NIST framework thereof.

Last week, Representative Langevin introduced HR 5983, the “Homeland Security Network Defense and Accountability Act of 2008”.  Some press on the bill:

• Security Focus
• Committee on Homeland Security

Now the big question for me on this bill (and really, any proposed law) is this:  How does this provide anything above and beyond what is already required by FISMA, OMB policies, and NIST guidelines?  My short analysis:  Not much, and Rep Langevin is just “stirring the pot” with the big spoon of politics.

HR 5983 requires the following:

• Re-establishes the role and staffing requirements for the CIO, including network monitoring
• Testing the DHS networks using “attack-based” protocols
• IG audits and reporting
• Adding responsibility for contractor systems

Again, nothing new here that isn’t required already.  The only benefit to this bill that I see is that if it’s law, the Executive Branch has to request the funding in their budget request and Congress has to (maybe) fund it. It isn’t that DHS doesn’t have the in-house expertise–they own US-CERT.  It’s not that they have a lack of smart people–they own the Security Line of Business.  It’s that there are only so many hours in the day to get things done, and DHS has had lots of work since their creation in 2002.

A little bit of peeking behind the security kimono at DHS is in order.  DHS consists of subagencies, known as Operational Elements, such as TSA, ICE, CBP, etc.  The heads of these agencies are peers to the DHS CIO and have their own CIO and CISO, even though that’s not what they’re called.  See, the OEs do not have to listen to the DHS CIO, and that’s a huge problem.  Last year, DHS made the DHS CIO the budget approver for the OE’s IT budgets, which is a step forward, but still there is much room for improvement.  That’s something that Congress can fix.

Now it just isn’t a “Government IT Security News Day” without a comment from Alan Paller of SANS fame…

“One story is missing from this issue because the press hasn’t picked it up yet. Under Chairman Langevin of Rhode Island, the US House of Representatives Subcommittee on Emerging Threats and Cybersecurity just approved a new bill that changes how security will be measured, at least at the Department of Homeland Security. This is the beginning of the end of the huge waste under FISMA and the start of an era of continuous monitoring and automation. Long overdue. Look for news stories over the coming days.
Alan”

Like I say sometimes, I’m a bear of little brain and a recovering infantryman, but why is the answer to a law to make another law saying the same exactly the same thing.  All I have to say is this:  You’re not on Slashdot, you actually have to read the bill before you comment on it.  I didn’t see anything that supports what Alan’s saying.    =)

Capitol at Sunset by vgm8383.

To me, the very interesting thing about this bill is this provision:

“Before entering into or renewing a covered contract, the Secretary, acting through the Chief Information Officer, must determine that the contractor has an internal information systems security policy that complies with the Department’s information security requirements, including with regard to authentication, access control, risk management, intrusion detection and prevention, incident response, risk assessment, and remote access, and any other policies that the Secretary considers necessary to ensure the security of the Department’s information infrastructure.”

I have an issue with the language of this provision.  It’s one of scope.

But perhaps an explanation is in order.  Most (OK, mabye half or a little bit more, this isn’t a scientific number) government IT systems are contractor-operated.  These contractors have “Government data” on their corporate networks.  Some of this is fairly benign:  contracting collateral, statements of work, staffing plan, bill rates, etc.  Some of this is really bad:  PII, Privacy Act data, mission data, etc.  Some of this is “gray area”: trouble tickets, event data, SIEM data, etc.

Now taking this back to cost-effective, adequate security, what the Langevin bill means is that you’re taking the FISMA framework and applying it to all contractors without any bounds on what you consider within your realm of protection–ie, according to the language of the bill, if I’m any contractor supporting DHS in an outsourcing engagement, you can audit my network, whether or not it has Government data on it.  This is a problem because your oversight cuts into my margins and in some cases does not provide the Government with the desired level of security.

My response as a contractor is the following:

• Increase my rates to compensate for the cost of demonstrating compliance
• Do not bid DHS contracts
• Adopt a policy that says that DHS policies apply to the systems containing government mission data and meta-data
• Charge the Government at Time and Materials for any new requirements that they levy on you for mitigation

Unfortunately, this is a game that the Government will win at with respect to controlling the contractor’s network and lose at with respect to cost.

Good contractors understand the liability of having separation between Government data and their own network.  Back in my CISO role, that was the #1 rule–do not putGovernment data on the corporate network or “cross the streams” (Thanks, Vlad).  In fact, I wrote a whole chunk of blog posts last year about outsourcing, go check them out.  In fact, we would give to the customer anything that could be built in a dedicated mode specifically for them.  The dedicated network sections used the customer’s policy, procedures, standards, and they got to test them whenever they wanted.  In back of that was a shared piece for things that needed large economy of scale, like the STK 8500 and the NOC dashboards to put all the performance data on one screen.

Having said that, some data does need to cross over to the contractor’s network (or, even better, a separate management network) in order to provide economy of scale.  In our case, it was trouble tickets–in order to split field technicians across different contracts to keep them billable, the only cost-effective way to do this is to have tickets go into a shared system.  Any other solution costs the Government a ton of money because they would be paying for full-time field techs to be on-site doing nothing.

The problem is that our guidance on contractor systems is grossly outdated and highly naive.  The big book of rules that we are using for contractor security is NISPOM.  Unfortunately, NISPOM only applies to classified data, and we’re left with a huge gap when it comes to unclassified data.

What we need is the unclassified version of NISPOM.

The NIST answer is in section 2.4 of SP 800-53:

The assurance or confidence that the risk to the organization’s operations, assets, and individuals is at an acceptable level depends on the trust that the authorizing official places in the external service provider. In some cases, the level of trust is based on the amount of direct control the authorizing official is able to exert on the external service provider with regard to the employment of appropriate security controls necessary for the protection of the service and the evidence brought forth as to the effectiveness of those controls. The level of control is usually established by the terms and conditions of the contract or service-level agreement with the external service provider and can range from extensive (e.g., negotiating a contract or agreement that specifies detailed security control requirements for the provider) to very limited (e.g., using a contract or service-level agreement to obtain commodity services such as commercial telecommunications services).

Hmmm, in a classic ploy of stealing lines from my Guerilla CISO Bag-o-Tricks ™, NIST has said “Well, it depends”.  And yes, it depends, but how do you impement that when OMB dictates that what NIST says is THE standard?

• When the Feds Come Calling
• How to Not Let FISMA Become a Paperwork Exercise
• More on Georgia’s FISMA Reporting
• Comments on SCAP 2008
• Random Thoughts on “The FISMA Challenge” in eHealthcare

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

In building slides for our ongoing NIST Framework for FISMA class, I put together a deck of the ongoing Government security initiatives.  It’s plenty of stuff to keep you busy.

“Government Security System” Photo by Kahala

These are some of the more interesting initiatives and a brief description of them:

President’s Management Agenda Scorecard:  This is a quarterly red-yellow-green (hmm, wonder why nobody but the military uses black-red-yellow-green) scorecard on the various aspects of the agenda.  Security is represented as some of the values behind the E-Government score.  More specifically, OMB calls out the following in their FISMA report to congress:

To “get to green” under the E-Government scorecard, agencies must meet the following 3 security criteria:

• IG or Agency Head verifies effectiveness of the Department-wide IT security remediation process. (rybolov: Plans of Actions and Milestones)
• IG or Agency Head rates the agency C&A process as “Satisfactory” or better.
• The agency has 90 percent of all IT systems properly secured (certified and accredited). (rybolov: C&A does not always equate to “secured”, but is an indicator)

In order to “maintain green,” by July 1, 2008, agencies must meet the following security and privacy criteria:

1. All systems certified and accredited. (rybolov: same C&A caveat as before)
2. Systems installed and maintained in accordance with security configurations. (rybolov: lots of wiggle room here since it’s the agency’s standard except for the Federal Desktop Core Configuration)
3. Has demonstrated for 90 Percent of applicable systems a PIA has been conducted and is publicly posted. (rybolov:  PIA is a Privacy Impact Assessment.  It gets posted in the Federal Register as a public notification of what the Government is collecting and what the use is)
4. Has demonstrated for 90 percent of systems with PII contained in a system of records covered by the Privacy Act to have developed, published, and maintained a current SORN. (rybolov: System of Record Notice, this is what is filed with the Federal Register)
5. Has an agreed-upon plan to meet communication requirements for COOP and COG. (rybolov: Continuity of Government)

You can view the current scorecard and learn more about it at results.gov.

OMB Management Watch List:  This is a list of “at-risk” projects.  Security is one part of the list of risks, but for the most part this is a list of high-risk projects within the context of a program/project manager.  The security criteria for being on the Watch List are based on on IG assessments of:

• Certification and Accreditation
• Plan of Actions and Milestones
• Privacy Impact Assessment

 You can check out the most recent Watch List at OMB’s website.

Combined Catalog of Controls:  Superseding DoDI 8500.2 (DoD catalog of controls) and DCID 6/3 (intelligence community catalog of controls) with a reinforced SP 800-53.  Process flow would be along SP 800-37.  I’ve talked about this before.

Security Line of Business:  Agencies become subject-matter experts in an area and become a contractor to the other agencies.  Not a new concept, we’ve seen it elsewhere.

Privacy Management:  OMB Memo 07-16 lays out a privacy plan containing the following tenets:

• Breach Notification:  Requires each agency to have a breach notification policy
• SSN Reduction:  Each agency reduces the use of Social Security Numbers where not needed
• PII Reduction:  Restrict the collection of PII where not needed
• Rules of Behavior:  Rules for employees to follow when they deal with PII

SCAP and FDCC:  I’ve covered these in much detail. 

Trusted Internet Connections: This is a plan to reduce the number of Government internet connections to 50.  Even the most ardent OMB supporters have to agree that this is both a fairly arbitrary number, not achiveable in the next several years, and not even really a good idea.  You heard it here first, folks, but conventional wisdom says that 500 is a better, more realistic number for the time being, and that is the “real” number that OMB is considering.  The start of this is OMB Memo 08-05.

Einstein:  Basically a Government-wide IDS and SIEM run by US-CERT.  It’s offered under the Security Line of Business.  The good thing about Einstein is that it allows DHS to correllate events government-wide.

Air Force Cyber Command:  It’s provisional now, doesn’t have a permanent headquarters, and is trying to figure out what its mission is, but it’s here.  Gossip around town is that it’s focused on both defensive and offensive missions, although they pictures are all defensive-based.  There’s some information on their website, but be sure to read between the lines.  =)

Cyber Corps:  Scholarship program for college students (both post-grad and undergrad) with a public service obligation following graduation.  You can find out more here.

SmartBuy:  A GSA-run program to bulk-purchase commercial off-the-shelf software at a high-volume discount.  Think of it as a buyer’s club for software.  SmartBuy has disk-encryption software.  You can get more information on the GSA website.

• Civilians Ask “What’s With All the Privacy Act Kerfluffle?”
• OMB Wants a Direct Report
• An Open Letter to NIST About SP 800-30
• GSA Looking for a Few Good Tools
• In Response to “Cyber Security Coming to a Boil” Comments….

Maybe I’ve been working on slide decks for too long.  That’s why I haven’t been blogging much over the past week:  when you spend 8 hours a day revising and formatting slides, your brain turns to jello.

Then suddenly on Tuesday, it hit me:  the Government’s problem with security is one of scale.  And at this point you all go “Duh, where have you been for the past 200 years?”  And yes, it’s not a problem exclusive to security, it goes hand-in-hand with personnel management, financial management, $foo management, and $bar management

Large-Scale Scaley Carp Photo by radcarper

Now the scale in itself isn’t really the problem, it’s that we don’t have information security models that scale to that level.  And what I mean by that is that each agency is pretty much their own enterprise.  The entire executive branch is one huge federation of independent enterprises (and some of the enterprises are federated, but we’ll ignore that for the time being).  Most of our existing thoughts on information security management are focused on the enterprise, and the only hope to use them is to manage each enterprise separately.

Really, folks, we don’t have information security models that scale up as massively as we need to, and what we’ve been doing is borrowing from other fields, most notably Federal law and public accounting.  Unfortunately for us, these are models based on compliance, not risk management.  Even then, I don’t see the compliance angle going away anytime soon.

Now this is the really big problem:  everybody has some kind of criticism about how the Government runs their information security.  But I don’t see anybody with a viable alternative, nor do I expect to see one because the only people with problems on this scale are large governments.

• Now ISC2 Blogs have an Opinion on FISMA
• Federated Vulnerability Management
• An Open Letter to the Next President of the United States
• NIST’S FISMA Pase II–Who Certifies Those who Certify the Certifiers?
• Massively Scaled Security Solutions for Massively Scaled IT

The US Army occassionally does things right.

Well, one of the things that they do right is training. Our training process for squad and above is mostly focused around the Observer-Controller (OC) and their value proposition (my MBA word for the day, TYVM). Whenever you are training, there is an OC tagging right along with you to assess what and why you are doing something and then make recommendations at the end.

 

Observer-Controllers hard at work, photo by David Axe

What an OC brings with them (aside from their 31337 BBQ Ski11z):

• Experience of having seen the same task done hundreds of times with various groups.
• A strong understanding of the doctrinally-correct way to do a task.
• Techniques to fill out where doctrine is not specific enough.
• Sometimes they have pre-written standard operating procedures that they will share with you.

What an OC will never do:

• Use you resources to support themselves.
• Own the solution space for you.
• Criticize you in front of your troops.
• Interfere with your ability to do your mission.

Hmmm, sounds like the things that a good auditor does.

Auditors are in a fantastic position to help the auditee because of the wide range of experience in how other companies have been doing the exact same thing that you are doing.  Point is, there is a level of collusion that needs to happen between the auditor and the auditee, and the extent of that collusion is really what we’re talking about when we start looking at Separation of Duties and similar things.

Over the years, auditors and auditees have had the nature of their relationship change numerous times. Around the time of Sarbanes-Oxley, the pendulum swung wildly the way of “no relationship no how” and now it’s slowly moving back to somewhere normal. Here’s a podcast with Michael Oxley talking about how auditors need to collude better with the auditee.  Disclaimer:  this is part of a series that is produced by my firm, but I had no part in this, Mkay?

Here in DC, we have a saying (Ok, I made it up my own self):  “Collusion is not just a technique, it’s THE technique.”  =)

• Split-Horizon Assessments and the Oversight Effect
• A Niche to a Niche is Still Hard to Staff
• FISMA Report Card News, Formulas, and 3 Myths
• Cloud Computing and the Government
• Some Comments on SP 800-39