Tidbits Heard at SCADA Meeting

One of the things that I have been missing by being unable to attend meetings and conferences is the side conversations that take place during the breaks in the meetings. I heard lots of interesting stuff at the meeting Thursday and I thought that I would mention a couple of them here.

Password Phishing Attacks

I was talking with a nice lady from the Coast Guard (I’m terrible about names and we both thought that she had given me her card, but I don’t have it) and the conversation turned to the DHS HSIN (Homeland Security Information Network) and Homeport. Both are semi-secure communications network that require some level of vetting and password access. I asked about the password change frequency and she told me it was 90-days, so this seems to be some sort of DHS (at least) standard.

I then asked her if the CG sent out emails reminding people about changing their password and they do. I didn’t get to ask any more follow-up questions, but it got me to thinking. Readers will remember that I have taken ISCD to task (most recently) for the emails they send out for updating the passwords for access to CSAT. These emails contain a link to CSAT where the password can be updated. I suspect that the Coast Guard and the folks running HSIN do the same thing.

This practice leaves a large part of the security community open to phishing attacks. A savvy attacker could send out an email like this and get system logon information by having the link go to a site they controlled. It’s not that difficult to set up an official looking site, or even a duplicate of the official site, that would allow for the collection of sign-on information; and even transmit the information to the official site so the password change would take effect.

It seems that DHS as an organization needs to re-think its password policy. I’m not sure how justifiable a 90-day reset requirement is, but the emails going out to remind people to reset their passwords should not include a link to the site where that takes place. I know, it sounds real customer oriented, but it just sets people up for failure.

A final word on this topic (well in this post anyway, I’m afraid I will return to it again at some future time). If you receive an email from a DHS agency about updating one of your passwords with them, DO NOT click on any links in the email to do so. Use your own list of links to get to the site.

Shamoon Attack Vector

You’ll pardon me if I don’t mention where this last tidbit came from. There were a couple of side conversations that went on about the control system implications of the recent big name attacks, including Shamoon. No one had any news about any direct attacks on control systems by these programs, but a number of people were concerned about the possibility of control system information being harvested by these attacks; nothing new there. One of these conversations, however, did provoke a comment about an idea floating around the counter-intel community that the Shamoon attack on Aramco was initiated via a thumb drive (no duh) inserted into a security system computer by a Palestinian security guard.

Palestinians perform a large number of low-level jobs in Southwest Asia including front line security officers. Okay, I know that security guards are an important part of the overall security plan and shouldn’t be considered low-level employees, but they certainly are so considered by most people; just look at their pay scales. It wouldn’t be hard for any national intelligence agency, terrorist group, organized crime syndicate, or even an oil-industry competitor to find and turn one of these security guards into a thumb-drive agent.

I’ll bet that every guard-house at active security gates have a computer or security terminal inside. I would bet that they don’t receive anywhere near the attention that computers do in the secure areas of the facility. But they are networked to the security office which is, almost certainly, linked to the enterprise system. This would be a nice attack surface.

And, if you were planning an attack, cyber or physical, wouldn’t it be nice to have a look at the security system controls before you started the attack? Quis custodiet ipsos custodes? Hopefully, not the attacker.

EOScada Alert from ICS-CERT

Yesterday DHS ICS-CERT published an advisory concerning multiple vulnerabilities in the EOScada application from C3-ilex based upon a coordinated disclosure from Dale Peterson of Digital Bond [Links added 11-03-12 06:30 EDT] (yep, it appears that even Dale will succumb to the temptation to coordinate a disclosure). Dale identified vulnerabilities on multiple ports related to improper access control, resource management errors (on two different ports) and data leakage.

The advisory reports that a low skilled attacker could remotely exploit these vulnerabilities. C3-ilex has produced a patch that is available to owners that have an up-to-date service agreement with the company. Other owners will have to pay for the patch. Yes, the advisory says that owners without a service agreement will have to pay to get these vulnerabilities that were due to design ineptitude corrected. I think that I would rather pay to replace the offending system and never do business with the vendor again.

I’ll bet that if Dale had known that this vendor would charge for patches he never would have been involved in a coordinated disclosure.

InfraGard SCADA Briefing

Today I had the pleasure to attend an SCADA Security Briefing sponsored by InfraGard, the Louisiana Governor’s Office of Homeland Security and Emergency Preparedness (GOHSEP) and Cimation. The presenters were Special Agent Will Hatcher (FBI), Devin King (GOHSEP) and Marc Ayala (Cimation). There were about 20 attendees from Louisiana chemical companies, and ICS vendor, and the US Coast Guard.

Presentations

The presentation by SA Hatcher was a good review of the change in the cybersecurity threat over the last 20 years or so (it was nice to hear someone talk about cybersecurity that remembers that hackers started out as phone phreakers, stealing service from Ma Bell). It was a fairly comprehensive review of changes in IT and ICS security issues over time. As one would suspect, SA Hatcher has had more experience with IT security issues, but he had a good understanding of recent ICS issues and looked at the DUQU-Flame-Shamoon as potential reconnaissance tools for future ICS attacks.

Devin gave an interesting presentation on the cybersecurity programs that he has helped develop for the Louisiana Fusion Center, one of the first cyber-fusion units in the country. Once again his main background is IT security, but, because of the large petrochemical industry in the State, there is a significant interest in developing ICS related cyber-security information sharing in the State Fusion Center. He noted in the presentation that he is getting significant information about cybersecurity incidents from State and local government agencies (about 50,000 reported cyber-attacks of all sorts per week), but nothing from the private sector. He solicited input from the audience noting that the unit was able to providing a variety of situational advisories and an extensive IP Blocking list.

Marc gave an interesting presentation on ICS security, having worked with ICS systems for a number of years. He included an interesting story about an ‘air-gapped’ control system that he had looked at that was based on an old-style pneumatic control system; the only problem was that the compressor supplying the control system air was a new-fangled, electronically controlled system complete with an internal web server.

Marc provided an interesting bit of information about the recent attacks on pipeline control systems. It seems that ICS-CERT updated their advisory (ISCA-12-136-01D) on their restricted server last week. The new version provides lists of files, versions and dates that have been found on affected systems; data that can be used to check computers for symptoms of attack. Marc pointed out that one of the files would look like it was a file for an Adobe file reader. This is a good reason for control system owners to have someone signup for HSIN access to that controlled server. (NOTE: I'm not signed up for this because of information sharing restrictions on their restricted information; not a good thing for a blogger.)

Demonstration

Marc also provided a demonstration of the results of a denial of service attack on an AB PLC. He had a nice HMI-PLC system setup that controlled a pump motor on the other side of the room. First he showed how he controlled the pump motor from the HMI via the PLC. Then he sent some random signals to an open port on the PLC simulating a DOS attack; it took just a couple of seconds for the pump to shut down. Even worse he showed that the DOS attack also resulted in the instruction set on the pump controller being erased so that it had to be reprogramed before the system would work again. Then he demonstrated how a firewall device protected the open port.

Future Briefings

This was one of a series of these briefings being conducted around the State. There is another one next month in Lafayette, LA  (watch Marc’s blog at Cimation for registration information). I would certainly recommend that facility owners and security officers consider attending. I would also recommend that other state organizations consider contacting Cimation or InfraGard to set up similar briefings.

ICS-CERT Late in Publishing Siemens Advisory

Yesterday the DHS ICS-CERT published an advisory for the Siemens SiPass Server. Siemens published this on their ProductCert web page back on October 10^th, a fact I noted in an earlier blog post about another Siemens product advisory from ICS-CERT. This advisory describes a buffer overflow vulnerability that was reported in a coordinated disclosure by Lucas Apa from IOActive.

According to the ICS-CERT advisory this vulnerability could allow a relatively low-skilled attacker to conduct a DOS attack or potentially execute arbitrary code on the system. Siemens has produced a hot fix (available through customer support) for three versions of the system, older versions should be upgraded. Additional protection can be established by configuring perimeter firewalls to block the affected port.

DHS S&T Awards Cybersecurity Research Contracts

There is an interesting article over on HSToday.US that looks at an overview of 34 R&D contracts ($40 million) recently awarded by the DHS S&T Directorate to look at a variety of areas of cybersecurity research. The 34 contracts have been awarded to 29 research organizations including national laboratories, universities and private organizations. The research will address issues in 14 technical topics.

Anthony Kimery’s article looks at the broad picture of this research but doesn’t address how this might impact the industrial control system (ICS) community. That isn’t unexpected since the document that forms the basis for the research proposals being funded, the Cyber Security Research and Development Broad Agency Announcement (BAA) BAA 11-02, doesn’t mention control systems in its 82 pages and only mentions Stuxnet once (in an inappropriate manner at that).

Research Areas

Having said that, it is safe to assume that at least some of the research will result in information that will be useful to the ICS security community. Since we don’t have access to the specific research proposals we have to look at the technical topics listed in the BAA that the folks at S&T wanted the research community to address. Those technical topics areas (TTAs) are:

• TTA #1: Software Assurance;

• TTA #2: Enterprise-Level Security Metrics;

• TTA #3: Usable Security;

• TTA #4: Insider Threat;

• TTA #5: Resilient Systems and Networks;

• TTA #6: Modeling of Internet Attacks;

• TTA #7: Network Mapping and Measurement;

• TTA #8: Incident Response Communities;

• TTA #9: Digital Provenance;

• TTA #10: Hardware-Enabled Trust;

• TTA #11: Moving Target Defense;

• TTA #12: Nature-Inspired Cyber Health; and

• TTA #13: Software Assurance MarketPlace

ICS Security Excluded

The definition of three of these TTAs (#2, #4 and #12) specifically limits the research to areas affecting information technology. It is conceivable that results may have applications for ICS security, but the specific targeting of IT systems makes it unlikely that results will be easily transferable to the industrial control system setting.

TTA #7 looks at too large a scale to be of immediate usefulness in protecting control systems as it looks at the geographic and topological mapping of Internet hosts and routers.

ICS Systems

TTA #5 doesn’t mention control systems specifically but the description of targeted systems seems directly applicable to ICS; it targets ‘time-critical’ systems. It defines these as “a system for which faster-than-human reaction [emphasis added] is required to avoid adverse mission consequences and/or system instability in the presence of attacks, failures, or accidents” (pg 46). Interestingly this TTA suggests that researchers look at both security and resilience. Recognizing that malware is part of the cyber-environment the folks at S&T suggest that operation in the presence of malware is a key to security and resilience. They propose that researchers look at technology that enables (pg 47):

• Tolerating malware (for example, safely doing a trusted transaction from a potentially untrusted system);

• Investigating "safe sandbox" techniques for critical transactions; and

• Tolerating a residual level of ongoing compromise within components and subsystems of a larger system.

TTA #6 concerns the modeling of Internet attacks and this is where the folks at S&T mentioned Stuxnet (pg 49):

“Malware and botnet activity in recent months and years has intensified across the Internet and other critical infrastructures, with recent events, such as Conficker and Stuxnet, demonstrating the clear and present threat posed that is intelligent, adaptive, and effective at scale over increasingly shorter time periods.”

While Stuxnet certainly targeted control systems and did spread via the internet to non-target systems, the Internet was not used in spreading the malware to the targeted computers in Iran. Beyond this apparent misunderstanding, however, this TTA is at least partially addressed to research on control system security. The BAA makes this clear when it requires that:

“Technologies developed under this topic must perform their functions within legal and ethical boundaries. It is expected that the resultant tools would be commercialized and made available to critical infrastructure providers [emphasis added] in addition to government network operations.”

Limited ICS Applicability

The definitions of the remaining TTAs all could have some applicability to ICS security, but they are still basically addressing IT security issues. Depending on how the research proposals are structured will determine how much use they will be to the ICS community. Having said that, there are some parts of the TTAs that appear to be the most interesting from the view point of control system security.

TTA #1 looks at software assurance and calls for the development of new tools that will allow for the analysis of existing software, “discovering vulnerabilities, defects, and other types of weaknesses” (pg 36) as well as tools for runtime monitoring of software. The first will help identify potential security holes and second will help to identify attacks in progress. Both will be of great help in protecting any cyber-system from attack.

TTA #3 is very broadly defined, maybe too broadly defined to be of practical use but it does raise the issue of the inherent conflict between security procedures and ease of use. It note that (pg 42):

“Security must be usable by non-technical users, experts, and system administrators. Put another way, systems must be usable while maintaining security. In the absence of usable security, there is ultimately no effective security. The need for usable security is increasingly being recognized, as is the fact that usable security is a challenging problem.”

TTA #8 introduces a new term in cybersecurity response; the CSIRT – the Cyber Security Incident Response Team. This is a sociological research requirement designed to determine “the characteristics that make an excellent CSIR individual, team, and community, and how these capabilities are identified and enhanced” (pg 54). While this might be helpful in the long run it isn’t going to make any immediate change in the funding and manning of such organizations.

TTA #9 is a socio-economic look at cyber-attacks. It is a one-dimensional analysis of the problem of cybersecurity that asks researchers to look at the economic motivation of attackers. It completely ignores the political aspects of attackers; there is no acknowledgement of the problem of cyber-terrorism or nation-state directed attacks.

TTA #10 asks researchers to look at the importance of digital provenance; “the chain of successive custody, including sources and operations, of computer-related resources such as hardware, software, documents, databases, data, and other entities” (pg 61). Digital provenance is going to be increasingly important as more and more counterfeit components and software make their way into the control system supply chain.

TTA #11 addresses the concept of hardware security as opposed to ensuring security through software and firm ware. S&T asks researchers to look at “new technologies will ensure that hardware will not inadvertently leak secrets or execute malware (even if penetrated by malware), and it will execute security-critical tasks even if partially compromised” (pg 64). It certainly sounds like a worthwhile goal, but it would seem to limit some of the current functionality found in systems where firmware or software allows for expansion of capabilities.

TTA #13 introduces a novel idea, building into cyber-systems something akin to the biological response to infections. The BBA notes:

“In the future, network components must have heightened ability to observe and record what is happening to and around them. With this new awareness of the system health and safety, these “self-aware systems” enjoy a range of options: these system may take preventative measures, rejecting requests which do not fit the profile of what is good, a priori, for the network; these systems can build immunological responses to the malicious agents which they sense in real time; these systems may refine the evidence they capture for the pathologist, as a diagnosis of last resort, or to support the development of new prevention methods. In the future, system owners should be able to monitor and control such dynamic cyber environments.”

TTA #14 ties back into TTA#1. It asks for the establishment of (pg 75): “a software assurance facility and the associated services that will be made available to both software analysis researchers and software developers, both open source and proprietary. Software analysis researchers will have access to services allowing them to test new algorithms for static, dynamic, and binary analysis against a variety of software in a multi-platform environment.” The value of such a facility is obvious, but it requires the successful implementation of TTA #1 to provide the tools of the facility.

Results Are What Counts

The awarding of these contracts is an important step, but the amount involved is a relatively small investment in cybersecurity. And it must be remembered that the investment in research does not always (or even often) produce the desired results. Still it is an important step being taken by DHS and some of these programs should start paying off in the next year or so.

CFATS Knowledge Center Update 10-26-12

Yesterday the folks at the CFATS Help Desk updated the CFATS Knowledge Center by eliminating one frequently asked question (FAQ # 1649) and essentially replacing it with a new Article, # 1729. While both deal with the process for a facility to request an extension of a CFATS submission deadline, the new procedure is substantially different from the previous process and there is a much more detailed explanation of the procedure in the new Article.

Written Requests

The old FAQ was essentially a provision of the mailing address (one for USPS and one for delivery services) for the Director of ISCD. The only other information provided was a brief statement about what had to be included in the request (“please include the facility ID and an explanation for the facility’s extension request”) and a reminder to properly mark and mail any Chemical-Terrorism Vulnerability Information (CVI); short, sweet and to the point.

The procedure for sending a written request for an extension remains much the same. They did eliminate the double printing of the address, providing just the one address for both modes of snail mail delivery. If you are using USPS you can still eliminate the two lines between “Mail Stop #0610” and “Washington, DC 20528” as mail to government offices gets checked and deloused as necessary at the ‘Mail Stop’ before it gets to the District.

Electronic Requests

There were no provisions mentioned in the old FAQ for the electronic submission of extension requests. The closest it came was a specific prohibition against faxing such requests to the Help Desk.

The new CFATS Knowledge Center Article explains how a new application within the on-line Chemical Security Assessment Tool (CSAT) allows a Submitter to submit an extension request on-line. Once signed into CSAT and on the CSAT Survey List screen there is now a button for “Request Extension” for the pending survey (SVA or SSP). The Article goes on to explain the steps that need to be followed to complete the request, but they do seem to be fairly straightforward and in keeping with the feel of the rest of the CSAT tools.

Once the request has been submitted the “Request Extension” button on the CSAT Survey List screen will be replaced by an “Extension Request Pending” message. If you submit your request by snail mail, this same change will let you know that ISCD has started the process of reviewing your request.

Notifications

There is one other small change that has been made in this process that you have to be fairly alert to catch. At the end of the first paragraph in the Article there is the following sentence:

“Upon receipt of the extension request, whether in paper or electronic form, the Department will review all relevant information and notify the facility of the Department’s decision through CSAT [emphasis added].”

Recently ISCD stopped sending their CSAT related letters to the facility via FedEx (Did the Post Office know about a government agency using FedEx instead of USPS?) . They now only provide an email notification to the Submitter that a copy of the letter is available on CSAT. I’m not sure if this was done as a cost saving measure (and it surely is) or a security measure as FedEx doesn’t ensure ‘eyes only’ delivery directly to the addressee. Since CSAT is a ‘secure on-line tool’ this does increase security.

Phishing Problem

Or does it? The folks at ISCD have inadvertently compromised the security of the CSAT tool by setting up people registered on CSAT for phishing attacks. Let me explain….

ISCD requires that passwords for the CSAT tool be changed every 90 days; a bit excessive perhaps, but it does increase security particularly because there can be long periods between sign-ons. To help people remember to update their passwords, ISCD sends out a “Password Expiration Notice” email at 60-days; intended as a helpful reminder. Unfortunately, they include a link to the CSAT site in that email making it easier for an individual to complete the update process.

Anyone with any cybersecurity sense knows that clicking on a link in a ‘password update’ email is a sure way to be taken to a fake web site that will accept your sign-on name and your current and new password; giving someone else full access to your site information. Unfortunately, the number of people with cybersecurity sense appears to be limited as this is one of the most successful phishing ploys around.

Now this isn’t a new problem at ISCD. I wrote about this back in 2008. It has recently come to my attention that this problem is continuing to this day. If they must send out reminder emails, ISCD needs to conduct a significant educational campaign reminding people about the problem of clicking on links in emails that to go to “sign-on pages”. They MUST also stop including such links in their emails; all emails going to registered users of CSAT.

ICS-CERT Updates CoDeSys Alert

Okay, I have to apologize to the folks at DHS ICS-CERT for casting aspersions upon the integrity of their Alert/Advisory product. This morning ICS-CERT published an update on the CoDeSys alert originally issued in April of this year concerning vulnerabilities that Reid Wightman had identified during Project Base Camp in the CoDeSys SCADA application. This update addresses the new exploit tools that Reid reported about over on the blog at DigitalBond.com.

The folks at ICS-CERT then went me one better; they posted a link (provided by CoDeSys) to a page that identifies the vendors (and the device names) that are using the CoDeSys application that is at the heart of the problem. It’s a little more complex than just a list of names, you have to fill in some search blocks and hit the “Show” button, but it is a very interesting little list of vendors.