Monday, August 21, 2017

Chlorine Incident Kills Two

This weekend there was an unusual incident in Mississippi where an auto accident involved a rural water treatment works. It resulted in the breach of a chlorine gas cylinder and the death of the two occupants of the car. As is usual, the details about the accident are sketchy, but with the help of Google Maps® and some industry knowledge, we can ferret out some lessons.

The Facility

The news article reports that two people were in a stolen car driving down a rural road when the “car slammed into the utility station, rupturing a large tank of chlorine”. In rural America, the only kind of ‘utility station’ that houses chlorine gas is a local drinking water pumping station. Searching Google Maps we can find that utility station here, on the west side of the road.

Looking at it on Street View®, we see a large, white, horizontal tank within a chain-link fenced enclosure. There is a small box-like structure, a pipe, a well-pump and an electric service pole with a nearby electrical panel.

I suspect that the reporter thought that the large white tank was a chlorine tank, but that is certainly not the case. First off, that tank is way too large; it would contain multiple years’ worth of chlorine gas for a facility this size. Second, chlorine gas is delivered in portable cylinders. For a facility of this size, that is typically a 50-pound cylinder that looks somewhat like a welding-gas cylinder. Two such cylinders will be found in the white box to the right of the tank; the one in current use and the backup for when the first is emptied. By the way, that large tank is a water tank, providing the pumping station with surge capacity.

The Accident

Looking at the map, I would guess that the car was proceeding north on Palmer Creek Drive, probably at a high-rate of speed. Instead of making the curve to the right, it continued straight and hit the large water tank. As part of the collision either the chlorine control box, or more likely the chlorine gas line from the box to the water system was damaged, releasing a small yellowish green cloud of chlorine into the atmosphere. It is not clear (and will not be until the autopsies are complete) if the chlorine gas, the injuries from the collision of a combination of the two caused the deaths of the occupants of the car.

There were chlorine gas related injuries to ‘several responding deputies and at least one fire fighter’. The Street View data is from 2013 and I cannot see any chlorine gas warning signs. It is quite possible that deputies responding to the accident did not know about the chlorine gas at the facility and approached the scene too closely. Fortunately, the small cloud would have dispersed enough to leave it a less-than-deadly concentration that they walked into, so the injuries were reportedly fairly minor.

Local residents were instructed to shelter-in-place in an abundance of caution. Again, with the small amount chlorine gas present, there was almost certainly no more danger at nearby residences than would be found in sniffing at the top of an open household bleach container.


Since the incident happened on Saturday night it was almost certainly a joy-riding accident. If it had happened twelve hours later, there would have been a very remote chance of it being an attack. There is a church located next to the treatment works it would have been remotely possible that the incident was an inept attempt to gas the congregation.

It would have been fairly easy to accomplish that type of attack by entering the facility with a pair of bolt cutters and a pipe wrench. But, again, releasing the chlorine gas at the facility would have resulted in a less than deadly gas cloud at the church, even if the breeze was blowing in the correct direction.

Of course, an even more effective attack could have been executed by removing the gas cylinders from the facility and then piping the connection into any sort of facility air-handling equipment that the attackers desired. Depending on the size of the facility, a lethal concentration of chlorine gas could possibly be introduced fast enough to cause some deaths. A large number of serious injuries and panic could certainly be an expected result.

There are no requirements under either the EPA water facility security regulations or the DHS Chemical Facility Anti-Terrorism Standards for physical security of the chlorine tanks at facilities of this sort; the facilities are just too small to make regulations cost effective. As is fairly typical, the padlocked gate on the chain-link fence and a padlock on the chlorine control box are the only security measures in place. Even if video surveillance or intrusion detection devices were in place, the response time to such rural locations is long enough to allow perpetrators to successfully leave the facility.

Saturday, August 19, 2017

Bills Introduced – 08-18-17

Yesterday, both the House and Senate met in pro forma sessions. There were ten bills introduced, including one in the Senate. Senate rules do not normally allow for bill introductions during pro forma sessions, but an exception was made in this case. Interestingly, that is one bill that may be of specific interest to readers of this blog:

S 1761 An original bill to authorize appropriations for fiscal year 2018 for intelligence and intelligence-related activities of the United States Government, the Community Management Account, and the Central Intelligence Agency Retirement and Disability System, and for other purposes. Sen. Burr, Richard [R-NC]

As is usual with authorization bills, I will be watching this for cybersecurity mentions.

Thursday, August 17, 2017

ICS-CERT Publishes an Advisory and Three Updates

Today ICS-CERT published a medical device security advisory for products from Philips. Three previously published industrial control system security advisories for products from Siemens (2) and Marel were updated with new information.

Philips Advisory

This advisory describes two vulnerabilities in the Philip DoseWise Portal (DWP) web application. The vulnerability was self-reported by Philip. ICS-CERT is reporting that Philip will be supplying a new product version later this month to mitigate the vulnerability.

ICS-CERT reports that an uncharacterized attacker could remotely exploit these vulnerabilities to gain access to the database of the DWP application, which contains patient health information (PHI). Potential impact could therefore include compromise of patient confidentiality, system integrity, and/or system availability.

NOTE: the Philips security page notes that the discovery of these vulnerabilities was based upon the findings of a customer submitted complaint and vulnerability report.

Marel Update

This update provides additional information on an advisory that was originally published on March 4th, 2017. The new information includes:
• Clarification of affected equipment;
• Adds a notice of an upcoming (10-1-17) update for the Pluto based systems;
• Explains that the M3000 terminal based products reached the end of their supported life in 2012;
• Added a new improper access control vulnerability to the advisory; and
• Added a link to the recently published Marel security notification

Comment: In the original advisory, the stand-alone statement “Marel has not produced an update to mitigate these vulnerabilities” seemed to indicate that Marel was not being cooperative. It now seems more that they were being slow to move forward and perhaps did not understand the need to communicate with ICS-CERT. Either that, or the publication of the ICS-CERT advisory was a slap in the corporate face that woke Marel up and got them to work on the vulnerability. I cannot tell which (properly so) from the ICS-CERT publication. In either case mitigations appear to be on the way.

It might be helpful if ICS-CERT had some sanction available that could provide some sort of intermediate push between doing nothing and publishing a zero-day that could put system owners at risk. The goal is to get a mitigation in place as soon as practicable and ICS-CERT has no authority to provide impetus to require recalcitrant vendors to do something.


This update provides additional information on an advisory that was originally published on May 9th, 2017 and updated on June 15th, 2017, on June 20th, 2017, on July 6th, 2017, and again on July 25th, 2017. The update provides new affected version information and mitigation links for:

• STEP 7 - Micro/WIN SMART: All versions prior to V2.3;
• SIMATIC Automation Tool: All versions prior to V3.0; and
• SINUMERIK 808D Programming Tool: All versions prior to V4.7 SP4 HF2


This update provides additional information on an advisory that was originally published on May 9th, 2017 and updated on June 15, 2017, and again on July 25th, 2017. The update provides new affected version information and mitigation links for:

• SIMATIC CP 1543SP-1, CP 1542SP-1 and CP 1542SP-1 IRC: All versions prior to  V1.0.15,
• SIMATIC ET 200SP: All versions prior to  V4.1.0,
• SIMATIC S7-200 SMART: All versions prior to V2.3,
• SINUMERIK 828D – V4.5 and prior: All versions prior to V4.5 SP6 HF2

Missing Siemens Updates and Advisories

ICS-CERT has yet to publish update or advisory for the following TWITTER® announcements from Siemens:

An advisory has been updated: SSA-286693: Vulnerabilities in Laboratory Diagnostics Products from Siemens; Aug 7th, 2017;

A new advisory has been published: SSA-131263: SMBv1 Vulnerabilities in Mobilett Mira Max from Siemens Healthineers; Aug 7th, 2017

NHTSA Sends Automated Vehicle Guidance to OMB

Yesterday the DOT’s National Highway Transportation Safety Administration (NHTSA) sent their Voluntary Guidance on Automated Driving Systems document to the OMB’s Office of Information and Regulatory Affairs (OIRA) for review. Guidance documents are not normally described in the Unified Agenda, so there is no public indication about what DOT will be including in this guidance document.

NHTSA hosted a series of public discussions on the topic last year. They also published an automated vehicles technology guidance document and a vehicle-to-vehicle notice of proposed rulemaking (NPRM) last year. The later document did include cybersecurity requirements.

Wednesday, August 16, 2017

Make America Secure and Prosperous Appropriations Act, 2018

The House Rules Committee announced today that is working on massive, multi-department spending bill to be considered when the House returns from summer recess. It is a move to cut short the spending process so that there may be a chance to pass a government spending bill before the September 30th deadline. The Rules Committee is calling for submission of amendments by 10:00 am on August 25th.

The combined bill is a complete re-write of HR 3354, the Department of the Interior, Environment, and Related Agencies Appropriations Act, 2018. The draft language incorporates most of the language from that bill and:

HR 3268 – Agriculture, Rural Development, Food and Drug Administration, and Related Agencies Appropriations Act, 2018;
HR 3267 – Commerce, Justice, Science, and Related Agencies Appropriations Act, 2018;
HR 3280 – Financial Services and General Government Appropriations Act, 2018;
HR 3355 – Department of Homeland Security Appropriations Act, 2018;
HR 3358 – Departments of Labor, Health and Human Services, and Education, and Related Agencies Appropriations Act, 2018;
HR 3362 – Department of State, Foreign Operations, and Related Programs Appropriations Act, 2018; and
HR 3353 – Transportation, Housing and Urban Development, and Related Agencies Appropriations Act, 2018

The House has already passed a combined spending bill for the other four spending bills not covered above. That bill, HR 3219, included the following spending bills:

• The Department of Defense Appropriations Act, 2018;
• The Legislative Branch Appropriations Act, 2018;
• The Military Construction, Veterans Affairs, and Related Agencies Appropriations Act, 2018; and
• The Energy and Water Development and Related Agencies Appropriations Act, 2018.

Combining eight spending bills into one big package could greatly reduce the amount of time required on the floor of the House for debate. I expect the Rules Committee would come up with a structured rule, with a few hundred floor amendments. The bill would almost certainly be passed in the House in a single week. The big question is whether or not the Senate would be allowed to take up the giant bill. Depending on what riders make it into the House passed version, I could almost expect to see an unusual amalgam of liberals and conservatives combining to block the moderate majority from considering and passing the bill.

ICS-CERT Publishes Two Advisories

Yesterday the DHS ICS-CERT published a medical device security advisory for products from BMC Medical and 3B Medical (one advisory). They also published a control system security advisory for products from Advantech

BMC Medical Advisory

This advisory describes an improper input validation vulnerability in the Luna continuous positive airway pressure (CPAP) therapy machine produced jointly by BMC Medical and 3B Medical. The vulnerability was reported by MedSec. Newer versions (after July 2017) have had the problem corrected; ICS-CERT reports that the company’s do not plan on providing mitigation measures for ‘older’ (before July 2017) machines.

ICS-CERT reports that a relatively low skilled attacker with adjacent network access could exploit the vulnerability to cause a crash of the device’s Wi-Fi module resulting in a denial-of-service condition affecting the Wi-Fi module chipset. This does not affect the device’s ability to deliver therapy.

NOTE: Buyers of CPAP devices should take careful note of the lack of post-production cybersecurity support demonstrated for this brand of devices.

Advantech Advisory

This advisory describes a heap-based buffer overflow vulnerability in the Advantech WebOP operator panels. The vulnerability was reported by Ariele Caltabiano (kimiya) via the Zero Day Initiative. ICS-CERT reports that Advantech was unable to verify the validity of this vulnerability. (NOTE: this obviously means that no mitigation measures appear to be forthcoming.)

ICS-CERT reports that a relatively low skilled attacker with uncharacterized access could use publicly available exploits to exploit this vulnerability to cause the target device to crash and may allow arbitrary code execution.

NOTE: There are a large number of ‘pending’ vulnerability reports on Advantech products currently listed on the ZDI web site.

Tuesday, August 15, 2017

ISCD Updates CFATS Knowledge Center

Today the DHS Infrastructure Security Compliance Division (ISCD) updated the Chemical Facility Anti-Terrorism Standards (CFATS) Knowledge Center by adding a link to a new CFATS fact sheet for colleges and universities and revised four frequently asked questions (FAQ) (according to the ‘Latest News’ blurb posted today on the Knowledge Center).

Colleges and Universities

The Colleges and Universities brochure is an update of a tri-fold brochure that was originally published in December 2010. The new brochure provides a brief overview of the CFATS program including a very brief description of the Top Screen reporting requirements. There is more detail in the new version and provides a number of important links to CFATS documents.

The one major shortcoming of the brochure is that, while it briefly describes chemicals of interest (COI) categories and explains that the list can be found in ‘Appendix A of the CFATS regulation’ there is no link to list of COI that is provided on the CFATS landing page, nor are the CFATS regulations actually listed (6 CFR 27).

New FAQs

The four ‘revised’ FAQ’s are:

The revised #1274 removes the mailing address [Infrastructure Security Compliance Division, Office of Infrastructure Protection, ATTN: CSAT, Department of Homeland Security, Building 5300, MS 6282, PO Box 2008, Oak Ridge, TN 37831-6282] and the messenger service delivery address [Infrastructure Security Compliance Division, Office of Infrastructure Protection, ATTN: CSAT, Department of Homeland Security, Building 5300, MS 6282, 1 Bethel Valley Road, Oak Ridge, TN 37831-6282] from the modes of contact for the CFATS Help Desk. I have no idea whether or not those old addresses are still good; but if they are, ISCD does not apparently want them used.

The revised #1288 adds regulatory references [§27.203(b) and §27.204(a)(2)] for the answer and a link to just the first reference. I have provided the link to the second.

FAQ #1606 is actually a new FAQ number, but the question and answer are very similar to an older FAQ (#1662) which is no longer on the current FAQ list (.PDF download). The new FAQ does not include any information (which was included in #1662) about a requirement to be CVI (Chemical-terrorism Vulnerability Information – the protocol for protecting the sensitive but unclassified information associated with the CFATS program) trained to be able to view/download the letter. Nor does the new FAQ mention that an Adobe Reader will be necessary to open the letter. NOTE: #1662 was still on the current FAQ list as of 8-4-17; the last time changes were made to the FAQ list.

FAQ #1785 is also a new FAQ number. There was an earlier article on the CFATS Knowledge Center (#1610) that addressed some of this information, but that article was prepared in 2010 and included copious descriptions of the old tiering process that was supplanted by CSAT 2.0 and the new Risk Assessment process. That article was removed sometime in early April of this year. The new FAQ very briefly mentions the tiering process and notes that facilities will be notified via the Chemical Security Assessment Tool (CSAT) that a tiering notification letter is available. It then briefly describes how to access that notification letter; and this time that discussion does include a mention of the CVI training requirements.

HR 3401 Introduced – Automated vehicles

Last month Rep. Schakowsky (D,IL) introduced HR 3401, a bill that would require the DOT’s National Highway Transportation Safety Administration (NHTSA) to establish new automotive safety standards for highly automated vehicles. This bill was introduced the same day that the House Energy and Commerce Committee  amended HR 3388 to do the same thing.

This bill is nearly identical to Section 4 of the revised HR 3388 adopted by the Committee. There is one area where the paragraph numbering is slightly different, but there are no substantive differences between the requirements. It would amend 49 USC by adding a new §30129, Updated or new motor vehicle safety standards for highly automated vehicles.

It would require DOT to “issue a final rule requiring the submission of safety assessment certifications regarding how safety is being addressed by each entity developing a highly automated vehicle or an automated driving system” {new §30129(a)(1)}.

It would also require DOT to submit to Congress a regulatory and safety priority plan designed to accommodate the development and deployment of highly automated vehicles while ensuring “the safety and security of highly automated vehicles and motor vehicles and others that will share the roads with highly automated vehicles” {new §30129(c)(1)}. That plan would include a requirement for NHTSA to “identify elements that may require performance standards including human machine interface and sensors and actuators, and consider process and procedure standards for software and cybersecurity as necessary” {new §30129(c)(2)(B)}.

Moving Forward

Ms. Schakowsky is the ranking member of the Digital Commerce and Consumer Protection Subcommittee of the House Energy and Commerce Committee. Normally this would probably allow her to have this bill considered in Committee. In this case, however, because this bill was introduced the same day that HR 3388 was, it seems as is the bill was introduced as a backup measure to ensure that the safety standards provisions of this bill could end up being considered separately from the remainder of the provisions of the larger bill if that bill was determined to be too controversial to be considered on the floor of the House.

I suspect that this bill will not see any further action until the House Leadership determines whether or not HR 3388 will make it to the floor. If it does not, this bill will likely be moved to the floor for a vote without going through a separate review by the Committee.


I did not mention the cybersecurity requirements described above in my discussion of HR 3388 because they were duplicative of the requirements that I described but were not as expansive as the cybersecurity requirements in §5 of HR 3388.

What is important (and unusual from a cybersecurity perspective) here is that both bills would require the establishment for safety standards for HMI, sensors and actuators. It does not include any guidance on what those standards would include, but that would normally be expected to be developed by the technical experts at NHTSA. But this would end up being where the Federal government took its first crack at developing safety (and perhaps specific cybersecurity) standards for key components found in (almost by definition) these critical components of control systems. Those standards could end up being ground breaking regulatory standards for the ICS industry.

Monday, August 14, 2017

OMB Approves PHMSA Shipping Papers ICR Revision

Last Friday the OMB’s Office of Information and Regulatory Affair approved the Pipeline and Hazardous Materials Safety Administration’s (PHMSA) information collection request (ICR) revision supporting requirements for hazardous material shipping papers and emergency response information. This ICR was filed in support of the most recent international harmonization of PHMSA hazardous material shipping regulations.

According to the abstract included in the recent notice, the ICR made the following changes to the ICR burden:

“This rulemaking reduced the burden to shippers by removing the requirement to provide a lithium battery handling document when shipping smaller lithium cells and batteries. While the rulemaking decreased the burden overall, the requirement that shippers communicate prototype or low production run battery shipments on a shipping paper resulted in an increase. The rulemaking also added new marine pollutant entries in Appendix B of § 172.101.”

While OIRA did not require any changes to the approved ICR, they did put PHMSA on notice about additional requirements that would be necessary for the next renewal of this ICR next spring. They noted that:

If PHMSA has not published a regulatory notice in the Federal Register seeking public comment on paperless hazard communication by the time PHMSA must publish a 60 day notice to extend OMB approval of this collection, PHMSA should include at least the following information in the 60 and 30 day notices for extending approval of this collection, in addition to the standard information required by the PRA:

• Identification and explanation of any technical and other barriers to paperless hazard communication by mode and environment (e.g., rural, urban) if applicable, and requests for public comment on ways to address those barriers;
• Identification and explanation of any safety problems associated with paperless hazard communication that are not present with paper-based hazard communication;
• Identification of safety, business and any other benefits associated with paperless hazard communication, by mode if possible; and
• At least rough estimates of the potential burden and cost reduction from fully allowing paperless hazard communication, by mode if possible, the methodology/inputs for the estimates, and request public comment on those estimates.

PHMSA will probably have to publish the 60-day ICR notice in the next couple of months to be able to get the comment period and time to review the responses before it becomes necessary to publish the 30-day notice before April 30th, 2018.


This is not the first time that the Trump Administration’s OIRA has provided instructions to regulators to proactively move to electronic submission of information. This continues a regulatory theme that we have been seeing for the last couple of administrations. Not only will the electronic data collection reduce the data handling costs for the government, but it should provide at least some time burden reduction for industry.

As with my earlier post this morning, I do have some concerns about the cybersecurity protections for the data exchange process. If the data is submitted via email (a not very effective form of electronic data submission), this would provide a large number of emails (with attachments) from probably unauthenticated and unknown senders; a very sure method of increasing the general attack surface at PHMSA.

If, on the other hand, the data is directly provided to the database via a public web page, the security of that data can be subverted if the cybersecurity of the database (and the submission page) has not been properly implemented. More importantly, the cybersecurity protections need to be included in the design of the application and periodically reviewed and updated. This is an additional cost associated with electronic data submission that appears to be at least some what overlooked in the discussion of paperless government innovations.

EPA Sends Hazwaste Electronic Manifest Final Rule to OMB

On Saturday, the Environmental Protection Agency sent the final rule for the implementation of the Hazardous Waste Electronic Manifest rule to the OMB’s Office of Information and Regulatory Affairs (OIRA) for approval. This bill implements the fee setting and implementation date requirements of the Hazardous Waste Electronic Manifest Establishment Act (PL 112-195).


With the Trump Administration’s concern about the ‘cost of regulation’ and how it effects business, it will be interesting to see how this final rule is being implemented. The congressional requirements for establishing the fund {42 USC 6939g(c)} are fairly comprehensive, leaving little room for fee reductions. There were no small business exceptions provided for in the authorizing legislation.

Since the authorizing legislation was written in 2012, there are no specific provisions requiring any cybersecurity protections of the E-Manifest system. Cybersecurity just was not on the Congressional radar at that point. It will be interesting to see if there are any attempts by the EPA to address such issues in this regulation.

Saturday, August 12, 2017

CG Publishes CSF Profile Document for Passenger Operations

Earlier this week the Coast Guard published on their Home Port web page ( > Cybersecurity > Cyber News > Passenger Operations Cybersecurity Framework Profile Review; sorry the CG does not use links on its HomePort) a new cybersecurity guidance document and requested public comments on the document. The new document is the “Content Preview of the Passenger Operations Cybersecurity Framework Profile”. The Coast Guard’s blog did provide a real link to the document.

The Profile

This document is an attempt by the CG to help affected organizations (US passenger vessel operations) implement the National Institute of Standards and Technology’s (NIST) Cybersecurity Framework (CSF). According to the CG’s blog:

“A profile implements the NIST Cybersecurity Framework, which was developed in 2014 to address and manage cybersecurity risk in a cost-effective way based on business needs and without placing additional regulatory requirements on businesses. The profile is how organizations align the Framework’s cybersecurity activities, outcomes, and informative references to organizational business requirements, risk tolerances, and resource allocations.”

The Profile is a .PDF document that first provides a list of 13 passenger vessel mission objectives with a brief description of each. These objectives include:

• Maintain human safety;
• Maintain marine safety and resilience;
• Maintain environmental safety;
• Maintain guest support and basic hotel services;
• Maintain regulatory compliance;
• Assure secure communications by function and mode;
• Optimize guest experience and value;
• Maintain supply chain and turnaround;
• Disembarking, embarking, and turnaround;
• Coordinate port operations;
• Assure (optimize) lifecycle asset management;
• Maintain passenger information and accounting systems; and
• Manage, monitor and maintain non-guest-facing office technology

The Profile then provides a CSF matrix showing each of the functions, categories and subcategories listed in the CSF with a listing for each of the 13 mission objectives listed above; categorizing them as either ‘High Priority’, ‘Moderate Priority’ or ‘Other Implemented Categories’. It is interesting that they do not use the pejorative term ‘Low Priority’ in the categorization.

Public Comments

The Coast Guard is asking for public comments on the Profile. They have provided a comment submission form (download .XLS) very similar to the format used by NIST to request comments during the development of the CSF. Comments can be emailed to Comments should be submitted by September 7th, 2017.


I really do like the general format of this Profile document. The mission statement provides a general overview of what the affected organizations are supposed to be attempting to accomplish in the operations. Tying that back into the CSF matrix with a prioritization scheme provides a workable management tool for implementation of the CSF.

There are two specific areas where ‘process control systems’ (a very interesting substitute for the term ‘industrial control systems’ that I would typically use) are prominently discussed in the Mission Objective portion of the Profile. First in the description of ‘Maintaining Human Safety’ it starts: “Recognizing cybersecurity-effects on process control systems that impact personnel safety.” Similarly, in ‘Maintain environmental safety’ it addresses cybersecurity effects “on process control systems that impact environmental safety”. Additionally, there are at least two other mission objectives that include mention of “manage support systems security”, a clear reference to various process control systems.

I am more than a little surprised at the prioritization of these ‘process control systems’ in many areas of the CSF implementation matrix, but that may be more of reflection on my lack of familiarity with passenger vessel operations than anything else. I was pleased, however, to see both the human safety and environmental safety objectives receive ‘high profile’ rankings under two of the Risk Assessment subcategories:

ID.RA -3: Threats, both internal and external, are identified and documented; and
ID.RA - 5: Threats, vulnerabilities, likelihoods, and impacts are used to determine risk

Unfortunately, that pleasure was more than offset by the ‘other’ ranking across the board for the “ID.RA -2: Threat and vulnerability information is received from information sharing forums and sources” in the same Risk Assessment Category. That hardly supports the ‘high profile’ rankings noted above.

I really do recommend that everyone with an interest in maritime safety (not just passenger vessels) take a good look at this 16-page document. It provides an interesting perspective on CSF implementation in an often-overlooked area of operations. Likewise, the control system security community (particularly those with maritime experience) should also give the document a good review. The Coast Guard deserves a wide variety in the thoughtful comments it receives on this Profile.

NIST Cybersecurity Workforce RFI Comments – 08-05-17

This is part of a continuing series of blog posts looking at the comments that NIST has received on their request for information (RFI) on cyber workforce development. The comments are posted to the NIST National Initiative for Cybersecurity Education (NICE) web site. The earlier posts in the series were:

This week there were only four new submissions posted to the NIST web site. Those were from:

AT&T pointed at a report that it had helped prepare for the Federal Communications Commission on cybersecurity workforce development in the communication’s sector.

The comments from Southern Utah University pointed at the course outline for their Masters program in Cybersecurity & Information Assurance. They also emphasized the need for academia and industry to cooperate in providing internship/apprenticeship opportunities for students or early career professionals.

The UI LABS – DMDII comments outline work that organization has done looking at the DFARS cybersecurity requirements for DOD contractors. They point out their research points to the problems that many of those contractors are having complying with the 109 cybersecurity requirements outlined in NIST 800-171.

UMass Lowell describes the certification program they have developed for implementation of the NIST Cybersecurity Framework.

Bills Introduced – 08-11-17

Both the House and Senate met in pro forma session yesterday and there were 5 bills introduced. None of those bills were of specific interest to readers of this blog.

The reason that I am making this post today is to bring attention to a little known process in the House; during these pro forma sessions, it is possible to pass legislation. Yesterday two bills were passed, HR 2288 and HR 339. Both of these bills had previously passed in the House, but were amended in the Senate. For whatever reason, the House Leadership determined that it was necessary to pass the bills now while the vast majority of House members were back in their district.

Rep. Comstock (R,VA) asked for unanimous consent for both bills to be considered under the unanimous consent process (a single Nay sounded in the chamber would have killed either bill). The amended versions of both bills were adopted without any objection from the unnamed Democrat that was probably the only other elected representative {besides the presiding acting Speaker Pro Tempore, Rep. Perry (R,PA)}  on the floor of the House chamber.

Now there is nothing untoward or sneaky about Friday’s proceeding. Both bills originally passed with overwhelming support (unanimous vote for HR 2288 and a voice vote for HR 339) in the House and by unanimous consent in the Senate. But it does remind us that even in the dead days of summer in the Capital, legislative action is possible.

Friday, August 11, 2017

ICS-CERT Publishes 5 Advisories

Yesterday the DHS ICS-CERT published five control system security advisories for products from ABB, Fuji Electric, Solar Controls (2), and SIMPlight.

ABB Advisory

This advisory describes a relative path traversal vulnerability in the ABB SREA-01 and SREA-50 remote monitoring tools. The vulnerability was reported by Bertin Jose and Fernandez Ezequiel. HMS Industrial Networks Ab provided a patch to correct the issue, but ABB has only tested it on the SREA-01. These are unsupported legacy products. There is no indication that the researchers have been provided an opportunity to verify the efficacy of the fix.

ICS-CERT reports that a relatively low skilled attacker could use publicly available exploits to remotely exploit the vulnerability to access files on the affected products’ file systems, view data, change configuration, retrieve password hash codes, and potentially insert and send commands to connected devices without authorization.

NOTE: ABB reports that exploit code was published on github by the researchers.

Fuji Advisory

This advisory describes multiple vulnerabilities in the Fuji Monitouch V-SFT screen configuration software. The vulnerabilities were reported by Fritz Sands and kimiya via the Zero Day Initiative. Fuji has released a new version to mitigate the vulnerabilities. There is no indication that the researchers have been provided an opportunity to verify the efficacy of the fix.

The three reported vulnerabilities are:

• Stack-based buffer overflow - CVE-2017-9659;
• Heap-based buffer overflow - CVE-2017-9660; and
• Improper privilege management - CVE-2017-9662

ICS-CERT reports that a relatively low skilled attacker could remotely exploit the vulnerabilities to allow remote code execution or cause the software that the attacker is accessing to crash. The improper privilege management vulnerability could allow an attacker with local access to escalate privileges.

WATTConfig Advisory

This advisory describes an uncontrolled search path element vulnerability in the Solar Controls WATTConfig M Software. The vulnerability was reported by Karn Ganeshen. ICS-CERT reports that Solar Controls has not responded to requests to coordinate with NCCIC/ICS-CERT.

ICS-CERT reports that a relatively low skilled attacker with uncharacterized access could exploit the vulnerability to allow arbitrary code execution.

HCDownloader Advisory

This advisory describes an uncontrolled search path element vulnerability in the Solar Controls Heating Control Downloader (HCDownloader). The vulnerability was reported by Karn Ganeshen. ICS-CERT reports that Solar Controls has not responded to requests to coordinate with NCCIC/ICS-CERT.

ICS-CERT reports that a relatively low skilled attacker with uncharacterized access could exploit the vulnerability to allow arbitrary code execution.

SIMPlight Advisory

This advisory describes an uncontrolled search path element vulnerability in the the SIMPlight SCADA Software. ). The vulnerability was reported by Karn Ganeshen. ICS-CERT reports that Solar Controls has not responded to requests to coordinate with NCCIC/ICS-CERT.

ICS-CERT reports that a relatively low skilled attacker with uncharacterized access could exploit the vulnerability to allow arbitrary code execution.

Thursday, August 10, 2017

Linking Safety and Security

Joe Weiss has an interesting blog post, Why SOCs are not comprehensive enough for ICS cyber security, over on At first glance, it is a re-working of a common complaint of Joe’s, the inability to initially differentiate between control system errors and cyber-attacks; a very important problem in process industries. But Joe points out a very real need to coordinate safety, physical security and cybersecurity activities in the process environment. And that is worth serious discussion.

Joe and I have talked about this on more than a couple of occasions. We both got into the cybersecurity world via the process side of operations; Joe in nuclear power plant engineering and me as a manufacturing process chemist. For both of us, process safety was an important consideration in everything we did.

Safety Reviews

A key tool that we both have used (with a variety of names) is the process hazard analysis, or PHA. In the chemical industry, this is a process for looking at the chemical manufacturing process that employs a step by manufacturing step analysis of a process to identify all of the things that can go wrong.

While techniques vary, each step of the process is looked at. A team of individuals (representing the various areas of expertise involved in a modern manufacturing environment) looks at each process variable (temperature, mixing, pressure, ingredient addition, etc.) to determine what would happen if the variable were changed. If the consequence raises a safety issue, the potential causes of the non-standard situation are identified and compensating controls are identified to prevent the non-standard occurrence. As the potential consequence get worse, the team is required to identify more mitigation measures.

One of the variables that is always included in these reviews is operator error. When there is an extensive process history available (these PHAs are periodically re-done, even if no changes are made to the process), then each of the operator errors that have occurred in the past is specifically include when the appropriate portion of the process is reviewed. Otherwise, the team (which always includes at least one operator and an operations supervisor) looks at what types of operator errors might be expected to be made.

The one operator error that is almost never included is a deliberate attempt by the operator to sabotage the process. This is because it is almost impossible to mitigate this type of ‘operator error’. The only effective mitigation is the implementation of a two-man rule where an operation can only be triggered by operating two physically separated controls nearly simultaneously. This is a very expensive (both in engineering and manpower) and used in only the most extreme situations.

An item that is always included in the list of things that can go wrong is the failure of a piece of process equipment. Pumps, valves, sensor, actuators can all fail and Father Murphy is well known by all process professionals. Common mitigation measures include routine calibration, inspection and schedueled preventative maintenance of process equipment. In situations where equipment failure has the most extreme consequences a common technique is to have parallel processing capability installed where the failed piece of equipment can be bypassed automatically or by simple operator action. Where critical sensors are a concern, multiple and independent sensors are installed and allowable output variations are established.

Security Reviews

Industry has been slower to conduct formal physical security reviews of their facilities. Until 9-11, most such reviews (nuclear power generation facilities excepted) were primarily directed at inventory shrink more than preventing attacks on the facility. Since 9-11 that has changed and there has been more attention paid at preventing terrorist attacks and stopping active shooter situations.

Most physical security reviews (there has not been the level of standardization of security reviews as we have seen with safety reviews) focus on identifying critical portions of the facility and positing what standard attack scenarios are expected and then placing controls in place to deter, delay and detect such events. As in safety reviews, a physical security review increases the mitigation measures employed as the potential consequences (or the probability) of attack increases.

Formal cybersecurity reviews for the process industries are much less common and seem (from the limited data that I have seen) to focus on vulnerability management (patching) and access controls. We are just starting to see implementation of tools to actively monitor process controls to detect intrusions.

Linking Safety and Security

Safety and security have very similar purposes in the process industry, prevention of unintended consequences, particularly hurtful consequences. In very many ways they are two sides of the same coin. Safety protects against random system failures and security prevents system failures caused by deliberate actions. Understanding the potential consequences of any given system failure allows for prioritization of costs and efforts.

Security folks need to have representation on the PHA teams. Not so much for their contributions to safety (though that is an obvious benefit), but so that they can truly understand the critical portions of the process environment. If they understand what the key safety components of the control system are, they may be able to plan a more effective defense-in-depth that provides additional security against intrusion (or more quickly identifies intrusion) into those critical parts of the control system.

Likewise, safety people and process people need to be represented on the security reviews, both physical and cyber (if those are done separately). Their input will be necessary to understand how security measures will impact operations and safety. Planning for a police response to an active shooter incident at a facility handling flammable materials will require careful consideration of safety issues. Allowing for multiple (and contemporaneous) operator logon to controls systems may be necessary. These are just two of the possible operations and safety considerations that need to be accounted for in a security review.

Protecting facilities from incidents that impact operations or the local community is the goal of both safety and security managers. Close cooperation between the two and with the operations team is something that has to take place for all three teams to succeed in supporting a successful business.

Wednesday, August 9, 2017

HR 3435 Introduced – Crude Oil Vapor Pressure

Last month Rep. Lowey (D,NY) introduced HR 3435, a bill that would establish crude oil Reid Vapor pressure standards for the shipment of crude oil by rail. The bill is virtually identical to HR 2379 that was introduced in the 114th Congress. No action was taken on that earlier bill.

The bill would immediately establish a maximum Reid Vapor Pressure limit of 8.5 psi for all crude oil shipped by rail. The DOT would then be required to establish “establish an appropriate national standard for the maximum volatility of crude oil to be permitted to be shipped by rail” {new 49 USC 20169(b)}. No guidance is provided on what would constitute ‘an appropriate national standard’.

Moving Forward

Lowey is not a member of the House Transportation and Infrastructure Committee to which this bill was assigned for consideration, but her co-sponsor {Rep. Garamendi (D,CA)} is. This means that there is a remote chance that the bill could be brought up in Committee. It is highly unlikely that the bill will receive consideration due to oil industry opposition. Since the initial RVP standard set in this bill is the average value reported out of the Bakken oil fields, it would severely reduce oil shipments from those fields (the bills intention).


The fact that this bill would rely on the Trump Administration to establish an ‘appropriate national standard’ without providing legislative guidance on that standard provides a clear indication that this is a pro forma introduction with no expectation that the bill will pass into law. Further, the introduction of the bill just before the summer recess (particularly when it is nothing more than a copy of a previously ignored bill) is a clear indication that Lowey and Garamendi produced the bill to ‘show’ their supporters that they are doing something about crude oil shipments.

As I have mentioned in an earlier post the Reid Vapor pressure test required by this bill has a number of technical problems associated with it. There is a good technical article that describes those problems and more effective test for predicting the problems with the rapid rise in pressure due to fire impingement that has led to some of the overpressure situations seen in some Bakken crude oil train wreck.

I would think that most transportation safety people would agree that some sort of reasonable limit on the vapor pressure of crude oil, particularly a standard related to the rate of pressure rise in a fire impingement situation, would help to reduce some of the incidents of explosive fires that we have seen in some crude oil train incidents. Having said that, the Reid Vapor Pressure testing required by this bill is totally inadequate to that task.

Tuesday, August 8, 2017

ICS-CERT Publishes Two Advisories

Today the DHS ICS-CERT published two control system security advisories for products from Moxa and OSIsoft. I mentioned the OSIsoft vulnerabilities in a blog post last month.

Moxa Advisory

This advisory describes an uncontrolled search path element vulnerability in the Moxa SoftNVR-IA Live Viewer. The vulnerability was reported by Karn Ganeshen. Moxa has developed an update to mitigate the vulnerability. There is no indication that Ganeshen was provided an opportunity to verify the efficacy of the fix.

ICS-CERT reports that an uncharacterized attacker with uncharacterized access could exploit the vulnerability to execute code from a malicious DLL on the affected system with the same privileges as the application that loaded the malicious DLL.

OSIsoft Advisory

This advisory describes two vulnerabilities in the OSIsoft PI Integrator. The vulnerabilities are self-reported. OSIsoft developed new versions of the software to mitigate the vulnerabilities.

The two reported vulnerabilities are:

• Cross-site scripting - CVE-2017-9655; and
• Improper authorization - CVE-2017-9653

 ICS-CERT reports that a relatively low skilled attacker could remotely exploit the vulnerabilities to gain privileged access to the system. An attacker may also be able to store a malicious script in the application database.

BTW: Siemens published a new advisory and updated two advisories yesterday (notification on TWITTER® here, here, and here). I had kind of expected ICS-CERT to report on these today. Maybe tomorrow….

Monday, August 7, 2017

S 1662 Introduced – FY 2018 CJS Spending

Last month, Sen. Shelby (R,AL) introduced S 1662, the Commerce, Justice, Science, and Related Agencies (CJS) Appropriations Act, 2018. The bill does not specifically mention cybersecurity, but there are a number of places in the Committee Report on the bill that address cybersecurity issues.

DOC Cybersecurity

Most of the Department of Commerce (DOC) cybersecurity funding is made through the National Institute of Standards and Technology (NIST). Thus, it is not surprising that all of the Committee cybersecurity comments are related to NIST. The Committee comments that:

• NIST cybersecurity spending remains constant and “NIST is encouraged to update and enhance the NIST Cybersecurity Framework” (pg 21);
• No less than $33,000,000 is provided for the expanded National Cybersecurity Center of Excellence (NCCoE); (pgs 21-2);
• NIST shall provide a detailed accounting for the NCCoE’s budget and activities in its fiscal year 2018 spend plan (pg 22); and
• The Committee provides up to $2,000,000 to develop an IoT cybersecurity research initiative; the initiative shall seek to improve security of IoT devices in consumer and industrial settings (pg 22).

DOJ Cybersecurity

The situation in the Department of Justice is quite a bit different, with a number of agencies having cybersecurity responsibilities. In general, “the Committee directs the Department to maintain its cybersecurity posture at no less than the fiscal year 2017 level to defend and respond to current and emerging attacks that threaten its own infrastructure and activities” (pg 60). Additionally, the Committee provided specific guidance:

• The Committee increased the spending for the United States Attorney’s Office (USAO) by $4.9 million above the requested amount;
• The increased spending will all the USAO to “provide the high-caliber level of training on cybercrime and digital evidence needed for Assistant U.S. Attorneys to be able to analyze and present digital evidence across all types of criminal cases” (pg 69).
• After noting that the “FBI remains the only agency with the statutory authority, expertise, and ability to combine counterterrorism, counterintelligence, and criminal investigatory resources to neutralize, mitigate, and disrupt illegal domestic computer-supported operations” (pg 74), the Committee provided programmatic increases for cybersecurity activities throughout the FBI;
• The Committee provided $1 million “for the continuation of a Cybercrime and Digital Evidence • Resource Prosecutor Pilot Program to provide State and local prosecutors with training and trial experience in cybercrimes and digital evidence” (pg 92); and
• The Committee provided $1 million “to establish a partnership with an institution for higher learning for the purposes of furthering educational opportunities for students training in computer forensics and digital investigation” (pg 92).

NSF Cybersecurity

The Committee continued funding for cybersecurity research at current levels. Additionally, they provided “no less than $55,000,000 for the CyberCorps: Scholarships for Service program” (pg 118. Of that money, $7.5 million was allotted for continued support of “community colleges that have been designated as a Center of Academic Excellence in Information Assurance 2–Year Education [CAE2Y]” (pg 119).

Moving Forward

As with the other spending bills, it is unlikely in the extreme that this bill will be specifically considered in the Senate. It looks like the two Appropriations Committees will be spending their time working out a continuing resolution and a subsequent combined spending bill. As a result, the money amounts mentioned above are very likely to change before the final spending bill is passed.

Energy and Commerce Amends and Passes HR 3388 – DECAL Act

Last month the House Energy and Commerce Committee amended and passed HR 3388, the Designating Each Car’s Automation Level (DECAL) Act, by a strongly bipartisan 54 to 0 vote. The adopted bill was a complete re-write of the original that had been little more than a truth in labeling bill that did not even mention cybersecurity. The new version of the bill establishes cybersecurity requirements for highly-automated vehicles as well as requiring DOT’s National Highway and Traffic Safety Administration to establish new safety standards for the same.

Cybersecurity Requirements

Section 5 of the bill would amend 49 USC by adding a new section, §30130; Cybersecurity of automated driving systems. The new section would require manufacturers to establish cybersecurity plan for ‘highly automated vehicles’ [which “means a motor vehicle equipped with an automated driving system” {revised 49 USC 30102(a)(7)}, see §13(a) of the revised bill]. That plan would include {new §30130(a)}:

• A written cybersecurity policy with respect to the practices of the manufacturer for detecting and responding to cyber-attacks, unauthorized intrusions, and false and spurious messages or vehicle control commands;
• The identification of an officer or other individual of the manufacturer as the point of contact with responsibility for the management of cybersecurity;
• A process for limiting access to automated driving systems; and
• A process for employee training and supervision for implementation and maintenance of the policies and procedures required by this section, including controls on employee access to automated driving systems.

That ‘written cybersecurity policy’ would include {new §30130(a)(1)}:

• A process for identifying, assessing, and mitigating reasonably foreseeable vulnerabilities from cyber-attacks or unauthorized intrusions, including false and spurious messages and malicious vehicle control commands; and
• A process for taking preventive and corrective action to mitigate against vulnerabilities in a highly automated vehicle or a vehicle that performs partial driving automation, including incident response plans, intrusion detection and prevention systems that safeguard key controls, systems, and procedures through testing or monitoring, and updates to such process based on changed circumstances.

Moving Forward

The fact that this bill passed out of committee with unanimous support clearly indicates that the bill is prepared to move forward to the floor of the House for consideration. Typically, I would suggest that it would be considered under the suspension of rules provision allowing limited debate and no amendments. In this case, however, the fact that Committee members also submitted at least nine other bills on the same day that potentially (I have only seen the language on one of those) addressed additional cybersecurity requirements, there may be some resistance to the bill being considered in such a cavalier fashion.

I suspect that the House leadership will come up with one of two solutions to this potential problem. The easiest (politically) would be for the Rules Committee to draft a structured rule that would allow the consideration of amendments based mainly on these other bills to be offered in a limited floor debate. This process, however, would take up substantial floor time, making it unlikely that the bill would be considered before October 1st. It also might result in some amendments being approved that are not supported by the leadership.

If there is substantial political support for moving this forward quickly (and that is unclear at this time), then an alternative scenario would be to include a carefully (read politically) selected number of the additional bills to also be considered under the suspension of the rules process and let their sponsors worry about if there are enough votes to meet the supermajority requirements of that process.


First, I would like to note that the bill completely separates the cybersecurity provisions of §5 from the privacy protection provisions of §12. This is very unusual in that Congress has a long history of equating cybersecurity and privacy protection. What is more interesting is that the privacy protection provisions do not include any mention of using the cybersecurity protections of vehicle systems to protect the privacy of information stored on or developed by those automated driving systems.

To my mind, there are two major cybersecurity shortcomings in this bill; the lack of information sharing provisions and the failure to address vulnerability reporting and coordination.

Given the automotive industry’s history of sharing components between vehicle lines of multiple manufacturers (most recently see the Takata air bag controversy) it would seem very likely that there will be instances where a cybersecurity vulnerability will occur in a device which is found in multiple vehicle lines. Failing to share that information between manufacturers will leave a large number of vehicles vulnerable to known vulnerabilities. I would prefer to see NHTSA as the designated information sharing agency there should be at least a requirement to share information with the Automotive ISAC.

Similarly, given the reality that most cybersecurity vulnerabilities seem to be found by independent security researchers or outside cybersecurity firms, there should be language in this bill providing for an agency to act as a receiver and coordinator of cybersecurity vulnerability information. Again, I would prefer to see NHTSA be given this role, but ICS-CERT would be an acceptable alternative (with information coordination requirements with NHTSA being specified). Using the Automotive ISAC would be a poor choice, since they are likely to take the manufacturers side in any dispute between researchers and vendors.

There is another cybersecurity related provision that I am surprised to see missing from this revised bill, a measure to address recall authority and recall mitigation measures for cybersecurity related problems with the highly automated vehicles. While the requirement for establishing a new safety standard for highly automated vehicles in §4 of the bill would provide general recall authority for cybersecurity related vulnerabilities under existing rules, it would not specifically authorize NHTSA to address cybersecurity vulnerabilities that have not actually resulted in problems in vehicle operations. It also would not provide NHTSA authority to require recalls for purely privacy related cybersecurity issues. To ease industry concerns about cybersecurity recalls, a specific provision allowing for remote updates of cyber systems as a cyber recall measure would need to be included in the bill.

Finally, the bill specifically excludes commercial vehicles from the requirements of the bill. There are significant and very advanced programs to automate commercial trucks. I understand that safety standards for those vehicles are separate from standard automotive safety standards. That means that coverage of those vehicles in this bill would probably be inappropriate from a regulatory standpoint, but I have seen no other attempt to regulate the cybersecurity of those heavier vehicles.

It will be interesting to see if any of these issues are addressed in the nine other bills pending publication by the GPO.

BTW: The revised language approved by the Committee will change the name of the bill from the DECAL Act to the Safely Ensuring Lives Future Deployment and Research in Vehicle Evolution (SAFTE DRIVE) Act. That will take effect when the Committee Report on the bill is published.

Saturday, August 5, 2017

NIST Cybersecurity Workforce RFI Comments – 08-05-17

This is part of a continuing series of blog posts looking at the comments that NIST has received on their request for information (RFI) on cyber workforce development. The comments are posted to the NIST National Initiative for Cybersecurity Education (NICE) web site. The earlier posts in the series were:

There were comments received from 76 different organizations this week, some with multiple submissions. There is no way that I am going to do even a cursory review of that many submissions; I will leave that to the professionals at NIST. Instead I’ll select some of the submissions and hit some high points; all perfectly arbitrary and non-random.

One very important point was made by Anna Johnston from the Information Systems Security
Association (ISSA) in Colorado Springs, CO. She noted that: “Too many businesses are seeking to hire senior cyber personnel to do basic diagnostics, patching, etc., when those tasks can be done by more junior cyber-skilled people.” Everyone wants rock stars to be backup singers. Great if you can afford it, but expect high-turnover.

The Automation Federation asks an interesting question; why isn’t cybersecurity included as a base fundamental skill in every part of our education system? They note: “Little attention is paid to the millions of workers in the middle, who are most likely the ones who need the most knowledge on how to perform their day to day tasks in a cyber secure manner.”

The California Governor’s Office of Emergency Services response addresses an often overlooked aspect of cybersecurity; emergency response. They that California is attempting to develop a strategy “intended to strengthen cyber emergency preparedness and response, standardize implementation of data protection measures, enhance digital forensics and cyber investigative capabilities, deepen expertise among California's workforce of cybersecurity professionals, and expand cybersecurity awareness and public education”.

The Center for Long-Term Cybersecurity (CLTC) points out a long standing problem with government hiring of cybersecurity professionals; the “cumbersome security clearance processes that often cause applicants to lose interest in government jobs before their application process is completed, and security policies that can unnecessarily isolate employees from their social and
professional networks”.

The Energy Sector Security Consortium, Inc. (EnergySec) makes two important points. First the continuing disconnect between IT and OT cybersecurity, noting that:

“Although NICE has a workforce framework, it is not widely used in our industry to identify the security roles or job descriptions. The roles identified in the framework are mostly applicable to traditional Information Technology aspects of business vs. the Operational Technology (e.g. industrial control systems).”

Second, they note the very real need for entry-level jobs “to provide a bridge from the emerging academic programs to mid and senior levels positions”.

While the Security University’s response has a very odd organization it does make a series of interesting points. Very importantly, they note:

“95% of cyber security professionals do not require a cybersecurity degree for a high wage in demand cyber job. They need qualified and validated skills learned from seasoned, skilled cybersecurity professionals with a practicum that demonstrates the student has learned a process and methodology that uses cybersecurity tools and understands enough of the risk policy to determine how to defend based on known threats in order to defend against unknown threats.”

Tenable makes an interesting observation in their response:

“However, our efforts to expand the human workforce will inevitably fall short of the insatiable demand for cyber talent, and we have to prepare for that. We need to have a complementary focus on technology and automation, enabling us to make the most of the human experts we have. Asymmetrically leveraging our cyber talent through the use of technology is the only path to success.”

The Coast Guard response also makes a very important point:

“Cybersecurity training and education must be agile in its planning, assessment, development and delivery cycle to adapt to the speed at which technology drives change and the need to adapt.”

ICS-CERT Publishes Eaton Alert

Yesterday the DHS ICS-CERT published a control system security alert for products from Eaton. The alert describes two buffer overflow vulnerabilities in the Eaton ELCSoft, a PLC programming software for Eaton Logic Control (ELC) controllers. The vulnerabilities were reported by Ariele Caltabiano (kimiya) via the Zero Day Initiative. ZDI has published advisories on these vulnerabilities (here and here) due to the lack of mitigation response from Eaton.

Friday, August 4, 2017

ISCD Publishes New CFATS FAQ

Today the DHS Infrastructure Security Compliance Division (ISCD) added a new frequently asked question (FAQ) to their Chemical Facility Anti-Terrorism Standards (CFATS) Knowledge Center. The new FAQ (#1784) and its associated response deal with whether or not amounts of a DHS chemical of interest (COI) in in transportation packaging needs to be included in the screening threshold quantity (STQ) calculations for a COI if that packaging is on or attached to motive power.

The simple answer is; it depends on the security issue associated with the particular COI. For release COI the answer is clearly, no. This is covered in 6 USC 27.203(b)(1)(ii). But, §27.203(b) only applies to release COI. For theft/diversion COI, however, the answer is yes since §27.203(c) does not include provisions exempting COI in transportation packaging ‘on or attached to motive power’.

The FAQ response does include a reference to the preamble to November 20, 2007 publication of the final rule establishing the CFATS program and Appendix A to 6 CFR Part 27. That reference refers back to the discussion of the calculation of the STQ for release chemicals. It is easy, however, to take that discussion out of context if one just looks at the paragraph on the bottom of page 65398 since that paragraph does contain a specific reference to §27.203(b); that reference was included in the previous paragraph.
/* Use this with templates/template-twocol.html */