Interesting article in Security Focus on President Obama and cybersecurity.  Yes, I complained on twitter because the “document on homeland security” is not really any kind of a solution, more like a bullet list of goals that sound suspiciously like a warmed-over campaign platform.

Guess what?  Every President does this, they put out their agenda for everyone to see.  With the last administration, it was the 5-point President’s Management Agenda.

Let’s be honest here, as Bubba the Infantryman would say, “There are only a couple of ways to suck an egg, and this egg has been around for a long time.”  Any cybersecurity strategy will harken back to the National Strategy to Secure Cyberspace because the problems are the same.  If you remember back to when the NStSC was first released, a horde of critics appeared out of the woodwork to say that there wasn’t enough implementation details and that the strategy wouldn’t be implemented because of that.  Well, they were partly right.

And now there’s the President stating his agenda with the same ideas that people have been saying for 6 years in more detail than what and suddenly it’s new and innovative.  That’s politics for you, folks.  =)  Bubba, in a rare fit of wisdom would say “The way you can tell the true pioneers is that they have arrows sticking out of their backs” and it might seem apropos here, if maybe a little bit cynical.

Hidden Agenda Eats Agenda photo by emme-dk.

Let’s go through each of the points with a little bit of analysis from myself:

Great idea.   Between OMB, NIST, DHS, DoD, DOJ, and a cast of thousands, there is a huge turf war over who really owns security.  Each of these groups do a phenomenal job doing what it is they do, but coordination between them is sometimes more like a semi-anarchist commune than a grand unified effort.  I seem to remember saying at one point that this was needed.  Granted, I was specifically talking about the internal side of the InfoSec Equitites Issue, so the scope here is a little different.

The Cyber Czar is literally buried deep down inside DHS with no real authority, a presidential advisor like is in the agenda would report directly to the President. 

We have a very good R&D plan in place (.pdf caveat), it just needs to be adopted and better funded.  For those of you who need a project, this is like a wishlist on things that some very smart Government guys are willing to fund.

Ouch, I cringe when I read this one.  Not that it’s needed because when it really comes down to it, every CISO in the US is dependent on the software and hardware vendors and their service providers.

Something the world outside the Beltway doesn’t understand is that “standards” are roughly equal to “regulation”.  It’s much, much better if the Government goes to industry groups and says “hey, we want these things to be part of a standard, can you guys work to put it all together?” There might be some regulation that is needed but it should be kept as small as possible.  Where the Government can help is to sponsor some of the standards and work along with industry to help define standards.

Maybe the best model for this is the age-old “lead the horse to water, demonstrate to the horse how to drink, hold the horses mouth in the water, and you still can’t get them to drink.”  We’ve tried this model for a couple of years, what is needed now is some kind of incentive for the horse to drink and for vendors to secure their hardware, software, firmware, and service offerings.

Maybe this gets down to political beliefs, but I don’t think this is the Government’s responsibility to prevent corporate cyber-espionage, nor should you as a company allow the Government to dictate how you harden your desktops or  where you put your IDS.  If you are not smart enough to be in one of these high-tech industries, you should be smart enough to keep your trade secrets from going offshore, or else you’ll die like some weird brand of corporate darwinism.

Government can prosecute evildoers and coordinate with other countries for enforcement efforts, which is exactly what you would expect their level of involvement to be.

Yes, in some cases when it’s cyber-espionage directed at the Government by hacking contractors or suppliers (the military-industrial complex), then Government can do something about it with trickle-down standards in contracts, and they usually do.  Think ITAR export controls scoped to a multi-national corporation and you have a pretty good idea of what the future will hold.

This point is interesting to me.  We already have rules to flag large transactions or multiple transactions, that’s how Elliot Spitzer got caught.  Untraceable Internet payment schemes sounds like pulp-fiction stuff and income tax tracking to me, I would like to know if they really exist.

On the other hand, law enforcement does need training.  There really is a shortage of people with the law enforcement and technical security backgrounds who can do investigations.

National data breach law == good, because it standardizes all of the state laws that are such a hodge-podge you need a full-time staff dedicated to breaking down incidents by jursidiction.  We have something like this proposed, it’s S.459 which just needs to be resurrected and supported by the Executive Branch as part of their agenda.

A common standard could be good as long as it’s done right (industry standards v/s Government regulation), see my comments above.

Note some key points I want you to take away:

Nothing is new under the sun.  These problems have been around a long time, they won’t go away in the next 4 years.  We have to build on the work of people who have come before us because we know they’ve looked at the problem and came to the same conclusions we will eventually come to.

Partnership is emphasized.  This is because as much lip-service we give to the Government solving our problems, the American Way (TM) is for the Government not to be your Internet Nanny.  Government can set the environment to support private information security efforts but it really is up to the individual companies to protect themselves.

Industry needs to solve its own problems.  If you want the Government to solve the nation’s information security problems, it means that we take US-CERT and have them monitor everything whether you want them to or not.  Yes, that’s where things are heading, folks, and maybe I just spilled the beans on some uber-secret plan that I don’t know about yet.  Trust me, you don’t want the transparency that the Government watching your data would provide.

Be careful what you ask for.  You just might get it.  When it comes to IT security, be extra careful because you’ll end up with regulation which means more auditors.

Agenda Grafitti photo by anarchosyn.

• Beware the Cyber-Katrina!
• Cyber Security coming to a boil
• 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 1

I love transition time.  We get all sorts of strange people who come in, issue their letters on how they think the Government can solve the major cybersecurity issues for both the Government’s IT systems and for the rest of the US as a whole.  And then, they all leave.

Nobody actually implements the suggestions because it takes time, effort, and money to get them done, and all that anybody ever wants to give is talk.  Talk is cheap, security is not.

Many years ago when I became an infantryman, our guest speaker at graduation made one of the most profound statements that I remember over 8 years later: “Infantrymen vote with their feet”. In other words, we’re doers, not talkers, and at one point in our lives we decided that something was important enough to give up 4 years of our lives, maybe more, for this cause.  Even Colonel Davy Crockett after he lost re-election to the House of Representatives wrote “I told the people of my district that I would serve them as faithfully as I had done; but if not … you may all go to hell, and I will go to Texas.”  He died less than 3 years later at the Alamo.  That, ladies and gentlemen, is how you vote with your feet.

My personal belief is that the primary problem the Government has with security (on both sides of the InfoSec Equities Issue) is that there is a lack of skilled security practitioners upon which to draw from.  If you think about everything we’ve done to date, it’s almost always a way of compensating for our lack of skilled people:

• Reducing security to a bunch of checklists
• Providing templates to non-security staff
• Automation wherever possible
• “Importing” non-security specialists such as accountants and technical writers in security roles
• Building a “Franchise Kit” upon which to base a security program
• Reserving key decisions for trained security staff

As an industry, we have failed (at least in the public sector) at generating people with the skills to do the job.

And in light of this, my challenge to you:  have a good idea and think you know how to solve the information security?  Yes, we need those, but what we really need are IT security infantrymen who are willing to be doers instead of talkers.  To answer the title of my blog post, the thing that the Government is missing is you.

Infantry Action Photo by Army.mil

So how can you help?  I know moving to DC is a bit of a stretch for most of you to do.  This is a short list of ideas what you can do:

• Learn how the Government secures systems: don’t just dismiss outright what people in DC are doing because conventional wisdom says that it is failing miserably, and don’t listen to people who do the same.
• Actively recruitment of techies to “embrace the dark side” and become security people:  We need more technically-savvy security people.
• Answer the call from DHS when it comes: living in DC is isolating from the rest of the world and all fo the good ideas that are out there.  Maybe you have a phenomenal microstrategy on how to secure IT.  They/we need to know them.  The Government cannot succeed at securing cyberspace (whatever your interpretation of that phrase means) without input from the private sector.
• Don’t engage the Government only when there’s money in it for you. ~$8B is a ton of money, but if you’re doing your job right as a vendor, you’re solving their problems as a first priority, not a second.
• Build a better education system for security staff and make better career paths to get people from the technical disciplines into security.

• Inside the Obama Administration’s Cyber Security Agenda
• Now ISC2 Blogs have an Opinion on FISMA
• In Other News, I’m Saying “Nyet” on S.3474
• Cyber Security coming to a boil
• A Step Inside the Guerilla CISO’s Mind

Government and information security–it really means two different things, and I’m going to break it down for you “Big Bird Stylie” as something I call the InfoSec Equities Issue.

If you’re like me, you have to be wondering the same things over and over again:

• Why is is that DHS has perpetually scored low on their FISMA report card and yet they are supposed to be leading the way for cybersecurity for the nation as a whole? (FYI, they got a B+ for FY 2007)
• How is it that the Government as a whole can have these gianormous data breaches ala the Veterans Administration and yet still claim to know how to help us secure our systems?
• Does the FTC really expect me to keep a straight face when I read OnGuardOnline?

Well fear not, dear readers, for this is the secret to understanding these conundrums:  they’re actually different issues with a different funding trail.  This budget difference, although a topic we security people shun whenever we can, is insanely critical.

For securing their own internal systems, the Government faces exactly the same problems that most companies have only amplified because of scale–security is a cost center, and cost centers get reduced wherever possible.  Fudiciary responsibility to the taxpayers requires that the agency CISO’s staff do more with less, and that’s not a happy thought if you end up on the wrong side of the security budget equation.

Minimal Security photo by °Florian.

When it comes to security of external systems (and some national-level internal programs), the Government runs these as a program and offered as a service to the nation.  Some typical programs include the following:

• Almost all of the National Cyber Security Division
• Department of Justice’s Computer Crime and Intellectual Property Section 
• The National Infrastructure Protection Plan
• DHS’s Science and Technology Directorate
• And yes, even NIST’s FISMA Project

It’s one of Washington’s best-kept secrets: being a program manager in the Government means that you get a mission and a bag of money, and your job is to decide where to spend it all.  This is the sweetest job and the one that you want whether it’s in security or any other discipline that you could image is a Government service–health care, law enforcement, or even the infamous “Gub’mint cheese”.

However, all is not peachy for programs.  They can get cancelled based on political will and trends, so if your program ends up non-favorably in the Washington Post, you might end with your bag of money pilfered for other programs.

Heightened Security photo by robmcm.

This concept of divergent funding is all nice and neat except, dear readers, when the issues are not separate–ie, when an internal IT system protected by the internal budget supports a particular program.  For example, consider the following scenarios:

• Security of vulnerability data at US-CERT (external) that resides on a Government IT system (internal).
• A financial system (internal) that tracks distributions to welfare recipients (external).
• A government website (internal) that supports awareness and training on security issues affecting individual citizens such as identity theft (external).

Now this is the concept behind the way Government is supposed to be running security programs:  the internal funds pay for the centralized security and the funded programs pay for any level of security for IT systems that they sponsor.

But several catches:

• The system owner has to understand how to budget for or ensure that security for their program is budgetted for.  Somewhere in there is an understanding of security risk.
• The system owner (who in theory has better funding and therefore better security) is dependent upon the centrally-managed security (which in theory has less funding and therefore worse security).
• Program-specific security comes out of the program, which means that higher security costs means that the program manager can’t spend money on the services they provide, which is where they really want to be spending it.
• A ton of negotiation is required to figure out responsibilities between the program manager and the CIO/CISO.
• If the agency takes too much money out of the program budget for security, we run into the same fudiciary responsibility problems in that we’re not managing our money properly.

• The Press has Me all Confused
• When the Feds Come Calling
• Got Training?
• Splunk Goes After the FISMA Lucre, They’re not Alone
• HR 5983–DHS Now Responsible for Contractor Security

Let’s talk about TIC today, dear readers, for I smell a conspiracy theory brewing.

For those of you who missed the quick brief, TIC is short for “Trusted Internet Connections” and is an architecture model/mandate/$foo to take all of the Internet connections in the Government (srsly, nobody knows how many of them really exist, but it’s somewhere in the 2,000-10,000 range) and consolidate them into 50.  These connections will then be monitored by DHS’s Einstein program.

No, Not That Kind of TIC photo by m.prinke.

Bringing you all up to date, you’ll need to do some homework:

• OMB Memo 08-05, “Implementation of Trusted Internet Connections (TIC)”
• Planning Guidance for Trusted Internet Connections (TIC)
• Final Trusted Internet Connections (TIC) Initiative Statement of Capability Evaluation Report, dated June 4, 2008
• OMB Memo 08-27 Guidance for Trusted Internet Connection (TIC) Compliance

Now having read all of this, some things become fairly obvious:

• If you have the following people needing connections:
  • 24 agencies, plus
  • DoD with 2 points of presence, plus
  • Intelligence agencies with a handful of Internet connections, means that:
• That basically, everybody gets one Internet connection.  This is not good, it’s all single point-of-DOS.
• Agencies have been designated as Internet providers for other agencies.  Sounds like LoB in action.
• Given the amount of traffic going through the TIC access points, it most likely is going to take a significant amount of hardware to monitor all these connections–maybe you saved 50% of the monitoring hardware by reducing the footprint, but it’s still hardware-intensive.
• TIC is closely tied with the Networx contract.
• In order to share Internet connections, there needs to be a network core between all of the agencies so that an agency without a TIC access point can route through multiple TIC service provider agencies.

And this is where my conspiracy theory comes in:  TIC is more about making a grand unified Government network than it is monitoring events–Einstein is just an intermediate goal.   If you think about it, this is where the Government is headed.

We were headed this way back in ought-two with a wonderful name: GovNet.  To be honest, the groundwork wasn’t there and the idea was way ahead of its time and died a horrible death, but it’s gradually starting to happen, thanks to TIC, FDCC, and Einstein. 

More fun links:

• Wired GovNet Article
• FCW GovNet Article
• Gartner Email Analysis on GOVNET (Note this gem: “Enterprises and government agencies should assume that a long-term solution to Internet security will arise elsewhere and should proceed to buy denial-of-service protection and other managed security services from commercial providers.”)

If you want to get a reaction out of the OMB folks, mention GovNet and watch them backpedal and cringe,–I think the pain factor was very high for them on GovNet. So I think that we should, as a cadre of information security folks, start calling TIC what it really is:  Govnet 2.0!  =)

• Comments on SCAP 2008
• The 10 CAG-egorically Wrong Ways to Introduce Standards
• In Response to “Cyber Security Coming to a Boil” Comments….
• Federated Vulnerability Management
• How I Became the Owner of Two Rogue WiFi APs

I just got back from the SCAP 2008 conference at NIST HQ, and this is a collection of my thoughts in a somewhat random order:

Presention slides are available at the NVD website

I blogged about SCAP a year ago, and started pushing it in conversations with security managers that I came across.  Really, if you’re managing security of anything and you don’t know what SCAP is, you need to get smart on it really fast, if for no other reason than that you will be pitched it by vendors sporting new certifications.

Introduction to SCAP:  SCAP is a collection of XML schemas/standards that allow technical security information to be exchanged between tools.  It consists of the following standards:

• Common Platform Enumeration (CPE): A standard to describe a specific hardware, OS, and software configuration.  Asset information, it’s fairly humdrum, but it makes the rest of SCAP possible–think target enumeration and you’re pretty close.
• Common Vulnerabilities and Exposures (CVE): A definition of publicly-known vulnerabilities and weaknesses.  Should be familiar to most security researches and patch monkies.
• Common Configuration Enumeration (CCE): Basically, like CVE but specific to misconfigurations.
• Common Vulnerability Scoring System (CVSS): A standard for determining the characteristics and impact of security vulnerabilities.  Hmmm, sounds suspiciously like standardization of what is a high, medium, and low criticality vulnerability.
• Open Vulnerability and Assessment Language (OVAL):  Actually, 3 schemas to describe the inventory of a computer, the configuration on that computer, and a report of what vulnerabilites were found on that computer.
• Extensible Configuration Checklist Description Format (XCCDF): A data set that describes checks for vulnerabilities, benchmarks, or misconfigurations.  Sounds like the updates to your favorite vulnerability scanning tool because it is.

Hall of Standards inside NIST HQ photo by ME!!!

What’s the big deal with SCAP: SCAP allows data exchanges between tools.  So, for example, you can take a technical policy compliance tool, load up the official Government hardening policy in XCCDF for, say, Windows 2003, run a compliance scan, export the data in OVAL, and load the results into a final application that can help your CISO keep track of all the vulnerabilities.  Basically, imagine that you’re DoD and have 1.5 million desktops–how do you manage all of the technical information on those without having tools that can import and export from each other?

And then there was the Federal Desktop Core Configuration (FDCC): OMB and Karen Evans handed SCAP its first trial-by-fire.  FDCC is a configuration standard that is to be rolled out to every Government desktop.  According to responses received by OMB from the departments in the executive branch (see, Karen, I WAS paying attention =)   ), there are roughly 3.5 Million desktops inside the Government.  The only way to manage these desktops is through automation, and SCAP is providing that.

He sings, he dances, that Tony Sager is a great guy: So he’s presented at Black Hat, now SCAP 2008 (.pdf caveat).  Basically, while the NSA has a great red-team (think pen-test) capability, they had a major change of heart and realized, like the rest of the security world (*cough*Ranum*cough*), that while attacking is fun, it isn’t very productive at defending your systems–there is much more work to be done for the defenders, and we need more clueful people doing that.

Vendors are jumping on the bandwagon with both feet: The amount of uptake from the vulnerability and policy compliance vendors is amazing.  I would give numbers of how many are certified, but I literally get a new announcement in my news reader ever week or so.  For vendors, being certified means that you can sell your product to the Government, not being certified means that you get to sit on the bench watching everybody else have all the fun.  The GSA SAIR Smart-Buy Blanket Purchase Agreement sweetens the deal immensely by having your product easily purchasable in massive quantities by the Government.

Where are the rest of the standards: Yes, FDCC is great, but where are the rest of the hardening standards in cute importable XML files, ready to be snarfed into my SCAP-compliant tool?  Truth be told, this is one problem with SCAP right now because everybody has been focusing on FDCC and hasn’t had time yet to look at the other platforms.  Key word is “yet” because it’s happening real soon now, and it’s fairly trivial to convert the already-existing DISA STIGs or CIS Benchmarks into XCCDF.  In fact, Sun was blindsided by somebody who had made some SCAP schemas for their products and they had no idea that anybody was working on it–new content gets added practically daily because of the open-source nature of SCAP.

Changing Government role: This is going to be controversial.  With NVD/CVE, the government became the authoritative source for vulnerabilities.  So far that’s worked pretty well.  With the rest of SCAP, the Government changes roles to be a provider of content and configurations.  If NIST is smart, they’ll stay out of this because they prefer to be in the R&D business and not the operations side of things.  Look for DHS to pick up the role of being a definitions provider.  Government has to be careful here because they could in some instances be competing with companies that sell SCAP-like feed services.  Not a happy spot for either side of the fence.

More information security trickle-down effect: A repeated theme at SCAP 2008 is that the public sector is interested in what Big SCAP can do for them.  The vendors are using SCAP certification as a differentiator for the time being, but expect to see SCAP for security management standards like PCI-DSS, HIPAA, and SOX–to be honest here, though, most of the vendors in this space cut their teeth on these standards, it’s just a matter of legwork to be able to export in SCAP schemas.  Woot, we all win thanks to the magic that is the Government flexing its IT budget dollars!

OS and Applications vendors: these guys are feeling the squeeze of standardization.  On one hand, the smart vendors (Oracle, Microsoft, Sun, Cisco) have people already working with DISA/NSA to help produce the configuration guides, they just have to sit back and let somebody turn the guides into SCAP content.  Some of the applications vendors still haven’t figured out that their software is about to be made obsolete in the Government market because they don’t have the knowledge base to self-certify with FDCC and later OS standards.  With a 3-year lead time required for some of the desktop applications before a feature request (make my junk work with FDCC) makes it into a product release, there had better be some cluebat work going on in the application vendor community.  Adobe, I’m talking to you and Lifecycle ES–if you need help, just call me.

But how about system integrators: Well, for the time being, system integrators have almost a free ride–they just have to deal with FDCC.  There are some of them that have some cool solutions built on the capabilities of SCAP, but for the most part I haven’t seen much movement except for people who do some R&D.  Unfortunately for system integrators, the Federal Acquisition Regulation now requires that anything you sell to the Government be configured IAW the NIST checklists program.  And just how do you think the NIST checklists program will be implemented?  I’ll take SCAP for $5Bazillion, Alex.  Smart sytem integrators will at least keep an eye on SCAP before it blindsides them 6 months from now.

Technical compliance tools are destined to be a commodity: For the longest time, the vulnerability assessment vendors made their reputation by having the best vulnerability signatures.  In order to get true compatibility across products, standardized SCAP feeds means that the pure-play security tools are going to have less things to differentiate themselves from all the other tools and they fall into a commodity market centered on the accuracy of their checks with reduced false positives and negatives.  While it may seem like a joyride for the time being (hey, we just got our ticket to sell to the Gubmint by being SCAP-certified), that will soon turn into frustration as the business model changes and the margins get smaller.  Smart vendors will figure out ways to differentiate themselves and will survive, the others will not.

Which leads me to this: Why is it that SCAP only applies to security tools?  I mean, seriously, guys like BigFix and NetIQ have crossover from technical policy compliance to network management systems–CPE in particular.  What we need is a similar effort applied to network and data center tools.  And don’t point me at SNMP, I’m talking rich data.  =)  On a positive note, expect some of the security pure-play tools to be bought up and incorporated into enterprise suites if they aren’t already.

Side notes:

I love how the many deer (well over 9000 deer on the NIST campus) all have ear tags.  It brings up all sorts of scientific studies ideas.  But apparently the deer are on birth control shots or something….

Former Potomac Forum students:  Whattayaknow, I met some of our former students who are probably reading this right now because I pimped out my blog probably too aggressively.  =)  Hi Shawn, Marc, and Bob!

Old friends:  Wow, I found some of them, too.  Hi Jess, Walid, Chris, and a cast of thousands.

Deer on NIST Gaithersburg Campus photo by Chucka_NC.

• Sir Bruce Mentions FDCC, World Goes Nuts
• Security Automation Developers Conference Slides
• Some Words From a FAR
• NIST and SCAP; Busting a cap on intruders Part 1
• Ed Bellis’s Little SCAP Project

Ever wondered if your electricity supply was safe from computer attack? Congress wondered that too. So they asked the Federal Energy Regulatory Commission (FERC) to find out. The answers they received in October of 2007 were not encouraging.

After 9/11 there was concern about the safety of the Bulk Power Supply (BPS). The President’s Commission on Critical Infrastructure Protection released a report which was explicit about the dangers faced. A frightening example of these dangers was demonstrated by the Aurora vulnerability, essentially a software hack that made a generator crash hard. When faced with this example industry moved to mitigate the problem with some prodding from Department of Homeland Security (DHS), Nuclear Regulatory Commission (NRC) and FERC. The Nuclear Sector, which is regulated by NRC, issued a requirement to address the problem. The Electric Sector was issued a recommendation to address the problem by the Electric Sector Information Sharing and Analysis Center (ES-ISAC). Guess which industry has moved forward with successful mitigation efforts and which has not. FERC reported back on these findings in October of 2007.

Fast forward to now. On September 11th the Bulk Power System Protection Act (BPSPA) of 2008 (PDF link) was put forward by Rep. Rick Boucher (D-VA), chairman of the House Subcommittee on Energy and Air Quality. In addition to the September 11th hearing on the BPSPA a closed door hearing was expected to be conducted the following week. The goal of this legislation is to expand the emergency power of FERC to regulate cybersecurity for the BPS. The act itself does not appear to be strongly opposed by the energy industry but, as always, the devil is in the details.

Diablo Canyon Nuclear Power Plant photo by emdot.

The draft legislation is disputed on three major points; whether to include national security threats, disclosure of threat information and a sunset provision.

FERC recommends wording that would make explicit the requirement to address national security threats. This seems an implicit and reasonable expectation that the people of the United States would have of the agency regulating the BPS but the Energy Sector considers this too expansive a role. They argue that it might cause expensive requirements to be issued such as stockpiling fuel.

The disclosure of threat information is a sore point. Here you can understand the pain of the industry in dealing with government intelligence agencies who would like to keep details of a threat spare to preserve the source of that information. Unfortunately the government must preserve their sources while providing enough information for the industry to react.

Both FERC and the Energy Sector agree on the idea of a sunset provision. The sunset provision in this case stipulates that so long as an order is implemented as a standard it should terminate one year after issuance unless renewed by the President or the Secretary of Energy. The issue is whether this sunset will include the orders to address existing problems (such as the Aurora vulnerability) in addition to orders issued for future vulnerabilities. FERC recommends that only future orders should be sunsetted while the Energy Sector recommends both current and future orders should be sunsetted.

One element which is not adequately addressed in this legislation is how FERC will build the capability to assess and manage cybersecurity issues for the BPS. What should be in place is a bipartite separation of duties between FERC and NIST similar to what is in place with the dual OMB/NIST FISMA roles. FERC would oversee the security while NIST would provide technical guidance on what security should be put in place. FERC does not have the experience in security frameworks or in depth expertise in SCADA security which is required for a cybersecurity initiative of this magnitude.

It is worth noting that Energy Policy Act of 2005 (PDF link) established a process through which the North American Electric Reliability Corporation’s (NERC) was authorized to enforce cybersecurity in the Energy Sector. NERC had gone so far as to create Critical Infrastructure Protection (CIP) standards to include with their Reliability Standards and had present them to FERC for approval by late 2007.

A review of the NERC CIP standards (CIP-001 through CIP-009) does not inspire confidence in NERC’s cybersecurity capabilities. I will discuss the shortcomings of this guidance in a subsequent post.

• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 2
• The 10 CAG-egorically Wrong Ways to Introduce Standards
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 1
• Help Wanted
• Beware the Audit Hammer