NCCIC Revamps ICS Web Site

Yesterday the DHS NCCIC redid their US-CERT and ICS-CERT web sites. According to a blurb on the site: “On June 25, us-cert.gov and ics-cert.us-cert.gov were consolidated into a single us-cert.gov site—a comprehensive, easy-to-navigate website with an updated look and feel.”

Actually, there are still two separate pages for IT and ICS activities. The main page for cybersecurity activity is https://www.us-cert.gov/. This page includes current US-CERT alerts, advisories and reports. It also contains links to a set of ICS pages on the site header, including the new ICS landing page: https://www.us-cert.gov/ics. That landing page looks to contain all of the information and services found on the old ICS-CERT site.

I liked the old format better, but then again, I have been using it for the last ten+ years. Nothing is constant except change.

Maybe more to come as I dig into this over the weekend.

US-CERT Publishes Heartbleed Bug Alert

This morning the US-CERT (NOT my normal ICS-CERT) published an alert for a TLS/DTLS heartbeat functionality vulnerability in the OpenSSL system. Now I don’t normally follow US-CERT vulnerability announcements very closely, but it has been pointed out  that this vulnerability may have a very big control system component.

The Vulnerability

US-CERT notes that a remote attacker with a publicly available exploit could gain access to sensitive data, possibly including user authentication credentials and secret keys, through incorrect memory handling in the TLS heartbeat extension. This could allow the attacker to decrypt data, obtain log-in credentials, or perform man-in-the-middle attacks using the OpenSSL protocols.

There is an interesting discussion of this vulnerability at HeartBleed.com.

The Control System Connection

The popular press has made the point that this makes a number of supposedly secure communications protocols vulnerable. One such protocol could be an organizations virtual private network (VPN). Since ICS-CERT has been pushing the use of VPN for ‘secure’ remote connections to control systems, a number of people are using the OpenSSL protocol to connect with their control system. These ‘secure’ connections are now vulnerable.

In a post over on the SCADASEC list at Infracritical.com Jake Brodsky notes that “this is a problem with the source code of OpenSSL/TLS. This code is embedded in many places, including many SCADA RTUs and associated network hardware”. People are going to have to do some hard looking to find all of the implementations of this system and get them corrected.

It would be real nice if ICS-CERT were to get out in front of the control system vulnerability side of this issue.

More USB Problems

As if Stuxnet hadn’t produced enough concerns about using USB jump drives with industrial control systems, yesterday US-CERT posted a warning about reports of “newly purchased removable media devices [that] are infected with malicious code”. If the system autorun is enabled (the default setting for most systems) the worm will infect the system when the device is connected.

There is no information in this report about what types of ‘removable media devices’ have been reported to be infected. This is not really a new issue; I recall reports of digital picture frames becoming infected at the manufacturer’s location when the quality control checks were done with an unprotected computer. Whether the devices being reported to US-CERT were deliberately or accidentally infected is not explained in this warning.

US-CERT recommends the implementing the following security practices:

• Disable autorun in Windows [see Microsoft knowledgebase article 967715].
• Maintain up-to-date antivirus software.
• Maintain up-to-date hardware, operating systems, and software by applying security patches, fixes, and updates.
• Perform virus scanning of the removable media devices prior to each use.

Please note that this warning did not come from DHS ICS-CERT so it did not include the caveat included in most ICS-CERT mitigation recommendations that administrators need to evaluate the potential impacts of the recommended mitigation measures on their particular systems prior to implementation.