STRATEGY RESOURCES

The development of a strategy will require a detailed understanding of the resources available to implement it. There will be a number of ways that any particular objec-tive resulting from the gap analysis discussed in Chapter 9, Section 9.3 can be ad-dressed. Note: the “gaps” identified in the analysis constitutes unmanaged risks that the strategy will be designed to address using the available resources within the ex-isting constraints.

Resources are any activity, process, asset, technology, individual, policy, and so on that can be utilized in some manner to move toward addressing a gap (i.e., miti-gating a risk) that serves to implement the strategy.

As used here, resources can provide information or be a part of a solution to a problem. Their absence or ineffectiveness may also constitute a risk or threat that must be addressed by the strategy. To “normalize” the understanding of a number of processes and elements of security that suffer from a variety of definitions and differences in understanding globally, each of the identified resources are described in relation to their relevance to a security strategy.

Resources available to implement a strategy will typically include:

앫 Policies. The high-level statement of management intent, expectations, and direction; can be considered to be the “constitution” of security governance.

앫 Standards. Set the allowable boundaries for people, processes, procedures, and technologies necessary to meet the intent of policies; Can be considered the “law” of security governance

앫 Procedures. Procedures are the detailed steps necessary to accomplish a par-ticular task and must conform to the standards

앫 Guidelines. For the purposes of information security, guidelines are helpful narratives in executing procedures including suggestions, tools, and so on.

앫 Architecture(s). Defines the relationships between objects, the information flows between them, and the inputs and outputs, as well as other aspects such as schemas, specifications, metrics, test points, and so on. They can range from contextual and conceptual, to logical, functional, physical, and opera-tional.

앫 Controls—physical, technical, procedural. Controls are any regulatory ele-ment, whether process, procedure, technology, or physical component, for ex-ample, access controls, procedural controls, and firewalls.

앫 Countermeasures. Countermeasures directly target mitigation of any threat or vulnerability; can be considered a targeted control.

앫 Layered defenses. Layered defenses are the practice of adding subsequent or sequential controls in an effort to ensure that failure of one control will not compromise the entire system.

앫 Technologies. Numerous technology controls are available to address grow-ing threats and losses. These will generally be preventive, detective, correc-tive, or compensatory in nature, or some combination of these. For example, a firewall can both be preventive and detective, as well as possibly compen-satory.

앫 Personnel security. People continue to be the greatest risk to security through overwork, lack of training, carelessness, indifference, accident, mis-takes, and, occasionally, malice. An effective strategy will consider the hu-man element as central to implementation and secure operations.

앫 Organizational structure. The structure of the organization can be benefi-cial to effective security strategy development or a monumental obstacle.

Considerations for strategy development must include organizational struc-tures, reporting relationships, real or potential conflicts between various

orga-nizational units, and whether it is a command and control structure or a flat, decentralized structure.

앫 Roles and responsibilities. The extent to which roles and responsibilities are clear and well defined must be considered in strategy development and will have a significant impact on implementation and operation of a security pro-gram.

앫 Skills. Strategies that utilize existing skills and proficiencies will be easier to implement and must be assessed in the planning phase.

앫 Training. Major changes to operations as a result of implementing security governance will require either skills acquisition or training or both. Training requirements must be considered in the development of a security governance strategy and the development of controls operation and configuration.

앫 Awareness and education. User awareness and education often provides the greatest return on investment in terms of security. Plans should include provi-sions for ongoing security awareness using various methods such as comput-er-based training and security briefings.

앫 Audits. Audits are a normal fact of life for most organizations but are often not utilized to best effect. The strategy should consider how to coordinate with auditors and utilize audits as a force for needed changes in overall gover-nance.

앫 Compliance enforcement. Compliance enforcement is often one of the most problematic elements of security governance and due consideration must be given in the strategy to how policies and standards can be enforced both from a technical perspective and the more difficult physical and procedural stand-point. Effective policy and standards compliance is essential to a successful security program.

앫 Threat analysis. Ongoing evaluation of existing and emerging threats must be planned for in strategy development.

앫 Vulnerability analysis. Technical vulnerability scanning is standard proce-dure in most organizations but physical and operational vulnerabilities are of-ten not tested and are ignored. The strategy should consider how all these ele-ments will be addressed.

앫 Risk assessment. Risk assessment must be a standard practice at the strate-gic, management, and operational levels, and must to cover entire business processes from input to output in addition to relevant external factors. Poli-cies and standards must provide the requirements for appropriate assessment of risk on an ongoing basis.

앫 Business impact assessment. Business impact assessments (BIAs) are essen-tial for determining protection and recovery priorities, and should be a policy requirement defined in the strategy.

앫 Resource dependency analysis. Resource dependency analysis can be an al-ternative to BIAs in determining protection and recovery priorities. It is based on analyzing the resources required for critical business processes.

앫 Outsourced security providers. Outsourced security providers are a viable option for implementing a strategy but carry some attendant risk that must be addressed. The strategy must consider the options for outsourcing as a viable approach to program implementation.

앫 Other organizational support and assurance providers. The strategy must consider how to optimize integration of a variety of other assurance providers in the organization to maximize security cost effectiveness.

앫 Facilities. Facilities management must be considered in a security program strategy given the critical nature of physical and environmental impact on in-formation security effectiveness.

앫 Environmental security. External environmental threats and risks must be addressed by the security program strategy.

앫 Metrics and monitoring. Effective governance is not possible without ade-quate metrics and suitable monitoring. All key controls must be designed with metrics in mind to ensure their continued operation. Monitoring of key processes and controls is also essential and the strategy must address how this will be accomplished.

10.3.1 Utilizing Architecture for Strategy Development

If major initiatives are anticipated to achieve the defined governance objectives, it is evident that there will be many moving parts that must be considered in terms of dealing with particular aspects as well as the relationship between the elements. It may be beneficial to consider a security architecture to formally address all the re-quired elements as well as their interrelationships and ability to achieve the desired outcomes. If we consider the SABSA approach discussed in Chapter 8, populating each of the 36 elements in the matrix repeated in Figure 10.1 is likely to provide a high level of assurance that this has been achieved.

Each of the resources listed (and perhaps others) will be utilized in one or more of the 36 elements. For example, Policies are in the Motivation column and the Logical layer, technology will populate several of both the Physical and Component layers, and organizational structure will be in the Contextual layer and People col-umn.

10.3.2 Using CobiT for Strategy Development

Mapping available resources to address gaps in the CobiT control objectives is rela-tively straightforward, as shown in the following examples.

In Planning and Organization (PO),

PO1—Define a Strategic IT Plan and Direction. This can be addressed from resources on the list by architectures, policies, organizational structure, and, of course, by the resource we are developing here, strategy.

95

Figure 10.1.SABSA Matrix

Assets (What)Motivation (Why)Process (How)People (Who)Location (Where)Time (When) ContextualThe BusinessBusiness Risk ModelBusiness Process ModelBusiness Organization RelationshipsBusiness GeographyBusiness Time Dependencies ConceptualBusiness Attributes ProfileControl ObjectivesSecurity Strategies and Architectural LayeringSecurity Entity Model and Trust FrameworkSecurity Domain Model

Security-Related Lifetimes and Deadlines LogicalBusiness Information ModelSecurity PoliciesSecurity ServicesEntity Schema and Privilege Profiles

Security Domain Definitions and Associations

Security Processing Cycle PhysicalBusiness Data ModelSecurity Rules, Practices, and ProceduresSecurity MechanismsUsers, Applications, and the User InterfacePlatform and Network InfrastructureControl Structure Execution ComponentDetailed Data StructuresSecurity StandardsSecurity Products and ToolsIdentities, Functions, Actions, and ACLs

Processes, Nodes, Addresses, and Protocols Security Step Timing and Sequencing OperationalAssurance of Operational ContinuityOperational Risk Management

Security Service Management and Support Application and User Management and Support Security of Sites, Networks, and Platforms Security Operations Schedule

PO4—Define the IT Processes, Organization, and Relationships. Policies, standards, organizational structure, and roles and responsibilities will be re-sources for PO4.

PO9—Assess and Manage IT Risks. Threat and vulnerability analysis and Risk and impact assessment from our resources list address this requirement.

10.3.3 Using CMM for Strategy Development

Using the CMM 4 Managed and Measurable approach, the available resources must be considered for each of the gaps identified in the 15 statements.

For example, assume that we must address “2—Information security risk man-agement is a defined manman-agement function with senior-level responsibility.” If this is not the case, the resources that would be relevant to addressing this issue can be Policies and, possibly, Standards, Organizational Structure, and Roles and Respon-sibilities.

Now consider “3—Senior management and information security management have determined the levels of risk that the organization will tolerate and have stan-dard measures for risk/return ratios.”

If this is not the case, resources to address this issue can include Policy and Stan-dards development setting forth the requirement, risk, impact assessment and analy-sis, development of continuity, disaster plans and the attendant recovery time objec-tives, and the requirement for business case development, including financial anlysis as a project requirement standard.

Each of the remaining 12 CMM attributes and characteristics must be evaluated in a similar manner to determine what resources are available to address the gaps.