Chapter 3 —Information Security Program Development and

Management

2
Chapter 3 - Information Security Program Development and
Management

This chapter reviews the diverse areas of knowledge needed to develop and
manage an information security program.

3
Information Security Program Management Overview

4
3.1 Information Security Program Management Overview

5
3.1 Information Security Program Management Overview

 The goal of an information security program is to implement the strategy

and achieve the defined objectives.

 The purpose of the security program development is to develop the

processes and projects that close the gap between the current state and
those objectives.

 Information security program management includes directing, overseeing

and monitoring activities and resources related to information security in
support of organizational objectives.

 Information security program management serves to protect information

assets, satisfy regulatory obligations, and minimize potential legal and
liability exposures.

6
3.1 Information Security Program Management Overview

 The security program is the process by which the organization’s security

systems are designed, engineered, built, deployed, modified, managed and
maintained as well as removed from service.

 The information security manager is mainly responsible for the

information security program.

 His / her responsibilities covers a broad area, and requires substantial

expertise and broad technical and managerial skills.

 In addition to understanding security concepts and technologies,

information security managers will increasingly need to gain expertise in a
range of management functions such as budgeting, planning, business case
development, recruiting and other personnel related functions.

7
3.1 Information Security Program Management Overview

Essential Elements of an Information Security Program

 There are 3 elements essential to ensure successful security program
design, implementation and ongoing management:

1. The program must be the execution of a well-developed information

security strategy closely aligned with and supporting organizational
objectives.

2. The program must be in cooperation and support from management

and stakeholders.

3. Effective metrics must be developed for the program to provide the

feedback necessary to guide program execution to achieve the defined
outcomes.

8
3.1 Information Security Program Management Overview

Outcomes of information security program management

 An acceptable level of the following 6 outcomes should be considered the
basis for developing the objectives of an effective information security
program:
 Strategic alignment.
 Risk management.
 Value delivery.
 Resource management.
 Assurance process integration.
 Performance measurement.

 The information security manager should consider the development of a

full security architecture to ensure that the goals and desired outcomes are
realized.

9
3.1 Information Security Program Management Overview

 If an enterprise architecture already exist, then a security architecture

should be incorporated into the existing enterprise architecture.

 The reality is that many organizations are not yet ready to undertake the
costs and efforts to implement information security governance.

 In these cases, the information security manager may need to “shortcut”

objectives development.

 This can be accomplished by utilizing a standard framework such as COBIT or

ISO/IEC 27001 in conjunction with a capability maturity model (CMM) scale
or ISO/IEC 15504 process assessment reference model used in COBIT 5.

10
3.1 Information Security Program Management Overview

Information security program objectives

 The objective of the information security program is to implement the
security strategy in the most cost-effective manner possible, while
maximizing support of business functions and minimizing operational
disruptions.

 Subsequently, the primary task will be turning the high-level strategy into
logical and physical reality through a series of projects and initiatives.

 The first step is to determine management objectives for information

security, develop key goal indicators (KGIs) that reflect those objectives, and
then develop ways to measure whether the program is heading in the right
direction to meet those objectives.

11
3.1 Information Security Program Management Overview

 There will be elements in the program that must be modified during program
design, development and ongoing administration. This can occur for a
variety of reasons, such as:
 changes in business requirements
 better solutions become available.
 unanticipated resistance by those affected by the changes.

 It is essential to determine the forces (drivers) that drive the business need
for the information security program, such as:
 The ever mounting requirements for regulatory compliance.
 Higher frequency and cost related to security incidents.
 Concerns over reputational damage.
 Growing commercial demands of Payment Card Industry (PCI) Data
Security Standard (DSS).

12
3.1 Information Security Program Management Overview
Concepts
 SDLCs
 Requirements development
 Specification development
 Control objectives
 Control design and development
 Control implementation and testing
 Control monitoring and metrics
 Architectures
 Documentation
 Quality assurance
 Project management
 Business case development
 Business process reengineering
 Budgeting, costing and financial issues
 Deployment and integration strategies
 Training needs assessments and approaches
 Communications
 Problem resolution
 Variance and noncompliance resolution
 Risk management
 Compliance monitoring and enforcement
 Personnel issues
Technology resources
 Firewalls
 Antivirus systems
 Security features inherent in networking devices (e.g., routers,
switches)
 Intrusion detection systems (IDSs), including host-based intrusion
detection systems (HIDSs), network intrusion detection systems
(NIDSs)
 Intrusion-prevention systems (IPSs)
 Cryptographic techniques (e.g., public key infrastructure [PKI],
Advanced Encryption Standard [AES], etc.)
 Digital signatures
 Smart cards
 Authentication and authorization mechanisms (one-time passwords
[OTPs], challenge-response, PKI certificates multifactor
authentication, biometrics)
 Wireless security methodologies
 Mobile computing
 Application security methodologies
 Remote access methodologies (virtual private network [VPNs], etc.)
 Web security techniques
 Log collection, analysis and correlation tools (i.e., Security
Information and Event Management [SIEM])
 Vulnerability scanning and penetration testing tools
 Data leak prevention methodologies (removable media security,
content filtering, etc.) and associated technologies
 Data integrity controls, e.g., backups, data snapshots, data
replication, RAID, SAN real-time replication, etc.
 Identity and access management systems
13
3.1 Information Security Program Management Overview

Concepts Technology resources

 Local area networks (LANs)
 Wide area networks (WANs)
 Backup and archiving approaches such as redundant array of
inexpensive disks (RAID), storage area networks (SANs)
 Internet and network protocols (TCP/IP, UDP, etc.)
 Operating Systems
 Network Routing concepts and protocols
 Databases
 Servers
 Enterprise architectures (two- and three-tier client servers,
messaging, etc.)
 Virtualization
 Cloud computing
 Web-related technologies and architectures

14
Enterprise Information Security Architecture

15
3.2 Enterprise Information Security Architecture

 Architecture can serve to define logical, physical and operational component

and process relationships.

 Information systems architecture addresses the design and construction of

computers, communications networks and business systems that are
required for the delivery of business services.

 Information systems architecture must take account of:

 The goals to be achieved through the systems.
 The environment in which the systems will be built and used.
 The technical capabilities of the people to construct and operate the
systems and their component subsystems.

 Architecture is a tool/mean to provide a framework to manage business

complexity successfully.

 Architecture also acts as a road map for a collection of smaller projects and
services that must be integrated into a single homogenous whole. 16
3.2 Enterprise Information Security Architecture
Sherwood Applied Business Security Architecture (SABSA)

 SABSA is a model for developing risk-driven enterprise information security

architectures and for delivering security infrastructure solutions that
support critical business initiatives.
 The model is layered, with the top layer being the business requirements
definition stage (Contextual Layer).

 At each lower layer a new level of detail is developed, going through the
definition of the conceptual architecture, logical services architecture,
physical infrastructure architecture

and finally at the lowest layer, the selection of technologies and products
(component architecture).

 Finally there is an operational security architecture, describing how security

service delivery is organized.

17
3.2 Enterprise Information Security Architecture
Sherwood Applied Business Security Architecture (SABSA)

18
3.2 Enterprise Information Security Architecture
Sherwood Applied Business Security Architecture (SABSA)

19
3.2 Enterprise Information Security Architecture

 For a detailed analysis of each of the 6 layers, a SABSA Matrix has been
developed that uses 6 questions for each layer (what, why, when, how,
where, and who?) as follows:
1. What are you trying to do at this layer?—The assets to be protected by
your security architecture.
2. Why are you doing it?—The motivation for wanting to apply security.
3. How are you trying to do it?—The functions needed to achieve
security at this layer.
4. Who is involved?—The people and organizational aspects of security at
this layer.
5. Where are you doing it?—The locations where you apply your security,
relevant to this layer.
6. When are you doing it?—The time-related aspects of security relevant
to this layer.

20
3.2 Enterprise Information Security Architecture

1. The Business View – Contextual Security Architecture:

 What? The business, its assets to be protected (brand, reputation, etc.)
and the business needs for information security.

 Why? The business risks expressed in terms of business opportunities and

the threats to business assets. (enabling eBusiness, brand enhancement
and protection, fraud prevention, loss prevention, fulfilling legal
obligations, achieving business continuity, etc.).

21
3.2 Enterprise Information Security Architecture
 How? The business processes that require security (business interactions
and transactions, business communications, etc.).

 Who? The organizational aspects of business security (governance and

management structures, supply chain structures, outsourcing
relationships, strategic partnerships).

 Where? The business geography and locations.

 When? The business time-dependencies (business transaction lifetimes

and deadlines, just-in-time operations, time-to-market, etc.).

22
3.2 Enterprise Information Security Architecture
2. The Architect's View – Conceptual Security Architecture: (security concepts
and principles)
 What you want to protect in terms of Business Attributes (see next page).

 Why the protection is important, in terms of controls, derived from an

analysis of business risks.

 How you want to achieve the protection, in terms of high-level technical

and management security strategies mapped to the business processes.

 Who is involved in security management, in terms of roles and

responsibilities, including asset owners, users, customers, and service
providers.

 Where you want to achieve the protection in terms of a security domains

boundaries (both logical and physical).

 When is the protection relevant.

23
3.2 Enterprise Information Security Architecture

24
3.2 Enterprise Information Security Architecture
3. The Designer’s View – Logical Security Architecture: (logical security
services, and the logical flow of control and the relationships between these
logical elements)
 What? Business information that needs to be secured.

 Why? Security and risk management policy requirements.

 How? Logical security services (authentication, confidentiality protection,

integrity protection, system assurance, etc.)

 Who? Users, security administrators, auditors, etc. - and their inter-

relationships, authorized roles and privilege profiles.

 Where? Security domains and inter-domain relationships (logical security

domains, physical security domains).

 When? login, session management, etc.

25
3.2 Enterprise Information Security Architecture
4. The Builder’s View – Physical Security Architecture: (physical security
mechanisms and servers)
 What? Business data model and the security-related data structures
(tables, messages, certificates, etc.).

 Why? Physical practices, procedures and actions.

 How? Security mechanisms (encryption, access control, virus scanning,

etc.) and the physical applications, middleware and servers upon which
these mechanisms will be hosted.

 Who? The people dependency in the form of the human interface (screen
formats and user interactions) and the access control systems.

 Where? Security technology infrastructure - host platforms and networks

(physical layout of the hardware, software and communications lines).

 When? Timing and sequencing of processes and sessions.

26
3.2 Enterprise Information Security Architecture
4. The Tradesman’s View – Component Security Architecture: (hardware items,
software items, and interface specifications and standards)

 What? ICT components such as ICT products, including data repositories

and processors.

 Why? The risk management-related tools and products such as risk

analysis tools, risk registers, risk monitoring and reporting tools.

 How? Process tools and standards for process delivery - both hardware
and software.

 Who? Personnel management tools and products (identities, job

descriptions, roles, functions, actions and access control lists).

 Where? Processes, nodes, addresses, and protocols.

 When? time schedules, clocks, timers and interrupts.

27
3.2 Enterprise Information Security Architecture
4. The Facilities Manager’s View – Operational Security Architecture: (systems
operations and service management work)
 What? Service delivery management (assurance of operational continuity
and excellence of the business systems and information processing, and
maintaining the security of operational business data and information).

 Why? Operational risk management (risk assessment, risk monitoring and

reporting, and risk treatment so as to minimize operational failures and
disruptions).

 How? Process delivery management (management and support of

systems, applications and services, performing specialized security-related
operations such as user security administration, system security
administration, data back-ups, security monitoring, emergency response
procedures, etc.).

 Who? Personnel management (account provisioning and user support

management).
28
3.2 Enterprise Information Security Architecture
 Where? Management of the environment (management of buildings,
sites, platforms and networks).

 When? Management schedule.

29
3.2 Enterprise Information Security Architecture

30
Business Case Development

31
3.3 Business Case Development

 The purpose of a business case is to capture the reasoning for initiating a

project or task.

 The business case should include all the factors that affect the project’s
success or failure, including benefits, costs and risk.

 The benefits must be tangible and relevant to the organization.

 Particular attention must be given to the financial aspects of the proposal.

 The method of presentation should be consistent with the organization’s

usual approach - a well-structured written document or a slide presentation.

32
3.3 Business Case Development

 The format of the business case should include some or all of the following:
 Reference: Project name/reference, origins/background/current state.

 Context: Business objectives/opportunities, business strategic

alignment.

 Value Proposition: Desired business outcomes, business benefits,

quantified benefits value, costs/ROI, risk/costs of not proceeding,
project risk.

 Focus: Problem/solution scope, assumptions/constraints, options

identified/evaluated, size, scale and complexity assessment.

 Deliverables: Outcomes, deliverables and benefits planned;

organizational areas impacted (internally and externally); key
stakeholders.

33
3.3 Business Case Development

 Dependencies: Critical Success Factors (CSFs).

 Project metrics: KGIs, KPIs.

 Workload: Approach, phase/stage definitions.

 Required resources: Project leadership team, project governance team,

team resources, funding.

 Commitments: Project controls, review schedule, reporting processes,

deliverables schedule, financial budget/schedule.

34
3.3 Business Case Development

Business Case Evaluation

 Evaluation and review of a business case should include determining that:
 The investment has value and importance.

 The project will be properly managed.

 The enterprise has the capability to deliver the benefits.

 The enterprise’s dedicated resources are working on the highest value

opportunities.

 Projects with interdependencies are undertaken in the optimal

sequence.

35
3.3 Business Case Development

Program Budgeting
 Budgeting is an essential part of information security program management
and can have a significant impact on the program’s success.

 Budget elements of each project that should be considered include:

 Employee time.
 Contractor and consultant fees.
 Equipment (hardware, software) costs.
 Space requirements (data center rack space, etc.).
 Testing resources (personnel, system time, etc.).
 Creation of supporting documentation.
 Ongoing maintenance.
 Contingencies for unexpected costs.

36
3.3 Business Case Development

 It will be impossible to have a 100 % accurate budget, engaging the

appropriate values and skilled project managers is vital in arriving at a fairly
accurate estimate.

 It is important to keep in mind that some aspects of an information security

program are not entirely predictable and can incur unanticipated costs,
particularly in the area of incident response.

 Unanticipated costs are often the need for external resources to assist with a
security event that exceeds the skills or bandwidth of the organization’s staff
(such as forensic consultants).

 Unanticipated costs can be mitigated by using:

 historical data of incidents and remediation costs of previous security
events.
 industry statistics from peer organizations.

37
Outsourcing and Service Providers

38
3.4 Outsourcing and Service Providers

 The two types of outsourcing that an information security manager may be

required to deal with include third-party providers of security services and
outsourced IT or business processes.

 The information security manager is normally the owner for outsourced

security services, whereas other outsourced services are the responsibility of
the process owners.

 The risk posed by third parties connected to the organization’s internal

network can be substantial and must be carefully considered.

 Early engagement by the information security manager in outsourcing

decision is essential to ensure that security is not compromised for the sake
of cost.

39
3.4 Outsourcing and Service Providers

 A variety of risk as a result of outsourcing must be considered, including:

 Loss of essential skills.
 Lack of visibility into security processes.
 New access and other control risk.
 Viability of the third-party vendor.
 Complexity of incident management.
 Cultural and ethical differences.
 Unanticipated costs and service inadequacies.

 Vendor’s controls needs to be audited and monitored through the life of the
contract to ensure that security measures are not downgraded over time.

 This can be accomplished by independent audit or onsite visits at the third-

party facility.

 Privacy laws to protect a company’s data also needs to be considered,

especially in different business cultures.
40
Controls and Countermeasures

41
3.5 Controls and Countermeasures

 Controls are defined as the policies, procedures, practices, technologies and

organizational structures designed to provide reasonable assurance that
business objectives are achieved and that undesirable events are prevented
or detected and corrected.

 Controls are essentially any regulatory process, whether physical, technical or

procedural.

 The choice of controls can be based on a number of considerations, including

their effectiveness, cost or restrictions to business activities, and what the
optimal form of control is.

 Controls are one of the primary methods of managing information security

risk and is a major responsibility of information security management.

42
3.5 Controls and Countermeasures

 Security controls encompass the use of technical and nontechnical methods.

 Technical controls are safeguards that are incorporated into computer

hardware, software, or firmware (e.g., access control mechanisms,
identification and authentication mechanisms, encryption methods,
intrusion detection software).

 Nontechnical controls are management and operational controls such as

security policies; operational procedures; and personnel, physical, and
environmental security.

43
3.5 Controls and Countermeasures

General controls and application-level controls:

 General Controls: cover controls activities over organization-wide IT
infrastructure and operating environment and thus support the entire
organization in a centralized fashion. Examples:
 Access security controls over the applications, O/S, databases, network
and data centers.
 Change management controls.
 System/application acquisition, development and maintenance.
 Operational controls (e.g. batch/online processing procedures, backup
procedures, recovery procedures, etc.).

 Application controls: are manual or automated procedures that typically

operate at a business process level and apply to the processing of
transactions by individual applications.
 Configuration controls.
 Exception reports, including review of these reports.
 Systems interface.
 System access. 44
3.5 Controls and Countermeasures

Control categories:
 Preventive: controls inhibit attempts to violate security policy, such as access
control enforcement, encryption and authentication.

 Detective: controls warn of violations or attempted violations of security

policy, such as audit trails, intrusion detection methods, etc.

 Corrective: controls remediate vulnerabilities, such as backup restore

procedures are a corrective measure as they enable a system to be recovered
if harm is so extensive that processing cannot continue without recourse to
corrective measures.

 Compensatory: controls compensate for increased risk by adding control

steps that mitigate a risk.

 Deterrent: controls provide warnings that can deter potential compromise;

for example, warning banners on login screens or offering rewards for the
arrest of hackers. 45
3.5 Controls and Countermeasures

Control recommendations:
 The following factors should be considered in recommending controls to
minimize or eliminate identified risk:
 Effectiveness of recommended options.
 Compatibility with other impacted systems, processes and controls.
 Relevant legislation and regulation.
 Organizational policy and standards.
 Organizational structure and culture.
 Operational impact.
 Safety and reliability.

 Elements of controls that should be considered when evaluating control

strength include whether the controls are:
 preventive or detective,
 manual or automated, and
 formal (documented in procedure manuals and evidence of their
operation is maintained) or ad hoc.
46
3.5 Controls and Countermeasures
Baseline Controls:
 Defined baseline security controls should be considered in all new systems
development.

 Security requirements should be defined and documented as an essential

part of the system documentation.

 Adequate security requirements should be ensured across the different

phases of the development life cycle. Such as authentication functions,
logging, role-based access control and data transmission confidentiality
mechanisms.

 The information security manager should employ internal or external

resources to review coding and security logic during development.

47
Common Information Security Program Challenges

48
3.6 Common Information Security Program Challenges
Initiating or expanding a security program will often result in a surprising array
of unexpected impediments for the information security manager. These can
include:
1. Organizational resistance due to changes in areas of responsibility
introduced by the program
2. A perception that increased security will reduce access required for job
functions
3. Overreliance on subjective metrics
4. Failure of strategy
5. Assumptions of procedural compliance without confirming oversight
6. Ineffective project management, delaying security initiatives
7. Previously undetected, broken or buggy security software

49
3.6 Common Information Security Program Challenges
• Management Support Lack of management support is most common in
smaller organizations and those that are not in security-intensive industries.
• Funding Inadequate funding for information security initiatives is perhaps
one of the most frustrating and challenging issues that the information
security manager must address
• Staffing The root causes of funding issues extend to the challenge of
inadequate staff levels to meet security program requirements

50
Information Security Program Objectives

51
3.7 Information Security Program Objectives
The objective of the information security program is to implement the strategy
in the most cost-effective manner possible, while maximizing support of
business functions and minimizing operational disruptions.

Chapters 1 and 2 explain how governance and risk management objectives for a
security program are defined and incorporated into an overall strategy

Whether the strategy has been developed in significant detail or only to the
conceptual level, program development will include a great deal of planning
and design to achieve working project plans.

building an information security program is often a process of comparing

existing organizational activity to what is required to achieve a desired state by
performing a gap analysis

52
 3.7 Information Security Program Objectives
It is essential to determine the forces that drive the business need for the
information security program. Primary drivers for an information security
program may include:
• The ever mounting requirements for regulatory compliance
• Higher frequency and cost related to security incidents
• Concerns over reputational damage
• Growing commercial demands of Payment Card Industry (PCI) Data Security
Standard (DSS)

• Determining the drivers will help clarify objectives for the program and
provide the basis for the development of relevant metrics.

53
Information Security Program Concepts

54
3.8 Information Security Program Concepts
As an information security program is developed, it is important that the
developers keep in mind the fundamental purpose of the security program

In situations where security governance has not been implemented and/or a

strategy has not been developed, it will still be necessary to define overall
objectives for security activities

55
3.8 Information Security Program Concepts
CONCEPTS:
Both implementing and managing a security program will require the
information security manager to understand and have a working knowledge of a
number of management and process concepts including:
• Business case development
• SDLCs • Business process reengineering
• Requirements development • Budgeting, costing and financial issues
• Specification development • Deployment and integration strategies
• Control objectives • Training needs assessments and approaches
• Control design and development • Communications
• Control implementation and testing • Problem resolution
• Control monitoring and metrics • Variance and noncompliance resolution
• Architectures • Risk management
• Documentation • Compliance monitoring and enforcement
• Quality assurance • Personnel issues
• Project management
Note: This is not an all inclusive list, but merely representative of many of the major concepts with
which that the information security manager must be familiar.

56
3.8 Information Security Program Concepts
Technology Resources:
It is also essential that the information security manager understand where a
given technology fits into the basic prevention, detection, containment, reaction
and recovery framework, and how it will serve to implement strategic elements.
• Firewalls • Wireless security methodologies
• Antivirus systems • Mobile computing
• Security features in networking devices • Application security methodologies
(e.g., routers, switches) • virtual private network (VPNs)
• Intrusion detection systems (IDSs), • Web security techniques
(HIDSs),(NIDSs) • Vulnerability scanning and penetration
• Intrusion-prevention systems (IPSs) testing tools
• Cryptographic techniques • Data leak prevention methodologies
• Digital signatures • Data integrity controls
• Smart cards • Identity and access management systems
• Authentication and authorization
mechanisms

57
Security Program Metrics And Monitoring

58
3.9 Security Program Metrics And Monitoring
From a management perspective, while there have been improvements in
technical metrics, they are generally incapable of providing answers to such
questions as:
• How secure is the organization?
• How much security is enough?
• How do we know when we have achieved security?
• What are the most cost-effective solutions?
• How do we determine the degree of risk?
• How well can risk be predicted?
• Are we moving in the right direction?
• What impact is lack of security having on productivity?
• What impact would a catastrophic security breach have?
• What impact will the solutions have on productivity?

59
3.9 Security Program Metrics And Monitoring
The primary parameter of metrics design can be summed up as:
1. Who needs to know?
2. What do they need to know?
3. When do they need to know it?

Metrics need to provide information at one or more of the following three

levels:
1. Strategic
2. Management
3. Operational

60
3.9 Security Program Metrics And Monitoring
1. Strategic metrics are often a compilation of other management metrics
designed to indicate that the security program is on track, on target and on
budget to achieve the desired outcomes.

2. Management (or tactical) metrics are those needed to manage the

security program such as the level of policy and standards compliance,
incident management and response effectiveness, manpower and
resource utilization.

3. Operational metrics are the more common technical and procedural

metrics such as open vulnerabilities, patch management status, etc.

61
3.9 Security Program Metrics And Monitoring
There are a number of other considerations for developing metrics. The
essential attributes that must be considered include:

• Manageable
• Meaningful
• Actionable
• Unambiguous
• Reliable
• Accurate
• Timely
• Predictive
• Genuine

62