Security Policy Manual - Part 2

What goes into a Security Policy Manual?

Some of the contents depend on whether you are providing Security Policy for the company as a whole, or just for the Information Technology.  An integrated Security Policy for the company makes sense if you can get universal support from operations (COO), Legal and Corporate functions.  Such things as document security, content and distribution can be integrated into a coherent whole when everyone agrees to work together.  On the other hand, if you get push-back from territorial constituencies that see you as stepping on their toes, you might need to settle for a policy that covers IT functions alone.

Factors that determine the technical content of the Security Policy Manual depend on your level of exposure through the internet, and the extent to which you need to integrate your systems functions with those of customers, vendors and business partners.  For example, if your customers’ data  are stored on systems managed by your business partners, you need a policy for vetting the security policies of your business partners that ensures your customers’ data is demonstrably secure.

Let’s look at a possible outline for a Security Policy Manual:

Introduction

Objectives, motivation, definitions, scope, document organization, document development process, document update and revision schedule and process.

Security Process

Risk Assessment, Strategy, Implementation, Monitoring, Process Monitoring and Updating, Governance.

Risk Assessment

Security Controls Implementation

Access Control, Configuration Management (hardware, software), Physical and Environmental Protection / Data Center Security, Encryption, Malicious Code Prevention, Systems Development, Acquisition, and Maintenance, Software Development and Acquisition, Systems Maintenance (Hardening, Patch Management), Personnel Security (Background Checks, Confidentiality, Non-Disclosure, and Authorized Use Agreement, Training), Data Security, Business Continuity Plan.

Security Monitoring

Activity and Condition Monitoring, Security Incident Response, Independent Security Audit /penetration testing.

Security Process Monitoring And Updating

Monitor security policies for effectiveness, updated as necessary.

Possible Appendices:

·         Password Policybb

·         Remote Access Policy

·         VPN Security

·         Router Security Policy

·         Removable Media Policy

·         Encryption Usage Policy

·         Server Security Policy

·         Virus/Malware Monitoring Policy

·         Software Development and QA Security Policy

·         ASP Security Policy

·         Third Party Connection Policy

·         Device Disposal/Loss/Replacement Policy

·         Systems Acceptable Use Policy

·         Workstation Security Policy

·         Information Sensitivity Policy

·         Wireless Infrastructure and Connection Policy

There is truly a lot to think about, but there are best practices and guidance available.

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.