NIST SP 800-34 Contingency Planning Guide gives detailed information regarding the necessary planning principles for developing an effective contingency capability, business impact analysis and alternative site selection and recovery strategies.
One of the other takeaways from this standard is its detailed explanation about how to embed contingency planning into information system development lifecycle. In Appendix F, it is stated that identification and integration contingency strategies should be performed at all stages of SDLC. This approach enable owner both implementing layered security protection and effective recovery strategies early in the system development. Moreover, it reduces costs and potential impact on business processes when the contingency plan is implemented.
My unique reading for this week is about the Crisis Communication Plan. This was unique because many times companies just focus on operations and technical aspects of contingency planning and forget that public relations is important in times of crisis. According to NIST, the crisis communications plan typically designates specific individuals as the only authority for answering questions from or providing information to the public regarding emergency response. Having a one source of communication going out to the public helps the company control the narrative. Without a Crisis Communication Plan an incident may look worse than it is in public because of differing statements from different people within the same organizations.
Hi Percy, Thanks for stating the importance of designating communication with the press ( during a major insident) to the public relations director of the organization. This will help to give the corporation one voice during an incident. The IT staff members and the IT security staff may be tempted to provide information to the public maybe because of their technical knowlegde but it is not their job.
This special edition of NIST gives a good summary about the development process of contingency plan for federal agencies. The process includes designing a contingency planning program, evaluating the organization’s needs against contingency strategy options based on the system impact levels, security controls, and technical considerations, and documenting the contingency strategy into a contingency plan, testing the plan, and maintaining it. This document also provides guidelines for technical contingency plan for three types of systems: Client-Server, Telecommunication and Mainframe. One key point to note is the importance of BIA while selecting appropriate contingency plan template. It is recommended that BIA be included right from the SDLC process as well as be considered during preparation of Risk Profile so that requirement of appropriate controls is known even for contingency planning.
This is an important point, and while it may seem like overkill to include BIA during the early phases of the SDLC, it would make the most feasible sense to include the consideration for contingency planning controls. Since we want to avoid making security an afterthought, it is appropriate that we try to include it as early as possible in all aspects of business processes.
One key point which I take away from NIST SP 800-34 (Contingency Planning Guide for Federal Information Systems) is about information system contingency planning process. It includes 7 main processes which are 1)Develop the contingency planning policy, 2) Conduct the business impact analysis (BIA), 3) Identify preventive controls, 4) Create contingency strategies, 5) Develop an information system contingency plan, 6) Ensure plan testing, training, and exercises, and 7) Ensure plan maintenance. Conducting BIA is the most important step to do Contingency plan because it is the process to determine mission or business process and recovery criticality, identify resource requirement, and identify recovery priorities for system resources. According to figure 3-2, it clearly illustrates how to determine critical system, recovery time objective (RTO) along with risk impact level from FIPS 199.
This is a very interesting takeaway. The 7 main processes towards the contingency planning process is so important for businesses to implement for successful coverage in the case of a disruption of service,
After reading through the NIST 800-34 publication, which discusses the certified and up-to-date methods for ensuring appropriate planning, procedures and security measures are in place to minimize service disruption, I have developed a better understanding of the requirements and considerations that must be taken into account while preparing an information system contingency plan (ISCP). During my reading, I took the time to ensure that I was at least somewhat familiar with most of the contingency planning process, focusing more time on sections I had the least understanding in such as the development of a Contingency Planning Policy Statement and the Creation of Contingency Strategies. In regards to the latter, I found it a great refresher to relearn how the FIPS 199 and Business Impact Analysis help determine the types of security controls that need to be implemented from the NIST 800-53 publication on Security and Privacy Controls for Federal Information Systems and Organizations.
Yes, the connection between documents is becoming more and more important the deeper we are diving in. With the rule from FIPS 199 and the analysis from Business Impact Analysis disaster recovery becomes so much easier to plan.
Nist 800-34r1 is a complete guide for developing IS contengency planning plan. It focus on Telecommunications , Mainframes and Client/Server Systems.
With more and more enterprises moving to the clound, the framework is still valid with ISCPP (Information System Contengency Planning Process) common to all Information Systems:
1) Develop the contingency planning policy;
2) Conduct the business impact analysis (BIA), cost balance poing;
3) Identify preventive controls;
4) Create contengency strategies;
5) Develop an information system contengency plan;
6) Ensure plan testing, training and exrcices;
7) Maintenance plan,
High Availability processes (HA) with the site mirroring is interresting as duplication eliminates single point of failure.
Hello,
Through reading your takeaways from the NIST 800-34 publication, I feel more confident in my current understanding of some of the overarching concepts covered in the document. Among the procedures you lined out that are common to the preparation of a contingency plan, the areas that I found the most interesting to briefly look into included the creation of contingency strategies and the development of the contingency planning policy.
In the NIST SP 800 34r1, it mentions a disaster recovery plan and its importance. A new takeaway that I learned was that this plan only address information systems that require relocation. I found this interesting as this was not my initial thought pattern towards this. Although this might be the case, I am aware that especially when it comes to data centers, they must be placed in an area that can withstand certain weather conditions. In the case that something occurs ruining the center, a relocation will be necessary.
Good point, Natalie,
Also the application of NIST guidance by agencies can result in different security solutions which are equally acceptable and meet the OMB definition of adequate security for federal information systems. According to the NIST document, auditors or evaluators assessing federal agencies must consider the intent of the security concepts and principles articulated within the particular guidance documents and how this guidance is applied in terms of specific mission responsibilities or operational environments.
One part that I found interesting in NIST SP 800-34r1 was the activation and notification phase, particularly the outage assessment procedure. When a disruption or outage occurs, the outage assessment team should first be notified as soon as possible in order to determine how the ISCP will be implemented. Some areas that need to be addressed are: the cause of the disruption, potential for additional damage, status of physical infrastructure, inventory and function status of equipment, type of damage to equipment or data, items that need to be replaced, and estimated restore time. This information will determine the impact of the disruption and the appropriate teams will be notified of how to move forward with the ISCP.
Sarah, activation and notification are paramount in the outage assessment procedure. I commented on another post that the “detection” phase is almost the most important step because if you never realize that you company has been hacked how will you ever fix the problems and stop it from happening again? I also think that there should be at least one section that outlines what should happen if humans are not able to complete their functions the entire process is essentially useless.
After reading the Contingency Planning Guide for Federal Information Systems, I noted the need for organizations to conduct a proper business impact analysis. Doing this can help the organization to identify, categorize and prioritize its information systems and components critical to its mission or business processes. According to this document, the BIA can help a firm to determine what impact loss of the system could have on the organization, and the system recovery time objective. Also, Information from the BIA can help an organization to know the type or frequency of backup, the need for redundancy, and the type of alternate site required to meet system recovery objectives.
You have highlighted the importance of BIA very well. BIA process and documentation and process is one of the most important steps of preparing a contingency plan. It is useful in determining many factors of a contingency plan as mentioned by you. The most interesting aspect is the involvement of business process owners, who give their input while preparing BIA. As IT Auditors, we have to correlate their business needs which are in financial numbers to the usefulness of the IT infrastructure being utilized in contingency plan.
The portion of NIST 800-34 that was most eye opening to me came early but I believe is crucial to having a solid base and understanding the entire guideline. The section is on the different types of plans that an organization need to deploy to be the most ready for if and when things go wrong. The three types of plans outlined are Continuity, Contingency, and Incident Response plans. Continuity plans focus on maintaining mission critical functions that will keep the main heart of the business working. Contingency plans outline what to do with the information systems concerning the data which is the most valuable asset to a business. And Cyber Incident Response plans focus on how to deal with an attacker and an attack once it happens. If a form can master all three of these plans they will be set up to weather whichever storm comes at them .
The one key takeaway from NIST 800 34r1 for me is that how the recovery step is placed. To recover a system, we first need to identify the sequence of restoration, After identifying the sequence, we need to know the step and what are we going to do next. The sequence of the restoration should be based on the Business Impact Analysis and the step of restoration is as follow,
Obtaining authorization to access damaged facilities and/or geographic area
Notifying internal and external business partners associated with the system
Obtaining necessary office supplies and work space
Obtaining and installing necessary hardware components
Obtaining and loading backup media
Restoring critical operating system and application software
Restoring system data to a known state
Testing system functionality including security controls
Connecting system to network or other external systems
Operating alternate equipment successfully
Hi, peiran Liu
You listed the recovery sequence, which helped me better understand the operation of the emergency plan.But I think sometimes when you get access to a damaged facility, there’s a possibility that the data could be stolen.The offline server should be offline in a timely manner and the backup and recovery work of the standby server should be started.
NIST SP 800 34r1 mainly targets at Client/server systems and Telecommunications systems. According to this plan, the IT security personnel can arrange the appropriate IT security plan for the organization to ensure the continuity of the organization’s business. The company’s Contingency Plan depends on the elements of the company. Maximum Tolerable Downtime (MTD), the Recovery Time Objective (RTO) and Recovery Point Objective (RPO) and so on. A good plan also needs to be implemented by experienced people, and IT security personnel should always be familiar with the implementation priorities of the plan.
NIST SP 800-34 Contingency Planning Guide gives detailed information regarding the necessary planning principles for developing an effective contingency capability, business impact analysis and alternative site selection and recovery strategies.
One of the other takeaways from this standard is its detailed explanation about how to embed contingency planning into information system development lifecycle. In Appendix F, it is stated that identification and integration contingency strategies should be performed at all stages of SDLC. This approach enable owner both implementing layered security protection and effective recovery strategies early in the system development. Moreover, it reduces costs and potential impact on business processes when the contingency plan is implemented.
My unique reading for this week is about the Crisis Communication Plan. This was unique because many times companies just focus on operations and technical aspects of contingency planning and forget that public relations is important in times of crisis. According to NIST, the crisis communications plan typically designates specific individuals as the only authority for answering questions from or providing information to the public regarding emergency response. Having a one source of communication going out to the public helps the company control the narrative. Without a Crisis Communication Plan an incident may look worse than it is in public because of differing statements from different people within the same organizations.
Hi Percy, Thanks for stating the importance of designating communication with the press ( during a major insident) to the public relations director of the organization. This will help to give the corporation one voice during an incident. The IT staff members and the IT security staff may be tempted to provide information to the public maybe because of their technical knowlegde but it is not their job.
This special edition of NIST gives a good summary about the development process of contingency plan for federal agencies. The process includes designing a contingency planning program, evaluating the organization’s needs against contingency strategy options based on the system impact levels, security controls, and technical considerations, and documenting the contingency strategy into a contingency plan, testing the plan, and maintaining it. This document also provides guidelines for technical contingency plan for three types of systems: Client-Server, Telecommunication and Mainframe. One key point to note is the importance of BIA while selecting appropriate contingency plan template. It is recommended that BIA be included right from the SDLC process as well as be considered during preparation of Risk Profile so that requirement of appropriate controls is known even for contingency planning.
This is an important point, and while it may seem like overkill to include BIA during the early phases of the SDLC, it would make the most feasible sense to include the consideration for contingency planning controls. Since we want to avoid making security an afterthought, it is appropriate that we try to include it as early as possible in all aspects of business processes.
One key point which I take away from NIST SP 800-34 (Contingency Planning Guide for Federal Information Systems) is about information system contingency planning process. It includes 7 main processes which are 1)Develop the contingency planning policy, 2) Conduct the business impact analysis (BIA), 3) Identify preventive controls, 4) Create contingency strategies, 5) Develop an information system contingency plan, 6) Ensure plan testing, training, and exercises, and 7) Ensure plan maintenance. Conducting BIA is the most important step to do Contingency plan because it is the process to determine mission or business process and recovery criticality, identify resource requirement, and identify recovery priorities for system resources. According to figure 3-2, it clearly illustrates how to determine critical system, recovery time objective (RTO) along with risk impact level from FIPS 199.
Hi Numneung,
This is a very interesting takeaway. The 7 main processes towards the contingency planning process is so important for businesses to implement for successful coverage in the case of a disruption of service,
Best,
Natalie
After reading through the NIST 800-34 publication, which discusses the certified and up-to-date methods for ensuring appropriate planning, procedures and security measures are in place to minimize service disruption, I have developed a better understanding of the requirements and considerations that must be taken into account while preparing an information system contingency plan (ISCP). During my reading, I took the time to ensure that I was at least somewhat familiar with most of the contingency planning process, focusing more time on sections I had the least understanding in such as the development of a Contingency Planning Policy Statement and the Creation of Contingency Strategies. In regards to the latter, I found it a great refresher to relearn how the FIPS 199 and Business Impact Analysis help determine the types of security controls that need to be implemented from the NIST 800-53 publication on Security and Privacy Controls for Federal Information Systems and Organizations.
Hi Imran,
Yes, the connection between documents is becoming more and more important the deeper we are diving in. With the rule from FIPS 199 and the analysis from Business Impact Analysis disaster recovery becomes so much easier to plan.
Nist 800-34r1 is a complete guide for developing IS contengency planning plan. It focus on Telecommunications , Mainframes and Client/Server Systems.
With more and more enterprises moving to the clound, the framework is still valid with ISCPP (Information System Contengency Planning Process) common to all Information Systems:
1) Develop the contingency planning policy;
2) Conduct the business impact analysis (BIA), cost balance poing;
3) Identify preventive controls;
4) Create contengency strategies;
5) Develop an information system contengency plan;
6) Ensure plan testing, training and exrcices;
7) Maintenance plan,
High Availability processes (HA) with the site mirroring is interresting as duplication eliminates single point of failure.
Hello,
Through reading your takeaways from the NIST 800-34 publication, I feel more confident in my current understanding of some of the overarching concepts covered in the document. Among the procedures you lined out that are common to the preparation of a contingency plan, the areas that I found the most interesting to briefly look into included the creation of contingency strategies and the development of the contingency planning policy.
In the NIST SP 800 34r1, it mentions a disaster recovery plan and its importance. A new takeaway that I learned was that this plan only address information systems that require relocation. I found this interesting as this was not my initial thought pattern towards this. Although this might be the case, I am aware that especially when it comes to data centers, they must be placed in an area that can withstand certain weather conditions. In the case that something occurs ruining the center, a relocation will be necessary.
Good point, Natalie,
Also the application of NIST guidance by agencies can result in different security solutions which are equally acceptable and meet the OMB definition of adequate security for federal information systems. According to the NIST document, auditors or evaluators assessing federal agencies must consider the intent of the security concepts and principles articulated within the particular guidance documents and how this guidance is applied in terms of specific mission responsibilities or operational environments.
One part that I found interesting in NIST SP 800-34r1 was the activation and notification phase, particularly the outage assessment procedure. When a disruption or outage occurs, the outage assessment team should first be notified as soon as possible in order to determine how the ISCP will be implemented. Some areas that need to be addressed are: the cause of the disruption, potential for additional damage, status of physical infrastructure, inventory and function status of equipment, type of damage to equipment or data, items that need to be replaced, and estimated restore time. This information will determine the impact of the disruption and the appropriate teams will be notified of how to move forward with the ISCP.
Sarah, activation and notification are paramount in the outage assessment procedure. I commented on another post that the “detection” phase is almost the most important step because if you never realize that you company has been hacked how will you ever fix the problems and stop it from happening again? I also think that there should be at least one section that outlines what should happen if humans are not able to complete their functions the entire process is essentially useless.
After reading the Contingency Planning Guide for Federal Information Systems, I noted the need for organizations to conduct a proper business impact analysis. Doing this can help the organization to identify, categorize and prioritize its information systems and components critical to its mission or business processes. According to this document, the BIA can help a firm to determine what impact loss of the system could have on the organization, and the system recovery time objective. Also, Information from the BIA can help an organization to know the type or frequency of backup, the need for redundancy, and the type of alternate site required to meet system recovery objectives.
Hello Ugo,
You have highlighted the importance of BIA very well. BIA process and documentation and process is one of the most important steps of preparing a contingency plan. It is useful in determining many factors of a contingency plan as mentioned by you. The most interesting aspect is the involvement of business process owners, who give their input while preparing BIA. As IT Auditors, we have to correlate their business needs which are in financial numbers to the usefulness of the IT infrastructure being utilized in contingency plan.
The portion of NIST 800-34 that was most eye opening to me came early but I believe is crucial to having a solid base and understanding the entire guideline. The section is on the different types of plans that an organization need to deploy to be the most ready for if and when things go wrong. The three types of plans outlined are Continuity, Contingency, and Incident Response plans. Continuity plans focus on maintaining mission critical functions that will keep the main heart of the business working. Contingency plans outline what to do with the information systems concerning the data which is the most valuable asset to a business. And Cyber Incident Response plans focus on how to deal with an attacker and an attack once it happens. If a form can master all three of these plans they will be set up to weather whichever storm comes at them .
The one key takeaway from NIST 800 34r1 for me is that how the recovery step is placed. To recover a system, we first need to identify the sequence of restoration, After identifying the sequence, we need to know the step and what are we going to do next. The sequence of the restoration should be based on the Business Impact Analysis and the step of restoration is as follow,
Obtaining authorization to access damaged facilities and/or geographic area
Notifying internal and external business partners associated with the system
Obtaining necessary office supplies and work space
Obtaining and installing necessary hardware components
Obtaining and loading backup media
Restoring critical operating system and application software
Restoring system data to a known state
Testing system functionality including security controls
Connecting system to network or other external systems
Operating alternate equipment successfully
Hi, peiran Liu
You listed the recovery sequence, which helped me better understand the operation of the emergency plan.But I think sometimes when you get access to a damaged facility, there’s a possibility that the data could be stolen.The offline server should be offline in a timely manner and the backup and recovery work of the standby server should be started.
NIST SP 800 34r1 mainly targets at Client/server systems and Telecommunications systems. According to this plan, the IT security personnel can arrange the appropriate IT security plan for the organization to ensure the continuity of the organization’s business. The company’s Contingency Plan depends on the elements of the company. Maximum Tolerable Downtime (MTD), the Recovery Time Objective (RTO) and Recovery Point Objective (RPO) and so on. A good plan also needs to be implemented by experienced people, and IT security personnel should always be familiar with the implementation priorities of the plan.