Building

Enterprise Security Architecture

Governance Plan










Table of Contents

1 VERSION CONTROL 7

2 ABSTRACT 8
2.1 ABOUT THE AUTHORS 8

3 INTRODUCTION 9
3.1 OBJECTIVE 9
3.2 TARGET AUDIENCE 9

4 EXECUTIVE SUMMARY 9
4.1.1 SITUATION 9
4.1.2 PROBLEMS 9
4.1.3 RESOLUTION 9

5 DOCUMENT ORGANIZATION 10

6 CONCEPTUAL BUILDING BLOCKS 10

6.1 SECURITY ARCHITECTURE GOVERNANCE 10
6.2 SECURITY ARCHITECTURE MANAGEMENT 11
6.3 HOW SECURITY ARCHITECTURE GOVERNANCE AND SECURITY ARCHITECTURE MANAGEMENT ARE RELATED 12
6.4 RISK TOLERANCE 12
6.4.1 HIGH RISK TOLERANCE LEVEL 13
6.4.2 MEDIUM RISK TOLERANCE LEVEL 13
6.4.3 LOW RISK TOLERANCE LEVEL 13
6.5 SECURITY PRESSURE POSITION 14
6.5.1 HIGH SECURITY PRESSURE POSITION 14
6.5.2 MEDIUM SECURITY PRESSURE POSITION 14
6.5.3 LOW SECURITY PRESSURE POSITION 15
6.6 TARGET-STATE DETERMINATION OF SECURITY ARCHITECTURE GOVERNANCE 15
6.7 SECURITY CHARTER 16
6.8 SECURITY SERVICE CATALOGUE 16
6.9 CONCEPT MAP 17

7 PLAN OF EXECUTION 18
7.1 PHASES OF WORK 18
7.1.1 ASSESS SECURITY REQUIREMENTS 18
7.1.2 PERFORM GAP ANALYSIS 18
7.1.3 CREATE BRIDGE INITIATIVE 18
7.1.4 IMPLEMENT BRIDGE INITIATIVE 18
7.2 PHASE-1: ASSESS SECURITY REQUIREMENTS 19
7.3 EXECUTION PLAN 19
7.4 [S1]: DETERMINE THE SECURITY PRESSURE POSITION 19
7.4.1 ACTIVITIES 19
7.4.2 PARTICIPANTS 19
7.4.3 EXPECTED OUTCOME 20
7.4.4 STEPS 20
7.5 [S2]: CREATE BUSINESS CASE 21
7.5.1 ACTIVITIES 21
7.5.2 REQUIRED PARTICIPANTS 21
7.5.3 EXPECTED OUTCOME OF THIS STEP 21
7.5.4 PREPARING A BUSINESS CASE 22

8 PHASE-2: PERFORM GAP ANALYSIS 23

8.1 ESTABLISH TARGET STATE 23
8.1.1 ACTIVITIES 23
8.1.2 PARTICIPANTS 23
8.1.3 EXPECTED OUTCOME 23
8.1.4 STEPS 23
8.2 CONDUCT GAP ANALYSIS 24
8.2.1 ACTIVITIES 25
8.2.2 PARTICIPANTS 25
8.2.3 EXPECTED OUTCOME 25
8.2.4 STEPS 25

9 PHASE-3: CREATE BRIDGE INITIATIVE 26

9.1.1 ACTIVITIES 26
9.1.2 PARTICIPANTS 26
9.1.3 EXPECTED OUTCOME 26
9.1.4 STEPS 26

10 PHASE-3: IMPLEMENT BRIDGE INITIATIVE 29

10.1.1 ACTIVITIES 29
10.1.2 PARTICIPANTS 29
10.1.3 EXPECTED OUTCOME 29
10.1.4 STEPS 29

11 APPENDIX A 30
11.1 SECURITY PRESSURE POSITION CASE STUDY 30


List of Figures
FIGURE 1 : HOW SECURITY ARCHITECTURE GOVERNANCE AND MANAGEMENT ARE RELATED 12
FIGURE 2 : RISK TOLERANCE CURVE 12
FIGURE 3 : SECURITY ARCHITECTURE GOVERNANCE LANDSCAPE 16
FIGURE 4 : CONCEPT MAP 17
FIGURE 5 : EFFORT MAP 28


List of Tables
TABLE 1 : GAP ANALYSIS 26
TABLE 2 : RESOURCE ESTIMATION 28




1 Version Control
Version Date Authors Comment
(Last name, First name)
1.0 7th April, 2016 Agarwal, Nidhi Document created
Chattopadhyay, Arnab


2 Abstract
This article examined the field of security architecture from the point of view of security
governance. It explains how security architecture governance can be created as a sub-field of
security governance and how the principles and structure of the same can be applied to
security architecture governance to build an overarching security environment that is easy to
understand, change, monitor and maintain. It has examined the security architecture
governance from the point of view of business sponsors and other stakeholders. It has
suggested security governance life cycle phases, sub-stages in each phase. For each sub-stage,
it has described the list of activities, proposed required participants, stated expected
outcomes and probable artifacts and identified building blocks of the area of concern. While
describing the building blocks, the article has touched upon some of the fundamental
concepts where required and explained it contextually to make the understanding clear. Its
principle of arriving at inferences is primarily based on risk management. It proposes
procedure, organization, artifact, challenges and implementation hints that can be used to
create a security architecture governance plan.

The authors expect this article to be useful for organization who are in the process of creating
or improving their existing security development process. The article is created based on
authors experience in building such a process for large enterprises in combination with the
research of publicly available materials across internet and other forms of publications. It
does not directly or indirectly attempts to depict any process of any particular organization.

2.1 About the Authors
Arnab Chattopadhyay
Arnab is a passionate technologist and loves to design, build and protect large scale systems.
Some of the key areas of his expertise includes telecom networks, large scale distributed
software development, big data technologies, artificial intelligence and information security.
He had spent significant number of years in security research, consulting and management of
security functions that includes identity and access management, cryptography, security
architecture, vulnerability management and security program development. He had worked
across the globe with large corporations to secure their systems. An entrepreneur at heart,
he was instrumental in creating one of the worlds first cloud-based penetration testing SaaS
companies.

Arnab has a Masters of Science degree in Telecom Engineering with Distinction from the
University College London. He held a patent in artificial intelligence.

Arnab can be reached at arnabc169@gmail.com

Nidhi Agarwal
Nidhi has been a Software Engineer for over 12 years. After years of working in the variety of
areas of software development that includes web application development, database and
developing algorithms, Nidhi moved into information security. She had lead development of
information security governance program in software product companies. She had worked
extensively in the areas of vulnerability management, identity and access management and
security governance. She has special interest in security architecture.

Nidhi has Bachelor Degree in Computer Science and Engineering with Honors from National
Institute of Technology, Allahabad.

Nidhi can be reached at anshnidhi@gmail.com

3 Introduction
3.1 Objective
The key objective of this paper is to provide guidance in:
1. Developing a customized information security architecture governance framework.
2. Applying the framework in organization context to create implementation roadmap.
3. Developing a measurement program to continuously improve security architecture
governance.

3.2 Target Audience
Business leaders, CIO, CISO
Business stakeholders
Operational stakeholders
Technology team
Information Security Team

4 Executive Summary
4.1.1 Situation
Security architecture program tends to focus heavily on technology, often neglecting
people, process policies needed to manage the program.
Activities in the program often planned as unrelated parts of specific problems to be
delivered in a given time window thereby losing overarching view of the architecture
and also losing ability to confidently claim that the security objectives are met.
Many cases it seems like a daunting task and often pushed backward.

4.1.2 Problems
This leads to several problems:
The security architecture team/security team doesnt know whether it is supporting
business goals.
The organization lose sense of direction in terms of defining security priorities and
initiatives.
Risk treatment becomes non-definitive.

4.1.3 Resolution
To make security architecture development better managed, security architecture
governance is must have.
The security architecture governance process must be part of and in sync with an
overarching security governance program.
The security architecture governance program must be customized to suit specific
organizational needs.
Begin by defining the organizational pressure that shape and define organizational
security posture and use best practice as a guide to determine what the security
 architecture program must include. The pressure would be referred as security
pressure position in rest of the document.
Conduct gap analysis to identify the initiatives needed to reach to the target state of
security architecture posture.
Create an action plan and implement the project using industry best practices, tools,
templates and using external expertise where required.

5 Document organization
The document is divided into two main parts:
Part where relevant concepts and how they are used to create the plan explained. This
is described in Section 5
Part where the steps of execution for creating the plan are explained. This is described
in Section 6.

To get most benefit out of the document, the readers are advised to read Section 5 and
Section 6 in sequence.

6 Conceptual Building Blocks

In this section, the concepts that form the building blocks of the solution are defined. Some
concepts are well established in the industry and they are explained here to set the context
and show their applicability. Some concepts are derived from well-established concepts.

6.1 Security Architecture Governance
To define security architecture governance, we first need to come up with an agreeable
definition of security architecture. The reason for using the term agreeable is that there
exists no single definition of security architecture.

Security Architecture can be defined as the practice of applying comprehensive and
rigorous methods for describing current and future systems [Ref: Wikipedia]

Security architecture includes people, process and technologies. The key goals of security
architecture can be stated as:
Providing structure
Enabling business-to-security alignment
Enabling Top down decision making starting with business objectives
Creating strong traceability
Abstracting complex concepts
Establishing common lingua of information security

Having defined security architecture, we need to define security architecture governance.
Since this paper is about describing security architecture governance as a subset of security
governance, we start by defining security governance.

Security Governance can be defined as: Information security governance includes the
elements required to provide senior management assurance that its direction and intent are
reflected in the security posture of the organization by utilising a structured approach to
implement an information security program.
ISACA, Information Security Governance, Guidance for Information Security Managers

From there, the definition of the security architecture governance can be derived as follows:

Information security architecture governance is a process of assurance that ensures
information security development for IT systems are happening in compliance with the
overall security governance commitments of an organization. It provides an
overarching manageable and monitor-able framework that brings in definitiveness
and traceability to security design from requirement to implementation.

Security Architecture Governance involves the following activities:
Evaluating current security design and development activities and its impact on overall
security objectives
Providing direction to the security design and development teams by determining risk
appetite, helping identification of work package, identifying security solution
acceptance criteria and assurance that the criteria are indeed been met
Monitoring the effectiveness of security development program
Regular communication with stakeholders regarding security development activities
and performance

6.2 Security Architecture Management
Information Security Management refers to the processes that ensure confidentiality,
integrity, and availability of an organizations assets, information, data, and IT services.
ITIL v3

Security architecture management executes based on direction from security architecture

governance. Key activities involved in security architecture management are:
Building and executing a metrics program
Creating policies
Executing risk management based on risk appetite defined by the governance process
Developing and executing training and awareness program
Developing a security charter and organizational structure
Ensuring compliance


6.3 How Security Architecture Governance and Security
Architecture Management are related
The diagram below (Fig: x) shows how security architecture governance and management are
related:

Figure 1 : How Security Architecture Governance and Management are related

6.4 Risk Tolerance
NIST SP 800-39 defines risk tolerance as the level of risk or degree of uncertainty that is
acceptable to organizations and is a key element of the organizational risk frame.

From an organization point of view, the risk tolerance level can be defined as how much data
and how many systems can be risked at an acceptable level.

Risk tolerance level would help the information security program to know the degree of
protection that the senior management would require to ensure CIA commitments.

Figure 2 : Risk Tolerance Curve

There is no generally accepted risk assumption model. Every organization are driven by a set
of business driver based on which its risk model is defined.

Risk Tolerance Level can be categorized as High, Moderate and Low.

6.4.1 High Risk Tolerance Level
Following are the typical risk characteristics of organizations with High tolerance level:

Does not operate within the following areas:
o Finance
o Health care
o Telecom
o Government
o Research
o Education
Have no compliance requirements
Dont have sensitive data
Customers do not expect the organization to implement and maintain strong security
controls.
Innovation and revenue generation comes before security, so more risk is accepted.
Organization does not have remote locations.
6.4.2 Medium Risk Tolerance Level
Following are the typical risk characteristics of organizations with Medium tolerance level:

Most likely the organization operates within the following areas:
o Government
o Research
o Education
The organization have some compliance requirements (e.g. HIPAA, PIPEDA, PCI).
The organization have some sensitive data, and are required to retain records.
Customers will eventually need strong security controls for their activities.
Due to the sensitive data, information security is more visible to senior management.
Organization has some remote locations.
6.4.3 Low Risk Tolerance Level
Following are the typical risk characteristics of organizations with Low tolerance level:

Operates within the following areas:
o Finance
o Health care
o Telecom
Have multiple compliance requirements and house sensitive data, such as medical
records.
Customers require and expect the organization to have and maintain strong security
controls.
Information security is highly visible to senior management and public investors.
Organization has multiple remote locations.

6.5 Security Pressure Position
An organizations security pressure position represents the forces and drivers that an
organization experiences to create a strong security program.

Extending from that definition, it can be said that the:
Security Architecture Pressure Position are the forces and drivers that necessitates
creation of a strong security architecture program.

Assessing security architecture pressure position would answer a set of broad-level questions
that could help answering executive management questions:
How attractive is the organization to adversaries?
How much customer pressure is there on the organization to improve security?
What is the quantum of regulatory and legal pressure related to security on the
organization?
What other organizational factors are driving the need to improve security?

Following are the values of security architecture pressure position analysis for the executive
management:
Gain a holistic insight of the quantum of pressure the organization is having for an
improved security architecture program
Provide rationale to support resource and budget
Understand pressure points to decide on implementing security to its maximum value
at minimum cost

There are three levels of security pressure position:

6.5.1 High Security Pressure Position
Organizations with high security pressure level would have a combination of many
factors driving the need for very strong security controls. The key attributes are likely
to be the attractiveness of the organization for the attackers and demand for strong
security controls from customers, regulators, government, business units and senior
management
This type of organization requires very strong security governance, management and
level of assurance
This type of organization would have low risk tolerance. Security implementation is
generally proactive and make use of security intelligence
6.5.2 Medium Security Pressure Position
Organizations with medium security pressure level would have a combination of a
number of factors driving the need for strong security controls. These organizations
are attractive to hackers due to the reason of tangible benefits e.g. financial objective.
They also receive pressures from customers, regulators, government, business units
and senior management for strong security
This type of organization requires strong security governance, management and level
of assurance to meet some compliance requirements and some business drivers
 This type of organization would have medium level of risk tolerance. Security
implementation is generally based on best practices and a balanced approach of cost
versus risk is taken when designing security controls
6.5.3 Low Security Pressure Position
Organizations with low security pressure level would generally be less attractive to the
attackers. They would be in a state where the pressure from regulator, business unit,
senior management and other IT department are not serious enough due to lack of
clear business drivers. The pressure of having a strong security program would be
significantly low
This type of organization would have high level of risk tolerance. Security
implementation would generally be based on need basis. They may not have financial
resources to buy/build best appropriates security technology

6.6 Target-State Determination of Security Architecture
Governance
Target-state security architecture is the final objective of any architecture governance plan.
Following are few important pointers on how to determine target security architecture
governance posture.

[1] Examine traits of successful security architecture program to find commonalities
Security architecture and its governance program varies between organization but certain
attributes are found to be common between successful ones. They are:
Security architecture governance always woks within the overarching security
governance framework
There exists a single holistic security architecture governance program for the entire
organization
Management commitment towards security governance and architecture is
demonstrated in top-down manner
The security governance, security architecture management is easy to execute and
maintain

[2] Examine how security architecture governance can interact with existing frameworks
Security architecture does not work in silo. It touches almost all IT systems of an organization
and hence it has touch points to almost all frameworks under execution in an organization.
So, the security architecture governance must define those touch points.

[3] Examine how various IT standards are best used as a mix to make governance program
successful
Typically, organizations where security governance has been successfully implemented, have
used best-of-breed approach when selecting standards. The impact of the following relevant
standards on security architecture governance must be studied:
ISO 27000 series
NIST SP800 series
COBIT 5 for security
PCI-DSS
OWASP for web application
SANS 20 critical security controls

[4] Identify components of overall security governance and select the ones relevant for
security architecture governance
Security governance generally has broad scope. The objective of this exercise is to identify
what is relevant to security architecture governance.

The following diagram attempts to visualize a typical security governance landscape and the
touch point of security architecture within the landscape. Touch points are shown as enclosed
within maroon border. The touch points areas need to be analyzed to derive security
architecture governance target-state requirements.

Figure 3 : Security Architecture Governance Landscape

6.7 Security Charter
It Is a declaration of commitment towards formalized security governance process and
definition and expected value it brings towards business. This helps in communicating the
value and need of security governance to various parts of management.

6.8 Security Service Catalogue
This is a catalogue of security services provided by the infosec organization. This helps in
communicating to other departments what security services they can avail to ensure the
security governance requirements are met. Example of a security service catalogue is:
Application Security Vulnerability Assessment and Penetration Testing Process
Infrastructure Penetration Testing
Mobile Application Assessment
Secure Code Reviews
PCI Compliance Readiness
Wireless Security Assessment
Firewall Review
 Host Reviews
Source Code Review
Build and Configuration Review
ISO 27002 Healthcheck
Cyber Response and Malware Analysis
Security Awareness Training

6.9 Concept Map
The concept map is an attempt to visualize how different concepts and processes for creating
security architecture governance plan are related and how they work together to deliver the
expected outcome.

Figure 4 : Concept Map

7 Plan of Execution

7.1 Phases of work

7.1.1 Assess Security Requirements
Main Objectives Key Deliverables
Understand security architecture program Business Case for security
objectives architecture governance
Define risk tolerance Risk tolerance report
Determine security pressure vectors
Create convincing business case


7.1.2 Perform Gap Analysis
Main Objectives Key Deliverables
Understand components of security Security architecture governance
architecture governance program maturity level current state report
Self-assess security architecture Security architecture governance
governance capabilities and maturity level target state report
Define security architecture target state Gap Analysis report
Identify existing gaps
7.1.3 Create Bridge Initiative
Main Objectives Key Deliverables
Build initiatives to bridge gaps (will be Bridge Initiative project plan
termed as Bridge Initiative) Prioritized list of gaps to be plugged
Estimate resources needed
Create effort map, define RACI matrix and
delivery schedule


7.1.4 Implement Bridge Initiative
Main Objectives Key Deliverables
Finalize roadmap and action plan Finalized Roadmap, Action Plan
Build the list of deliverables Security Architecture Effectiveness
Develop matrices of measurement for and Quality Metrics
security architecture quality and
effectiveness
Build continuous improvement process
through measurement


7.2 Phase-1: Assess Security Requirements

Perform Create Implement

Assess Security Gap Bridge Bridge
Requirements Analysis Initiative Initiative


7.3 Execution Plan
1. Start with kick-off meeting.
a. Discuss and create a common understanding of the challenges of security
architecture governance.
b. Create business case by documenting goals, objectives and challenges
2. Risk identification workshop
a. Create a list of candidate risks
b. Run a risk qualification discussion and create a qualified risk list
c. Mark each qualified risk with a tolerance grading
d. Define security pressure vectors
e. Determine risks through organizations security pressure vectors

7.4 [S1]: Determine the Security Pressure Position

7.4.1 Activities
Identification of the organizational risk level
Assessment of security pressure position

7.4.2 Participants
Head of security
Security engineer
CIO
Member of compliance and audit team
Member of legal team

7.4.3 Expected Outcome
Determination of organizational risk level and risk tolerance
Assessment of security pressure vectors
Understanding how the organization carries inherent risks through its regular business
function

7.4.4 Steps
The outline steps to determine security pressure position are as follows:
1. Determine the risk tolerance level
2. Determine security pressure position

7.4.4.1 Risk Tolerance Determination
An organizations risk model must take into account a set of drivers. The following list provides
some of the most common drivers. However, this list is not comprehensive and subjected to
change based on context.
Compliance
Privacy risks
Security threats
Data and asset value
Industry and competitive pressure
Management preferences

Since this paper is about security architecture governance, it assumes that the organization
already has a risk tolerance level defined for each system as part of overall security
governance exercise. If the definition does not exist, perform a threat modelling exercise using
a standard methodology (STRIDE from Microsoft is a good one to start). The expected outcome
would be:
Prioritized threats and assets and required levels of mitigation

The difference between the mitigation level and the threat level/asset value determines the
risk tolerance. The lower the difference, the lower the tolerance.

7.4.4.2 Security Pressure Position Determination
Once the risk tolerance is done, the security architecture pressure position analysis can be
approached based on the following key attributes:
Industry
Organization type
Users
Compliance requirements
Customer security requirements
Business requirements
Corporate data
Complexity of existing technology environment
Security risk management
Security incidents
Physical location environment
Resource and budget constraints

Outline steps for assessing security pressure position
Initiate discussion on each of the applicable risk variables
Provide custom weightage for each of them as applicable to the organization
Capture responses appropriately

One useful tool to perform this task would be Microsoft Security Assessment Tool (version:
4.0). This can be found at https://www.microsoft.com/en-in/download/details.aspx?id=12273

Risk tolerance must be applied to all applicable attributes. Use it to determine rank of impact
of each attribute. A sample case study on how to assess security pressure position is provided
in Appendix-A which attempt to make the understanding clear.

7.5 [S2]: Create Business Case

7.5.1 Activities
Launch business case creation activity for security architecture governance
Understand main challenges of security architecture governance
7.5.2 Required Participants
Head of Security
Security Engineer
IT System owners

7.5.3 Expected Outcome of this step
Understanding the meaning of security architecture governance applicable to the
organization
Goals behind an adequate framework in place
List of identified challenges facing the organization
Business Case

7.5.4 Preparing a Business Case
There are a number of different ways a business case can be presented. It is generally
contextual and vary with organization and concerned environment. The authors of this paper
has used their experience to define a set of guidelines. The objective is to make the creation
of use case simple which is also easy to understand.

7.5.4.1 Main goals of a business case:
Help securing executive sponsorship, funding and commitment for the project and
eventual governance program.
o To do this, the business case must present a convincing case for how the
security architecture governance program can bring business benefits to the
organization.
Identify RACI matrix to drive ownership
Clarify project goals

7.5.4.2 Target Audience of the business case
Executives most effected by security issues

7.5.4.3 Customize
Tailor the business case to address specific security issues of senior executives
Create the use case such that it answers the questions regarding overall business
impact, not just security.

7.5.4.4 Key Attributes of a business case:
Cost Attributes
o Incident detection and escalation costs
o Notification costs
o Post data breach costs
o Lost business costs
Benefits
o Incident reduction
o Optimizing information security investment by overarching security
architecture control
o Improved reputation and brand equity
o Continuous improvement
o Ability to plan in future
Security as a business enabler
o Competitive differentiator
o Eliminate costs and losses
o Limit the impact and associated cost of security breach
Business goals to security architecture objectives mapping
Common security architecture governance challenges and how they are applicable to
the specific organization
Common security architecture management challenges and how they are applicable
to the specific organization


8 Phase-2: Perform Gap Analysis
8.1 Establish Target State

8.1.1 Activities
Assess current security architecture governance maturity state
Understand and evaluate the relevance of the requirements of security architecture
governance program
Determine the target state of security governance architecture

8.1.2 Participants
Head of security
Entire Security Team
CIO
Business Leaders

8.1.3 Expected Outcome
Understanding of different components that make up organizational security
architecture governance framework
Security architecture governance maturity level
Future target state of security architecture governance

8.1.4 Steps
8.1.4.1 Self-assess Security Architecture Governance Maturity Levels
The following steps can be followed to derive self-assessed maturity level of security
architecture:
Initiate a workshop
Measure for the following areas:
o Context and leadership
o Evaluation and direction
o Compliance
o Preventive security
 o Security response and recovery
o Measurement
For each of the areas, ask participants to mark maturity level on a scale 1 to 5. Explain the
level rating beforehand
The participants must choose in a short time
For each area, the highest and lowest maturity level provider must explain rationale
Repeat for each area as mentioned in the first point
Document the result and produce report

8.1.4.2 Define Security Architecture Governance Target State
The following steps can be followed to derive target state of security architecture governance:
Initiate a workshop
Measure for the following areas:
o Context and leadership
o Evaluation and direction
o Compliance
o Preventive security
o Security response and recovery
o Measurement
Armed with maturity level in each area, ask participants what improvement they would
like to see
For each area, provider must explain rationale
Repeat for each area as mentioned in the first point
Collate results
Produce report

8.2 Conduct Gap Analysis
Based on discussions with various industry experts, analysis of security programs of some of
the large enterprises and authors own experience in developing security enterprise security
programs, some of the key gaps commonly found are:
Lack of well-defined security architecture governance program
Inadequate security measurement and reporting
Inadequate awareness and training
Lack of well-defined objective security posture
No formalized risk tolerance
Buy-in for security governance, especially security architecture governance is half-
hearted

In the following section, the steps to perform gap analysis is described.





8.2.1 Activities
Determine exiting gap in the framework
Prioritization of gaps based on resource, cost and overall benefits

8.2.2 Participants
CISO
Security team
CIO

8.2.3 Expected Outcome
Gap area of security architecture governance

8.2.4 Steps
1. Make a list of existing and relevant security projects
2. For each project, compare the state with the initiatives suggested in target state
architecture
3. As a guidance, use the following questions to examine the gaps:
a. Is there any project that is already underway as per the target state?
b. Is there any project that does not fit in the target state architecture?

Example:

Current Security Project Security Target State Comments
Security design review initiative Institutionalize security Initiative already exists but
- currently case-by-case basis architecture review as a formal require to make it more mature
process as per target state

Security design effectiveness Institutionalize security Initiative already exists but
measurement as afterthought architecture matrices definition require to make it more mature
or when management reporting and measurement as per target state
is needed

 Develop a security system Program exist but not mentioned
catalog in target state. Need to decide
whether to keep it on target
state
Conduct internal security Program does not exist in current
architecture audit for all systems state. New program proposed in
target state
Table 1 : Gap Analysis

9 Phase-3: Create Bridge Initiative

9.1.1 Activities
Review the gap and finalize the list
Design initiatives to bridge the gaps

9.1.2 Participants
IT and Security leaders
Security team

9.1.3 Expected Outcome
Security architecture governance roadmap

9.1.4 Steps
1. Estimate resource needed
a. Cost
b. Human Resource
c. Level of the alignment of initiative with the overall organizational goals and
objectives
d. Relative security benefits of the initiative
2. Create effort map
3. Create security architecture governance roadmap

9.1.4.1 Estimate resources
Cost
Initial Capex: one-time capital expenditure
Recurring Opex: annual recurring operational expenditure

Human Resource
Development staffing: man power required for complete SDLC
Recurring staffing: man power required for maintenance and operations

Level of alignment with rest of the organization
Must be analyzed and decided based on few guideline questions. This is not a comprehensive
list of questions but just indicator.
How well the initiatives to bridge the gaps are aligned with organizations strategic
goals and objectives?
Are the stakeholders bought in to the initiative?

Identify Security Benefits
Description of relative security benefits and risk reduction due to the initiative

The resource estimation must be standardized using some grading level ex. High Medium and
Low. The table below shows an example:

Organizations Definition
Initial Capex High $10,00,000+
Medium $500,000+
Low $100,1000+

Recurring Opex High $10,00,000+
Medium $500,000+
Low $100,1000+

Development Staffing High > YY man hours
Medium > ZZ and < YY man hours
Low < ZZ man hours

Recurring Staffing High > YY man hours
Medium > ZZ and < YY man hours
Low < ZZ man hours

Level of Alignment with High Directly supports critical
Business functions
Medium Indirectly supports critical and
major functions
Low All other tertiary functions

 Security Benefits High Directly impacts legal and
compliance risks, financials and
trust
Medium Indirectly impacts the above
mentioned areas
Low Basic risks
Table 2 : Resource Estimation

9.1.4.2 Create Effort Map
An effort map is a tool to communicate easily with the stakeholders on how to prioritize the
security architecture work. Following are roughly the steps to create effort map:
1. Represents cost, benefit and alignment to business in three axes (see the graph shown
in Figure-5). When mapping, combine all cost in one
2. Place build initiative in the graph based on determined coordinate

Figure 5 : Effort Map

9.1.4.3 Create Security Architecture Governance Roadmap
The actual steps to create security architecture roadmap may vary between organization.
Following are few outline steps which are generic and can be used as a guideline.
1. Go through each identified gap in sequence, map to build initiative components
(described above) and put start and end date-time
2. For each build initiative, create RACI matrix
3. Identify dependencies among tasks of the build initiatives and resolve conflicts and
circular dependencies
4. Create Gantt Chart
5. Produce draft roadmap and cycle through reviews by respective stake holders till sign-
off is achieved





10 Phase-3: Implement Bridge Initiative

10.1.1Activities
Finalize roadmap and action plan
Build deliverables
Build security matrix
Perform security assurance exercise

10.1.2Participants
IT and Security leaders
Security team

10.1.3Expected Outcome
Finalized Security architecture governance roadmap

10.1.4Steps
1. Finalize roadmap and action plan
2. Build a security charter
3. Institutionalize a formal security organization
4. Determine appropriateness of security training program
5. Formalize risk posture and create risk management process
6. Formalize security architecture development and change management process
7. Create/modify policies relevant to security architecture development
8. Create/modify security service catalogue
9. Create a process for security vendor management
10. Develop security architecture effectiveness matrix



11 Appendix A
11.1 Security Pressure Position Case Study
Organization: A National Level Telecom company
Type: Provider of National Critical Infrastructure

For the purpose of simplicity, it is assumed that only two systems are considered to be under
the scope of information security. The two systems are: (a) managed VLAN services for
financial services and (b) consumer mobile services. The next section shows an example of
how to define security pressure position.

Q1: How attractive is the organization to adversaries?

A1: The organization is highly attractive for an adversary to attack and find a breach because
the payoff is very high. The payoff could be financial, stealing trade secret or getting
confidential defense related information.

Enumeration of type of attackers: script kiddies, state sponsored, organized cybercrime gang,
groups with political agenda, moral police groups, right to freedom group, terrorist
organization.

For the purpose of the example, let us only consider one group which is organized crime
group. The answer we have to find is what are the key motives for an organized crime group.
Few of the motives could be:
Subscribe high value service by not paying or availing large discount that is not
applicable
Buy service under fake identity for future misuse of the account
Account take over and sell theft identity information in underground market
Inject malware to disrupt service (for example, encrypt data) and ask for ransom
ransomware
Disrupt legitimate business by launching DDoS and ask for ransom money

All of these would be fed into security requirement. Quantitative loss to business could be
calculated which could be used for prioritization. A number of different adversary analysis
technique could be applied to find out the applicability, probability, severity and likelihood of
one or more than one adversary attacking the system. This will help in identifying the
applicable adversaries, discarding that are not to be considered. For example, in this case,
state sponsored adversary, script kiddies can be dropped from the prospect list. This exercise
would help in defining security requirements which will impact how security architecture
needs to be designed.

Q2: How much customer pressure is there on the organization to improve security?

A2: Customers for communication services are decently aware of the need of security. They
are well aware of their right, laws and put high value to privacy and confidentiality. They are
aware of the security breaches via media reports and are sensitive to lack of security. As a
result, any security breach, even a minor one, has potential for significant loss of business.
Quantitative analysis would show the potential loss in revenue. Now, this could be viewed in
time window. It might be found that customers overall perception of security of the services
provided by the organization is high. So, any big changes in security might not be needed in
short term, however it would be required in long term. On the other hand, if it was found that
there has been a breach few years back which had drawn attention to customers by means
of big media coverage, the pressure to create high level security controls would be high. The
security requirements must include the relevant items that reflects customers pressure.
Another example, that is applicable to a different kind of service, for example, a multi-
geography managed VLAN service for a Fortune 500 Investment Bank, the customer would
demand a set of security controls which might come as a deal blocker if not provided in the
first release. So, the security requirements must include that.

Q3: What is the quantum of regulatory and legal pressure related to security on the
organization?

A3: An organization of this type is likely to be highly regulated and hence it would be subjected
to a number of various legal and regulatory requirements related to information security. The
possible areas of regulatory requirements could be storing PII information, retaining record
of customer conversation with its service center, compliance to certain regulations like PCI,
HIPPA, SOX, Basel etc. The possible legal compliance could be the requirement to conform
with CALEA (Communication Assistance for Law Enforcement Agencies) for lawful
interception of suspected communication. All these requirements must be included in the list
of security requirements.

Q4: What other organizational factors are driving the need to improve security?

A4: There could me many other reasons for the need for high quality security e.g. the
organization may provide security as a service, the organization may market a service for
which security is an enabler (example: confidential information exchange), the organization
may provide mission critical services. There could also be a reason why for some system
tightening of security control will not be possible due to customer experience reason or
implementing security control might delay product rollout which will impact revenue.

For, managed VLAN services the following are the result of analysis. This is representative
data and not a comprehensive analysis.

Compliance requirements SOX, Basel and the level of compliance must be HIGH

Customer security requirements 1. The availability must 99.999%
2. Cryptography public key must be 4096 bit,
symmetric key must be 256 bit, ECC for public key
algorithm, AES for symmetric key
3. All SVLAN end points must use IPSec with Oakley as
key exchange protocol
4. All user authentication must use 2FA with time-
synchronous OTP
5. All SVLAN route must provide quad redundancy
including cable redundancy
 6. Must support federated SSO with customers Ping
Identity Services so that customers employees can
perform SSO with the telecom providers service
portal

Business requirements 1. The system must be rolled out by next quarter
2. The end-to-end provisioning time must be less than
5 days
3. The latency SLAs must be met
4. The contract must be signed in next one month
5. CSAT (Customer Satisfaction) Index must be 4+ out
of 5

Corporate data
Complexity of existing High. The organization uses a number of proprietary
technology environment technologies that has a mix of old and new encryption
capabilities. The network management system has a
complex array of devices and element managers each
with their own security systems.

Security risk management Assume that majority of the security risks must be
mitigated.

Security incidents Last year a major data breach had taken place. As a
result, the earlier CISO lost his job. It got a very negative
media coverage. Recent reports shows that number of
attempted attacks had increased on the network
management system that the organization is
attempting to implement.

Physical location environment The fiber optical terminal points are spread across
geographies. At places in crosses country boundary. The
edge nodes and the connection between tandem
exchanges are spread across partly secure environment.

Resource and budget constraints Due to another major product release, the engineering
resource cannot be moved to adequately resource the
current team. The recent budget slash has constrained
purchasing new security appliance.

Based on the analysis above, it can be found that the organizations security pressure position
is High (matches with the High definition given in previous section). Although, the other
systems security pressure position can be Medium, the overall security pressure position
need to be considered to be High since the major revenue generating system is classified as
High and the organizations risk tolerance level is Low since it is a national critical
infrastructure service provider.

That means, the security architecture must consider this condition in all design decision. It
must apply this condition when making trade-offs. All governance processes for security
architecture must be created/modified to accommodate the condition.

For example, the requirement is to have users to use 2FA using time synchronous token. The
security architecture must provide a capability to securely and seamlessly provision the
tokens, deliver to the intended users, provide lifecycle management i.e. activate/deactivate,
reset PIN, handle lost token and other lifecycle methods. Similarly, all the architecture
governance must mandate sign-off for all security design by the compliance office and
arrange security assurance check point to validate the legal and regulatory compliance.

















END OF DOCUMENT