It’s part of the security herding instinct: "Company A is doing it, therefore it must be the right thing for me!"
Mike Braun, CISSP CISA CISM ITIL-F, Senior Security Engineer, Verizon Business.
Regarding "compliance vs security": Compliance is doing the minimum necessary to meet an audit or regulatory compliance. Security is doing what is necessary, often within the compliance or audit structure, to reduce risk to an acceptable level defined by the business you’re in.
Jake Brodsky, Washington Suburban Sanitary Commission
How secure is secure enough?
That's really the foundation question. It's like asking how safe should our cars be? We can include all sorts of measures in them, ranging from anti-lock brakes, airbags, seat-belts, crumple zones, safety glass, traction control, and so on and so forth. Yet even this isn't going to help if the driver is reckless.
Control systems are like that. Currently we have very few prescriptive standards, and the application of the broad concepts borrowed from IT is no simple task. The biggest hurdle is education: Ensuring that people understand what they're doing when they design these things. It is also a matter of teaching people to operate these things securely.
As an interim step, we have to mandate a compliance-based approach, with the caveat that this alone may not save you from an attack. In other words, do this, even if you do not understand exactly why; and if you screw up, you could still get hurt. So study why you should be doing this.
In the long run, a compliance-based approach is only a temporary measure until people combine enough experience and knowledge to know better.
Ralph Langner, Langner Communications AG
I noticed your request for input on the controlglobal blog. Even though I work in Europe, I want to share some thoughts that you might find helpful.
How much security do you need to be really secure?
The answer certainly depends largely on your definition of security. I define the following as INSECURE: An automated industrial process is insecure if foreseeable failures or manipulation attempts of automation equipment, SCADA installations or network devices can cause damage beyond the insignificant, or can cause damage of unknown extent. In real life, it is often quite easy to determine required mitigation controls to get away from insecure. However, there is a difference between HSE [health, safety and environmental] risks and risks relating "only" to money. For HSE, budget for mitigation is largely determined by ethics, legislation and compliance, whereas for monetary consequences, budget decisions have to match anticipated monetary loss.
What's the difference between compliance and security?
Simple, if you look at the last sentence above. Only part of the potential negative outcomes from security events; i.e., HSE, are regulated. Compliance requires regulation that you can comply to. For other risks, there is no compliance, but there are still security issues that need to be mitigated. For example, there is no need to patch systems or to install firewalls in order to be compliant. Companies do so anyway in order to reduce risk.
Chemical Facility Security News
There is no such as “really secure” or “absolutely secure”; it is a purely theoretical concept like infinity. By adding security measures you can get closer, but each successive improvement moves you a shorter distance towards the theoretical goal. Unlike the mathematical construct, however, the theoretical goal is periodically moved a random increment further away due the advances made by the opposition—and, that movement is seldom made with the knowledge of the home team.
Compliance versus Security
Since security is unattainable, and for all intents and purposes unmeasurable, organizations establish artificial standards that serve as a surrogate for security. When a component of that organization has met the current standards, they can claim to be “in compliance.” Most people fail to realize that being ‘in compliance’ only bears an indistinct and variable relationship to being secure.
William T. Shaw - PhD, CISSP
As I am sure you well know, “compliance” is more of an issue about legal niceties and being able to claim to have taken reasonable measures, provided reasonable oversight and shown suitable governance in a court of law. You can be in compliance and yet not be secure if you are merely willing to do the minimum necessary to meet regulations and are not actually focused on establishing true security. Most of the regulations regarding industrial automation security are somewhat vague and open to a range of possible interpretations. That is one reason that groups like the ISA’s SP-99 committee are trying to generate more detailed, specific recommendations. The NERC CIPs are an interesting mix of specific requirements (like requiring an IDS for an EMS/SCADA system) and generalities (like the lack of a standardized, defined methodology for performing vulnerability assessments.) An organization could come into compliance with the “‘letter” of those requirements and yet still have security holes. As someone once said, perfect security is not possible and obtaining it would be prohibitively expensive. So organizations have to make a basic business decision about how secure they need to be, and then let that be part of the equation when implementing a security program. Numerous electric utilities ignored the initial NERC cybersecurity pronouncements (1200/1300) and took a wait-and-see attitude, both because the recommendations were somewhat vague and because they had no enforcement “teeth.’ Among various organizations I have consulted with some immediately wanted to know what the minimum amount of effort was, that would allow them to claim compliance. They were not really interested in security (or felt they already were secure enough) only in compliance.