Dale Peterson Jacob Kitchel of Industrial Defender selected the interesting title of Am I Compromised? for his S4x13 session. However, the bulk of the session is different approaches to applying whitelisting to ICS components including:
- vulnerability-based approach
- whitelist them all
- sort and then whitelist (learning mode)
- establishing a clean and trusted system
Jacob looks at the challenges of knowing when you have a ‘clean’ system. It’s hard enough with a newly deployed system, but how to owner/operators know if their deployed system is clean.
Dale Peterson  Want to learn how Ruben Santamarta found the TURCK backdoor disclosed last week by ICS-CERT? Read his article on Identify Back Doors in Firmware By Using Automatic String Analysis. He pulls out the strings from firmware and then uses a tool he wrote called Stringfighter to identify likely hard coded credentials. Ruben we want you at S4x14.
A research report from Zpryme breaks down the $8 billion the US Government allocated to smart grid projects as part of the 2009 recovery act. $5.1B has been spent so far and $3.2B (63%) was spent on smart meters. The industry won’t see this market stimulating money again. The smart grid budget for 2014 looks to be $450M with most going to R&D rather than subsidizing meter purchases.
US Congressmen Markey and Waxman release a report they ‘wrote’ entitled Electric Grid Vulnerability – Industry Responses Reveal Security Gaps. The best part of the report is Table 1 on page 14. Key findings, such as utilities are under cyber attack, like every other company connected to the Internet, aren’t helpful. This mainly is a document to support past legislation that is being reintroduced.
May 28th is a big day in Japanese ICS Security as the government’s Control System Security Center (CSSC) will celebrate the opening of the ICS testbed in Tagajo. I haven’t visited the site yet, which is located close to Sendai and where the deadly tsunami hit, but the pictures show a truly first class facility for research and training.
ISA99 has released a draft of TR62443-2-2 Patch Management in the IACS Environment to help owner/operators develop a patch management program. They are looking for comments.
I generally avoid commenting on industry quotes in articles, but the Register article on respected expert Mark Fabro’s AUSCERT presentation is disturbing. It is not difficult to cause serious damage to the critical infrastructure by attacking an ICS. In fact, we had too many presentations at S4x13 showing how in simple ways that we are going to likely reject the simple attack sessions for S4x14. It certainly doesn’t require clearing 143K hurdles, and small team of 1-3 people with moderate skills and motive and a willingness to suffer the consequences of retribution can do significant damage. Perhaps the author didn’t accurately capture Mark’s viewpoint or maybe he was only talking about the difficulty of causing a nationwide blackout rather than just damage to a portion of the bulk electric system or other critical infrastructure.
Tweet of the Week
Don’t forget to subscribe to this blog RSS feed and follow @digitalbond.com on twitter.
Worth Reading Articles
Critical Intelligence provides reports and other information products on Cyber Situational Awareness and Threat Intelligence services for Industrial Control System Owner/Operators, Vendors and Government stakeholders.
Image by ChrisInPlymouth
 
Michael Toecker  There is a tactic in sales and marketed called ‘FUD’. Many of us are familiar with it, most of us have encountered it. It stands for “Fear, Uncertainty, and Doubt”, and the tactic involves influencing perceptions with overwhelming amounts of…. “Fear, Uncertainty, and Doubt”.
FUD is a constant issue in the ICS Security arena, for we deal with things that do more than go bump in the night, they can explode, spin themselves apart, electrify everything, and spread chemical nastiness into the air. So, are you suitably impressed now? Scared? Uncertain about your safety, and the safety of your family? Have an overriding need to call your representative, and vent that feeling? That’s FUD.
And like this recent article that quotes Joe Weiss and Walt Boyes. First, some respect: Joe bangs the drum harder and stronger than many in ICS, and his efforts in D.C. provide pressure for change. And Walt’s reputation precedes him as well, as a Fellow in ISA and former designer of industrial automation equipment. And it’s important to note that no article, no quote, can fully represent the totality of someone’s opinion. However, I’ve read enough from both of them over the years to know where they stand on IT and ICS.
But HONESTLY fellas .. Why all the FUD?
Yes, we need to be careful when we add security controls to industrial control systems, maybe not adding them at all if the age and capability of the system won’t support it. Yes, there are significant differences in how ICS works from the normal IT model, such as the need for reliable, on-time, and accurate data and control capability. And yes, well intentioned but ICS-inexperienced IT personnel have interrupted critical processes (of course, so have engineers, there is no monopoly on oops).
But, instead of following those statements up with tangible actions that IT and security vendors can take to become more aware and compete in this space, Joe and Walt criticize an entire establishment, basically because that establishment aren’t engineers, and don’t know how the plant operates. Fundamentally, not every ICS security project that employs IT personnel is doomed to failure, just as not every engineering effort is fated for success. What makes a project successful is the people, and how they work together toward a common goal, and all this division and suspicion just isn’t healthy. Good people build better tools, learn faster, and provide better risk reduction, regardless of where they are in the engineer/technician/professional hierarchy.
I understand where Joe and Walt are coming from, they don’t want unqualified individuals and companies working in the ICS space, and even talking (testifying?) about ICS related issues. They are concerned about unintended effects, especially effects that cause the exact problem the security is attempting to prevent and detect. But going about it in this way, spreading FUD around that is directed specifically at IT and Security companies may have an unintended effect itself: The truly competent hang back to ensure that they are competent, while the grossly incompetent blunder on into RFPs and site visits.
The fact is this: ICS owners hire those that put themselves forward for the work, not the ones that are hanging back. The space is getting a lot hotter, we need to get the best qualified at the front, and fast.
Readers, I’m here to tell you this: It’s ok if your role in a project is security, threats, and the tools used to mitigate against cyber intrusion, but not knowledge of the process. Security knowledge is necessary, it’s valuable, and it’s in short supply in the ICS community. But, know your limitations, and be open honest and transparent about those limitations, because you are not a process expert. There must be others at the table with the process knowledge, the operational knowledge to contribute. If those individuals aren’t there, I suggest you walk, because you are in a risky situation.
What is not ok is assuming you have that experience. What is not ok is doing work on ICS systems without proper guidance and discussion with those who do have a knowledge of the control system and the process. What is not ok is assuming the behavior of a control system based on an entirely different IT system. Ideally, the responsibility for ensuring that contractors are competent rests on the owner, but without standards of excellence in ICS and IT to measure individuals and corporations by, there is a lot of room for the incompetent to dodge.
In his blog post, Joe asks the question “What does it take for ICS cyber security to become mainstream..”?
My answer: We need security, management, and operations to sit down and discuss the real rewards and risks associated with putting security into ICS, and stop trying to scare each other off. This will not be a painless process, but with discussion and transparency we can make ICS security more mainstream, and develop practices to ensure reliability and availability of critical processes. Many of these practices exist, such as the NIST SP800-82 and ISA 99, but others will need to be found out the painful way, and communicated to industry. And, we need to stop the criticism, and make with the actions.
Or, we can continue to point and criticize and opine from the opposite sides of the table. Your choice.
title image by opensourceway
Michael Toecker  There has been a common theme in cyber security to have great discoveries follow on the heels of new tools. This situation exists in the sciences in general, and has been described by Isaac Newton, Stephen Hawking, and others as “standing on the shoulders of giants”, where the giants are those who have come before, often cutting their way through dense jungle, so that we can pick up the machete ourselves and continue, potentially making great discoveries in the process.
What’s even better is when a new tool comes along that opens up a new facet of cyber security to inspection and analysis. These tools transform complex concepts and science into commonplace analysis, allowing access to specialized science and technology that we had limited access to before.
A recent example is the Shodan search engine, a simple concept and large effort that allows researchers and others to search for internet facing systems, for whatever purpose they desire. Research using the Shodan search engine has uncovered unsecured SCADA, hundreds of thousands of vulnerable devices, potential misconfiguration, and other insecure situations. Without the Shodan engine, researchers that wished to look for these devices had to develop their own scanning and analysis infrastructure, not a simple task.
But, this is the past… What future giants will help shape how cyber security, and ICS, research will move? And what tools should we be developing to move the needle on ICS Security progress?
A commonly shared opinion is that the opening of Radio spectrum to easy analysis will lead to new research on radio based devices, both in ICS and regular cyber security. With a large chunk of automation being supported by radio in the 900 MHz spectrum, the RFCat is a must. I’ve written up my review of my experience with RFCat training here, and @at1as does many training events during the year as well.
Second, bug hunting is often depicted in media as an ‘individual sport’ with an image of some researcher bent over a keyboard, hunting and pecking. Not only is this view false, it’s very damaging from a sustainability perspective; fundamentally, the vendors out there that don’t do much security testing think that decent testing requires lots of manpower. The real pros, like Billy Rios and Terry McCorkle, have an automated infrastructure where software goes in, is processed, and the results are easily analyzed after-the-fact for the really nasty issues. They find more bugs while drinking beer and playing with their kids than any hunt and peck search.
Last, we all know most automation devices are inherently insecure, with protocols that do not provide integrity, access control, or authentication to ensure commands issued are coming from appropriate sources. So, we can make a finding like the one at the right, but what have we done to demonstrate this vulnerability? Well, we have some plugins with the Metasploit project for SCADA that can demonstrate this, much better than a simple one-liner in a report. (MTEdit: Uh, no production demonstrations, got it?)
So, my question to those who read: What tool should be developed for ICS Security that currently does not exist? What problem needs to be solved in a group manner before individual research can continue?
title image by Gage Skidmore
Dale Peterson 
Dave McGurdy, President & CEO of the American Gas Association (AGA), will testify before the US House Committee on Energy and Commerce. He has published his testimony (ht: patrick coyle). After singing the praises of their industries efforts on ICS security and the current public/private partnership, Mr. McGurdy takes potential US Government regulation head on:
In the recent past, concerns over increasing cyberattacks on critical infrastructure have led to legislative efforts to create a set of top-down cybersecurity regulations. AGA remains concerned that prescriptive cybersecurity regulations will have little practical impact on cybersecurity and, in fact, will hinder implementation of robust cybersecurity programs.
First and foremost, prescriptive cybersecurity regulations would fundamentally transform the productive cybersecurity relationship natural gas utilities have with the TSA Pipeline Security Division from a successful partnership to a more standard regulator-regulated mode, forcing companies to focus more resources on compliance activities than on cybersecurity itself. Also, from a practical perspective, it is unlikely that any set of cybersecurity regulations will be dynamic enough to help companies fight constantly changing and increasingly sophisticated threats.
I sympathize with AGA and other organizations trying to avoid regulation. NERC CIP actually harmed the cyber security posture of companies that were actively trying and succeeding in improving their ICS security. The gas sector, broadly viewed, has been one of the most proactive sectors, along with petrochem, in addressing ICS cyber security.
AGA membership is primarily natural gas distribution companies, but it also includes transmission companies, storage, and others involved in the industry. Some of these members are Digital Bond clients, and some have been actively working on SCADA security for over five years and are making great progress. Regulation would likely do little to improve their security posture.
The problem is the majority still have very poor SCADA security programs, and just like the electric sector will not spend money or resources on this until forced to by regulation or after something very bad happens. NERC CIP has at least forced some utilities to harden their security perimeters, employ user management controls, etc.
Two other points:
- I’m not sure if fracking falls under AGA, but those plant and field systems are being put up so fast because every day delay can be measured in dollars. Cyber security, while desired, is often pushed aside to get the operation running.
- Insecure by design – even those owner/operators who care and are actively working on security are stuck with a keep the bad guys out philosophy given the protocols and PLC/RTU available today. The defense-in-depth is really defense-in-security-perimeters.
I’m increasingly sympathetic to the contention that government or industry regulation is required. Developing effective and efficient regulation or certification programs is difficult, and I don’t have the answer, or strongly felt concepts, on how to do it. However, the lack of discussion and experimentation on what type of regulation or certification would be effective is disappointing.
Image by earthwatch
Dale Peterson Eric Johansson from Management Doctors in Sweden brought over a great Siemens S7 demo rack to demonstrate some attacks on the Siemens S7 PLC family.
At 7:45 Erik shows the Level 3 (highest security that controls read/write access) can be recovered by capturing the packets sent to the PLC. This was actually known and included in Siemens documentation (July 2011) as a potential weakness — with advice to not let the bad guys on your network.
At 14:13 Erik shows a denial of service attack on the Siemens equipment he brought to S4x13. It requires a power cycle and administrator action to put the PLC back into Run mode.
The Q&A at 18:19 is quite interesting.
Arne Vidstrom of FOI was part of the team that did this work.
Dale Peterson  Odd and troubling week.
DHS Secretary Napolitano announced Enhanced Cybersecurity Services — the US Government will share information on 0days and threats via a paid service offered by private government contractors like AT&T, Raytheon and Northrup Grumman. This would even include 0days purchased from researchers. Does this make or break the 0day market? How does this compare to a bug bounty? this is so odd it’s hard to even come up with a cogent argument for or against your tax dollars at work.
The US NIST published a document analyzing the request for information (RFI) responses to the upcoming cybersecurity framework. Respondents think it should be flexible, global, risk-based and leverage existing standards. Ok …
NIST issued Revision 1 of SP800-82 Guide to ICS Security. More importantly they announced an effort for a major update of this document to Revision 2 in the next year.
The NY Times and most other major media vaguely reported on cyber attacks on energy sector companies with the goal of sabotage or control of the ICS. The information is based on a non-public bulletin from ICS-CERT.
Anonymous announced Operation Petrol will start on June 20th against “greedy oil companies” and governments that support them.
The US Security and Exchanges Commission (SEC) reported that the 27 largest public companies sustained no major financial losses due to cyber attacks.
Tweet of the Week
the same public that says the #nist cyber security framework should be "risk based" says "baseball should include baseballs" #nistcsf #eo Don’t forget to subscribe to this blog RSS feed and follow @digitalbond.com on twitter.
Worth Reading Articles
Critical Intelligence provides reports and other information products on Cyber Situational Awareness and Threat Intelligence services for Industrial Control System Owner/Operators, Vendors and Government stakeholders.
Image by ChrisInPlymouth
Dale Peterson 
If you had any doubts about the thirst for ICS security news in the press, this week’s articles on some research from NC State provided a vivid demonstration. NC State puts out a press release on some early research, far away from anything that can be purchased, questionable if it would be of value in and ICS, and it turns into articles such as New Software Protects Networked Control Systems From Cyber Attacks.
Let me be clear that is not a knock on the research itself. We have been advocating and highlighting ICS security research for almost a decade now with our S4 conference. The researchers at NC State have an interesting approach that we might consider worthy of a slot at S4x14 or some future event as it develops.
The paper Convergence and Recovery Analysis of the Secure Distributed Control Methodology for D-NCS is available online.
The base idea is to eliminate sensor data from a process if the sensor or device passing the sensor data has been compromised. Actually, this could be due to any fault, not just a physical or cyber compromise. The challenge is how does the system know the sensor or device has been compromised?
The researchers rely primarily on a consensus algorithms, which I believe would severely limit it’s practical use. The example given in Section V.A is easy to understand. Eight temperature sensors take a measurement, and sensors 5 and 6 vary significantly from the converged value of the other six sensors. They are considered compromised and excluded from the process.
The problem with using consensus algorithms to detect cyber attacks or other anomalies is it requires the deployment and maintenance of a large number of additional sensors that don’t exist today in most control systems. Many times sensors are not redundant (let alone in numbers to allow consensus calculations), but data smoothing/interpolation takes place to remove and replace flawed or missing data. In a sense the researchers suggest doing this in a brute force way rather than through intelligent use of surrounding state and data.
There are high risk / high value sensors that implement a simple variant of the consensus algorithm suggested by the researchers. For example, you will sometimes see three sensors used in the chem sector, and one of the sensor’s data discarded if it varies more than a certain percentage from the other two sensors’ data.
If this is pushed out to the field or plant, as the researchers envision and makes sense, then the consensus algorithm would be implemented in the PLC which is much more likely to be attacked than the sensor. And there is still the data integrity issue in the PLC demonstrated by Stuxnet.
A more promising and realistic and difficult approach is to combine the suggested removal of data from a process with process anomaly detection rather than consensus algorithms. There have been a few sessions at S4 where researchers have tried to model possible states of a process and detect when impossible or unlikely states or state chains occurred. The most detailed have involved substation processes, and it has worked. The problem is it was very time consuming to develop the model to detect anomalies.
One minor item in the paper particularly worried and bothered me. The researchers used the term Distributed Network Control System (D-NCS). DCS is a very common term if they wanted to focus on plant implementations, or the could have used ICS. Did they not know what terminology is commonly used by the people they hope will use the research?
The NC State press release was reasonable, not sensational, and sensible marketing of their research capabilities. The press are simply feeding the reading public what they want. The oddity is the interest in control system security is stronger outside the control system community than inside the community where the majority still hope the issue just goes away.
Image by chrissam42
Stephen Hilt  PLCScan is a utility that was released by scadastrangelove to help identify PLC devices. It does so by acting as a port scanner to see if two common ports are open and then decides what to do based on the availability of the ports. Documented within The Rack is PLCScan, a set of python scripts that will help gather information from PLC Devices.
First uses of a utility like this, could be fast scans of large subnets to identify PLCs. This could be PLCs of your own networks or PLCs of the internet, after all the blog post from scadastrangelove was titled “PLCScan the Internet”. It is only a matter of time before functionality of this sort gets added to searches like Shodan. A problem is that even this utility can cause issues on a production system if one does not know what kind of sensitivity comes along with these types of scans.
The more we use the control system protocols within to help identify the systems the more accurate information we will be able to get from the devices, also the safer the utilities will be to run. In recent blog post about practicing tools, Ralph Langner said “the device should be considered fragile by default, period”. I agree with this statement, especially for utilities like PLCScan, we should assume that we will bring the device offline if we are using a tool against a production network.
PLCScan could add great abilities to the assessment team. The utility can pull information from a PLC that then can be used as a reference point to validate information. This information could be information that the assessment team would had to manually pull from devices and configurations with screenshots. Information from the output from utilities like PLCScan are a lot easier to parse and utilize the data then reviewing screenshots.
Even with the risk of bringing the device offline the benefits to knowing what type of information that utilities like PLCScan can provide are very important to understand. Based on the testing we have performed with PLCScan, the script is well written and does take some errors into account to be the safest with the device as possible. It should be used against hosts and not subnets to start with as the only way to truly stop the scan may leave some devices in state that might crash the device.
Control system specific utilities like PLCScan will provide good information and a great value to the community if we keep helping projects like this get the most amount of information in the safest way possible. The more information we are able to gather about the systems on line we will be able to have accurate information about what is truly connected to the internet. If we can correctly identify the devices attached, we can remove them from the internet and protect them from malicious uses.
Image from Threatpost
Dale Peterson  I asked Eyal Udassin of C4-Security in Israel to comment on the ICS hack disclosed this week. “The hack isn’t something for the books. It’s of small kibutz named Sa’ar in the northern part of Israel, indeed from a year ago. The operator had a remote access software with no password on it, so not surprisingly it was hacked. He found out that someone moved the screen view the same morning, so he understood immediately that something is fishy and changed the remote access method to a secure one.”
ISA99 released another draft standard for comment this week – ISA-64432-4-1 Product Development Requirements. I’ll write up my thoughts on it in an article next week.
Kim Zetter of Wired covered another vulnerable ICS connected to Internet story this week. It normally wouldn’t warrant mentioning as loyal readers have certainly heard enough of this Shodan / Internet search story. However, it was a Google Building Energy Management System.
Tweet of the Week
1) Hack Google's Building Management System2) Report it to the Google Vulnerability Rewards Program3) …4) Profit?http://t.co/VvLJrjrr9N  Don’t forget to subscribe to this blog RSS feed and follow @digitalbond.com on twitter.
Worth Reading Articles
Nothing this week.
Critical Intelligence provides reports and other information products on Cyber Situational Awareness and Threat Intelligence services for Industrial Control System Owner/Operators, Vendors and Government stakeholders.
Image by ChrisInPlymouth
|
Subscribe:  
Schneider Has Not Removed Modicon FTP Backdoor Account In
2377 days
Worth Reading
The connection to twitter has returned an error. Please try again later.
|
