Hello there!

My name is Lee Herloth (with a “Hard T”) and I work in critical infrastructure protection, specifically for an electric utility.  I’ve been invited by the good folks here at Liquidmatrix.org to write a blog from time to time and I thank them for the opportunity.

I was ready to fire off a post about how utterly unprofessional, dangerous, and borderline criminal it is to see so many vendors testifying in front of the United States Congress in support of new legislation (no less then five active bills right now) designed, in title, to increase the security of varying critical infrastructures.  However, I have thought better of that as it would not be fitting of a southern gentleman.

Instead, I will refrain from calling said vendors on the carpet for using their influence to back legislation that directs the government to use their auditing guidelines, risk assessment tools, or to anoint a singular person as the czar of all things critical infrastructure protection.  Therefore, this post will be SANS any ranting lest the internal struggle of having done so Impact my Core values, for that surely would not be Weiss.

On any given day, there are tens of thousands of United States residents alone who are without power due to mundane reliability failures stemming from equipment failure, human error, weather, and physics – oh, and the occasional possum or two.  However, “Oops!  My bad”, isn’t a sexy headline.  Instead, much like the current fuss around “swine flu”, that which has a catchy name will win the attention of the reactive politicians and people at large and the larger, more meaningful issues go unaddressed.

Yes, we are plugging in our critical infrastructure to your internet.  We have no choice.  You want cheap, clean, reliable power so off to the races we go.  As with any new activity, there will be learning opportunities and missteps along the way, and we have much work to do.

I believe I have a rather unique insight into the industry and I’m passionate about protecting the infrastructure I’m charged to protect against all comers.  Make no mistake about it – if we leave the future direction of critical infrastructure protection in the wrong hands, you will start to see a decrease in the reliability and affordability of your power.  The cure, when offered by a snake-oil salesman, will be most definitely worse than the disease.

And with that, I bid you good day.

Comments

  1. Well-put sir. I have worked (as a power services vendor) in a past life so I’ve worked on “securing power delivery and regulatory mechanisms” – and sadly I’ve found that the pace and pressure of delivering “innovation” out-paced our ability to secure it quite badly. Unfortunately, bad things often happened as a result.

    In the near future I’d love to hear someone from your position comment on the things going on with self-regulating power grids (like what’s happening in California with the power company being able to “wirelessly” regulate a home’s thermostate during peak power usage periods) – the idea of the “Smart Grid” is very cool, but the security implications are far beyond what I think most people have considered.

    Love to hear your opinions and thoughts.

  2. Awesome post. Need more like this. I love it when security twits get involved in legislation and public policy, even more so when they don’t even live in the US. =)

  3. It refreshing to see someone with a reliability focus. It is the primary mission. Let’s use the sexy headlines to fund true reliability projects with secure implementations.

  4. In reading the blogs and summary of the testimony, it isn’t just “self serving vendors who are pushing this legislation. Don’t forget the numerous consultants and consulting firms. JTT

  5. hat is an interesting blog entry…

    Its my opinion that Infrastructure engineers do not understand the risk that hackers pose to their infrastructures and as a direct result do not properly weigh the threat that malicious hackers bring to the table. I see a repeatable theme where engineers talk about risks like human error, system failures, etc. and how those risks can cause downtime. I almost never see engineers talk about the hacker threat and how that can cause downtime. In fact, the opposite is true in that I’ve witnessed engineers attempting to discredit the hacker threat and to consider the threat less severe than the risk of human error or system failure.

    Its important to understand two definitions. Risk is used to define the vulnerability of a particular target. “What is my risk?” is synonymous to “what is my vulnerability?” in most, if not all cases. The threat, for the purposes of this argument, is the hacker. In this case, if the threat is able to align with the risk then there can be, has been, and will continue to be problems. Those problems can mimic human error, system failures, etc. As a result, the engineer might never realize the true source of the failure(s).

    This problem is further compounded by ignorance about what risks exist with respect to which risks can be exploited by hackers (think alignment of risk and threat). It is _fact_ that infrastructural technologies, not just SCADA technologies, are riddled with risks that can be exploited by hackers. But, because engineers aren’t aware of these risks, or don’t understand these risks, or don’t understand how hackers can use these risks, they are not weighed properly with respect to importance and severity. There is no fault or blame so long as engineers make an effort to expand their understanding of risks and take these new issues into consideration. To date, most engineers aren’t making such an effort but instead are trying to discredit the hacker threat.

    Distributed Metastasis is the act of propagating a penetration throughout a network from an initial point of penetration. The initial penetration can be done using an email, pdf, document, .jpeg image file, client side exploit, server side exploit, etc. Getting compromised can be as simple as reading a .pdf attachment, browsing the web, or plugging in a USB stick. It can also be as complicated and intricate as a Social Engineering attack augmented by technology issues. Either way, once an attacker is in there’s a good chance that he or she will perform distributed metastasis. Once that happens, the infrastructure can’t be easily recovered and is under the control of the hacker. What is more scary is that if the hacker is good, nobody will know that he or she is there.

    This isn’t FUD. My team penetrates into networks that are well protected and well monitored by today’s standards. Last year we were only detected 1% of the time during our advanced penetration tests. In most cases we penetrated our customer’s infrastructure, performed Distributed Metastasis, and called the customer to update them. When we tell them that we are already in and that we’ve penetrated multiple internal (LAN) based systems from the internet, they’re shocked. Hackers have the upper hand and they always will. Security will always be reactive because hackers create the threat and you can’t defend against a threat until its been created and discovered. Hackers are starting to focus more and more on Infrastructure, so when is infrastructure going to focus more and more on hackers?

    A bit of a tangent… but it makes sense… doesn’t it?

  6. I’m not clear on what you’re for or against here.

    Do you not believe there are significant operational vulnerabilities in critical infrastructure’s reliability posed by cyber systems? Do you not believe there are people maliciously trying or interested in exploiting those vulnerabilities? Or do you believe the threat exists, but you are knocking the vendors’ positions/solutions to those threats?

    If it’s the latter, I’m with you. If it’s the first two, not so much.

    Also, you seem to be implying (maybe Im misreading..it’s not clear)…that fixing “security” risks must come at the cost of fixing “normal” reliability risks and we should fix “normal” problems first. First, I don’t believe it’s an either/or scenario. Second, since the industries have done a typically GOOD job at fixing “normal” reliability risks, there is – of course – less of a push for further work in those areas. On the other hand, mitigations to cyber threats are typically NOT as mature, and so probably deserve more discussion. Last, treating “cyber” risks and “normal” reliability risks as different things really implies a misunderstanding of the nature of the cyber risks.

  7. @Jack Whitsitt

    It most definitely is not an either/or scenario. As the infrastructure automates, the lines between safety, reliability, and security must necessarily blur. That is one of the biggest concerns I have with much of what I see – an overemphasis by some, through FUD, that the primary focus is one versus the other, be it reliability or security. It is difficult to discern if they are just trying to dip into the pot of “cyber gold” at the industry’s expense or are indeed blind to the larger picture.

    I suppose mine is a cautionary tale. On the ground, this sort of public grandstanding does nothing but enforce cultural gulfs that must be bridged if we’re to make real headway towards tackling the challenges we face. Given the size and complexity of the issues we’re dealing with, there is plenty of room at the table and perhaps, just maybe, an opportunity to learn.

    There are indeed significant operational vulnerabilities that come with automation given the long lifecycle of infrastructure components. There are also an unknown number of threats aligned against us and I agree that there needs to be a major adjustment to the standards governing our industry, perhaps through legislation of some kind, to ensure that these infrastructures are shored up. However, I would much rather see this sort of legislation come through without the FUD that lends itself to vendor/consultant lock-in, and focus more on how to create cohesive standards that address not just one aspect, but the above _in cohesive unison_, lest we willfully overlook key issues in response.

    Now where did I put that glass of sweet tea…

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.