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.

Security Audit

How is your system security? Workstations? Servers? Web site? Terminal Server?

How do you know?

You have followed all the recommendations from all the hardware and software vendors. You’ve hardened your servers, firewalls, load balancers and other web-facing appliances. You have a protocol for regularly installing and testing service packs and security patches for your operating systems and vulnerable software. You have closed unneeded ports and deactivated unused services.

What have you missed?

You have appropriately segmented your network (DMZ) to limit access to your mission-critical servers and databases containing private or proprietary data. You scrupulously close the backdoors your administrators have used for emergency system access from home. If you host your own website or web application, you have programmed defensively guarding against the upload of executable files and scripts disguised as text files. Your input forms check for cross-site scripting (XSS) attacks in both the front end and back end code. You employ intrusion detection and prevention software or services.

What else do you need to do?

I strongly recommend an independently performed security audit that includes both automated and manual penetration testing. I have been the beneficiary of three of these very informative exercises, and it is amazing what a good security audit will turn up. For two of our audits I contracted with The Morningtown Group. My third audit was performed by SAIC at the behest of a US Government organization using our services. We have responded to auditors’ suggestions by doing everything from installing better physical security (locks and keys), to strengthening our user password requirements, to turning off stray MS Windows Server services. We have also determined that some suggestions do not apply to our situation and can be safely ignored.

What do you get for your money?

You get:

· A comprehensive security survey and audit performed by certified systems security professionals

· A report covering a panoply of potential risks to your systems from accidental intrusion, malicious human attack, and natural disasters among others

· A software scan of web-facing system vulnerabilities—automated penetration testing

· Follow-up manual penetration testing based on the findings of the software scan

· A list of potential vulnerabilities and suggested mitigation strategies, by risk severity, probability of occurrence and priority.

· Validation of all your hard work to produce a secure system for your employer

· The warm feeling that you have truly done everything you can to both secure your company’s IT infrastructure, and had that effort validated

· The ability to tell your customers and potential customers that you regularly contract for a systems security audit

Regarding that last point. When anyone asks, I tell them politely but pointedly that, “No, we do not share the audit report outside the IT department. I would be happy to summarize it for you, though.”

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