TSA Publishes 30-day ICR for Highway Base Program

Today the Transportation Security Administration (TSA) published a 30-day information collection request (ICR) notice in the Federal Register (77 FR 71431) to support their new Highway Baseline Assessment for Security Enhancement (BASE) Program. This program will replace the TSA’s Highway Corporate Security Reviews.

According to today’s ICR notice the “TSA's Highway BASE program seeks to establish the current state of security gaps and implemented countermeasures throughout the highway mode of transportation by posing questions to major transportation asset owners and operators”. The TSA expects to conduct about 750 on-site assessments under this ICR on an annual basis with each assessment lasting about 3 hours.

The notice states that there were four comments filed on the earlier 60-day ICR notice (77 FR 3162), but since those comments were not solicited or filed via the Federal eRulemaking Portal (www.Regulations.gov) there is no readily available source for reviewing those comments. This notice only informs us that:

“Two comments were unrelated to the ICR. The remaining two comments were requests for program information.”

According to the earlier 60-day notice the program will exclude “hazardous materials shippers and carriers as per agreement with U.S. Department of Transportation (DOT)” (77 FR 31633). While the remaining trucking industry will be covered by the TSA security effort the most critical component from the point of view of the potential risk of chemical attacks on large segments of the population via terrorist attacks on HazMat shipments (anhydrous ammonia, or  chlorine for example). While I understand that DOT (federal and State) has many more inspectors, but TSA has primary responsibility (and supposedly the expertise) for transportation security, not DOT.

OMB needs to resolve this conflict of regulatory responsibility between DOT(PHMSA) and DHS(TSA). This ICR would be a good vehicle to initiate efforts to make DHS actually responsible for the security of HazMat transportation.

NIST Announces Smart Grid Advisory Committee Meeting

Today the National Institute of Standards and Technology (NIST) published a notice in the Federal Register (77 FR 71169-71170) that their Smart Grid Advisory Committee would be holding a meeting on December 18^th and 19^th. Among other items to be addressed the Committee will receive presentations on cybersecurity. The actual agenda for the meeting will be published at some point in time on the NIST Smart Grid web site.

The meeting is open to the public, but pre-registration is required. Registration may be done by email (cuong.nguyen@nist.gov). Oral comments may be made at the meeting without further registration. People wishing to provide written comments should send them to nistsgfac@nist.gov.

OMB Approves FRA PTC NPRM

Yesterday the Office of Management and Budget (OMB) announced that it had approved the Federal Railroad Administration’s notice of proposed rulemaking (NPRM) revising some of their positive train control regulations. According to the Fall 2011 Regulatory Agenda (this is the most current version of the Agenda; the Obama Administration has not been updating their agenda very regularly) this NPRM was initiated at the request of the American Association of Railroads (AAR).

The abstract notes that this proposed rule would “revise Positive Train Control regulations by defining the de minimis exception and en route failures, proposing exceptions relating to yard movements that may not be considered on the main line system, and amending regulations governing grade crossing and signal and train control systems.”

One assumes the ‘de minimis’ exception refers to the minimum amount of selected hazardous chemicals that are transported on a section of line that would establish the requirement to equip that section of rail line with PTC systems. The actual weight of chemical triggering that exemption is not likely to change due to the wording of the congressional PTC mandate, so it is unclear what changes would be made.

OMB approved the rule ‘consistent with change’ so there is no telling how long it will take the FRA to publish this rule in the Federal Register. It will be at least a week or two.

CG Publishes LNG-LHG LOR Final Rule

Today the Coast Guard published in the Federal Register (77 FR 70886-70891) a final rule outlining a separate process for reconsideration of  letters of recommendation (LORs) by the Coast Guard concerning the siting of liquefied natural gas (LNG) or liquefied hazardous gas (LHG). The LORs are provided to Federal, State, or local government agencies having jurisdiction for siting, construction, and operation of the facility by the Captain of the Port (COTP) providing the Coast Guard’s assessment of the suitability of the waterway for LNG or LHG marine traffic.

I described the reason for the rule and the process proposed when the NPRM was issued back in December of last year. There were only two comments received concerning the NPRM and both disagreed with the basis of Coast Guard’s proposal of this rule. Those comments from two State agencies in Rhode Island can be found on the Federal eRulemaking Portal (www.Regulations.gov; Docket # USCG-2011-0227). In response the preamble provides additional discussion about why the Coast Guard does not consider the LOR to be either a ‘final agency action’ or a ‘major federal action’.

There was a minor change made to the final rule specifically adding “Indian tribal government” as one of the agencies that has a specific authority to request a reconsideration of a published LOR.

The final rule will be effective on December 28^th, 2012 and will only apply to LOR’s issued after that date.

Luigi and Disclosure – ReVuln

Last week an article on CIO.com about a new company in the cybersecurity market co-founded by Luigi caused a little bit of an uproar when it noted that ReVuln® would be selling vulnerabilities rather than reporting them to vendors or national CERTS. While this is of concern to security managers, it is hardly a new business model. What is new is that a high-profile researcher (and Luigi has always thrived on visibility) is publicly advertising that he is selling vulnerabilities to governments and other ‘responsible’ entities. That plus the fact that they are apparently selling non-exclusive notifications to a wide variety of customers.

Luigi

Luigi made a name for himself through uncoordinated disclosures of vulnerabilities in a wide range of software systems. As I have noted here in a couple of instances Luigi has taken the coordinated disclosure route on occasion (via ZDI), but the vast bulk of his prolific disclosure inventory has been made as simple postings on his personal web site or via Bugtraq.

A number of commenters over the last couple of years have questioned how Luigi could hope to make a living if he continued to piss off vendors via his public disclosures. Those questions have apparently been answered.

ICS Vulnerabilities for Sale

The ReVuln homepage notes that 44% of the vulnerabilities they currently have for sale involve industrial control systems (SCADA). With the current rise in interest in cyber-warfare and cyber-weapons these vulnerabilities should find a relatively vigorous market with governments. Both offensive and defensive activities will find access to these vulnerabilities to be very valuable.

In fact, cyber-defenders are probably going to be forced to subscribe to the ReVuln services since the company is not apparently selling exclusive access to these vulnerabilities. Knowing that an adversary might have access to vulnerabilities in control systems in critical infrastructure, defenders will want to have access to the same vulnerability information to put appropriate defenses in place to prevent their utilization in a cyber-attack.

Will Vendors Buy?

The ReVuln website ‘Services’ tab notes that the Zero-day feed service is available to ‘Companies and Governments’. I’m sure that we won’t hear about it from any of the advertising departments at the major vendors that they are subscribing to this service, but I am willing to bet that there will be some ICS vendors that will think that buying zero day vulnerabilities in the market place will, in the long run, be more cost effective than allowing them to be available to governments and other vendors without knowing about them. At least they would have a chance to get the problems patched if they know about the vulnerabilities.

Actually, I’m pretty sure that vendors would do their best to ensure that they are not seen as subscribers to this service. Luigi and ReVuln are already going to be causing any number of other ‘independent security researchers’ to look at the ‘vulnerability for sale’ business model. If it becomes publicly known that any of the major vendors are subscribers, we will see even more startups in this field.

An interesting question arises because of ReVuln’s marketing of these vulnerabilities to ‘companies’. I don’t see anything that specifically identifies system vendors as being (or precludes them from being) potential customers. If they are willing, for example, to sell to ICS vendors, will Vendor A get access to 0-days for Vendor S? Ignoring the potential marketing advantage of knowing about the competitor’s vulnerabilities, it would certainly make sense that Vendor A should be interested in checking their own system for vulnerabilities similar to those found in Vendor S’s product line.

Will CERTS Buy?

The most obvious potential government agencies that could have potential interest in subscribing to this type service (outside of the military or intelligence services, of course) would be national CERTS. In the US one would like to think that the ICS-CERT would be a natural customer for this type of service. Again, a quiet customer because ICS-CERT also has a strong self-interest in maintaining the coordinated disclosure system.

The question for CERTS is will the politicians allow them (authorize the spending) to subscribe to this type of service? On the one hand the intelligence/military folks probably would not like to see this as ICS-CERT (for example) would be expected to work with the vendor to get the systems patched. That would remove that 0-day from the potential arsenal of the intel/military ops people.

On the defense side of the equation, how would the government go about defending against the 0-days for critical infrastructure installations if they didn’t notify the vendor? Perhaps we will see the rise of a defensive programing cadre within military/homeland security that would develop their own patches for sensitive systems. I can see the military mind coming up with that idea, but no control systems engineer with any sense would apply a patch that hadn’t gone through the vendor vetting process. There’s no telling what neat problems could arise.

ReVuln Security

As one would expect ReVuln takes the security of their product line very seriously. Their web site makes it clear that the vulnerability information is not available directly through their web site (they securely email the 0-days to their customers) and they do not store the vulnerability information on any of their servers. I would suspect that Luigi and company are paranoid enough to store that information on stand-alone computers in a secure and shielded room. After all, they don’t make any money if someone steals their 0-days.

Regulation

One thing is pretty certain, I foresee some vendors calling for the regulation of companies like ReVuln. As much as they have opposed cybersecurity regulation that might have put restrictions or requirements on their operations someone is certainly going to call for restricting the right of folks to sell vulnerabilities. I will be very surprised if we don’t see some sort of pro forma bill introduced during the waning days of this session.

Actually this may be one of the reasons that Luigi and company chose Malta as their home base (besides the beautiful weather, picturesque countryside, and lovely blue water); the US Congress (or EU or whomever) is going to have a difficult time enforcing local laws on their Maltese operations.

Having said that, what would reasonable regulations look like? Well, you can’t shut them down and you can’t stop them from reasonable sales in the public market place; the knowledge of the vulnerabilities comes from their own research so they certainly own it. You could place some reasonable restrictions on who they can sell the information to; no known terrorists or criminal enterprises. Perhaps you could get away with requiring the offering non-exclusive sales to various CERT organizations and allowing those organizations to contact the affected vendors.

Or maybe they could just be required to offer to sell the vulnerabilities to the vendor before offering it on the open market. It would be interesting to see how you would craft rules to establish what is a reasonable price for the vendor to take or leave. Of course, that has been the problem all along as most vendors have been loath to pay some unwashed heathen (okay, they didn’t actually say that, but that has been the impression that many in the research community have been dealing with) for finding some ‘relatively minor’ problem with their control system.

Nothing New

In any case, ReVuln is not really anything new. We have been hearing about an underground economy in 0-day sales for a couple of years now. What Luigi and friend have done is to bring the business plan out into the open so that we can all participate (or not). We will certainly discuss it and perhaps try to regulate it. But, it is not going away.

PHMSA Advisory Pipeline Advisory Committees to Meet

The Pipeline and Hazardous Materials Safety Administration (PHMSA) published a notice in Monday’s Federal Register (77 FR 70543; available on-line yesterday) that it’s two pipeline safety advisory committees, the Gas Pipeline Advisory Committee (GPAC) and the Liquid Pipeline Advisory Committee (LPAC), will be holding meetings over a three day period starting December 11^th, 2012 in Alexandria, VA. The meetings will cover two new pipeline safety rules under development.

Schedule

The LPAC will meet on December 11^th and the GPAC will meet on December 13^th. Both meetings will be half-day affairs. The two will hold a joint meeting all day on December 12^th. The last time these two committees met (back in July) they held their joint meeting first and then held their separate meetings afterward. Apparently a scheduling conflict prevented things from happening that way this time.

Agenda

The notice does state that there will be two topics to be addressed at these meetings, two pipeline safety rules. Those rules address:

• Implement changes to the administrative procedures in Part 190 Enforcement Procedures; and

• Establishment of criteria and procedures for determining the adequacy of state pipeline excavation damage prevention law enforcement programs.

The first appears to be a new rulemaking initiative from PHMSA. There is nothing mentioning this in the latest Unified Agenda. Of course the Obama Administration has not updated the UA since they published the Fall 2011 Agenda in January of this year. We will have to wait and see what information is published on the PHMSA web site or the Federal eRulemaking Portal before this meeting to see what is being proposed.

The second appears to be a follow-up on the notice of proposed rulemaking (NPRM) that was published last March. Since that comment period ended July 9^th and there were 38 comments posted to the Federal eRulemaking portal (www.regulations.gov; Docket PHMSA-2009-0192) for that NPRM, PHMSA seems to be moving fairly quickly on preparing the final rule on this topic.

The notice does not provide a breakdown of which topics will be specifically addressed at the joint meeting versus the stand alone meetings. Presumably the topics at the joint meeting will not be too much of a carryover from the stand alone meetings because of the way the GPAC meeting follows the joint meeting.

The TPSSAC web site does not provide any information on this meeting as of 07:00 EST this morning. There is a mention of the meeting but the link provided is merely a place holder not an actual link. Please note the name changes that are apparently being made for these two committees from their overly long ‘Technical Pipeline Safety Standards Advisory Committee’ titles. The change that is mentioned in passing in this Notice is not yet reflected on the web site.

Public Comments

PHMSA will not be web casting these meetings, alas an ongoing trend apparently for these two advisory committees. The meetings are open to the public and written and oral comments are being solicited. There is no mention of needing to register to attend these meetings, but you must notify PHMSA by email (cheryl.whetsel@dot.gov) by December 5^th if you wish to make an oral statement during the meetings.

Written comments may be submitted via the Federal eRulemaking Portal (www.Regulations.gov; Docket number PHMSA-2009-0203). Please note that this docket has not yet been established as of 07:00 EST today.

CG Announces CTAC Meeting

The Coast Guard published a notice in this Monday’s Federal Register (77 FR 70453-70454; available on-line today) that the Chemical Transportation Advisory Committee (click through the HomePort link for more information) would be holding a 2-day meeting on December 12^th in Washington, DC. The Committee will address issues related to the maritime transportation of bulk-hazardous chemicals. This Committee was re-established last year after having been idle since their 2008 meeting.

Agenda

The Committee will receive presentations from the Coast Guard on:

• Hazardous Substances Response Plans;

• Vapor control systems and mobile vapor control systems;

• Classification of Biofuels and Biofuel blends;

• Shipments and use as fuel of Liquefied Natural Gas and Compressed Natural Gas;

• Air emissions;

• Tank Barge best practices;

• Certification of 3rd party witnesses for the International Convention for the Prevention of Pollution from Ships prewash;

• Material Safety Data Sheets requirement for oils carried as cargo and fuel;

• Pending International Maritime Organization issues;

• Security, Transportations Worker Identification Credential, etc;

• USCG Centers of Excellence; and

• Food grade product safety.

In addition the Committee will establish their initial prioritization of issues and establish the agenda and meeting schedules for Subcommittees and Working Groups to address the topics listed above.

It is possible (but not real likely) that there might be additional information provided on the TWIC Reader Rule recently submitted to the OMB.

Public Comments

The Coast Guard is soliciting public comments on the agenda topics listed above. Written comments and requests to make oral comments at the meeting need to be submitted by November 29^th. Written comments can be submitted via the Federal eRulemaking Portal (www.Regulations.gov; Docket # USCG-2012-1030). Personnel wishing to make oral comments (limited to 3 minutes each) before the Committee should contact Lieutenant Sean Peterson, ADFO (ph – 202-372-1403; fax – 202-372-1926).

ICS-CERT Publishes Sinapsi eSolar Advisory

Earlier this week the DHS ICS-CERT folks published a follow-up advisory to an earlier alert about multiple vulnerabilities in the Sinapsi eSolar family of devices. The original uncoordinated disclosure was made by Roberto Paleari and Ivan Speziale.

Multiple Vulnerabilities

Four vulnerabilities have been identified and confirmed by the vendor. They are:

• Hard-coded credentials – CVE-2012-5862;

• SQL injection - CVE-2012-5861;

• Operating system command injection – CVE-2012-5863; and

• Broken session enforcement – CVE-2012-5864

Note: the CVE links are not yet active as of 11-23-12 06:00 EST; they will be in the near future.

A relatively unskilled attacker could use the publicly available exploit code to remotely attack the affected systems. Depending on the vulnerability exploited arbitrary code could be executed or confidentiality could be compromised

Mitigation

Sinapsi has new firmware for the affected devices and it is available via the system menu in the devices Web interface, so these devices are specifically designed to face the internet contrary to the ICS-CERT recommendation made in this advisory (actually in all ICS-CERT publications).

The advisory also notes that: “Sinapsi released the new firmware on Monday, November 19, 2012 directly to the devices.” This implies (I’m being generous) that Sinapsi has designed these devices to specifically be remotely reconfigured by someone other than the owner without the owner’s consent or knowledge.

Device security certainly does not seem to be a matter of concern with this vendor. In fact, this vendor seems to have taken ‘insecure by design’ to a new level; designed to be insecure. Why bother with these patches?

Multiple Vendors

It is only in the Mitigation section of this advisory that we learn that these vulnerabilities may affect devices from other vendors. The advisory would not be expected to list these vendors until they confirm that they have addressed the vulnerabilities. The original alert listed:

• Enerpoint eSolar Light;

• Schneider Electric Ezylog Photovoltaic Management Server;

• Gavazzi Eos-Box; and

• Astrid Green Power Guardian

Actually, the original exploit was developed for the Schneider device.

CFATS Spending Cuts May Not Be Dead

The congressional news site TheHill.com is reporting that work is being done on preparing an Omnibus FY 2013 spending bill that would replace the stopgap spending bill, HJ Res 117/PL 112-175, that was signed by the President back in October. They are reporting that this bill could be considered in the Lame Duck session.

CFATS

There is currently no word about details that may be included in the bill, but there is a chance that the House Appropriations Committee cuts to the CFATS program found in HR 5855 could creep back into this bill. The earlier Senate DHS spending bill (S 3216) included some cuts to the CFATS program but was holding back on further cuts until a detailed DHS manpower and systems review of the CFATS program was completed. I have not seen the results of any such study but it would probably have been one of those politically restricted reports sent only to the appropriations committees.

On the other hand, an omnibus spending bill that included the standard CFATS extension until the end of the fiscal year would remove some of the pressure for early action on a comprehensive chemical facility security bill. Bills passed under time pressures are usually politically expedient rather than carefully considered and result in program delays and problems down the road. I think that we would prefer to see a carefully crafted bill passed in late 2013 or early 2014 than a politically expedient bill passed in February or March.

Cybersecurity

This type of spending bill might also be a way for Congress to slip some cybersecurity language in for covering some critical infrastructure systems. If it weren’t too onerous in its coverage of privately owned cyber-systems (including control systems) and avoided some of the privacy issues on IT security, it would be difficult to remove such provisions from this large of a bill.

It will have to be watched closely.

EPA Publishes Iodomethane Cancelation Notice

The Environmental Protection Agency published a notice in today’s Federal Register (77 FR 69840-69842) that it had received a request from Arysta LifeScience North America, LLC to cancel its registration of iodomethane as a fumigant. This follows an announcement earlier this year by Arysta that it was canceling the production and sale of Midas®, it iodomethane based fumigant product.

As I noted in an earlier blog, iodomethane (methyl iodine) had been touted as a replacement for methyl bromide as a soil fumigant since it does not have the same ozone destructive characteristics as methyl bromide. In fact, the EPA had awarded Arysta an ‘Ozone Layer Protection Award’ for its Midas fumigant based upon that products substitution for methyl bromide.

Today’s announcement by the EPA is more of a formality than anything since Arysta has stopped marketing this product, but it does act as a notice that the elimination of methyl bromide as a fumigant will be even further delayed since it is the only fumigant effective in a number of critical uses.

As long time readers will be painfully aware, I have long chided DHS for their removal (72 FR 65404) of methyl bromide from the DHS list of chemicals of interest (COI – Appendix A 6 CFR) for the CFATS program. Their naïve acceptance of the EPA assurance of the phase out of the commercial use of this material means that there are some numbers of facilities in the United States that produce, store or use this material that may not have adequate security to protect against the theft or diversion of this material for use as chemical weapon by terrorists.

Today’s announcement by the EPA just further argues that DHS should add methyl bromide back to the COI list in an expeditious manner.

Another DHS-NPPD PCII Questionnaire ICR

On Friday the National Protection and Programs Directorate (NPPD) at DHS published a 60-day information collection request (ICR) notice in the Federal Register (77 FR 68795-68796) that would allow for the establishment of a questionnaire concerning the Protected Critical Infrastructure Information (PCII) program.

The Questionnaire

This is a different questionnaire from the one for which OMB recently approved a separate ICR. While the purpose of both questionnaires is to improve the PCII program, they are apparently targeted at different audiences. The earlier ICR was targeted at federal officials and contractors. According to this notice:

“This questionnaire is designed to gather information from PCII Officers that will be used by the NPPD/IP PCII Program to assess state and local programs, their compliance with PCII rules and requirements, and the specific needs of their accredited programs. These assessments are designed to help the DHS PCII Program and Officers to ensure that PCII is being properly protected and to limit the potential for mishandling and improper disclosures.”

We won’t see the actual questionnaire until the ICR is submitted to the Office of Management and Budget. That means that we won’t actually know what questions are being asked to accomplish the above objective.

Protecting PCII

I am concerned about the phrase “to ensure that PCII is being properly protected and to limit the potential for mishandling and improper disclosures”. The whole point of the PCII program is that the private sector voluntarily shares sensitive information about critical infrastructure with the federal government. The only incentive that the government is able to provide is that it will in turn provide actionable intelligence information that the participants might be able to use to protect their facilities.

Since everyone knows that that information will come infrequently at best (or hopes that it will be infrequent; no one wants to be targeted by terrorists) this is not much of an incentive. This means that any risk of governmental disclosure of the information will be enough to stop most facility owners from sharing critical information with the government.

NPPD certainly has a responsibility to ensure that the privately provided information shared with State and local officials continues to be protected from disclosure. There is nothing in this ICR notice that indicates that there are other tools being used by NPPD to ensure the adequate protection of the PCII information at the State and local level. I certainly wouldn’t advocate that all of the security measures be disclosed, but this notice that proposes that actions need to be taken to ensure that PCII is properly protected at the State and local level should include some sort of assurances that there are other measures already in place to ensure the same thing.

Public Comments

NPPD is soliciting public comments on this ICR. Comments can be filed using the Federal eRulemaking Portal (www.Regulations.gov; Docket # DHS-2012-0046). Comments need to be filed by January 15, 2013.

OMB Receives CG TWIC Reader Rule

On Friday the Office of Management and Budget announced that it had received the Coast Guards notice of proposed rulemaking (NPRM) for the long awaited TWIC Reader Rule. This rule has been held up for a number of reasons including delays in starting and finishing the TSA TWIC Reader pilot program.

As I noted in an earlier blog I would suspect that it will be sometime after the first of the year when OMB approves this NPRM. Because of the slow pace of the rule making process it is likely that the final rule on this will not go into effect until sometime in 2014.

The Lazy Duck Session

So much for Sen. Reid’s (D,NV) threat of holding Senators for a vote on S 3254, the National Defense Authorization Act, before Thanksgiving. Yesterday the Senate voted to start their Thanksgiving Recess today. Okay, it wasn’t even a vote; S. Con Res 60 {co-sponsored by Reid and Minority Leader McConnell (R,KY)} was adopted by unanimous consent; I’ll bet that there weren’t but a handful of Senators present.

To be fair, the important stuff that will be dealt with by this post-election session is mainly being done behind the scenes and will not really be debated in public. There will be a couple of short speeches on both sides and the votes will take place. They may be able to get this done before Christmas.

The House is meeting today and will, among other things, vote on S. Con Res 60; probably the last vote of the day. Even if the House doesn’t agree the Senate will just meet in pro forma sessions like they are today.

Oh, yes, S 3254? The Senate started debate today, officially any way, no actual talking about the bill took place. As predicted a number of amendments were offered, fewer than I expected, but none of them dealt with cybersecurity or cyber-warfare issues.

ICS-CERT Updates CoDeSys Advisory – Sort of

Yesterday DHS ICS-CERT published a new advisory about a novel twist on an earlier CoDeSys advisory; no not the Wightman one from April, but the Luigi-Unuver one from January. That advisory identified, among other vulnerabilities, a stack-based overflow vulnerability based on Port 8080/TCP. The new advisory today identified a stack-based overflow vulnerability based on Port 80/TCP in the ABB AC500 PLC Webserver application that is based upon the CoDeSys Webserver.

The new advisory does not give credit for the identification of the vulnerability so one would assume that it came from ABB. It does note that there is a publicly available exploit code for the vulnerability; one would expect that it refers to the Luigi disclosure on the CoDeSys vulnerability.

Yesterday’s advisory notes that the ABB patch for this vulnerability was made available last December. This is interesting in that this is about the same time that the original Unuver Alert and shortly after the initial Luigi disclosure. It seems that ABB was faster replying to the CoDeSys vulnerability than the original manufacturer.

That makes one think about something that was said about the Wightman discovery of the other CoDeSys vulnerability. The DigitalBond blog by Wightman noted that:

“I mentioned at the beginning a success story. The tools do not work on at least one of the vendor’s products, who chooses to remain anonymous. The vendor has a security development lifecycle (SDL) that included threat modeling. They identified the threat of uploading rogue ladder logic and other malicious files, saw that this was not addressed by the CoDeSys runtime, and added a “security envelope” around the runtime.”

I don’t know who the anonymous vendor is, but this appears to be the same sort of forward thinking security effort that was apparently demonstrated by ABB in this instance. The only question is why did ABB disclose this issue to ICS-CERT at this time. Maybe they want some recognition for their security efforts.

Reid Kills Cybersecurity Bill

This afternoon Sen. Reid (D,NV) effectively killed the Senate’s cybersecurity bill, S 3414, daring the Republicans to vote down a take it or leave it option on a cloture vote. Allowing no attempt for the Republicans to offer any amendments to the bill, Reid insured that he would not get the necessary votes to stop debate, ending with a nearly party-line vote of 51-47 (four Republicans voting Aye and four Democrats voting No). This was a purely political move since Reid knew that the bill would never pass in the House.

We will now see if Reid has any interest in actually allowing the consideration of cybersecurity legislation, no matter how meaningless. As I mentioned in an earlier post, there are three house bills (okay, just three cybersecurity bills) that are waiting for Senate action. If Reid wants to pass a symbolic cybersecurity vote two of those bills (probably not CISPA) would fill the bill. But, I would bet that none of these three bills will see the light of day.

Now we just have to wait for the President’s executive order; the justification has been established.

Senate begins consideration process for S 3254

Yesterday the Senate began the consideration process (consideration of the motion to proceed to consideration of the bill) for S 3254, the National Defense Authorization Act of 2012. Passage of this bill is one of the priorities for the Lame Duck session. It does contain a number of cybersecurity provisions but none of them specifically address control systems issues.

This is an early part of the consideration process for an important bill. A number of news agencies have reported that it won’t actually be considered until after the Thanksgiving Recess, but Sen. Reid (D,NV) said on the floor of the Senate yesterday that it will be voted on before Thanksgiving.

Yesterday’s action did start the amendment offering process.

Cybersecurity Legislation in the Lame Duck Session

Michelle Kincaid has an interesting outlook on cybersecurity legislation potential in the lame duck session in her cybersecurity blog post. While I don’t see anything in particular to disagree with, it is important to remember that political calculations change significantly in a lame duck session, making it much more difficult to successfully predict political outcomes.

While most people focus on legislators that are on their way out, who may (or may not) vote on principle instead of political motives now that they may never face the voters again, there is a new crop of Senators that are now starting into their two year election cycle; many of them will now begin paying more attention to political posturing than principle.

Legislation in the Senate

Most of the cybersecurity legislation attention is being focused on consideration of S3414. Sen. Reid (D,NV) that may bring this back to the floor for consideration this week and there is even a remote chance that it could pass in the Senate. The key stumbling block to its passage will be reaching an agreement with the Republicans on what amendments would be considered before a final vote on the bill. It is unlikely that, even if this bill does get passed in the Senate, that it will pass in the House where there is much more opposition to increasing government regulations.

Overlooked in most discussions of cybersecurity legislation is the fact that there are three bills that have already been passed in the House and are waiting for Senate action. They are

• HR 2096, Cybersecurity Enhancement Act of 2012;

• HR 3523, Cyber Intelligence Sharing and Protection Act; and

• HR 3834, Advancing America's Networking and Information Technology Research and Development Act of 2012

While the CISPA bill is more than a little controversial, the other two bills had strong bipartisan support in the House ( HR 2096 passed 395-10 and HR 3834 passed on a voice vote). While being far from comprehensive bills either of these could probably pass in the Senate if the leadership took the effort to bring them to a vote. These bills may provide Reid with a way of saying that the Senate dealt with cybersecurity legislation in this session.

Legislation in the House

With no Senate passed bills to consider, the House still has one cybersecurity bill that has been reported out of committee that could be considered on the floor with minimal effort; HR 3674, the PRECISE Act of 2012. This bill is actually the closest thing to a House counterpart to S 3414 in that it actually provides VERY limited authority for DHS to regulate cybersecurity in critical infrastructure. This could probably pass a House floor vote without any real problem, but it is too late for this to make it through the Senate as well.

If this bill had been passed in the regular session (and it was put on the house calendar back in July and then ignored) it would have provided a more useful discussion tool for Senate consideration of cybersecurity. It actually would form a pretty good basis for the executive order that is reportedly being worked on by the Administration.

If Rep. Lungren (R, CA) is returned for the 113^th Congress (the vote count has still not been certified and is trending against him) then I would expect to see this bill re-introduced in January.

Still No CFATS Personnel Surety ICR

It has now been 60 days since Under Secretary Beers of the DHS National Programs and Protection Directorate (NPPD) promised Congress that the NPPD would be publishing the new information collection request (ICR) outlining the revised plan for conducting personnel surety background investigations against the national Terrorism Screening Database (TSDB). Needless to say that has not happened.

I doubt that Congress will take action on CFATS during the lame duck session; there are too many really high-priority issues that are on their plate. In January, however, a new Congress will be sitting in Washington and all of the current bills will be erased. An issue that is sure to come up is the reauthorization of the CFATS program. Most of the congressional leaders that Beers has misled over the last two years about the efficacy of the program will still be here. The personnel surety ICR issue will certainly be one of many raised in the reauthorization hearings that will certainly be scheduled in the first couple of months of the 113^th Congress.

Integrating Multiple Critical Systems

The folks at GrayMatterSystems.com have posted links to an interesting white paper on two different LinkedIn Groups, ICS-CS and Water Treatment Industry. It looks at work done by Longwatch, Inc integrating a video surveillance system, an access control system and a SCADA system for a public water utility across multiple sites.

The System

The paper concentrates on the difficulties involving adding video surveillance capabilities to the system that uses digital radio to link 32 remote sites to the central control/monitoring system. This diagram from the whitepaper shows how the video surveillance system at each site was integrated into the overall system with the control of that system using the same human machine interface (HMI) as the multiple facility access control system and the water treatment SCADA system.

In this case the link to the LAN was via a MDS iNET 900 transceiver, the same device used to connect the remote access control and SCADA systems to the LAN. A Wonderware HMI is used to monitor “the status of all doors, alarms, cameras and wireless systems” (pg 5). The whitepaper goes on to note that:

“Monitoring and control of the [water treatment] system is our highest priority, so it is very important that the access control and video do not interfere with process data on the radio network.”

Because of the relatively narrow bandwidth of the radio system (50 kb/sec), the paper describes some of the trade-offs that were made in the video surveillance system. The system transmitted stills to the LAN from each camera every 20 minutes and the operator could switch to live video on any camera when required.

System Security Compromised

While I do understand that utilities (and everyone else in our current economic environment) operate on tight budgets, it does seem to me that the integration of three separate control systems through a single HMI is just asking for security problems. You now have five different software systems (SCADA, HMI, video control, access control and communications) and an untold number of devices that may provide unintended remote access to all of the systems. And in this instance, they are all connected to a “corporate LAN or Internet”; no air-gap here.

A 0-day vulnerability in any of the interconnected systems and devices could lead to a compromise of the entire system. Since each of the remote video systems is specifically designed to allow for a thumb-drive download of video files at each of the remote sites, the system also seems to be inadvertently designed to allow for easy insider attacks, deliberate or otherwise.

Finally, this integrated-system makes water-system operators security-monitors. There is no doubt in my mind that water-system issues will receive priority attention from these personnel, not system security.

The integration of these three systems is certainly cost effective and that makes this an attractive option for many facilities. But the integration of control systems and security systems makes no more sense than integrating control systems and safety systems. A single point of failure or vulnerability compromises all of the integrated systems. The potential cost of failure is just too high.

Lame Duck Congressional Hearings – Week of 11-12-12

Well the election is over and the 112^th Congress is coming back to Washington to catch up on some of the work they couldn’t get done, for a variety of reasons, before the election. There are a large number of important topics on their plate to be dealt with in their limited time left in office yet they still have time to conduct hearings on topics that have already been talked to death.

One such topic is Weapons of Mass Destruction (maybe it should be all caps, if you listen to the rhetoric). This coming week the Subcommittee on Counterterrorism and Intelligence of the House Homeland Security Committee will be holding a hearing on “WMD Terrorism: Assessing the Continued Homeland Threat” on Thursday. No witness are currently listed on Committee web site. It is not currently listed as a closed hearing so there will be no real update of intelligence information presented.

The Chair of the Subcommittee, Rep. Meehan (R,PA), is one of the co-authors of HR 2356, the WMD Prevention and Preparedness Act of 2011, that was reported just before the extended election break, so there doesn’t seem to be much of a legislative reason for conducting this hearing unless the testimony is expected to provide additional information to support a House vote on the pending bill during the lame duck session. There has been bipartisan support for this bill, but action is still ‘pending’ on this bill in four other committees with a 'deadline' for their action of November 30^th. It might take a WMD to actually get this bill to the floor.

Reader Comment – Not All ICS Are Equal

As I promised earlier I would like to address the second half of Dale Peterson’s comment posted to yesterday’s blog about pay for patch. In the second half of his comment Dale said:

Side thought - we are going to need to stop treating ICS as a single category. Not all ICS is used in critical infrastructure. We shouldn't act as if every HMI vuln has a big consequence. The C3-Ilex is actually used in the electric sector and a few others so that does affect what almost all would label critical infrastructure. I'll have a blog [DigitalBond.com] on a different (not patching) aspect of this up later today.

This is not the first time or venue that Dale has made this point, and from time to time we all need to be reminded that we shouldn’t take all reported vulnerabilities with equal seriousness. Nor should we consider every control system to be equally vulnerable.

ICS Vulnerability Reports

Dale has mentioned on a number of occasions that he is concerned with the fact that it appears that ICS-CERT pays as much attention to vulnerabilities in obscure human machine interface (HMI) applications as it does to PLC vulnerabilities in widely deployed systems. It is certainly true that the vast majority of alerts and advisories concern systems that are not widely used in critical infrastructure in the United States. What isn’t as clear is how much of the limited resources of ICS-CERT is taken up with these lesser used system. That would be an interesting study for the DHS IG or the Congressional Research Service.

Having said that, I think that ICS-CERT is still providing a valuable service in the reports that it provides on these systems. These would be even more useful if they maintained an easily searchable database with these vulnerabilities and responses listed in a way that would allow a small company to investigate the security background of these vendors.

Besides, do we really want a government agency like this picking and choosing which researcher reports it is going to address? Unless some outside agency sets very strict guidelines on how those decisions are made (and who else in DHS has the technical background to set those guidelines), such a system of picking and choosing will quickly devolve into a political process that will serve no one well.

Dale in a blog today, also points to large scale problems that ICS-CERT is under-sourced to handle. He give the example of the Project Shine report of 500,000 internet facing control systems that were recently reported to ICS-CERT. He notes that identifying and notifying the owners of those IPs will take a great deal of time and effort. He also questions if it is worth the time of ICS-CERT to complete that herculean task since it is unlike that more than a small fraction will be associated with critical infrastructure facilities. I will note that I am expecting to see a public announcement in the next week or so from a private group that they are going to accept responsibility for identifying and contacting those IP owners, relieving ICS-CERT of that burden.

No, the real problem here is the ‘limited resource’ side of the equation, not that ICS-CERT takes on the vulnerability communications task on little used systems. I think that the doubling of the budget and manpower for this office would have a minimal impact on the size of the federal budget, and it would provide a substantial improvement in the capabilities of the organization.

ICS Vulnerabilities

The other side of Dale’s comment concerns where these vulnerabilities are found in the field. Two systems with control systems that only differ in the number of PLCs connected to the system will have the system vulnerability, but will have different levels of risk associated with them. And that risk is not determined by size alone; a whole host of other factors including socio-economic and political go into determining the risk of an attack on the system.

This is something that has generally been missing from the discussion of ICS Security. Systems that control the stability of the electrical grid are more at risk of attack than those that control the operation of a small hydroelectric plant. The cybersecurity community needs to start talking about how these risk levels will affect decisions about how to secure control systems. It just doesn’t make sense that a manufacturer of kiddy-widgets would need to worry as much about protecting his control system as a similarly sized chemical manufacturer that is handling toxic inhalation hazard chemicals.

Not only is the level of risk different, but the mode of attack is probably going to be different as well. That chemical manufacturer will probably have to be concerned about the probability of a terrorist attack while the widget manufacturer will be more concerned about the potential of attack by a disgruntled employee. These two different types of risk will require two different types of security planning and execution.

Finally, even though Joe Weis has been pushing this idea for years, there really hasn’t been much discussion about the resilience of control systems to unintended system upsets. Most of the cyber-incidents over the last decade have not had anything to do with deliberate attacks on the systems, but seem to have been the result of human error or inappropriate machine responses to and accidental stimuli.

Insecure by Design

One final area that I would like to address that Dale inexplicably did not include in the comment on this blog is the whole idea of ‘insecure by design’. I don’t know if Dale coined the term, but he certainly uses it often enough that many folks cringe at the site of it. The vast majority of PLCs (as an example of insecure devices) in use today never had any thought to security included in their design process. In the most cases, if an attacker gains administrative access to a control system network they can pretty much re-program the PLC to do what the attacker wants. Worse yet, it has been demonstrated in the wild that it can be done without the system owner being able to detect either the access or the re-programing.

Even if every PLC manufacturer started today to turn out only PLCs with secure communications for programing purposes, it would be 10 to 15 years before all of the existing insecure PLCs were pulled out of processes because of life-cycle issues. But, we really don’t need to concern ourselves with replacing all of the insecure PLCs, again because not all of them are equally at risk for attack.

Instead of beating each other up over whether it is more important to cure insecure by design or post-install secure communications link, we need to be talking about defining a methodology to identify relative risk to attack. With that tool owners could decide which PLCs need to be replaced with an expensive high-security PLC, which PLCs should be protected by less expensive add-on secure communications devices and which PLCs can be just left alone to last out their current useful life.

Priorities Must Be Established

In a perfect world it would not be possible to attack any control system because the design, manufacture and implementation of every control system would take security into account at every step of the process. Unfortunately, this hasn’t been done for the control systems currently in use or even being designed for use. It’s too late to worry over much about that; it is what it is.

What current system owners need are tools to determine the risks of their systems to attack, either from within or without. Those systems at the highest risk level, particularly those that are in critical infrastructure installations, then need to determine which parts of their systems are at the most risk and harden those first and hardest. Then they need a plan to continue hardening their systems as time and resources permit.

 

Once we get well started on this, then we can worry as a society about what kind of security we need to reasonably put into place in the lower risk facilities.

Supervisory Chemical Security Inspector Opening

Last week the Infrastructure Security Compliance Division of DHS/NPPD posted a job opening on USAJobs.gov for a Supervisory Chemical Security Inspector. The application period for this GS-15 job position will be open until November 13^th, 2012. The person selected for this position in Arlington, VA will serve as the Branch Chief of the Inspections & Enforcement (I&E) Branch for the CFATS program (and probably the Ammonium Nitrate Security Program if/when that is actually started).

Duties

According to USAJobs.gov the duties of this position include:

• Collaborate and maintain working relationships with other Infrastructure Security Compliance Division branches to inform, educate, and direct security issues to appropriate existing channels for review and resolution.

• Monitor the performance of the Chemical Facility Anti-Terrorism Standards (CFATS) program and relate activities on a continuing basis, taking appropriate steps to improve its effectiveness.

• Provide policy analysis, oversight, and technical expertise on legislation and regulations to the national CFATS program by assessing, interpreting, and implementing regulatory requirements.

• Develop networks and build alliances, engage in cross-functional activities; collaborate across boundaries and find common ground with a wide range of stakeholders. Utilize contacts to build and strengthen internal support bases.

• Responsible for the direct management and supervision of subordinates and oversight of all staff members in the Inspection and Enforcement Branch to include several remote locations.

• Responsible for hiring, performance evaluation, disciplinary action, and leave approval.

Qualifications

The USAJobs.gov site divides qualifications into two categories; Key Requirements and Qualifications Required.

The Key Requirements are:

• U. S. Citizenship is required.

• Must be able to obtain and maintain a Top Secret/SCI security clearance.

• Relocation Expenses MAY be authorized.

• Overnight travel of 6-10 nights per month may be required.

• Selectee will be required to submit a financial disclosure form (OGE-450).

• Must be able to obtain a state driver's license.

For the Qualifications Required at the grade GS-15, applicants must have at least one full year of specialized experience comparable in scope and responsibility to the GS-14 level in the Federal service (obtained in either the public or private sectors). This experience must include activities such as

• Evaluating subordinate chemical inspector preparation, performance, and reporting on chemical facility inspections;

• Reporting on chemical facilities by utilizing the Chemical Facility Anti-Terrorism Standards (CFATS); and

• Supervising the work performance of other chemical facility inspectors.

Commentary

 

It would seem to me that the ‘Qualifications Required’ kind of limit the scope of eligibility for this position to Regional Commanders (the heads of the regional chemical facility inspector teams) in the CFATS program. I don’t see any real problem with this as it would certainly limit the amount of additional training required for someone moving into this position.  It could be argued, however, that limiting this to in-house promotions would not allow for the kind of new thinking that is obviously required to get this program moving forward with the inspection process in a timelier manner.

Tweets and Comments – Pay for Patch

I’m really not trying to run a cybersecurity blog here, but it certainly does seem that cybersecurity posts seem to draw the most attention. I had two readers respond quickly, Joel Langill in a Tweet and Dale Peterson in a blog comment, to today’s blog post telling me that the practice of charging for security patches is fairly wide spread in the ICS vendor community.

 

I’m sorry to hear that, as one should be able to deduce from reading my blog post. Since I haven’t worked on an ICS since 2006 and didn’t maintain it then, it isn’t too surprising that I haven’t heard about this since it certainly hasn’t been discussed in any of my reading sources for the last couple of years.

Oh, well, I guess I could avoid some embarrassment and delete the last paragraph of my post since I obviously got it wrong (along with my tweet about the original posting), but I think I’ll let it stand. I’ve never been one to try to hide my mistakes.

It does make me wonder, if it is fairly wide spread, why ICS-CERT chose to mention the fact in their advisory about the EOScada system. I don’t recall seeing this mentioned in any other advisory that I have read over the last three years. Could it be that someone there in Idaho was trying to provoke a reaction to get a discussion started about the issue? We’ll probably never know, but I would like to think the issue deserves to be discussed, so let this be the forum. I’m not getting paid by either side and I don’t have a personal axe to grind in the matter.

So let’s hear what people have to say on the issue. I would like to hear from owners, and vendors, and integrators, and researchers, and even the politicians. I have a smattering of readers from all of the above. By all means hide behind the anonymous first name but please add your last name as vendor, owner, integrator, researcher or politician, that way we know where the comments are coming from.

And let us see if we can do this politely. On the day before our national election, we need to show the politicians reading this blog how adults discuss the important issues.

 

NOTE: Dale made a second, relatively unrelated point in his comment that I will discuss in a later blog posting.

LinkedIn Comments – Paying for Security Patches

I’ve had an interesting conversation with David Spinks, the owner of the Cyber Security in Real-Time Systems group on LinkedIn® concerning my comments last week about the EOScada advisory from DHS ICS-CERT. Concerning my comments about owners that did not have service agreements having to pay for security patches, David posted the following comment on the CSIRS group site:

“Personnally I think it is reasonable that any vendor charges to issue a patch to organisations that have purchased software and hardware but decide not to take out a maintenance contract. As I have said in other recent discussions the age of ICS on the cheap has gone .... organisations (in particular executive boards) need to beging to invest in security this includes spending on ongoing support and maintenance of the systems they are responsible for .... equipment and softwre refreash should be included in any new budget submissions for ICS systems.”

I replied that:

“I disagree, David. I look at security vulnerabilities in ICS much the same way that the US Government looks at safety defects in automobiles. They are something that the vendor is responsible for providing a fix for, free of charge. Now I would certainly agree that at some point in the life cycle of the product it makes more sense to update/replace than to patch, but given the long life-cycle of these products in the plant environment, this is probably at some significant number of years down the road.”

Now, both of those comments are rather brief, but they do address a very important issue in ICS security; an issue that deserves more than a paragraph describing each of the opposing sides of the disagreement.

To Pay or Not To Pay

First off, let’s clear up a common misconception; the customers are going to pay for patches. A company is going to expend time and materials developing patches. As with any expenses that a for-profit organization expends, the costs are recouped through sales; either directly as a service charge or indirectly through the cost of the products sold. If the costs are not recovered the company goes out of business.

A simplistic view of the above would lead one to believe that the service charge point of view taken by C3-ilex on their EOScada patch is a ‘fairer’ way to pass along the cost of the patch as the current owners are the ones receiving the benefit of the patch, so they should be paying the cost, either through an on-going service contract or a fee-for-patch.

This narrow view ignores the fact that future buyers will also benefit from the patch as it will, hopefully, be applied to future versions of the product. Another method could apply a portion of the current patch development costs to expected future product sales and allow the remainder to be charged to current customers. This may, in fact, be what C3-ilex is doing with this product; they haven’t commented on the effect of this patch on future product pricing.

Fitness for Use

So far this discussion has not looked at product liability issues. Let’s start here with the concept of ‘fitness for use’. This is a legal term that, according to BusinessDictionary.com, means:

“Effectiveness of a design, manufacturingmethod, and support process employed in delivering a good, system, or service that fits a customer's defined purpose, under anticipated or specified operational conditions [emphasis added]. Also called fitness to use.”

Product liability law generally holds that a seller guarantees fitness for use unless they specifically state otherwise. This is the reason that we see the terms ‘limited warranty’ or ‘no warranty implied’ on so many sales advertisements and contracts. The seller is legally proclaiming the fact that they are specifically limiting or declining to guarantee fitness for use.

The big problem here is the phrase ‘under anticipated or specified operational conditions’. Back in the bad-old-days when control systems were assumed to be protected-by-obscurity or air-gapped, no one made any pretenses that there was a need to offer security features on a control system beyond, perhaps, a password for access to work stations. After the twin tower attacks in 2001 we began to see a realization in more control system owners that they had a certain amount of responsibility for security their production systems, particularly in critical infrastructure industries.

Even so, Pre-Stuxnet (PS), there was still a general industry belief that control systems were protected by their complexity and isolation. Ante-Stuxnet (AS) a consensus is developing that there is much more that has to be done to protect control system security than just hide behind the myth of isolation and the faded hope of complexity. I think that a vendor would now have a hard time convincing a product liability jury that basic security measures were not covered under ‘anticipated operational conditions’ on systems sold AS; the question would be more open on PS systems.

Of course, there still remains the problem of deciding which security measures are basic enough to automatically be considered responses to ‘anticipate operational conditions’ or which are problems that could not have been anticipated by a reasonable person. This will have to be decided by case law or legislation.

The Court of Public Opinion

On the other hand, in the court of public opinion, the expectation of free security updates has already been established as the cyber-industry gold standard. In the IT side of the house that standard was clearly established by Microsoft. Their Tuesday push of security patches to the field has caused everyone else to fall into step in pushing free patches to customers; no one does it as effortlessly as MS, but they all silently follow suit.

On the ICS side the major players have all followed the MS example, except they are not actively pushing patches to the field for rather obvious reasons. Thus the standard of free patches has been clearly established in the control system market place. The current case of C3-ilex is an anomaly that will probably not be repeated.

Product Liability Legislation

Let us not forget that when Congress gets sufficiently agitated, they can wield a powerful legislative storm. Earlier I mentioned the special product liability rules that apply to the automotive industry. Largely because of the book, Unsafe at Any Speed, Congress set up the National Highway Traffic Safety Administration (NHTSA) to regulate safety recalls of automobiles. After the Ford-Firestone rollover fiasco, the rules about reporting of safety defects were further strengthened, expanding the rules of what was considered a safety defect.

The NHTSA rules set up a strict regulatory program for vendor reporting of manufacturing defects. Manufacturers are required to report any customer complaint or warranty repair to a wide variety of safety systems on motor vehicles. Additionally, there is a public hotline for direct to the government complaints about suspected safety defects while law enforcement and insurance companies also report suspected defects to NHTSA.

While the vast majority of automotive safety recalls are voluntarily initiated by industry, NHTSA does have the authority to order a manufacturer to initiate a recall. Furthermore, NHTSA receives quarterly reports on the progress of all recalls, voluntary and directed, to establish that the manufacturer is making a good faith effort to contact all owners of the affected models.

Imagine what an Industrial Control System Security Administration might look like if there is a major critical infrastructure incident that is traced back to security vulnerabilities in a control system. Congress may often be slow to act, but it is quick to over react. When its ire is raised, when the general public is grossly offended, Congress legislates with a broad and freely sweeping pen; frequently extending existing regulatory models into uncharted areas. If it is good enough for the auto industry it should be good enough for the control system industry; this is a response that is well understood by politicians.

No Fee for Patches

So no, I don’t see the C3-ilex fee-for-patching model catching on in the industrial control sector. Fortunately they are a small enough player that they are unlikely to attract the ire of Congress and cause legislation to be written to prohibit the practice. Unless, of course, one of the owner operators that has to pay for the current patch has the ear of an influential congresscritter. Then it would be easy enough to slide such a prohibition into a cybersecurity or spending bill. Similar things have happened before.

OMB Approves PCII Survey ICR

Earlier this week the Office of Management and Budget (OMB) announced the approval of an information collection request (ICR) submitted by DHS National Protection and Programs Directorate (NPPD) that would allow NPPD to collect information during a survey of participants of the Protected Critical Infrastructure Information (PCII) program. The ICR was approved without change.

The ICR

The original Federal Register notice for this ICR (76 FR 17935-17936) notes that:

The PCII Program helps government analysts, emergency responders, and other homeland security professionals access data about facilities and systems on which the Nation depends. The PCII Program is responsible for ensuring compliance with the regulation’s uniform procedures for the handling, use, dissemination, and safeguarding of PCII. In this capacity, the PCII Program oversees a community of stakeholders, including submitters of CII, authorized users of PCII and accredited Federal, State and local entities with homeland security duties.

The purpose of the survey covered by this ICR is to “gather information to improve relationships with stakeholders and maximize the value of the PCII Program” according to the abstract provided in the ICR notice. NPPD expects to have 100 responses to this survey and expects that it will take about 13 hours for a respondent to collect the data and respond. As is typical for NPPD submitted ICRs, they don’t expect this effort to cost the respondents any money; apparently they have never heard of the adage that time is money.

Interestingly, this ICR was originally submitted in February and then was withdrawn by NPPD in July; there is no word why the ICR was withdrawn at that time. It was resubmitted in September with no new Federal Register notices (ICR submissions require a 60-day notice and a 30-day notice before being sent to OMB), so one would like to assume that there were no significant changes made in the submission documentation.

The Questionnaire

There is a link to the approved PCII Stakeholder Survey provided in the ICR document; it is actually a Word® document version of the on-line survey. The version of the survey in the original submission is actually a series of web shots of the actual planned on-line survey. The only real differences between the two are differing sets of questions 11 thru 14. There is nothing startling in the differences in those questions other than the approved version appears to be asking for slightly less detail. Perhaps this was done to increase the anonymity of the responses.

While the new question 11 does include ‘Submitter’ as one of the responses to describe the person completing the survey, the responses to question 12 does make it clear that this survey is being targeted at government users of the PCII program, not the public portion that is actually providing the information. That may be why there is no cost associated with the 13 hours per response noted in the ICR.

Implications

I think that it is fair to say that the proper sharing of PCII is an important perquisite to ensuring that intelligence and security analysts have access to the necessary information necessary for doing their jobs. As such it is important for the PCII program managers to understand those things that are making that proper sharing of information more difficult.

The Wiki Leaks fiasco has also shown us what happens when it is too easy to share critical information. It would have been nice to see at least one question in the survey that would address the issues of inadequate information sharing controls.