Source: https://chemical-facility-security-news.blogspot.com/2017/09/
Timestamp: 2018-04-23 15:25:18
Document Index: 367590047

Matched Legal Cases: ['§14', '§4301', '§7304', '§2', '§3', '§3', '§12310', '§1662', '§502', '§505', '§505']

Chemical Facility Security News: September 2017
This week the National Institute of Standards and Technology (NIST) published a new implementation document to support the Cybersecurity Framework, the Cybersecurity Framework Manufacturing Profile. In many ways this is similar to the Coast Guard’s draft Framework for Passenger Vessels, so much so that I suspect that the NIST team had some significant input into the CG’s document.
The Profile starts with a brief look at manufacturing systems with a brief overview of the different two very broad types of manufacturing systems (process and discrete) and the types of electronic communications that are employed within the manufacturing and critical infrastructure sectors. It then goes on to provide a quick look at the Cybersecurity Framework, providing some background information about how the Framework was developed and is organized.
Then, as with the CG’s Framework, it provides a brief discussion of the business or mission objectives that are affected by cybersecurity risk. Those objectives (not in prioritized order it is emphasized) (pg8):
• Maintain trade secrets.
After providing a series of tables that shows which Framework subcategories support which objective the document proceeds with a discussion of relative potential impact or security levels; Low, Moderate and High. This is includes tables describing impact levels based upon both direct impacts of failure of cybersecurity systems (injury, financial loss, environmental release, interruption of production, and public image) and more generalized impacts based upon products produced or the industry involved.
Finally, we then get to the meat of the Profile; a 26-page table that provides a listing of recommendations for general steps to take for each of the Frameworks sub-categories for each level of impact, along with the appropriate Framework supporting document references for those recommendations.
Remembering that the CSF is a risk management or risk communication document and not a technical cybersecurity blueprint, NIST has done a very thorough job of producing a document that is useable by most folks in the manufacturing sector and those critical infrastructure sectors that use industrial control systems. Will people find faults with various specific recommendations? Almost certainly, but that would be true for any document of this type.
I do have one very serious misgiving about this Profile document. The on-line version provides some very good, very specific links to supporting documents. For example, for subcategory DE.DP-5 (Detect, Detection Process #5) the on-line version of the document provides a direct link to CA-2 (Security Assessments) within NIST SP 800-53; very helpful. The problem? Those links are not included in the .PDF document downloaded from the site. I suspect that that is because NIST intends to continually update those links (a thankless task if ever there was one) as the various reference documents are revised. Still, it does limit the effectiveness of the downloaded version of the Profile.
There is a very interesting anomaly in the Profile; there are a number of recommended actions that do not include a reference. For example in ID.GV-1 (Identify, Governance #1) it recommends for all three risk levels: “Ensure the security policy is approved by a senior official with responsibility and accountability for the risk being incurred by manufacturing operations.” This is certainly a good recommendation, but it is interesting that this (and a significant number of similar recommendations) have not been identified in any of the NIST supplied references.
Labels: Control System Security, Cybersecurity Framework, Manufacturing Profile
Yesterday, with both the House and Senate preparing to leave for the weekend, there were 68 bills introduced. Of these, two may be of specific interest to readers of this blog:
S 1885 A bill to support the development of highly automated vehicle safety technologies, and for other purposes. Sen. Thune, John [R-SD]
S 1900 A bill to require all persons who acquire, maintain, or use personal information to have in effect reasonable cybersecurity protections and practices whenever acquiring, maintaining, or using personal information in commerce, and for other purposes. Sen. Blumenthal, Richard [D-CT]
S 1885 was introduced with a fair amount of fanfare and media buzz (see here for example). Thune’s press release includes links to a copy of the bill and a summary of its provisions. That summary explains the cybersecurity provisions this way:
“This section [§14] would require manufacturers of HAVs [Highly Automated Vehicles] and ADS [Automated Driving Systems] to develop and execute a written plan for identifying and reducing cybersecurity risks to the motor vehicle safety of such vehicles and systems. This section would also authorize the Secretary to work cooperatively with manufacturers to develop a policy for coordinated disclosure of cybersecurity vulnerabilities (such as bug bounty programs), and it would direct other federal agencies researching cybersecurity risks associated with HAVs to coordinate with the Secretary on their findings.”
The GPO version of the bill has not been published, but I will probably be reviewing the bill this weekend since it is scheduled for consideration in Thune’s Commerce, Science, and Transportation Committee on Wednesday.
S 1900 will probably not be covered here since there are almost certainly no control system issues involved (I hope) but I am including it today as an example of potential congressional overreaction to cybersecurity incidents (almost certainly the Equifax fiasco here). If the bill does, in fact (and it probably does not) provide for cybersecurity standards for “all persons [emphasis added] who acquire, maintain, or use personal information” then we have a sweeping piece of cybersecurity legislation that would create more problems than it solves.
Labels: Automated Vehicles, Bills Introduced, Personal Information Security, S 1885, S 1900
Today the DHS ICS-CERT published a control system security advisory for products from Siemens. This advisory describes an improper access control vulnerability for the Siemens Ruggedcom ROS and SCALANCE devices. The vulnerability was self-reported by Siemens. Siemens has developed firmware updates for two of the affected products and a work around for the other products pending firmware development.
ICS-CERT reports that a relatively low skilled attacker on an adjacent network could remotely exploit the vulnerability to perform unauthorized administrative actions.
Yesterday with both the House and Senate in session there were 32 bills introduced. Of those, two may be of specific interest to readers of this blog:
HR 3855 To require a report on significant security risks of the national electric grid and the potential effect of such security risks on the readiness of the Armed Forces. Rep. Rosen, Jacky [D-NV-3]
S 1872 A bill to authorize the programs of the Transportation Security Administration relating to transportation security, and for other purposes. Sen. Thune, John [R-SD]
I suspect that HR 3855 is a companion bill to S 1800. Companion bills are identical bills introduced in both houses of congress to allow for parallel processing in the bill consideration process. Alternatively, when a bill is stalled or blocked in committee in one house of congress, the introduction of a companion bill in the other can restart the consideration process.
S 1872 is one of those annual authorization bills that ‘must’ wend their way through the legislative process every year. I will watch this bill for chemical transportation security measures.
Labels: Bills Introduced, DOD Grid Security, FY 2018 TSA Authorization, HR 3855, S 1872
Today the DHS Infrastructure Security Compliance Division (ISCD) published their latest version of the Chemical Facility Anti-Terrorism Standards (CFATS) Fact Sheet. The data continues to show a net increase in the number of facilities covered under the program and a similar increase in the number of compliance inspections completed to date. The data still paints a confusing picture that would seem to indicate a high rate on CFATS non-compliance.
Table 1 shows the comparison between the data reported today and that reported last month for facilities currently covered by the CFATS program. For the first time since reporting resumed we see a positive month-to-month change in all of the reported categories
Table 2 shows the similar comparison of monthly data for the total numbers for each category since the inception of the CFATS program. As expected the month-to-month change in each category is positive, but we continue to see a significant disparity between the two tables in differences (∆) for compliance inspections and both authorization inspections and approved security plans.
Table 2: Total Facility Data
If I update the graph that I used last month to include the current data (Graph 1) we can see the sharp differences between the rate of change in current approved site security plans (a pre-requisite for having a compliance inspection), the total number of compliance inspections completed to date, and the current compliance inspection numbers.
Graph 2: Compliance Inspection Data
As with last month, it is hard to come up with any explanation of the data presented by ISCD other than to conclude that ISCD is finding a disturbing number of facilities non-compliant with the implementation of their site security plans. What makes this so disturbing is that facilities negotiated with ISCD on setting the content of their site security plans, so it is hard to believe that they were ‘not aware of program requirements’.
Security of Non-Compliant Facilities
The big question that this raises is how secure are these non-compliant facilities? That is a question that is next to impossible to answer from the data that ICSD is allowed to share with the public. ISCD is not about to, nor can they legally, share any data about the security of covered facilities.
Of course, I am under no restrictions about the conjectures that I raise in attempting to answer this question. So here goes an uninformed, but educated guess as to what is going on…
First, I think that basic security measures are in place to deter, detect and delay terrorists desiring to attack these facilities. Those are all fairly straightforward and would have been in place before ISCD authorized or approved the site security plans (SSP) under which these facilities operate. I suspect that the non-compliances fall into three categories:
• Planned security measure failures;
• Changes is security posture; and
The first category covers those high-expense capital expenditures that facilities could not immediately implement because of budgeting constraints. ISCD gave facilities credit for these security measures when approving the SSP, because specific plans and budgeting approvals were in place. As with any plan, things can go wrong and those plans may not have been at an appropriate level of completion when the Chemical Security Inspectors (CSI) showed up for the compliance inspection will be a problem. Those would certainly make the facility non-compliant.
How badly that would affect the actual security of the facility is hard to tell without knowing the details. ISCD would have required some sort of interim compensatory controls to be in place to mitigate the vulnerabilities while the planned action is implemented. So, while there may be a hole in the security plan, it should not be gaping nor readily identifiable.
I do know that ISCD has no quota of non-compliances to issue and would I would bet that, if facilities in this situation had previously talked with ISCD about the problem they were having with their planned security measures, they would have been able (in most reasonable cases) negotiate a new time frame for implementation. When the inspector gets there, it is certainly too late.
I suspect that the second category is probably the most common reason for non-compliance. The CFATS program requires {6 CFR 27.210(d)} facilities to submit a new Top Screen whenever it “makes material modifications to its operations or site”. This allows ISCD to determine if a new or revised security plan is required to mitigate any security vulnerabilities associated with those changes. Since ‘material modifications’ is not a defined term in 6 CFR 27, it would not be surprising to hear that facility or operational changes that the facility made without an apparent security purpose might be considered a ‘material modification’ in light of the undisclosed risk assessment process that ISCD uses to evaluate facilities for program coverage and risk tiering.
CFATS covered facilities need to take a hard look at any facility, chemical process, or business procedures changes with a specific eye to its potential effect on the efficacy of the site security plan. This especially applies to any procedure or device specifically mentioned in the SSP. This is one of the reasons why it is important to have a site security manager who is an integral member of the facility management team.
The final category is more of a stretch of my intuition, but with an increasing focus across DHS on cybersecurity issues, it would not be hard to guess that implementing Risk Based Performance Standard (RBPS) 8, Cybersecurity, would be an item on specific interest on compliance inspections. Facilities with access to a well-trained cybersecurity team, would probably have no problems implementing the agreed upon cybersecurity measures in the SSP. Facilities without such support would have a much more difficult time in meeting the cybersecurity requirements of a reasonable cybersecurity plan.
This is the one area that I am not as confident in the overall security posture of non-compliant facilities. Again, it would depend in large part about the chemicals of interest involved and how much control systems and inventory controls played in the security of those COI at the site. But, there are so many ways that either informational or operational computer systems could impact security plans that I suspect that this is the area with the widest variation in actual the security of dangerous chemicals across the country. Which would be why ISCD would be specifically focusing on the security of these systems in any compliance inspection.
We are a little more than a year away from the current expiration of the CFATS program (12-18-18). Congress is likely to start looking at this program again as they consider reauthorizing the program. If ISCD is having the high non-conformance rate that I think the current data indicates, there will certainly be questions asked on the Hill about this topic. I hope ISCD has some good answers.
Posted by Patrick Coyle at 10:00 PM No comments: Links to this post
Labels: CFATS Fact Sheet, Chemical Facility Security, ISCD
Yesterday the Senate agreed to begin debating the consideration of S 1579, the FY 2018 National Defense Authorization Act. This was the original senate version of the NDAA that served as the template for McCain’s substitute language for HR 2810 that was passed in the Senate last week. This is an unusual move as the House has yet to consider the Senate amendments to HR 2810. Even if the House were to reject the Senate amendments there would still be the resulting conference committee to work out the differences in the two versions.
Earlier in the day the Senate did make a minor correction to the wording of two amendments that were adopted on the floor, SA 1065 (pg S 5760) and SA 1086 (pg S 5768). Both amendments made changes to the funding tables in §4301, but they failed to include the words: “At the end of Division F add the following:” at the start of the amendment. The adjustments were made under the unanimous consent procedure, the way minor editorial errors are normally corrected post-passage. This should not be the reason for the consideration of S 1579.
There is no explanation of the consideration of this bill in the Congressional Record today, nor have I seen anything in the national news. I am going to keep an eye on this.
Labels: FY 2018 NDAA, HR 2810, S 1579
Earlier this month the Department of Transportation (DOT) published their first report on the composition of the fleet of railcars used in the transportation of flammable liquids. This is one of the reports that was required to be prepared by DOD in the 2015 Fixing America’s Surface Transportation Act (FAST Act, PL 114-94; 129 STAT 1599).
The data reflects changes in the composition of the railcar fleet used to transport flammable liquids in response to the phase out schedule requirement of §7304 the FAST Act (129 STAT 1596) for older and less safe DOT 111 and CPC 1234 railcars. Table 1 below shows the changes in fleet composition since 2013.
Table 1: Changes if Flammable Liquid Railcar Fleet
With two years left (since the end of the reporting period) in the required phaseout of the DOT 111 tank cars, it looks like the railroad industry is well on its way to meeting the congressional mandate. A large portion of change over took place before the congressional mandate was put into place in December of 2015. In 2013 the flammable liquid shippers started replacing the unjacketed DOT 111 cars in their fleet with jacketed DOT 111’s and CPC 1234. It was only in 2015 that those railcars started to be removed from flammable liquid transportation service.
Unfortunately, it does not seem as if this phase out is being accomplished by the introduction of new (or refurbished) railcars. It looks like this is being greatly influenced by a general decline in the number of railcars in flammable liquid service. Table 2 shows the changes in types of flammable liquids being transported by the entire fleet.
Table 2: Changes in Flammable Liquids Being Shipped
This table shows that the changes in the number of railcars in flammable liquid service is almost entirely due to the general decline in the number of shipments of crude oil and ethanol. Both of these commodities suffered severe declines in 2014 and 2015 due to the drastic fall in crude oil pricing. That pricing stabilized in 2016 and has been gradually increasing since then. The decline in the number of crude oil shipments has almost certainly also stabilized and is probably increasing.
This means that future declines in the number of DOT 111 and CPC 1234 tank cars being phased out of flammable liquid service can no longer be sustained by just the reductions in the railcar fleet. More DOT 117 railcars are going to have to be placed into service to replace those older railcars. This report does not address the disparity between the number of DOT 111 and CPC 1234 railcars still needing to be replaced and the rate at which new/refurbished DOT 117 railcars are being introduced.
NOTE: Thanks to ProgressiveRailroading.com for pointing to this ‘public’ report.
Labels: Crude Oil, DOT 111, Hazardous Material Shipping
The House is coming back to Washington after a week working in their districts and the Senate is coming back from a really-long weekend. The big news this week will once again be the healthcare ‘debate’ in the Senate, but there will be two hearings of interest, both touching on cybersecurity.
On Wednesday the Information Technology Subcommittee of the House Oversight and Government Reform Committee will hold a hearing on the “Cybersecurity of the Internet of Things”. No witness list has been provided.
According to the Library of Congress there are currently three House bills (HR 686, HR 1324, and HR 3010) that contain reference to “Internet of Things” and none of them have been referred to the Oversight Committee for consideration. It looks like the leadership just wants to get into the IOT political game.
On Wednesday the Senate Homeland Security and Governmental Affairs Committee will be holding a hearing on “Threats to the Homeland”; which will almost certainly at least touch on a number of cybersecurity topics. The current witness list includes:
• Elaine C. Duke, DHS;
• Christopher A. Wray, FBI; and
• Nicholas J. Rasmussen, National Counterterrorism Center
Considering the breadth of the topic I think we can only expect to see broad highlights in the prepared testimony. It will be interesting, however, to watch the focus of the questions tossed at the panel.
Labels: Congressional Hearings, Cybersecurity, IOT
The nice thing about writing this blog is that periodically I get a chance to talk to people in the field that are responsible for implementing the Chemical Facility Anti-Terrorism Standards (CFATS) program. I had one of those conversations today with a long-time reader who is a contractor helping a new CFATS covered facility that was caught up by CSAT 2.0. As is usual these conversations are tempered by having to adhere to Chemical-terrorism Vulnerability Information (CVI) rules, so specifics could not be mentioned. Still, there is some information worth sharing.
CSAT 2.0 and MTSA
A lot of facilities are being introduced to the CFATS program by recent changes in the Chemical Security Assessment Tool (CSAT 2.0) and the new risk assessment process that was concurrently introduced by the Infrastructure Security Compliance Division (ISCD) at DHS. This was not covered in my discussions today, but I am hearing indications that some of these new facilities used to feel that they were exempt from CFATS coverage because they were covered by the Coast Guard’s Maritime Transportation Security Act (MTSA) program. The notification letters that ISCD started sending out last fall make it clear that only those portions of the facility covered by MTSA requirements are exempt from the CFATS program requirements.
It seems that a number of facilities took the allowable course of restricting their MTSA footprint to the immediate shore side portion of their facilities. For many larger facilities, this left major portions of the facility uncovered by federal security regulations. ISCD made it clear that those portions of the facility not covered by MTSA were subject to the CFATS Top Screen reporting requirements and potentially full coverage under the CFATS program depending on the DHS risk assessment based upon Top Screen submission data.
After the Tiering Letter
The conversation today addressed some of the lessons learned at a CSAT 2.0 facility that recently received their tiering letter (the official notification from CSAT that the Top Screen submission and subsequent risk assessment had allowed ISCD to determine that the facility is at ‘high-risk’ for potential terrorist attack and was therefore subsequently placed in the CFATS program.
After the inevitable “oh, no… really?” conversation the facility requested a compliance assistance inspection as they began work on prepping for the security vulnerability assessment (SVA) and site security plan (SSP) submissions. Shortly thereafter a DHS chemical security inspector (I still hate the inevitable ‘CSI’ fallout) showed up to take a look at the facility and the work they had already done to make it secure. This is one of those rare cases when you can sigh with relief instead of cringe when the guy says: “I’m from the government and I’m here to help you.”
The initial good news was that because of a detailed DOT Hazmat Security Plan (49 CFR 172.802) the facility had a good head start on fulfilling the requirements of the CFATS Risk-Based Performance Standards (RBPS; 6 CFR 27.230) as explained in the RPBS Guidance document. Additionally, since the CSI had already seen this type of facility before, he was able to provide a template that could probably be used by the facility to submit an alternative security plan (ASP, not the ACC/NACD ASP that I have previously discussed) instead of submitting the cumbersome SSP found in the CSAT tool. (Note: I’m trying to see if I can get hold of a link to that new template.)
One of the nice parts of the CFATS program is that ISCD really is working with facilities to get site security plans formalized. To understand why, you just need to look at the most basic restriction that ISCD is operating under; they are forbidden by Congress {6 USC 622(c)(1)(B)(i)} from specifying security measures that facilities must employ.
In practice, this means that the approval of the SSP by ISCD is really a negotiating process. The facility proposes a set of security measures and ISCD determines whether or not those measures meet the RBPS criteria for the Tier Level to which the facility is assigned. ISCD then explains any deficiencies and the facility attempts to remedy them. In the early days of the program this could end up being a rather lengthy process. Fortunately, the CSI now have enough experience with facility security plans, so that they can provide suggestions about what has worked at other facilities.
Once the SSP is approved by ISCD the relationship changes to something more approaching a typical agency private sector relationship as the SSP becomes an enforceable set of standards against which compliance can be measured. I suspect, however, that the relationship will still have more cooperative overtones than with most government agencies because of the relatively stable assignment of CSI to responsibility for a small number of facilities. This allows for a better understanding of facility issues and a closer working relationship.
One thing that this new facility was told during their compliance assistance visit was to make sure that they took a good hard look at their cybersecurity planning. As one could expect, ISCD is taking its cue from much higher up the ladder at DHS in focusing on cybersecurity issues.
I reminded my caller that the facility has a relatively large degree of discretion when it defines the portion of the facility which is covered by the CFATS program. For facilities with release risk chemicals of interest (COI) there may be no need to include business IT systems in the CFATS perimeter if they have no effect on the security of the COI at the facility. This is yet another good reason for carefully segmenting the different cyber-networks at a facility.
I also suggested to my reader that they take a good look at using the Cybersecurity Evaluation Tool (CSET) to help evaluate the security of their control systems. The newest versions of this tool from ICS-CERT includes specific CFATS related questions that can be used to help formulate the cybersecurity portion of SSP. The use of CSET does not provide a free pass on the RPBS 8 (cybersecurity) requirements, but it can be a helpful tool.
I am always interested in talking about chemical facility security with just about anyone involved in the field. My contact information is available on my blog or LinkedIn. I do have a day job with a variable schedule that sometimes makes it challenging to schedule a phone call, but I am certainly willing to make the effort.
Labels: CFATS, Chemical Facility Security, Cybersecurity
The DOT’s Pipeline and Hazardous Material Safety Administration (PHMSA) published three Hazardous Materials Regulations (HMR) waivers in Monday’s Federal Register (82 FR 44696-44697, 82 FR 44699-44700, and 82 FR 44697-44698; available on-line today). These waivers are in support of the Environmental Protection Agency’s clean-up efforts for Hurricane Harvey and Hurricane Irma.
Each waiver identifies the areas affected based upon President Trump’s emergency declarations for Texas and Louisiana (Waiver #1); Florida, Puerto Rico, South Carolina and the Virgin Islands (Waiver #2); and Georgia (Waiver #3). The waiver only applies to the specific areas identified in those declarations and their subsequent amendments.
Each waiver provides that: “non-radioactive hazardous materials may be transported to staging areas within 50 miles of the point of origin. Further transportation of the hazardous materials from staging areas must be in full compliance with the HMR.” Each waiver remains effective for 30 days from September 1st (Waiver #1), September 8th (Waiver #2), or September 10th, 2017 (Waiver #3).
I do not recall seeing these types of waivers after previous hurricanes. They certainly seem like a good idea. It provides the EPA with some amount of flexibility in how they structure their recovery efforts to isolate and remediate unsafe hazardous materials that are found during their cleanup efforts.
Unfortunately, I can find nothing on the EPA’s web sites about the establishment of the collection points mentioned in these waivers. Neither the latest news release for Maria and Irma recovery, nor the hurricane specific web sites for Maria and Irma (NOTE: There is apparently no similar site for Harvey) contain any mention of the PHMSA waivers or collection points. This is particularly unhelpful as the PHMSA waivers quickly approach their expiration.
It seems that the Federal government still has some lessons to learn in handling the coordination of their response activities (and the publication of those activities) within the government.
Labels: Harvey, Hazardous Material Safety, Irma, Maria, PHMSA Waiver
Yesterday the DHS ICS-CERT published five control system security advisories for products from Schneider, Ctek, Digium, iniNet Solutions, and Saia Burgess Controls. The advisory for the products from Saia Burgess Controls was originally posted to the NCCIC Portal on August 22, 2017.
Saia Burgess Controls Advisory
This advisory describes an information exposure vulnerability in the Saia Burgess Controls PCD Controllers. The vulnerability was reported by Davide Fauri of Eindhoven University of Technology. The latest version of the firmware mitigates the vulnerability. There is no indication that Fauri has been provided an opportunity to verify the efficacy of the fix.
ICS-CERT reports that a relatively low skilled attacker could remotely exploit the vulnerability to to obtain information in memory.
The SBC upgrade notes also report that the current version makes the following security changes:
• Protective functions are activated by default;
• Improved password protection associated with the role-based user management;
• Access filter using "white" and "black" lists;
• Removed hardcoded password [NOT mentioned in ICS-CERT advisory].
Similar changes were also apparently made to the SBC PG5 Controls Suite.
iniNet Solutions Advisory
This advisory describes an improper authentication vulnerability in the iniNet Solutions SCADA Webserver. The vulnerability was reported by Matthias Niedermaier and Florian Fischer, both of Augsburg University of Applied Sciences. iniNet has released a new version that allows users to implement basic authentication. There is no indication that the researchers were afforded an opportunity to verify the efficacy of the fix.
ICS-CERT reports that a relatively low skilled attacker could remotely exploit the vulnerability to access human-machine interface (HMI) pages or to modify programmable logic controller (PLC) variables without authentication.
Digium Advisory
This advisory describes an OS command injection vulnerability in the Digium Asterisk GUI. The vulnerability was reported by Davy Douhine of RandoriSec. Asterisk GUI is no longer maintained and should not be used. Digium recommends affected users to migrate to Digium’s SwitchVox product.
ICS-CERT reports that a relatively low skilled attacker could remotely exploit the vulnerability to execute arbitrary code on the device.
Interesting Questions: Would owners of a control system that uses an HMI configured with Digium’s Asterix GUI even know that it had been used, particularly if the system had been designed by a contractor or vendor? Would it take a complete system redesign to change out the GUI for an HMI?
Ctek Advisory
This advisory describes an improper authentication vulnerability in the Ctek SkyRouter. The vulnerability was reported by Maxim Rupp. The latest firmware version mitigates this and “additional security requirements”. NOTE: “Ctek, Inc., reports that due to industry demand, wireless carriers are rapidly eliminating 2G and 3G CDMA service and they will not be creating any additional update releases for those products.” There is no indication that Rupp was provided an opportunity to verify the efficacy of the fix.
ICS-CERT reports that a relatively low skilled attacker could remotely exploit the vulnerability to view and edit settings without authenticating.
This advisory describes a missing authentication for critical function vulnerability in the Schneider InduSoft Web Studio products. The vulnerability was reported by Aaron Portnoy, formerly of Exodus Intelligence. Schneider has created a patch to mitigate the vulnerability. There is no indication that Portnoy was provided an opportunity to verify the efficacy of the fix.
ICS-CERT reports that a relatively low skilled attacker could remotely exploit the vulnerability to remotely execute arbitrary commands with high privileges.
NOTE: The Schneider security bulletin was published last Friday. Maybe Dale Peterson was right, it looks like ICS-CERT is doing ‘ICS-vuln Thursday’.
Labels: Aaron Portnoy, Control System Security, Ctek, David Dohine, Davide Fauri, Digium, Florian Fischer, ICS-CERT Advisory, iniNet, Matthias Niedermaier, Maxim Rupp, Saia Burgess Controls, Schneider
Last week Sen. Warren (D,MA) introduced S 1800, the Securing the Electric Grid to Protect Military Readiness Act of 2017. The bill is nearly identical to SA 867, Warren’s proposed amendment to HR 2810 on the same topic. It addresses efforts to protect the electrical distribution systems on military installations.
Warren is a member of the Senate Armed Services Committee to which this bill was referred for consideration. This means that she may have enough influence to have the Committee consider the bill.
I do not see anything in this bill that would engender any significant opposition. If the bill were to be considered it would be likely to pass with at least some bipartisan support.
There is nothing in this bill that directly addresses cybersecurity concerns for the industrial control system associated with military power distribution systems. A lot of the language seems to be IT-centric (for example: “to deny access to or degrade, disrupt, or destroy an information and communications technology system or network” {§2(c)(4)(A)} in the definition of ‘significant malicious cyber-enabled activities’).
I doubt that DOD would fail to address ICS security issues in the required studies and reports, but it would certainly be helpful if the bill specifically addressed requirements for ICS security considerations. I suspect that the failure to do so reflects a continued failure on the part of Congress to recognize the different issues involved with ICS security.
Posted by Patrick Coyle at 8:59 AM No comments: Links to this post
Labels: Electric System Security, S 1800
On Monday the Senate passed HR 2810, the FY 2018 National Defense Authorization Act (NDAA) by a strongly bipartisan vote of 89 to 8; even the opposition was bipartisan with three Republicans, four Democrats and one Independent voting Nay.
Of all of the amendments that I discussed in my series of blog posts over the last two weeks, only three were adopted:
• Reed (for Kaine) Amendment No. 1089, to establish opportunities for scholarships related to cybersecurity.
• McCain (for Portman) Amendment No. 712, to require a plan to meet the demand for cyberspace career fields in the reserve components of the Armed Forces.
• McCain (for Portman) Amendment No. 1055, to require a report on cyber applications of blockchain technology.
They were all considered as part of an en bloc amendment [pgs S5787-8] offered by Sen. McCain (R,AZ) at the end of the final debate on HR 2810. The en bloc amendment was adopted by unanimous consent [pg S5796].
Since there are significant differences between the versions of this bill passed in the House and Senate, it is very likely that there will be a conference committee appointed. There is, however, a very slight chance that the House will agree to the Senate amendment to the bill when it returns from their week working in their districts.
Today the DHS ICS-CERT published a control system security advisory for products from PHOENIX CONTACT. They also provided a link to a British publication: “Code of Practice CyberSecurity for Ships”.
This advisory describes ten improper access control vulnerabilities in the PHOENIX CONTACT mGuard Device Manager. The vulnerabilities are related to the Oracle Java SE implementation in the product. These vulnerabilities were self-reported by PHOENIX CONTACT. They have a new version that mitigates the vulnerabilities.
ICS-CERT reports that a relatively low skilled attacker could remotely exploit these vulnerabilities to allow unauthorized remote access, modification of data, and may allow remote and local users to gain elevated privileges.
Once again, we see a vulnerability caused by third party software and there is an open question about what other software systems have the same vulnerabilities. Interesting though that these 10 Oracle vulnerabilities are all dated in 2017. Makes it even more likely that other vendors using the same Oracle software will have not discovered/mitigated the vulnerabilities in their products.
Cyber Security for Ships
The code of practice document was produced for the British Government by the Institution of Engineering and Technology. It provides a high-level overview of the topic including an interesting overview of the threat environment for the shipping industry. Appendix D provides a non-technical description of how mitigation measures can be developed and Appendix H provides a lengthy bibliography of cybersecurity standards for both IT and operational systems.
Labels: Control System Security, Cybersecurity for Ships, ICS-CERT Advisory, Phoenix Contact
Earlier this month Rep. Kilmer (D,WA) introduced HR 3712, the Major General Tim Lowenberg National Guard Cyber Defenders Act. The bill would provide specific authorization for military reserve component cyber civil support teams. NOTE: For more on Gen. Lowenberg see here and here.
Section 2 of the bill amends 10 USC 12310(c) which provides for military reservists to be used in an active duty role to support of emergency preparedness programs. It would add a new subparagraph (1)(E) to add “An attack or natural disaster impacting a computer, electronic, or cyber network” to the list of covered emergencies for which the emergency preparedness programs would be appropriate.
The bill then goes on to add a new subparagraph (3)(B) that would specifically allow an individual reservist or a “a reserve component cyber civil support team” to provide emergency preparedness support for the newly added cyber-attacks or disasters.
Cyber Civil Support Team Authorization
Section 3 of the bill requires that each state will have (within 5 years) “an operational reserve component cyber civil support team composed of reserve component members of the Armed Forces” {§3(a)}. To be considered operational each Cyber Civil Support Team would be required to be able to {§3(c)}:
• Perform duties relating to analysis and protection in support of responding to emergencies involving an attack or natural disaster impacting a computer, electronic, or cyber network;
• Advise and coordinate on any incident deemed critical for the protection of life, property, and maintenance of good order for the Governor;
• Cooperate with and assist private sector owners and operators of critical infrastructure and key resources;
• Collaborate and participate in information sharing with Federal, State, and local Fusion Centers, emergency management authorities, and emergency management divisions; and
• Coordinate with elements of the Department of Homeland Security.
Section 4 of the bill ensures that these Cyber Civil Support Teams are specifically covered by the provisions of the Freedom of Information Act under 5 USC 552.
Section 5 of the bill provides for a spending authorization of $50 million for support of the requirements of this bill.
Neither Kilmer nor his two cosponsors {Rep. Palazzo (R,MS) and Rep. Heck (D,WA)} are members of the House Armed Services Committee to which this bill was assigned for consideration. This means that the bill is very unlikely to be considered in that Committee; pretty much ensuring that the bill will not get to the floor of the House for a vote.
There is nothing in this bill which would engender any serious opposition to its passage. The one major drawback to the bill is the spending authorization, but that is one area where Kilmer and Palazzo have some influence, since they are both on the House Appropriations Committee. If the bill were to be considered it is quite likely that it would receive substantial bipartisan support.
While there is a great deal of talk in Congress about protecting critical infrastructure from cyber-attacks, there does not seem to be too much that the military can do to protect the vast majority of critical infrastructure cyber-systems that are owned by the private sector. In fact, there is a very real argument that the private sector is responsible for that and should pay for that protection via activities either in-house or through a wide variety of organizations in the ever-expanding cybersecurity market place.
However, where cyber breaches have a physical impact on the community beyond the boundaries of critical infrastructure, there is certainly a need for the kind of support outlined in this bill. What concerns me about the approach taken in the bill is the focus on post-incident response instead of emergency preparedness planning.
Planning for the potential consequences of broadly effective cybersecurity incidents is a pre-requisite for effective responses to such wide scale incidents. In fact, the §12310(c) program was founded on the idea that providing one or two professional planners (military folks are, after all, as much planners as they are fighters) to local government emergency-response planning agencies was a cost-effective way of helping to mitigate the consequences of terrorist attacks and natural disasters.
All but the largest local government agencies are ill prepared to plan for or respond to cyber-attacks on critical infrastructure. Most have problems enough providing for their own cybersecurity prevention efforts, much less have time or resources to plan for attacks on privately owned critical infrastructure effecting their area. Cyber Civil Support Teams under State control could provide another (though still limited) resource for local governments involved in the planning process.
Labels: Cyber Civil Support Teams, HR 3712
Senate Amendments to HR 2810 (FY 2018 NDAA) – 9-14-17
On Thursday, after voting to close debate on the McCain substitute language amendment (SA 1003), the Senate agreed to a final vote on HR 2810, the FY 2018 National Defense Authorization Act (NDAA), at 5:30 pm EDT on Monday, September 18th, 2017. Meanwhile, more amendments continue to be proposed. In addition to the previously proposed amendments (see here, here, here, here and here) a large number of possible amendments to HR 2180 were proposed in the Senate on Thursday; only one of which may be of specific interest to readers of this blog:
SA 1089. Mr. KAINE - SEC. 1661. Cyber Scholarship Opportunities Act of 2017 (pgs S5768-9);
Amendment SA 1089 is pretty nearly the same as SA 849 that Sen. Kaine (D,VA) proposed on September 7th, 2017. The only difference is that the latest version removes the section on ‘Findings’ that explains why Kaine thinks that cyber scholarships are necessary.
This amendment would require that the current Federal Cyber Scholarship-for Service program (15 USC 7442) be expanded to include a pilot program of scholarships at at least five community colleges for students who are pursuing associate degrees or specialized program certifications in the field of cybersecurity and either “have bachelor’s degrees; or are veterans of the armed forces” {§1662(a)(2)}. No additional funding is provided for the new scholarship requirements.
Just a reminder, as of this writing, none of the amendments that I have addressed in this series of blog post (with the obvious exception of SA 1003) have even been considered on the floor of the House, much less adopted. There is a remote chance that some may be considered on Monday, but I do not really expect it.
This large number of amendments proposed for a ‘must pass’ bill like the NDAA is not unusual. With the political horse trading involved in getting enough votes to pass a bill like this, there is always the possibility that some pet bit of legislative language can be inserted via the Senate amendment process. It takes relatively little effort by a Senator’s staff to craft most of these amendments (frequently just cut and paste from a previously submitted bill), so it is kind of like buying a $1 lottery ticket when the pot is really high. A piece of legislation that might never see the light of day in the normal legislative process can become law because it was attached to an important bill.
A less well-known fact is that one of these little suspected gems may have already been added to the substitute language that was offered on this bill. I certainly did not do a full detailed analysis of every portion of the bill. Getting a new section added or a current section slightly revised can be the price of support for a bill like this. Depending on how much McCain trusts his committee staff and how significant the change was, he may not even know the details about those types of changes to the substitute language before it was proposed.
This is one of the reasons that I do not try to cover each of the potentially interesting amendments with the same level of detail as I use to cover interesting legislation. There is a very small chance of the amendments being considered or passed. The effort that I do make, reflects on bits of legislative language that I find illustrative of either poorly or well written legislative language, unique ideas, or really slick pieces of legislative legerdemain.
With both the House and Senate preparing to leave for their weekend recess, there were 64 bills introduced yesterday. Of those two may be of specific interest to readers of this blog:
HR 3776 To support United States international cyber diplomacy, and for other purposes. Rep. Royce, Edward R. [R-CA-39]
S 1821 A bill to establish the National Commission on the Cybersecurity of United States Election Systems, and for other purposes. Sen. Gillibrand, Kirsten E. [D-NY]
I am not sure what ‘cyber diplomacy’ is, but if it concerns control system security issues I will be covering HR 3776 here.
I do not really plan to expand the focus of this blog to include detailed coverage of election cybersecurity issues, but I will be watching S 1821 for the definitions it uses and the scope of coverage of the Commission.
Labels: Bills Introduced, Cyber Diplomacy, Election Cybersecurity, HR 3776, S 1821
Senate Amendments to HR 2810 (FY 2018 NDAA) – 9-13-17
Yesterday the Senate actually began consideration of HR 2810, the FY 2018 National Defense Authorization Act (NDAA). Meanwhile, more amendments continue to be proposed. In addition to the previously proposed amendments (see here, here, here and here) a large number of possible amendments to HR 2180 were proposed in the Senate yesterday; including five that may be of specific interest to readers of this blog:
• SA 1003. Mr. MCCAIN - National Defense Authorization Act for Fiscal Year 2018 substitute language (pgs S5487-671);
• SA 1009. Mr. SASSE - cyberspace solarium commission (pgs S5674-6);
• SA 1019. Ms. HARRIS - pilot program on integrating into the department of defense workforce individuals with cybersecurity skills and technical expertise whose services are supported by private persons (pg S5678);
• SA 1025. Mr. WHITEHOUSE - botnet prevention (pgs S5680-1); and
• SA 1055. Mr. PORTMAN - report on cyber applications of blockchain technology (pg S5701-2)
The substitute language (SA 1003) from Sen. McCain (R,AZ), and the staff of the Senate Armed Services Committee, is arguably the most important amendment to be offered to date, as it will form the working basis for the language that will be considered on the floor of the Senate. This language is based (as expected) on S 1519, the original Senate NDAA bill and it includes each of the cybersecurity related sections that I identified in S 1519.
SA 1009 would require DOD to establish the Cyberspace Solarium Commission with a mandate to “develop a consensus on a strategic approach to protecting the crucial advantages of the United States in cyberspace against the attempts of adversaries to erode such advantages” {SA 1009(a)}. The name harkens back to Eisenhower’s 1953 National Security Council’s Solarium Special Committee that was used to help formulate Eisenhower’s containment strategy vis-à-vis the Soviet Union.
The Commission would be tasked with {SA 1009(f)}:
• Weighing the costs and benefits of various strategic options to reach the goal of protecting the US cyberspace advantage;
• Reviewing adversarial strategies and intentions, current programs for the protection of the US cyberspace advantage, and the capabilities of the Federal Government to understand if and how adversaries are currently being deterred or thwarted in their aims and ambitions; and
• Evaluating the current allocation of resources for understanding adversarial strategies and intentions and protecting the US cyberspace advantage.
This proposed amendment from Sen. Whitehouse (D,RI) and Sen. Graham (R,SC) is very similar to S 2931 that was introduced in the 114th Congress by Graham and Whitehouse. This amendment does not deal with DOD issues, but the Senate rules do allow for the consideration of extraneous amendments.
The Senate held a cloture vote today on the McCain substitute language amendment and it passed with a bipartisan vote of 84 to 9. When the Congressional Record for today is published tomorrow I expect that we will see that some amendments were dealt with today, but at this point I have no idea which ones.
Labels: FY 2018 NDAA, HR 2810, S 1519
This afternoon the House passed a much-amended HR 3354 by a very partisan 211 to 198 vote. The vote was closer than the party membership numbers would indicate in part because of the 14 Republicans that voted Nay, but also because of the 25 members (16 Republicans and 9 Democrats) that did not vote (probably due to early flight times for their weekends at home).
The large ‘Nay’ vote just about guarantees that the Senate will not take up this version of the bill. I expect that we will see a Senate bill omnibus bill introduced (or possibly a substitute language amendment to this bill) that will then be amended in a lengthy floor process. The resulting bill will be harder to reconcile with this House passed measure in a form that both houses will be able to pass. Fortunately, we have until December 8th.
NOTE: Just a reminder, the three amendments that I had identified as being of potential specific interest to readers of this blog were all approved early in the amendment process.
Labels: FY 2018 Spending, HR 3354
ICS-CERT Updates an Advisory and Publishes Another
Today the DHS ICS-CERT updated a previously published advisory for a product from Siemens. They also published a new advisory for a product from LOYTEC.
This update provides additional information on an advisory that was originally published on originally published on May 9th, 2017 and updated on June 15, 2017, on July 25th, 2017, and then again on August 18th, 2017. The update provides new affected version information and mitigation links for:
• SCALANCE M-800,S615: All versions prior to V04.03,
The advisory describes four vulnerabilities in the LOYTEC LVIS-3ME HMI touch panel. The vulnerabilities were reported by Davy Douhine of RandoriSec. LOYTEC has released a firmware update to mitigate the vulnerabilities. There is no indication that Douhine was provided an opportunity to verify the efficacy of the fix.
• Relative path traversal - CVE-2017-13996;
• Insufficient entropy - CVE-2017-13992;
• Improper neutralization of input during web page generation - CVE-2017-13994; and
• Insufficiently protected credentials - CVE-2017-13998
ICS-CERT reports that a relatively low-skilled attacker could remotely exploit these vulnerabilities to cause information exposure or allow arbitrary code execution.
Labels: Controls System Security, Davy Douhine, ICS-CERT Advisory, ICS-CERT Update, LOYTEC, RandoriSec, Siemens
Last month Sen. Burr (R,NC) introduced S 1761, the Intelligence Authorization Act for Fiscal Year 2018. This bill is the Senate counterpart of HR 3180 that was passed in the House on 7-28-17.
While a good portion of the bill is not publicly available (classified) there are a number of provisions that may be of specific interest to readers of this blog. In addition to Title V (Securing Energy Infrastructure), those sections include:
Sec. 606. Report on cyber-attacks by foreign governments against United States election infrastructure.
Title V is very closely patterned on S 79 of the same title. There are only three significant additions to the language of S 79 found in Title V:
• Adding a definition of the term ‘Director’ as the Director of Intelligence and Counterintelligence of the Department of Energy {§502(2)};
• Adding an interim 180-day report to Congress {§505(a)}; and
• Adding a definition of the term ‘appropriate committees of Congress’ as the intel committees, the Senate Committee on Energy and Natural Resources, and the House Energy and Commerce Committee {§505(c)}.
Joint Cybersecurity Unit
Section 610 is similar in intent to the three bills introduced to date (S 1544, HR 3191 and HR 3259) that would prohibit funding for the establishment of a joint cybersecurity unit with elements of the Russian government. There is, however, a significant difference in the implementation of the restriction.
Section 610(a) would require the Director of National Intelligence to submit a report to Congress before and such unit is established. The report would include:
• The nature of any intelligence to be shared pursuant to the agreement;
• The expected value to national security resulting from the implementation of the agreement; and
• Such counterintelligence concerns associated with the agreement as the Director may have and such measures as the Director expects to be taken to mitigate such concerns.
The Senate Intelligence Committee held a mark-up hearing on July 27th, 2017 and they approved the current version of the bill. A committee report was published on September 7th, 2017. The bill will be considered by the Senate at some point in the not too distant future as this is one of the ‘must pass bills’ that each house must consider. A bill will eventually pass, though not necessarily this bill, and it would then be reconciled with the House bill in a conference committee.
Posted by Patrick Coyle at 1:49 PM No comments: Links to this post
Labels: Energy Infrastructure Security, FY 2018 Intel Authorization, S 1761