In much the same way, just because your system “complies” with a particular directive or set of guidelines does not imply that it's necessarily inherently secure. Best practice guidance, regulations and compliance documentation all provide critical input into the process, but to achieve adequate security in depth―a single layer is not usually enough―means you have to assess the specifics relating to items such as your geography, communications infrastructure, employee policies and control, technical architecture, protocol support, physical access, training, criticality of data and systems, government or other regulatory body requirements, risk profile and much more.
Regular auditing and testing of that framework will then help evolve the model further.
John Cusimano, Director, Security Services, exida
The answer to the question “how much security do you need” really depends on how much risk are you willing to accept. With the understanding that one can never completely eliminate risk, corporations need to quantify their level of tolerable risk and then design their systems to meet or exceed this level. Risk-based methodologies have been successfully applied to Safety Instrumented System design since the late 1990s and can arguably applied to security design as well. Similarly, risk assessment methodologies can be applied to security assessments to quantify the risk inherent in a system. Once a risk level has been determined, system architects can apply defense-in-depth strategies to mitigate the risk to critical assets to a tolerable level.
Compliance is measure of conformity to a standard or regulation; whereas, security is defined as being “free from danger or injury.” The relationship between the two is that one can establish a target security level in the form of a tolerable risk level and measure whether one is compliant to that target.
PCS 7 Marketing Manager, Siemens Energy & Automation
How much security do you need to be secure?
Security is really a relative term. There is almost no way to provide 100%t assurance that a system is secure today and will be secure in the future. Some would say that an isolated system (air gap) is secure. That is true―until an engineer brings a memory stick from his office PC and connects it to the isolated system to transfer files.
Security is also not a static concept. It is continually changing. To maximize security posture, owner/operators should implement a defense-in-depth security concept. This concept leverages technology (such as firewalls, access control, virus scanners), software patch management, physical protection and personnel operating procedures to create a layered defense.These measures must be continually updated and augmented to ensure that newly discovered security vulnerabilities are mitigated.
Security also has a risk vs. reward curve that differs by business and by industry. For example, the potential consequences of a cyber incident to a piece of the U.S. critical infrastructure (like a nuclear power plant) could be catastrophic.
What’s the difference between “compliance” and “security”?
Wikipedia defines compliance as “the act of adhering to, and demonstrating adherence to a standard or regulation.” For security this would imply adherence to a security regulation. But, unfortunately, there is no one accepted security regulation that governs process and SCADA applications across industries. The NERC Critical Infrastructure Protection (CIP) Cyber Security Standards govern electrical/bulk power industries. The Chemical Facility Antiterrorism Standard (CFATS) applies to high-risk chemical facilities.
To fill the security compliance gap, ISA has created the Security Compliance Institute (ISCI). One of the main goals of this consortium is to define a security test specification that can be used for compliance testing of devices and systems. The institute will also coordinate the testing of devices against the compliance test specification resulting in the granting of the “ISASecure” certification. The testing protocol is being developed based on industry best practices and the work of various standards such as ISA 99.
On a SCADA security mailing list, I saw a request for perspectives on two issues:
- How much security do you need to be really secure?
- What's the difference between "compliance" and "security"?
I don't mind responding to these, but the opinions are, of course, my own and not any position of the company that employs me.
1. How much security do you need?
It depends on what you are trying to defend from. If it is from outsider attacks/intrusions, then it is an ongoing process. The methods of attack change constantly, so the security defenses you use must also change constantly. There is no such thing as "enough," since the game is always changing.
If, on the other hand, you are trying to secure your systems from insider threats, the problem is different, but also equally difficult. It comes down to individual accountability. If something happens, can you tell precisely who did it and when? If you can't, then you are inadequately prepared. If you can, and something does happen, at least you can determine the guilty party and take action against them. If speed and/or flexibility are important to your business, you have to work hard to maintain individual accountability. If you have assets to protect at all costs, then speed and flexibility are not factors, and you define very strict rules to ensure individual accountability.