Rybolov Note: this is part 3 in a series about S.773.  Go read the bill here.  Go read part one here.  Go read part two here. Go read part four here.  Go read part 5 here. =)

SEC. 13. CYBERSECURITY COMPETITION AND CHALLENGE. This section of the bill creates a series of competitions for a range of ages and skills… with cash prizes!  Mostly it’s just the administration of competitions–cash prizes, no illegal activities, etc.

This goes back to the age-old discussions of glorification of illegal activities, giving tools to people who are too young to know how to stay out of jail.

But then again, I know why this section of the bill is in there.  If we want to grow enough security professionals to even remotely keep up with demand, we need to do a much better job at recruiting younger techies to the “security dark side”.  Competitions are a start, the next step is to get them into formal education and apprenticeships to learn from the gray-hairs that have been in industry for awhile.

Once again, the same verbiage about tasking Commerce with leading this effort… I’m not sure they’re the ones to do this.

Verdict: Already happening although in ad-hoc fashion.  I’m not sold on teaching high school kids to hack, but yeah, we need to do this.

SEC. 14. PUBLIC-PRIVATE CLEARINGHOUSE. Although the title of this sounds really cool, like super-FOIA stuff, it’s really just information-sharing with critical infrastructure owners and operators.

One interesting provision is this:

“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”

In other words, all your critical infrastructure information belong to Feds.  This is interesting because it can run the range from the Feds asking power grid operators for information and getting what they get, or it can be stretched into justification for auditing of privately-owned critical infrastructure.  I’m pretty sure that they mean the former, but I can see the latter being used at a later stage in the game.

One thing I thought was interesting is that this section only refers to information sharing with critical infrastructure.  There is a big gap here in sharing information with state and local government, local (ie, non-Federal) law enforcement, and private industry.  I think other sections–most notably  section 5–deal with this somewhat, but it’s always been a problem with information dissemination because how do you get classified data down to the people who need it to do their jobs but don’t have any level of clearance or trustability other than they won an election to be sheriff in Lemhi County, Idaho? (population 5000)  Also reference the Homeland Security Information Network to see how we’re doing this today.

Verdict: Really, I think this section is a way for the Feds to gather information from the critical infrastructure owners and I don’t see much information flow the other way, since the means for the flow to critical infrastructure owners already exists in HSIN.

Capitol photo by rpongsaj.

SEC. 15. CYBERSECURITY RISK MANAGEMENT REPORT. This small section is to do some investigation on something that has been bouncing around the security community for some time now: tying security risks into financial statements, cyberinsurance, company liability, etc.

Verdict: Seems pretty benign, hope it’s not just another case where we report on something and nothing actually happens. This has potential to be the big fix for security because it deals with the business factors instead of the symptoms.

SEC. 16. LEGAL FRAMEWORK REVIEW AND REPORT. This section requires a review of the laws, national-level policies, and basically what is our national-level governance for IT security.  As weird as this sounds, this is something that needs to be done because once we have a national strategy that aligns with our laws and policies and then is translated into funding and tasks to specific agencies, then we might have a chance at fixing things.  The one caveat is that if we don’t act on the report, it will become yet another National Strategy to Secure Cyberspace, where we had lots of ideas but they were never fulfilled.

Verdict: Some of this should have been done in the 60-day Cybersecurity Review.  This is more of the same, and is a perfect task for the Cybersecurity Advisor when the position is eventually staffed.

SEC. 17. AUTHENTICATION AND CIVIL LIBERTIES REPORT. This section is really short, but read it verbatim here, you need to because this one sentence will change the game considerably.

“Within 1 year after the date of enactment of this Act, the President, or the President’s designee, shall review, and report to Congress, on the feasibility of an identity management and authentication program, with the appropriate civil liberties and privacy protections, for government and critical infrastructure information systems and networks.”

So my take on it is something like REAL-ID and/or HSPD-12 but for critical infrastructure.

My personal belief is that if you have centralized identity management, it runs contrary to civil liberties and privacy protections: the power of identification lies with the group that issues the identification.  Hence the “rejection” of REAL-ID.

If I operated critical infrastructure, I would definitely protest this section because it gives the Government the decision-making authority on who can access my gear.  Identity and access management is so pivotal to how we do security that there is no way I would give it up.

On the bright side, this section just calls for a feasibility report.

Verdict: Oh man, identification and authentication nation-wide for critical infrastructure?  We can’t even do it in a semi-hierarchical top-down world of Government agencies, much less the privately-owned critical infrastructure.

• 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 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
• The World Asks: is S.773 Censorship?

I just love how the security twit community this month is turning into a bunch of public policy wonks before my very eyes.  First we have S.773, the Cybersecurity Act of 2009 and then the House hearings on the effectiveness of PCI.

“To retain respect for sausages and laws, one must not watch them in the making.” –Otto von Bismark (ref: Wikipedia)

• Why We Need PCI-DSS to Survive
• 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
• The World Asks: is S.773 Censorship?
• Senate Homeland Security Hearings and the Lieberman-Carper-Collins Bill

In the words of one of my twitter buddies… it will be a good thing when this conficker business is over so I don’t have to worry about saying obscene words in meetings anymore.

• IKANHAZFIZMA Does Awareness Training
• Hackers, Protesters, Iran, Twitter, and Lolcats
• LOLCATS, Eric Schmidt, and Privacy
• Noms and IKANHAZFIZMA
• IKANHAZFIZMA and Transparency

So I like reading about what people think about security and the Government.  I know, you’re all surprised, so cue shock and awe amongst my reader population.

Anyway, this week it’s Fortify and a well-placed article in NextGov.  You remember Fortify, they are the guys with the cool FUD movie about how code scanning is going to save the world.  And oh yeah, there was this gem from SC Magazine: “Fortify’s Rachwald agrees that FISMA isn’t going anywhere, especially with the support of the paper shufflers. ‘It’s been great for people who know how to fill out forms. Why would they want it to go away?'”  OK, so far my opinion has been partially tainted–somehow I think I’m supposed to take something here personal but I’m not sure exactly what.

Fortify has been trying to step up to the Government feed trough over the past year or so.  In a rare moment of being touch-feely intuitive, from their marketing I get the feeling that Fortify is a bunch of Silicon Valley technologists who think they know what’s best for DC–digital carpetbagging.  Nothing new, all y’alls been doing this for as long as I’ve been working with the Government.

Now don’t get me wrong, I think Fortify makes some good products.  I think that universal adoption of code scanning, while not as foolproof as advertised, is a good thing.  I also think that software vendors should use scanning tools as part of their testing and QA.

Fortified cité of Carcassonne photo by http2007.

Now for a couple basic points that I want to get across:

• Security is not a differentiator between competing products unless it’s the classified world. People buy IT products based on features, not security.
• The IT industry is a broken market because there is no incentive to sell secure code.
• In fact, software vendors are often rewarded market-wise because if you arrive first to market with the largest market penetration, you become the defacto standard.
• The vendors are abstracted from the problems faced by their customers thanks to the terms of most EULAs–they don’t really have to fix security problems since the software is sold with no guarantees.
• The Government is dependent upon the private sector to provide it with secure software.
• It is a conflict of interest for the vendors to accurately represent their flaws unless the Government is going to pay to have them fixed.
• It’s been proposed numerous the Government use its “huge” IT budget to require vendors to sell secure projects.
• How do you determine that a vendor is shipping a secure product?

Or more to the point, how do I as a software vendor reasonably demonstrate that I have provided a secure product to the government without a making the economics infeasible for smaller vendors, creating an industry of certifiers ala PCI-DSS and SOX, or dramatically lengthening my development/procurement schedules?  Think of the problems with common criteria, because that’s our previous attempt.

We run into this problem all the time in Government IT security, but it’s mostly at the system integrator level.  It’s highly problematic to make contract requirements that are objective, demonstrable, and testable yet still take into account threats and vulnerabilities that do not exist today.

I’ve spent the past month writing a security requirements document for integrated special-purpose devices sold to the Government.  Part of this exercise was the realization that I can require that the vendor perform vulnerability scanning, but it becomes extremely difficult to include an amount of common sense into requirements when it comes to deciding what to fix.  “That depends” keeps coming back to bite me in the buttocks time and time again.  At this point, I usually tell my boss how I hate security folks, self included, because of their indecisiveness.

The end result is that I can specify a process (Common Criteria for software/hardware, Certification and Accreditation for integration projects) and an outcome (certification, product acceptance, “go live” authorization), leave the decision-making authority with the Government, and put it in the hands of contracts officers and subject-matter experts who know how to manage security.  Problems with this technique:

• I can’t find enough contracts officers who are security experts.
• As a contractor, how do I account for the costs I’m going to incur since it’s apparently “at the whim of the Government”?
• I have to apply this “across the board” to all my suppliers due to procurement law.  This might not be possible right now for some kinds of outsourced development.
• We haven’t really solved the problem of defining what constitutes a secure product.
• We’ve just deferred the problem from a strategic solution to a tactical process depending on a handful of clueful people.

Honestly, though, I think that’s as good as we’re going to get.  Ours is not a perfect world.

And as for Fortify?  Guys, quit trying to insult the people who will ultimately recommend your product.  It’s bad mojo, especially in a town where the toes you step on today may be attached to the butt you kiss tomorrow.  =)

• Comments on SCAP 2008
• Ed Bellis’s Little SCAP Project
• Sir Bruce Mentions FDCC, World Goes Nuts
• When Standards Aren’t Good Enough
• No, FISMA Doesn’t Require That, Silly Product Pushers

“Drawn” by an infosec engineer known simply as “TomBot” and passed down in email for years.  Click the diagram to get a bigger version.

Network Diagram by TomBot.

• Et Tu, TIC?
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 2
• When Standards Aren’t Good Enough
• Security Assessment Economics
• A Step Inside the Guerilla CISO’s Mind

Rybolov’s comment: This is Ian’s response to the comments for his post on Cybersecurity Coming to a Boil.  It was such a good dialog that he wanted to make a large comment which as we all know, eventually transforms itself into a blog post.  =)

You are making some excellent points; putting the leadership of the Administration’s new Cyber security initiative directly in the White House might appear to be a temporary solution or a quick fix. From my point of view, it looks more like an honest approach. By that I mean that I think the Administration is acknowledging a few things:

• This is a significant problem
• There is no coherent approach across the government
• There is no clear leadership or authority to act on the issue across the government
• Because of the perception that a large budget commitment will have to be allocated to any effective solution, many Agencies are claiming leadership or competing for leadership to scoop up those resources
• The Administration does not know what the specific solution they are proposing is — YET

I think this last point is the most important and is driving the 60-day security assessment. I also think that assessment is much more complex than a simple review of FISMA scores for the past few years. I suspect that the 60-day review is also considering things like legal mandates and authorities for various aspects of Cyber security on a National level. If that is the case, I’m not familiar with a similar review ever having taken place.

2004 World Cyber Games photo by jurvetson.  Contrary to what the LiquidMatrix Security folks might think, the purpose of this post isn’t to jam “cyber” into every 5th word.  =)

So, where does this take us? Well, I think we will see the Cyber Security Czar, propose a unified policy, a unified approach and probably some basic enabling legislation. I suspect that this will mean that the Czar will have direct control over existing programs and resources. I think the Cyber Security Czar taking control of Cyber Security-related research programs will be one of the most visible first steps toward establishing central control.

From this we will see new organizational and reporting authorities that will span existing Agencies. I think we can also anticipate that we will see new policies put in place and a new set of guidelines of minimum level of security capabilities mandated for all Agency networks (raising bottom-line security). This last point will probably prove to be the most trying or contentious effort within the existing Agency structure. It is not clear how existing Agencies that are clearly underfunding or under supporting Cyber Security will be assessed. It is even less clear where remedial funding or personnel positions will come from. And the stickiest point of all is…. how do you reform the leadership and policy in those Agencies to positively change their security culture? I noticed that someone used the C-word in response to my initial comments. This goes way beyond compliance. In the case of some Federal Agencies and perhaps some industries we may be talking about a complete change sea-change with respect to the emphasis and priority given to Cyber Security.

These are all difficult issues. And I believe the Administration will address them one step at a time.
In the long-term it is less clear how Cyber Security will be managed. The so-called war on drugs has been managed by central authority directly from the White House for decades. And to be sure, to put a working national system together that protects our Government and critical national infrastructure from Cyber attack will probably take a similar level of effort and perhaps require a similar long-term commitment. Let’s just hope that it is better thought-out and more effective than the so-called war on drugs.

Vlad’s point concerning Intelligence Community taking the lead with respect to Cyber Security is an interesting one, I think the Intelligence Community will be important players in this new initiative. To be frank, between the Defense and Intelligence Communities there is considerable technical expertise that will be sorely needed. However, for legal reasons, there are real limits as to what the Intelligence and Defense Communities can do in many situations. This is a parallel problem to the Cyber Security as a Law Enforcement problem. The “solution” will clearly involve a variety of players each with their own expertise and authorities. And while I am not anticipating that Tom Clancy will be appointed the Cyber Security Czar any time soon. I do expect that a long-term approach will require the stand-up of either a new organization empowered to act across current legal boundaries (that will require new legislation), or a new coordinating organization like the Counter Terrorism Center, that will allow all of the current players bring their individual strengths and authorities to focus on a situation on a case by case basis as they are needed (that may require new legislation).

If you press me, I think a joint coordinating body will be the preferred choice of the Administration. Everyone likes the idea of everyone working and playing well together. And, that option also sounds a lot less expensive. And that is important in today’s economic climate.

• Cyber Security coming to a boil
• Beware the Cyber-Katrina!
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 4
• Et Tu, TIC?
• The 10 CAG-egorically Wrong Ways to Introduce Standards