Hey folks, I’m back with my second installment on protecting the un-protectable:
Last week we discussed the SCADA environment and some of the unique business and technology challenges we face when trying to secure it both from availability and cyber security hazards. The questions you are all asking yourself now are “how did we get here?” “Why would anyone build anything this insecure?” The answer is so simple … we never anticipated these networks would communicate with the outside world. PCD and SCADA environments were meant to be “closed loop” and therefore air-gapped (If you’re air gapped, you don’t need security, right? Ask Iran about the Natanz nuclear facility). If you think about it, that was a perfectly good assumption. Why would factory machinery ever need to access the internet, or a power plant, or an oil rig… I could go on and on. However, this paradigm changed for two reasons.
1) Manufacturers wanted data. They wanted this data so they could analyze why two of the exact same machines could have different output, or to see predictive failures.
2) Later on, we wanted to change the system environments to compensate for the parameters we had received from the data to optimize performance and/or to stop failures before they happened (an example of this would be varying the turbine speed at a power plant during warm and cold months in order to optimize power output. The ability to do this manually saves thousands of dollars each year and allows manufacturers to scale their support exponentially).
So how do we protect this environment that can’t use most traditional security methods, and in most cases has several unpatched original operating systems? Well the answer is, do it methodically and carefully. First, let us lay out the three areas to protect:
Availability of access into the environment (this has become mission critical think about nuclear power plants whose cooling system goes into pre failure and requires the manufacturer experts to be able to act remotely immediately). Next generation authentication. We need to ensure that the people approved to access the environment are in fact the right people, at the right time, from the right place (no session hijacking). Availability and reliability of systems to design the network properly using accepted standards, while taking the business requirements into account (in some cases of extreme availability and reliability, keep the design as simple as possible, use the right components, and add best practices and standards). Securing the environment from the outside, and at a component level, securing components from each other.Today we will cover availability of access, or in other words, how best to protect these environments from DoS and DDoS attacks (Denial of Service). Next time, we will cover next generation authentication and system availability and reliability.
[You might also like: SCADA: Mission critical, highly vulnerable, almost un-protectable.]Availability is becoming increasingly top of mind partly due to the ever-increasing number of high profile DDoS cases. SCADA environments are particularly susceptible because they are very sensitive to latency and not built to handle high numbers of requests. On top of this, oftentimes the SCADA network is not protected under the corporate DDoS security design (yes the Operations teams do not want to ride the same network as the corporate network). Standard volumetric DDoS protection will not meet the basic needs. Organizations need to take this threat seriously and the best choice is a hybrid approach.
Yes, you have to have a service for volumetric protection, but because the introduction of simple latency can cause significant disruptions, an on premise device is also a requirement. This type of hybrid design gives maximum protection from both Layer 7 and volumetric attacks. In recent years, many of these SCADA equipment providers have added SSL encryption to encapsulate their communication protocol. In order to ensure we don’t have encrypted attacks that we can’t see, it is also important to add a device that decrypts and re-encrypts the SSL to allow for inspection (this needs to be done only one time as opposed to doing it in each and every inspection layer in order to limit latency). In other words, decrypt and send the packets through all the security measures, then re-encrypt and send it on.
On top of this, some SCADA environments are modernizing and becoming more “webified.” As this trend accelerates it becomes more important to consider web application vulnerabilities and bad coding a real threat. In order to counter this threat, we recommend a Web Application Firewall (WAF), but (and there is a big but) we can’t use the traditional inline WAF deployment as it adds too much latency even in transparent mode. We recommend looking for a WAF that can truly sit out on line. If it identifies a threat it can then send a message to the appropriate person and/or to an upstream device to enforce specific actions. This type of design will avoid latency and still ensure maximum protection.
Today there are several manufacturers/service providers that make DDoS solutions, web application firewalls and SSL decrypt/encrypt devices. However, there are very few that can offer a whole solution with a centralized management GU, enhanced scripting for automation, etc. In an environment where there is a limited IT skill set, where environments literally make money or cost lives, security, visibility, simplicity and ease of use are paramount. A single, integrated, well supported manufacturer with enterprise grade technology is a must.
That’s a wrap for availability of access. Next week, we will jump into next generation authentication.
Read “Keep It Simple; Make It Scalable: 6 Characteristics of the Futureproof Load Balancer” to learn more.
Download Now