Posts Tagged ‘SCADA security’
Wednesday, June 25, 2014 @ 02:06 PM gHale
Editor’s Note: This is an excerpt from the Practical SCADA Security blog at Tofino Security.
By Eric Byres
One of the most recent and the most informative security conferences was the International NCSC One Conference 2014 at the World Forum in The Hague. This is a massive and well organized event run by the Netherlands National Cyber Security Centre, the Dutch equivalent to the US-CERT.
During NCSC One, I heard some great talks on the state of encryption technology today, SCADA security consortiums, and foreign APT threats. But the highlight was the plenary speech by Jon Callas entitled “Security and Usability in the Age of Surveillance.” Jon’s talk focused on Bring Your Own Device (BYOD) security, but it raised some questions that are core to cyber security in the 21st century.
The BYOD controversy revolves around the possible security issues that arise when employees use their personal mobile devices to access privileged company resources. A common example is using your iPhone to access your company’s email system – does this increase or decrease corporate security?
The first question that Jon brought up was around understanding the real goals of any security policy or program. While security traditionalists talk about ensuring Confidentiality, Availability, and Integrity, Jon suggested the real goals can end up divided into two more general ones:
• Maintaining Safety
• Maintaining Control
Most of the time the reason given for a specific security policy is safety – for example, securing a SCADA system to ensure the safety of the processes, people, and products. This reason is hard to argue with. After all, who wants to be less safe?
In reality there are many security policies that have nothing to do with safety; instead, they are about maintaining IT control. Now this isn’t necessarily bad, but it is a lot harder to sell compared to the safety argument. So the safety excuse gets rolled out every time.
Enter the Evil Smart Phone
Jon then explained how this relates to the BYOD controversy. When mobile devices first came onto the market, the IT department loved the BlackBerry. Like the mainframe and the central server, the BlackBerry architecture centralized everything. Every email you sent and every note you made passed under the watchful eyes of the IT department. Any other mobile device was banned because it was “unsafe” for confidential company information.
Unfortunately for Blackberry, the real customer wasn’t the IT department, but rather the end user. When the user was a lowly engineer or a sales person, the iPhone, iPad, or Android could be safely ignored. But once company chief executives started to buy iPhones and saw how effective they were, suddenly IT had to start accepting other mobile devices.
The flood gates burst open and soon iPhones and Androids dominated the corporate world while Blackberry withered to a shadow of its former glory.
Yet to this day we still hear lots of crying about how insecure personal mobile devices are and how the IT department has to “bring the problem under control.” There are endless pitches for BYOD security products and no shortage of corporate policies (many of questionable effectiveness) intended to “manage the problem.” The reason always given is the “safety and security” of corporate intellectual property.
Laptop More Secure than iPhone?
But is the iPhone or Android really the security risk the IT world claims? Or are they just annoyingly difficult to maintain centralized control over?
Sure, smart phones aren’t perfect, but how many truly effective rootkits have you seen for attacking iPhones? Now consider how many rootkits there are for taking over PCs. How many serious mobile device vulnerabilities have you needed to quickly patch in the last year? Maybe two? And how often do you have to install a critical Windows, Java, or Adobe patch on your PC? Every week? As Jon put it: “Antivirus software for the mobile device is not exactly a growth market.”
In fact, it may be that personal phones are actually more secure than all the other devices that are welcomed by traditional IT.
Smart phones are also more carefully guarded by their owners. Jon quoted studies showing, on average, people noticed and reported a missing phone in less than 20 minutes compared to 24 hours for a missing wallet. If someone stole my laptop on a weekend, it could be two days before I noticed. And once an iPhone goes missing, the remote wipe features are very effective. I doubt my IT department could ever wipe the laptop they gave me if I happen to lose it.
Mobile Devices are NOT Perfect but…
To be clear, Jon is NOT saying that mobile devices are perfectly secure – far from it. But all the evidence suggests that they are more secure than any other common computing device currently in use. Thus the argument to tangle up iPhones and Androids in red tape is just an excuse. And industry might just be better off from a security point of view if we embraced — or even encouraged — the mobile device on the plant floor. It certainly is worth considering.
Picking the Right SCADA Battles
I often think that safety as an excuse for control is common in airport security. Many of the restrictions and processes required by both the TSA and the airlines with the “We’re doing this for your protection” justification appear to be a way to make the customer easier to control (or are an excuse to cut services).
For example, The Atlantic magazine reported that a TSA employee confessed to reporter Jeff Goldburg the purpose of enhanced pat downs was to make opting out of full body scans so unpleasant that everyone would choose to go through the scanner. This would make the inspection process quicker and cheaper for the TSA.
Causing people frustration never leads to better security; it just encourages rebellious behavior. This is doubly true for the industrial world. It is human nature that people (especially engineers!) only have so much patience for security policies that make their job harder to do.
Institute a few security controls that offer clear safety benefits and people will respect them. Throw too many controls in a person’s way and they will find a way to circumvent them so they can get their job done. Unfortunately people don’t necessarily pick the least effective controls to ignore – they might obey the ineffective measures and bypass the important ones.
Thus, as SCADA security professionals we need to pick our security battles carefully. After listening to Jon, I will be looking deeper into the real goals of any SCADA security policy or technology I am exposed to. Is it really helping make SCADA and ICS safer? Or is it just a way to make control easier? Is it addressing the real risks? Or is it just for show? Fail to ask these questions and we risk creating a backlash against the whole SCADA/ICS security message. And that will be a loss for the entire industry.
Eric Byres is vice president and chief technology officer at Tofino Security. Click here to read the full version of the Practical SCADA Security blog.
Wednesday, February 29, 2012 @ 04:02 PM gHale
The past two years have been a real wakeup call for the industrial automation industry. For the first time ever there is proof the industry has been the target of sophisticated cyber attacks like Stuxnet, Night Dragon and Duqu.
If you are a process control engineer, an IT professional in a company with an automation division, or a business manager responsible for safety or security, you may be wondering how your organization can get moving on more robust cyber security practices.
In order to provide you with guidance in this area, Eric Byres, chief technology officer at Tofino Security and John Cusimano, director of security at exida, wrote a white paper entitled “7 Steps to ICS and SCADA Security.”
Wednesday, November 2, 2011 @ 05:11 PM gHale
Editor’s Note: This is an excerpt from Eric Byres’ Practical SCADA Security blog at Tofino Security.
By Eric Byres
On one hand, industry is becoming concerned about just how vulnerable control systems have become to outside attacks. But the irony continues as new tools and applications that increase that exposure are appearing daily.
It is a well-proven fact human beings are terrible at making good judgments about risk. We badly under estimate the risks of very infrequent, but serious events (black swans). We lean toward decisions that are beneficial or efficient in the short term, as long as the consequences are sufficiently long term. We underestimate the risks for things we can control (like driving a car), but over estimate the things we can’t control (like being in a plane crash).
This is not just a fact for security related decisions. We are bad at any risk-related decision – health, personal safety, financial planning and so on. Consider the poor smoker – neither gruesome images of cancer victims nor graphic warning labels prevent them from opening those packs and enjoying a drag from their next smoke … Only when a health crisis is upon us, do most of us modify our behaviors.
For SCADA and ICS security the story is the same. In the battle between making a task easier and making a task more secure, nine times out of ten, security is going to lose.
Of course, safety and security do triumph sometimes. Smoking rates are falling, workers in factories are more safety aware and driving deaths are declining (at least in the developed world).
Typically these wins come from one of three causes:
1. Sustained educational programs.
2. Enforced management of behaviors.
3. Simplified risk reduction technologies.
Consider driving deaths due to car accidents. The combination of massive educational programs on the risks of driving without a seat belt, laws requiring the wearing of seat belts, and the introduction of improved safety technology (such as antilock brakes and air bags) in automobiles all drove the death rate downward. All three have been critical legs to the solution. All have been expensive and slow to see significant results. But they do get results.
ICS and SCADA security needs to take a page from the lesson book of safety, especially industrial process safety. Significant progress has been made in this area over the past two decades:
Years of repeated safety education programs have slowly made safety top of mind for anyone entering an industrial site.
Well-designed standards like IEC-61805 (Functional safety — Electrical/electronic/programmable electronic safety-related systems) and IEC-61511 (Functional safety — Safety instrumented systems for the process industry sector) have led to well-designed safety strategies.
Significant improvement in the technologies and ease of use for safety integrated systems (SIS) has made deploying a safe process an economically viable reality.
All three have been critical to achieving safer plants and factories.
We are not going to be successful at making our factories and infrastructure more secure unless we embrace education, standards and technology as the three legs of the solution. Furthermore, each leg needs to be well-designed. Education that is sporadic, poor regulations that reward compliance rather than results, or technology that is complex and cumbersome will doom the quest for better security.
Regarding technology, the battle between security and efficiency has to end. These two characteristics need to become one, that is, the cyber security solution itself must help the plant become more efficient. The technology should allow the business and its engineers to achieve their goals.
Robust yet simple and easy to implement cyber security technology, sustained education and well thought out standards are all required to end the battle between security and efficiency – and truly protect our plants and critical infrastructure.
Eric Byres is chief technology officer at Byres Security. Click here to read the full version of the Practical SCADA Security blog.
Thursday, September 15, 2011 @ 05:09 PM gHale
Editor’s Note: This is an excerpt from Eric Byres’ blog at Tofino Security.
By Eric Byres
A few weeks ago, I received an email from a user asking about antivirus protection for SCADA systems. Antivirus is an essential tool for ICS and SCADA systems. This is what he wrote:
‘My security supplier tells me that attacks from Stuxnet (and next-Stuxnet like worms) can be avoided by protecting WinCC computers using an antivirus product. This will make the PLC perfectly safe, they tell me.’
If any security expert claims systems can be secured by just using antivirus products on the Windows computers in a control system, they are crazy, irresponsible or both. Antivirus (AV) technology helps protect the plant floor, but it is not enough on its own.
For the most part, AV software only works if you have a signature, which is great for dealing with well known common malware like Conficker. Unfortunately, there is no signature for a worm using a zero-day vulnerability. Stuxnet proved that – it was in the wild for a year before there were any signatures available. Antivirus software did not spot the worm for that year.
But Stuxnet is far from the only example. Far less sophisticated attacks that completely bypass the AV software appear every week.
No responsible IT group would think of only using AV technology and not bother with the firewalls in their network. Even a receptionist’s computer has both antivirus AND a personal firewall operating. This is the concept of defense-in-depth – no single solution can provide complete protection.
The typical PLC or DCS is a far more important asset than a receptionist’s computer. It is also a much easier target for attack. 99.99% of the control devices and protocols used today offer no robust authentication, integrity or confidentiality capabilities. They can be completely controlled by any individual or worm that gets a foothold on the network.
Nor can PLCs and DCSs be easily patched or have security features added to them, even when security vulnerabilities are discovered. For example, the Siemens S7-300 PLC vulnerabilities revealed 6 weeks ago by Dillon Beresford at Black Hat 2011 are still not patched. This leaves millions of legacy control systems open to attack from even an inexperienced hacker.
Of course, the ICS and SCADA user is limited in what is currently available to defend systems. For example, at this time PLCs and DCS CPUs can’t have antivirus software installed directly and none have built-in firewalls. But DCS vendors like Honeywell, Emerson and Invensys do supply firewalls to be installed directly in front of critical controllers. In effect, these are acting like personal firewalls for PLCs and DCS devices.
On Windows computers, antivirus technology needs to be supplemented with white listing technology and a good patching strategy. Segregating groups of PCs into controlled security zones also really helps.
The IEC62443 and ANSI / ISA99 ICS security standards are very clear on this topic. So are the IT standards, like ISO 27001. A defense-in-depth solution is a standards requirement.
The bottom line is that you need to deploy a variety of technologies and procedures if you want a secure control system.
Eric Byres is chief technology officer at Byres Security. Click here to read the full version of his blog.
Thursday, August 11, 2011 @ 05:08 PM gHale
Editor’s Note: This is part I of a two-part series on how to get started toward a more secure SCADA security package. For a full account of the story, click on Eric Byres blog.
By Eric Byres
The furor over the Siemens vulnerabilities and the fear that Son-of-Stuxnet could be around the corner has raised awareness for end users to take cyber security seriously.
If you are a process control engineer, an IT professional in a company with an automation division, or a business manager responsible for safety or security, you may be wondering how your organization can get moving on more robust cyber security practices. This is where you can get started.
Step 1 in the process is to get a security risk assessment done. The ISA99.02.01 and IEC62443 cyber security standards state your first step should be a Security Risk Assessment. Unless you know the risks you are trying to mitigate, you are just throwing your money away by rushing to solutions.
Unfortunately, I see many companies do exactly that. A salesperson says “buy my security technology and all will be secure” and companies believe him or her. They throw money at a solution for what might be a minor risk, leaving far more serious risks unaddressed.
Now, my company is a vendor of security technology and obviously we don’t like to turn down sales. But, as a responsible professional in your organization, you should be advocating for taking a step back and doing risk assessment work first.
Companies like exida do great work in this area and have sophisticated risk analysis tools and services available. Your investment in a Security Risk Assessment will provide a payback in terms of avoiding errors, highlighting priorities and providing a framework that facilitates discussions between groups.
The second step is to learn industrial cyber security fundamentals. At the same time the Security Risk Assessment is in process, it is a good idea to learn about industrial cyber security fundamentals.
A good place to start is the ANSI/ISA-99 Standards which address the subject of cyber security for industrial automation and control systems. The standards describe the basic concepts and models related to cyber security, as well as the elements contained in a cyber security management system for use in the industrial automation and control systems environment. They also provide guidance on how to meet the requirements described for each element.
The ANSI/ISA99 standards provide the base documents for the ISO/IEC standards in industrial control security, known as IEC-62443. Over the next few years, these standards will become the core standards for SCADA and process control security worldwide.
Visit the ANSI ISA-99 Standards section for more information.
The third step is understanding the unique requirements of ICS and SCADA cyber security. Another part of your education process might be to work with your IT group to inform them why ICS and SCADA security approaches are different from traditional IT security approaches. A ton of information is out there, but a brief synopsis of key points:
• Plant downtime has to be strictly avoided unless scheduled. Thus, technologies that require frequent rebooting of systems are not suitable.
• Industrial cyber security devices, such as firewall appliances, often need to be industrially hardened. That is, be certified to work in extreme operating conditions.
• Plant systems are made by different vendors than typical IT vendors. ICS and SCADA cyber security technologies should be certified and approved by industrial automation vendors and standards groups.
• Ease of configuration and management of technologies is important as configuration errors can negate the protective value of a technology. Industrial cyber security products are often managed by controls engineers who are not firewall specialists. Thus, technology solutions need to be suitable for the skills of the people who operate and manage them.
• Depending on the vendor equipment and networking technologies being used in the plant, cyber security products might need to be effective in securing industrial protocols that do not exist in the enterprise world. Examples are the Modbus TCP and OPC Classic protocols.
• More and more industries are moving toward cyber security regulation. A current example is NERC CIP in the power industry. Thus solutions are needed that meet and exceed relevant industry standards.
• A focused and ongoing effort for cyber security is “normal” for business and enterprise systems. Such effort is “new and unusual” for automation systems. Recognition of the different “state of nation” by the people responsible for the different systems can go a long way toward constructive teamwork.
Now, I know getting the automation side and the IT folks “playing together nicely” is a bit like the quest for the Holy Grail, but the fact is cooperation is necessary. If you can lead or facilitate such cooperation, then you will be a “part of the solution” rather than “part of the problem”.
Next: Part 2 discusses the remaining steps to making your facility cyber secure. Click here to read a full report. Eric Byres is chief technology officer at Byres Security.