We Don't Care about Data and IT Security

  • Part of the problem with security issues is the nature of the feedback loops to the people who have the power to ensure that security measures are central to the way an organization works.

    The feedback loop to a client who wants you to carry out some work for them is likely to be both continuous and subject to a very definite negative outcome if you fail to meet expectations - which will almost never go much beyond cost and timescale.

    It is therefore easy to continuously prioritise that delivery at the expense of time and resource that could ensure better adherence to good practice in the security field. Here the feedback loop is slow and uncertain. Slack practice will increase the probability of a security breach, but compared to the immediacy and certainty of client feedback it is easy to dismiss.

    IT staff, in my experience, do care and will do their best to maximize security and data integrity within the limitations they have imposed on them, and will try to escalate their concerns. However, power doesn't lie with those people and business priorities generally mean that anything that may increase time or cost on a project gets dismissed with a JFDI instruction from those who do hold the decision making power.

  • John Hanrahan (8/11/2014)


    That sounds like Auditors who know their stuff. I have been through audit after audit the last few years and have found from an IT perspective the auditors don't come close to understanding IT security or even the issues. It is disturbing to have them come in and audit our IT when it is clear they really only understand accounting. I figure if they aren't reading Brian Krebs on a regular basis they aren't up to speed (that isn't a guarantee though of course).

    That crew probably bill themselves as penetration testers. That's to distinguish from the auditors who are pretty much all paper with respect to controls.

    K. Brian Kelley
    @kbriankelley

  • venoym (8/12/2014)


    K. Brian Kelley (8/11/2014)


    venoym (8/11/2014)


    I have to question the "myth" of the Air-Gap that is referenced. A proper Air-Gap or Data Diode for SCADA systems provides a level of protection that cannot be denied.

    It provides an additional level of protection. I'm not denying that. However, the way most SCADA systems have been built, what's behind that data diode is ripe for the picking. You can't add additional layers of protection without breaking the system. Why do they have that attitude? Because they trust the air gap/data diode is the be all/end all. It isn't. It's just a broke and outdated idea in infosec.

    I realize this will probably fall on deaf ears. If you rely on only the Data Diode/Air Gap, you deserve to fail, and will fail. An Air-Gap/Data Diode is required by Federal Regulations for Nuclear. Consider, you can't take a system that is a hodgepodge of equipment from every decade back to the 1970's and expect to run the latest and greatest IDS/IPS and anti-malware on every device. Most devices in a SCADA system are simple PLC/firmware devices that only know "point A and set points X, Y and Z". Servers and workstations need to be protected by Best Practices regardless of Air-Gap.

    To blanketly state that a Data Diode/Air-Gap is broken and outdated Information Security is disingenuous at best. They work as long as you continue to do the other Cyber Security Best Practices in addition. Like anything, they are a tool to be used and used properly. Similar to the use of NULLs or GOTO, there are valid and GOOD uses of them (Yes, I realize that half of the people reading this just tuned out, but seriously... do some objective research). Finally I'll state that you do NOT want a Nuclear plant to have its control and protection systems to have a 2 way connection to the Internet.

    It's not falling on deaf ears. You understand that there is a need for more. However, go back and look at how many SCADA systems can't be protected from insecure installations because you'll break something or, at best, you'll render it out of support. Why is that?

    It's because too many in the industry rely on data diode/air gap *exclusively*. Too many systems are designed where this is the only protection. That's my point. That's the point of that article. You're arguing the same point, that there needs to be more on that single factor of protection. The mistake you're making is extending your own understanding and practice to the rest of your industry.

    K. Brian Kelley
    @kbriankelley

  • K. Brian Kelley (8/12/2014)


    venoym (8/12/2014)


    K. Brian Kelley (8/11/2014)


    venoym (8/11/2014)


    I have to question the "myth" of the Air-Gap that is referenced. A proper Air-Gap or Data Diode for SCADA systems provides a level of protection that cannot be denied.

    It provides an additional level of protection. I'm not denying that. However, the way most SCADA systems have been built, what's behind that data diode is ripe for the picking. You can't add additional layers of protection without breaking the system. Why do they have that attitude? Because they trust the air gap/data diode is the be all/end all. It isn't. It's just a broke and outdated idea in infosec.

    I realize this will probably fall on deaf ears. If you rely on only the Data Diode/Air Gap, you deserve to fail, and will fail. An Air-Gap/Data Diode is required by Federal Regulations for Nuclear. Consider, you can't take a system that is a hodgepodge of equipment from every decade back to the 1970's and expect to run the latest and greatest IDS/IPS and anti-malware on every device. Most devices in a SCADA system are simple PLC/firmware devices that only know "point A and set points X, Y and Z". Servers and workstations need to be protected by Best Practices regardless of Air-Gap.

    To blanketly state that a Data Diode/Air-Gap is broken and outdated Information Security is disingenuous at best. They work as long as you continue to do the other Cyber Security Best Practices in addition. Like anything, they are a tool to be used and used properly. Similar to the use of NULLs or GOTO, there are valid and GOOD uses of them (Yes, I realize that half of the people reading this just tuned out, but seriously... do some objective research). Finally I'll state that you do NOT want a Nuclear plant to have its control and protection systems to have a 2 way connection to the Internet.

    It's not falling on deaf ears. You understand that there is a need for more. However, go back and look at how many SCADA systems can't be protected from insecure installations because you'll break something or, at best, you'll render it out of support. Why is that?

    It's because too many in the industry rely on data diode/air gap *exclusively*. Too many systems are designed where this is the only protection. That's my point. That's the point of that article. You're arguing the same point, that there needs to be more on that single factor of protection. The mistake you're making is extending your own understanding and practice to the rest of your industry.

    I know I'm a little slow, but I'm having some difficulty identifying venoym's mistake, from what I've read he's actually talking about required and recommended practices. Could you offer a little help in identifying his actual mistake? Sure would be appreciated!

  • patrickmcginnis59 10839 (8/12/2014)


    I know I'm a little slow, but I'm having some difficulty identifying venoym's mistake, from what I've read he's actually talking about required and recommended practices. Could you offer a little help in identifying his actual mistake? Sure would be appreciated!

    Venoym believes in defense in depth and not relying on one mechanism to protect your kingdom. This is the best approach. There's nothing wrong here.

    Unfortunately, there are too many in the development, implementation, and administration of SCADA software that don't think the same way. They believe that one defense, the air gap/data diode, can protect them from any and all attacks.

    Venoym's mistake, at least from what I've seen in the posts, is in thinking that more folks in the industry think like Venoym does. From what I've seen of the SCADA industry, Venoym is the exception, not the rule, when it comes to thinking about security and how to properly apply it.

    K. Brian Kelley
    @kbriankelley

  • Andrew..Peterson (8/11/2014)


    Yes, free market now.

    But back in the 1970's, without the limit, the only cards in wide use were American Express and Diner's Club.

    That surprises me. Barclaycard was widespread in the UK before 1970; I can't remember what the customer liability limit was, or even if there was a limit, despite having a card back then. There weren't any ATMs that accepted them, though - they had no mag stripe, just embossed details, and could only be where things were sold. They were a lot more popular that Diner's Card or Amex because they they took a smaller cut.

    Tom

  • jay-h (8/11/2014)


    Andrew..Peterson (8/11/2014)


    Credit card companies focus on fraud because they have to. A long time ago, a law was passed limiting the card holder's exposure to $50. (thank government regulations - for anyone who is anti-government).

    Funny thing, that. Many cards hold the cardholder to zero exposure. This is NOT required by regulation. But competition and the realization that getting the user to carry the card involves allaying fears.

    Free market.

    Nope, regulation. The regulation has reduced the liability to below the 'hassle threshold'. If liability were unlimited you'd not have them writing off the cash. In fact, if liability were pinned at $5000, or even $1000, they wouldn't, no matter how "competitive" the market cosy oligopoly.

    They'd just sell you a useless insurance policy they're almost never going to pay out on "for your peace of mind".

    I'm a DBA.
    I'm not paid to solve problems. I'm paid to prevent them.

  • K. Brian Kelley (8/12/2014)


    patrickmcginnis59 10839 (8/12/2014)


    I know I'm a little slow, but I'm having some difficulty identifying venoym's mistake, from what I've read he's actually talking about required and recommended practices. Could you offer a little help in identifying his actual mistake? Sure would be appreciated!

    Venoym believes in defense in depth and not relying on one mechanism to protect your kingdom. This is the best approach. There's nothing wrong here.

    Unfortunately, there are too many in the development, implementation, and administration of SCADA software that don't think the same way. They believe that one defense, the air gap/data diode, can protect them from any and all attacks.

    Venoym's mistake, at least from what I've seen in the posts, is in thinking that more folks in the industry think like Venoym does. From what I've seen of the SCADA industry, Venoym is the exception, not the rule, when it comes to thinking about security and how to properly apply it.

    In actuality, I don't extend that thinking. The US Nuclear Regulatory Commission does. Regulations stipulate that you can't stop at a Data Diode/Air-Gap, regardless of what your SCADA vendor does. I know for a fact that there are many who think that a Data Diode is the end all, which is wrong headed at best. The simple point that I'm attempting to illustrate is that beating a drum of "Air-Gaps are useless" is just as wrong as relying solely on them, this is what the linked article was about and is what you stated in your editorial. What the mantra of "Air-gaps are failed infosec" will lead to is SCADA systems directly connected to the Internet and highly vulnerable to many 0 day exploits that can cause actual damage to large portions of a country. Simply put, if it is not connected it cannot be remotely controlled! Do you still have to do best practices? YES. You can't disregard that some things NEED to be disconnected. (Think about the Top Secret data/information at the CIA as an example).

  • venoym (8/13/2014)


    K. Brian Kelley (8/12/2014)


    patrickmcginnis59 10839 (8/12/2014)


    I know I'm a little slow, but I'm having some difficulty identifying venoym's mistake, from what I've read he's actually talking about required and recommended practices. Could you offer a little help in identifying his actual mistake? Sure would be appreciated!

    Venoym believes in defense in depth and not relying on one mechanism to protect your kingdom. This is the best approach. There's nothing wrong here.

    Unfortunately, there are too many in the development, implementation, and administration of SCADA software that don't think the same way. They believe that one defense, the air gap/data diode, can protect them from any and all attacks.

    Venoym's mistake, at least from what I've seen in the posts, is in thinking that more folks in the industry think like Venoym does. From what I've seen of the SCADA industry, Venoym is the exception, not the rule, when it comes to thinking about security and how to properly apply it.

    In actuality, I don't extend that thinking. The US Nuclear Regulatory Commission does. Regulations stipulate that you can't stop at a Data Diode/Air-Gap, regardless of what your SCADA vendor does. I know for a fact that there are many who think that a Data Diode is the end all, which is wrong headed at best. The simple point that I'm attempting to illustrate is that beating a drum of "Air-Gaps are useless" is just as wrong as relying solely on them, this is what the linked article was about and is what you stated in your editorial. What the mantra of "Air-gaps are failed infosec" will lead to is SCADA systems directly connected to the Internet and highly vulnerable to many 0 day exploits that can cause actual damage to large portions of a country. Simply put, if it is not connected it cannot be remotely controlled! Do you still have to do best practices? YES. You can't disregard that some things NEED to be disconnected. (Think about the Top Secret data/information at the CIA as an example).

    "Air gaps are failed infosec" hasn't led to SCADA systems directly connected to the Internet. That's because there are SCADA systems that already are. And keep in mind that SCADA extends beyond nuclear. Almost any time someone does a study on SCADA systems, what is found? Are the types of controls you indicate should be in place for nuclear what is found? Is it even close? What leads to that thinking?

    K. Brian Kelley
    @kbriankelley

  • K. Brian Kelley (8/13/2014)


    "Air gaps are failed infosec" hasn't led to SCADA systems directly connected to the Internet. That's because there are SCADA systems that already are.

    Yeah, sure, so some people already get it wrong means it's fine to encourage more people to get it wrong, does it?

    You may have a valid argument somewhere in this discussion, but that nonsemnsense just lost you all your credibility with me.

    And keep in mind that SCADA extends beyond nuclear.

    So what? Because SCADA covers more than nuclear we should not bother about SCADA safety for nuclear?

    Almost any time someone does a study on SCADA systems, what is found? Are the types of controls you indicate should be in place for nuclear what is found? Is it even close? What leads to that thinking?

    What thinking is that that you are talking about? You don't appear to want people to understand what you mean. Are you asking whether things appropriate for nuclear are found every time a study is done on non-nuclear? If so, what relevance do you think the answer to that question could imaginably have to whether those things are important to the nuclear case? If not, what on earth does that string of words mean?

    Tom

  • TomThomson (8/13/2014)


    K. Brian Kelley (8/13/2014)


    "Air gaps are failed infosec" hasn't led to SCADA systems directly connected to the Internet. That's because there are SCADA systems that already are.

    Yeah, sure, so some people already get it wrong means it's fine to encourage more people to get it wrong, does it?

    You may have a valid argument somewhere in this discussion, but that nonsemnsense just lost you all your credibility with me.

    The idea that saying "air gaps are failed infosec" isn't what leads folks to connect SCADA systems to the Internet. Connecting any system to the Internet takes time and resources. So why do people do it? For their own convenience. I'm rejecting the notion that saying a statement like this makes people do something that causes themselves more work unless there's another reason. There IS another reason. And folks will go forward with that reason regardless of the risk. We see it outside of SCADA, too.

    And keep in mind that SCADA extends beyond nuclear.

    So what? Because SCADA covers more than nuclear we should not bother about SCADA safety for nuclear?

    I'm not saying that we shouldn't bother about SCADA systems for nuclear. If you go back and read the conversation, my comments are directed towards SCADA as a whole. One subset of the industry's implementation may be relatively secure. But you can't look at that one subset and say the whole industry follows the same pattern. It doesn't. The studies show that SCADA as a whole does not. That's my point.

    Almost any time someone does a study on SCADA systems, what is found? Are the types of controls you indicate should be in place for nuclear what is found? Is it even close? What leads to that thinking?

    What thinking is that that you are talking about? You don't appear to want people to understand what you mean. Are you asking whether things appropriate for nuclear are found every time a study is done on non-nuclear? If so, what relevance do you think the answer to that question could imaginably have to whether those things are important to the nuclear case? If not, what on earth does that string of words mean?

    As I said, something is lost if you don't follow the conversation. I'm not saying neglect nuclear. What I've been saying is that nuclear isn't representative of the whole. If nuclear is more secure and believes in more than an air gap/data diode solution, then it's actually an exception when you consider the entire population. It shouldn't be that way, but it is what it is.

    K. Brian Kelley
    @kbriankelley

  • I think we have all gotten off the original topic here which was valid when it started. Security is an issue and the thought concerning it needs to be changed. However there are 2 things that aren't being addressed as this string progresses.

    1) You can't make a horse drink once you lead it to water.

    2) This is more important, if the current leaders are doing anything about it then stop wondering what could be done and start leading. Start doing anything that gets the message out there; be the change you want to happen instead of wondering when others are going to do it.

    My opionion on this.

Viewing 12 posts - 46 through 57 (of 57 total)

You must be logged in to reply to this topic. Login to reply