2. "Compliance" vs "Security"
Compliance is dotting the i's and crossing the t's for some form that is required by your company, or required by law. It really has nothing to do with security or secure systems. FISMA is such an example.
Security is making sure that you protect your assets.
I would wager that companies who are secure are also compliant. Companies that are compliant are not necessarily secure.
Ernie Rakaczky, Principal Security Architect
To position the “compliance versus security question” correctly, one must first take compliance/compliancy and realize from the outset that there are multiple levels in being compliant, but that the number one focus always seems to be around that one snapshot in time―the audit.
Holistically, compliancy is imperative for a successful cyber or physical security program. Being compliant can range from complying with an auditable set of federally mandated guidelines, like NERC CIP, to simply complying with an internal policy or procedure that has been established within a security program. Compliancy requirements drive the overall management of a security program, and it is within these requirements that many necessary security measures will be established.
Here again, people first look at security measures as a means to protect, and that is paramount, but security measures also need to include monitoring, correlation, rationalization, etc. That is how you can begin to evaluate if the investment in security outweighs the value of the assets you are trying to protect.
Compliancy can’t guarantee that established security measures of an organization will never be breached. But compliancy and practical security measures serve as the foundation for a culture where everyone feels like they have an equal stake in the overall security and success of the operation. In a security culture, the security program is part of the plant’s normal way of life.
So how do you know if you have enough security to be really secure?
To answer that, we have to use the basic definition of security as the degree of protection against danger, loss and criminals.
To understand, manage and reduce risk, the following elements need to be considered. It all comes down to:
- Assurance - the level of guarantee that a security system will behave as expected;
- Countermeasure - a way to stop a threat from triggering risk;
- Defense-in-depth - never relying on a single security measure, but on a layer of security measures;
- Exploit - a vulnerability that has been triggered by a threat;
- Risk - a possible event that could cause a loss;
- Threat - a method of triggering risk;
- Vulnerability - a weakness in a target that can potentially be exploited.
So how does this all play into determining security requirements?
For the most part, today’s conversations on security focus on the cost of and/or burden of implementing security. Plant and enterprise managers know that something has to be done, but at the same time, they want to know what they can do to reduce the cost of their investment while still mitigating risk.
In some regards, just doing even a little will raise the security of the infrastructure substantially.
Something that is frequently overlooked is the fact that today’s control systems and their interconnectivity can be used not only to improve operations, i.e., controlling the process better to move more down the wire, out the pipe, etc, but also for improving the flow of business information across the enterprise. That means that data that has always been there is more valuable now, and when it all comes together from several plants, it allows an operation to make better, more fundamentally sound day-to-day business decisions. So what we really need to start doing is quantifying that data and the value it brings to an organization to help them make a solid business case for investing in security.
At its core, the basic security requirement is to protect the process and operation from disruptions and all the issues that derive from an event. Some of the risks within process controls are related to policies that require moving existing data out of the actual control systems, things like EPA reporting, historian information, production management information, etc.
It is safe to say that no plant is going to go back in time and reinstate operational procedures, as was common practice in the past, via manual logging, data transfer via manual recoding, trying to estimate a value on a pen chart, etc. The challenge today is to identify these common practices and clearly show how continual modernization has saved and enhanced the financial models of the operating organization. By doing that, we should start to see the clear value and importance of applying stronger security to reduce risk, maintain business continuity and provide the ability for greater visibility into process areas.
Dan DesRuisseaux, Manager, Ethernet Marketing Group
1) How much security is enough?
Security requirements will vary based on application and the criticality of the process. An application that monitors readings from sensors and does no active control will have different security requirements than a system that controls a complex, mission-critical application. Other variables, such as public perception, downstream processes and environmental impact, also weigh heavily on the decision to add more or less security. Additionally, security can have a price tag associated with it, thus security requirements must be weighted based on the business impact of a breach and the up-front cost.