For some reason, “Rebuilding C&A” has been a perennial traffic magnet for me for a year or so now.  Seeing how that particular post was written in 2007, I find this an interesting stat.  Maybe I hit all the SEO terms right.  Or maybe the zeitgeist of the Information Assurance community is how to do it right.  Anyway, if you’re in Government and information security, it might be worthwhile to check out this old nugget of wisdom from yesteryear.

• GAO’s 5 Steps to “Fix” FISMA
• Old Saint NIST: Ho Ho Hold on, what’s this?
• A Funny Thing Happened Last Week on Capital Hill
• “Machines Don’t Cause Risk, People Do!”
• The 10 CAG-egorically Wrong Ways to Introduce Standards

A few weeks back I read an article on an apparent shift in emphasis in government security… “OMB outlines shift on FISMA” take a moment to give it a read. I’ll wait….

That was followed by NASA’s “bold move” to change the way they manage risk…

Once again the over-emphasis and outright demagoguery on “compliance,” “FISMA reports,” “paper exercises,” and similar concepts that occupy our security geek thoughts have not given way to enlightenment. (At least “compliancy” wasn’t mentioned…) I was saddened by a return to the “FISMA BAD” school of thought so often espoused by the luminaries at SANS. Now NASA has leapt from the heights… At the risk of bashing Alan Paller yet again, I am often turned off by the approach of “being able to know the status of every machine at every minute, ” – as if machines by themselves cause bad security… It’s way too tactical (incorrect IMHO) and too easy to make that claim.

Hence the title of this rant – Machines don’t cause risk, people do!

The “people” I’m talking about are everyone from your agency director, down to the lowliest sysadmin… The problem? They may not be properly educated or lack the necessary skills for their position – another (excellent) point brought forth in the first article. Most importantly, even the most seasoned security veteran operating without a strategic vision within a comprehensive security program (trained people, budget, organizational will, technology and procedures) based upon the FISMA framework will be doomed to failure. Likewise, having all the “toys” in the world means nothing without a skilled labor force to operate them and analyze their output. (“He who dies with the most toys is still dead.”) Organizations and agency heads that do not develop and support a comprehensive security program that incorporates the NIST Risk Management Framework as well as the other facets listed above will FAIL. This is nothing new or revolutionary, except I don’t think we’ve really *done* FISMA yet. As I and others have said many times, it’s not about the paper, or the cost per page – it’s about the repeatable processes — and knowledgeable people — behind what the paper describes.

I also note the somewhat disingenuous mention of the risk management program at the State Department in the second article… As if that were all State was doing! What needs to be noted here is that State has approached security in the proper way, IMHO — from a Strategic, or Enterprise level. They have not thrown out the figurative baby with the bath water by dumping everything else in their security program in favor of the risk scoring system or some other bright, shiny object. I know first-hand from having worked with many elements in the diplomatic security hierarchy at State – these folks get it. They didn’t get to the current level of goodness in the program by decrying (dare I say whining about?) “paper.” They made the organizational commitment to providing contract vehicles for system owners to use to develop their security plans and document risk in Plans of Action and Milestones (POA&Ms). Then they provided the money to get it done. Is the State program a total “paragon of virtue?” Probably not, but the bottom line is that it’s an effective program.

Mammoth Strategy, Same as Last Year image by HikingArtist.com.

Desiring to know everything about everything may seem to some to be a worthy goal, but may be beyond many organization’s budgets. *Everything* is a point in time snapshot, no matter how many snapshots you take or how frequently you take them. Continuous, repeatable security processes followed by knowledgeable, responsible practitioners are what government needs. But you cannot develop these processes without starting from a larger, enterprise view. Successful organizations follow this–dare I say it–axiom whether discussing security governance, or system administration.

Government agencies need to concentrate on developing agency-wide security strategies that encompass, but do not concentrate on solely, what patch is on what machine, and what firewall has which policy. Likewise, system POA&Ms need to concentrate on higher-level strategic issues that affect agencies — things like changes to identity management schemes that will make working from home more practical and less risky for a larger percentage of the workforce. Or perhaps a dashboard system that provides the status of system authorization for the agency at-a-glance. “Burying your head in a foxhole” —becoming too tactical — is akin to burying it in the sand, or like getting lost in a bunch of trees that look like a forest. When organizations behave this way, everything becomes a threat, therefore they spray their resource firepower on the “threat of the day, or hour.”

An organization shouldn’t worry about patching servers if its perimeter security is non-existent. Developing the larger picture, while letting some bullets strike you, may allow you recognize threats, prioritize them, potentially allowing you to expend minimal resources to solve the largest problem. This approach is the one my organization is following today. It’s a crawl first, then walk, then run approach. It’s enabled management to identify, segregate, and protect critical information and resources while giving decision-makers solid information to make informed, risk-based decisions. We’ll get to the patches, but not until we’ve learned to crawl. Strangely, we don’t spend a lot of time or other organizational resources on “paper drills” — we’re actively performing security tasks, strategic and tactical that follow documented procedures, plans and workflows! Oh yes, there is the issue of scale. Sorry, I think over 250 sites in every country around the world, with over 62 different government customers tops most enterprises, government or otherwise, but then this isn’t about me or my organization’s accomplishments.

In my view, professional security education means providing at least two formal paths for security professionals – the one that SANS instantiates is excellent for administrators – i.e., folks operating on the tactical level. I believe we have these types of security practitioners in numbers. We currently lack sufficient seasoned professionals – inside government – who can approach security strategically, engaging agency management with plans that act both “globally” and “locally.” Folks like these exist in government but they are few. Many live in industry or the contractor space. Not even our intelligence community has a career path for security professionals! Government as a whole lacks a means to build competence in the security discipline. Somehow government agencies need to identify security up-and-comers within government and nurture them. What I’m calling for here is a government-sponsored internal mentorship program – having recognized winners in the security game mentor peers and subordinates.

Until we security practitioners can separate the hype from the facts, and can articulate these facts in terms management can understand and support, we will never get beyond the charlatans, headline grabbers and other “self-licking ice cream cones.” Some might even look upon this new, “bold initiative” by NASA as quitting at a game that’s seen by them as “too hard.” I doubt seriously that they tried to approach the problem using a non-academic, non-research approach. It needed to be said. Perhaps if the organization taking the “bold steps” were one that had succeeded at implementing the NIST guidance, there might be more followers, in greater numbers.

Perhaps it’s too hard because folks are merely staring at their organization’s navel and not looking at the larger picture?

Lastly, security needs to be approached strategically as well as tactically. As Sun Tzu said, “Tactics without strategy is the noise before defeat.”

• A Funny Thing Happened Last Week on Capital Hill
• How to Not Let FISMA Become a Paperwork Exercise
• When the Feds Come Calling
• In Which Our Protagonist Discovers We Need More Good Public Policy People Who Understand Security
• Ooh, “The Word” is out on S 3474

Well, several funny things happened, they happen every week.  But specifically I’m talking about the hearing in the House Committee on Homeland Security on FISMA reform–Federal Information Security: Current Challenges and Future Policy Considerations.  If you’re in information security and Government, you need to go read through the prepared statements and even watch the hearing.

Also referenced is HR.4900 which was introduced by Representative Watson as a modification to FISMA.  I also recommend that you have a look at it.

Now for my comments and rebuttals to the testimony:

• On the cost per sheet of FISMA compliance paper: If you buy into the State Department’s cost of $1700 per sheet, you’re absolutely daft.  The cost of a security program divided by the total number of sheets of paper is probably right.  In fact, if you do the security bits right, your cost per sheet will go up considerably because you’re doing much more security work while the volume of paperwork is reduced.
• Allocating budget for red teams: Do we really need penetration testing to prove that we have problems?  In Mike Smith’s world, we’re just not there yet, and proving that we’re not there is just an excuse to throw the InfoSec practitioners under the bus when they’re not the people who created the situation in the first place.
• Gus Guissanie: This guy is awesome and knows his stuff.  No, really, the guy is sharp.
• State Department Scanning: Hey, it almost seems like NIST has this in 800-53.  Oh wait, they do, only it’s given the same precedence as everything else.  More on this later.
• Technical Continuous Monitoring Tools: Does anybody else think that using products of FISMA (SCAP, CVE, CVSS) as evidence that FISMA is failing is a bit like dividing by zero?  We really have to be careful of this or we’ll destroy the universe.
• Number of Detected Attacks and Incidents as a Metric: Um, this always gets a “WTF?” from me.  Is the number increasing because we’re monitoring better or is it because we’re counting a whole bunch of small events as an attack (ie, IDS flagged on something), or is it because the amount of attacks are really increasing?  I asked this almost 2 years ago and nobody has answered it yet.
• The Limitations of GAO: GAO are just auditors.  Really, they depend on the agencies to not misrepresent facts and to give them an understanding of how their environment works.  Auditing and independent assessment is not the answer here because it’s not a fraud problem, it’s a resources and workforce development problem.
• OMB Metrics: I hardly ever talk bad about OMB, but their metrics suck.  Can you guys give me a call and I’ll give you some pointers?  Or rather, check out what I’ve already said about federated patch and vulnerability management then give me a call.

So now for Rybolov’s plan to fix FISMA:

1. You have to start with workforce management. This has been addressed numerous times and has a couple of different manifestations: DoDI 8570.10, contract clauses for levels of experience, role-based training, etc.  Until you have an adequate supply of clueful people to match the demand, you will continue to get subpar performance.
2. More testing will not help, it’s about execution. In the current culture, we believe that the more testing we do, the more likely the people being tested will be able to execute.  This is highly wrong and I’ve commented on it before.  I think that if it was really a fact of people being lazy or fraudulent then we would have fixed it by now.  My theory is that the problem is that we have too many wonks who know the law but not the tech and not enough techs that know the law.  In order to do the job, you need both.  This is also where I deviate from the SANS/20 Critical Security Controls approach and the IGs that love it.
3. Fix Plans of Actions and Milestones. These are supposed to be long-term/strategic problems, not the short-term/tactical application of patches–the tactical stuff should be automated.  The reasoning is that you use these plans for budget requests for the following years.
4. Fix the budget train. Right now the people with the budget (programs) are not the people running the IT and the security of it (CIO/CISO).  I don’t know if the answer here is a larger dedicated budget for CISO’s staff or a larger “CISO Tax” on all program budgets.  I could really policy-geek out on you here, just take my word for it that the people with the money are not the people protecting information and until you account for that, you will always have a problem.

Sights Around Capital Hill: Twice Sold Tales photo by brewbooks. Somehow seems fitting, I’ll let you figure out if there’s a connection. =)

• “Machines Don’t Cause Risk, People Do!”
• GAO’s 5 Steps to “Fix” FISMA
• How to Not Let FISMA Become a Paperwork Exercise
• In Other News, I’m Saying “Nyet” on S.3474
• The 10 CAG-egorically Wrong Ways to Introduce Standards

Every once in a while an opportunity presents itself to affect some real change in federal information security practice.  Now is such a time.  A slew of new NIST documents are being released between now and April.  These are the core NIST documents that describe how to satisfy FISMA.  They include NIST SPs 800-30 Revision 1, 800-39, 800-37 Revision 1 and 800-53A Revision 1. That’s where you come in.

The documents define what federal government practice will look like in the coming years.  If they are flawed then the practice will be flawed.  To prevent stupidity from leaking in when nobody is looking NIST releases the documents as drafts so everyone gets a chance to eyeball them.  First you eyeball, then you comment.  They look at the comments and they fix the flaws.  Fix the flaws now and you don’t live with them later.

The most important document in draft right now is the NIST Special Publication 800-37 Revision 1.  This document describes the central processes involved in the authorization of information systems that support the federal government.  Notice I didn’t say Certification and Accreditation?  That’s because C&A is deader than a sheep at a wolf convention. Want to know what replaces it?  Pick up a copy of NIST SP 800-37r1 FPD, give it a read and send in your comments.

Better yet, consider joining a formal document review process.  I’m leading a team of hale and hearty volunteers at OWASP in a NIST SP 800-37r1 FPD review and we’d love to have you come join the fun.   We’re on a tight schedule so now is the time to act.

Time is short, the comment period for NIST SP 800-37 Revision 1 FPD ends on December 31st, 2009.

• The Guerilla CISO Rants: Don’t Write a System Security Plan
• Observations on SP 800-37R1
• “Machines Don’t Cause Risk, People Do!”
• NIST Cloud Conference Recap
• William Jackson on FISMA: It Works, Maybe

Here in the information assurance salt mines, we sure do loves us some conspiracies, so here’s the conspiracy of the month: S.773 gives the Government the ability to view your private data and the President disconnect authority over the Internet, which means he can sensor it.

Let’s look at the sections and paragraphs that would seem to say this:

Section 14:

(b) FUNCTIONS- The Secretary of Commerce–

(1) shall have access to all relevant data concerning such networks without regard to any provision of law, regulation, rule, or policy restricting such access;

Section 18: The President–

(2) may declare a cybersecurity emergency and order the limitation or shutdown of Internet traffic to and from any compromised Federal Government or United States critical infrastructure information system or network;

(6) may order the disconnection of any Federal Government or United States critical infrastructure information systems or networks in the interest of national security;

Taken completely by itself, it would seem like this gives the president the authorities to do all sorts of wrong stuff, all he has to do is to declare something as critical infrastructure and declare it compromised or in the interests of national security.  And some people have:

• S773… Government Control of Internet, Censoring Talk Radio!
• Censorship – A Political Rant
• Politics 4 All Comments

And some movies (we all love movies):

It makes me wonder since when have people considered social networking sites or the Internet as a whole as “critical infrastructure”. Then the BSOFH in me things “Ye gods, when did our society sink so low?”

Now, as far as going back to Section 14 of S.773, it exists because most of the critical infrastructure is privately-held.  There is a bit of history to understand here and that is that the critical infrastructure owners and operators are very reluctant to give the information on their piece of critical infrastructure to the Government.  Don’t blame them, I had the same problem as a contractor: if you give the Government information, the next step is them telling you how to change it and how to run your business.  Since the owners/operators are somewhat non-helpful, the Government needs more teeth to get what it needs.

But as far as private data traversing the critical infrastructure?  I think it’s a stretch to say that’s part of the requirements of Section 14, it’s to collect data “about” (the language of the bill) the critical infrastructure, not “processed, stored, or forwarded” on the critical infrastructure. But yeah, let’s scope this a little bit better, CapHill Staffers.

On to Section 18.  Critical infrastructure is defined elsewhere in law.  Let’s see the definitions section from HSPD-7, Critical Infrastructure Identification, Prioritization, and Protection:

In this directive:

The term “critical infrastructure” has the meaning given to that term in section 1016(e) of the USA PATRIOT Act of 2001 (42 U.S.C. 5195c(e)).

The term “key resources” has the meaning given that term in section 2(9) of the Homeland Security Act of 2002 (6 U.S.C. 101(9)).

The term “the Department” means the Department of Homeland Security.

The term “Federal departments and agencies” means those executive departments enumerated in 5 U.S.C. 101, and the Department of Homeland Security; independent establishments as defined by 5 U.S.C. 104(1);Government corporations as defined by 5 U.S.C. 103(1); and the United States Postal Service.

The terms “State,” and “local government,” when used in a geographical sense, have the same meanings given to those terms in section 2 of the Homeland Security Act of 2002 (6 U.S.C. 101).

The term “the Secretary” means the Secretary of Homeland Security.

The term “Sector-Specific Agency” means a Federal department or agency responsible for infrastructure protection activities in a designated critical infrastructure sector or key resources category. Sector-Specific Agencies will conduct their activities under this directive in accordance with guidance provided by the Secretary.

The terms “protect” and “secure” mean reducing the vulnerability of critical infrastructure or key resources in order to deter, mitigate, or neutralize terrorist attacks.

And referencing the Patriot Act gives us the following definition for critical infrastructure:

In this section, the term “critical infrastructure” means systems and assets, whether physical or virtual, so vital to the United States that the incapacity or destruction of such systems and assets would have a debilitating impact on security, national economic security, national public health or safety, or any combination of those matters.

Since it’s not readily evident from what we really consider to be critical infrastructure, let’s look at the implemention of HSPD-7.  They’ve defined critical infrastructure sectors and key resources, each of which have a sector-specific plan on how to protect them.

• Agriculture and Food
• Banking and Finance
• Chemical
• Commercial Facilities
• Communications
• Critical Manufacturing
• Dams
• Defense Industrial Base
• Emergency Services
• Energy
• Government Facilities
• Healthcare and Public Health
• Information Technology
• National Monuments and Icons
• Nuclear Reactors, Materials and Waste
• Postal and Shipping
• Transportation System
• Water

And oh yeah, S.773 doesn’t mention key resources, only critical infrastructure.  Some of this key infrastructure isn’t even networked (*cough* icons and national monuments *cough*). Also note that “Teh Interblagosphere” isn’t listed, although you could make a case that information technology and communications sectors might include it.

Yes, this is not immediately obvious, you have to stitch about half a dozen laws together, but if we didn’t do pointers to other laws, we would have the legislative version of spaghetti code.

Going back to Section 18 of S.773, what paragraph 2 does is give the President the authority to disconnect critical infrastructure or government-owned IT systems from the Internet if they have been compromised.  That’s fairly scoped, I think.  I know I’ll get some non-technical readers on this blog post, but basically one of the first steps in incident response is to disconnect the system, fix it, then restore service.

Paragraph 6 is the part that scares me, mostly because it has the same disconnect authority as paragraph 2and the same scope (critical infrastructure and but the only justification is “in the interests of national security”. In other words, we don’t have to tell you why we disconnected your systems from the Internet because you don’t have the clearances to understand.

So how do we fix this bill?

Section 14 needs an enumeration of the types of data that we can request from critical infrastructure owners and operators. Something like the following:

• Architecture and toplogy
• Vulnerability scan results
• Asset inventories
• Audit results

The bill has a definitions section–Section 23.  We need to adopt the verbiage from HSPD-7 and include it in Section 23.  That takes care of some of the scoping issues.

We need a definition for “compromise” and we need a definition for “national security”. Odds are these will be references to other laws.

Add a recourse for critical infrastructure owners who have been disconnected: At the very minimum, give them the conditions under which they can be reconnected and some method of appeal.

• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 4
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 3
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 1
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 5
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 2

Rybolov Note: this is part 4 in a series about S.773.  Go read the bill here.  Go read part one here.  Go read part two here.  Go read part three here. Go read part four here.

Themes: I’ve read this thing back and forth, and one theme emerges overall: We’ve talked for the better part of a decade about what it’s going to take to “solve” this problem that is IT security, from an internal Federal Government standpoint, from a military-industrial complex standpoint, from a state and local government standpoint, from a private-sector standpoint, and from an end-user standpoint.  This bill takes some of the best though on the issue, wraps it all up, and presents it as a “if you want to get the job done, this is the way to do it”.

Missing: The role of DHS.  Commerce is highly represented, over-represented to my mindset.  Looking at the pieces of who owns what:

Commerce security organizations:

NTIA–Technically not a security organization, but they manage the DNS root and set telecom policy.

NIST–They write the standards for security.

FTC–They regulate trade and have oversight over business fraud.

DHS Security organizations:

NPPD–They are responsible for critical infrastructure and national risk management.

NCSD–They do the security operations side of our national cybersecurity strategy and run US-CERT. (BTW, hi guys!)

Secret Service–They have the primary responsibility of protecting the US Currency which also includes computer crimes against financial infrastructure.

Science and Technology Directorate–They are responsible for research and development, including IT security.

DOJ Security Organizations:

FBI–Surprise, they do investigations.

So you see, some of the things that are tasked to Commerce are done by DHS and DOJ.  This is probably the nature of the bill, it was introduced in the Commerce committee so it’s understandable that it would be Commerce-centric.

Cost: One thing kept nagging me in the back of my head while going through this bill is the cost to do everything  We’re asking to do a lot in this bill, now what’s the total cost?  Typically what happens when a bill makes it out of committee is that the Congressional Budget Office attached a price to the legislation as far as the total cost and then what’s the breakdown for the average American household.  That data isn’t published yet on the bill’s page, so we’ll see in the next iteration.

In-Your-Face Politics: Really, this bill is showing us how to do the full security piece.  It includes everything.  It’s challenging people to come up with alternatives.  It’s challenging people to delete the sections that don’t make sense.  It’s challenging people to fix the scope issues.  Like it or hate it, it definitely stirs up debate.

Final Thoughts: S.773 is a pretty decent bill.  It has some warts that need to be fixed, but overall it’s a pretty positive step.

Capitol photo by bigmikesndtech.

• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 3
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 4
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 2
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 1
• The World Asks: is S.773 Censorship?