Monday, September 25, 2017

Committee Hearings – Week of 9-24-17

The House is coming back to Washington after a week working in their districts and the Senate is coming back from a really-long weekend. The big news this week will once again be the healthcare ‘debate’ in the Senate, but there will be two hearings of interest, both touching on cybersecurity.

IoT Cybersecurity


On Wednesday the Information Technology Subcommittee of the House Oversight and Government Reform Committee will hold a hearing on the “Cybersecurity of the Internet of Things”. No witness list has been provided.

According to the Library of Congress there are currently three House bills (HR 686, HR 1324, and HR 3010) that contain reference to “Internet of Things” and none of them have been referred to the Oversight Committee for consideration. It looks like the leadership just wants to get into the IOT political game.

Homeland Threats


On Wednesday the Senate Homeland Security and Governmental Affairs Committee will be holding a hearing on “Threats to the Homeland”; which will almost certainly at least touch on a number of cybersecurity topics. The current witness list includes:

• Elaine C. Duke, DHS;
• Christopher A. Wray, FBI; and
• Nicholas J. Rasmussen, National Counterterrorism Center


Considering the breadth of the topic I think we can only expect to see broad highlights in the prepared testimony. It will be interesting, however, to watch the focus of the questions tossed at the panel.

Saturday, September 23, 2017

CSAT 2.0 From the Field

The nice thing about writing this blog is that periodically I get a chance to talk to people in the field that are responsible for implementing the Chemical Facility Anti-Terrorism Standards (CFATS) program. I had one of those conversations today with a long-time reader who is a contractor helping a new CFATS covered facility that was caught up by CSAT 2.0. As is usual these conversations are tempered by having to adhere to Chemical-terrorism Vulnerability Information (CVI) rules, so specifics could not be mentioned. Still, there is some information worth sharing.

CSAT 2.0 and MTSA


A lot of facilities are being introduced to the CFATS program by recent changes in the Chemical Security Assessment Tool (CSAT 2.0) and the new risk assessment process that was concurrently introduced by the Infrastructure Security Compliance Division (ISCD) at DHS. This was not covered in my discussions today, but I am hearing indications that some of these new facilities used to feel that they were exempt from CFATS coverage because they were covered by the Coast Guard’s Maritime Transportation Security Act (MTSA) program. The notification letters that ISCD started sending out last fall make it clear that only those portions of the facility covered by MTSA requirements are exempt from the CFATS program requirements.

It seems that a number of facilities took the allowable course of restricting their MTSA footprint to the immediate shore side portion of their facilities. For many larger facilities, this left major portions of the facility uncovered by federal security regulations. ISCD made it clear that those portions of the facility not covered by MTSA were subject to the CFATS Top Screen reporting requirements and potentially full coverage under the CFATS program depending on the DHS risk assessment based upon Top Screen submission data.

After the Tiering Letter


The conversation today addressed some of the lessons learned at a CSAT 2.0 facility that recently received their tiering letter (the official notification from CSAT that the Top Screen submission and subsequent risk assessment had allowed ISCD to determine that the facility is at ‘high-risk’ for potential terrorist attack and was therefore subsequently placed in the CFATS program.

After the inevitable “oh, no… really?” conversation the facility requested a compliance assistance inspection as they began work on prepping for the security vulnerability assessment (SVA) and site security plan (SSP) submissions. Shortly thereafter a DHS chemical security inspector (I still hate the inevitable ‘CSI’ fallout) showed up to take a look at the facility and the work they had already done to make it secure. This is one of those rare cases when you can sigh with relief instead of cringe when the guy says: “I’m from the government and I’m here to help you.”

The initial good news was that because of a detailed DOT Hazmat Security Plan (49 CFR 172.802) the facility had a good head start on fulfilling the requirements of the CFATS Risk-Based Performance Standards (RBPS; 6 CFR 27.230) as explained in the RPBS Guidance document. Additionally, since the CSI had already seen this type of facility before, he was able to provide a template that could probably be used by the facility to submit an alternative security plan (ASP, not the ACC/NACD ASP that I have previously discussed) instead of submitting the cumbersome SSP found in the CSAT tool. (Note: I’m trying to see if I can get hold of a link to that new template.)

Cooperative Enforcement


One of the nice parts of the CFATS program is that ISCD really is working with facilities to get site security plans formalized. To understand why, you just need to look at the most basic restriction that ISCD is operating under; they are forbidden by Congress {6 USC 622(c)(1)(B)(i)} from specifying security measures that facilities must employ.

In practice, this means that the approval of the SSP by ISCD is really a negotiating process. The facility proposes a set of security measures and ISCD determines whether or not those measures meet the RBPS criteria for the Tier Level to which the facility is assigned. ISCD then explains any deficiencies and the facility attempts to remedy them. In the early days of the program this could end up being a rather lengthy process. Fortunately, the CSI now have enough experience with facility security plans, so that they can provide suggestions about what has worked at other facilities.

Once the SSP is approved by ISCD the relationship changes to something more approaching a typical agency private sector relationship as the SSP becomes an enforceable set of standards against which compliance can be measured. I suspect, however, that the relationship will still have more cooperative overtones than with most government agencies because of the relatively stable assignment of CSI to responsibility for a small number of facilities. This allows for a better understanding of facility issues and a closer working relationship.

Cybersecurity


One thing that this new facility was told during their compliance assistance visit was to make sure that they took a good hard look at their cybersecurity planning. As one could expect, ISCD is taking its cue from much higher up the ladder at DHS in focusing on cybersecurity issues.

I reminded my caller that the facility has a relatively large degree of discretion when it defines the portion of the facility which is covered by the CFATS program. For facilities with release risk chemicals of interest (COI) there may be no need to include business IT systems in the CFATS perimeter if they have no effect on the security of the COI at the facility. This is yet another good reason for carefully segmenting the different cyber-networks at a facility.

I also suggested to my reader that they take a good look at using the Cybersecurity Evaluation Tool (CSET) to help evaluate the security of their control systems. The newest versions of this tool from ICS-CERT includes specific CFATS related questions that can be used to help formulate the cybersecurity portion of SSP. The use of CSET does not provide a free pass on the RPBS 8 (cybersecurity) requirements, but it can be a helpful tool.

Other Conversations


I am always interested in talking about chemical facility security with just about anyone involved in the field. My contact information is available on my blog or LinkedIn. I do have a day job with a variable schedule that sometimes makes it challenging to schedule a phone call, but I am certainly willing to make the effort.

PHMSA Publishes Hurricane Recovery Waivers

The DOT’s Pipeline and Hazardous Material Safety Administration (PHMSA) published three Hazardous Materials Regulations (HMR) waivers in Monday’s Federal Register (82 FR 44696-44697, 82 FR 44699-44700, and 82 FR 44697-44698; available on-line today). These waivers are in support of the Environmental Protection Agency’s clean-up efforts for Hurricane Harvey and Hurricane Irma.

The Waivers


Each waiver identifies the areas affected based upon President Trump’s emergency declarations for Texas and Louisiana (Waiver #1); Florida, Puerto Rico, South Carolina and the Virgin Islands (Waiver #2); and Georgia (Waiver #3). The waiver only applies to the specific areas identified in those declarations and their subsequent amendments.

Each waiver provides that: “non-radioactive hazardous materials may be transported to staging areas within 50 miles of the point of origin. Further transportation of the hazardous materials from staging areas must be in full compliance with the HMR.” Each waiver remains effective for 30 days from September 1st (Waiver #1), September 8th (Waiver #2), or September 10th, 2017 (Waiver #3).

Commentary


I do not recall seeing these types of waivers after previous hurricanes. They certainly seem like a good idea. It provides the EPA with some amount of flexibility in how they structure their recovery efforts to isolate and remediate unsafe hazardous materials that are found during their cleanup efforts.

Unfortunately, I can find nothing on the EPA’s web sites about the establishment of the collection points mentioned in these waivers. Neither the latest news release for Maria and Irma recovery, nor the hurricane specific web sites for Maria and Irma (NOTE: There is apparently no similar site for Harvey) contain any mention of the PHMSA waivers or collection points. This is particularly unhelpful as the PHMSA waivers quickly approach their expiration.


It seems that the Federal government still has some lessons to learn in handling the coordination of their response activities (and the publication of those activities) within the government.

Friday, September 22, 2017

ICS-CERT Publishes 5 Advisories

Yesterday the DHS ICS-CERT published five control system security advisories for products from Schneider, Ctek, Digium, iniNet Solutions, and Saia Burgess Controls. The advisory for the products from Saia Burgess Controls was originally posted to the NCCIC Portal on August 22, 2017.

Saia Burgess Controls Advisory


This advisory describes an information exposure vulnerability in the Saia Burgess Controls PCD Controllers. The vulnerability was reported by Davide Fauri of Eindhoven University of Technology. The latest version of the firmware mitigates the vulnerability. There is no indication that Fauri has been provided an opportunity to verify the efficacy of the fix.

ICS-CERT reports that a relatively low skilled attacker could remotely exploit the vulnerability to to obtain information in memory.

The SBC upgrade notes also report that the current version makes the following security changes:

• Protective functions are activated by default;
• Improved password protection associated with the role-based user management;
• Access filter using "white" and "black" lists;
• Removed hardcoded password [NOT mentioned in ICS-CERT advisory].

Similar changes were also apparently made to the SBC PG5 Controls Suite.

iniNet Solutions Advisory


This advisory describes an improper authentication vulnerability in the iniNet Solutions SCADA Webserver. The vulnerability was reported by Matthias Niedermaier and Florian Fischer, both of Augsburg University of Applied Sciences. iniNet has released a new version that allows users to implement basic authentication. There is no indication that the researchers were afforded an opportunity to verify the efficacy of the fix.

ICS-CERT reports that a relatively low skilled attacker could remotely exploit the vulnerability  to access human-machine interface (HMI) pages or to modify programmable logic controller (PLC) variables without authentication.

Digium Advisory


This advisory describes an OS command injection vulnerability in the Digium Asterisk GUI. The vulnerability was reported by Davy Douhine of RandoriSec. Asterisk GUI is no longer maintained and should not be used. Digium recommends affected users to migrate to Digium’s SwitchVox product.

ICS-CERT reports that a relatively low skilled attacker could remotely exploit the vulnerability  to execute arbitrary code on the device.

Interesting Questions: Would owners of a control system that uses an HMI configured with Digium’s Asterix GUI even know that it had been used, particularly if the system had been designed by a contractor or vendor? Would it take a complete system redesign to change out the GUI for an HMI?

Ctek Advisory


This advisory describes an improper authentication vulnerability in the Ctek SkyRouter. The vulnerability was reported by Maxim Rupp. The latest firmware version mitigates this and “additional security requirements”. NOTE: “Ctek, Inc., reports that due to industry demand, wireless carriers are rapidly eliminating 2G and 3G CDMA service and they will not be creating any additional update releases for those products.” There is no indication that Rupp was provided an opportunity to verify the efficacy of the fix.

ICS-CERT reports that a relatively low skilled attacker could remotely exploit the vulnerability to view and edit settings without authenticating.

Schneider Advisory


This advisory describes a missing authentication for critical function vulnerability in the Schneider InduSoft Web Studio products. The vulnerability was reported by Aaron Portnoy, formerly of Exodus Intelligence. Schneider has created a patch to mitigate the vulnerability. There is no indication that Portnoy was provided an opportunity to verify the efficacy of the fix.

ICS-CERT reports that a relatively low skilled attacker could remotely exploit the vulnerability  to remotely execute arbitrary commands with high privileges.


NOTE: The Schneider security bulletin was published last Friday. Maybe Dale Peterson was right, it looks like ICS-CERT is doing ‘ICS-vuln Thursday’.

Thursday, September 21, 2017

S 1800 Introduced – DOD Electric Grid Security

Last week Sen. Warren (D,MA) introduced S 1800, the Securing the Electric Grid to Protect Military Readiness Act of 2017. The bill is nearly identical to SA 867, Warren’s proposed amendment to HR 2810 on the same topic. It addresses efforts to protect the electrical distribution systems on military installations.

Moving Forward


Warren is a member of the Senate Armed Services Committee to which this bill was referred for consideration. This means that she may have enough influence to have the Committee consider the bill.

I do not see anything in this bill that would engender any significant opposition. If the bill were to be considered it would be likely to pass with at least some bipartisan support.

Commentary


There is nothing in this bill that directly addresses cybersecurity concerns for the industrial control system associated with military power distribution systems. A lot of the language seems to be IT-centric (for example: “to deny access to or degrade, disrupt, or destroy an information and communications technology system or network” {§2(c)(4)(A)} in the definition of ‘significant malicious cyber-enabled activities’).


I doubt that DOD would fail to address ICS security issues in the required studies and reports, but it would certainly be helpful if the bill specifically addressed requirements for ICS security considerations. I suspect that the failure to do so reflects a continued failure on the part of Congress to recognize the different issues involved with ICS security.

Wednesday, September 20, 2017

Senate Passes HR 2810 – FY 2018 NDA

On Monday the Senate passed HR 2810, the FY 2018 National Defense Authorization Act (NDAA) by a strongly bipartisan vote of 89 to 8; even the opposition was bipartisan with three Republicans, four Democrats and one Independent voting Nay.

Of all of the amendments that I discussed in my series of blog posts over the last two weeks, only three were adopted:

• Reed (for Kaine) Amendment No. 1089, to establish opportunities for scholarships related to cybersecurity.
• McCain (for Portman) Amendment No. 712, to require a plan to meet the demand for cyberspace career fields in the reserve components of the Armed Forces.
• McCain (for Portman) Amendment No. 1055, to require a report on cyber applications of blockchain technology.

They were all considered as part of an en bloc amendment [pgs S5787-8] offered by Sen. McCain (R,AZ) at the end of the final debate on HR 2810. The en bloc amendment was adopted by unanimous consent [pg S5796].


Since there are significant differences between the versions of this bill passed in the House and Senate, it is very likely that there will be a conference committee appointed. There is, however, a very slight chance that the House will agree to the Senate amendment to the bill when it returns from their week working in their districts.

Tuesday, September 19, 2017

ICS-CERT Publishes PHOENIX CONTACT Advisory

Today the DHS ICS-CERT published a control system security advisory for products from PHOENIX CONTACT. They also provided a link to a British publication: “Code of Practice CyberSecurity for Ships”.

PHOENIX CONTACT Advisory


This advisory describes ten improper access control vulnerabilities in the PHOENIX CONTACT mGuard Device Manager. The vulnerabilities are related to the Oracle Java SE implementation in the product. These vulnerabilities were self-reported by PHOENIX CONTACT. They have a new version that mitigates the vulnerabilities.

ICS-CERT reports that a relatively low skilled attacker could remotely exploit these vulnerabilities to allow unauthorized remote access, modification of data, and may allow remote and local users to gain elevated privileges.

Once again, we see a vulnerability caused by third party software and there is an open question about what other software systems have the same vulnerabilities. Interesting though that these 10 Oracle vulnerabilities are all dated in 2017. Makes it even more likely that other vendors using the same Oracle software will have not discovered/mitigated the vulnerabilities in their products.

Cyber Security for Ships



The code of practice document was produced for the British Government by the Institution of Engineering and Technology. It provides a high-level overview of the topic including an interesting overview of the threat environment for the shipping industry. Appendix D provides a non-technical description of how mitigation measures can be developed and Appendix H provides a lengthy bibliography of cybersecurity standards for both IT and operational systems.
 
/* Use this with templates/template-twocol.html */