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

SEC. 7. LICENSING AND CERTIFICATION OF CYBERSECURITY PROFESSIONALS. This section has received quite a bit of airtime around the blagosphere.  Everybody thinks that they’ll need some kind of license from the Federalies to run nessus.  Hey, maybe this is how it will all end up, but I think this provision will end up stillborn.

I know the NIST folks have been working on licensing and certification for some time, but they usually run into the same problems:

• Do we certify individuals as cybersecurity professionals?
• Do we certify organizations as cybersecurity service providers?
• What can the Government do above and beyond what the industry provides? (ISC2, SANS, 27001, etc)
• NIST does not want to be in the business of being a licensure board.

Well, this is my answer (I don’t claim that these are my opinion):

• Compulsory: the Government can require certifications/licensure for certain job requirements.  Right now this is managed by HR departments.
• Existing Precedent: We’ve been doing this for a couple of years with DoDI 8570.01M, which is mandatory for DoD contracts.  As much as I think industry certification is a pyramid scheme, I think this makes sense in contracting for the Government because it’s the only way to ensure some kind of training for security staff.If the Government won’t pay for contractor training (and they shouldn’t) and the contractor won’t pay for employees to get training because their turnover rate is 50% in a year, it’s the only way to ensure some kind of training and professionalization of the staff.  Does this scale to the rest of the country?  I’m not sure.
• Governance and Oversight: The security industry has too many different factions.  A Government-ran certification and license scheme would provide some measure of uniformity.

Honestly, this section of the bill might make sense (it opens up a bigger debate) except for one thing:  we haven’t defined what “Cybersecurity Services” are.  Let’s face it, most of what we think are “security” services are really basic IT management services… why should you need a certification to be the goon on the change control board.  However, this does solve the “problem” of hackers who turn into “researchers” once they’re caught doing something illegal.  I just don’t see this as that big of a problem.

Verdict: Strange that this isn’t left up to industry to handle.  It smells like lobbying by somebody in ISC2 or SANS to generate a higher demand for certs.  Unless this section is properly scoped and extensively defined, it needs to die on the cutting room floor–it’s too costly for almost no value above what industry can provide.  If you want to provide the same effect with almost no cost to the taxpayers, consider something along the 8570.01 approach in which industry runs the certifications and specific certifications are required for certain job titles.

SEC. 8. REVIEW OF NTIA DOMAIN NAME CONTRACTS. Yes, there is a bunch of drama-llama-ing going on between NTIA, ICANN, Verisign, and a cast of a thousand.  This section calls for a review of DNS contracts by the Cybersecurity Advisory Panel (remember them from section 3?) before they are approved.  Think managing the politics of DNS is hard now?  It just got harder–you ever try to get a handful of security people to agree on anything?  And yet, I’m convinced that either this needs to happen or NTIA needs to get some clueful security staffers who know how to manage contracts.

Verdict: DNSSEC is trendy thanks to Mr Kaminski.  I hate it when proposed legislation is trendy.  I think this provision can be axed off the bill if NTIA had the authority to review the security of their own contracts.  Maybe this could be a job for the Cybersecurity Advisor instead of the Advisory Panel?

SEC. 9. SECURE DOMAIN NAME ADDRESSING SYSTEM. OK, the Federal Government has officially endorsed DNSSEC thanks to some OMB mandates.  Now the rest of the country can play along.  Seriously, though, this bill has some scope problems, but basically what we’re saying is that Federal agencies and critical infrastructure will be required to implement DNSSEC.

Once again, though, we’re putting Commerce in charge of the DNSSEC strategy.  Commerce should only be on the hook for the standards (NIST) and the changes to the root servers (NTIA).  For the Federal agencies, this should be OMB in charge.  For “critical infrastructure”, I believe the most appropriate proponent agency is DHS because of their critical infrastructure mission.

And as for the rest of you, well, if you want to play with the Government or critical infrastructure (like the big telephone and network providers), it would behoove you to get with the DNSSEC program because you’re going to be dragged kicking and screaming into this one.  Isn’t the Great InfoSec Trickle-Down Effect awesome?

Verdict: If we want DNSSEC to happen, it will take an act of Congress because the industry by itself can’t get it done–too many competing interests.  Add more tasks to the agencies outside of Commerce here, and it might work.

Awesome Capitol photo by BlankBlankBlank.

SEC. 10. PROMOTING CYBERSECURITY AWARENESS. Interesting in that this is tasked to Commerce, meaning that the focus is on end-users and businesses.

In a highly unscientific, informal poll with a limited sample of security twits, I confirmed that nobody has ever heard of Dewie the Webwise Turtle.  Come on, guys, “Safe at any speed”, how could you forget that?  At any rate, this already exists in some form, it just has to be dusted off and get a cash infusion.

Verdict: Already exists, but so far efforts have been aimed at users.  The following populations need awareness: small-medium-sized businesses (SMBs), end-users, owners of critical infrastructure, technology companies, software developers.  Half of these are who DHS is dealing with, and this provision completely ignores DHS’s role.

SEC. 11. FEDERAL CYBERSECURITY RESEARCH AND DEVELOPMENT. This section is awesome to read, it’s additions to the types of research that NSF can fund and extensions of funding for the existing types of research.  It’s pretty hard to poke holes in, and based on back-of-the-envelope analysis, there isn’t much that is missing by way of topics that need to be added to research priorities.  What I would personally like to see is a better audit system not designed around the accounting profession’s way of doing things.  =)

Verdict: Keep this section intact.  If we don’t fund this, we will run into problems 10+ years out–some would say we’re already running into the limitations of our current technology.

SEC. 12. FEDERAL CYBER SCHOLARSHIP-FOR-SERVICE PROGRAM. This is an existing program, and it’s pretty good.  Basically you get a scholarship with a Government service commitment after graduation.  Think of it as ROTC-light scholarships without bullets and trips to SW Asia.

Verdict: This is already there.  This section of the bill most likely is in to get the program funded out to 2014.

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

Rybolov Note: this is such a long blog post that I’m breaking it down into parts.  Go read the bill here.  Go read part two here.  Go read part three here. Go read part four here.  Go read part 5 here. =)

So the Library of Congress finally got S.773 up on http://thomas.loc.gov/.  For those of you who have been hiding under a rock, this is the Cybersecurity Act of 2009 and is a bill introduced by Senators Rockefeller and Snowe and, depending on your political slant, will allow us to “sock it to the hackers and send them to a federal pound-you-in-the-***-prison” or “vastly erode our civil liberties”.

A little bit of pre-reading is in order:

• Chairman Rockefeller and Senator Snowe Introduce Comprehensive Cybersecurity Legislation
• Bill Press Release
• Will The Cybersecurity Act of 2009 Require IT Security Professionals To Get A License From The Feds?
• CADNA Supports the Introduction of the Cybersecurity Act of 2009
• http://www.eff.org/deeplinks/2009/04/cybersecurity-act
• Should Obama Control the Internet?

Timing: Now let’s talk about the timing of this bill.  There is the 60-day Cybersecurity Review that is supposed to be coming out Real Soon Now (TM).  This bill is an attempt by Congress to head it off at the pass.

Rumor mill says that not only will the Cybersecurity Review be unveiled at RSA (possible, but strange) and that it won’t bring anything new to the debate (more possibly, but then again, nothing’s really new, we’ve known about this stuff for at least a decade).

Overall Comments:

This bill is big.  It really is an omnibus Cybersecurity Act and has just about everything you could want and more.  There’s a fun way of doing things in the Government, and it goes something like this: ask for 300% of what you need so that you will end up with 80%.  And I see this bill is taking this approach to heart.

Pennsylvania Ave – Old Post Office to the Capitol at Night photo by wyntuition.

And now for the good, bad, and ugly:

SEC. 2. FINDINGS. This section is primarily a summary of testimony that has been delivered over the past couple of years.  It really serves as justification for the rest of the bill.  It is a little bit on the FUD side of things (as in “omigod, they put ‘Cyber-Katrina‘ in a piece of legislation”), but overall it’s pretty balanced and what you would expect for a bill.  Bottom line here is that we depend on our data and the networks that carry it.  Even if you don’t believe in Cyberwar (I don’t really believe in Cyberwar unles it’s just one facet of combined arms warfare), you can probably agree that the costs of insecurity on a macroeconomic scale need to be looked at and defended against, and our dependency on the data and networks is only going to increase.

No self-respecting security practitioner will like this section, but politicians will eat it up.  Relax, guys, you’re not the intended audience.

Verdict: Might as well keep this in there, it’s plot development without any requirements.

SEC. 3. CYBERSECURITY ADVISORY PANEL. This section creates a Cybersecurity Advisory Panel made up of Federal Government, private sector, academia, and state and local government.  This is pretty typical so far.  The interesting thing to me is “(7) whether societal and civil liberty concerns are adequately addressed”… in other words, are we balancing security with citizens’, corporations’, and states’ rights?  More to come on this further down in the bill.

Verdict: Will bring a minimal cost in Government terms.  I’m very hesitant to create new committees.  But yeah, this can stay.

SEC. 4. REAL-TIME CYBERSECURITY DASHBOARD. This section is very interesting to me.  On one hand, it’s what we do at the enterprise level for most companies.  On the other hand, this is specific to the Commerce Department –“Federal Government information systems and networks managed by the Department of Commerce.”  The first reading of this is the internal networks that are internal to Commerce, but then why is this not handed down to all agencies?  I puzzled on this and did some research until I remembered that Commerce, through NTIA, runs DNS, and Section 8 contains a review of the DNS contracts.

Verdict: I think this section needs a little bit of rewording so that the scope is clearer, but sure, a dashboard is pretty benign, it’s the implied tasks to make a dashboard function (ie, proper management of IT resources and IT security) that are going to be the hard parts.  Rescope the dashboard and explicitly say what kind of information it needs to address and who should receive it.

SEC. 5. STATE AND REGIONAL CYBERSECURITY ENHANCEMENT PROGRAM. This section calls for Regional Cybersecurity Centers, something along the lines of what we call “Centers of Excellence” in the private sector.  This section is interesting to me, mostly because of how vague it seemed the first time I read it, but the more times I look at it, I go “yeah, that’s actually a good idea”.  What this section tries to do is to bridge the gap between the standards world that is NIST and the people outside of the beltway–the “end-users” of the security frameworks, standards, tools, methodologies, what-the-heck-ever-you-want-to-call-them.  Another interesting thing about this is that while the proponent department is Commerce, NIST is part of Commerce, so it’s not as left-field as you might think.

Verdict: While I think this section is going to take a long time to come to fruition (5+ years before any impact is seen), I see that Regional Cybersecurity Centers, if properly funded and executed, can have a very significant impact on the rest of the country.  It needs to happen, only I don’t know what the cost is going to be, and that’s the part that scares me.

SEC. 6. NIST STANDARDS DEVELOPMENT AND COMPLIANCE. This is good.  Basically this section provides a mandate for NIST to develop a series of standards.  Some of these have been sitting around for some time in various incarnations, I doubt that anyone would disagree that these need to be done.

1. CYBERSECURITY METRICS RESEARCH:  Good stuff.  Yes, this needs help.  NIST are the people to do this kind of research.
2. SECURITY CONTROLS:  Already existing in SP 800-53.  Depending on interpretation, this changes the scope and language of the catalog of controls to non-Federal IT systems, or possibly a fork of the controls catalog.
3. SOFTWARE SECURITY:  I guess if it’s in a law, it has come of age.  This is one of the things that NIST has wanted to do for some time but they haven’t had the manpower to get involved in this space.
4. SOFTWARE CONFIGURATION SPECIFICATION LANGUAGE: Part of SCAP.  The standard is there, it just needs to be extended to various pieces of software.
5. STANDARD SOFTWARE CONFIGURATION:  This is the NIST configuration checklist program ala SP 800-70.  I think NIST ran short on manpower for this also and resorted back to pointing at the DISA STIGS and FDCC.  This so needs further development into a uniform set of standards and then, here’s the key, rolled back upstream to the software vendors so they ship their product pre-configured.
6. VULNERABILITY SPECIFICATION LANGUAGE: Sounds like SCAP.

Now for the “gotchas”:

(d) COMPLIANCE ENFORCEMENT- The Director shall–

(1) enforce compliance with the standards developed by the Institute under this section by software manufacturers, distributors, and vendors; and

(2) shall require each Federal agency, and each operator of an information system or network designated by the President as a critical infrastructure information system or network, periodically to demonstrate compliance with the standards established under this section.

This section basically does 2 things:

• Mandates compliancy for vendors and distributors with the NIST standards listed above.  Suprised this hasn’t been talked about elsewhere.  This clause suffers from scope problems because if you interpret it BSOFH-stylie, you can take it to mean that anybody who sells a product, regardless of who’s buying, has to sell a securely-configured version.  IE, I can’t sell XP to blue-haired grandmothers unless I have something like an FDCC variant installed on it.  I mostly agree with this in the security sense but it’s a serious culture shift in the practical sense.
• Mandates an auditing scheme for Federal agencies and critical infrastructure.  Everybody’s talked about this, saying that since designation of critical infrastructure is not defined, this is left at the discretion of the Executive Branch.  This isn’t as wild-west as the bill’s opponents want it to seem, there is a ton of groundwork layed out in HSPD-7.  But yeah, HSPD-7 is an executive directive and can be changed “at the whim” of the President.  And yes, this is auditing by Commerce, which has some issues in that Commerce is not equipped to deal with IT security auditing.  More on this in a later post.

Verdict: The standard part is already happening today, this section just codifies it and justify’s NIST’s research.  Don’t task Commerce with enforcement of NIST standards, it leads down all sorts of inappropriate roads.

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

Some of my friends (and maybe myself) will be teaching the NIST Framework for FISMA in May and June with Potomac Forum.   This really is an awesome program.  Some highlights:

• Attendance is limited to Government employees only so that you can talk openly with your peers.
• Be part of a cohort that trains together over the course of a month.
• The course is 5 Fridays so that you can learn something then take it back to work the next week.
• We have a Government speaker ever week, from the NIST FISMA guys to agency CISOs and CIOs.
• No pitching, no marketing, no product placement (OK, maybe we’ll go through DoJ’s CSAM but only as an example of what kinds of tools are out there) , no BS.

See you all there!

• Security Automation Developers Conference Slides
• C&A Seminar, October 15th and 16th
• Comments on SCAP 2008
• New SP 800-60 is Out, Categorize Yerselves Mo Better
• The “Off The Record” Track

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

We’ve got another good US Government Security Certification and Accreditation (C&A) Seminar/Workshop coming up at the end of March with Potomac Forum.

Graydon McKee (Ascension Risk Management and associated blog) and Dan Philpott (Fismapedia Mastermind and Guerilla-CISO Contributor) are going to the core of the instruction, with a couple others thrown in to round it all out.  I might stop by if I have the time.

What we promise:

• An opportunity to hear NIST’s version of events and what they’re trying to accomplish
• An opportunity to ask as many questions as you possibly can in 2 days
• Good materials put together
• An update on some of the recent security initiatives
• An opportunity to commiserate with security folks from other agencies and contractors
• No sales pitches and no products

See you all there!

• C&A Seminar, October 15th and 16th
• Building A Modern Security Policy For Social Media and Government
• Some Comments on SP 800-39
• C&A Seminar in August, Instructor-to-Coolness Ratio Goes Up!
• NIST Framework for FISMA Dates Announced

Did you know that the US Department of Defense published the Consensus Audit Guidelines?  Yes, it’s true!  At least according to a ZDNet UK article title, “US Dept of Defense lists top 20 security controls“.

There is a haze of confusion settling around the Consensus Audit Guidelines origins.  The text of the CAG press release (pdf) is clear that it is developed by a consortium of federal agencies and private organizations.  It further states CAG is part of the Center for Strategic and International Studies work on CSIS Commission report on Cybersecurity for the 44th Presidency.  The title of the CAG press release is also equally clear that it is from a “Consortium of US Federal Cybersecurity Experts” which is substantively different than a consortium of federal agencies and private organizations.

The press release relates that CAG was initiated when a team discovered similarities between massive data losses by the US defense industrial base (DIB) and attacks on Federal agencies.  The project then grew as more agencies agreed to become involved.  Following the current public review of CAG the next steps for development are listed as pilot implementations at government agencies, a CIO Council review and an IG review. The clear inference of this origin story and ennumeration of steps is that the project has official Federal backing.

Let’s test that inference.  Click here for a Google search of the entire *.gov hierarchy for “Consensus Audit Guidelines”.  As I write this there is exactly one entry.  From oregon.gov.  A search using usa.gov (which uses live.com) has the same results.  Looking around the various organizations listed as contributors doesn’t yield any official announcements.

So why the confusion in the press?  Why does it appear from the news articles that this is an Federal project?  I wouldn’t speculate.

On a slightly different topic, I’ve been reading through the Consensus Audit Guidelines themselves and enjoying the guidance it provides.  I’ll write up a more complete analysis of it once I have finished my read through.  My initial impression is that CAG controls provide worthwhile recommendations but the framework for implementation needs development.

All Aboard the Astroturfmobile photo by andydr.  Perhaps an explanation is in order….

• The 10 CAG-egorically Wrong Ways to Introduce Standards
• In Response to “Cyber Security Coming to a Boil” Comments….
• “Machines Don’t Cause Risk, People Do!”
• 20 Critical Security Controls: Control-by-Control
• Keeping The Lights On: Cybersecurity Law for the Electric Grid