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.