Incident response plans 1 to 3 paragraphs (non technical) that discuss: • • • • • • • • • • • Selecting team members Define roles, responsibilities and lines of authority Define a security incident Define a reportable incident Training Detection Classification Escalation Containment Eradication Documentation Change management Change management is a formal process for directing and controlling alterations to the information processing environment.
This includes alterations to desktop computers, the network, servers and software.
The objectives of change management are to reduce the risks posed by changes to the information processing environment and improve the stability and reliability of the processing environment as changes are made.
It is not the objective of change management to prevent or hinder necessary changes from being implemented.
Any change to the information processing environment introduces an element of risk.
Even apparently simple changes can have unexpected effects.
One of Managements many responsibilities is the management of risk.
Change management is a tool for managing the risks introduced by changes to the information processing environment.
Part of the change management process ensures that changes are not implemented at inopportune times when they may disrupt critical business processes or interfere with other changes being implemented.
Not every change needs to be managed.
Some kinds of changes are a part of the everyday routine of information processing and adhere to a predefined procedure, which reduces the overall level of risk to the processing environment.
Creating a new user account or deploying a new desktop computer are examples of changes that do not generally require change management.
However, relocating user file shares, or upgrading the Email server pose a Information security much higher level of risk to the processing environment and are not a normal everyday activity.
The critical first steps in change management are (a) defining change (and communicating that definition) and (b) defining the scope of the change system.
Change management is usually overseen by a Change Review Board composed of representatives from key business areas, security, networking, systems administrators, Database administration, applications development, desktop support and the help desk.
The tasks of the Change Review Board can be facilitated with the use of automated work flow application.
The responsibility of the Change Review Board is to ensure the organizations documented change management procedures are followed.
The change management process is as follows: • Requested: Anyone can request a change.
The person making the change request may or may not be the same person that performs the analysis or implements the change.
When a request for change is received, it may undergo a preliminary review to determine if the requested change is compatible with the organizations business model and practices, and to determine the amount of resources needed to implement the change. • Approved: Management runs the business and controls the allocation of resources therefore, Management must approve requests for changes and assign a priority for every change.
Management might choose to reject a change request if the change is not compatible with the business model, industry standards or best practices.
Management might also choose to reject a change request if the change requires more resources than can be allocated for the change. • Planned: Planning a change involves discovering the scope and impact of the proposed change; analyzing the complexity of the change; allocation of resources and, developing, testing and documenting both implementation and backout plans.
Need to define the criteria on which a decision to back out will be made. • Tested: Every change must be tested in a safe test environment, which closely reflects the actual production environment, before the change is applied to the production environment.
The backout plan must also be tested. • Scheduled: Part of the change review board’s responsibility is to assist in the scheduling of changes by reviewing the proposed implementation date for potential conflicts with other scheduled changes or critical business activities. • Communicated: Once a change has been scheduled it must be communicated.
The communication is to give others the opportunity to remind the change review board about other changes or critical business activities that might have been overlooked when scheduling the change.
The communication also serves to make the Help Desk and users aware that a change is about to occur.
Another responsibility of the change review board is to ensure that scheduled changes have been properly communicated to those who will be affected by the change or otherwise have an interest in the change. • Implemented: At the appointed date and time, the changes must be implemented.
Part of the planning process was to develop an implementation plan, testing plan and, a back out plan.
If the implementation of the change should fail or, the post implementation testing fails or, other “drop dead” criteria have been met, the back out plan should be implemented. • Documented: All changes must be documented.
The documentation includes the initial request for change, its approval, the priority assigned to it, the implementation, testing and back out plans, the results of the change review board critique, the date/time the change was implemented, who implemented it, and whether the change was implemented successfully, failed or postponed. • Post change review: The change review board should hold a post implementation review of changes.
It is particularly important to review failed and backed out changes.
The review board should try to understand the problems that were encountered, and look for areas for improvement.
Change management procedures that are simple to follow and easy to use can greatly reduce the overall risks created when changes are made to the information processing environment.
Good change management procedures improve the over all quality and success of changes as they are implemented.
This is accomplished through planning, peer 213 Information security review, documentation and communication.
ISO/IEC 20000, The Visible OPS Handbook: Implementing ITIL in 4 Practical and Auditable Steps  (Full book summary ), and Information Technology Infrastructure Library all provide valuable guidance on implementing an efficient and effective change management program.
Information security 214 Business continuity Business continuity is the mechanism by which an organization continues to operate its critical business units, during planned or unplanned disruptions that affect normal business operations, by invoking planned and managed procedures.
Unlike what most people think business continuity is not necessarily an IT system or process, simply because it is about the business.
Today disasters or disruptions to business are a reality.
Whether the disaster is natural or man-made, it affects normal life and so business.
So why is planning so important? Let us face reality that “all businesses recover”, whether they planned for recovery or not, simply because business is about earning money for survival.
The planning is merely getting better prepared to face it, knowing fully well that the best plans may fail.
Planning helps to reduce cost of recovery, operational overheads and most importantly sail through some smaller ones effortlessly.
For businesses to create effective plans they need to focus upon the following key questions.
Most of these are common knowledge, and anyone can do a BCP. 1.
Should a disaster strike, what are the first few things that I should do? Should I call people to find if they are OK or call up the bank to figure out my money is safe? This is Emergencey Response.
Emergency Response services help take the first hit when the disaster strikes and if the disaster is serious enough the Emergency Response teams need to quickly get a Crisis Management team in place. 2.
What parts of my business should I recover first? The one that brings me most money or the one where I spend the most, or the one that will ensure I shall be able to get sustained future growth? The identified sections are the critical business units.
There is no magic bullet here, no one answer satisfies all.
Businesses need to find answers that meet business requirements. 3.
How soon should I target to recover my critical business units? In BCP technical jargon this is called Recovery Time Objective, or RTO.
This objective will define what costs the business will need to spend to recover from a disruption.
For example, it is cheaper to recover a business in 1 day than in 1 hour. 4.
What all do I need to recover the business? IT, machinery, records…food, water, people…So many aspects to dwell upon.
The cost factor becomes clearer now…Business leaders need to drive business continuity.
My IT manager spent $200000 last month and created a DRP (Disaster Recovery Plan), whatever happened to that? a DRP is about continuing an IT system, and is one of the sections of a comprehensive Business Continuity Plan.
Look below for more on this. 5.
And where do I recover my business from…
Will the business center give me space to work, or would it be flooded by many people queuing up for the same reasons that I am. 6.
But once I do recover from the disaster and work in reduced production capacity, since my main operational sites are unavailable, how long can this go on.
How long can I do without my original sites, systems, people? this defines the amount of business resilience a business may have. 7.
Now that I know how to recover my business.
How do I make sure my plan works? Most BCP pundits would recommend testing the plan at least once a year, reviewing it for adequacy and rewriting or updating the plans either annually or when businesses change. Information security 215 Disaster recovery planning While a business continuity plan (BCP) takes a broad approach to dealing with organizational-wide effects of a disaster, a disaster recovery plan (DRP), which is a subset of the business continuity plan, is instead focused on taking the necessary steps to resume normal business operations as quickly as possible.
A disaster recovery plan is executed immediately after the disaster occurs and details what steps are to be taken in order to recover critical information technology infrastructure. Laws and regulations Below is a partial listing of European, United Kingdom, Canadian and USA governmental laws and regulations that have, or will have, a significant effect on data processing and information security.
Important industry sector regulations have also been included when they have a significant impact on information security. • UK Data Protection Act 1998 makes new provisions for the regulation of the processing of information relating to individuals, including the obtaining, holding, use or disclosure of such information.
The European Union Data Protection Directive (EUDPD) requires that all EU member must adopt national regulations to standardize the protection of data privacy for citizens throughout the EU. • The Computer Misuse Act 1990 is an Act of the UK Parliament making computer crime (EG cracking sometimes incorrectly referred to as hacking) a criminal offence.
The Act has become a model upon which several other countries including Canada and the Republic of Ireland have drawn inspiration when subsequently drafting their own information security laws. • EU Data Retention laws requires Internet service providers and phone companies to keep data on every electronic message sent and phone call made for between six months and two years. • The Family Educational Rights and Privacy Act (FERPA) (20 U.S.C. § 1232  g; 34 CFR Part 99) is a USA Federal law that protects the privacy of student education records.
The law applies to all schools that receive funds under an applicable program of the U.S.
Department of Education.
Generally, schools must have written permission from the parent or eligible student in order to release any information from a student’s education record. • Health Insurance Portability and Accountability Act (HIPAA) of 1996 requires the adoption of national standards for electronic health care transactions and national identifiers for providers, health insurance plans, and employers.
And, it requires health care providers, insurance providers and employers to safeguard the security and privacy of health data. • Gramm-Leach-Bliley Act of 1999 (GLBA), also known as the Financial Services Modernization Act of 1999, protects the privacy and security of private financial information that financial institutions collect, hold, and process. • Sarbanes-Oxley Act of 2002 (SOX).
Section 404 of the act requires publicly traded companies to assess the effectiveness of their internal controls for financial reporting in annual reports they submit at the end of each fiscal year.
Chief information officers are responsible for the security, accuracy and the reliability of the systems that manage and report the financial data.
The act also requires publicly traded companies to engage independent auditors who must attest to, and report on, the validity of their assessments. • Payment Card Industry Data Security Standard (PCI DSS) establishes comprehensive requirements for enhancing payment account data security.
It was developed by the founding payment brands of the PCI Security Standards Council, including American Express, Discover Financial Services, JCB, MasterCard Worldwide and Visa International, to help facilitate the broad adoption of consistent data security measures on a global basis.
The PCI DSS is a multifaceted security standard that includes requirements for security management, policies, procedures, network architecture, software design and other critical protective measures.
Read more about ITIL In : ISO IEC 20000 The Visible OPS Handbook Implementing ITIL in….: