DHS Updates CIP Landing Page

DHS maintains a number of ‘landing pages’ where they post links to a wide variety of web pages on their site that might be of interest to specific homeland security audiences. Recently they updated the ‘Critical Infrastructure Protection’ landing page by adding a link to their ‘Cybersecurity’ landing page.

Since all sorts of computer systems are an integral part of each of the 18 Critical Infrastructure Key Resource (CIKR) sectors, adding this link to the CIP page was obviously a smart and somewhat overdue move. Unfortunately the cybersecurity page provides very limited information on a key function of most of the 18 sectors; industrial control systems. In fact, there is only one ICS specific link on the page; it goes to the ‘Control Systems Security Program Training’ page of the CSSP site.

Don’t get me wrong. The inclusion of the training programs page is very important. The CSSP training programs are an invaluable, if severely limited in time and resources, part of increasing the overall security of industrial control systems in the United States.

Two other CSSP programs should be specifically linked to the cybersecurity landing page; the CSSP homepage and the Cybersecurity Evaluation Tool (CET). To aid in identifying the CET as a control systems evaluation tool the listing of that tool on the cybersecurity page should probably include ‘ICS’ or ‘Control System’ in the title. Of course the CSSP homepage includes a link to the CET page, but a specific listing under say ‘Technical Resources’ on the Cybersecurity page would almost certainly increase the visibility of that tool.

Arguably the most valuable part of the CSSP site is the listing of the latest control systems alerts and advisories found on the homepage. This listing helps insure that system owners and operators get the latest information on vulnerabilities that could affect their control systems. Adding this link to the CIP landing page would increase the visibility of CSSP site.

ICS-CERT Issues Duqu Update, New Advisory and New Link

Today was a busy day for the folks at the DHS Industrial Control System Cyber Emergency Response Team (ICS-CERT); they updated their alert on Duqu, they published a new advisory on a completely separate control system issue and updated the bad link previously identified by some muckraker.

Duqu Update

Less than a day after their initial information alert on w32.Duqu, ICS-CERT provides some added details (presumably supplied by Symantec and/or McAfee) that may allow targeted vendors to identify if their systems have been attacked by Duqu. They provided the command and control server IP address (already shut down according to the alert) and recommended that network and proxy logs be checked for communications with that IP; a sure sign of past or current infections.

They also noted that organizations should update their ‘antivirus definitions’ to allow for detection/prevention of present or future attacks (both McAfee and Symantec have announced that such definition updates are available for their products).

A strange question occurred to me today while reading some of the other conversations and articles about Duku; does this sound like a coordinated disclosure to anybody? I know… this is really a vulnerability in a ICS system so maybe ‘coordinated disclosure’ is not really a proper term to use. But, it does seem to me that the same reasoning should apply; keeping this quiet should have allowed ICS-CERT to coordinate with the relatively small targeted community to detect and isolate this particular Trojan. A public disclosure like this gives the perpetrators too much information about the mistakes that they made that allowed them to be detected.

The reason that I ask is that if this wasn’t the equivalent to a coordinated disclosure (and there is no indication that ICS-CERT got any earlier warning than did the rest of us) why do Symantec and McAfee get their names mentioned when researchers like Beresford and Luigi get specifically un-named? I know what I suspect the answer is, but I’ll leave that as an exercise for the reader.

Schneider Electric Advisory

This new advisory addresses a buffer overflow vulnerability reported (in a coordinated fashion) by Kuang-Chun Hung from the Information and Communication Security Technology Center (ICST) in a device driver used by six different software packages from Schneider Electric.

The ICS-CERT advisory notes that an attacker with a low skill level could use this vulnerability to execute a denial of service (DOS) attack. It would take a more skilled individual to use the vulnerability to execute arbitrary code. Both types of attacks could be remotely executed.

Schneider Electric has published a patch and provided customers with notification describing the vulnerability. The effectiveness of the patch has been verified by ICST.

CSSP Year in Review

Earlier today I noted the bad (incorrect) link associated with the publication of the CSSP Year in Review. The folks at the DHS Control Systems Security Program have corrected that problem and there is now a good link to a pretty PR-document.

Leading people to believe that this is a review of the work that CSSP has done during the last fiscal year is misleading at best. There is a single 8-bullet listing on page 3 that explicates (very broadly and briefly) the accomplishments of CSSP.  For example the first bullet point is:

“• ICS-CERT fly-away teams were deployed to seven organizations over the fiscal year (FY).”

Don’t get me wrong; I understand that these fly-away teams provide an important functional capability, but that is not even addressed. But, we now know that they deployed.

Unfortunately, the things that I was hoping to see addressed did not make the cut. In my quick skim of the 16 pages (filled with color photos) I did not see a single mention of Stuxnet, Beresford v Siemens or Luigi v HMI. Oh well good PR is always valuable for organizations, particularly for public funded organizations.

CSSP Page Update 05-24-10

Just last week I updated you on the changes to the DHS-CERT Control System Security Page and I discussed their updated reporting procedures for industrial control system cyber incidents. Unfortunately, some of the information that I told you about has been removed from the CSSP main web page. DHS removed the email address for reporting ‘general cyber activity’ (soc@us-cert.gov) as well as a second phone number. There hadn’t been an explanation of what that second number would be used for so that doesn’t seem to be a major change. The one change that I am disappointed to see is that DHS removed their offer to “provide onsite assistance, free of charge, to organizations that require immediate investigation and resolve in responding to a cyber attack.” I had noted that this type of assistance could be invaluable for facilities experiencing a cyber incident, especially since most facilities don’t have the necessary internal expertise to conduct these investigations or correct the problem. All was not negative in this latest change. DHS did move the link to their public-key to the main page so that facilities can encrypt confidential or sensitive business information when making their reports. Fortunately the links that I provided (and are still not available on the CSSP page) for the Phishing reporting procedure and reporting vulnerability issues are still active.

DHS-CERT CSSP Calendar Page Update 05-11-10

The DHS-CERT Control System Security Program has updated their Calendar web page. They have had June training date posted for their Introduction to Industrial Control Systems Cybersecurity for Federal Employees class for almost a week now, but today they have added a class description and registration information. It’s kind of odd since a July training date has had this type information available since last month.

Of course, the July training is an advance class that lasts five days and is being held in the Idaho Falls, ID training center. The June 9th class will be held in Washington, DC and it will be an introductory course. These classes are for Federal employees and contractors and are free of charge. Only a limited number of spaces are available. As DHS and the rest of the Federal Government ramp up the number of employees available for cyber security duties, classes like these are going to be very valuable. As I noted in my blog about the July class, I certainly recommend that ISCD get as many of their chemical inspectors to these classes as possible. Last week I explained that there is a weakness in the CFATS inspection program because of the dearth of qualified ICS security experts to conduct SSP inspections. These CERT classes will be invaluable in correcting that situation. As always, I would really like to hear from any readers that attend these classes. I would like to hear the gory details of how well these classes are taught and how comprehensive the coverage is. As a professional instructor I know that student feedback is not necessarily a good gauge of instructional performance, but it is one of the few metrics to which I will have access.

CSSP Web Page Update 04-23-10

On Friday the DHS-CERT Control Systems Security Program website was updated with links to new security warning documents and information on training that will be offered by CSSP in July. Control System’s Analysis Reports Under the ‘What's New’ heading on the site there are two new documents that every security officer and cyber security officer at high-risk chemical facilities should read. They deal with two potential attack vectors that are being used to attack control systems. The first report, SSH Brute‐Force Scanning And Attacks, addresses an attack mode that has been familiar to the general IT community for years, the brute-force authentication search for authentication credentials on systems providing secure shell (SSH) command line access. Control systems or their components that are running SSH on a default TCP Port are particularly vulnerable to this type of attack. The report explains the risk for this type of attack and methods to reduce/eliminate the threat. The second report, USB Drives Commonly Used as an Attack Vector against Critical Infrastructure, describes a variety of ways that USB devices like thumb drives can be used to gain unauthorized access to control systems. From social engineering attacks, to malware infected devices, and intentional insider attacks using LaunchPad applications, a number of techniques for attacking control systems using these devices are described. Advanced Cyber Security Training The CSSP Calendar web page was updated, removing the April classes and providing information on a July training program, the Control Systems Cyber Security Training and Workshop for Federal Employees. This five day training course will be conducted on July 19th thru 23rd, 2010 and will be held at the Control Systems Analysis Center in Idaho Falls, ID. This program will address a variety of current cyber security techniques for ICS security and will include Red Team/Blue Team exercises. Hopefully, DHS ISCD will be able to get some of their chemical security inspectors to this type of training.

Control System Security Metrics

A key component in any attempt to ‘improve’ a system is the ability to measure change in system characteristics. It is only thru such measurements before and after a system change that an objective analysis of improvement can be made. The DHS Control Systems Security Program (CSSP) recently published their latest version of their suggested metrics for measuring changes in relative security of industrial control systems (ICS), the Primer Control Systems Cyber Security Framework and Technical Metrics (Primer). Dimensions of Cyber Security The CSSP Primer describes a ‘framework’ for making decisions about ICS security. It identifies seven control systems cyber security dimensions that “capture many of the system attributes, which correlate with a control system’s risk exposure” (pg 1). The CSSP uses the term ‘dimension’ because they describe “an important aspect of the control system’s cyber security posture at a given point in time” (pg 2). Those seven dimensions are:

“Security group knowledge “Attack group knowledge “Access “Vulnerabilities “Damage potential “Detection “Recovery”

Detailed definitions of the terms can be found in the Primer (pg 2), but most of the dimensions are relatively easy to decipher just from their titles. The two ‘group knowledge’ dimensions are a little less clear than the others. The ‘Security group knowledge’ looks at looks at how easy it is for changes to be made to the ICS without the knowledge of those responsible for the security (the ‘Security Group’) of the ICS; supposing that such surreptitious changes could be used to gain control of the system. The ‘Attack group knowledge’ dimension looks at how easy it would be for an attacker to gain information about details of the system that would allow for a deliberate, knowledgeable attack on the system. ICS Security Metrics The security ‘dimensions’ help to define the framework for ICS security measures, but they do not provide any direct measures that will allow a facility to track the ‘performance’ of their security systems. The Primer notes that there are a number of different metrics that have been developed by people in the industry and provide the following list of references (pg 24) as examples:

“E. Chew, A. Clay, J. Hash, N. Bartol, and A. Brown, Guide for Developing Performance Metrics for Information Security, NIST Special Publication 800-80, May 2006.

“R. Ross, S. Katzke, A. Johnson, M. Swanson, and G. Rogers, “System Questionnaire with NIST SP 800-53: Recommended Security Controls for Federal Information Systems,” Technical Report, NIST, References and Associated Security Control Mappings, Gaithersburg, Maryland, March 2006.

“M. Swanson, N. Bartol, J. Sabato, J. Hash, and L. Graffo, Security Metrics Guide for Information Technology Systems, NIST Special Publication 800-55, National Institute of Standards and Technology (NIST), Gaithersburg, Maryland, July 2003.

“M. McQueen, W. Boyer, S. McBride, M. Farrar, and Z. Tudor, "Measurable Control System Security through Ideal Driven Technical Metrics", S4: SCADA Security Scientific Symposium, January 23, 2008”

The Primer authors note that to be effective there should be at least one metric for each of the ICS security dimensions listed in the Primer. They recommend (pg 5) that the following 10 metrics (and associated dimension) should be used to track changes in the security posture of ICS:

“Rogue Change Days (Security Group Knowledge); “Security Evaluation Deficiency Count (Security Group Knowledge); “Data Transmission Exposure (Attack Group Knowledge); “Reachability Count (Access); “Attack Path Depth (Access); “Known Vulnerability Days (Vulnerabilities); “Password Crack Time (Vulnerabilities); “Worst Case Loss (Damage Potential); “Detection Mechanism Deficiency Count (Detection); and “Restoration Time” (Recovery).

According to the authors, each of the metrics listed above is an answer to one basic security question: “What can be objectively measured on the system that is a reasonable representation of how nearly the system approaches the ideal of its associated control systems cyber security dimension?” The Primer provides a detailed technical discussion of each metric including a range of possible values and an ‘ideal’ value. While ‘ideal’ value may not be achievable, the measurable values do provide a tool for tracking progress or assessing the efficacy of security measures. Case Studies The Primer does provide two examples of how the security dimensions and metrics were used in actual practice in two different case studies. The first such study will be of primary interest to the chemical security community since it took place at a chemical facility with a DCS ICS. Unfortunately the details associated with the case studies are minimal and there is little discussion of how the metrics were applied. There is more detail for the second case study which looks at the more politically sensitive case of an electric power distribution SCADA system. Standards for Metrics What is missing from the discussion of the metrics is the definition of an ‘acceptable’ value for the metric signifying that the security measures are ‘adequate’. There is a brief mention of ‘target’ values in the two case studies. The authors describe the suggested target value as “the value that could be obtained by changing the system configuration to improve cyber security while retaining required functionality” (pg 20), but provide no information on how the value was set and use different values in the two different case studies. While not stated in the Primer, the reason for the lack of definition of acceptable values is at least partially based on the fact that such a decision is at its most basic a management evaluation of the risk and the cost of security. Where legal standards are set (and that has not yet been done for ICS) for acceptable values then achieving those standards becomes a matter of compliance not security. Recommendation The CSSP should be commended for developing this document. It is a valuable addition to the cyber security debate. It is, however, probably not an adequate amount of information to develop and implement a metric based ICS security monitoring program. It assumes a relatively high level of knowledge about industrial control systems and computer networks. If CSSP provides some training sessions (on-line and on-site) to support this framework, it will be much more accessible. Having said that, facilities that use an industrial control system need to get a copy of this document and review it in detail. High-risk chemical facilities in particular should pay special attention to these metrics in developing their cyber security programs.