Thursday, March 31, 2016

ICS-CERT Publishes ICONICS Advisory

This morning the DHS ICS-CERT published a new advisory for a directory traversal vulnerability in the ICONICS WebHMI. The vulnerability was reported by Maxim Rupp. A new version of the HMI is available, but there is no indication that Maxim was provided the opportunity to verify the efficacy of the fix. ICONICS has also recommended that the vulnerable version of WebHMI not be exposed directly to the Internet.


ICS-CERT reports that a relatively inexperienced attacker could remotely exploit this vulnerability to download arbitrary files from the target system.

Wednesday, March 30, 2016

OMB Approves Contractor Data Security Rule

Yesterday the OMB’s Office of Information and Regulatory Affairs (OIRA) announced that it had approved the new Federal Acquisition Regulation establishing Basic Safeguarding of Contractor Information Systems. As I noted in an earlier post, the rule would add a new subpart and contract clause for the basic safeguarding of contractor information systems that contain, transmit, or process Federal contract information.


This rule would only directly apply to federal contractors operating under FAR based contracts (DOD, NASA, and GSA for instance), but it does establish a precedence for federally established security rules that apply to unclassified IT systems.

PHMSA Announces Oil Spill Response Planning Workshop

Today the DOT’s Pipeline and Hazardous Material Safety Administration (PHMSA) published a meeting announcement in the Federal Register (81 FR 17765-17766) for a public workshop to be held in Washington, DC on April 12th, 2016. The purpose of the meeting is to discuss Oil Spill Response Plans covered by PHMSA’s 49 CFR Part 130 and Part 194 regulations. The meeting will be web cast.

The Notice


The notice does not include an agenda for the meeting; that will be published at a later date on the meeting web site. The notice does explain that the workshop will “bring federal regulators, interested members of the public, industry, and other stakeholders together to share knowledge and experiences with oil spill response planning and preparedness, gather ideas for harmonizing PHMSA’s regulations with other agencies, and discuss practical ways regulated entities can better plan and prepare for an oil spill.”

Public Participation


The meeting and the web cast are both open to the public. Advance registration for attending the meeting in person is recommended because of limited seating. Registration can be completed on the meeting web site.  Written comments may be submitted up to 30 days after the workshop. Comments may be submitted via the Federal eRulemaking Portal (www.Regulations.gov; Docket # PHMSA-2016-0021).

Commentary


As I have mentioned a number of times in this blog, the biggest shortcoming in the oil spill response planning requirements for both PHMSA and the Coast Guard is that they only address the environmental impacts of oil contamination of water ways. While this is certainly an important area of concern, the crude-oil train accidents of the last couple of years have pointed out a serious problem of more immediate safety concern to the public; fires and explosions related to highly hazardous flammable train (HHFT) derailments.

The recent increase in the number and size or unit trains (most commonly crude oil and ethanol, but also other commodity hazardous chemicals) has greatly increased the chance that a hazardous material containing railcar will be involved in any given derailment. With the flammability of ethanol and many varieties of crude oil, the chance of a catastrophic fire related to these derailments has increased dramatically. Most fire departments cannot afford to keep the specialized firefighting equipment on hand to deal with these hazmat fires, especially given the very low chance of occurrence of an HHFT derailment in any particular community.


Federal, State and local governments, along with the railroads and hazmat shippers need to come together to address the increased risk of HHFT derailment fires. This PHMSA workshop should be a good place to start that discussion.

Tuesday, March 29, 2016

ICS-CERT Publishes ICS Medical Advisory

This morning the DHS ICS-CERT published their first ‘medical advisory’ for a whole slew (new technical term) of vulnerabilities in older versions of the CareFusion Pyxis SupplyStation. It appears that ICS-CERT is establishing a separate category of advisories for medical devices; the same information just a separate naming-numbering system.

The Advisory


The advisory outlines (saying ‘describes’ would be a gross exaggeration of terminology) over 1400 3rd-party vulnerabilities in older, unsupported versions of the system still running on Windows Server 2003/XP. The vulnerabilities are categorized based upon their CVSS Base score; CVSS 7.0 – 10.0, 715 vulnerabilities; CVSS 4.0 – 6.9, 606 vulnerabilities; and CVSS 0.0 – 3.9, 97 vulnerabilities.

The vulnerabilities were reported by Billy Rios and Mike Ahmadi in collaboration with CareFusion. The affected systems are at the end of their life and CareFusion does not plan on updating the software. The medical advisory does provide a list of mitigating measures that CareFusion recommends owners of the older devices that remain in use.

Commentary


While a new name and number for these medical device advisories will make it easier for medical-device security-researchers to keep up with advisories that specifically apply to their specialties, ICS-CERT is (for now at least) keeping these advisories listed on the same page as the more traditional control system advisories and alerts. I wonder if we are also going to see a new name for other non-traditional controls systems such as building control systems, security control systems and transportation control systems?

Billy and Mike reportedly used an “automated software composition analysis tool” to identify this huge number of vulnerabilities. I’m assuming that what they did was identify the different software components (see the listing in the medical advisory) and then looked up the vulnerabilities listed for each of the components. Then I would assume that CareFusion confirmed that they had issued no patches for any of the listed vulnerabilities. I wonder if they did the same thing for the various 3rd-party libraries used by the various components? I do hope that Billy and Mike are planning on doing a presentation on this investigation at one of the conferences this year.

This is, HOPEFULLY, an outlier example of the problem of bundling software systems and then attempting (or not attempting as is apparent in this case) with keeping up with all of the patches and updates for the various programs. This may be an extreme example, but I would be that it is not the only product with this problem, either in the medical device category or any other ICS category for that matter.


As a side note, don’t be too quick to chide the Pyxis owners for still using medical devices base upon the outdated Server 2003/XP products. CareFusion has apparently worked with Microsoft to continue supporting their systems past the normal XP end-of-life. Apparently smaller hospitals and other medical facilities with limited equipment budgets use an equipment utilization model that is not uncommon in more traditional automation environments; if it ain’t broke, don’t mess with it.

Monday, March 28, 2016

NTIA Announces Vulnerability Disclosure Meeting – 4-8-16

The Commerce Department’s National Telecommunications and Information Administration (NTIA) published a meeting notice in today’s Federal Register (81 FR 17146) concerning a multi-stakeholder process concerning the collaboration between security researchers and software and system developers and owners to address security vulnerability disclosure. The meeting will be held in Chicago, IL on April 8th, 2016.

This will be the third in a series of meetings. The first two were held last year in September and December. The meeting in April will build on the previous work in an open, transparent, consensus-driven process to develop voluntary principles guiding the collaboration between vendors and researchers about vulnerability information.


The meeting will be open to the public, both in person and via the web. Information on access to the meeting will be posted on the Multi-Stakeholder Process web site.

Enhancing Resilience Through Cyber Incident Data Sharing and Analysis

Today the DHS National Protection and Programs Directorate (NPPD) published a notice in today’s Federal Register (81 FR 17193-17194) requesting comments on three white papers produced by the NPPD Staff in conjunction with work done by the Cyber Incident Data and Analysis Working Group (CIDAWG) (comprised of CISOs and CSOs from various critical infrastructure sectors, insurers, and other cybersecurity professionals). The white papers address the critical need for information sharing as a means to create a more robust cybersecurity insurance marketplace and improve enterprise cyber hygiene practices across the public and private sectors.

The three white papers are:


The Value Proposition


The first whitepaper describes how a cyber incident data repository could help advance the cause of cyber risk management. NPPD is seeking input on the following questions in relation to this document:

• What value would an anonymized and trusted cyber incident data repository, as described in the white paper, have in terms of informing and improving cyber risk management practices?
• Do you agree with the potential benefits of an anonymized and trusted repository, as outlined in the white paper, that enterprise risk owners and insurers could use to share, store, aggregate, and analyze sensitive cyber incident data?
• Are there additional benefits of an anonymized and trusted repository that are not mentioned in the white paper? Please explain them briefly.
• What kinds of analysis from an anonymized and trusted repository would be most useful to your organization?

Establishing Community-Relevant Data Categories


The second whitepaper addresses the kinds of prioritized data categories and associated data points that should be shared among repository users to promote new kinds of needed cyber risk analysis. NPPD is seeking input on the following questions in relation to this document:

• Could specific data points within the 16 data categories effectively inform analysis to bolster cyber risk management activities?
• Are the 16 data categories accurately defined?
• What additional data categories could inform useful analysis to improve cyber risk management practices?
• What do these additional data categories mean from a CISO or other cybersecurity professional perspective?
• Rank the level of importance for each data category, including any additional data categories that you have identified.
• What value does each data category and associated data points bring to a better understanding of cyber incidents and their impacts?
• What does each data point actually mean (and to whom); and which ones are the greatest priority, to which stakeholders, and why?
• How easy/difficult would it be to access data associated with these categories in your organization and then share it into a repository and why?

Overcoming Perceived Obstacles


The final white paper identifies perceived obstacles to voluntary cyber incident data sharing and offers potential approaches to overcoming those obstacles. NPPD is seeking input on the following questions in relation to this document:

Would your organization be interested in contributing to a cyber incident data repository and using repository-supported analysis to improve your organization's risk management practices?
• What obstacles do you anticipate—both internal and external to your organization—that might prevent the sharing of cyber incident data into a repository?
• Who might say `no' to sharing and why?
• What mechanisms, policies, and procedures could help overcome these obstacles to sharing?

Public Comments


NPPD is soliciting public comments on the above topics. In particular, it is looking for comments from members of the cybersecurity and insurance communities; chief information security officers (CISOs); chief security officers (CSOs); academia; Federal, State, and local governments; industry; and professional organizations/societies.

NPPD tries to make it clear in this request for comments that they are not looking for specific program proposals at this time. What they are trying to do at this stage is to provide additional information to the CIDAWG for its continued work to better understand the potential of an anonymized and trusted cyber incident data repository to address the cybersecurity needs of the public and private sectors.

Comments may be submitted via email (cyber.security.insurance@hq.dhs.gov). Comments should be submitted by May 24th, 2016.

Commentary


There is no indication in the Federal Register Notice whether NPPD is looking at IT or OT systems or both. The reason for this (after a brief look at the table of contents of the three white papers) is that NPPD is apparently not making any differentiation between the two. The second white paper, for instance, includes five theoretical case studies and the first of those is a control system incident.

I have not yet had a chance to take a detailed look at any of the publications, but the brief look that I have made seems to indicate that the CIDAWG is making some subtle (and probably unintentional) oversights in the scope of their work. For instance, the sample data input page (pg 8 of the data categories paper) lists health records under data theft, but it does not specifically include an mention of medical devices, apparently lumping them under the ‘SCADA/ICS Attack’ category. Similarly, there is no specific mention of transportation related attacks.

The other thing that is missing from this discussion appears to be any focus on who would be collecting and analyzing the incident data. It looks to me like there has been an underlying assumption that the government (specifically some organization within NPPD) would  be responsible for this function. That may be an appropriate governmental function, but there are alternatives that should also be addressed in this work. The Insurance Institute for Highway Safety, for instance, comes to mind as an organization with a similar function.


The last point that I would like to make here is a question about the openness of this comment process. NPPD has chosen to internalize the comment management process instead of utilizing the Federal eRulemaking Portal. The public advantage of the formal submission process is that all comments are publicly posted in an easily accessible and well understood web site. Now NIST has successfully used an internalized submission management process and they did a good job on their request for information projects in making sure that the comments were clearly posted on their web site. NIST made it clear in the request notices that such postings would be made. NPPD has not done that in this notice.

Saturday, March 26, 2016

NIST Announces Pre-Workshop Session

This week NIST announced that the NIST National Cybersecurity Center of Excellence (NCCoE) will be holding a two-hour meeting before the Cybersecurity Framework Workshop next month. The meeting will be for personnel in the maritime and the oil/gas industries.

According to the announcement:

“In this NCCoE-facilitated Open Session, attendees will identify and prioritize hard cybersecurity problems in addressing challenges for enterprises in the maritime and oil & natural gas industries. The session will begin with a quick overview of the NCCoE's Use Case & Building Block tool identification process. We will then conduct a facilitated discussion identifying and prioritizing potential cybersecurity Use Case challenge statements to solve with partners in our labs. As part of the session, the NCCoE will share some candidate use cases identified during its work with the maritime and oil & natural gas industry to develop a CyberSecurity Framework Profile.”

There is a possibility that the discussion will be extended by up to two additional hours depending on participation.

NOTE: NIST also has a YouTube® video available about the workshop.


ICS-CERT Publishes and Advisory and an Agenda

Thursday the DHS ICS-CERT published a new advisory for the Cogent Data Hub application and the final draft agenda for the Industrial Control System Joint Working Group’s (ICSJWG) Spring 2016 meeting.

Cogent Advisory


This advisory describes a privilege escalation vulnerability in the Cogent Data Hub application. The vulnerability was reported by Steven Seeley of Source Incite. Cogent has produced a new version of the software to mitigate the vulnerability and Steven has verified the efficacy of the fix.

ICS-CERT reports that an exploit of this vulnerability would require local access and would require an authorized user to load a malformed file. Given those prerequisites, ICS-CERT says that a relatively unskilled attacker could exploit this vulnerability to escalate their access to system level.

ICSJWG 2016 Spring Agenda


The final draft of the agenda ICSJWG 2016 Spring Meeting. As I had previously noted, this 3-day meeting will be held in Scottsdale, AZ starting May 3rd, 2016. It looks like a nice mix of presentations in three simultaneous venues. The presentations on the Main stage include:

• How do you know if you are doing enough;
• Building C2M2 and its successful testing at several government and academic institutions;
• Factors that influence the structure of cyber organizations;
• Hands-on demonstration using pre-built wizards;
• NIST Cybersecurity Framework;
• Efforts to develop implementation guidelines in support of the NIST  Cybersecurity Framework;
• Meeting the challenge for cyber assurance with UL cap.

There is a forensics workshop that will be taking place the full three days of the Meeting. Each session will last about 30 minutes. “This hands-on technical workshop will allow attendees to learn recommended best practices for performing hard drive and memory captures on a
live system. Attendees will work one-on-one with ICSCERT’s Advanced Analytical Laboratory staff to learn techniques used to capture forensic copies for analysis.”


Thursday, March 24, 2016

Bills Introduced – 3-23-16

Yesterday as the House prepared to leave Washington for its two week (plus) Easter Recess there were 60 bills introduced. Of those two may be of specific interest to readers of this blog:

HR 4851 To enhance electronic warfare capabilities, and for other purposes. Rep. Walorski, Jackie [R-IN-2] 

HR 4860 To authorize the Secretary of Homeland Security to establish the United States - Israel Cybersecurity Center of Excellence, and for other purposes. Rep. Cicilline, David N. [D-RI-1]

The electronic warfare bill will only be of interest if it pertains to cybersecurity in addition to historical electronic warfare techniques. Even then it will be followed here if it contains language concerning control systems that would help inform the defense of privately owned systems.


As with most cybersecurity bills I will be looking closely at definitions to determine if coverage in this blog is appropriate.

Wednesday, March 23, 2016

Bills Introduced – 03-22-16

With only the House in session yesterday there were 19 bills introduced. Of those one may be of specific interest to readers of this blog:

HR 4839 To prohibit the Government from requiring any person to assist in devising a method for breaking the encryption of a wire or oral communication. Rep. Salmon, Matt [R-AZ-5] 


I doubt that there will be any ICS related tie-ins on this bill, but it will be interesting to see what definitions are used. After yesterday’s terror attacks in Belgium, I really don’t suspect that this bill has much of a chance of being considered with all of the calls for law enforcement and intelligence access to encrypted communications being so vehemently renewed.

ICS-CERT Updates ABB Advisory

Yesterday morning the DHS ICS-CERT published an updated version of the ABB Panel Builder Advisory that was published last week. A number of minor revisions were made to the advisory.

First the advisory reiterates that version 6.0 of the program was not affected by the reported vulnerability. Not sure why this was needed since only version 5.1 was mentioned as being affected and a recommendation that users upgrade to version 6.0 had been included in the original.

Second there is a clarification that the vulnerability is in the program used to construct Panel 800 HMI’s not in the HMI’s themselves as was implied in the original version. Interestingly this change was followed by a revised deployment description based upon that also corrects the above confusion between the Builder and the HMI. The interesting thing is that this change is made outside of the designated change boundary for change 2 of 4; a minor nit-picking point to be sure.

The third change is the addition of two vanilla security mitigations that are generally applicable to any operation and are not specific to this vulnerability. ICS-CERT advisories routinely include such mitigation measures, but these two were specifically recommended by ABB.

The last change is the addition of a link to the ABB Cyber Security Advisory for this vulnerability. I had provided this same link in my earlier blog post.


NOTE: I missed this when I did my post last night about the new Siemens advisory. The wife and I are moving this week and I only have limited internet access, so I was moving too fast to notice the subtle change in the listing for this advisory. I didn’t notice it until I checked my Twitter® feed and by then I didn’t have enough time to go back and revise the earlier post.

Tuesday, March 22, 2016

ICS-CERT Publishes Siemens Advisory and Water System Hack

This morning the DHS ICS-CERT published an advisory for a vulnerability in the Siemens APOGEE Insight. Additionally, ICS-CERT published a link to the Verizon Data Breach Digest; a new method Verizon is using to share selected data from their annual data breach report.

Siemens Advisory


This advisory describes an incorrect file permissions vulnerability in the Siemens APOGEE Insight. The vulnerability was reported by Network & Information Security Ltd. Company and HuNan Quality Inspection Institute. Siemens is reporting a work around while they continue to work on a new version of the software to mitigate the vulnerability.

ICS-CERT reports that a relatively unskilled attacker with local access to the file system and authentication credentials could exploit this vulnerability to modify application data.

The Siemens Security Advisory was published last Friday and announced on TWITTER®.

Verizon Data Breach Digest  


The new Verizon Data Breach Digest was published this weekend and ICS-CERT is providing a link to the new document. Actually ICS-CERT is calling this the ‘annual data breach report’, but that was published earlier this year. This is a new document this year where Version takes a selected number of reports (18 in this initial effort) from the latest (2015) breach report and fleshes out the story with some additional details.

Readers of this blog will most likely be interested in Scenario 8 (pg 38); Hacktivist attack—the Dark Shadow. This tells the story of a breached water treatment facility operations system; an actual ICS (well mostly) attack in the United States. I say ‘well mostly’ because the unnamed utility was operating their control systems on an old AS 400 that was also running administrative operations (including employee PII).

Verizon noted that unnamed Syrian based hacktivists stole a bunch of employee PII data and also played with some PLC settings over a couple of days, apparently opening and closing random valves. The random actions did cause some out-of-spec drinking water, but apparently in-line testing equipment alarmed the bad water and the operators were able to take remedial action.

This was not much of an attack, but it was a successful attack on a US utility control system and deserves to be acknowledged as such. The EPA is the agency responsible for security issues at water treatment facilities and it would be interesting to know if the utility ever reported the incident to them. I haven’t heard anything through my limited connections to the water treatment industry, but if the EPA was sharing the information, it would probably be done via restricted distribution.


It is a good thing that the utility called in a Verizon team to conduct a routine security check of their system (they didn’t tell Verizon that they had noted anomalous valve actions until after the team located and reported the hack). If it had been reported to ICS-CERT we might not have heard about this on the public facing web site.

Monday, March 21, 2016

RMP NPRM: Inherently Safer Reviews

This is part of a continuing series of blog posts about the EPA’s recently published notice of proposed rulemaking (NPRM) for revisions of their Risk Management Program. Earlier posts in this series include:


IST Discussion


There is a lengthy discussion in the NPRM preamble about the use of safer technology and alternative (STAA). It defines STAA as “risk reduction strategies developed through analysis using a hierarchy of process risk management strategies (or hierarchy of controls), which consists of those which are inherent, passive, active, and procedural.” The detailed discussion addresses topics like:

EPA’s past approach to STAA;
Public input on STAA;

STAA Revision Overview


In this NPRM the EPA is only proposing to make STAA revisions to Program 3 facilities in the following North American Industrial Classification System (NAICS) sectors:

• NAICS 322 - paper manufacturing
• NAICS 324 - petroleum and coal products manufacturing; and
• NAICS 325 - chemical manufacturing;

Changes would be made to the PHA requirements in §68.67 to require analysis of potential safer technology and alternatives that would include, in the following order of preference: IST or ISD, passive measures, active measures, and procedural measures. That analysis would include a requirement to evaluate the feasibility of implementing any of the measures considered.

The EPA is not currently considering requiring facilities to implement feasible STAA measures. It notes:

“While EPA believes that sources should look for additional opportunities to increase safety, we believe that the facility owners or operators are in the best position to identify which changes are feasible to implement for their particular process.”

Definitions


The NPRM would add a number of new definitions to §68.3. Those definitions would include:


Process Hazard Analysis


Changes would be made to §68.67(c) by adding sub-paragraph (8) requiring covered facilities to “address safer technology and alternative risk management measures applicable to eliminating or reducing risk from process hazards”. Included in sub-paragraph would be language to:

Specify that the analysis include, in the following order of preference: IST or design, passive measures, active measures, and procedural measures;
Determine the feasibility of the IST or ISD considered

Guidance


The NPRM notes that there is already plenty of guidance in existence concerning how to evaluate STAA. These include:

• CCPS, 2009. Inherently Safer Chemical Processes: A Life Cycle Approach, 2nd ed., American Institute of Chemical Engineers, CCPS New York, Wiley;
• Contra Costa Hazardous Materials Program, 2011. ISS Checklist;

Not Being Addressed in NPRM


In addition to not requiring STAA implementation in this NPRM there are two other areas related to inherently safer design that are not being addressed. They are:


The EPA is requesting comments on all three areas for potential consideration in future rulemakings.

Commentary


As I have mentioned on a number of occasions IST (or now STAA) is a very complex and technical topic. Many environmental and safety advocates have taken a relatively hard line that IST (in particular substitution of ‘safer chemicals’) should be mandated by the EPA and there is a petition (mentioned above) for the EPA to do just that. Industry, on the other hand, has taken an almost equally hardline that they are already doing IST analysis and any requirement to implement IST by bureaucrats could force them out of business.

The EPA is trying to tread an interesting line between those two semi-fixed positions. In not specifically requiring implementation they have acknowledged the very real basis for industry’s concern that requiring specific process changes is well beyond the EPA’s technical expertise. On the other hand requiring industry to identify IST and conduct a feasibility analysis could end up forcing more facilities to voluntarily adopt IST for business reasons.

If a facility has a catastrophic accidental release on a process where a facility has formally identified a feasible IST that was not implemented, they should certainly expect that the EPA would require that implementation in the inevitable consent agreement that would culminate the accident investigation. More importantly, any lawyer representing injured parties from such an accident would certainly point to the company’s assessment of a ‘feasible IST’ that was not implemented as proof that the company was derelict in their duty to operate a safe facility.


If adopted, this rulemaking will certainly result in a number of facilities that will make significant process changes; most with the surprised intent to increase the profitability of the facility by lowering process and/or insurance costs. There will be some number, one would hope that it would be small, that would look at the increased potential liability of not implementing a costly IST project as a reason to shut down the facility. Many people (probably not including the displaced workers) might argue that those facilities should be shutdown.

House Sends S 1180 (IPAWS) to President

This evening the House considered S 1180, the Integrated Public Alert and Warning System (IPAWS) Modernization Act, under suspension of the rules. Using only 18 minutes of the 40 minutes allocated to debate of the bill, the House approved the bill by a voice vote.


Since this bill codifies responsibility for IPAWS in a new 6 USC 526, this should settle the ongoing disagreement between the House Homeland Security Committee and Energy and Commerce Committee over the which committee has oversight jurisdiction. This dispute is one of the things that held up the House from considering their two versions of this bill.

Congressional Hearings – Week of 3-20-16

This week the House will be in session for a short week and then leave for their two week (plus) Easter Recess while the Senate is already home for their two weeks. Budget hearings are slowing down and there will be one non-budget hearing of potential interest to readers of this blog.

Budget


Only one budget hearing this week of potential interest. The Defense Subcommittee of the House Appropriations Committee will be holding a hearing on Tuesday to look at the budget for Guard and Reserve forces. Since many of the cybersecurity troops are found in Guard and Reserve units, this portion of the budget may be of interest.

Cyber Insurance


Also on Tuesday the Cybersecurity, Infrastructure Protections and Security Technologies Subcommittee of the House Homeland Security Committee will be holding a hearing on “The Role of Cyber Insurance in Risk Management”. The witness list includes:

• Matthew McCabe, Marsh Finpro;
• Adam W. Hamm, North Dakota Insurance Commissioner;
• Daniel Nutkis, Health Information Trust Alliance;
• Tom Finan, Ark Network Security Solutions

I have not really begun to address cyber insurance in this blog, mainly because it has not yet become a real part of control system risk management. I would expect that this hearing could provide some insight into how this risk management tool is evolving, but I do not think that there will be any mention of ICS related insurance. Watch, however, for mention of 3rd party liability. Once the insurance industry starts to address that in cyber insurance then I would expect to start to see real control system policies being written.

On the Floor


There will be one bill coming to the House floor this week that may be of specific interest to readers of this blog, S 1180 – Integrated Public Alert and Warning System Modernization Act of 2015. It is interesting that the House leadership has decided to take up this bill instead of either of the two House bills on this topic.


The bill will be considered under suspension of the rules, so there will be no amendments and limited debate. I expect that the bill will be sent to the President with substantial bipartisan support.

Sunday, March 20, 2016

HR 4765 – HHFT Response Grants

This week Rep. Herrera (R,WA) introduced HR 4765, the Fire Department Proper Response and Equipment Prioritization Act. The bill would require FEMA to give high priority to grants for incident response training for crude oil and ethanol train accidents.

Assistance to Fire Fighters Grants


The bill would amend 15 USC 2229(c), Assistance to firefighters grants, by adding a new paragraph (4) that would require FEMA to “give high priority consideration to grants providing for planning, training, and equipment to firefighters for crude oil-by-rail and ethanol-by-rail derailment and incident response”.

No additional funding is provided.

Moving Forward


Herrera is not a member of the Science, Space and Technology Committee to which this bill has been assigned. Thus it is unlikely that he would be able to influence the Committee to take up this bill. The alternative would be to use this language as a floor amendment to either a FEMA authorization bill or the DHS spending bill. In either case it would be unlikely that there would be any substantial opposition to the amendment.

Commentary


I can sympathize with any congressman that has oil or ethanol trains transiting communities within their district. While there have been a number of high-profile crude oil train accidents in the last couple of years, the actual threat to any given community is quite remote. But if an accident did occur the community would rely on their emergency response personnel to be trained and equipped to handle such a situation.

Many (if not most) communities do not have the spare training and equipment funds to finance operations of such low potential occurrence. This is where local communities tend to turn to the deep (relatively) pockets of the federal government for assistance. Those pockets are not deep enough, however, to fund every community for every year for such training and equipment. And training, if not repeated or practiced frequently, becomes stale and ineffective.

For low frequency, high-impact events like these rail catastrophes would probably be more effectively served by training and equipping a fast acting state or regional response team. The equipment costs for each team would be higher due to having to be able to respond quickly over longer distances (probably require air transport), but it would be lower than training and equipping each fire department along the train routes.


The other problem with this bill and others like it that expand grant uses or influence the grant funding process without providing additional funds it that they really only serve to dilute the limited money available for these grants. Particularly for low frequency events like this, grants to one community will mean that another community with a more likely occurrence that needs grant money will not get it.

HR 4743 Introduced – Cybersecurity Consortium

Last week Rep. Castro (D,TX) introduced HR 4743, the National Cybersecurity Preparedness Consortium Act of 2016. The bill would establish a consortium to support efforts to address cybersecurity risks and incidents, including threats of terrorism and acts of terrorism.

The Consortium


Section 2 of the bill would require the DHS Secretary to establish the National Cybersecurity Preparedness Consortium. The Consortium would “consist of academic, nonprofit, industry, and government partners that develop, update, and deliver cybersecurity training in support of homeland security” {§2(e)}. The Consortium would be authorized to {§2(c)}:

• Provide training to State and local first responders and officials specifically for preparing for and responding to cybersecurity risks and incidents;
• Develop and update a curriculum utilizing existing programs and models;
• Provide technical assistance services to build and sustain capabilities in support of preparedness for and response to cybersecurity risks and incidents, including threats of terrorism and acts of terrorism;
• Conduct cross-sector cybersecurity training and simulation exercises for entities, including State and local governments, critical infrastructure owners and operators, and private industry;
• Coordinate with the national cybersecurity and communications integration center of the Department of Homeland Security to help States and communities develop cybersecurity information sharing programs;
• Coordinate with appropriate Department of Homeland Security cybersecurity and training officials to assist in the incorporation of cybersecurity risk and incident prevention and response (including related to threats of terrorism and acts of terrorism) into existing State and local emergency plans.

Moving Forward


Castro is not a member of the Homeland Security Committee to which the bill was referred for consideration. A number of his cosponsors, however, are influential members of that Committee including Rep. Smith (R,TX) and Rep. Richmond (D,LA). It would seem that there is enough interest in this bill to ensure that it would be considered in Committee. Whether that would translate into an ability to move it forward to the whole House remains to be seen.

If this were to reach the floor in either the House or Senate, there does not seem to be anything controversial enough to cause any significant opposition. I would suspect that it would be considered under suspension of the rules in the House and under unanimous consent in the Senate.

Commentary


Unfortunately, this bill uses a dated definition of ‘cybersecurity risks’ and ‘incident’ that does not include industrial control systems, so the efficacy of preventing cyber-based acts of terrorism is greatly reduced. The definition of both terms refer to ‘information system’ and that is defined in 44 USC 3502(8). That definition reads:

“(T)he term ‘‘information system’’ means a discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information”.

For the last year or so most cybersecurity legislation {for example see §102(9) of the Cybersecurity Information Sharing Act (CISA) of 2015 included in Division N of the Consolidated Appropriations Act, 2016} has been modifying that definition by adding language that specifically includes “industrial control systems, such as supervisory control and data acquisition systems, distributed control systems, and programmable logic controllers”. This has been done in recognition of the fact that successful attacks on such systems could have physical effects that would be much more devastating than attacks on purely information systems.


To truly be effective the definition of information system used in this bill will have to be changed to the CISA definition. It is also about time that someone in Congress should consider amending the definition in §3502 to bring it into a more inclusive status.

Saturday, March 19, 2016

S 2658 – FAA and Cybersecurity

Earlier this week the Senate Energy, Commerce and Transportation Committee marked up S 2658, the Federal Aviation Administration Reauthorization Act of 2016. While the bill includes a number of sections on unmanned aviation systems (which I will cover in a later post), there was one section of the bill that concerns cybersecurity and there was an amendment offered in the markup that would have significantly increased the cybersecurity requirements of the bill.

NOTE: The GPO has finally printed a copy of the original bill, but that has already been superseded by substitute language that formed the basis for the Committee markup. All references to the bill in this post refer to that substitute language.

Section 4109


Section 4109 was included in the original version of the bill and made it whole into the substitute language. It is found in Title IV, Subtitle A; Next Generation Air Transportation System (pg 267). It would require the FAA Administrator to {§4109(a)}:

• Identify and implement ways to better incorporate cybersecurity measures as a systems characteristic at all levels and phases of the architecture and design of air traffic control programs, including NextGen programs;
• Develop a threat model that will identify vulnerabilities to better focus resources to mitigate cybersecurity risks;
• Develop an appropriate plan to mitigate cybersecurity risk, to respond to an attack, intrusion, or otherwise unauthorized access and to adapt to evolving cybersecurity threats; and
• Foster a cybersecurity culture throughout the Administration, including air traffic control programs and relevant contractors.

In short, the section recognizes that cybersecurity issues exist and leaves it to the professionals at the FAA to deal with the specifics while providing them the general authority to do so. And, of course, it included a requirement for the obligatory report to Congress after one year.

Markey Amendment


Sen. Markey (D,MA) introduced an amendment that would have virtually re-writen §4109. It started off with a new paragraph (a) that provided definitions of key terms. Those terms included:

• Covered air carrier;
• Covered manufacturer;
• Cyberattack;
• Critical software systems; and
• Entry point.

The paragraph (a) requirements (see above) from the bill would have been made paragraph (b) and the following paragraphs with detailed regulatory requirements would have been added:

• Disclosure of cyberattacks by the aviation industry;
• Incorporation of cybersecurity into requirements for air carrier operating certificates and manufacturer production certificates;
• Annual report to Congress on cyberattacks on aircraft systems as well as maintenance and ground support systems; and
• Managing cybersecurity risks of consumer communications equipment;

In general, Markey’s amendment would have provided the FAA with specific authority to craft the most comprehensive cybersecurity oversight regulations in the Federal government (outside of military contractors, anyway).

The Markey amendment was voted down by a vote of 8-12. The Committee does not provide details of the votes on their web page, but with a 13-11 Republican majority on the Committee, this means that at least 3 Democrats voted against the Markey amendment. In contrast, the overall bill (and the vast majority of the 60 submitted amendments) passed on a voice vote.

Moving Forward


As I remarked in an earlier post this bill will move to the Senate floor fairly quickly. The Senate just started their two week Easter recess, but I suspect that the Committee staff will be hard at work writing the report on this bill. I would not be surprised to see that report filed in one of the three pro forma sessions that the Senate has scheduled over the next two weeks, but at the very latest it should be published in the first full week of April when the Senate returns to Washington.

Commentary

While there is fairly widespread opposition in the cybersecurity community to additional regulation of cybersecurity, I firmly believe that public safety and security require more than voluntary application of cybersecurity principles in certain aspects of our society; especially since there has been such an obvious dearth of that voluntary application. Aviation safety and security, are in my estimation, one of the obvious areas where public good requires legislative and regulatory attention to cybersecurity.

The broadly shaped goals of the adopted version of §4109 can hardly be opposed because of specificity of equipment or protocols. The requirements are written with an absolute paucity of specificity. It does, however, rely upon a significant amount of cybersecurity acumen (if not necessarily technical knowledge) on the part of the FAA administration to establish the minimum level of regulatory oversight that the FAA needs to maintain over carriers and manufacturers to protect the public from cybersecurity vulnerabilities and their deliberate or accidental exploitation.

The provisions of the Markey amendment were a lot more specific in their cybersecurity requirements, but still avoided the problems of specifying techniques or equipment. For example, in the proposed paragraph for air carrier certificate requirements, there was the following mandate {§4109(d)(2)(a)}:

“Require all entry points to the electronic systems of each aircraft operating in the United States airspace[,] and [the] maintenance or ground support systems for such aircraft[,] to be equipped with reasonable measures to protect against cyberattacks, including the use of isolation measures to separate critical software systems from noncritical software systems;”

Unfortunately, the opposition (both inside Congress and out) to any serious specificity in cybersecurity requirements is obvious and in the short term (at least) is clearly in the entrenched majority with substantially bipartisan support. But again, I want to remind people in the cybersecurity community, political support is fickle at best. All it requires is one cyber incident that obviously and publicly puts people in harm’s way or kills people and the politicians in Washington will craft the most demanding and potentially contradictory cybersecurity rules that one could imagine.

The one area of the Markey proposal that I would like to see again considered in any floor action on S 2658 would be a requirement for the reporting of cyberattacks by the aviation industry. I think that the Markey definition of cyberattack needs some work, but the basics are there. The definition in his amendment was: “the unauthorized access to aircraft electronic control or communications systems or maintenance or ground support systems for aircraft, either wirelessly or through a wired connection.” {§4109(a)(3)}.


Markey then went on in paragraph (c) to demand the DOT establish regulations for air carriers and manufacturers to report successful or attempted “cyberattack on any system on board an aircraft, whether or not the system is critical to the safe and secure operation of the aircraft”. Since this would include hacking the onboard entertainment system to get a free move or intercepting someone’s unencrypted wi-fi email, this language is overbroad. If it were limited to ‘electronic control or aircraft communications systems’ and specifically excluded passenger side communications or the entertainment system, it would be a more acceptable requirement.

NIST Updates CSF Meeting Agenda

This week the National Institute of Standards and Technology (NIST) updated the draft agenda for their 2016 Cybersecurity Framework Workshop next month. The new agenda (.PDF) expands the information available on the topics to be discussed. My earlier post on this workshop can be found here.

The first day of the workshop (April 5th) is primarily designed for attendees who are not completely familiar with the Cybersecurity Framework (CSF) or the methodology that NIST used to develop the CSF. There will be two separate (but identical) Framework overviews presented by NIST. Attendance is obviously optional.

During the remainder of the 3-day workshop there will be three panel discussions and a number of working sessions. The panels will include:

• NIST Panel RFI Readout;
• Framework Use (Red Auditorium);
• International Alignment (Red Auditorium);
• Maritime Framework Profile (Green Auditorium);
• Cybersecurity Insurance (Red Auditorium); and
• State, Local, and Tribal Framework Use (Red Auditorium)

Based upon past NIST CSF workshops the working sessions will typically be led by NIST personnel, but will focus on audience participation and input. Topics for the working sessions will include:

• Roadmap Items – Privacy and Civil Liberties, International Alignment;
• RFI Topics – Governance, Framework Update;
• Special Topics in Framework Use – U.S. Coast Guard Framework Profile;
• Roadmap Items – Supply Chain Risk Management, Confidence Mechanisms;
• RFI Topics – Governance, Framework Update, Best Practice Sharing;
• Roadmap Items – Workforce and Education, Automated Indicator Sharing;
• RFI Topics – Governance, Framework Update, Best Practice Sharing;
• Special Topics in Framework Use – FFIEC Cybersecurity Assessment Tool;
• Roadmap Items – Authentication, Federal Agency Cybersecurity Alignment;
• RFI Topics - Framework Update; and
• Special Topics in Framework Use – CSIP Recover Publication

This agenda may be refined somewhat more as the dates approach, but based upon past workshops, this will be pretty much what will be going on. Before the workshop starts I expect that we will have at least a preliminary assessment by NIST of the RFI Comments.


Friday, March 18, 2016

Anhydrous Ammonia and Land Use Planning

One of the issues that was raised in the CSB’s report on the West Fertilizer explosion was land use planning and hazardous chemical facility siting. The question was asked in that report: “Why would a community be located so close to a facility storing a potentially dangerous chemical?” That same question was recently asked in an Iowa farm community with a different chemical, anhydrous ammonia, but in a more proactive manner.

It seems that a Midwestern farm chemical supply company recently shut down a fertilizer distribution facility. One of the reasons was apparently concerns about the location of their anhydrous ammonia storage tanks inside of a town of 800 people. While they had reportedly never had ammonia release, the potential consequences of such a release could be quite severe.

In searching for a site for a replacement facility, the company obviously wanted to be close to their customers, corn farmers, so they wanted a location near a farming community. They selected a site on a state highway a little more than a mile outside of a town of about 4,000 people. Then they went to the local government board to request an appropriate zoning change for the property.

It was not a completely isolated location, and a few of their potential neighbors objected. It was even suggested that the facility be located at an existing farm supply facility right in town. If that plan had been accepted it would have placed the entire town within the facility’s danger zone as  calculated by the EPA’s RMP*Comp program. The planning board demurred and ended up approving the site outside of town.

While that is the end of the story in the local paper, it may not be the end of the problem. If we look at a map of the area we can see that businesses are already expanding out of town along the state highway. Those businesses are already within a mile of the proposed fertilizer facility. It does not take any great skill to see that if the town continues to expand, one of the areas where that expansion will head is straight towards the new fertilizer company.


If the local leaders don’t keep the potential hazard in mind as they continue to allow their town to expand, then in five or ten years an accident at that facility could have a devastating impact on another small, tight knit community; all for the want of effective land use planning that takes into account potential chemical hazards at local businesses.

NHTSA Announces Automated Vehicle Safety Meeting

Today the DOT’s National Highway Traffic Safety Administration (NHTSA) published a meeting notice in the Federal Register (81 FR 14934-14936) for a public meeting in Washington, DC on April 8th, 2016. The purpose of the meeting is to seek input on planned guidelines for the safe deployment and operation of automated vehicles. This automated vehicle initiative is part of the NHTSA’s crash avoidance research program.

The full day meeting will address 12 topics:

Evaluation and testing of scenarios the AV system should detect and correctly operate in;
Detection and communication of operational boundaries;
Environmental operation and sensing;
Driver transitioning to/from AV operating mode;
Data;
Crash avoidance capability;
Electronics systems safety;
Aspects of AV technology that may not be suitable or ready for guidelines;
Information AV's may need to communicate to pedestrians and other vehicles (manual or automated); and
Other topics needed for operational guidance.

Readers of this blog should note that NHTSA includes both cybersecurity and system safety under the heading of ‘electronics systems safety’.

Advanced registration to attend the meeting is recommended. The meeting will also be webcast via a link on the Automated Vehicle web site.


NHTSA is soliciting both oral comments at the meeting and written comments. Written comments may be submitted via the Federal eRulemaking Portal (www.Regulations.gov; Docket # NHTSA-2016-0036). Written comments should be submitted by May 18th, 2016.

Thursday, March 17, 2016

FRA Announces RSAC Meeting – 04-07-16

Today the DOT’s Federal Railroad Administration published a meeting notice in the Federal Register (81 FR 14515-14516) for a public meeting of the Railroad Safety Advisory Committee in Washington, DC on April 7th 2016. The RSAC was formed to develop new regulatory standards, through a collaborative process, with all segments of the rail community working together to fashion mutually satisfactory solutions on safety regulatory issues.

Status reports will be presented by the following working groups (links are for the task statements for the working gourp - .PDF download):



While this is a public meeting, there is nothing in the notice that would indicate that feedback from the public, either oral or written, will be accepted for this meeting.

ICS-CERT Updates Advisory and Publishes New Advisory

This morning the DHS ICS-CERT published an update for an advisory published in December for a cross-site scripting vulnerability in the in XZERES 442SR turbine generator operating system (OS). It also published a new advisory for a vulnerability in the ABB Panel Builder 800.

XZERES Update


This update corrects the CVE number for the vulnerability. The CVE number published in the original advisory was actually for another cross-site scripting vulnerability in the same equipment that was reported by ICS-CERT in an advisory published in March of last year.

ABB Advisory


This advisory describes a DLL hijacking vulnerability in the ABB Panel Builder 800. The vulnerability was reported by Ivan Sanchez from Nullcode Team. ABB has produced a new version of the software that mitigates the vulnerability. There is no indication that Sanchez has been provided an opportunity to verify the efficacy of the fix.

ICS-CERT reports that an attacker must get malicious code to a specific directory in the file system and then convince an authorized operator to execute the code. ICS-CERT says that this cannot be exploited remotely.


The ABB Security Advisory (not referenced in this advisory) for this vulnerability has a workaround that can be used pending the updating of the software to the newer version. Thanks to Joel Langill for tweeting about this document this morning.

Protecting the Sky over CI

Yesterday the American Chemistry Council issued a press release commending the Senate Commerce, Science and Transportation Committee on their adoption of a much modified version of S 2658, the Federal Aviation Administration Reauthorization Act of 2016. An official copy of the bill has yet to be printed by the GPO, but a committee draft was used for mark-up process. The press release said (in part):

“ACC and its members commend Chairman Thune for his leadership on aviation safety and for working closely with Senator Blunt to include a provision to the Senate’s Federal Aviation Administration (FAA) reauthorization bill that will address the troubling gap in current policies regarding the safe operation of drones around chemical facilities. With today’s vote, Congress has taken another important step toward addressing the serious security concerns that have come with this new and rapidly growing technology.”

Background


There were over 50 amendments acted upon during that markup and most were adopted (I’ll have more on that hearing and the bill provisions in a later post). I searched through all of the amendments and could not find anything about protecting chemical plants. I then went back through the substitute language upon which the Committee actually acted. Sure enough I found the provision in §2144.

Now let me first start out by saying that this provision is not the same language that the ACC applauded last month in the House version of the FAA authorization, HR 4441. That bill was passed in committee but will apparently not work its way to the floor because of some intra-party problems.

First a procedural matter; there are a large number of provisions in S 2658 that are applicable to unmanned aircraft systems. Many of those would include additions to 49 USC in a new Chapter 448, Unmanned Aircraft Systems. The provisions of §2144 do not include instructions for adding language to Chapter 448. This may cause some minor administrative problems for the regulations that the FAA Administrator is supposed to craft, but those would be future problems of little interest to Congress. As a side note, the provision in HR 4441 would have been included in 49 USC.

Bill Provisions


Section 2144 would require the Administrator to establish new regulations within 180 days of the enactment of this bill; a very short time frame for any agency, but especially for the FAA, to complete the regulatory process. The purpose of the regulations would be to allow facilities to petition the FAA to “prohibit or otherwise limit the operation of aircraft, including an unmanned aircraft [emphasis added], over a fixed site facility” {§2144(a)}.

While the similar language in the House bill applied only to security regulated chemical facilities (CFATS and MTSA facilities) the coverage in this bill is much more expansive. It includes {§2144(b)(1)(C)}:

• Critical infrastructure;
• Oil refineries and chemical facilities;
• Amusement parks; and
• Other locations that may benefit from such restrictions

The bill provides only the broadest standards for the approval or disapproval of those applications. It allows the Administrator to consider {§2144(b)(2)(C)}:

• Aviation safety;
• Personal safety of the uninvolved public;
• National security; or
• Homeland security

The FAA is required to review those petitions within 90-days. The bill does not require the FAA to provide a notice of why the petition was denied. The Administrator, however, may allow a resubmission of the petition that addresses the reasons for its disapproval. If the petition is approved the FAA will outline {§2144(b)(2)(B)}:

• The boundaries for unmanned aircraft operation [emphasis added] near the fixed site facility; and
• Such other limitations that the Administrator determines may be appropriate.

Moving Forward


This bill is going to the floor of the Senate; the only question is when. I expect that it will get to the floor pretty quickly for the Senate. The current FAA authorization ends at the end of March, but HR 4721 was just approved by the Senate and is on its way to the President to extend that until July 15th (which just happens to be the last day the House and Senate plan to be in session before their election year lengthened summer recess). It would appear that the House and Senate committee staffs have been hard at work crafting a version of this bill that should be able to pass in both bodies.

It will probably take most of a week of floor debate and amending in the Senate. As long as there are no poisoned amendments tacked on to the bill it will pass in the House the following week. The big question is can the Senate get this to the floor before things start to get clogged up with spending bills. Hopefully, it will get to the floor in early April.

Commentary


I never can understand why staff members fail to make legislative mandates such as this a part of the US Code. It really does not make much difference, but it makes it look like this is a temporary measure that does not deserve a place in formal federal law. It does provide another problem which this section very carefully ignores, without being included in a portion of the US Code that includes key definitions, a bill should provide those definitions internally; this bill did not do that for this section.

There is an important internal disconnect in this Section of the bill. It starts off by allowing facilities to petition to limit the operation of aircraft, including an unmanned aircraft. It concludes, however, by only allowing the FAA to set the boundaries for unmanned aircraft operation. I’m pretty sure that many facility owners would prefer to include all aircraft, but the petition and approval processes should apply to the thing.

This bill also has the same severe problem that I identified with the similar provisions in HR 4441; making flight illegal does not stop the aircraft overflights. The bill does include in other sections proposals to require real-time identification of UAS and their pilots sometime in the future, there does not yet exist technology to accomplish that requirement, especially for aircraft currently in the field.

Without being able to identify aircraft violating facility airspace, the only way this prohibition can be effective is to allow the facility owner to take action to take down offending aircraft. That is currently illegal under FAA interpretation of the law that makes it illegal to interfere with an aircraft in flight in the National Air Space (NAS; with exceptions, of course, for actions by duly ordered military aircraft). To be effective, this section should provide some sort of active legal recourse to facility owners.

The provisions of §2144 do not explain how the limitations authorized in {§2144(b)(2)(B)} compare or interact with other restricted airspace designations that the FAA is required to maintain. Nor does it explain how the FAA should go about communicating this information to the UAS flying public. While commercial UAS pilots should be expected to have flight charts available that should allow them to avoid designated restricted air space, it is extremely unlikely that most ‘model aircraft’ UAS pilots would have them available or know how to read them. Ultimately, most experts would prefer to see these designations included in mandatory geofencing firmware within the drone, but we are a long way from being able to require that level of control system sophistication in all covered UAS, much less have a reasonable way to update that firmware with changes to restricted airspace in the NAS.


What probably needs to be added to §2144 is a few study and report provisions that would address these and other not quite so obvious problems with adding additional airspace restrictions to the operations in the NAS. If such provisions were included in this bill with a related sunshine date to force Congress to deal with the results of those studies and reports, then this would probably be a very good first step in limiting the flight of aircraft, including UAS, near critical infrastructure.

ICS-CERT Updates KACO Alert

Two days ago ICS-CERT published a minor update to their alert from August, 2015 for a hard-coded password vulnerability in KACO HMI products. The revised version added a single sentence to the summary portion of the Alert:

“According to this report, the password is easily found in the client code.”

I have no idea why ICS-CERT thought that this was important enough to add to the alert seven months after it was originally published. I suppose that it could be because KAKO has not been responsive enough in addressing this vulnerability.

Readers of this blog might be more than a little surprised that it has taken me two days to report on this update. The reason for that is simple, I just received an email this morning from ICS-CERT advising me of the recent update; this notification is a service that anyone can sign up for and I have previously mentioned it. A couple of months ago ICS-CERT changed their policy of listing updates to their alerts and advisories on their landing page. They had been making Twitter® notifications of these revisions, but did not do so in this case.

There are a couple of other oddities about how they handled this update. Normally ICS-CERT annotates changed versions of alerts and advisories by sequentially adding a letter to the end of the advisory number; for example, a first update would be labeled ICS-ALERT-16-074-XXA. They did not do that in this case. Another thing that they normally do is to highlight the changed areas in the body of the alert or advisory. Again, they did not do so in this case.

Now, none of these irregularities has a real impact on the information presented and in this case the change to the document is so minor that perhaps they thought that all of these additional details were not needed.

Just for the record here is the personal web site of the researcher, Aditya K Sood, who reported this vulnerability and a link to video of his presentation where he publicly disclosed this (and at least 3 other) HMI zero-days.


In any case there are muckrakers and nitpickers like me to keep the public informed, so now you know about this minor change and the oddities that go with it. I’ll leave it to the reader to figure out what this all means.
 
/* Use this with templates/template-twocol.html */