Whether prompted by regulations or by management intent to comply with security best practices, the first step after creating a security strategy is development of policies. However, there are some organizations who treat policies as the endgame. Those taking this approach are not only misguided. They are potentially exposing their sensitive data and critical systems to greater risk.
The Policy Myth
Security policies are simple statements of intent. They provide to employees management’s expectations regarding acceptable use, handling, and implementation of critical systems as well as the confidentiality, integrity, and availability of sensitive information. However, they don’t provide for consistent application of management intent. Nor do they describe and mandate and system of oversight to ensure compliance and effectiveness.
David Aminzade addresses these issues in an article posted today on Help Net Security. He begins with,
Most large organizations maintain a detailed corporate security policy document that spells out the “dos and don’ts” of information security. Once the policy is in place, the feeling is of having achieved ‘nine-tenths of the law’, that is, that the organization is in effect ‘covered’. This is a dangerous misconception. Because much like in the world of law and order, while creation of law is fundamental, implementation and enforcement of law is what prevents chaos.
Source: Is having a security policy in place really nine-tenths of the law?, David Aminzade, Help Net Security, 20 April 2009
Making Policies Real
To make policies ‘real’ to technical and business process employees, people must be aware they exist. They must also follow documented processes intended to result in compliance. So the next step after policy approval is development of supporting processes.
Processes typically provide step-by-step instructions for how to perform a single task or set of tasks. If an employee follows a process, he or she will automatically produce compliant outcomes—at least that’s the expectation. Effective processes are developed in collaboration with all stakeholders, and then introduced to existing employees via training programs. New hires should be provided with similar training.
This is another point in developing a security program where some organizations stop, with the belief they are now compliant. Stopping here strengthens their defenses beyond those of the policy-only managers, but it still causes them to fall short of a truly effective security program.
The final step in making policies real to employees and the organization is implementation of oversight tools and processes. Aminzade included a good-start list in his article:
Continuously monitor firewall and other security device changes, compare them to the corporate security policy, and send out alerts if the policy has been violated. Track and report all changes in a uniform, simple and straightforward style. Provide a vendor-neutral, top-down view of all security infrastructure that an executive can understand. Enable security administrators to test a change against security policy before it is implemented, to assess and avoid risk.
To this list I would add internal audits, which provide an outsider’s perspective of processes and outcomes. I would also add both internal and external vulnerability scans and penetration tests.
The first bullet should be part of an overall log management process. I always recommended outsourcing this activity. It is tedious work which can be done at less cost by a managed security services provider (MSSP).
Tasks associated with the second and fourth bullet are typically part of a change management process. Change management
… deals with how changes to the system are managed so they don’t degrade system performance and availability. Change management is especially critical in today’s highly decentralized, network-based environment where users themselves may be applying many changes. A key cause of high cost of ownership is the application of changes by those who don’t fully understand their implications across the operating environment.
Source: Implement change management with these six steps, Change Tech. Solutions, ZDNet, 8 January 2004
Along with oversight, sanctions should be imposed fairly, as close to the actual event as possible, and clearly stated as possible consequences for not following approved procedures. Formal, documented investigations can help change employee behavior even if their risky actions are not cause for disciplinary action. Investigations help raise management awareness of potential employee or process issues.
The final word
Getting compliant is about documenting management intent, building enforceable processes which produce consistent outcomes, and monitoring to ensure the network is as secure as expected. Assuming employees will simply act safely because a policy exists or making assumptions about security outcomes is a good way to end up as tomorrow’s media target because of a breach or malware induced network shutdown.