CISA Updates Iranian PLC Attacks Advisory – 7-22-26

Yesterday, CISA announced that they had updated their Joint Cybersecurity Advisory on “Iranian-Affiliated Cyber Actors Exploit Programmable Logic Controllers Across US Critical Infrastructure” that had originally been published on April 7th, 2026. The new information included expanding the list of affected products to include systems from Schneider Electric and Siemens and includes updated indicators of compromise information (XML and JSON). 

I do not typically cover these Joint Cybersecurity Advisories, but the Technical Details section of the report included the following comment: 

“After the actors extracted device project files, the FBI and CISA identified the modification and deletion of project file logic, to include Add-On Instructions (AOIs) and data manipulation on HMI and SCADA displays (T1565). Additionally, the changes disabled critical shutdown and alarm logic, allowing systems to enter unsafe conditions without notifying operators of the anomalies.” 

As a former process chemist, that claim certainly caught my attention and raised the stakes considerably. 

The Joint Advisory references two supporting vendor advisories for products from Rockwell Automation and Siemens. Siemens updated that advisory today, adding S7-1200 PLC as targeted device based on the CISA advisory update as well as references to S7-1200 G1, S7-1200 G2, S7-1500 user manuals. They did not, however, remove the following comment: 

“At this point in time, we have not observed any exploitation of vulnerabilities (emphasis added) in Siemens industrial control system (ICS) products.” 

Neither CISA nor the vendors have identified a specific, correctable vulnerability involved in these attacks. 

S 2439 Introduced - DHS ICS Capabilities Enhancement

Last month, Sen Peters (D,MI) introduced S 2439, the DHS Industrial Control Systems Capabilities Enhancement Act. The bill is nearly identical to the version of HR 1833 which passed in the House on July 20^th, 2021. The bill is currently scheduled to be considered by the Senate Homeland Security and Governmental Affairs Committee on Wednesday.

I made the following point in my post on HR 1833 that is also applicable to this bill:

“First off, it should be obvious to those that follow the control system security activities of CISA that this bill does not actually cause the Agency to undertake any new actions. It merely codifies the authority of CISA to do what it has been doing for quite some time. That could, however, be important in any period of budget constraint; agencies would be more likely to cut back programs and processes that have not been specifically authorized by Congress.”

I also made comment about my favorite topic definition of terms:

“As I was with HR 5733 [version of this bill in the 116^th Congress, link added], I am concerned that the bill did not modify the subsection (c), Functions, portion of §659 to specifically address the industrial control system support outlined in the new subsection (p). While there are numerous mentions of similar cybersecurity responsibilities, all of the mentions include using terms defined in §659(a) that rely on the IT restrictive definition of information systems. If Congress is not going to address those definitional issues (and that is probably considered by the crafters of this bill as being beyond the scope of the legislation) then they should have included adding a subsection to §659(c) like this:

“(12) supporting the cybersecurity operations of industrial control systems as outlined in (p).”

HR 2500 Reported in House – FY 2020 NDAA

Last month the House Armed Services Committee published their report on HR 2500, the FY 2020 National Defense Authorization Act (NDAA) along with a copy of the marked up version of the bill. There is one interesting TWIC bit in the actual bill and an entire subtitle of cyber-operations provisions (§1621 thru §1632 starting on page 884), but nothing specific to control system security. There is, however, and interesting discussion about ICS security in the Committee Report in a section dealing with facility electrical utility security.

TWIC Use

Section 2832 clarifies the use of the Transportation Workers Identification Credential (TWIC) for access to military facilities. This section amends §1050 of the National Defense Authorization Act for Fiscal Year 2017 (PL 114–328, 130 STAT. 2396). That earlier legislation directed DOD to consider allowing the use of TWICS for unescorted access to military facilities. The actual language allowed some wiggle room; “the Secretary shall, to the maximum extent practicable, ensure that the Transportation Worker Identification Credential (TWIC) shall be accepted as a valid credential for unescorted access to Department of Defense installations by transportation workers.” {§1050(a)}

In this bill the entire first paragraph was replaced with stricter language providing that the TWIC “is accepted as a valid credential for unescorted access to a work site at a maritime terminal of the Department of Defense” {new §1050(a)(1)} and allowing DOD to consider authorizing the use of TWIC for access to other DOD facilities.

ICS Security

The Committee Report (pgs 284-5) notes that in 2015 (2016?) the “Department subsequently directed the services and other Defense agencies to develop plans for identifying the goals, milestones, and resources needed to identify, register, and implement cybersecurity controls on facility-related ICS.” Apparently DOD has not provided adequate feedback to the Committee on how that work has progresses, so the Committee is directing the Government Accountability Office (GAO) to evaluate:

• The extent to which the military departments have developed and implemented plans and associated guidance to enhance the cybersecurity of ICS and what, if anything, remains incomplete;

• The challenges the military departments have encountered in implementing relevant guidance to enhance the cybersecurity of ICS and how effectively the challenges have been overcome;

• How effectively the military departments implemented industry leading practices to enhance cybersecurity for ICS; and

• How effectively the military departments conduct tests of the cybersecurity of ICS and implement improvements to security to counter any weaknesses identified.

Moving Forward

The House Rules Committee has closed the period for submitting possible amendments to HR 2500. As of today, 652 amendments have been submitted. I am currently keeping an eye on five of those amendments for possible coverage in future blog posts; #160, #244, #395, #415, and #457.

The Committee has not yet established a date for hearing on the rule for consideration of HR 2500. There has been some talk of adding a DHS spending bill (not yet published by the Appropriations Committee) to HR 2500, but that would be an unusual combination of bills. I do expect that some form of this bill will be considered before the House takes their summer recess.

DHS Publishes 30-Day CSAT ICR Change Notice – 05-07-19

Today the DHS Infrastructure Security Division of CISA published a 30-day Information Collection Request (ICR) revision notice for the Chemical Security Assessment Tool in the Federal register (84 FR 19929-19933). The 60-day ICR revision notice was published on February 7^th, 2019. This notice includes a detailed response to questions submitted by an unnamed commenter (official comment here) on the 60-day ICR notice.

The 30-day ICR Comments

Alert readers will recall that I pointed out two discrepancies in an otherwise detailed ICR notice. Those discrepancies are related to incomplete data being presented on two of the information collections covered in this ICR:

• Identification of Facilities at Risk; and

• Assets at Risks

The first deals with information collected from facilities that ship DHS chemicals of interest (COI) about facilities to which they ship COI. The second deals with information collected about industrial control systems that are related to the use, storage or loading of COI at the facility. I posed a number of questions about each of those collections and todays ICR notice provides detailed answers to those questions.

Identification of Facilities at Risk

While the full set of comments concerning the Identification of Facilities at Risk information collection is well worth reading, particularly by facilities that have thought that DHS would not be able to find out that they had COI and thus could get away without filing a Top Screen, the data that I found interesting was presented in response to my questions about the history of this information collection. I’ll briefly summarize it below:

• Number of potential responses per year – 845

• Number of voluntary responses that identified facilities actually received – 15

• Number of facilities of concern identified – 172

• Number of Top Screens from newly identified facilities – 27 (to date, may be more pending)

• Number of new CFATS covered facilities from those Top Screens – 18

This final data section on the Identification of Facilities at Risk data collection concludes with the following editorial comment:

CISA believes that voluntarily supplied customer and suppliers lists are an excellent source of information to identify chemical facilities of interest and covered chemical facilities.

Assets at Risk

This is the data collection that was completely overlooked in the 60-day notice. Again, the full response to the questions I asked about this data collection are worth reading, particularly by anyone interested in the regulation of industrial control system security. I will highlight a few of the more interesting data points here.

The number of times Chemical Security Inspectors requested information about assets at risk:

◦ FY 2017 – 2,018

◦ FY 2018 – 3,328

◦ FY 2019 (to date) – 1,107

The number of voluntary responses – all requested facilities;

The following comment was provided about the information collected:

CISA has found that the information generally collected under the section (Assets at Risk) is not information previously provided in an approved facility's SSP or ASP. The information collected through the second section of the instrument generally supplements the information provided by covered chemical facilities in their SSP or ASP. Information collected through this instrument is recorded in case files created by CISA employees outside of the SSP or ASP (e.g., Compliance Inspection Reports).

Commentary

Once again, I would like to commend the folks at DHS for the way that they have dealt with these questions and ICRs related to the Chemical Anti-Terrorism Standards (CFATS) program in general. The wealth of information provided to the regulated community to justify the information collection requests is a model that other agencies in the Federal Government should follow.

The differences in the response rates to the two voluntary information collections is more than a little interesting. The 100% response rate to the questions about industrial control system security issues seems to me to be indicative of the industry’s cooperative compliance with the CFATS program. The Infrastructure Security Compliance Division (ISCD) has worked very hard to foster a strong working relationship with the regulated industry and this is a great indicator of how well that hard work has paid off.

The very low voluntary compliance rate on the facility identification collection poses an interesting conundrum for the folks at ISCD. First, the success rate for identifying facilities that have not followed the law (for what ever reason) and completed a Top Screen is phenomenal. That combined with the higher than normal conversion of initial Top Screen submissions to identification of submitting facilities as CFATS covered facilities means that this is a very effective tool for achieving the congressional mandate in 6 USC 629, Outreach to chemical facilities of interest.

The low voluntary compliance rate for this collection is almost certainly based upon organizations wanting to protect customer relationships. Non-complying companies are probably trying to avoid the appearance of ‘ratting out’ their customers, and this is certainly understandable. ISCD recognition of this concern is also why this is a voluntary information collection.

During the CFATS reauthorization Congress might want to take a look at whether or not they might want to mandate this information collection. Being able to collect this information from each covered facility that ships COI domestically will certainly bring ISCD much closer to 100% identification of facilities of interest. Whether or not this is worth the political cost of mandating the disclosure is something that only Congress can answer.

HR 334 Introduced – Cybersecurity Education

Earlier this month Rep. Lieu (D,CA) introduced HR 334, the New Collar Jobs Act of 2019. The bill would amend the Internal Revenue Code to add a new section establishing an “employee cybersecurity education credit” {new §45S(a)}.

The Tax Credit

The general business tax credit to be included under 26 USC §38 would be for 50% of cybersecurity education expenses (up to $5,000 per year per employee) “paid or incurred by the employer during such taxable year”. The qualified expenses would be the “amounts paid or incurred for each employee who earns a certificate or degree at the undergraduate or graduate level or industry-recognized certification relating to those specialty areas and work roles that are listed in NCWF Work Roles in the document entitled, ‘NICE Cybersecurity Workforce Framework (NCWF)’ [NIST Special Publication 800-181; NOTE: the link does not work during the current Federal Funding Fiasco]” {new §45S(c)}.

Moving Forward

Because of the politics of the Federal Funding Fiasco the committee membership listing for the House has not yet been completed so it is hard to tell what sort of influence Lieu and his three cosponsors will have to see that HR 334 is considered in committee.

I do not see anything in the bill that would raise any great objection to the bill. I suspect that if it were considered in committee or on the Floor it would generally receive bipartisan support.

Commentary

While there are no definitions in the bill nor can we see the current listing of the ‘specialty areas and work roles’ to which this tax credit would apply, it would be reasonable to assume that it would include cybersecurity training for industrial control systems (ICS). I say this because the Congressional Findings portion of the bill specifically notes {§2(2)}:

“As manufacturers leverage new technologies from robotics to distributed control systems to create modern factories and industrial plants, different employment requirements have emerged including the need for cybersecurity talent.”

The next subparagraph goes on to explain:

“Leading cybersecurity experts have reported spike of 250 percent in industrial automation and control system cyber-incidents occurring during the period between 2011 and 2015 and as a result are seeking personnel with knowledge of their industry coupled with knowledge of security technology to prevent their organization from becoming victims of cyber-attacks.”

I do not believe that the bill would limit the tax credit to just ICS cybersecurity programs, but this clearly explicates the crafters intent that such programs would be covered under this proposed tax credit.

HR 4120 Introduced – ICS Research

On Wednesday Rep. Bera (D,CA) introduced HR 4120, the Grid Cybersecurity Research and Development Act. The bill would provide for a comprehensive interdisciplinary research and development initiative to strengthen the capacity of the electricity sector to neutralize cyberattacks.

Definitions

Section 3 of the bill provides the working definitions for the bill. Since this is a stand-alone bill (not amending existing legislation) these definitions are very important. The terms include:

• Critical electric infrastructure information – uses definition from 16 USC 824o-1 (incorrectly printed in the bill as ‘824a-1’);

• Cybersecurity – “means a set of preventative measures to protect information from a digital device or system, including a device or system used to manage the electric grid, from being stolen, compromised, or used to carry out an attack” {§3(2)};

• Human factors research – “means research on human performance in social and physical environments, and on the integration of humans with physical systems and computer hardware and software” {§3(5)};

• Human-machine interface – “means technologies that present information to an operator about the state of a process or system, or accept human instructions to implement an action, including visualization displays such as a graphical user interface” {§3(6)}; and

• Transient devices – “means removable media, including floppy disks, compact disks, USB flash drives, external hard drives, mobile devices, and other devices that utilize wireless connections for limited periods of time {§3(8)}.

Energy Cybersecurity R&D

Section 4 of the bill requires the Secretary of Energy, in coordination with a variety of federal, state and local agencies and private sector groups, to “carry out a research, develop23

ment, and demonstration initiative to harden and mitigate the electric grid from the consequences of cyber attacks by increasing the cybersecurity capabilities of the electricity sector and accelerating the development of cyberse curity technologies and tools” {§4(a)}. It specifically identifies responsibility to carry out activities to {§4(b)}:

• Identify cybersecurity risks to the communication and control systems within, and impacting, the electricity sector;

• Develop methods and tools to rapidly detect cyber intruders and cyber incidents, including the use of data analytics techniques to validate and verify system behavior using multiple data streams reflecting the state of the system;

• Assess emerging energy technology cybersecurity capabilities, and integrate cybersecurity features and protocols into the design, development, and deployment of emerging technologies, including renewable energy technologies;

• Develop secure industrial control system protocols and identify vulnerabilities in existing protocols;

• Improve the physical security of communication technologies and industrial control systems, including remote assets;

• Integrate human factors research into the design and development of advanced tools and processes for dynamic monitoring, detection, protection, mitigation, and response;

• Advance the capabilities and use of relevant interdisciplinary mathematical and computer simulation modeling and analysis methods;

• Evaluate and understand the potential consequences of practices used to maintain the cybersecurity of information technology systems on the cybersecurity of industrial control systems;

• Increase access to and the capabilities of existing cybersecurity test beds to simulate impacts of cyber-attacks on industrial control system devices, components, software, and hardware; and

• Reduce the cost of implementing effective cybersecurity technologies and tools in the electricity sector.

Additionally, the Energy Department is specifically tasked with working “with manufacturers to build or retrofit security features and protocols into” {§4(b)(5)}:

• Communication and network systems and management processes;

industrial control and energy management system devices, components, software, firmware, and hardware, including distributed control and management systems and building management systems;

• Data storage systems and data management and analysis processes;

• Generation, transmission, distribution, and energy storage technologies;

• Automated and manually controlled devices and equipment for monitoring or managing frequency, voltage, and current;

• Technologies used to synchronize time and develop guidance for operational contingency plans when time synchronization technologies are compromised;

• End user elements that connect to the grid, and

• The supply chain of electric grid management system components.

Technical Guidance and Standards

Section 5 of the bill addresses support activities required by DOE and other federal agencies in developing and sharing technical guidance documents and standards.

DOE is required to facilitate the updating of {§5(a)(1)}:

• The Roadmap to Achieve Energy Delivery Systems Cybersecurity;

• The Cybersecurity Procurement Language for Energy Delivery Systems; and

• The Electricity Subsector Cybersecurity Capability Maturity Model.

DOE is also required to develop voluntary guidance to improve forensic analysis capabilities to include {§5(a)(2)}:

• Developing standardized terminology and monitoring processes;

Identifying minimum data needed; and

• Utilizing human factors research to develop more effective procedures for logging incident events; and

• Developing a mechanism to anonymize, aggregate, and share the testing results from cybersecurity industrial control system test beds to facilitate technology improvements by public and private sector researchers.

DOE and the National Institute of Standards and Technology (NIST) are tasked with developing voluntary, consensus-based standards to improve cybersecurity for {§5(c)(1)}:

• Emerging energy technologies;

• Distributed generation and storage technologies, and other distributed energy re24

sources;

• Electric vehicles; and other technologies and devices that connect to the electric grid that can affect voltage stability.

Vulnerability Testing

Section 6 of the bill requires DOE to work with owner/operators and the national laboratories to {§6(a)}:

• Utilize a range of methods, including voluntary vulnerability testing and red team-blue team exercises, to identify vulnerabilities in physical and cyber systems;

• Develop cybersecurity risk assessment tools and provide confidential analyses and recommendations to participating stakeholders;

• Work with stakeholders to develop methods to share anonymized and aggregated results in a format that enables the electricity sector, researchers, and the private sector to advance cybersecurity efforts, technologies, and tools;

• Identify information, research, staff training, and analysis tools needed to evaluate industrial control system cybersecurity issues and challenges in the electricity sector; and

• Facilitate the sharing of information and the development of tools needed to evaluate industrial control system cybersecurity issues.

Appropriations

Section 11 of the bill provides the authorization for spending money to support the various programs called for in this bill. It sets the following annual authorization amounts:

$65,000,000 for fiscal year 2018;

$68,250,000 for fiscal year 2019;

$71,662,500 for fiscal year 2020;

$75,245,625 for fiscal year 2021; and

$79,007,906 for fiscal year 2022.

Moving Forward

Bera is a member of the House Science, Space, and Technology Committee to which the bill was assigned for primary consideration. His three cosponsors are also influential Democrats on that Committee. This means that there may be enough influence to have the bill be considered in Committee. The one problem here is that there are no Republican cosponsors of the bill, indicating a potential lack of bipartisan support.

Since no regulatory actions are included (or authorized) by the bill the only thing that will draw any real opposition is the authorized spending. Those monies will have to come from somewhere in the budget and probably from the DOE budget. With money already tight, this will be the major stumbling block that the sponsors will have to overcome to see this bill considered in Committee and move it to the floor of the House.

Commentary

The Committee Staff members that crafted this bill are to be commended on developing a comprehensive energy sector cybersecurity bill. Section 2 of the bill, the Congressional Findings that support the need for the bill, is one of the best non-technical descriptions of the cybersecurity problems facing the electrical grid that I have seen. It includes an appropriately nuanced attention to the differences between information and operational technology and a realistic appreciation of the role of human factors in the problem. Good job.

Having said that, there are a few short comings that need to be addressed. The first is the issue of Critical Electric Infrastructure Information (CEII), the controlled but unclassified information system protecting information shared by the electric grid industry and the Department of Energy. Throughout this bill there are numerous references rightfully reiterating that the information shared by industry with DOE is protected from public disclosure under this program.

There are multiple references in the bill to ‘aggregating and anonymizing information’ as this is the key to ‘sharing’ the information provided under the CEII program. Unfortunately, the federal government does a poor job generally (and I suspect DOE specifically) of sanitizing and sharing restricted information. This may not be a problem within the grid operation community (I don’t have the information necessary to make the assessment), but DOE does not play well with outsiders.

This is a problem here because large amounts of the ICS cybersecurity research and development efforts outlined in the bill could have enormous positive impacts on the remainder of the ICS community. DOE has no incentive, nor even a mechanism, to share this valuable information outside of their regulated community.

This problem is further compounded by the failure to specifically include ICS-CERT in the federal agencies to be included in this development effort. ICS-CERT is the only federal agency with the sole focus on the cybersecurity of industrial control systems. And they have the mechanisms in place to share information with the remainder of the ICS security community.

The other major issue is the lack of attention to the issue of vulnerability disclosures. The bill attempts to address the issue in §6 of the bill, but it only really looks at system testing at the facility level. While this is certainly a valuable part of vulnerability testing, it ignores the much larger issue of the cybersecurity testing of individual components of the control systems done on a daily basis by independent security researchers and relatively small research companies.

Congress needs to come up with a way to incentivize those researchers to share their information with DOE instead of with the other existing organizations that pay researchers for their identified vulnerabilities and then provide the information to paying customers. DOE needs to establish a coordinating mechanism so that vulnerability reports from researchers are coordinated with the vendors and the mitigation measures are reported to the user community. OR the bill could just recognize the already existing mechanisms established by ICS-CERT and provide for priority disclosure of vulnerabilities and their mitigations to grid operators (and establishing a mechanism for doing that).

S 133 Introduced – FY 2017 Intelligence Authorization

Earlier this month Sen. Burr (R,NC) introduced S 133, the Intelligence Authorization Act for Fiscal Year 2017. Last Friday the Senate Select Committee on Intelligence reported the bill favorably without amendment. There are two cybersecurity provisions that may be of interest to readers of this blog:

Sec. 312. Assistance for nationally significant critical infrastructure.

Sec. 614. Report on cybersecurity threats to seaports of the United States and maritime shipping.

CI Assistance

Section 312 would authorize elements of the intelligence community, through the Under Secretary for Intelligence and Analysis of the Department of Homeland Security, to provide assistance to covered critical infrastructure facilities “to reduce the risk of regional or national catastrophic harm caused by a cyber attack (sic) against covered critical infrastructure” {§312(c)}.

A key term used in §312 is ‘covered cybersecurity asset’ which is defined as “an information system or industrial control system [emphasis added] that is essential to the operation of covered critical infrastructure” {§312(a)(2)}.

The bill describes the type of assistance to be provided by the intelligence community. It includes {§312(e)(2)}:

• Activities to develop a national strategy to effectively leverage intelligence community resources made available to support the program;

• Activities to consult with the Director of National Intelligence and other appropriate intelligence and law enforcement agencies to identify within the existing framework governing intelligence prioritization, intelligence gaps and foreign intelligence collection requirements relevant to the security of covered cyber assets and covered critical infrastructure;

• Activities to improve the detection, prevention, and mitigation of espionage conducted by foreign actors against or concerning covered critical infrastructure;

• Activities to identify or provide assistance related to the research, design, and development of protective and mitigation measures for covered cyber assets and the components of covered cyber assets; and

• Activities to provide technical assistance and input for testing and exercises related to covered cyber assets.

Cybersecurity Threats to Seaports

Section 614 would require the Under Secretary of Homeland Security for Intelligence and Analysis to submit a report to Congress on cybersecurity threats to seaports and maritime shipping. The report would address “the cybersecurity threats to, and the cyber vulnerabilities within, the software, communications networks, computer networks, or other systems” {§614(a)}. While it does not specifically address control systems, the ‘other systems’ mention probably provides for coverage of that topic.

In addition to a report on any recent cyberattacks or cybersecurity threats, the bill would require an assessment of{§614(b)}:

• Any planned cyberattacks directed against such software, networks, and systems;

• Any significant vulnerabilities to such software, networks, and systems; and

• How such entities and concerns are mitigating such vulnerabilities.

While not specifically stated, the report will almost certainly be classified because of the requirement to be “consistent with the protection of sources and methods” {§614(a)}.

Moving Forward

This bill was supposed to have been a ‘must pass’ bill in the last session. The House passed three slightly different versions of an intel authorization bill and the Senate Select Committee on Intelligence marked up their own version of such a bill, but nothing made its way to the Senate floor. With most of the players remaining the same in the Senate, it will be interesting to see if the change in administration has any potential effect on the consideration of this bill.

ICS-CERT Publishes Advisory and Monitor

This morning the DHS ICS-CERT published an advisory for OSIsoft PI AF as well as the March-April Monitor.

OSIsoft Advisory

This advisory describes a a default permissions vulnerability in PI AF product. This vulnerability was self-reported. Since this is described as more of an installation issue rather than a software issue, OSIsoft is recommending making adjustments to “PI SQL (AF) Trusted Users” instead of making any changes to the programming.

ICS-CERT reports that a relatively unskilled attacker could remotely exploit the vulnerability to execute SQL statements that result in tampering, information disclosure, repudiation, elevation of privilege, and denial of service.

March-April Monitor

This latest version of the Monitor features:

∙ A water sector incident investigation;

∙ A report on assessments conducted by ICS-CERT;

∙ Situational awareness;

∙ ICS-CERT news; and

∙ A variety of standard Monitor reports.

The interesting thing about the water facility incident was that while it initially looked like a malware attack, it wasn’t. The whole incident was an installation error. While there are certainly lessons to be learned about having an installation done properly, I don’t really think that it is necessarily important enough to be mentioned here. On the other hand, that may have been the most interesting incident during this two month period; we can only hope.

The brief report on the cybersecurity assessments done by ICS-CERT indicates that they spent most of their time in the water sector. Of the 21 assessments done during the two month period, fourteen were in water and waste water facilities.

The situational awareness section of the Monitor looks at multi-factor authentication. It is an interesting page and a half read.

The news section has brief articles on the upcoming spring meeting of ICSJWG, ICS-CERT regional training and CSET 6.2. This is the second time (the first was the year in review publication) that ICS-CERT has featured v6.2 of the CSET but the CSET web page still mentions nothing about the latest and greatest version. Maybe it’s not so great after all.

ICS-CERT Publishes an Update, an Advisory and an Alert

Yesterday the DHS ICS-CERT published an update for a Siemens advisory, a new advisory for an Advantech product line, and an alert for a Microsoft vulnerability.

Siemens Update

This update is for an WinCC advisory that was originally published last November. This update provides notification that the last affected system (WinCC 7.0 SP 3) now has an update available to mitigate the vulnerability. Siemens published their update last week.

Advantech Advisory

This advisory describes a buffer overflow vulnerability in the Advantech EKI-1200 MODBUS Gateway product line. The vulnerability was originally reported by Enrique Nissim and Pablo Lorenzzato of the Core Security Engineering Team in a coordinated disclosure. ICS-CERT reports that Advantech has a patch that mitigates the vulnerability but there is no indication that the researchers have validated that fix.

ICS-CERT reports that a relatively unskilled attacker could remotely exploit this vulnerability to execute arbitrary code.

Microsoft Alert

This alert describes a critical security update for the Microsoft Windows operating systems. The JASBUG vulnerability was first reported by four different researchers, including Jeff Schmidt at Global Advisors. Microsoft has produced an update that mitigates the vulnerability, but there is no indication that the researchers have been given the opportunity to verify the efficacy of the update.

ICS-CERT reports that an attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.

ICS-CERT notes that just processing the update does not fix the vulnerability. Additional actions need to be taken by the system administrator before the fix actually mitigates the vulnerability.

ICS-CERT Publishes 5 Advisories and 1 Update

It was a busy day for ICS-CERT today with four new advisories, an almost three month old advisory being publicly published and one update of an advisory that was published yesterday. Did anyone mention that S4x15 started today?

GE DNP3 Advisory

Let’s get the old advisory out of the way first. This advisory was originally published back on October 14^th on the US-CERT Secure Portal. It describes a Crain-Sistrunk improper input validation vulnerability in the DNP3 implementation used by GE iFix and Cimplicity products. The implementation was produced by Catapult Software who developed a patch that mitigates the vulnerability and GE has verified the efficacy of the patch. It does not appear that Crain-Sistrunk have verified the efficacy.

ICS-CERT reports that a relatively unskilled attacker could remotely exploit this vulnerability to effect a DOS attack.

According to the Project Robus web site it now looks like 29 of the 30 DNP3 vulnerabilities reported by Crain-Sistrunk have now been publicly disclosed by ICS-CERT.

NOTE: There is no reason given for the unusually long delay between the US-CERT publication and the ICS-CERT public notification.

GE Multilink Advisory

This advisory describes two vulnerabilities that effect the GE Multilink line of switches. The vulnerabilities were found by Eireann Leverett of IOActive in one of the Multilink switch lines and GE notified ICS-CERT that other lines were affected as well. A firmware upgrade is available.

The two reported vulnerabilities are:

● Resource consumption vulnerability - CVE-2014-5418; and

● Hard-coded key - CVE-2014-5419

ICS-CERT reports that a relatively low skilled attacker could remotely exploit these vulnerabilities to conduct a DOS attack or decrypt traffic. ICS-CERT reports that there is no public exploits for these specific vulnerabilities while GE restricts that claim specifically only to the ML800 switches.

Phoenix Contact Software Advisory

This advisory describes an authentication vulnerability in applications developed by Phoenix Contact Software. These applications are used by undisclosed vendors to run process control and manage IEC 61131 logic. The vulnerabilities were originally reported by Reid Wightman of Digital Bond. Phoenix Contact Software is considering developing a fix for these vulnerabilities.

ICS-CERT reports that a relatively unskilled attacker could remotely exploit this vulnerability to inject arbitrary commands into the protocol.

The end use product may or may not contain mitigation measures to protect against this vulnerability.

GOOD LUCK. Caveat emptor.

Clorius Controls Advisory

This advisory describes an insecure Java client web authentication vulnerability in the Clorius Controls A/S ISC SCADA server. The vulnerability was originally reported by  Aditya Sood  who has validated the efficacy of the update that has been made available.

ICS-CERT reports that a relatively low skilled attacker could remotely exploit this vulnerability to gain complete access to the server.

Siemens Advisory

I noted the Siemens release of their advisory about this vulnerability this morning on Twitter and am now happy to report the ICS-CERT prompt release of their advisory. It describes three separate authentication vulnerabilities in the WinCC Sm@rtClient iOS Application. The vulnerabilities were originally reported by Kim Schlyter, Seyton Bradford, and Richard Warren from FortConsult. Siemens has produced an update to mitigate the vulnerability, but there is no report that the researchers have validated its efficacy.

The vulnerabilities include:

● Insufficiently protected credentials - CVE-2014-5231 and CVE-2014-5233; and

● Improper authentication - CVE-2014-5232

ICS-CERT reports that a relatively low skilled attacker with local access to the mobile device could exploit these vulnerabilities to gain access to the application and then presumably (my guess, not mentioned in the advisory) remotely access the control system with the full rights of the mobile device owner.

CodeWrights Advisory Update

Yesterday’s advisory was updated today to clarify that while ABB is a customer of CodeWrights HART DTM  library that they have not yet verified that any of their systems are affected by the identified vulnerability. The update provides a link to the ABB security advisory page where ABB will make the notification if any systems are found to be vulnerable.

I think that it is probably safe to assume that ICS-CERT has not yet verified that any other of the potentially affected vendors listed actually have products with the vulnerabilities. They apparently made the somewhat reasonable assumption that if these vendors (including ABB) had bought the rights to use the vulnerable libraries that there products using those libraries would be affected.

I guess we will just have to wait and see. I know which way I would bet.

ICS-CERT Publishes OpenSSL Update and 2 New (Almost) Advisories

The afternoon the DHS ICS-CERT updated (up to ‘F’ now) their Situational Awareness Alert for the OpenSSL vulnerability. They also published new advisories for vulnerabilities in systems from Trihedral Engineering and Yokogawa.

HeartBleed

This update adds ABB to the list of vendors with affected products. The Relion 650 series has a patch available to mitigate the vulnerability. There is no explanation as to why this update was so long in coming. The last HeartBleed update was published back in April and ABB published their advisory in July.

Trihedral Advisory

This advisory describes an integer overflow vulnerability in their VTS and VTScada products. The vulnerability was reported by an anonymous researcher through ZDI. ICS-CERT reports that Trihedral has produced a patch that mitigates the vulnerability.

ICS-CERT reports that a relatively unskilled attacker could remotely exploit this vulnerability to cause the application to crash.

Interestingly the Trihedral update page says nothing about this vulnerability in their upgrade descriptions. ZDI does report that they notified Trihedral of this vulnerability (ZDI-CAN-2599) on November 19^th so this was a very quick response.

Yokogawa Advisory

This advisory reports an XML external entity processing vulnerability in the Yokogawa FAST/TOOLS application. The vulnerability was reported by Timur Yunusov, Alexey Osipov, and Ilya Karpov of Positive Technologies Inc. ICS-CERT reports that Yokogawa has developed a service pack that mitigates this vulnerability, but no mention is made that the researchers have verified the efficacy of the fix.

ICS-CERT reports that it would be difficult to craft an exploit of this vulnerability and local access would be required. Yokogawa also reports (in their CVSS calculation) that local access is required, but note that it can be exploited by an attacker that “intrudes into the WebHMI server in any way”. Something may be lost in translation there because that sounds to me like remote access could be used to exploit this vulnerability.

I mentioned earlier that Yokogawa had publicly reported this vulnerability over a week and a half ago; not very timely reporting by ICS-CERT.

If Sony Had Been a Chemical Plant

The infosec world is still buzzing about the recent hack of Sony and how completely their information systems were owned by the attacker. Researchers will be pouring over this attack for a while trying to figure out how it all happened and what could have been done to prevent it.

The Hack

The Sony hackers took, among other things, valuable intellectual property (high quality digital copies of yet to be released films), thousands of internal documents (one source said 1 terabytes worth), and system access information to include log-in credentials and passwords. The attack was so thorough that Sony was forced to shut down all computer systems for days while they went through and inspected/cleaned every machine.

The TWITERVERSE is all agog, of course about #SonyHack. I’ve made my own small contribution (sans hashtag, of course). The one tweet of mine that I would like to look at in more detail came on Saturday:

“I guess we should be glad that Sony didn't make dangerous chemicals or supply something really important....”

XYZ Chemical Company

So what would have been different if it had been XYZ Chemical Company that had attracted the ire of the GOP attackers? Other than differences in what IP was stolen, probably not much in the immediate results of the attack. The longer term results could have been much more serious to communities around XYZ plants and possibly to the nation.

Intellectual property theft? Well, formulations come to mind first. The wholesale release of formulations would give every competitor here and around the world a leg up in understanding how XYZ makes their products. Even for fully mature product lines, the little tweaks to the formulation a company makes can make a major difference in pricing and performance. This could make for a serious change in competitive status.

The public publishing of the formulations could have other consequences as well. There are a number of chemicals being used in the chemical industry that have raised concerns among environmental activists. If a formulation list included such chemicals the company could come under additional scrutiny from these activists, potentially leading to image issues. Worse yet, if any of the chemicals being used were on the lists of chemicals offensive to various environmental wacko fringe groups, the facility could become a target for varying degrees of physical attacks.

Control System Insecurity

From a security perspective the IP that is of more concern, however, would be process flow diagrams and control system working documents. Those pieces of information would make it much easier for an attacker that has gained access to the control system to figure out how to manipulate the controls in that system in a manner that could disrupt the facility in the worst possible way.

Since most corporate types use a single set of login credentials across the entire spectrum of company computer systems, it is very likely that even if the control systems were not directly breached in the attack, there would be useable log-in credentials for the control systems to be culled from the corporate log-ins. Once an attacker can gain legitimate access to a control system, the various ‘insecure-by-design’ problems become very large vulnerabilities.

If the control system had been directly breached as well the problems become much worse. The shut down and start-up of a chemical control system, particularly with continuous chemical processes like refineries, is not something that is done lightly or quickly. And searching control systems for logic bombs, back-doors, and forms of re-programing is a much more time consuming task than for an IT system of comparable size. The larger the number of PLCs involved the more difficult the task becomes.

Physical Insecurity

One set of computer data files that no one wants to see released are physical security plan files. Password and log-in credentials can be changed fairly easily, but making significant changes to a site security plan are very expensive and time consuming. The public availability of site security plans would make the facility much more susceptible to physical attack or theft of chemicals.

While there are some people that claim that the Sony attackers had at least some physical access to the corporate computer system that would not necessarily mean that that access included detailed information about the site security plan. Most folks entering a facility are aware of only a small part of the over-all security plan for the facility.

For many chemical manufacturing facilities a major source of security concerns can be found in the computer systems of the order handling folks. The timing and sourcing of inbound and outbound chemical shipments makes them that much more vulnerable to off-site attack. Those attacks may allow for inbound shipments to be intercepted and converted to a method of attack (VBIED) or simply diverted to some other nefarious or illegal end.

The Big Picture

The major take away from this attack is that this was no longer a hack to deface a web site, steal money or credentials. This was a full scale attack on a company with the intent of seriously harming the company for some as of yet unknown reason. The scope and scale of the attack is unlike anything we have seen in the corporate world. Unfortunately, as with all things cyber, it will undoubtedly set the new gold standard for serious attacks as it give other groups and hackers ideas about what can be accomplished with a successful cyber attack.