3 Tough Questions with Chris Jager

Recently, I got to spend some time interviewing Chris Jager via email on industrial control systems security. He didn’t pull any punches and neither did I. Here, are 3 Tough Questions between myself (@lbhuston) and Chris.


A Short Biography of Chris Jager (@chrisjager): I have over 15 years of experience in Information Technology and have focused on the practical application of security principles throughout my career. Most recently, I was director of the NESCO Tactical Analysis Center at EnergySec; a non-profit organization formed to facilitate information sharing, situational awareness, and education outreach to the energy sector. I am active in a number of information security workgroups and have provided operational, architectural, and regulatory compliance guidance to large and small organizations in both the public and private sectors, focusing on the energy sector exclusively since 2006.


Brent: You have spent a lot of time working on Industrial Control Systems (ICS) in your career. During that time, you have been witness to the explosion of interest in IT security as a profession. Why should some of the younger folks thinking about information security as a career consider a focus on ICS and SCADA? Why should they care?

Mr. Jager: This is a fantastic question and, if I frame my response correctly, the answer will hopefully be self-evident to your readers.

ICS and SCADA are terms that are seldom understood and often misused by information security (infosec) publications. SCADA systems typically manage geographically disperse areas and often consist of numerous functionally disparate processes.

However, because of the immense variety of different processes that can be managed by industrial control systems, ICS has become somewhat of a catchall term – including SCADA systems. For example, you’ll often find electric power generation processes such as turbine control, burner management, vibration monitoring and more lumped into the mix. Each of these processes has discrete or locally distributed control and instrumentation systems, any of which can cause catastrophic safety, reliability, and financial issues if misused.

For me, the challenge of protecting these kinds of systems is far more interesting than making sure that little Bobby can’t drop the student records table in a classroom database. Much of the actual management technology is the same as what is used in general IT, but the application is very different. Things get a little more exotic (and arcane) when you go further down the stack into digital–to-analog conversion, but it’s not overly difficult for most folks to understand once exposed to it. The negative impacts of misuse aren’t limited to convenience and financial loss. Risk to life and limb is a very real possibility in many processes that are managed by industrial control system automation that is being run out of specification.

Typically, industrial control systems are deployed in step with the physical equipment they are designed to manage. The physical equipment is often orders of magnitude more expensive than the ICS components that ship with it and may be designed for lifespans measured in decades. In short, upgrades seldom occur as they need to be engineered and tested for functionality, safety, and a myriad of other issues pertaining to the existing physical equipment.

This has led to a situation where the groups that understand control systems and processes are naturally (and often generationally) gapped from those groups who understand the current threat and vulnerability landscapes. Consequently, there are currently very few individuals that understand industrial control system security as it relates to the changing threat picture. If the challenge of doing something very few dare to try doesn’t sound good on its own, this is the sound of opportunity knocking. Answer the door!

I’d like to make one last point on this question. Take a look around your house or apartment and count the number of internet-enabled devices you have. Most people these days have far fewer traditional computers than embedded systems – devices that aren’t user-serviceable without breaking a warranty or two. And the hacking skills necessary to modify such devices to fit use cases unintended by the manufacturers seem to come naturally to the younger folk of today. Those skills are also relatively portable to the ICS/SCADA world where embedded systems are the norm. Sure, some of the protocols and hardware packages are somewhat different, but they are all relatively simple compared to what folks are tinkering with at their coffee tables. We can always use more QA/breakers – particularly at key points in the supply chain where issues can be spotted and fixed before they become permanently vulnerable installations. Again I say, “knock knock”!

 

Brent: You talk a lot about how challenging ICS/SCADA security is. Do you think protecting ICS/SCADA systems in a meaningful way is an attainable goal? Assuming yes, do you think it could be done during what’s left of our careers? Why or Why not?

Mr. Jager: If I didn’t think it was an attainable goal, I’d not be doing the kind of work I’ve done over the past number of years. There are much easier ways to make a buck than to have people who are entrenched in the old way of doing things actively work to prevent you from even introducing discussions about change – let alone actually implementing it!

There is momentum in this area, but much work still needs to be done. Devices still ship from manufacturers with easily discerned hardcoded administration credentials, firmware updates are accepted without challenge and more. Once deployed in the field, user passwords seldom change, vulnerabilities discovered post-installation go unmitigated, and so on.

Because we have all this noise around basic security failures and their associated issues, we don’t yet know what constitutes “meaningful” or “attainable” when we speak of complex industrial control systems. A prime example here is that the electric sector is still using the exact same set of controls and asset scoping for its regulated security standards as when I first started working in the sector in 2006. NERC CIP version 1 was in final draft form, and the current requirements catalog will remain largely unchanged until at least 2015 when and if version 5 becomes effective. There have been minor changes in the interim, but not one that comes remotely close to addressing change in the threat landscape.

Will we ever have a perfect system? No. We do, however, urgently need to stop being complacent about the subject and implement those security measures that we can.

 

Brent: If you had your own ICS system, let’s say you ran Chris’s power company, what would that look like? How would it be protected?

Mr. Jager: It would look very, very “dumb”. Until such time as ICS and other automation technologies are vetted by process engineers – and I’m talking about the entire ICS/automation stack, I would automate only where it was impossible to operate the business or process without it.

It seems to me that we have a major employment problem in this country and no clear path to resolution. Putting some of these people to work securing our industrial control systems is an area where the private sector can help get the country back to work without relying on government funded stimulus packages. An added bonus is that we’ll end up with a whole cadre of workers who have been exposed to the industry, a percentage of who will stay in the field and help to address the industry’s gray out problem. All it takes is one or two sizable impacts from automation failure or misuse for the cost savings seen through automation to be wiped out.

Where I had no choice but to automate, Chris’ Power Company would look very much like any power company out there today, unfortunately. There simply aren’t enough vendors and manufacturers out there presently that produce secure equipment. Even then, systems integrators often further weaken the environment by adding support accounts and other remotely accessible backdoors to these systems.

Be it in the energy sector or any other, process automation installations will inevitably mature to a state of persistent vulnerability due to their long lifespans. Vulnerability discovery and exploitation techniques advance over time, vulnerabilities are introduced through regression bugs elsewhere in the software or protocol stack, or the process itself may have changed to a point where a previously innocuous vulnerability now has the ability to introduce a large impact if exploited.

Eventually, pointing out that the emperor has no clothes becomes a career limiting move – particularly when said emperor is an exhibitionist! Instead, the focus should be on identifying the more sensitive individuals in the crowd and protecting them appropriately through sound risk identification principles. We can’t make the problems go away through risk management, but we can use the techniques to identify the things that matter most and, where we can’t mitigate the risk, implement monitoring and response controls. This sort of approach also helps prioritize future efforts and dollars.

The top security controls at Chris’ Power Company would center around monitoring and response as employees would be trained to assume the environment was in a persistent state of compromise. In the environment we live in today where threats are real and expressed, and vulnerabilities aren’t able to be universally mitigated, the only real chance at controlling risk you have is to manage the impact of a successful attack. You only get that chance if you are able to detect and respond before the attack balloons to the maximum impact value.

If you failed to give my company that chance, you wouldn’t be working at Chris’ Power Company!


Thanks to Chris Jager for his insights and passion about ICS security. We appreciate his willingness to spend time with us. Thanks, as always, to you the reader, for your attention. Until next time, stay safe out there!

Quick Thought on CSRF Attacks

Yesterday, I listened to @Grap3_Ap3 present at the Columbus OWASP local chapter on Cross Site Request Forgery (CSRF). While this attack has been around since 2001, it continues to show a strong presence in web applications across a range of platforms. Phil spent a lot of his time talking about content management systems on the public Internet, but we have seen CSRF very widely exploitable on embedded devices.

Embedded devices, often equipped with rather rudimentery web servers and applications for management, have proven to be a searing hot pain point for CSRF in our research. While that isn’t shocking or new, I definitely see an interesting and potentially dangerous collision between the growth of the “Internet of Things” and web vulnerabilities. Today, some of these platforms are toys, or novelty tools built into home appliances – BUT, the future of internetworking of our devices and our physical lives means that these web controls will eventually have larger impacts on our day to day lives.

What happens when a CSRF attack can be used to trick your teenager into clicking on a picture on the web that while they view it, they also execute a command to raise the temperature on your refrigerator to unsafe levels? Or when an embedded link in an email tricks you into a click that turns your oven onto super heat clean mode without your knowledge? Sound like a prank? Maybe. Extend it to thermostats, home automation and consumer control over alternative energy controls like solar panels and such and it might take a new form.

We are on a course of collision. Our inattention to information security and the exploding complexity and technology dependencies will soon come together in ways that may surprise us. Ignore the hyperbole, but think about it rationally. Isn’t it time we worked with organizations who make products to demand an increase in protection from some of these basic known attacks? In the future, consumers and organizations alike will vote with their dollars. How will you spend yours?

SDIM Project Update

Just a quick update on the Stolen Data Impact Model project for today. Basically, we have reached a point where have created an idea that the impact of stolen data should be a curve. We have decided to implement that curve across two axis measured in the following:

Risk to the organization – 0 – 10, obviously subjective.

Those values will be plotted across four time segments: Immediate, Short Term, Intermediate Term and Long Term. Some folks are still discussing if we need a Residual catch all for things that don’t ever go away. If you have thoughts on it, please weigh in.

Thus far, we are leaving the term definitions to the consumer. But we are generally working with them as variable as we run scenarios with variety.

The next step will be to build and publish a couple of quick and dirty sample curves for some common stolen data scenarios. Then, we will begin to generate the scoring mechanism and perhaps a questionnaire for doing the scoring on a more repeatable basis.

If you have thoughts, please weigh in via the comments or touch base with us on Twitter. I will be the main conduit for feedback (@lbhuston). 

Thanks for reading and this process is already proving helpful for some folks, so we enjoy working on it.

Ask The Experts: Malware Infection Mitigation

This time, we have a question from a reader:

Dear Experts, I’ve been fighting with my help desk team about the proper response to a malware infection. Once we know a workstation or server has been infected, what should we do to make sure that machine is clean before we put it back in service? We have heard a variety of stories about cleanup versus rebuild. What is the MSI security expert’s take on the proper response to malware infection?

John Davis replied:

It would be nice to be able to eliminate Malware without having to totally rebuild your computer. I wish I had some good news for folks on that score. But unfortunately, the only way to be sure that a malware infection has been totally eliminated is to do just that: rebuild your computer completely from reliable backups. This illustrates the importance of making frequent backups and storing those backups securely!

Adam Hostetler also added:

The only proper response is complete wipe and reinstall. It’s impossible to say it’s clean after it has a known infection, one part might be gone but the malware may have installed or downloaded other components that weren’t detected. I recommend having a good image to use on workstations, and store as little data on them as possible, so a quick turn around is likely. It’s also a good idea to implement strong egress controls on your firewalls and monitor them. This helps in preventing malware from doing damage, and aids in finding infections. 

Got a question for the Experts? Get in touch on Twitter (@lbhuston or @microsolved) or via the comments. Thanks for reading!

PS – Chris Jager (@ChrisJager) points out on Twitter: Also to consider: Closing vuln that allowed the malware onto the host & refreshing backups & build docs w/said updates.

Thanks Chris! We just ASSUMED (yeah, we know…) that was already in scope, but good to mention that it should be pointed out. Clearly, making sure the bad guys lose their foothold from being re-exploited is CRITICAL.

Threat Update: Wide Scale Phishing in Progress

GlobalDisplay Orig

Just a quick update about the ongoing threat from malware dropped by phishing attacks. There are a lot of phishing attacks currently in progress. Fishing has been a leading form of compromise for quite some time and indicators appear to point to an increasing amount of phishing attacks and a larger amounts of damage from successful exploitation.

Many organizations are reporting wide spread phishing using recycled, older malware including Zeus, Tepfer and other common remote access tools. In some cases, these malware are repackaged or otherwise modified to evade anti-virus detection. Attackers are showing medium to high levels of success with these attacks.

Once compromised, the normal bot installation and exfiltration of data occurs. For most organizations that don’t play a role in critical infrastructure, this likely means credentials, customer information and other commercially valuable data will be targeted. For critical infrastrcuture organizations, more specific  design, future state and architectural data is being targeted along with credentials, etc.

Organizations should be carefully and vigilantly reviewing their egress traffic. They should also be paying careful attention to user desktop space and the ingress/egress from the user workstation DMZ or enclaves (You DO have your user systems segregated from your core operations, correct???). Remember, you CAN NOT depend on AV or email filtering to rebuff these attacks at a meaningful level. Detection and response are key, in order to limit the length of time the attacker has access to your environment. Anything short of full eradication of their malware and tools is likely to end with them still maintaining some level of access and potentially, control.

Now is a good time to consider having a phishing penetration test performed, or to consider using MSISimplePhish to perform some phishing for yourself. Awareness alerts and training are also encouraged. This is going to be a long term threat, so we must begin to implement ongoing controls over the entire technology/ppolicy & process/awareness stack. 

If you have any questions on phishing attacks, malware or incident response, please let us know. Our teams are used to working with these attacks and their subsequent compromises. We also have wide experience with designing enclaved architectures and implementing nuance detection mechanisms that focus on your critical assets. Feel free to touch base with us for a free 30 minute call to discuss your options for increasing security postures.

Audio Blog Post – IT History: An Interview with Brent’s Mom

Today, I got to do something pretty cool! I got to record a quick interview about the history of IT and what some of today’s technologies look like through the eyes of someone who has done IT for the last 40 years. Even cooler than that, I got to interview MY MOM! 

Check this out; as she discusses mainframes, punch cards and tape vaults, insights about mainframe authentication and even quality control in the mainframe environment. She even gives advice to IT folks approaching retirement age and her thoughts on the cloud. 

She closes with a humorous insight into what she thinks of my career and when she knew I might be a hacker. 🙂

It’s good stuff, and you can download the audio file (m4a format) by clicking here

Thanks for listening and let me know if you have other IT folks, past or present, you think we should be talking to. I’m on Twitter (@lbhuston) , or you can respond in the comments.

HoneyPoint Security Server ICS/SCADA Deployment Example

Recently, there have been several questions about potential deployment scenarios for HoneyPoint Security Server in and around ICS and SCADA organizations. Here is a quick, high level view of what a sample deployment might look like in a utility or other ICS environment. Note that the sample environment has fully embraced enclaveing. The network is fully segmented based on function.

In organizations where segmentation or the use of enclaves has not been established, HPSS can still be used and would be deployed in much the same manner.

Please let us know if you have any questions about this diagram or about deploying HPSS in your environment. We would be happy to set up a free consultation with you to discuss how the tool could aid in your detection program and give you increased visibility throughout your enterprise.

PS – If the graphic is difficult to read, right click on it and select view in new tab. The theme for the site is having trouble with this particular graphic.

HighLevelEnclaves

New Project: Stolen Data Impact Model (SDIM)

This is just a quick announcement about a new project we are starting at MSI. The name of the project is the Stolen Data Impact Model (SDIM).

The goal of the project is to identify a methodology for scoring the impact of data stolen in a breach. We believe the scoring mechanism will be some kind of curve, based on the impact of the loss over time. Currently, we are spreading that loss over four time frames: immediate, short term, intermediate term and long term.

We also believe that there are more than one facet of impact that could be in play and we are currently discussing how to handle the multiple facets.

We are just starting the project, and plan to work through it with the input f the community. We searched for models to address this, but were unable to identify any. If your organization has a model, methodology or process for this and you are open to sharing, please get in touch. You can always contact us in the comments or via Twitter (@lbhuston) or (@microsolved).

Thanks and we hope to present more on this topic shortly.