Wednesday, March 25, 2015

Baseline – Not the Dubstep You’re Looking For…



Disclaimer: I have no real world ISC/SCADA system or security experience, I’m just a guy that takes in information and thinks about a better ways to do things.

We've all heard about taking a “baseline” of your network environment so you have some way to gauge and detect any anomalous behavior on your systems to, hopefully, help catch any type of malicious activity before it gets out of control, or in the very least, have a good idea of where to start when performing IR if there is a network breach. And, like most of us that already work in well-established networks, we know how difficult and time consuming a task this would be. But in a well-designed ICS production environment, this might be a bit less traumatic experience than one might think.

First of all, if a production ICS network is properly segregated (as it should be) the traffic flowing over the network is really not that complex because the protocols used aren't that complex. Modbus, DNP3 and most of the other ICS protocols out there operate on very small frame sizes and command lists compared to other network protocols, so while there may be a lot of traffic flowing back and forth between a controller and a device, the commands being sent are known and can generally be predicated based on their configuration and what action the system is designed to perform. In other words, you’re not going to see your Smart-Meter or valve controller performing Google searches or streaming YouTube videos unless something has gone terribly wrong! (Yes, that was a terribly joke).

This being the case, an ICS production environment is ripe for baselining even if it’s already up and running (which most are). So this is the first step in beginning to secure an ICS production network and there really isn't any reason why this should not be happening right now in all major and even minor critical infrastructure environments. We all know this isn't the case, but it should be the case none the less. If critical infrastructure company can get over this first, daunting hurdle, keeping this baseline up to date can actually become relatively easy in the future. Let me explain…

Once the major baseline is established and the network engineers know what normal traffic looks like and what might be abnormal, it becomes much easier to tune inline controls to recognize and flag real warning signs that something maybe amiss in their systems. And at this point, maintaining this baseline can become very easy if the proper deployment controls are put into place when the engineers either have to replace a controller or deploy a new system.

I am sure (or hopeful, however you want to look at it) that when a new ICS controller is replaced due to failure or through a system upgrade, or anytime a new piece of equipment is going to be introduced into the system, extensive testing occurs to make sure the new device is function properly before being deployed into the production environment. This is only logical and makes perfect sense, but this is also the time to not only make sure the operation and control of the system is well established, but also the perfect time to baseline the new system’s network traffic as it’s being run through all normal  conditional testing. By imposing this new deployment protocol you can capture all of the communications of the system in its purest form and have a perfect baseline of what to expect its typical traffic to look like; from normal operational commands, to fault conditions, to extreme fail-safe actuation or any anomalous traffic that might indicate that someone is trying or has breached the network.

This can be helpful in any kind of network, but ICS/SCADA networks can greatly leverage this kind of process with more precision than any other network environment I can imagine, to great benefit not only to the company, but to the environment and to the consumers of the products produced by critical infrastructure companies.

</my_two_cents>

Discuss…


Saturday, March 14, 2015

Of Cats and Security



So I was listening to Paul’s Security Weekly (@securityweekly) podcast last Thursday night when one of their guests, one Michael Santarcangelo (@catalyst), used the phrase, “Risk Catnip”. I almost fell on the floor laughing, as he weaved that phrase into his thought without any hesitation. It surprised everyone on the show and we all got a great laugh out of it.

The next day, since I loved that phrase so much, I decided to re-Tweet his phrase along with some other phrases ending with “catnip”. One of those phrases was “Threat Catnip”. A follower of mine by the name of @PeterGanzevles (Hacktic) replied with about the best response I believe I ever heard, he coined the term “Threatnip”, which got me thinking… (I know, I know, keep your jokes to yourself).


 Embedded image permalink


“Threatnip”, as it turns out, is actually a real thing and it’s used all the time as a lure to get executives to buy into Threat Intelligence products like reports, dashboards, blinky boxes and consultations. And much like catnip, once the prey has pounced on the lure and plays around a bit, the thrill is gone along with a considerable amount of money that could have been put to better use. Now I’m not saying that there is no use for Threat Intelligence, in fact, quite the opposite is true, but there has to be more than just the “Threat” part, because, as “Intelligence” implies, it must serve as a function of a continuous cycle of security posture improvement.

The morale of this short story is this: don’t be a “Threatnip” peddler, be a total solutions provider!


Here are some people that are much wiser than I on this subject:

Edward McCabe (@edwardmccabe):

John Berger

Rafal Los (@Wh1t3Rabbit)