TMW Blog Comment

It has come to my attention that my recent post on the ‘late response from Triangle MicroWorks’ may have been based upon incomplete information.

First off I have been informed that there were earlier direct communications from TMW to their customers long before their most recent post about the ICS-CERT vulnerability on their web site. These communications were not made via their web site; that would not be surprising, particularly if they were made before the publication of the ICS-CERT advisory. That would, in fact, be something that ICS-CERT would encourage; allowing the customers a chance to take corrective actions before the vulnerability became public. That is the whole point of the coordinated disclosure process

Second, I have been told that there were earlier versions of the post that I talked about on the web site, but they were recently removed in a house cleaning action that all web sites periodically undergo. Since I don’t routinely check most vendor web sites (other than when an advisory is issued) I would normally not become aware of such posts.

I became aware of the most recent TMW post because of a social media mention. I based my blog response on the wording of the TMW statements in the post and the fact that there is no other mention of the vulnerability on their web site. It appears that that may not have been an adequate basis for making the judgment that I made.

If I misinterpreted the situation, I apologize to the management, staff and customers of TMW and would be more than willing to provide them space on my blog to fully correct my miss-interpretation of the situation.

NIST Updates Cybersecurity Framework Page – 12-16-13

Earlier this week NIST did a complete revamp of their Cybersecurity Framework (CSF) home page. There is less information directly on the page but there are still active links to all of the developmental information from the old site.

It looks like NIST is getting ready for the publication of the final version of CSF. No word yet when that will be (to be fair the comment period just ended a little over a week ago) but the deadline that was established in EP 13636 was one year or February 19^th, 2014. That deadline does not carry the force of law; the Director of NIST only has to keep his boss, the Secretary of Commerce, happy. In this case that means the keeping the President satisfied that work is progressing with reasonable dispatch.

We’ve already seen how much the President is holding the chemical folks to their deadlines on the Chemical Safety and Security EO, or the National Archives and Records Administration on the Sensitive But Unsecure Information  EO deadlines. If NIST can get a document into the Federal Register by June, the President will probably be real happy. Unless, of course there is a major critical infrastructure breach, then all bets are off.

QUESTION: Why isn’t 40 million compromised bank accounts (ala Target)  a major breach? It’s only money.

Cybersecurity Framework Comments – 12-21-13

This is the fifth (and perhaps the last) in a series of posts about public comments submitted in response to the publication of the NIST Preliminary Cybersecurity Framework (PCSF). The earlier posts are listed below.

Cybersecurity Framework Update – 11-23-13

Cybersecurity Framework Comments – 11-30-13

Cybersecurity Framework Comments – 12-07-13

Cybersecurity Framework Comments – 12-14-13

There were 114 new comments posted to the PCSF comment web site this week, more than double the number from the week before. Actually the number of comments per week has more than doubled every week since NIST started posting the comments. With the number of comments submitted this week, I’m going to have to cut back my comments to those that reflect control system issues.

One thing that we are seeing this week is the ‘corporate comment’ that was obviously written by lawyers. These are old-style format comments (not the NIST requested spread sheet) that speaks in generalities that are of little or no use to anyone trying to clean up or improve the Framework. I’m counting these under the ‘Motherhood’ label.

• Repeat of (7x) add three steps to the ‘Getting Started’ discussion; 1) Determine scope of critical infrastructure to protect, 2) Conduct self-assessment of current cybersecurity status, 3) Ensure continuous improvement.

• Motherhood and apple pie comments (37x). Most of these include objections to the Privacy Appendix.

• Restrict Framework (4x) to the systems and assets essential to critical infrastructure functions.

• Move the Tiers concept to CSF 2.0 after more work.

• Address the role of Sector Specific Agencies.

• Add additional function; Authenticate.

• Address identity management.

• Address security design of communications networks.

• Add more substance to industrial control system issues

• Add ‘Smart Grid’ to control system list.

• Add ISO/IEC 27002 as an Informative Reference.

• Add an Access Control category to Protect function.

Add a listing of ISACs, CERTs, public private partnerships, NIST special publications, and other resources for recovery.

Add subcategory to governance category to address vendor cybersecurity issues.

Add Secure Engineering Design category.

Add , ISO/IEC 19770-2 as an Informative Reference.

Add ANSI/AWWA 430: Security Practices for Operations and Management as an Informative Reference for water systems.

Add NIST Special Publication 800.53 Rev4, Security and Privacy Controls for Federal Information Systems and Organizations, Security Control 44 as an Informative Reference.

Add critical infrastructure criticality measurement methodology.

Add priority rankings to Core table for each subcategory.

Address updates, patches and antivirus use in control systems.

Needs to more completely address the current cybersecurity gaps identified in the various workshops.

Include reference to use of Protectced Critical Infrastructure Information (PCII) protocol for sharing information with government agencies.

Expand use of threat assessment.

Include more complete definition of ‘critical infrastructure’ to make it less ambiguous.

Insurance Issues

There is an interesting letter from Lloyds about cyber risk insurance. It is well worth reading in its entirety as there has been a lot of discussion about insuring cyber risk, but they make one, clear and definitive statement that throws that whole discussion into disarray:

“It is clear that the insurance industry’s current capacity to provide insurance coverage for cyber risk is insufficient to meet the anticipated size of the risk.”

Essential Problem with CSF

Jack Whittsitt has a very detailed letter about the current state of cybersecurity, the ineffectiveness of current ‘Best Practices’ and the short comings of the CSF. I urge anyone concerned with cybersecurity to read Jack’s letter submitted to NIST.

Guidance to Legislators

There is a very interesting comment provided by Southern California Edison about state legislatures getting involved in the cybersecurity process. They note:

“If state legislatures and regulators begin independently addressing cybersecurity concerns inconsistent approaches, the lack of cohesion could actually reduce our overall defenses.”

The same could, of course, be said for the Congress, but the Executive Branch has a notoriously hard time controlling them. The proposed solution calls for providing “guidance to state legislatures and regulators regarding how to view the framework and their role with respect to the Framework.” I would love to see how that works out (tiny bit of sarcasm).

Insider Issues

A number of commenters have at least partially addressed the relative lack of coverage of insider attacks in this CSF. One of the broadest statements on this is worthy of a blog post all of its own. It comes from Absio:

“Environmental controls are essential but alone they cannot mitigate the insider problem—and data loss is essentially always an insider problem. Whether attackers get inside via a perimeter breach (hacking or phishing, social engineering) or by invitation (Manning, Snowden), it is from the inside that they do their damage.”

The Big Problem with PCSF

One of the best short-form commentaries on the shortcomings of the PCSF that I have seen comes from the comments submitted by the Department of Defense:

“This framework may be written at too high a level to be executable at the company level. NIST SP 800-37, the Risk Management Framework, is written at a level that can be executed by industry individuals not well-versed in risk management principals.”

Process Commentary

A large proportion of the commenters, and certainly the vast majority of those with specific change suggestions, used the spreadsheet format suggested by NIST in their RFI. With the large number of comments (and some were quite lengthy running to 30+ pages on occasion) this format will make it much easier for NIST to process and review the suggestions. Again, NIST is leading the way among government agencies in innovating the way that it interacts with the public and processes the ideas submitted to it.

The last comment posted to the comment page was placed their on December 20^th, a full week after the close of the comment period. It is not clear if that delay was due to it being a late submission or whether NIST handling issues delayed the posting. We’ll have a better understanding of that as we see if additional comments are posted in the coming weeks.

I am still surprised that there hasn’t been more of an outcry about the short time frame that NIST provided for the comment process. On a program of this significance I would normally expect at least a 90-day comment period, not one of 45 days. This is especially true since the comment period included Thanksgiving and December is frequently a time of reduced staffing throughout industry and government.

I understand that NIST has a February deadline to get the CSF published. Even with their better information processing ability they are going to be hard pressed to get all of these comments processed, appropriate editing done and get the document approved through the political and administrative review process in time to meet their deadline. Still, shortened comment period is going to have a political downside as the government tries to get critical infrastructure organizations to voluntarily adopt this Framework.

Senate Confirms Mayorkas as Deputy Secretary of DHS

This morning the Senate confirmed Nicholas Mayorkas to be Deputy Secretary of the Department of Homeland Security by a mostly party-line vote of 54-41. The Noes were not so much against Mayorkas as against voting on his nomination while he was still under investigation by the DHS IG for alleged improprieties while he has been the Director of US Citizenship and Immigration Services.

Senate Sends NDA to President

Yesterday the Senate agreed to the House amendment to HR 3304, the National Defense Authorization Act FY 2014, in a bipartisan vote of 84 – 15 [Link added 10:55 CST 12-20-13].

I’m a little bit late posting this, but I have been trying to wait until the Senate vote web page shows the details of this vote, but they still seem to be stuck on an earlier vote. The Government Printing Office is also having problems with publishing the version of HR 3304 that was passed in the House last week; the link to the page results in a ‘page cannot be found’ error message.

There was an afternoon attempt to derail the ‘passage without amendment plan’ of Sen. Reid (D,NV), but it was narrowly defeated by a vote of 45 – 55. Once that hurdle was cleared it was just a matter of how much speechifying needed to be done before the final vote could be held.

The bill, along with its cybersecurity provisions that I discussed earlier, now heads to the President for signature.

A Late Response from Triangle Microworks

Readers of this blog are well familiar with the on-going issue of improper input validation vulnerabilities in a variety of DNP3 protocol products from a number of different suppliers. There was yet another ICS-CERT advisory published yesterday. Each of the disclosures in this family have been coordinated disclosures by Crain-Sistrunk that remained tightly held until the affected vendor had patches or upgrades in place to fix their specific vulnerability. Only then did ICS-CERT publish the advisory for that vendor’s vulnerability.

A Late Announcement

This makes the announcement earlier this week on the Triangle MicroWorks web site more than a little odd. This is the first mention of the ICS-CERT advisory on their web site since that advisory was issued back in August. According to ICS-CERT they had a verified (by Crain-Sistrunk) update available then (no link was provided, just a note to contact the company) to correct this vulnerability. So, why the delay?

Now I don’t know the folks at TMW and I don’t follow the business side of this issue, so I can’t answer that question with any certitude. But I can tell you what it looks like to me like an attempt to ignore the problem, hoping that they would never have to admit to their customers that they had made a mistake. They corrected the coding problems; they get attaboys for that. But those attaboys get wiped out by the awshit that they get for not being proactive about getting the word out to their customers so that they could fix the existing problems in the installed systems.

Blame Shifting

To make matters worse the announcement attempts to minimize the extent of the problem by noting that the vulnerability “can only be exploited by a hacker when the security perimeter for the SCADA Network has been breached”. So this makes the problem not a coding issue, but a problem with the customer’s implementation of security.

Now, to be fair, there is an ongoing debate within the control system security community about the topic of ‘insecure by design’ and whether or not security is a perimeter defense issue or whether it should be focused on the interior devices. Both sides in that debate have legitimate points in support of their arguments.

Unfortunately, many of the slave devices affected by this vulnerability are placed in locations where no one is going to install real physical security safeguards to provide a reasonable security perimeter behind which these vulnerable devices can operate with impunity. Pole mounted devices and devices in remote locations protected by a simple fence are particularly vulnerable to the serial port vulnerability reported by Crain-Sistrunk.

I suppose it is the customer’s decision to deploy these devices in locations where their security cannot be assured. And that is a risk-benefit analysis that only the system owners can make. But to make that decision they must be fully aware of the potential vulnerabilities that they are accepting.

Bigger Problem than Reported by ICS-CERT

There is another attaboy that TMW gets for information in this announcement. The original ICS-CERT advisory only reported vulnerabilities associated with the outstation source code library produced by TMW. According to this week’s notice:

“A similar vulnerability was discovered shortly after, which could affect customers using our DNP3 Master Source Code Library.”

Looking at the language used here it looks like TMW is self-reporting an expanded vulnerability that they discovered. I think that it is always a good thing for vendors to self-report vulnerabilities, it demonstrates an on-going commitment to increasing the security of their devices and code.

I look forward to seeing ICS-CERT update their TMW advisory to reflect the additional vulnerability.

DNP3 Application Note

So why would TMW be making this late statement about their corrected vulnerability if they had been trying to publicly ignore it for so long? It looks like the reason is related to last week’s release of the new DNP3 User Group application note addressing this exact issue. While many people don’t directly follow the ICS-CERT advisories, most anyone that would buy the various DNP3 code libraries from TMW would be expected to notice that announcement from the DNP3 Users Group.

In fact, yesterday TMW posted another announcement on their web site specifically about that topic. Interestingly they close that post with the following comment:

“We are pleased to report that the coding practices at Triangle MicroWorks already exceed these recommendations.”

I’m surprised that they didn’t add that their DNP3 libraries have been fuzz tested by an outside independent security research team; Crain-Sistrunk.

ICS-CERT Publishes DNP3 Advisory #15 – NovaTech

This afternoon the DHS ICS-CERT published their 15^th advisory for a Crain-Sistrunk identified improper input validation vulnerability. This one was for the Orion Master and Slave modules from NovaTech. NovaTech has produced a firmware update that Crain-Sistrunk have verified mitigates the identified vulnerability.

As is typical for this series of advisories, ICS-CERT reports that there are twin vulnerabilities; one affecting IP communications and the other affecting serial communications. The advisory notes that a skilled moderately attacker could remotely exploit the IP vulnerability to execute a denial of service attack. A higher attacker skillset, according to ICS-CERT, would be required to exploit the serial communications vulnerability because either physical access would be required or a social engineering attack would have to be included in the exploit.

While I am not an electrical transmission system engineer, the discussions I’ve seen about the serial communications vulnerability would seem to indicate that certain non-technical skills (cutting a fence or climbing a ladder) would be required to gain physical access to the slave devices, the level of technical skill required to plug in a serial cable is quite low.

BTW, according to the count on the Project Robus web site there are still 10 (or maybe 11, Adam Crain may have lost count of the vulnerable systems) vulnerability reports wending their way through the coordinated disclosure system for nearly identical vulnerabilities. There probably would be more, but Crain-Sistrunk (and now Todorski) have moved on to bigger and better discoveries. Besides, no one wants to catalog all of the systems that are vulnerable because they are based upon a vulnerable library from Triangle Microworks.