Information security as an ongoing effort

Editor's Notes

• #3: Learning Objectives: Upon completion of this material you should be able to: Understand the need for the ongoing maintenance of the information security program. Become familiar with recommended security management models. Understand key factors for monitoring the external and internal environment. Learn how planning and risk assessment tie into information security maintenance. Understand how vulnerability assessment and remediation tie into information security maintenance. Learn how to build readiness and review procedures into information security maintenance.
• #4: Learning Objectives: Upon completion of this material you should be able to: Understand the need for the ongoing maintenance of the information security program. Become familiar with recommended security management models. Understand key factors for monitoring the external and internal environment. Learn how planning and risk assessment tie into information security maintenance. Understand how vulnerability assessment and remediation tie into information security maintenance. Learn how to build readiness and review procedures into information security maintenance.
• #5: Introduction Upon the successful implementation and testing of a new and improved security profile, an organization might feel more confident of the level of protection it is providing for its information assets. It shouldn’t. By the time the organization has completed implementing the changes mandated by an upgraded security program, a good deal of time has passed. In that time, everything that is dynamic in the organization’s environment has changed. Some of the factors that are likely to shift in the information security environment are: New assets are acquired New vulnerabilities associated with the new or existing assets emerge Business priorities shift New partnerships are formed Old partnerships dissolve Organizational divestiture and acquisition occur Employees who are trained, educated, and made aware of the new policies, procedures, and technologies leave New personnel are hired possibly creating new vulnerabilities If the program is not adjusting adequately to change, it may be necessary to begin the cycle again. That decision depends on how much change has occurred and how well the organization and its program for information security maintenance can accommodate change. If an organization deals successfully with change and has created procedures and systems that can flex with the environment, the security program can probably continue to adapt successfully. The CISO determines whether the information security group can adapt adequately and maintain the information security profile of the organization or whether the macroscopic process of the SecSDLC must start anew to redevelop a fundamentally new information security profile. It is less expensive and more effective when an information security program is designed and implemented to deal with change. It is more expensive to reengineer the information security profile again and again.
• #6: Introduction If the program is not adjusting adequately to change, it may be necessary to begin the cycle again. That decision depends on how much change has occurred and how well the organization and its program for information security maintenance can accommodate change. If an organization deals successfully with change and has created procedures and systems that can flex with the environment, the security program can probably continue to adapt successfully. The CISO determines whether the information security group can adapt adequately and maintain the information security profile of the organization or whether the macroscopic process of the SecSDLC must start anew to redevelop a fundamentally new information security profile. It is less expensive and more effective when an information security program is designed and implemented to deal with change. It is more expensive to reengineer the information security profile again and again. If the program is not adjusting adequately to change, it may be necessary to begin the cycle again
• #7: The CISO determines whether the information security group can adapt adequately and maintain the information security profile of the organization or whether the macroscopic process of the SecSDLC must start anew to redevelop a fundamentally new information security profile. It is less expensive and more effective when an information security program is designed and implemented to deal with change. It is more expensive to reengineer the information security profile again and again.
• #9: Managing For Change Once an organization has improved the security posture of the organization, the security group must turn its attention to the maintenance of security readiness. To do so, information security must constantly monitor the threats, assets, and vulnerabilities. As the organization continues to function, the team constantly monitors its systems and the environments in which it operates. The team also reviews external information to stay on top of the latest general and specific threats to its information security.
• #10: Security Management Models To assist the information security community to manage and operate the ongoing security program, a management model must be adopted. In general, management models are frameworks that structure the tasks of managing a particular set of activities or business functions.
• #11: The ISO Model The ISO management model is a five-layer approach that provides structure to the administration and management of networks and systems. The core ISO model addresses management and operation thorough five topics: Fault management Configuration and name management Accounting management Performance management Security management
• #12: The ISO-based Security Management Model The five areas of the ISO model are transformed into the five areas of security management as follows: Fault management Configuration and change management Accounting and auditing management Performance management Security program management
• #13: Fault Management In the ISO model, fault management is the process of identifying, tracking, diagnosing, and resolving faults in the system. As information security involves systems, based both on people and technology, fault management also applies to people and technology. Fault management of information security involves identifying faults in the applied information security profile and then addressing them through remediation.
• #14: Vulnerability assessment involves the physical and logical assessment of the vulnerabilities present in information systems. This is most often accomplished with penetration testing. Penetration testing involves security personnel simulating or performing specific and controlled attacks to compromise or disrupt their own systems by exploiting documented vulnerabilities. InfoSec administrators who have not looked at their systems through the eyes of an attacker are failing to maintain readiness. The best procedures and tools to use in penetration testing and other vulnerability assessments are the procedures and tools of the hacker community.
• #15: Fortunately, many intrusion detection systems detect the signatures of these tools and can alert information security management of their use. As a security professional, you should incorporate these tools into your own toolbox of software, to examine your systems and test your security. Ethereal Nessus NMAP Sam Spade Snort
• #16: User problems can be created or influenced by a security program. Modifications to firewalls, implementations of IDS rules, or new systems policies in the network may directly impact how users interact with the systems. Proper user training and ongoing awareness campaigns can reduce problems; however, they are never completely eliminated.
• #17: Another aspect of fault management is the monitoring and resolution of user complaints. Help desk personnel must be trained to recognize a security problem as distinct from other system problems. As the help desk personnel screen problems, they track the activities for resolving the complaint in a help desk information system. One key advantage to formal help desk software is the ability to create and develop a knowledge base of common problems and solutions. This knowledge base can be searched when a user problem comes up, speeding up the process of resolving the complaint when it replicates a problem that has already been resolved. This knowledge base can also generate statistics on the frequency of problems by type, by user, or by application, and can detect trends and patterns in the data. The tracking of trouble tickets includes tracking problem resolution.
• #18: Configuration and Change Mgmt Configuration management is the administration of the configuration of the components of the security program. Change management is the administration of changes in the strategy, operation, or components of the information security program. Both configuration and change management administration involve non-technical as well as technical changes. Non-technical changes impact procedures and people. Technical changes impact the technology implemented to support security efforts in the hardware, software, and data components.
• #19: Non-technical Change Mgmt When implementing changes to the information security program, the organization may need to implement a number of new policies and procedures. The documents that result from these efforts should be changed when they are insufficient, outdated, or inaccurate. As a result, the document manager should maintain a master copy of each document, record and archive revisions made, and keep copies of the revisions, along with editorial comments on what was added, removed, or modified.
• #20: Non-technical Change Mgmt As mentioned in earlier, policy revisions are not considered implemented and enforceable, until they have been disseminated, read, understood, and agreed to. Modern, Web-based software is available to make the creation, modification, dissemination, and agreement documentation processes more manageable.
• #24: Technical Configuration and Change Management. Just as documents have version numbers, revision dates, and requirements to monitor and administer change, so do technical components. Configuration item: A hardware or software item that is to be modified and revised throughout its life cycle Version: The recorded state of a particular revision of a software or hardware configuration item. These are often noted as the version number in the form M.N.b. Major release: A significant revision of the version from its previous state – (M) Minor release (update or patch): A minor revision of the version from its previous state – (N.b) Build: A snapshot of a particular version of software assembled (or linked) from its various component modules Build list: A list of the versions of components that comprise a build is called a build list Configuration: A configuration is a collection of components that make up a configuration item Revision date: The date associated with a particular version or build Software library: A collection of configuration items that is usually controlled and that developers use to construct revisions and to issue new configuration items Procedures associated with configuration mgmt. 1.Configuration identification: The identification and documentation of the various components, implementation, and states of configuration items 2.Configuration control: The administration of changes to the configuration items and the issuance of versions 3.Configuration status accounting: The tracking and recording of the implementation of changes to configuration items 4.Configuration audit: Auditing and controlling the overall configuration management program Configuration control is usually only performed by an entity that actually develops its own versions of configuration items.
• #25: Accounting and Auditing Management Chargeback accounting enables organizations to internally charge their departments for system use. While chargebacks for CPU cycle time are seldom used today, certain kinds of resource usage are commonly tracked, such as resources on a computing, or charges are made on a human effort-hour basis. Accounting management involves the monitoring of the use of a particular component of a system. With accounting management you begin to determine optimal points of systems use as indicators for upgrade and improvement. In this context, auditing is the process of reviewing the use of a system, not to check performance, but to determine misuse or malfeasance. Most computer-based systems used in security can create logs of their activity. The management of systems logs in large organizations is a complex process. Fortunately, automated tools can consolidate various systems logs, perform comparative analysis, and detect common occurrences or behavior that is of interest. Many vendors offer log consolidation and analysis features.
• #26: Performance Management Because many information security technical controls are implemented on common IT processors, they are affected by the same factors as most computer-based technologies. It is therefore important to monitor the performance of security systems and their underlying IT infrastructure to determine if they are working effectively. Some common system and network metrics used in performance management are also applicable in security, especially when the components being managed are associated with the ebb and flow of network traffic. To evaluate the performance of a security system, the administrators must establish performance baselines within the system. In this context, a performance baseline is an expected level of performance against which all subsequent levels of performance are compared. Organizations must establish baselines for a number of different criteria and for various periods of time. To accomplish this effectively, the organization must monitor all possible variables, collecting and archiving performance baseline data, and then analyzing it.
• #27: Security Program Management Once an information security program is functional, it must be operated and managed. The ISO five-area framework that is currently being discussed is designed to support the structuring of a management model; however, it focuses on ensuring that various areas are addressed, rather than guiding the actual conduct of management. The British Standard BS 7799 contains two standards that are designed to assist in this effort. The second part is the BS 7799 (Part 2) specifies requirements for establishing, implementing, and documenting an information security management system (ISMS). Part 2 of the BS 7799 document introduces a process model with the steps of Plan-do-check-act. Plan: by performing a risk analysis of the vulnerabilities faced by the organization Do: by applying internal controls to manage risk Check: by undertaking periodic and frequent review to verify effectiveness Act: by using planned incident response plans as necessary
• #28: The Maintenance Model A maintenance model is intended to complement the chosen management model and focus organizational effort on maintenance. This figure diagrams a full maintenance program and forms a framework for the discussion of maintenance that follows. External monitoring Internal monitoring Planning and risk assessment Vulnerability assessment and remediation Readiness and review
• #30: Monitoring The External Environment The objective of the external monitoring domain within the maintenance model is to provide the early awareness of new and emerging threats, threat agents, vulnerabilities, and attacks that is needed to mount an effective and timely defense. External monitoring entails collecting intelligence from data sources, and then giving that intelligence context and meaning for use by decision makers within the organization.
• #32: Data Sources Acquiring data about threats, threat agent, vulnerabilities, and attacks is not difficult. There are many sources and few costs associated with gathering the raw intelligence. What is challenging and can be expensive is turning this flood of good and timely data into information that decision makers can use. External intelligence can come from three classes of sources: Vendors CERT organizations Public network sources Regardless of how the organization collects external monitoring data, the CISO evaluates the actions and personnel needed to act on the information. The responsibility for establishing a viable external monitoring program extends to: Creating documented and repeatable procedures Providing proper training to primary and backup staff assigned to perform the monitoring tasks Equipping assigned staff with proper access and tools to perform the monitoring function Designing criteria and cultivating expertise among the monitoring analysts, so that they can perform analytic steps to cull meaningful summaries and actionable alerts from the vast flow of raw intelligence Developing suitable communications methods for moving weighted external intelligence to designated internal decision makers in all three communities Integrating the Incident Response Plan with the results of the external monitoring process for appropriate, timely responses
• #33: Data Sources Acquiring data about threats, threat agent, vulnerabilities, and attacks is not difficult. There are many sources and few costs associated with gathering the raw intelligence. What is challenging and can be expensive is turning this flood of good and timely data into information that decision makers can use. External intelligence can come from three classes of sources: Vendors CERT organizations Public network sources Regardless of how the organization collects external monitoring data, the CISO evaluates the actions and personnel needed to act on the information. The responsibility for establishing a viable external monitoring program extends to: Creating documented and repeatable procedures Providing proper training to primary and backup staff assigned to perform the monitoring tasks Equipping assigned staff with proper access and tools to perform the monitoring function Designing criteria and cultivating expertise among the monitoring analysts, so that they can perform analytic steps to cull meaningful summaries and actionable alerts from the vast flow of raw intelligence Developing suitable communications methods for moving weighted external intelligence to designated internal decision makers in all three communities Integrating the Incident Response Plan with the results of the external monitoring process for appropriate, timely responses
• #34: Monitoring, Escalation, and Incident Response The basic function of the external monitoring process is to monitor activity, report results, and escalate warnings. The optimum approach for escalation is to rely on a thorough integration into the planning and process steps of the IRP . The monitoring process has three primary deliverables: Specific warning bulletins issued when developing threats and specific attacks pose a measurable risk to the organization. Periodic summaries of external information. Detailed intelligence on the highest risk warnings.
• #35: Data Collection and Management Over time, the external monitoring processes should capture knowledge about the external environment in a format that can be referenced both across the organization as threats emerge and for historical use. In the final analysis, external monitoring collects raw intelligence, filters it for relevance to the organizations, assigns it a relative risk impact, and communicates these findings to the decision makers in time to make a difference.
• #36: Monitoring The Internal Environment It is just as important to monitor the external environment as the internal environment, that is the internal computing environment. The primary goal of the internal monitoring domain is to maintain an informed awareness of the state of all of the organization’s networks, information systems, and information security defenses. Building and maintaining an inventory of network devices and channels, IT infrastructure and applications, and information security infrastructure elements Active participation in, or leadership of, the IT governance process within the organization to integrate the inevitable changes found in all network, IT, and information security programs Real-time monitoring of IT activity using intrusion detection systems to detect and initiate responses to specific actions or trends of events that introduce risk to the organization’s assets Periodic monitoring of the internal state of the organization’s networks and systems. This recursive review of the network and system devices that are inline at any given moment and any changes to the services offered on the network is needed to maintain awareness of new and emerging threats. This can be accomplished through automated difference detection methods that identify variances introduced to the network or system hardware and software.
• #38: Network Characterization and Inventory Each organization should have a carefully planned and fully populated inventory for all network devices, communication channels, and computing devices. The process of collecting this information can be called characterization, which is the systematic collection of the characteristics of the network and computer devices present in the environment. Once the characteristics have been identified, they must be carefully organized and stored using a mechanism, manual or automated, that allows timely retrieval and rapid integration of disparate facts.
• #39: The Role of IT Governance The primary value of active engagement in an organization-wide IT governance process is the increased awareness of the impact of change. This awareness must be translated into a description of the risk that is caused by the change. Such a description is developed in the planning and risk assessment domain of operational risk assessment. Awareness of change that flows from IT governance comes from two primary parts of the IT governance process: Architecture review boards: Many organizations have a group designated for the managed technology planning, review, and approval process that coordinates the acquisition and adoption of new technologies. The group directs the orderly introduction of change in information technology across the organization. IT change control process: Most organizations of appreciable size have implemented one or more mechanisms to control change in the network, IT infrastructure, and IT applications.
• #40: Making Intrusion Detection Systems Work To be effective, IDS must be integrated into the maintenance process. An endless flow of alert messages makes little difference to the effectiveness of the information security program. After all, the IDS is reporting events that have already occurred. The most important value of the raw intelligence provided by the IDS is to prevent risk in the future. Whether the organization has outsourced IDS monitoring, staffs IDS monitoring 24 x 7, staffs IDS monitoring 8 x 5, or merely ignores the real-time alerts from IDS, the log files from the IDS engines can be mined to add information to the internal monitoring knowledge base. Analyzing attack signatures for unsuccessful system attacks can identify weaknesses in various security efforts. One approach that has achieved good results is to perform combinations of manual and automated difference analysis to identify changes to the internal environment.
• #41: Planning And Risk Assessment The primary objective of the planning and risk assessment domain is to keep an eye on the entire information security program. This is done in part by identifying and planning ongoing information security activities that further reduce risk. Also, the risk assessment group identifies and documents risks introduced by both IT projects and information security projects. Further, it identifies and documents risks that may be latent in the present environment.
• #42: The primary outcomes from this domain are: Establishing a formal information security program review process that complements and supports both the IT planning process and strategic planning processes Instituting formal project identification, selection, planning and management processes for information security follow-on activities that augment the current program Coordinating with IT project teams to introduce risk assessment and review for all IT projects, so that risks introduced from the introduction of IT projects are identified, documented, and factored into projects decisions. Integrating a mindset of risk assessment across the organization to encourage the performance of risk assessment activities when any technology system is implemented or modified
• #44: Information Security Program Planning and Review Periodic review of an ongoing information security program coupled with planning for enhancements and extensions is a recommended practice for each organization. The strategic planning process should examine the IT needs of the future organization and the impact those needs have on information security. A recommended approach takes advantage of the fact that most organizations have annual capital budget planning cycles, and manage security projects as part of that process.
• #45: InfoSec Improvement through Ongoing Projects The projects follow the SecSDLC model for development and implementation, if the organization does not have a SDLC methodology that would supercede its use. After the program is in place, large projects should broken into smaller projects for several reasons: Smaller projects tend to have more manageable impacts to the networks and users Larger projects tend to complicate the change control process in the implementation phase Short planning, development, & implementation schedules reduce uncertainty for IT planners and financial sponsors Most large projects can easily be assembled from smaller projects, giving more opportunities to change direction and gain flexibility as events occur and circumstances change
• #46: Security Risk Assessments A key component in the engine that drives change in the information security program is a relatively straightforward process called an information security operational risk assessment. The RA is a method to identify and document the risk that a project, process, or action introduces to the organization and, perhaps offer suggestions for controls that can reduce that risk. The information security group often finds itself in the business of coordinating the preparation of many different types of RA documents including: Network connectivity, Dialed modem, Business partner, Application, Vulnerability, Privacy, Acquisition or divesture, Other RAs
• #47: Vulnerability Assessment And Remediation The primary goal of the vulnerability assessment and remediation domain is the identification of specific, documented vulnerabilities and their timely remediation. This is accomplished by: Using vulnerability assessment procedures which are documented to safely collect intelligence about network, platforms, dial-in modems, and wireless network systems Documenting background information and providing tested remediation procedures for the reported vulnerabilities Tracking, communicating, reporting and escalating to management the itemized facts about the discovered vulnerabilities and the success or failure of the organization to remediate them
• #49: Vulnerability Assessment The process of identifying and documenting specific and provable flaws in the organization’s information asset environment is called vulnerability assessment. While the exact procedures can vary, the following five vulnerability assessment processes can serve many organizations as they attempt to balance the intrusiveness of vulnerability assessment with the need for a stable and productive production environment.
• #50: Internet Vulnerability Assessment The Internet vulnerability assessment process is designed to find and document the vulnerabilities that may be present in the public-facing network of the organization. Since attackers from this direction take advantage of any loophole or flaw, this assessment is usually performed against all public-facing addresses, using every possible penetration testing approach. The steps in the process are: Planning, scheduling and notification of the penetration testing: Large organizations often take an entire month to perform the data collection phase using nights and weekends and avoiding change control blackout windows. The various technical support communities are given the detailed plan, so that they know when each device is scheduled for testing and what tests are used. Target selection: Working from the network characterization database elements that are stored in the risk, threat, and attack database, the penetration targets are selected. Test selection: Using the external monitoring intelligence generated previously, the test engine is configured for the tests to be performed. Scanning: The penetration test engine is unleashed at the scheduled time using the planned target list and test selection. The results of the entire test run are logged to text log files for analysis.This should be a monitored process, so that if an invasive penetration test causes a disruption to a targeted system, the outage can be reported immediately for recovery. Analysis: A knowledgeable and experienced vulnerability analyst screens the test results for the vulnerabilities logged during scanning. Record keeping: Record the details of the documented vulnerability in the vulnerability database, identifying the logical and physical characteristics and assigning a response risk level to the vulnerability to differentiate the truly urgent from the merely critical.
• #51: Intranet Vulnerability Assessment The intranet vulnerability assessment process is designed to find and document selected vulnerabilities that are likely to be present on the internal network of the organization. Attackers from this direction are often internal members of the organization, affiliates of business partners, or automated attack vectors (such as viruses and worms). This assessment is usually performed against selected critical internal devices with a known, high value by using selective penetration testing. The steps in the process are almost identical to the steps in the Internet vulnerability assessment, except as noted. Planning, scheduling, and notification of the penetration testing: There will be substantially more systems to assess. Often intranet administrators prefer penetration testing be performed during working hours. Target selection: At first, the penetration test scanning and analysis should focus on testing only the highest value, most critical systems. As the configuration of these systems is improved, and fewer candidate vulnerabilities are found in the scanning step, the target list can be expanded. Test selection: The selection of the tests to be performed usually evolves over time to match the evolution of the threat environment. Most organizations focus their intranet scanning efforts on a few, very critical vulnerabilities at first, and then expand the test pool to include more scripts. Scanning: Just as in Internet scanning, the process should be monitored, so that if an invasive penetration test causes disruption, it can be reported for repair. Analysis: Follows the same three steps: classify, validate and document. Record keeping: Identical to the one followed in Internet vulnerability analysis.
• #52: Platform Security Validation The platform security validation (PSV) process is designed to find and document the vulnerabilities that may be present because of misconfigured systems in use within the organization. These misconfigured systems fail to comply with company policy or standards as adopted by the IT governance groups and communicated in the information security and awareness program. Fortunately automated measurement systems are available to help with the intensive process of validating the compliance of platform configuration with policy.
• #53: Wireless Vulnerability Assessment The wireless vulnerability assessment process is designed to find and document the vulnerabilities that may be present in the wireless local area networks of the organization. Since attackers from this direction are likely to take advantage of any loophole or flaw, this assessment is usually performed against all publicly accessible areas using every possible wireless penetration testing approach.
• #54: Modem Vulnerability Assessment The modem vulnerability assessment process is designed to find and document any vulnerability that is present on dialup modems connected to the organization’s networks. Since attackers from this direction take advantage of any loophole or flaw, this assessment is usually performed against all telephone numbers owned by the organization, using every possible penetration testing approach. One of the elements of this process, using scripted dialing attacks against a pool of phone numbers, is often called war-dialing.
• #55: Documenting Vulnerabilities The vulnerability database, like the risk, threat, and attack database, both stores and tracks information. It should provide details about the vulnerability being reported as well as linkage to the information assets characterized in the risk, threat, and attack database. While this can be manual data storage, the low-cost and ease of use of relational databases makes them a more realistic choice. The data stored in the vulnerability database should include: A unique vulnerability ID number for reporting and tracking remediation actions Linkage to the risk, threat, and attack database based on the physical information asset underlying the vulnerability. Vulnerability details usually based on the test script used for the scanning step of the process. Dates and times of notification and remediation activities Current status of the vulnerability instance Comments Other fields as needed to The vulnerability database is an essential part of effective remediation to avoid losing track of specific vulnerability instances as they are reported and remediated.
• #56: Documenting Vulnerabilities The vulnerability database, like the risk, threat, and attack database, both stores and tracks information. It should provide details about the vulnerability being reported as well as linkage to the information assets characterized in the risk, threat, and attack database. While this can be manual data storage, the low-cost and ease of use of relational databases makes them a more realistic choice. The data stored in the vulnerability database should include: A unique vulnerability ID number for reporting and tracking remediation actions Linkage to the risk, threat, and attack database based on the physical information asset underlying the vulnerability. Vulnerability details usually based on the test script used for the scanning step of the process. Dates and times of notification and remediation activities Current status of the vulnerability instance Comments Other fields as needed to The vulnerability database is an essential part of effective remediation to avoid losing track of specific vulnerability instances as they are reported and remediated.
• #57: Remediating Vulnerabilities The objective of remediation is to repair the flaw causing a vulnerability instance or remove the risk from the vulnerability. As a last resort, informed decision makers with the proper authority can accept the risk. When approaching the remediation process, it is important to recognize that building relationships with those who control the information assets is the key to success. Success depends on the organization adopting a team approach to remediation, in place of cross-organizational push and pull.
• #58: Acceptance of Risk In some instances risk must simply be acknowledged as part of organization’s business process. The information security professional must assure the general management community that the decisions made to assume risk for the organization are made by properly informed decision makers. These decision makers must have the proper level of authority to assume the risk. In the final analysis, the information security group must make sure the right people make risk assumption decisions with complete knowledge of the impact of the decision balanced against the cost of the possible security controls.
• #59: Threat Removal In some circumstances, threats can be removed without repairing the vulnerability. The vulnerability can no longer be exploited, and the risk has been removed. Other vulnerabilities may be amenable to other controls that allow an inexpensive repair and still remove the risk from the situation.
• #60: Vulnerability Repair The optimum solution in most cases is to repair the vulnerability. Applying patch software or implementing a work around to the vulnerability often accomplishes this. In some cases, simply disabling the service removes the vulnerability. In other cases simple remedies are possible. Of course, a common remedy remains the application of a software patch to make the system function in the expected fashion and to remove the vulnerability.
• #61: Readiness And Review The primary goal of the readiness and review domain is to keep the information security program functioning as designed and continuously improving over time. This is accomplished by: Policy review: Sound policy needs to be reviewed and refreshed from time to time to provide a current foundation for the information security program. Readiness review: Major planning components should be reviewed on a periodic basis to ensure they are current, accurate, and appropriate. Rehearsals: When possible, major plan elements should be rehearsed. Policy review is the primary initiator of the readiness and review domain. As policy is revised or current policy is confirmed, the various planning elements are reviewed for compliance, the information security program is reviewed, and rehearsals are held to make sure all participants are capable of responding as needed.
• #63: Epilogue When CISOs can’t sleep, what is keeping them awake? CISOs find themselves counting sheep because of the maintenance issues covered in this chapter. A solid maintenance program can complement every information security program, and over time can even strengthen a weak program