Based on 25 years of professional experience in various businesses around the globe, I can say that many industry verticals have a pretty good state of safety culture as it relates to the health and safety of their employees.  This is especially true for companies involved in high-risk businesses such as oil and gas, (nuclear) energy, manufacturing, chemicals, food processing, and so on.  In such industries, it is pretty clear that there is a risk that something may blow up, hurt, or even kill people.

However, it seems that the next big driver for them is business alone, and they are not as focused on information or IT security when it comes to the logic side of security like bits and bytes, document handling of confidential information, and similar subjects.  This is in stark contrast to their keen attention to physical safety and security issues.

It would seem intuitive that any organization with  a commitment to safety by counting (and incentivizing) the hours (days, weeks, months, ...) of safety-incident-free time should also be easy to convince that taking a similar approach to information security would be a good thing. But it is not that easy.  Operations in these businesses are very physical, so it is not really in the mind-set of a rig guy or gal, a welder, a component mixer, machine operator, or similar, that another devastating incident (attack) could happen from "within" the system(s), by a human adversary committed to do harm in the interest of their nation state or paying agent.  All those systems in the above mentioned industries that are working at the process level (sensors/actuators, process control, SCADA (supervisory control and data acquisition) are designed for efficient and effective, good performing, and reliable operation, but they were not really designed and built to resist logic attacks from a human smart guy who can outsmart almost every defense.

In industrial networks, spanning the areas of instrumentation, control bus, operations, business, or enterprise, the often cited Purdue reference model that provides for several "levels" or "zones" of abstraction and segregation can be used.  A really good introduction can be found in the Secure Data Transfer Guidance for Industrial Control and SCADA Systems.

The main security points to address are:

• Network segmentation by a secure architecture with a multi-zone approachas in the example referenced (such as an internet-near services zone (or "Enterprise DMZ"), a critical services zone (or "Enterprise Zone"), a business support zone (or "Operations DMZ"), an operations support zone (or "Operations Management"), an operations control zone (or "Supervisory Control"), and an automation zone (with different firewalled process control, safety controls, phasors and actuators -or "Instrumentation Zone")). A zone is a network segment controlled by the same one authority and security policy (think of systems with the same trust level).
• Pleaseensure that the firewalls segmenting off the above zones will be able to fully understand and verify the allowed protocols and also be able to decipher encrypted traffic.  They should be able tofunction as a true application level gateway, while still being able to defend against lower protocol level attacks (including overlaying attacks across those layers), proxy, and filter.  In case that one specific product alone cannot handle these requirements, integrate a solution so that the resulting "firewall black-box entity" is atrue security guarantorand not a point product that will fail in one way or the other.  Integrated IPS/IDS features, malware and advanced threat protection all should be integrated here, fed by globally acquired threat intelligence sources.
• Encryption must be centralizedin the form of a trusted PKI/CA; exchange with a third party (i.e. for oversight or vendor support) must be donevia a mutually agreed certification-root-CA.
• For process control parametersthat are being set via the above used protocols,integrity checks like hashing, MAC, CRC, and the like are in order.  Imagine a bit flipping due to an external event (cosmic radiation, static discharge, etc.) resulting in a valve opening instead of closing or vice-versa.
• Authentication shouldno longer be based on IP addresses or similar lower level entity tuples, but insteadfocus on the user (identity) subject and a PKI-based certificatethat is authenticated by a trusted root CA certificate (a process for updates etc. must be defined and adhered to).
• In addition to the technical areas that must be addressed, it is of not-to-be-overestimated importance todefine, adhere to, and audit the organizational controls around personnel(hiring/back ground checks, ongoing and regular training & awareness, transfer, and separation process), equipment purchasing and installation (rogue wireless APs for example),and change management processes(ITIL etc.).
• The processes of an organization should be regularly reviewedfor improvement and potential security shortcomings.  This is expensive and time intensive, but each breach you can read daily in the newspapers or see on TV / twitter (or your favorite source of information) will give you one more reason to follow this advicebeforethe attack happens in your case.  It will also integrate[1] very well with a BIA (business impact analysis) effort that should be done anyway.
• The former two bullets are true in general, but here are focused on the people in industrial control settings, and on industrial processes (process level).

People who have been working in security realms for years can certainly relate to situations where they were told:

• "We can't afford to wait; we must bring in this new service [/tool/protocol/feature/...] right now for the business"
• "We're paying the bill, you're just a cost center" (or worse: "you're impeding business")
• "This quarter was terrible, we need to tighten up and get rid of roadblocks"
• Etc. -your favorite story goes here

The problem of security is often business leaders have no idea about these subjects, have only focused on certain aspects of "their" business and forget/ignore the bigger picture that is painted on the wall (WSJ) about companies being under attack every day.  As long as an attack has not impacted "their" business, business leaders would have to justify the extra spending on security to their board and they are guilty of being afraid to do that.  Unfortunately, it takes time (and many breaches over the last decades) for boards to become knowledgeable about these issues.  Fortunately, though, there are indicators that boards are starting to get the message (either via regulators, competitor breaches, or just because they take their oversight roles seriously).  They start asking CIOs, CTOs, CEOs, and other executives how they have addressed security problems and what they have planned for the worst case scenario.  That is where groups like mine come into play: we're a unique and dedicated team of highly accomplished former CISO/CSOs who  are ready to help your company to derive an adequate security strategy from your business strategy.  We can help you at all stages -regardless where you are at with your security maturity life-cycle.

In case you are interested in our team's services, please reach out to Cisco via the contacts link.

[1] See the entire security lifecycle in my commercial book "C(I)SO -And Now What?" -a free excerpt is available here: http://www.csoonline.com/article/730751/book-excerpt-c-i-so-and-now-what-?