Security Policy Manual

Do you have a written, published security policy? What does it cover? Is it for internal use only, or do you share it with customers? Do you keep it up to date? How often is it revised? Do you really follow it, or is it more honored in the breach than the observance?

Clients often want to see a Security Policy Manual. Some just want to know that it exists, but others truly dissect security processes to ensure that vendors are living up to the client’s vendor standards. This latter group of clients is often also interested in seeing evidence that the training and other processes documented have been implemented. You probably need a well documented security policy, and need to publish it internally. Besides being a recognized best practice, it is good to train employees in security (both system security and otherwise), and make them aware that there are published standards to which they are being held. Whether you need to share the contents of this policy with clients will depend on the nature of your systems, their business and the sensitivity of their data with which you deal.

It is important to:

• Have a published security policy manual, and maintain it under change control
• Follow its tenets, and document compliance
• Cover both systems and employee behavior
• Adhere to operational and organizational norms considered to be industry best practices for security
• Omit processes and procedures that clearly have no business benefit in your environment

So what is in a security policy manual?

I have seen dozens of security policy manual, and have begun to suspect that they are all lineally descended from one common ancestor (I have the same suspicion when I read disaster recovery plans). While they are all different, it is clear that there are common themes despite the obvious differences in technology, organization, and level of data sensitivity from company to company. This is not a bad thing. It is a reflection of the growing body of information security best practices, our common acceptance of these standards and the integration of the associated good security behavior into our normal activities. Taking an existing security policy manual (with permission, of course) and adapting it to your company’s needs is rather not plagiarism, but standing on the shoulders of those who have come this way before. There are plenty of other venues in which you can exercise your creativity; this doesn’t have to be one of them. Actually adapting an existing policy manual to your particular business and technology needs may take all the creativity you can muster.

So what do you need to include in your security policy manual, and where can you get help? A great Internet resource is The SANS Security Policy Project. The SANS Institute (http://www.sans.org/) was established in 1989 as a cooperative research and education organization. The Security Policy Project (http://www.sans.org/security-resources/policies/) offers a Security Primer and an amazing assortment of templates for a Security Policy Manual. These templates are available for your use, with the appropriate attribution to the SANS Institute. In their templates they make distinctions between policies (specific requirements), standards (requirements that must be met by everyone), and guidelines (best practice suggestions). These distinctions may be overkill for your purposes.

System attacks for fun and profit are becoming more ubiquitous and more sophisticated every day. Having a good policy and a good policy manual do not guarantee good security. Good security requires constant vigilance. In the next article I’ll outline some specific recommendations for your Security Policy Manual.

Introducing Small Company CTO Blog

These days it is a given that a medium size or large company will have a Chief Technology Officer (CTO). Information (computer) technology (IT) represents a significant business expense, and permeates all aspects of our business. It must be managed as a valuable resource, and the business must receive quantifiable value from its IT investment. Larger companies may have divisional CTOs reporting directly, or dotted line to a corporate Office of the CTO. CTOs have wide responsibilities for IT infrastructure, system development and information utilization. They may have staffs to whom they delegate the management of large budgets, inventory, operations, process and procedure development, security, business continuity planning, system development, project management (PMO), vendor management, research, architecture, outsourced development and procurement, among others. A large company will have documented policies and procedures that govern all the above.

In a small company, the CTO wears all the same hats without anyone to whom to delegate. In some small companies the IT Director assumes many of these roles, as they become necessary. Company management may not appreciate the vast scope of the roles one person is being asked to play.

The role of the CTO in a small company can be vastly different than that same role in a larger organization. It really takes a wider breadth of skills and experience, and an active network of outside skilled professionals to:
• Consult on thorny problems
• Bounce ideas off
• Pick up the slack on critical projects when the budget permits.

The small company CTO must manage the Technology and technologists, contribute hands-on deliverables in areas that his or her staff lacks the necessary skill, support the business functions and goals of the company and patiently explain IT initiatives to business management. Over the next several months I hope to share my experience in all these areas through essays and anecdotes published in this space. I will select a topic and attempt follow that as a theme through several entries. However, as interesting events overtake me in my various roles with different companies, I will share off-topic entries out of sequence.

Aaron Cohen
October 7, 2009