When it comes to security policies and practices, there are rules (both written and unwritten) that need to be adhered to. An organization simply cannot implement changes to security on the fly as it could lead to disaster. Yet, there are times when changes are necessary, or mandated due to an incident response plan. In that instance, what should business leaders be focusing on?
CSO recently posed a hypothetical question to a few sources. When it comes to adjusting or adapting a security policy -- that is, changing what's already in place due to any previously unforeseen event such as a security breach, downsizing, employee termination, etc.--what are some key considerations that business leaders need to focus on or keep in mind?
"Start with first principles. Understanding what matters to an organization (PII? PCI? Intellectual Property?) is the jumping off point for a robust and modern set of security controls, and absent focus, organizations tend to react to incidents rather than organize a coherent set of investments and behavioral changes that will yield measurable results," explained Kevin O'Brien, enterprise solution architect, at CloudLock.
After that, he added, "Know where you want to be as a result of your change, and ensure that you can apply metrics to it... Security is often at the junction of what end users are interacting with, and how; it makes sense to control for data walking out the door via print-outs if and only if your users are physically accessing files in an office with a printer, for example."
Otherwise, modern environments tend to be highly distributed, and platform solutions (Salesforce, Office 365, Google Apps, etc.) define both the types of data that matters to ordinary users and the mechanisms through which they can access and externalize them.
"A robust security plan will address those environments specifically, and provide a means of measuring incidents and responding to them in real time," O'Brien said. But don't confuse auditing with control.
"Insight is not security on its own. Security policy should not only lay out what may or may not be exposed, but also how a breach or loss will be addressed, both in the short term to limit the damage done, and over the longer term to mitigate the exposure vector and reoccurrence risk."
Given the same hypothetical question, Michael Daly, the CTO of Cybersecurity and Special Missions for Raytheon, told CSO that business leaders should capture metrics on the current environment in order to understand compliance to the current policy. From there, the organization would need to project the state of compliance with the draft policy. While this happens, the organization should "avoid creating any policy for which you cannot measure your compliance."
"Understand the relationship between your draft policy and the legal frameworks (law, regulations, executive orders, national standards) in any area where this policy would apply, including your enforcement mechanisms; for example, if you create a new policy that will involve monitoring the use of the Internet, be sure to take into account the requirements for employee notification, data protection, data retention restrictions, disclosure requirements, etc," Daly explained.
Moreover, organizations should have a communication plan to notify employees (as well as suppliers and partners if needed) of the change in policy, the reason for the change, and how they can comply, Daly said.
"Communications should be very brief. Avoid policies for which compliance requires extensive communication or training," he said.
Organizations should also avoid creating policies that require persistent exceptions ("waivers"), and avoid policies that cannot be implemented with controls that prevent deviation. Compliance should be automatic and transparent whenever possible, Daly said, adding that business leaders should "make it easy to do the right thing."
When posed with our hypothetical, Eric Cowperthwaite, the Vice President of advanced security and strategy for CORE Security, highlighted three priorities: impact, cost, and the Law of Unintended Consequences.
"As an example you want to roll out a new password scheme changing passwords from 6 digits to 8 to improve security. If you are dealing with a smaller organization, this task is not that daunting but as soon as you get involved with a geographically diverse organization, or a company with many departments this becomes a more difficult task," Cowperthwaite said, explaining the impact side of his answer.
"For these larger organizations you need to conduct a business impact analysis. As part of that analysis you need to figure out how to roll out the changes, the impact of the changes, deployment issues, and communications for the changes," he said.
Sticking to the password example, Cowperthwaite mentioned cost as another consideration, pointing out time as a key expense.
"If we ask 100k people to change their passwords how much time will that take? What is the cost of that lost productivity? Does the cost in lost productivity outweigh the benefit of a more secure system? A cost-benefit analysis is needed. In some regulated industries, there are mandated staff ratios that need to be maintained, if you take a person off the job for a training session or update class, you need to backfill that position to maintain compliance."
As for the Law of Unintended Consequences, Cowperthwaite kept to his password policy change example, and pointed out the fact that the organization will need to deal with the possibility of legacy systems that cannot adapt to the new policy, as the character requirements for passwords are too large. Moreover, there are the possible behavioral changes that the policy will create, the hold-outs who never get around to changing their passwords, as well as debate between longer, simpler passwords and shorter more complex passwords.
"In a large organization even a seemingly small change requires massive amounts of planning," Cowperthwaite said, hammering home the downside to an ever-connected business world.
This story, "Essential Considerations When Making Changes to Security" was originally published by CSO .