Thursday, July 20, 2017

Chemical Plants and Ransomware

There has been an interesting and on-going discussion on TWITTER® related to how chemical plants may be affected by ransomware like WannaCry. It was the result of the publication of two DHS-OCIA FOUO documents about WannaCry (here and here). They were published by PublicIntelligence.

The on-going TWITTER discussion was really based upon one entry in a chart in the second document described above; (U) Table 1—Ransomware Targeting and Susceptibility by Sector. The entry for the Chemical Sector contained the statement: “Chemical plants have manual overrides in place to ensure the safe containment of chemical processes in case cyber defenses fail. In some cases, it may be possible to run the chemical plant independently of cyber controls, otherwise the plant will most likely shut down.”

Most of the discussion has been on where the supporting data for that statement comes (short answer, no one knows) and how accurate that statement is. I cannot provide any information on the first, but a reasonable answer to the second will take more than 140 characters to explain.

Chemical Plant Automation


There is a great deal of variety in the level and sophistication of automation in chemical manufacturing processes. I have worked in a plant where there was absolutely no automation. Sensors were either analog or digital with no connections beyond a power supply. All operations are directly controlled by the operator manually operating various valves and power switches. Plants like this are unusual in this day and age. They are small plants typically running experimental processes on a shoestring budget. They are going to essentially be unaffected by ransomware except on the business process side of the house.

The most sophisticated facilities (and I have seen some of these, but never worked in one) have almost completely automated their chemical manufacturing processes. The extensive and complicated control system requires limited operator oversight; taking a wide mix of sensor data (temperature, pressure, flowrates and valve states for example) processes that data to develop (via a complex process control algorithm) commands to various operations devices (transfer valves, heating, cooling and vacuum controls for example) to control the manufacturing process. The operator actions are fairly limited to starting or stopping the process, making small manual adds of chemicals to the process and watching for process upset conditions.

Most specialty chemical manufacturing (batch processes) have a level of automation somewhere between these two extremes. An operator typically watches sensor data on a human machine interface (HMI) display and operates controls via the same HMI in response to a written set of instructions, training and experience. There may be some manual valve movements made by the operator or his assistants, but most are remotely operated via electrical or pneumatic operations.

Safety systems are in use (hopefully) in all plants regardless of the level of automation. They may be simple mechanical devices such as pressure relief valves or rupture disks. They could be process alarms that require operators to take manual corrective actions. They could be simple interlocks where a specific sensor output generates a direct command to operate a specific valve. Or they could be complex algorithmic responses to a variety of sensor readings resulting is a number of automatic operational changes to the process. These automated safety systems can reside in a stand-alone computer system with dedicated sensors and valves that are not in any way connected to the main process control system (the safest system) or various parts (or all of) the safety system could reside on the same computer system running the chemical manufacturing process.

In a perfect world, what determines the level of sophistication (and thus cost) of the safety system is the potential outcome of the process upset that it controls. The more serious the potential consequence of the process upset (again in a perfect world) the more complex and involved the safety system becomes. Where there are potential catastrophic, off-site consequences one would like to expect to see sophisticated stand-alone safety systems to prevent those catastrophic results.

Ransomware Effects


For purposes of this discussion I am going to assume that the ransomware has effected all networked controls system computers and that any stand-alone safety systems remain operational, these would include sophisticated systems, mechanical devices and most electro-mechanical interlocks (those not controlled through a PLC).

For the least automated systems the affects would be mainly cosmetic; operators would still be controlling the process, it would be more physical control with the operator going out and manually operating controls instead of using the HMI. This is assuming that there are still sensor readouts that do not go through the HMI. This would require either analog gauges or 4/20ma gauges wired to old-style displays.

Double displays with their associated wiring are a pain to maintain and frequently are considered a wasteful duplication of resources. The absence of analog gauges or non-computer sensor-output displays would mean that the operator would have no view of the key process control variables, and thus, no control of the process.

The consequences of going to full operator manual control of processes would be immense. I made the transition from full manual to semi-automated process control. We were able to add more sensors to better understand the process variables and those new sensors were in locations that were not readily accessible by the operator. Just those additional sensors decreased process times (and thus process costs) significantly as well as reducing product variability and off-spec products. We also significantly reduced the number of operators that were necessary to operate multiple processes that typically run at specialty chemical plants. Some plants would be able to operate at significantly reduced capacity, but increased product variability problem could have downstream quality effects on customer operations.

For fully automated chemical facilities (typically found in continuous process facilities like refineries) an instantaneous change to manual operation would not be possible. The lack of analog gauges and local sensor readouts and the relatively inaccessible manual controls would make it physically impossible for operators to coordinate the operation of the connected portions of the process in real time.

Safety Effects


Again, properly designed and implemented safety systems would be expected to stop any catastrophic consequences of sudden loss of control in chemical manufacturing systems. There were a number of very important qualifiers in that previous sentence. The major problem with designing safety systems is that it is very difficult to completely understand catastrophic failure modes in a manufacturing environment.

Typically, one has to use lab scale data to understand the physical parameters of those failure modes (NO ONE wants to do FULL SCALE testing of such failure modes) and then apply various models to try to scale up those test results to be able to plan for preventive actions to stop or mitigate the failures. No matter how sophisticated the modeling efforts they are, in the end, based upon educated guesses as to how the system will behave. Then systems are designed to try to best control those failure modes. And, it is not generally acceptable to really test those systems to see how they actually work in practice (in the emergency environment).

The OCIA Statement


The OCIA statement that started this discussion is almost certainly not based upon any survey of the chemical industry. It is a reasonable brief attempt by outsiders with a non-chemical manufacturing background to categorize the potential consequences of a non-chemical emergency event on generic chemical manufacturing.

If I were to attempt to reword this statement from a chemical manufacturing process point of view, it would read something like this:

“Chemical manufacturing facilities should have safety systems in place to contain catastrophic consequences in the event of loss of control. The efficacy of those systems and their operation in an instantaneous loss of computer control situation would have to be evaluated on a case-by-case basis. Continued commercial production without replacing/fixing affected computer based process controls could be possible is some unknown number of facilities. It would be difficult to accurately predict which facilities could continue commercially viable production.”


Bills Introduced – 07-19-17

Yesterday, with both the House and Senate in session, there were 54 bills introduced. Of these only one may be of specific interest to readers of this blog:

H Res 459 Expressing the sense of the House of Representatives that the United States should support the development of programs that better prepare students for careers in cybersecurity by actively promoting ethical hacking skills. Rep. Garrett, Thomas A., Jr. [R-VA-5]


Generally speaking, ‘sense of Congress’ resolutions are fairly meaningless political statements with no practical effect. I will be watching this one, however, to see how it is worded and what definitions, if any, it uses. I do not expect that it will actually see consideration in committee or on the floor of the House.

Wednesday, July 19, 2017

Bills Introduced – 07-18-17

Yesterday with both the House and Senate in session there were 27 bills introduced. One of those may be of specific interest to readers of this blog:

HR 3282 To amend title 49, United States Code, with respect to electronic logging devices, and for other purposes. Rep. Babin, Brian [R-TX-36]


I will only be providing additional coverage of this bill if it includes specific language addressing chemical transportation or if it contains cybersecurity provisions.

Tuesday, July 18, 2017

ICS-CERT Publishes Advisory and Updates Another

Today the DHS ICS-CERT published a new control system security advisory for products from Rockwell. They also updated another control system security advisory for products from Siemens. The Rockwell advisory was originally published in the NCCIC Portal on May 18, 2017.

Rockwell Advisory


This advisory describes an improper input validation vulnerability in the Rockwell MicroLogix 1100 Controllers. The vulnerability was reported by Mark Gondree of Sonoma State University, Francisco Tacliad and Thuy Nguyen of the Naval Postgraduate School. Rockwell has a newer firmware version that mitigates the vulnerability. There is no indication that any of the researchers have been provided an opportunity to verify the efficacy of the fix.

ICS-CERT does not provide any information on skill level or type access required to exploit this vulnerability. They just note that a successful exploit could lead to a denial of service condition.

Siemens Update


This update provides additional information on an advisory that was originally published on July 6th, 2017. The new information included updated version information for:

• Firmware variant Modbus TCP: All versions prior to V1.10.01,
• Firmware variant DNP3 TCP: All versions prior to V1.03, and
• SIPROTEC 7SJ66: All versions prior to V4.23
• SIPROTEC 7SJ686: All versions prior to V4.86
• SIPROTEC 7UT686: All versions prior to V4.01
• SIPROTEC 7SD686: All versions prior to V4.04

The only change seen in the security reporting from Siemens was affected version information and the update link for DNP3 TCP. The other updated version information was provided in the ‘Mitigation’ section of the earlier ICS-CERT version of the advisory, but not in the ‘Affected Products’ section.

Commentary


I have not done an actual tally to confirm this, but it seems to me that we see a much higher percentage of Rockwell product advisories making it to the NCCIC (or the old US-CERT) secure portal before being publicly disclosed than we do for Siemens products. Since it is not clear how this decision is made for limited disclosure, it would be unfair to say something untoward was happening; but, it does seem odd.


If the decisions are made based upon company requests for the delay, then this is a marketing call by the respective companies with no foul noted. If the decision is being made just by ICS-CERT, then the community probably deserves some process explication.

HR 3101 Introduced – Port Cybersecurity

Last month Rep. Torres (D,CA) introduced HR 3101, the Strengthening Cybersecurity Information Sharing and Coordination in Our Ports Act of 2017. The bill establishes a number of modest cybersecurity requirements for (and in support of) port operations.

Federal Requirements


Section 2 of the bill establishes federal requirements for cybersecurity risk assessments, information sharing and coordination. First it requires DHS to conduct (and subsequently evaluate) a risk assessment for maritime cybersecurity based upon the NIST Cybersecurity Framework. Next, it requires DHS to ensure that at least one maritime information sharing analysis committee (ISAC) participates in the National Cybersecurity and Communications Integration Center.

Paragraph (4) requires DHS to establish “guidelines for voluntary reporting of maritime-related cybersecurity risks and incidents (as such terms are defined in section 227 of the Homeland Security Act of 2002 (6 U.S.C. 148)) to the Center [NCCIC]”. The next paragraph then requires DHS to “to report [on] and make recommendations to the Secretary on enhancing the sharing of information related to cybersecurity risks and incidents between relevant Federal agencies and State, local, and tribal governments”.

Local Requirements


Section 3 of the bill establishes local cybersecurity requirements. First it requires each Maritime Security Advisory Committee “to facilitate the sharing of cybersecurity risks and incidents to address port-specific cybersecurity risks, which may include the establishment of a working group of members of Area Maritime Security Advisory Committees to address port-specific cybersecurity vulnerabilities” {§2(1)}. Next it requires all new maritime or facility security plan (under 46 USC 70103) to “include a mitigation plan to prevent, manage, and respond to cybersecurity risks” {§2(2)}.

Specifically §4 amends two separate provision of 46 USC {§70102(b)(1)(C) – facility and vessel assessments – and §70103(c)(3)(C) – vessel and facility security plans} by adding the word “cybersecurity” after “physical security”. It would also add a requirement for vessel and facility security plans to address the “prevention, management, and response to cybersecurity risks” {new §70103(c)(3)(C)(v)}.

Moving Forward


While Torres is not a member of either committee to which the bill has been assigned for consideration, two of her cosponsors are {Rep. Correa (D,CA) – Homeland Security; and Rep. Wilson (D,FL) – Transportation and Infrastructure}. This means that there is at least a chance that either or both of these committees could consider HR 3101.

I do not see anything in the bill that would engender any significant opposition. If the bill were to be considered on the floor of the House it is likely that it would pass, probably under the suspension of the rules provision.

Commentary


Once again, the provisions of this bill rely on the 6 USC 148(a)(1) definition of ‘cybersecurity risk’, a definition that is limited to information systems and does not include control systems. This would mean that the requirements of this bill would not apply to operation of any of the many critical control systems found on vessels or in maritime facilities.


I would again like to point to a solution to this definitional problem in port cybersecurity legislation that I proposed in an earlier blog post. It would still use the existing, IT-centric, definition of ‘information system’, but would add a new definition for ‘control system’ and then combine both terms in the definition of ‘cybersecurity risk’.

Committee Hearings – Week of 7-16-17

With both the House and Senate in session there is a wide slate of congressional hearings this week. Spending bills are finishing up in the House and the Senate continues to plug away on nomination hearings. There are two cybersecurity hearings of potential interest, one a markup and one addressing energy security.

Spending Bills


The House Appropriations Committee is still working on ginning out their spending bills with two more hearings being conducted during the remainder of the week:


Cybersecurity Mark-up


On Wednesday the Digital Commerce and Consumer Protection Subcommittee of the House Energy and Commerce Committee will mark-up a staff draft of a bill on highly automated vehicle testing and deployment. The Committee Draft of the bill contains a section on “Cybersecurity of automated driving systems” which I will try review later today.

Energy Security


Later this morning the Senate Energy and Natural Resources Committee will hold a hearing to examine the status and outlook for U.S. and North American energy and resource security. Cybersecurity is certainly going to be part of this discussion. The witness list includes:

• Fatih Birol, International Energy Agency;
• Stephen Cheney, American Security Project;
• Robert Coward, American Nuclear Society;
• Dan McGroarty, Carmot Strategic Group;
• Mark Mills, Manhattan Institute; and
• Jamie Webster, Center for Energy Impact

On the Floor of the House


Today the House will consider HR 3050, Enhancing State Energy Security Planning and Emergency Preparedness Act of 2017, under their suspension of the rules procedure. This means that there will be limited debate and no amendments will be considered. This usually means that the House leadership considers this to be a non-controversial bill with a high-probability of passage (which requires a super-majority). NOTE: The committee report on the bill has not yet been published, it will probably be submitted today, but will not actually be available on the Congress.gov site until later this week.


NOTE: The House Rules Committee called for amendments to HR 2997, 21st Century Aviation Innovation, Reform, and Reauthorization Act. This is the House version of the FY 2018 FAA reauthorization. I have not published a review of this bill yet because there is currently nothing of real interest included in the introduced version. It looks like that will be changing. No hearing is scheduled yet, but it may happen later this week.

Bills Introduced – 07-17-17

With both the House and Senate in session there were 20 bills introduced yesterday. Of those, three may be of specific interest to readers of this blog:

HR 3266 Making appropriations for energy and water development and related agencies for the fiscal year ending September 30, 2018, and for other purposes. Rep. Simpson, Michael K. [R-ID-2]

HR 3267 Making appropriations for the Departments of Commerce and Justice, Science, and Related Agencies for the fiscal year ending September 30, 2018, and for other purposes. Rep. Culberson, John Abney [R-TX-7]

HR 3268 Making appropriations for Agriculture, Rural Development, Food and Drug Administration, and Related Agencies programs for the fiscal year ending September 30, 2018, and for other purposes. Rep. Aderholt, Robert B. [R-AL-4]

As with all spending bills, I will be watching these for potential cybersecurity provisions.


Monday, July 17, 2017

ISCD Publishes COI Flyer for CFATS Customers

Today the DHS Infrastructure Security Compliance Division published a new flyer for its Chemical Facility Anti-Terrorism Standards (CFATS) program. They flyer is designed to be provided to customers of CFATS facilities that receive shipments of DHS chemicals of interest (COI) from the covered facility to notify those customers that they might have CFATS reporting responsibilities.

A link to the flyer can be found on the CFATS landing page. There, ISCD explains the purpose of the flyer:

“Update (July 2017): Chemical security is a responsibility that DHS shares with chemical facility owners and operators, employees, and emergency responders. DHS created a flyer for facilities shipping, selling, or distributing a CFATS Chemical of Interest (COI) to notify their customers to report their chemical holdings to DHS. Please download, print, and distribute the Receiving a COI Flyer as a resource to increase awareness of the CFATS program to new segments of the population who hold COI.”

A different link to the same flyer can be found on the CFATS Knowledge Center. ISCD announces that link with this ‘Latest News’ entry:

“ISCD has published a flyer that facilities may choose to use when selling or shipping COI to notify customers that they may need to report their holdings to DHS. Facilities are not required to share this flyer, but are encouraged to let facilities that sell, ship, or distribute COI know about this resource during the course of a normal engagement. Please contact CFATS@hq.dhs.gov with any and all questions.”

ISCD emphasizes that the use of the flyer is completely voluntary. They are just trying to expand their outreach program to ensure that all potentially covered facilities are aware of the reporting requirements for the CFATS program.

Commentary


This is a fairly straightforward one-page flyer without a lot of graphics or bells and whistles. I think, however, that ISCD has gone a little too much on the simple side. Much of the write-up assumes that the reader has some basic understanding of the ins and outs of the CFATS program. For example, in bold type (for emphasis) the flyer states: “Facilities that come into possession of screening threshold quantities of COI must report their holdings to DHS within 60 days by filing a Top-Screen survey.” There is no real explanation of why chemicals are COI or what a ‘screening threshold quantity’ is, it simply provides a link to the Appendix A table that lists the COI’s and the complex set of regulatory data that are associated with them in the CFATS program.

It would have been much more helpful if the flyer provided links to the various parts of the CFATS web site that describe these complex topics; for example, the CFATS Covered Facility web page.


Still, I am glad to see that ISCD is continuing to look for new ways to ensure that potentially covered facilities are aware of the CFATS initial reporting requirements.

S 1405 Introduced – FY 2018 FAA Authorization

Last month Sen. Thune (R,SD) introduced S 1405, the Federal Aviation Administration Reauthorization Act of 2017. This year’s bill includes one cybersecurity provision and a large number of provisions concerning unmanned aircraft systems (UAS). The UAS related items that may be of specific interest to readers of this blog include:

§2105. Analysis of current remedies under Federal, State, and local jurisdictions.
§2123. Small unmanned aircraft safety standards.
§2126. Additional rulemaking authority.
§2128. Special rules for model aircraft.
§2129. Authority.
§2133. Airport safety and airspace hazard mitigation and enforcement.
§2151. Federal and local authorities.
§2163. Unsafe operation of unmanned aircraft.

Cybersecurity


Section 4109 of the bill would require the FAA revise existing aircraft certification regulations to include {§4109(a)}:

• To address cybersecurity for avionics systems, including software components; and
• To require that aircraft avionics systems used for flight guidance or aircraft control be secured against unauthorized access via passenger inflight entertainment systems through such means as the Administrator determines appropriate to protect the avionics systems from unauthorized external and internal access.

The new regulations would be based upon work of the Aircraft Systems Information Security Protection Working Group as directed by Congress last year in §2111 of PL 114-190 (130 Stat 626).

Model Aircraft


Section 2128 of the bill adds a new §44808 (Special rules for model aircraft) to 49 USC. That section modifies and then codifies the model aircraft rules established in §336 of the FAA Modernization and Reform Act of 2012 (PL 1125-95, 126 Stat 77).

The ‘operational parameters’ in paragraph (a) have been expanded by including the following requirements for the model aircraft exemption {new §44808(a)}:

• Not flown beyond the visual line of sight of persons co-located with the operator or in direct communication with the operator;
• The aircraft is flown from the surface to not more than 400 feet in altitude, except under special conditions and programs established by a community-based organization; and
• The operator has passed an aeronautical knowledge and safety test administered by the Federal Aviation Administration online for the operation of unmanned aircraft systems subject to the requirements of section 44809 or developed and administered by the community-based organization and maintains proof of test passage to be made available to the Administrator or law enforcement upon request.

The FAA is further provided the authority to modify the operational parameters defined in the bill ‘as appropriate’. Paragraph (b)(2) provides an expansive list of considerations that the FAA might use to change those parameters.

Paragraph (d) of the new section provides the FAA with permissive authority to “promulgate rules relating to the registration and marking of model aircraft”. Furthermore, §2129 of the bill specifically re-instates the registration and marking requirements for small unmanned aircraft published by the FAA in December, 2015 and were recently vacated by the United States Court of Appeals for the District of Columbia Circuit in Taylor v. Huerta (No. 15–1495).

Regulation of UAS Operations


Section 2105 requires the Government Accountability Office (GAO) “a review of the privacy issues and concerns associated with the operation of unmanned aircraft systems in the national airspace system”. Additionally, it tasks the GAO with identifying “specific issues and concerns that may limit the availability of existing civil or criminal legal remedies regarding inappropriate operation of unmanned aircraft systems in the national airspace system” {§2105(2)}.

Section 2123 addresses setting safety standards for UAS. It would add a new §44803 to 49 USC (Small unmanned aircraft safety standards). It would require the FAA to establish a rulemaking advisory committee to develop recommendations for regulations to establish {§44803(a)(1)}:

• Risk-based, consensus safety standards related to the safe integration of small unmanned aircraft systems into the national airspace system (referred to in this section as ‘consensus safety standards’) that can evolve or be updated as appropriate; and
• A Federal Aviation Administration process for permitting, authorizing, or approving small unmanned aircraft systems and their operations based on the safety standards to be accepted by the Administrator under this section.

The FAA would then be responsible for implementing those recommendations by establishing a process for {new §44803(d)}

• The acceptance by the Federal Aviation Administration of consensus safety standards recommended;
• Permitting, authorizing, or the approving small unmanned aircraft systems makes and models based upon the consensus safety standards; and
• The certification of a manufacturer of small unmanned aircraft systems that has demonstrated compliance with consensus safety standards.

These safety standards would also specifically apply to model aircraft {new §44803(f)}.

Mitigating Unsafe UAS Operations


Section 2133 would add a new §44810 to 49 USC. That new section would require the FAA to “develop a plan for the certification, permitting, authorizing, or allowing of the deployment of technologies or systems for the detection and mitigation of unmanned aircraft systems” {new §44810(b)(1)}. The implemented plan would “allow appropriate officials of Federal, State, or local agencies requesting to utilize such technologies or systems to take steps to detect and mitigate potential airspace safety threats posed by unmanned aircraft system operations §44810(b)(2)}.

The section goes on to clearly state that the following federal statutes would not apply the operation of these ‘technologies or systems’ {new §44810(h)}:

18 USC 32 – Destruction of aircraft or aircraft facilities;
18 USC 1030 (the bill actually says ‘1031’, an obvious error) – Fraud and related activity in connection with computers;
18 USC Chapter 119 – Wire and electronic communications interception and interception of oral communications; and
18 USC Chapter 206 – Pen registers and trap and trace devices

Section 2163 would make it a federal crime to unsafely operate an ‘unmanned aircraft’. It would add a new section 39B to 18 USC. It would make it a federal offense to operate an unmanned aircraft in a manner that “knowingly or recklessly interferes with, or disrupts the operation of, an aircraft carrying 1 or more occupants operating in the special aircraft jurisdiction of the United States, in a manner that poses an imminent safety hazard to such occupants” {new §39B(a)}.

Committee Mark-Up


On June 29th the Senate Commerce, Science, and Transportation Committee held a mark-up hearing that included the mark-up of S 1405. In that hearing 57 amendments, including substitute language from Chairman Thune, were offered and presumably adopted (though there is no indication on the Committee web site of the status of actions taken). The substitute language made no changes of significance to the provisions previously discussed. There was one amendment from Sen. Johnson (R,WI) that may be of specific interest here.

Johnson’s amendment would add a new §44816 to 49 USC, Unmanned aircraft systems in restricted buildings or grounds. This amendment mirrors current restrictions found in 18 USC 1752 against unauthorized entry of the White House or other grounds where the President (or other persons protected by the Secret Service) is present. It would apply similar legal penalties for flying UAS in such areas.

The amendment further expands upon the §1752 coverage by adding the phrase “impede or disrupt the orderly conduct of Government business or official functions” {new §44816(a)} with respect to UAS operations.

Violation of the new section would be punishable under 18 USC by fines and/or up to one year in prison, unless the offense included mounting a weapon on the UAS or caused serious bodily harm. Then the maximum sentence would be fines and/or up to ten years in prison.

Moving Forward


The FAA reauthorization is one of the ‘must complete’ actions for Congress each year, though that does not specifically apply to this particular bill. A House version of this bill has yet to be offered, but will ultimately happen. Each branch of Congress will pass their own version of an FAA reauthorization bill and a conference committee will iron out the differences. There is always the possibility of short-term continuing-authorization bills being passed.

Commentary


I am very happy to see that this bill provides not only authority, but specific requirements for the FAA to regulate the cybersecurity of aircraft control systems. I am disappointed, however, in the failure to require specific rules regarding the reporting of cybersecurity attacks (with an appropriate definition of what constitutes an attack) or the discovery of security vulnerabilities in avionics software or devices. Additionally, I would have liked to have seen a specific requirement for regulated air carriers and aircraft (and avionic system) manufacturers to be members of some sort of recognized cybersecurity information sharing organization.

The bill finally addresses one of the major issues related to enforcing UAS operation regulations, the fact that any attempts to immediately stop a UAS from illegal operation (not completely defined by this bill) would almost certainly involve violation of a number of federal criminal statutes.

I am not sure, however, that offering a blanket exemption to those laws is quite the right way to proceed. I would have preferred the bill to require the FAA to establish specific ground rules where such exemptions applied. The way that §2133 is written does not just limit the use of the developed ‘technologies and systems’ to the areas around airports. They would generally apply to any counter-UAS operations conducted by “Federal departments and agencies to detect and mitigate potential threats posed by errant or hostile unmanned aircraft system operations” {new §44810(a)} or more generally by “appropriate officials of Federal, State, or local agencies requesting to utilize such technologies” {new §44810(b)(2)}.

The Johnson amendment is an overly broad extension of current presidential security rules. While arguments could certainly be made to support allowing the Secret Service to control the use of UAS around the White House and presidential functions, the inclusion of the ‘orderly conduct of Government business’ language could have a chilling effect on freedom of speech and be a broad tool to counter civil disobedience usage of UAS.


Finally, there is curiously lacking any mention of potentially applying flight restrictions to UAS operations above or around critical infrastructure or other restricted areas. Actually, what I would prefer to see would be to specifically disallow the operation of UAS over or around facilities where the federal government currently regulates security (for example: CFATS, MTSA and CIP regulated facilities) with the specific permission of the facility owners/operators. This would avoid the vague definition of ‘critical infrastructure’.

Saturday, July 15, 2017

Bills Introduced – 07-15-17

Yesterday with only the House in Washington there were 26 bills introduced. Of those only one may be of specific interest to readers of this blog:

HR 3259 To prohibit the use of Federal funds for the establishment or support of a cybersecurity unit with the Russian Federation, and for other purposes. Rep. Speier, Jackie [D-CA-14]


As with HR 3191 and S 1544 this is almost certainly more of a political statement than a viable attempt at legislation, but it will be followed here due to its potential effects on cybersecurity activities in the federal government.

ICS Public Disclosures – Week of 07-08-17

This week we have two public disclosures from vendors. The first is an interesting update of information from ABB and the second is a fresh self-disclosure from OSIsoft.

ABB Update


ABB published their security advisory for their VSN300 Wi-Fi Logger Card; these were earlier reported by ICS-CERT. There was no link to the ABB advisory in the ICS-CERT advisory because it was published two days later. The importance of the ABB advisory is that it includes exploit code for the two reported vulnerabilities; an unusual move for a vendor.

The publication of the exploit code needs to be taken into account in the risk analysis done by owners in their decision as to whether or not they will be updating the Card firmware.

It will be interesting to see if ICS-CERT updates their advisory.

Thanks to Joel Langill for pointing out the publication of this advisory.

OSIsoft Advisory


OSIsoft announced this week the publication of security updates for their PI Integrator For Business Analytics 2016, PI Integrator for Microsoft Azure 2016, and PI Integrator for SAP HANA 2016 products with new versions of all three being made available.

The new versions correct two self-identified vulnerabilities:

• Improper Neutralization of Input During Web Page Generation; and
• Improper Authorization


OSIsoft reports that: “An unauthorized user could gain privileged access to the PI Integrator application and views of PI System data. A miscreant could also store malicious script in the application database and subsequently execute it on the targeted user's machine.”

Friday, July 14, 2017

House Passes HR 2810 – FY 2018 NDAA

Today the House passed HR 2810, the FY 2018 National Defense Authorization Act (NDAA) by a substantially bipartisan vote of 344 to 81. All four cyber-related amendments passed by voice votes.

The bill passed today will not be considered in the Senate. The Senate will take up their own version of the NDAA (S 1519) perhaps as soon as next week. Once the amendment process in the Senate is complete, a conference committee will be appointed to work out the differences in the two bills.

Trump Administration Submits 911 Grant Revision Regulations to OMB

The OMB’s Office of Information and Regulatory Affairs (OIRA) announced Wednesday that both the DOT’s National Transportation Safety Administration (NTSA) and the DOC’s National Telecommunications and Information Administration have submitted separate notice of proposed rulemakings (NPRMs) implementing changes to the 911 Grant Program. These rulemakings were not included in the Obama Administration’s Fall 2016 Unified Agenda and the Trump Administration has yet to publish their Spring 2017 Unified Agenda.


I’ll be watching to see if these NPRM’s address cybersecurity measures for 911 programs.

Bills Introduced – 07-13-17

Yesterday with both the House and Senate in session, there were 51 bills introduced. Of those, two may be of specific interest to readers of this blog:

HR 3219 Making appropriations for the Department of Defense for the fiscal year ending September 30, 2018, and for other purposes. Rep. Granger, Kay [R-TX-12]

HR 3240 To improve the productivity and energy efficiency of the manufacturing sector by directing the Secretary of Energy, in coordination with the National Academies and other appropriate Federal agencies, to develop a national smart manufacturing plan and to provide assistance to small- and medium-sized manufacturers in implementing smart manufacturing programs, and for other purposes. Rep. Welch, Peter [D-VT-At Large]

As usual I will be watching the Defense spending bill for cybersecurity matters. A copy of the bill is already available, but I am still waiting on the copy of the Committee Report to be published.


HR 3240 is probably a bit of a long shot for coverage here. ‘Smart Manufacturing’ should mean automation and use of the industrial internet of things (IIoT) so I would hope (but probably not expect) that this bill would also include ICS cybersecurity provisions.

Thursday, July 13, 2017

ICS-CERT Publishes 3 Advisories

Today the DHS ICS-CERT published three control system security advisories for products from Siemens (2) and GE. They also published the latest version of the ICS-CERT Monitor and a new FY 2016 Assessment Report.

SIMATIC Advisory


This advisory describes two vulnerabilities in the Siemens SIMATIC Sm@rtClient Android App. The vulnerabilities were reported by Karsten Sohr and Timo Glander from the TZI at the University of Bremen. Siemens has released a new version to mitigate the vulnerabilities. There is no indication that the researchers have been provided an opportunity to verify the efficacy of the fix.

The two vulnerabilities are:

• Channel accessible by non-endpoint - CVE-2017-6870; and
• Authentication bypass using alternative bypass or channel - CVE-2017-6871

ICS-CERT reports that a relatively low skilled attacker could remotely exploit the vulnerability to read and modify data within a Transport Layer Security TLS session. The Siemens security bulletin reports that the second vulnerability requires “physical access to an unlocked mobile device”.

GE Advisory


This advisory describes a heap-based buffer overflow vulnerability in the GE Communicator application. The vulnerability was reported by Kimiya, working with iDefense Labs. GE recommends upgrading to the newst version that mitigates the vulnerability. There is no indication that Kimiya was provided an opportunity to verify the efficacy of the fix.

ICS-CERT reports that a relatively low skilled attacker could remotely exploit the vulnerability to execute arbitrary code or create a denial-of-service condition.

Comment: Once again a previously released version (revision date 02-18-17) fixes a security issue that was not identified in the Release notes. Remarkably lucky programmers that could fix an unidentified problem. Those release notes did identify another vulnerability in earlier versions that was corrected but has not apparently been reported to ICS-CERT; an unused software graphic library which was identified as a potential Microsoft® ActiveX security vulnerability.

SiPass Advisory


This advisory describes multiple vulnerabilities in the Siemens SiPass integrated access control system. Siemens is self-reporting the vulnerabilities. Siemens has produced a new version that mitigates the vulnerabilities.

The reported vulnerabilities are:

• Improper authentication - CVE-2017-9939;
• Improper privilege management - CVE-2017-9940;
• Channel accessible by non-endpoint - CVE-2017-9941; and
• Storing passwords in a recoverable format - CVE-2017-9942

ICS-CERT reports that a relatively low skilled attacker with unauthenticated network access could remotely exploit these vulnerabilities to perform administrative operations.

ICS-CERT Monitor


The ICS-CERT Monitor for May-June 2017 provides a little more useful information than we have been seeing in this publication of late. There are two brief but informative articles that should be read by all facility security managers:

• Data Classification for Recovery Planning (pg 2); and
• Cybersecurity Defense (pg 2)

The first outlines the risk assessment process used to determine backup rates for data. The second briefly discusses the importance of wet-ware (personnel) training to aid the security process. Both could have been fleshed out quite a bit, but given the glossy corporate report format that really is not practical. It would be helpful if ICS-CERT (or someone) did a fact sheet or white paper on both of these important topics. If someone knows of one, please point me at it.

FY 2016 Assessment Report


Well, the FY 2016 Assessment Report is not be published quite as late in the year as the 2015 report was, but you have to wonder why it took so long to publish such an uninformative 20 page report. If you read my review of the 2015 report, you already know most of the problems with this version.

One disheartening fact did jump off the page a scream at me, ‘Physical Access Control’ jumped back onto the ‘Top Six Weakness’ categories reported in the 130 assessments conducted last year. Again, you have to be careful of the numbers here because it is quite possible that some of the facilities had more than one assessment (three different assessment types) conducted.


Oh well, read it. Be careful of how much respect you give for the individual numbers (and those will be much hyped in the main stream and cybersecurity press), but look for the small pieces of valuable information (for example on page 11 “Keys allowing physical access may be out of the facilities’ control, possibly allowing unauthorized personnel to access critical or sensitive areas.”).

HR 2810 Considered in House – Four Cyber Amendments Passed

Yesterday the House began consideration of HR 2810, the FY 2018 National Defense Authorization Act. All four of the cyber related amendments that I described yesterday were passed by voice votes as part of four separate en bloc amendments. The House tries to group uncontroversial amendments into groups to reduce the amount of time taken up in the debate/vote process.


• Thornberry en bloc 1 (Pages H5737–44) (included #22);
• Thornberry en bloc 3 (Pages H5749–53) (included #56); and
• Thornberry en bloc 4 (Pages H5753–56) (included #80 and #81)

The House is continuing consideration of HR 2810 today.

ISCD Publishes CFATS Emergency Response Fact Sheet

Today the DHS Infrastructure Security Compliance Division (ISCD) posted a new fact sheet on the Chemical Facility Anti-Terrorism Standards (CFATS) Knowledge Center.  The fact sheet deals with the implementation of Risk-Based Performance Standard (RBPS) #9, Response in developing a site security plan (SSP) for a CFATS covered facility.

Generally speaking, there not much new here that is not already covered (in slightly more detail) in the RBPS Guidance Document. The one exception is that the fact sheet stresses that there are differences between Security Response Plans and Emergency Response Plans, but that both are required portions of the response planning necessary for site security plans.

One piece of discussion is glaringly missing from the Fact Sheet, the need to plan for backup power, communications and process safeguards. Physical attacks (and natural disasters) are very likely to have negative affects upon these critical areas and any response or recovery plan is going to have to address those necessities.

Both documents fail to completely address coordination with State and local authorities. While they do mention fire, police and emergency medical services, they fail to discuss the role of Local Emergency Planning Committees (LEPCs) in emergency response planning. While not every community has an active LEPC, CFATS facilities should make a positive effort to reach out to whatever LEPC is active in their community to ensure that adequate coordination is made between all effected and affected agencies.


Finally, local hospital emergency departments (with an emphasis on multiple facilities) in the area need to be notified of any chemicals held on site that could require specific (and/or unusual) medical technologies to treat exposed individuals. Where expensive and/or short-shelf-life kits (see my discussion about cyanide kits, for example) the local medical community needs to be aware of these measures so that they can either ensure there is a local stockpile available or that  appropriate sharing agreements are initiated.

S 1475 Introduced – Cyber Hygiene

Last month Sen. Hatch (R,UT) introduced S 1475, the Promoting Good Cyber Hygiene Act of 2017. This is very similar to HR 3010. While not strictly a companion measure (due to changes in formatting, word order and organization) this bill would establish the same voluntary cybersecurity program; principally for use by the Federal Government.

Moving Forward


Unlike the sponsorship situation with HR 3010, Sen. Markey (D,MA), a cosponsor of this bill, is a member of the Senate Commerce, Science, and Transportation Committee (Hatch is not) so there is a possibility that this bill could be considered by that Committee.

Markey has worked hard on establishing a reputation as a cybersecurity gadfly (I use that term with a certain amount of admiration) in the Senate. Unfortunately, his scattergun approach to crafting cybersecurity language has left him with a significant amount of inherent opposition to his bills; none of the bills that he has offered to date (admittedly still early in the session) has been considered in Committee.

Commentary



This bill sounds good, but, like its companion, it has some serious definition problem in the IoT provisions. That ICS-inclusive definition has essentially no effect on the study required because that study is to be to consider the effects of the identified cybersecurity concerns upon Federal IT systems.

S 1519 Introduced – FY 2018 NDAA

Earlier this week Sen. McCain (R,AZ) introduced S 1519, the National Defense Authorization Act for Fiscal Year 2018. The bill has already been marked up in the Senate Armed Services Committee. The House version of this bill is currently being considered on the floor of the House. The bill includes a number of cyber provisions.

Those provisions include:

§510. Service credit for cyberspace experience or advanced education upon original appointment as a commissioned officer.
§1042. Department of Defense integration of information operations and cyber-enabled information operations.
§1621. Policy of the United States on cyberspace, cybersecurity, and cyber warfare.
§1622. Cyber posture review.
§1623. Modification and clarification of requirements and authorities relating to establishment of unified combatant command for cyber operations.
§1624. Annual assessment of cyber resiliency of nuclear command and control system.
§1625. Strategic Cybersecurity Program.
§1626. Evaluation of agile acquisition of cyber tools and applications.
§1627. Report on cost implications of terminating dual-hat arrangement for Commander of United States Cyber Command.
§1628. Modification of Information Assurance Scholarship Program.
§1629. Measuring compliance of components of Department of Defense with cybersecurity requirements for securing industrial control systems.
§1630. Exercise on assessing cybersecurity support to election systems of States.
§1630A. Report on various approaches to cyber deterrence.
§1630B. Prohibition on use of software platforms developed by Kaspersky Lab.

Only one of these provisions (§1629) specifically addresses industrial control system operations.

ICS Compliance


Section 1629 requires DOD to modify its Cyber Scorecard (part of the DOD Cybersecurity Discipline Implementation Plan) to specifically address securing “the industrial control systems of the Department against cyber threats, including supervisory control and data acquisition systems (SCADA), distributed control systems (DCS), programmable logic controllers (PLC), and platform information technology (PIT)” {§1629(a)}.

Kaspersky Lab


Section 1630B is the much-publicized prohibition of DOD use or continued use products from the Kaspersky Lab. There is nothing in the language of §1630B (or in the Committee Report on the bill) that explains the reason for the prohibition.

Moving Forward


This bill is one of the ‘required’ bills that will be passed each year. The bill will be taken up by the Senate, probably before the summer recess starts in August. The process will include a substantial number of amendments to be considered. Once the bill passes in the Senate, a conference committee will take up the differences between the House version (HR 2810) and this bill.

Commentary


If the §1629 provisions make it into the final bill, DOD will have to substantially re-write their Cybersecurity Discipline Implementation Plan. The current document is IT-centric with no mention of control systems or their unique security issues.


The Kaspersky provision is pure political theater; anti-Russian posturing at its worst. Interestingly, the ‘immediately’ provisions of the section do not become effective until October 1st, 2018 {§1630B(c)}, theoretically one year after this bill becomes effective. I suspect that this unusual provision was added to allow calmer heads to remove this requirement after the political capital is harvested.

FAA ICR Revision for Closing Small Drone Registration

Today the OMB’s Office of Information and Regulatory Affairs (OIRA) announced the emergency approval of a change to the information collection request (ICR) supporting the FAA’s Small Unmanned Aircraft Registration System program. The change was requested in order for the FAA to comply with a recent court finding that the registration program was not legal.

According to the supporting document [.DOCX download link] submitted to OIRA:

“With respect to this update to the information collection, as a result of the May 19, 2017 ruling by the U.S. Court of Appeals for the District of Columbia Circuit, the Small UAS Registration and Marking interim final rule was vacated to the extent it applies to model aircraft. Model aircraft must meet the definition and operational requirements provided in section 336 of the FAA Modernization and Reform Act. Owners who are operating exclusively in compliance with section 336 who wish to de-register and receive a refund of the registration fee may do so by requesting de-registration from the FAA, which requires the FAA to collect their payment information.”

A new form [.DOCX download link] was included in the ICR revision submission. This form will be used by ‘model aircraft’ owners to de-register. It includes seven certification check-offs used to ensure that the registrant is flying a UAV in accordance with the ‘model aircraft’ provisions of §336 of the FAA Modernization and Reform Act (PL 112-95, 126 Stat 77-78). Commercial small aircraft registrants may not use this process to de-register as they were no covered in the court ruling.


I expect that we will see something in the Federal Register in the coming days addressing this de-registration process.

Bills Introduced – 07-12-17

Yesterday with both the House and Senate in session there were 46 bills introduced. Of those, four may be of specific interest to readers of this blog:

HR 3191 To prohibit the use of Federal funds to establish, support, or otherwise promote a joint cybersecurity initiative with Russia, and for other purposes. Rep. Boyle, Brendan F. [D-PA-13]

HR 3198 To provide for Federal Aviation Administration research and development, and for other purposes. Rep. Knight, Stephen [R-CA-25]

HR 3202 To require the Secretary of Homeland Security to submit a report on cyber vulnerability disclosures, and for other purposes. Rep. Jackson Lee, Sheila [D-TX-18]

S 1544 A bill to prevent Federal funds from being used to establish a cybersecurity unit in cooperation with the Russian Federation.  Sen. Klobuchar, Amy [D-MN]

HR 3191 and S 1544 are almost certainly political statements rather than a serious attempt at legislating, but they will be followed here for their potential effects on cybersecurity programs of the US government.

HR 3198 will only be followed if it includes cybersecurity provisions.


I will be watching HR 3202 for possible specific language related to industrial control systems.

Wednesday, July 12, 2017

Rule for Consideration of HR 2810 – FY 2018 NDAA

Last night the House Rules Committee completed their work on the rule for consideration of HR 2810, the FY 2018 National Defense Authorization Act. The bill will be considered under a structured rule with only 88 of the 434 submitted amendments to be considered on the floor of the House.

Of those 88 amendments only four deal with cyber issues. Those amendments are:

22. Johnson, Mike (LA) #329 (REVISED) Requires the Army to conduct a report on the Army Combat Training Centers and the current resident cyber capabilities and training at such bases to examine potential training readiness shortfalls and pre-rotational cyber training needs are met.

56. Harper (MS), Brady, Robert (PA) #126 Authorizes the Speaker of the House with the concurrence of the Minority Leader to call upon the Executive Branch for additional resources in the event the House is the victim of a cyber-attack.

80. Correa (CA) #258 Requires the Department of Defense to update its cyber strategy; to require the President to develop a strategy for the offensive use of cyber capabilities; and to allow for technical assistance to North Atlantic Treaty Organization members.

81. Aguilar (CA) #95 (REVISED) Creates a talent management pilot program for the recruitment, training, professionalization, and retention of personnel in the cyber workforce of the Department of Defense.

None of these cyber initiatives specifically address control system security issues.

NIST Publishes Cyber Workforce Development RFI

Today the National Institute of Standards and Technology (NIST) published a request for information in the Federal Register (82 FR 32172-32174) in supporting its efforts to assess the scope and sufficiency of efforts to educate and train the American cybersecurity workforce of the future in accordance with requirements of the President’s Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure Executive Order (EO 13800).

NIST is specifically requesting answers to the following questions:

1. What current metrics and data exist for cybersecurity education, training, and workforce developments, and what improvements are needed in the collection, organization, and sharing of information about cybersecurity education, training, and workforce development programs?

2. Is there sufficient understanding and agreement about workforce categories, specialty areas, work roles, and knowledge/skills/abilities?

3. Are appropriate cybersecurity policies in place in your organization regarding workforce education and training efforts and are those policies regularly and consistently enforced?

4. What types of knowledge or skills do employers need or value as they build their cybersecurity workforce?

5. Which are the most effective cybersecurity education, training, and workforce development programs being conducted in the United States today?

6. What are the greatest challenges and opportunities facing the Nation, employers, and workers in terms of cybersecurity education, training, and workforce development?

7. How will advances in technology (e.g., artificial intelligence, Internet of Things, etc.) or other factors affect the cybersecurity workforce needed in the future?

8. What steps or programs should be continued, modified, discontinued, or introduced to grow and sustain the Nation's cybersecurity workforce, taking into account needs and trends?


Comments should be submitted via email at cybersecurityworkforce@nist.gov. Comments will be posted at https://nist.gov/​nice/​cybersecurityworkforce. Comments should be submitted by August 2nd, 2017.

CG Publishes Draft MTSA Cybersecurity Guidance

Today the Coast Guard published a notice in the Federal Register (82 FR 32189-32191) requesting public comments on their draft of Draft Navigation and Vessel Inspection Circular (NVIC) No. 05-17 For Guidelines for Addressing Cyber Risks at Maritime Transportation Security Act (MTSA) Regulated Facilities. The draft guidelines can be found at https://homeport.uscg.mil/mycg/portal/ep/home.do > Cybersecurity > Cyber News > Draft Cyber Navigation and Vessel Inspection Circular (NVIC) 05-17 > View Document (sorry, the CG does not use actual links to documents on the Homeport site; you have to click on the links noted above to get to the document).

The Notice explains that the guidance document addresses how cybersecurity issues should be addressed under the current Facility Security Assessment (FSA) and Facility Security Plan (FSP) requirements of 33 CFR Parts 105 and 106. It does not address cybersecurity issues on vessels (33 CFR 104).

The guidance document also sets out proposed best practices for the establishment of a cyber governance and risk management program at MTSA covered facilities. A large portion of the best practices guidance is based upon the NIST Cybersecurity Framework (CSF).


The CG is soliciting public comments on the draft guidance document. Comments may be submitted via the Federal eRulemaking Portal (www.Regulations.gov; Docket # USCG-2016-1084). Comments should be submitted via September 11th, 2017.

Bills Introduced – 07-11-17

Yesterday with both the House and Senate in session there were 31 bills introduced. Of those, one may be of specific interest to readers of this blog:

HR 3180 To authorize appropriations for fiscal year 2018 for intelligence and intelligence-related activities of the United States Government, the Community Management Account, and the Central Intelligence Agency Retirement and Disability System, and for other purposes.  Rep. Nunes, Devin [R-CA-22] 


As always, I will be watching this bill for cybersecurity provisions.

Tuesday, July 11, 2017

ICS-CERT Publishes 6 Advisories and 2 Updates

Today the DHS ICS-CERT published six control system advisories for products from Schweitzer Engineering Laboratories, OSIsoft (2), ABB, Fuji Electric, and Siemens. They also published updates for two other control system advisories for products from OSIsoft and Siemens.

SEL Advisory


This advisory describes an improper access control vulnerability in the SEL SEL-3620 and SEL-3622 Ethernet Security Gateways. The vulnerability was reported by Jason Holcomb with Revolutionary Security. SEL has developed a firmware update. ICS-CERT reports that Holcomb has verified the efficacy of the fix.

ICS-CERT reports that a relatively low skilled attacker could remotely exploit the vulnerability to effect unauthorized communications through the SEL-3620 and SEL-3622 to configured NAT port forwarding destinations.

PI ProcessBook Advisory


This advisory describes (unspecified) third party software {Microsoft Visual Basic for Applications (VBA) v6.5} vulnerabilities in ealier versions of OSIsoft PI ProcessBook and PI ActiveView. There is no specific listing of the individual vulnerabilities involved. These vulnerabilities were self-reported by OSIsoft. Newer versions of the OSIsoft products contain newer versions of the VBA, but do not remove the dll files in which the vulnerabilities reside when upgraded, these must be removed manually.

OSIsoft reports that the affected VBA version would still be required if the workstation was also running MS Office 2003 or MS Office 2007.

ICS-CERT reports that a relatively unskilled attacker could remotely exploit the vulnerabilities to access arbitrary code.

PI Coresight Advisory


This advisory describes a cross-site request forgery vulnerability in the OSIsoft PI Coresight product. The vulnerability is self-reported. OSIsoft has produced a new version that mitigates the vulnerability.

ICS-CERT reports that a relatively low skilled attacker could remotely exploit the vulnerability to access the PI System resulting in unauthorized viewing or alteration of PI System data.

ABB Advisory


This advisory describes two vulnerabilities in the ABB VSN300 WiFi Logger Card. The vulnerability was reported by Maxim Rupp. Newer versions are not affected by the vulnerabilities. There is no indication that Rupp was provided an opportunity to verify the efficacy of the fix.

ICS-CERT reports that a relatively low skilled attacker could remotely exploit the vulnerability to allow attackers to gain unauthorized access to privileged information.

Fuji Electric Advisory


This advisory describes an improper restrictions of operations within the bounds of a memory buffer vulnerability in the Fuji V-Server. The vulnerability was reported by Ariele Caltabiano via the Zero Day Initiative. Fuji has produced a patch to mitigate the vulnerability. There is no indication that Caltabiano has been provided an opportunity to verify the efficacy of the fix.

ICS-CERT reports that an uncharacterized attacker could remotely exploit the vulnerability  to remotely execute arbitrary code.

Siemens Advisory


This advisory describes an out-of-bounds write vulnerability in the Siemens SIMATIC Logon Remote Access product. The vulnerability was reported by Tenable Security. Siemens has produced a new version to mitigate the vulnerability. There is no indication that Tenable has been provided an opportunity to verify the efficacy of the fix.

ICS-CERT reports that a relatively low skilled attacker could remotely exploit the vulnerability to cause a denial of service of the SIMATIC Logon Remote Access service under certain conditions.

OSIsoft Update


This update provides new information on the advisory that was originally published on January 10th, 2017. It reports that the new version of PI ProcessBook described above also mitigates this vulnerability. There is no indication that the researcher (Vint Maggs) has been provided an opportunity to verify the efficacy of the fix.

Siemens Update



This update provides new information on the advisory that was originally published on June 29th, 2017. Firmware updates are now available for all affected products. The updated Siemens security advisory reports that SINUMERIK products have been removed from the affected products list available on the Siemens website.

Bills Introduced – 07-10-17

With the Senate in session (and the House present in a proforma session) there were 13 bills introduced yesterday. Of those bills only one may be of specific interest to readers of this blog:

S 1519 An original bill to authorize appropriations for fiscal year 2018 for military activities of the Department of Defense, for military construction, and for defense activities of the Department of Energy, to prescribe military personnel strengths for such fiscal year, and for other purposes.


When an official print version of the bill becomes available I will be looking at this bill for cybersecurity provisions.
 
/* Use this with templates/template-twocol.html */