Posts Tagged ‘SCADA’
Monday, June 1, 2015 @ 09:06 AM gHale
What Leaders Need to Know and Ask to Ensure a Strong Security Profile
By Marc Ayala and Jeff Jensen
Among phrases sure to catch the attention of most all oil and gas executives: Enhanced asset utilization, production optimization, accelerated resource recovery and capital efficiency. Keep these moving in the right direction and greater profitability and market capitalization will surely grow. But one phrase that might escape their concern could endanger any initiative: Network security.
In fact, executives could be doing a grave disservice to their shareholders and their own fortunes if they choose to ignore this threat or to delegate their understanding of how it can undermine the safety of people, production and property at the core of a thriving oil and gas enterprise. What they need is the knowledge to evaluate the nature of this risk and to ask informed questions about their companies’ defenses against it.
Oil and gas industry executives must stay informed of cyber security threats for two reasons: The energy sector is by far hackers’ top target and a cyber attack on their own facilities can potentially have serious impacts on operations and profitability as well as grave consequences for the life safety of personnel and nearby communities.
How important is network security? Consider this: Of the top 16 security targets designated as critical by the U.S. Department of Homeland Security (DHS), cyber attacks on the energy sector in 2013 were 59 percent of 256 total attacks deemed serious enough for its Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) to investigate. That was three times the number of attacks on critical manufacturing facilities, the runner-up, and 30 times the number of attacks on government facilities.
And how frequent are those attacks? With hackers automating their network assaults, one can occur every few minutes until a penetration occurs. During one session on network security led by a Siemens expert, he prefaced his presentation by opening a new, working web server connected to the Internet with its Modbus TCP/IP port 502 exposed. At the end of his remarks, he checked the web server’s security monitoring software and found 35 attacks had occurred from all over the world – all in just one hour.
OT vs. IT Security
IT professionals have plenty to worry about in defending against cyber attacks on their companies’ enterprise networks. These are what connect people with each other, via email, web collaboration tools and even voice communications, and also with information, via various company databases, customer relationship management (CRM) tools and so forth. After all, malware, data theft and corrupted data or devices can disrupt user productivity and even a company’s transactional capabilities.
But in that environment, no one ever suffers an injury or worse.
This is one of the biggest differences between enterprise network security and industrial network security. If a hacker, whether a deliberate saboteur or a teenage malcontent, penetrates an industrial network and disrupts critical processes or controls, especially automated life safety protections, someone could get seriously or even mortally hurt. That’s why DHS set up ICS-CERT to reduce risks associated with control systems-related incidents and mitigation measures.
Industrial Network Realities
Aside from the critical life-safety security distinction of industrial networks, they differ from non-industrial enterprise networks. First, industrial control systems (ICSs), which include supervisory control and data acquisition (SCADA) systems, are by definition connected to networks. These ICS and SCADA networks are often linked to enterprise networks, which have external-facing vulnerabilities that can open doors for hackers. Wireless SCADA systems, often operating from remote locations using public IP addresses, are also vulnerable to attack, accessible via their wireless media, including cellular, 900MHz radio, satellite and microwave.
Industrial networks must often operate 24×7, in real or near-real time and require 99.9 percent uptime or better (99.99 or 99.999 percent in the case of public communication networks). In contrast, enterprise IT networks typically must operate on a best-effort basis (so a break in one part of the network forces routers to send data packets down alternate paths) and be available during “business hours.” Point is, the disruption risks of a security breach in an ICS or SCADA network can be much greater than for an enterprise IT network.
In the past 20 years, industrial automation and control systems have become more vulnerable to cyber security intrusions, primary among them are:
• The increasing mobility of workers, which has created greater demands for 24×7 remote network access for engineering, operations and technical support personnel, sometimes leading to less secure network connections and security practices.
• Growing use and integration of commercial and open source technologies, such as Windows and Linux operating systems, SQL databases and Ethernet protocols, all of which a hacker can exploit by opening back doors for the same malware that can infect enterprise IT systems.
• Proliferation of “how-to” documentation and actual code on the Internet, which has lowered the bar for the technical competencies needed to hack industrial control systems.
• Integration of a company’s legacy plant systems with its enterprise systems by interconnecting industrial and corporate networks – and external third parties via the public Internet. Not only does external connectivity create vulnerabilities, but the integration also introduces ambiguity within companies as to which group – enterprise IT or process engineering – owns responsibility for overall cyber security.
Another set of security issues with industrial networks involves their evolution from early patchworks of electrical relays or antiquated microprocessor controllers and manually monitored indicator lights, trips and breakers. While those legacy systems might work well enough to operate relatively simple processes even today, they likely lack proper security controls. Nonetheless, they most likely end up connected to modern distributed control systems (DCSs) that feature the latest programmable logic controllers (PLCs), which are micro-computers using Windows or Linux which connect over industrial Ethernet to human-machine interfaces (HMIs). In turn, these HMIs are often accessible anywhere in the world via PCs or touchscreen tablets and smartphones – by legitimate DCS operators or by hackers exploiting the vulnerabilities in the connections between old and new systems.
With modern ICS, SCADA and DCS networks, infiltrations can occur from any of three sources:
1. Top-down from the corporate and data zones (Zones 4, 3 and 2)
2. Bottom-up from the field and safety/control zones (Zones 0 and 1); and
3. “Sideways” from external sources, either via the Internet, remote operations and facilities or remote
Lower Security Risks
Companies can find plenty of information to help guide their efforts to harden and secure their industrial control systems. Three internationally recognized ICS security standards, which can provide excellent starting points and guidance, are IEC 62443 / ISA99, NIST 800-82, and NERC-CIP.
These standards boil down to three steps: A current state assessment; hardening the environment, physical and logical; and ongoing vigilance.
They incorporate what’s known in security as the “defense-in-depth” model. This involves dividing a security deployment strategy into layers, with the most critical systems protected by multiple levels of security.
Every security risk mitigation effort for an industrial control system must start by evaluating the current state of its security by conducting an assessment. Here are some questions to consider:
Does a network’s borders correspond to its physical borders? They should. For example, if the user locked down the SCADA server and its software in an effort to prevent tampering with its configurations and data, is the server itself securely located to prevent unauthorized access to its network ports, removable media drives, keyboard and mouse?
Where are the network’s security zones and conduits? An industrial control system should have distinct functional zones that separate the field device control layer from the SCADA remote monitoring layer. In turn, these should end up separated from the DCS control layer – and more importantly, separated from any layer of safety-critical systems. Finally, the DCS and safety-critical system layers must end up separated from the enterprise IT layer. All those layers should communicate with each other only via carefully prescribed and secure conduit connections. And all those layers need to be separate from all external connections, each of which should also end up carefully prescribed and secured.
What and where is each connection within the industrial control network? This step helps identify what’s known as the network attack interface. Look for internal local area network (LAN) connections and wide area network (WAN) connections; remote connections with distant sensors and operating facilities; internal wireless connections, including Internet connections; modem or dial-up connections (yes, they do still exist); and external connections to third-parties, such as business partners, vendors and regulatory agencies. All connections should end up catalogued in detail and their current security measures noted, especially their firewall protection and update status.
What devices and software applications have connections, and what are their functions? This step helps identify what’s known as the software attack interface. Similar to the step above, all hardware devices – HMIs, PCs, servers, wireless access points, phones, even printers and video surveillance cameras – must end up catalogued along with all their operating system versions, software applications and the port numbers that each device uses to communicate. All current security measures should end up noted as well as their status regarding updates and patches.
Who is in charge of securing the industrial control network? For quite a few companies this might not be clear – yet it’s critically important. ICS, SCADA, DCS and safety systems typically evolved with industrial and process engineering teams in charge. During that time frame, enterprise IT teams had their hands full with rationalizing the corporate IT landscape. That left a large gray area of unclear responsibilities and sometimes adversarial relationships between the two groups. It can be a classic human story of in-fighting going on while the barbarians are tearing down the city gates. Executives – especially CEOs, CIOs and CISOs (chief information security officers) – need to recognize this phenomenon and put one qualified company person or team in charge of securing the industrial control system, in concert with enterprise IT and plant or production management. This person or individuals should have clear cyber security roles, responsibilities and authority to formulate and enforce well-defined security governance policies for managers, system administrators and end-users.
How vulnerable are the network and software attack fabrics? After identifying all the elements subject to cyber attack, the next step is to conduct penetration testing, to determine each one’s vulnerability. This can be a time-consuming, tedious task for large systems comprising hundreds of connections and components or more, but it’s necessary to fully assess the strengths and weaknesses of ICS, SCADA, DCS and safety networks, which are only as strong as their weakest component.
Due to the nature of these critical, real-time production systems, it’s vitally important that any penetration testing occur in a lab environment and not on the production system itself. With extreme care, caution and coordination, production, operations and process safety management will need to conduct a risk analysis and develop contingency plans – with executive management sign-off – before doing any penetrating testing or modification of a live control system. Failure to do so could have grave consequences not only for the personnel and property of a plant or production site, but also for the people and property in surrounding communities. This is why any third-parties selected to help with ISC, SCADA, DCS and safety system security testing or modification must be exceptionally well qualified and experienced in the engineering and workings of your system(s).
Hardening the Environment
A thorough assessment will reveal all existing and potential security holes and everything that needs strengthening. In effect, the list of all a system’s security shortcomings will become its punch list for action. Depending on how long that list is, levels of prioritization can come into play to close the worst vulnerabilities as soon as possible.
Assigning Security Access Levels (SALs) to each element can help with prioritization. Next steps in this stage would include:
Remove, disable or disconnect anything not needed. An assessment will probably uncover elements never needed but ended up installed as part of bigger installation or became unnecessary over time. If you find any unnecessary connections, disconnect them. If any unnecessary software applications or default network services end up discovered, remove or disable them.
Establish a security strategy based on a layered “defense-in-depth” model. After eliminating unnecessary connections, and software, what’s left needs protection. Ensure physical and logical security coincide, with strict access privileges for all users, providing access only to what they need to do their jobs. Logs should be kept for all accesses and video surveillance placed on the locked-down physical confines of network elements – HMIs, servers, routers and switches. All firewalls should be up-to-date. Full security features should be turned on in all hardware devices, operating systems, software and hardware devices.
Document, document, document. The catalog of a system’s network and software attack surfaces should be the start of a full documentation of its security. This should include “as-built” system architecture diagrams showing all elements, their locations, their functions, their governance and their connections with other elements.
Add to that written policies and procedures for: establishing, updating and terminating user accounts; upgrade and patch management policies, procedures and assigned responsibilities for all firewalls, devices and software applications; and scope, frequency and procedures for conducting security audits and penetration testing. All this documentation itself should have version and access controls, plus always be backed up to an offsite location, so it’s available by alternative means if the system goes down due to a cyber attack or some unrelated disaster.
Communicate, communicate, communicate. During the hardening stage, many employees and other stakeholders will become aware of what’s going on, so it’s important to communicate with them the reasons for doing so, let them know who is in charge of the effort, advise them of any changes in their day-to-day work as a result, and set proper expectations for their roles in supporting the effort.
After hardening a company’s ICS, SCADA, DCS and safety networks, the heightened protection will begin degrading over time without ongoing efforts to maintain security levels. To watch for and respond to apparent and actual attacks, and to conduct periodic security audits and tests, a user should:
Establish response teams to identify and evaluate potential attack scenarios. The designated person or team in charge of industrial network security should identify potential attack scenarios and then convene the core stakeholders into a rapid response team. Each team member needs to imagine, describe and document the potential impact on his or her function should a security attack succeed, as well as what mitigation measures to take. Roles and responsibilities need to be assigned and contact information shared in a central place. The team should meet at least annually to reacquaint themselves with each other and with their risk and mitigation scenarios. It’s a good idea to conduct exercises that assume the worst-case scenario has occurred, which can provide the team with practice.
Conduct periodic audits and penetration testing. The frequency of audits and penetration testing depends on how critical an industrial control system is to a company’s functioning or the life-safety of personnel and surrounding communities. Obviously a nuclear plant would require much more frequent audits and systems testing than a dairy products plant. Any industrial facility, however, should conduct an audit and systems testing no less frequently than once a year. Notably, audits often overlook evaluating the currency and relevancy of existing documentation. That’s why it’s important to review and update documentation. If production lines are frequently reconfigured, with consequent changes made to their control systems, then mini-audits should then end up conducted to avoid introducing any unintended system vulnerabilities.
The ultimate goal of securing industrial control systems and networks against cyber attacks is to ensure their reliable and safe operation.
Oil and gas industry executives can make tremendous progress in reaching this goal by initiating a thorough systems assessment and needed hardening, then putting in place a formal watchdog process governed by designated, well-qualified people with the knowledge and authority to create and enforce policies and procedures.
Doing so will cost money and time, but it will be one of the most important investments that oil and gas operators can make in the safety and well-being of their people, production and property.
Marc Ayala is the former senior technical advisor at system integrator, Cimation and Jeff Jensen is an application engineer at Siemens Industry, Inc.
Thursday, May 14, 2015 @ 04:05 PM gHale
By Heather MacKenzie
When it comes to securing ICS and SCADA networks, firewalls (also called security appliances) play an important role. That may be stating the obvious, but are you familiar with the essential concepts that distinguish the types of industrial firewalls on the market?
A switch with Access Control Lists provides a different type of security than a stateful firewall, which in turn offers different benefits than a Deep Packet Inspection (DPI) firewall.
These differences are critically important for industrial networks. Most of them use specialized communication protocols not designed with security in mind. Indeed, many of them were created to run equipment built before the Internet was born.
With the long life spans of industrial equipment (20 years and more) it means that today’s security technology needs to take into account the communication limitations of equipment built in another era. Even devices built not that long ago face limitations in terms of memory and CPU horsepower that seem unbelievable to anyone with a smart phone in their pocket today.
Let’s take a look then at the essential concepts you need to know in order to make informed choices for firewalls on your automation network.
To understand “stateful” and “DPI” it is first important to understand how the traditional IT firewall works.
A firewall is simply a device that monitors and controls traffic flowing within or between networks. It starts by capturing traffic passing through it and comparing that traffic to a predefined set of rules (called Access Control Lists or ACLs). Any messages that do not match the ACLs are then discarded.
The traditional IT firewall allows the ACLs to check three primary fields in a message:
• The IP address of the computer sending the message (AKA the source IP)
• The IP address of the computer receiving the message (AKA the destination IP)
• The upper layer protocol contained in the IP frame as defined in the field “TCP Destination Port Number”
The TCP Destination Port Number needs a bit more explanation. These ports are not physical ports like an Ethernet port, but instead are special numbers embedded in every TCP or UDP message to identify the application protocol carried in the message.
For example, Modbus/TCP uses port 502 and HTTP uses port 80. These numbers are registered under the Internet Assigned Numbers Authority (IANA) and rarely ever change.
So to put this all together, imagine you only want to allow web traffic (i.e. HTTP traffic) from a client at IP address 192.168.1.10 to a web server with an address of 192.168.1.20. Then you would write an ACL rule something like:
“Allow Src=192.168.1.10 Dst=192.168.1.20 Port=HTTP”
You would load this ACL in the firewall and as long as all three criteria were met, the message would be allowed through.
Or say you want to block all Modbus traffic from passing through the firewall. You would simply define a rule that blocks all packets containing 502 in the destination port field.
Seems simple, doesn’t it?
Stateful Way to Go
Let’s take a closer look at the ACL rule shown above. One aspect of it is the rule is applied to individual messages. However, just like communication between people, communication on a network rarely involves just a single message.
Instead, there is a constant exchange of packets (messages), where each is in some way dependent on previous packets. This understanding of the previous traffic is what we call “state.” State involves information such as which device started the session, who last sent a message, was the last message rejected because of errors and so on. Without this, communication quickly breaks down.
A “stateless” or “packet filter” appliance only analyzes each packet in isolation of other information relating to the communication session. It has a series of static rules and uses them to take action upon received packets on an individual basis.
The limitation of a firewall/security appliance that can only analyze this limited data is it is not possible to block “inbound” communication not the direct result of an “outbound” request. Because of this, hackers can get into the control system by changing their IP address to match that of an application server and using a common destination port number. This is known as “spoofing.”
A stateful firewall, on the other hand, looks at other parameters and keeps an internal record that tracks the details of the session state. This information makes it possible to analyze the reasonableness of each packet. Stateful inspection means that inbound traffic to the client device will only be allowed if it is in response to an outbound request.
Stateless firewalls allow denial-of-service attacks on PLCs because the flood of inbound requests that come with such attacks are not matched to outbound requests. Stateful firewalls, on the other hand, map each request and reply to a state. They then drop all data not adhering to the proper sequence of events.
With this information you won’t make the mistake of thinking that a layer 2 switch with ACL rules is a firewall. It is not. It will not block out-of-sequence packets, nor prevent denial-of-service attacks to a PLC.
Enter Deep Packet Inspection
Let’s go back to the example ACL. Besides state, another problem with its simple scheme is it is very black and white. Consider the Modbus/TCP protocol which uses port 502. With an ACL you either allow Modbus messages through or you block them. Fine-grained control of the protocol is impossible.
Thus if you allow data read messages, from an HMI to a PLC, to pass through a traditional firewall you are also allowing programming messages to pass through. This is a serious security issue. If you do the reverse, and block all messages, then the messages necessary for running the control network are blocked.
Clearly the firewall needs to dig deeper into the protocols to understand exactly what the protocol is being used for. And that is exactly what Deep Packet Inspection does. After the traditional firewall rules are applied, the firewall inspects the content of the contained messages and applies more detailed rules.
For example, a Modbus DPI firewall determines if the Modbus message is a read or a write message and then drops all write messages. Good DPI firewalls can also “sanity check” traffic for strangely formatted messages or unusual behaviors (such as 10,000 reply messages in response to a single request message). These sorts of abnormal messages can indicate traffic created by a hacker trying to crash a PLC and need to be blocked.
Be aware the Deep Packet Inspection is sometimes known by other terms, such as content inspection or protocol whitelisting. It is not a widely available capability.
SCADA security expert Eric Byres believes true DPI (i.e., inspection and filtering of the protocol fields at all layers) is critical if industry is going to take control of its ICS and SCADA networks. Recent high profile malware, like Dragonfly’s Havex, took advantage of a lack of content inspection to spread within its targeted networks.
By understanding the concepts of “stateful” and “Deep Packet Inspection” you can assess the importance of these capabilities for mitigation against a specific risk. If protecting key PLCs on the plant floor is important, a DPI firewall might be the way to go.
Heather MacKenzie is with Tofino Security, a Belden company. Click here to view Heather’s blog.
Wednesday, September 3, 2014 @ 05:09 PM gHale
By Gregory Hale
It wasn’t too long ago when industrial control systems (ICS) and supervisory control and data acquisition (SCADA) systems were in the scope of the bad guys. These systems, sometimes close to 30 years old and considered easy pickings, were suffering hacks, or threatened hacks, on a fairly regular basis.
The thing is, they still are.
When you looked at the headlines a year or two ago, they talked about Stuxnet, Night Dragon, Shamoon, Saudi Aramco, RasGas, ExxonMobil, Shell, just to name a few. Now the news still talks about hack attacks, but they are of a different kind. This time the retail sector is in the crosshairs. Just look at Target, Neiman Marcus, and most recently Home Depot.
Home Depot is the latest retailer to suffer a major credit card data breach that may have started in late April or early May.
The Atlanta-based home improvement retailer is now working with banks and law enforcement to investigate “unusual activity” that would point to a hack.
It is easy to say this is just the retail sector and it doesn’t affect manufacturing, but that is not true. Just how should the manufacturing industry react to the point of sale (PoS) attacks going on in the retail sector?
The main thing is, security professionals in the industry should remain vigilant and keep their mind in the game and know an attack is just a click away.
“I have been watching the PoS issues, including several notifications from the NCCIC (National Cybersecurity and Communications Integration Center),” said Joel Langill, ICS cyber security consultant and founder of SCADAhacker.com. “I believe that this is ‘the retail industry’s Stuxnet.’ The recent Target and Neiman Marcus breach put these systems on the front page of the mainstream media, so all of those researchers shifted focus and are now having fun finding problems throughout these systems.”
Researchers, however are finding similarities between retail systems and ICS/SCADA systems.
“I think there is a lot of comparisons between the attacks hitting the PoS terminals and the manufacturing world,” said Graham Speake, vice president and chief product architect at NexDefense, Inc. “While the attackers are obviously after credit card information in these attacks, it does show the sophistication of the attackers. Like an industrial control system, the PoS network is normally a separate network with links to the main business network. The lack of attention to the PoS network in terms of what communications are occurring and egress monitoring, a fairly static network with real time devices on it and devices that are not updated/upgraded frequently are also characteristics of industrial control networks.”
In the dynamic and evolving security environment, bad guys continue to find new ways to get into systems, but these attackers are not moving from industry to industry like a bunch of 7-year-olds chasing a ball while playing a soccer game. In most cases, these are professional attackers on a very specific mission going after their target.
“I don’t believe that it is the same set of threat actors, so manufacturing should not lower their guard thinking that the bad guys have shifted targets — it is a new set of bad guys with the same ones still targeting manufacturing,” Langill said. “Havex (Dragonfly, Energetic Bear, Crouching Yeti) should have shown this, and should have opened everyone’s eyes to the new tactics of exploiting ‘trusted relationships.’”
“Owners of PoS networks had put in defenses to protect that data, even regulated with PCI standards, but the lack of visibility allowed multiple breaches (even after the Target warnings),” Speake said. “Attackers could turn their attention to ICS networks and, using similar attack tools and methods, gain access to these networks, not for credit card scraping but for extortion or disruption.”
Friday, August 22, 2014 @ 01:08 PM gHale
The move to using open standards such as Ethernet, TCP/IP, and web technologies in supervisory control and data acquisition (SCADA) and process control networks has begun to expose these systems to the same cyberattacks that have wreaked so much havoc on corporate information systems.
That is why aeSolutions is offering a course that provides a detailed look at how the ANSI/ISA99 standards can help protect your critical control systems. It also explores the procedural and technical differences between the security for traditional IT environments and those solutions appropriate for SCADA or plant floor environments. Cost of the course is $1,510.
This course is required for the ISA99/IEC 62443 Cybersecurity Fundamentals Specialist Certificate Program. You can register for the exam through ISA after completing the course.
Those who successfully complete this course and pass the exam receive the designation of ISA99/IEC 62443 Cybersecurity Fundamentals Specialist.
The course is Wednesday, September 17, at 8 a.m. to Thursday, September 18, at 4 p.m. at the JL Towers, 3800 Centerpoint Drive, Suite 620, Anchorage, AK 99503.
The course will allow you to :
• Discuss the principles behind creating an effective long term program security Interpret the ANSI/ISA99 industrial security guidelines and apply them to your operation
• Define the basics of risk and vulnerability analysis methodologies
• Describe the principles of security policy development
• Explain the concepts of defense in depth and zone/conduit models of security
• Analyze the current trends in industrial security incidents and methods hackers use to attack a system
• Define the principles behind the key risk mitigation techniques, including anti-virus and patch management, firewalls, and virtual private networks
You will cover:
• Understanding the Current Industrial Security Environment: What is Electronic Security for Industrial Automation and Control Systems? | How IT and the Plant Floor are Different and How They are the Same
• How Cyberattacks Happen: Understanding the Threat Sources | The Steps to Successful Cyberattacks
• Creating A Security Program: Critical Factors for Success/Understanding the ANSI/ISA-62443-2-1 (ANSI/ISA-99.02.01-2009)- Security for Industrial Automation and Control Systems: Establishing an Industrial Automation and Control Systems Security Program
• Risk Analysis: Business Rationale | Risk Identification, Classification, and Assessment | The DNSAM Methodology
• Addressing Risk with Security Policy, Organization, and Awareness: CSMS Scope | Organizational Security | Staff Training and Security Awareness
• Addressing Risk with Selected Security Counter Measures: Personnel Security | Physical and Environmental Security | Network Segmentation | Access Control
• Addressing Risk with Implementation Measures: Risk Management and Implementation | System Development and Maintenance | Information and Document Management
• Monitoring and Improving the CSMS: Compliance and Review | Improve and Maintain the CSMS
• Develop a business case for industrial security
• Conduct security threat analysis Investigate scanning and protocol analysis tools
• Apply basic security analysis tools software
Includes ISA Standards:
ANSI/ISA-62443-1-1 (ANSI/ISA-99.00.01-2007) – Security for Industrial Automation and Control Systems Part 1: Terminology, Concepts & Models
ANSI/ISA-62443-2-1 (ANSI/ISA-99.02.01-2009) – Security for Industrial Automation and Control Systems: Establishing an Industrial Automation and Control Systems Security Program
ANSI/ISA-62443-3-3 – Security for industrial automation and control systems: System security requirements and security levels
For more information, contact Jodi Pietrowski at aeSolutions.
Tuesday, August 12, 2014 @ 01:08 PM gHale
The National Institute of Standards and Technology wants to create a test bed to examine industrial control systems for cyber security vulnerabilities.
Industrial control systems (ICS) or SCADA (Supervisory Control and Data Acquisition) systems operate critical infrastructure, such as dams, gas plants, petroleum refineries and chemical manufacturing plants.
Hackers can potentially wreak havoc with assaults on such systems. In late June, for example, a targeted malware attack on SCADA systems called Havex ended up discovered by the Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) at the Department of Homeland Security (DHS) that could have allowed intruders to take over Internet-connected systems.
NIST is trying to get ahead of attackers by developing a simulation system that emulates the operations of specific industrial situations.
The simulation rack will provide NIST’s researchers the opportunity to probe systems for flaws and examine the efficacy of certain network security approaches, including deep packet inspection of network traffic, encryption, user authentication, and security software like anti-virus protection.
In a request for information , NIST is soliciting feedback from vendors interested in designing and building simulation racks of SCADA systems for testing purposes.
Tuesday, June 24, 2014 @ 05:06 PM gHale
By Gregory Hale
You are under attack and you don’t even know it.
That was the subject of a demonstration and talk Tuesday entitled “ICS Security Today Awareness and Practice” at the 2014 Siemens Automation Summit.
“We are trying to protect people, production, property, environment and the economy,” said Marc Ayala, senior technical advisor at security provider Cimation. He talked about how many people that are qualified and actually know something about enterprise security and the number he came up with was 50,000 true experts. When it comes to Industrial Control System (ICS) or Supervisory Control and Data Acquisition (SCADA) security, Ayala said there were “500 people that know ICS security.”
The industries most likely targeted, Ayala said, were energy and transportation.
One of the first things a user needs to accomplish is to evaluate risk, said Eric Forner, ICS/SCADA security engineer at Cimation.
Threats are coming from hackers that could be conducting automated attacks, or from nation states that develop exploits and know how control systems work, Forner said. A third area is from internal attacks, “which is more of a threat than the other two.”
Another area that is a big attack area and has the potential to get bigger is social media attacks, Ayala said.
All you have to do is send a person a malicious email with an attachment from a person they may be familiar with and that person now becomes a victim.
“That is the pivot point where an attacker can then go in and start viewing the system,” Ayala said. “You have to be very careful with who you connect with.”
Keeping bad guys out of the system is vital as the demonstration by Forner proved.
In the demo, Forner was able to bypass a firewall and jump right into a system and take it over.
Most firewalls are usually in place because a standard has told people to put them in, but they end up having an “allow anything command,” Forner said.
That ends up being important as Forner was able to use various commands to work his way through a PLC without too much of a problem.
But the way in to any system is through IP addresses found on the Internet, the researchers said.
One of the problems, Forner said, was the industry’s reliance on incredibly old Modbus/TCP protocol.
Port 502 is the Modbus TCP port and it is one of the top ports under attack,” Ayala said.
In the demo, there was a level transmitter that would shut the system down when the fluid reached a certain level, but when they issued a few commands to get into the system, they essentially owned the process.
When that happened all indicators showed the operator the tank was not at an overflow level and is actually decreasing, but in reality the tank ended up overflowing. They were able to override the safety interlock and take down the process.
As an extra added bonus, after overflowing the tank, the researchers then took command of the HMI in the system and downloaded a game of solitaire.
Yes, this was a demo at a conference, but that could be a real life experience that could cause an incident.
“Cyber security in ICS/SCADA is a life safety issue and must be treated as such,” Ayala said. “Safety is everywhere and it is constant. With all our total interconnections, safety is all the time now.”
Wednesday, June 4, 2014 @ 07:06 PM gHale
By Gregory Hale
There are heavy challenges facing automation professionals in the years to come and cyber security ranks up there at the top.
“There are issues like skills availability, working in remote locations and cyber security,” said Vimal Kapur, the brand new president of Honeywell Process Solutions (HPS) during his keynote address Tuesday at the 2014 Honeywell Users Group in San Antonio, TX. “We can’t ignore (cyber security). It is an undesired event and we have to do something about it.”
Kapur, just named president of HPS in May, talked about trends and outlooks he sees in the industry. While newly named as president, Kapur has been with Honeywell for 25 years so he is very aware of industry nuances and trends.
One of the areas he wants to focus on collaborating to ensure global coverage as the world markets emerge from long standing recessions.
“China and the Americas continue to lead in capital spending, but Europe, Middle East and Asia (EMEA) and Asia Pacific are recovering,” he said.
Closer to home in North America, Kapur said natural gas is continuing its growth curve.
“The Americas oil and gas industries continue to dominate capital spending in the region, especially as they migrate to new natural gas sources,” said Kapur. “These changes have been having a profound impact for the past two or three years, and this trend is going to continue for several more years.”
He also pointed out how Honeywell will be able to leverage its capabilities in upstream oil and gas, midstream and downstream with new SCADA, RTU, DCS, safety, advanced and field instrumentation solutions.
Also understanding and designing the systems properly from the beginning is more vital now than it ever has been.
“Large capital expenditure projects are growing more complex, expensive and time-consuming. So instead of us coming in and adding automation and control at the end of a project before start-up, it’s becoming critical for us to execute automation and get it out of the critical path of these projects,” Kapur said.
Planning the project is one thing, but the next step is applying operational integrity and operational excellence.
“Being able to accomplish operational integrity means operating safely. Operational excellence means running a process more efficiently,” he said. “That all includes making people and assets safer, and running processes more reliably.”
One other trend Kapur discussed was cloud computing.
“Cloud computing in automation has huge potential,” Kapur said. “That is something that is happening now; not something that will happen in the future.”
Another trend is universality, Kapur said. By that he said there would be one universal device that handles multiple capabilities. A case in point is a smartphone that can handle computing, video, phone and general communications capabilities.
In the past one device could handle one function, but why not have one device that handles multiple functions.
He then translated that to the Honeywell environment where, in one case, he pointed to Universal IO which transformed from a single device to one that can handle multiple tasks.
Universal I/O and cloud computing capabilities form the core of the company’s Lean Execution of Automation Projects (LEAP) program for taking automation out of the critical path on customers’ projects.
The goal behind LEAP is to cut engineering time
- No repeat engineering
- Drives efficiency
- Lean execution
- Standardized processes and tools
Monday, April 28, 2014 @ 10:04 AM gHale
There is a directory traversal vulnerability affecting the InduSoft Web Studio application, according to a report on ICS-CERT.
Successful exploitation of this remotely exploitable vulnerability could allow remote execution of arbitrary code. This vulnerability ended up reported by the Zero Day Initiative (ZDI) who received the initial dispatch from security researcher John Leitch.
Web Studio Version 7.1 suffers from the issue.
Successful exploitation of the reported vulnerability could allow an attacker to read files outside the web root and possibly perform arbitrary code execution. These actions can result in adverse application conditions and ultimately impact the production environment on which the supervisory control and data acquisition (SCADA) system works.
InduSoft Web Studio is a collection of automation tools to develop human-machine interfaces, SCADA systems, and embedded instrumentation systems.
InduSoft Web Studio often ends up integrated as a third-party component in other vendors’ products. According to Austin, TX-based InduSoft, Web Studio sees uses across several sectors including commercial facilities, critical manufacturing, energy, food and agriculture, healthcare and public health, and water and wastewater systems.
The NTWebServer (test web server installed with InduSoft Web Studio) contains a flaw that enables a malicious user to read files outside the web root. This can end up exploited to read APP files that may contain application passwords. It may be possible to achieve remote code execution by exfiltrating credentials for Web Studio itself, then using them to remotely administer the targeted instance to deploy attacker controlled server-side code.
CVE-2014-0780 is the case number assigned to this vulnerability, which has a CVSS v2 base score of 7.5.
No known public exploits specifically target this vulnerability. However, an attacker with a low skill would be able to exploit this vulnerability.
InduSoft did not intend for this web server to see action in real applications. It was a demonstration/training software (as stated in user manuals). They have created a mitigation for this vulnerability in InduSoft Web Studio v7.1+Service Pack 2+ Patch 4. Users may obtain this patch at the following location (you must log into your InduSoft account).
For more information, you can email InduSoft technical support.