BCP Planning I

You have been asked to put together a disaster recovery or a business continuity plan.  OK, first a few questions:

1. Are you responsible for the full business continuity plan, or just a disaster recovery of the IT equipment and services?
2. If just disaster recovery, then is there already a business continuity framework?  Are these being done in parallel?
3. If you are responsible for the full business continuity plan, do you have support from a high up enough in the organization to get the cooperation you will need from every other business unit?

Even the simplest disaster recovery plan that addresses only IT services and equipment needs to be based upon the answers to a few basic questions about the priorities of the business.

­

•           What critical business functions are supported by the IT infrastructure?
• ­          How long can each of these services be unavailable without impacting business operations and bottom line?
• ­          For which of these functions are there manual operational workarounds?
• ­          How much is the business willing to spend to ensure what level of the mean time to recovery (MTTR)?

Our technology has advanced to the point that with the dedication of enough money and resources we can guarantee continuous operation for most applications.  Service-level agreements (SLAs) need to be negotiated port each business function.  Whereas it makes business sense to spend money on low latency recovery strategies for applications that generate revenue or are critical to human life and safety, other applications may be safely left off-line for an extended period of time.  These are business trade-offs.  These decisions must be made by business managers with the support of technical intelligence from the IT community.

In the event of a disaster, the business wants all their systems back online, immediately, and for free.  IT needs to present to the business a span of options and relative costs that include hardware, software and operational expense.  In this way you get upfront buy in from the business for the disaster recovery plan.  Without going through this exercise you will be second-guessed at every turn, both during the project, and then again when and if a disaster is ever declared.

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.

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