Closed Rule Adopted for HJ Res 59 – CR

Late yesterday evening (Wednesday) the House Rules Committee adopted a closed rule for the consideration of HJ Res 59, the Continuing Appropriations Resolution, 2014. This means that probably later today the House will have one hour of debate on the Rule (H Res 352) which will pass on a party line vote. Then there will be one hour of debate on the CR and it will pass on a party line vote. The ball will be dropped in the Senate’s court.

CR Provisions Changed

The rule adds an amendment to the version of HJ Res 59 that will be considered by the House. The Rules Committee site summarizes the amendment this way:

“Fully defunds Obamacare and ensures that the Government can make all principle and interest payments on the national debt and ensure the full payment of Social Security benefits in the event that the debt limit is reached. The amendment adds the text of H.R. 2682, the Defund Obamacare Act of 2013, and the text of H.R. 807 (with a modification), the Full Faith and Credit Act, to the underlying continuing resolution.”

All of the earlier portions of the bill will remain intact. This includes the specific provision extending the CFATS authorization for the duration of the CR (December 15^th, 2013) {§122}. 

Senate Actions

The Senate will not pass the CR as currently amended. If the leadership can actually get this to a floor vote, the action will include an amendment stripping the amendment made by the Rules Committee. This will allow the Republicans to force an up/down vote on Obamacare. Pro-Obamacare votes will be a campaign issue in the mid-term elections next year a number of swing States news in next year’s mid-term election.

Whether this will be enough to appease the radical wing of the party remains to be seen. If not the Republican Leadership will need a significant number of moderate Democratic votes to pass the CR after the Conference. It’s happened before during this session and it will likely happen again.

Parliamentary Move

Section 2 of the Rule would allow the House to suspend the rules to consider a bill (like a conference report) at any time during the period of 9-26-2013 thru 9-29-2013 something that is not normally allowed {Clause 1 of Rule XV) on a Thursday, Friday or Saturday.

BTW: This means that the District Work week for next week has been canceled.

Rules Committee Hearing on CR

The House Rules Committee announced this afternoon that is was making an emergency addition to it previously scheduled hearing this afternoon to add a rule for the consideration of HJ Res 59, the Continuing Appropriations Resolution, 2014. This CR was supposed to be considered last week, but was held up continuing discussions within the Republican caucus about how to deal with attempting to defund Obamacare.

As introduced this CR would extend current funding until December 15^th and would extend the CFATS authorization until that date, pending further budget action.

Reader Comment – 09-17-13 – Disclosure – An Opposing View

Last night Jake Brodsky, a long time reader, commentor and well respected user of industrial control systems in a water treating environment, posted a very impassioned response to my post about the ICS-CERT policy on not acknowledging researchers responsible for uncoordinated disclosures. I would like to recommend that all readers take a look at Jake’s response because it is a very good explanation of the problems that many users (not just utilities) have with responding to vulnerabilities in their industrial control systems.

Security Implementation Issues

Jake makes a very real point that many (some might say most) owners of control systems do not have the resources to respond in a timely manner to even the properly coordinated vulnerability disclosures that we would all prefer to see. As larger and larger numbers of control devices are deployed in distribution and manufacturing systems it takes an extraordinary amount of time to test, plan and deploy the useable patches and upgrades that are produced by vendors. And Jake doesn’t even directly address those instances where patches and upgrades cannot be deployed because of their inadvertent effects on other parts of the control system deployed in the field.

Jake and I both agree that uncoordinated disclosures make an already difficult problem even more intractable. Where a coordinated disclosure typically provides Jake and his compatriots in the field with at least a potential solution to their problem, an uncoordinated disclosure provides even more detail about the vulnerability (coordinated disclosures do not typically include exploit code), but it could be months even years before the vendor can develop a mitigation strategy that Jake then has to figure out how to deploy.

Personal Responsibility

Jake takes a very personal interest in the safety and efficacy of the control system for which he is responsible. He also realizes that protecting his system can be best done by improving the overall level of security in the ICS community and he is very active in that effort. Any one that discounts Jake’s opinion does so at his own risk and I support Jake 100% in his efforts to keep control systems safe and secure.

Jake makes an important point in his comment:

“This issue of disclosure and giving credit is about you and me, and the infrastructure we depend on. This is about personal responsibility. If you want to give credit to someone who doesn't comprehend the ramifications of his discovery, that is your right. But I see this as giving immediate gratification to one person in lieu of community security. If we refuse to give them the public accolades they seek, researchers will be less tempted to use black or grey hat disclosure policies.”

 Jake is absolute correct that these disclosures are potentially a problem for everyone on a very major scale. The sooner that our society comes to understand the complexity of the systems that support them and how vulnerable those systems are to attack the better off we will be. Security researchers in particular need to understand the consequences of their disclosures and take personal responsibility for their actions.

Having said that, I disagree with Jake’s last statement. I doubt that Blake or any of his ilk read my blog or have even heard of it and most don’t care that ICS-CERT even exists. I don’t give Blake credit for his benefit; I do it for the folks like Jake so that they know exactly what they are up against. Jake and some of his compatriots may be able to see Blake’s exploit code and figure out a work around defense (okay not many of his compatriots). But more importantly they should be aware immediately that their devices may now be susceptible to attack by any script kiddy that can gain access to those devices.

The places that provide the actual listings of the vulnerability and exploit code (and I do provide links to those sources in my blog post for the reasons described above) are the sites that provide the public accolades that these folks search for. While they are part of the problem, I don’t think that we should fault them too much. I would still prefer to see these disclosures on these sites than to have them sold on the black market to people who clearly intend to be able to use those exploits as weapons. At least we learn of the vulnerabilities when they get posted to these sites.

Legal Responsibility

This brings up an interesting idea. I think that Jake and I would both agree that a researcher responsible for an uncoordinated disclosure that is subsequently used in a successful attack on a control system is at least partially responsible for that attack if his disclosure include exploit code (I’ll explain that caveat in a bit). Unfortunately, I don’t think that any current laws would allow for prosecution of that researcher if that exploit code was used in an attack. If Congress wants to write meaningful cybersecurity legislation, this might be something they should want to include.

I include the ‘exploit code’ caveat in this suggestion to avoid a freedom of speech issue that is very near and dear to me as a blogger. I frequently discuss and describe various vulnerabilities in areas dealing with cybersecurity and chemical security. I acknowledge that some of those discussions might provide an attacker with the genesis of a plan for an attack. I am very careful not to include the level of detail comparable to ‘exploit code’.

Providing ‘exploit code’ level details is the moral and legal equivalent of yelling fire in a crowded theater. Describing the vulnerability is more like pointing out that the theater contains flammable materials and the exits don’t work.

Moving Forward

Clearly Jake is not going to completely agree with much of what I have written above and I respect that. We disagree but we are on the same side. This discussion needs to be held on a wider scale as it has important implications for the future of control system security.

Sooner or later one of these uncoordinated disclosures is going to be used in an actual attack on a real world control system. We need to figure out how we are going to deal with this now, while we can discuss it rationally. If we wait until people are killed in an actual attack the politicians are going to take the discussion out of our hands with knee jerk reactions that will only make our lives more difficult and won’t solve any of the security issues involved.

Bills Introduced – 09-17-13

Congress is in full swing and bills are being introduced in significant numbers in both houses of Congress, but only one bill yesterday that readers of this blog might be specifically interested in; a cybersecurity bill.

HR 3107 : To require the Secretary of Homeland Security to establish cybersecurity occupation classifications, assess the cybersecurity workforce, develop a strategy to address identified gaps in the cybersecurity workforce, and for other purposes. Sponsor: Rep Clarke, Yvette D. (D,NY)

This is the bill that I mentioned in by blog post Sunday. It will be marked up in a hearing before the House Homeland Security Committee today.

ICS-CERT Issues Minor Update to Sixnet Advisory

Today the DHS ICS-CERT published a relatively minor update (or major if you are Kyle Stone) to the previously updated advisory for the Sixnet Universal Protocol. Kyle’s name was added as a researcher who independently identified the undocumented function code vulnerability in the product. I’m assuming that Kyle made a coordinated disclosure, otherwise he would have been ignored by ICS-CERT.

Acknowledging Uncoordinated Researchers

There was an interesting Twitversation last night that was started by my Tweet on the failure of ICS-CERT to acknowledge the researcher, Blake, who was responsible for the vulnerability disclosures that were the basis for the two latest ICS-CERT alerts. You can see the entire conversation by viewing Adam Crain’s Tweet. This is a perennial discussion in the ICS security community and I would like to take this opportunity to explain my point of view on the topic.

Uncoordinated Disclosures

First let me start off by clearly stating that I think the most effective (from the user’s perspective) form of vulnerability disclosure is a coordinated disclosure through ICS-CERT. This way the vendor has a chance to correct/mitigate the vulnerability before it becomes publicly available. I prefer the disclosure through ICS-CERT over direct disclosure through the vendor because ICS-CERT has a policy of publicly disclosing the vulnerability within 45-days if the vendor “is unresponsive, or will not establish a reasonable timeframe for remediation”.

Public disclosures of a control system vulnerability before the vendor has a chance to see/fix the vulnerability are generally a bad thing for the control system user community. It allows a much wider range of potential attackers to take pot shots at our devices. It is not, however, the worst option from a user perspective. That would be the sale of the vulnerability on the black/grey market to someone who would announce the vulnerability by actually using it to attack a live control system.

Encouraging Security Researchers

Because there will always be security vulnerabilities in any complex piece of software/firmware/hardware the ICS community needs to encourage independent security researchers to continue to look for new and innovative ways to compromise such systems. It is only through discovery and disclosure that these security holes will be discovered. In an era where it has become obvious that cyber-warfare is not only possible, but likely, it is obvious that the community is better served by public disclosure/repair policies than by allowing black-market sales to attackers.

As vendors get more proficient at making their products more secure, it will be harder and more expensive for researchers to find new vulnerabilities. We will find fewer and fewer researchers who will be willing to take on the vulnerability search just out of love of a challenge. They will need to have some sort of recompense for their expenses at the very least.

We have already seen a number of attempts made to turn security research into commercial enterprises, some with more success than others. All of these have some sort of draw backs as seen from the wider user perspective in that there is no guarantee that the discovered vulnerabilities are going to get directly back to the vendor so that corrective actions can be taken to eliminate the vulnerability. Lacking an effective bug-bounty program we are going to see even more of these attempts at grey-hat research organizations.

Independent Researchers

The age of the independent researcher as the main source of vulnerability discoveries has passed. That doesn’t mean, however, that they have disappeared from the landscape. There will always be the independent who loves to try his skills against corporate computing. This will also continue to be the breeding ground for young researchers who are trying to establish reputations that will ensure their access to jobs with the more formal research community.

The ICS community needs to encourage these independent researchers to move into the larger community. This cannot be achieved by ignoring their accomplishments. Failure to provide public recognition of the efforts will drive them to the black-hat community that thrives on notoriety or into the hands of the black-marketeers that will financially reward them for their efforts.

Intellectual Property Protection

As an independent blogger, I have a great deal in common with the independent security researcher. I write this blog because of a love for the industry and the challenge of changing society. The only compensation that I receive for this work (and there are lots of hours put into this, just ask my wife) is the recognition of my efforts and the knowledge that in some small way I am making a difference.

It is important to me that my ideas are shared, but it is also important that my work is acknowledged when it is shared. Most people, when they quote my ideas will give credit either to this blog or to me personally; that is all I ask. However, when someone quotes my work without giving me credit, they are stealing my work. They are misappropriating my intellectual property.

This is what ICS-CERT is doing when they publish a vulnerability discovered by an independent researcher yet fail to disclose either who that researcher is or from where they obtained the information. Just because they are a government agency does not make that misappropriation any less real or any less costly to the researcher. In fact, it can be argued that misappropriation by a government agency is even worse because it gives the appearance that such theft is socially acceptable or even legal.

Change the Policy

ICS-CERT needs to change their policy on disclosing the identity of independent researchers who publicly disclose ICS vulnerabilities without coordinating that disclosure with either ICS-CERT or the vendor. They are not going to stop such disclosures by failing to recognize their sources, they will only drive them firmly into the opposing camp and ensure that the zero day vulnerability will become public only when it is used as a weapon.

Needless to say, I will continue to give credit where it is due whenever I can discover who was behind the initial disclosure.

Another ICS-CERT Alert for Blake

The DHS ICS-CERT just released their second alert in less than a week, for another ActiveX control, this time in the Mitsubishi MC-WorkX Suite; another SCADA/HMI application. Further pushing the similarities with the previous alert, ICS-CERT again failed to give Blake credit for the discovery of this vulnerability (two thumbs down). ICS-CERT does get credit for publishing faster, this uncoordinated disclosure was made yesterday on Exploit-DB.com (one thumb up).

ICS-CERT notes that this vulnerability is reportedly remotely exploitable and could result in arbitrary code execution.

Looking at Blake’s history on Exploit-DB it looks like he has come back to hackery after a hiatus of some sort. He seems to have a penchant for ActiveX vulnerabilities, though he is certainly more versatile that just that. It does seem that he has just started targeting control systems. I wonder how many more ActiveX vulnerabilities he will be reporting?

BTW: Can someone answer a question about ActiveX controls for me? Is it possible that we could see the same control in multiple applications? And, if it is vulnerable in one, will it be vulnerable in the others?