Final Project - Sergio Ginocchio · Final Project: Contextual Security Architecture Abstract This paper is written from the perspective of a security architecture consultant hired

CSOL 520 Secure Systems Architecture

FINAL PROJECT Contextual Security Architecture

Sergio Ginocchio

CSOL520 Module 7 Sergio Ginocchio

1

Final Project: Contextual Security Architecture

Abstract This paper is written from the perspective of a security architecture consultant hired by Informatics Inc., to design an enterprise security system for Intergalactic Banking and Financial Services, Inc.(IBFS) This paper will focus on the Contextual Security Architecture layer of the SABSA® Model. The business requirements have been captured from the case study on chapter 4 of the textbook. This paper describes how the Contextual Layer relates to the business and security needs of IBFS, lists and describes the deliverables for the SABSA® Contextual Layer, and how these deliverables could be developed.

The SABSA® Model The SABSA® model provides an analysis framework and methodology to develop and deliver an enterprise security architecture that is focused on enabling business objectives while providing a balanced cost-effective approach to risk management. The SABSA® model consists of six layers:

• Contextual Security Architecture

• Conceptual Security Architecture

• Logical Security Architecture

• Physical Security Architecture

• Component Security Architecture

• Operational Security Architecture or Service Management Architecture

Each layer of the SABSA® model represents the view of a different player in the process of specifying, designing, constructing and using the building. (Sherwood et al., 2005, p.33)

The Business View Contextual Security Architecture

The Architect's View Conceptual Security Architecture

The Designer's View Logical Security Architecture

The Builder's View Physical Security Architecture

The Tradesman's View Component Security Architecture

The Facilities Manager's View Operational Security Architecture

Table 1. Layered Architecture Views

A vertical analysis of each of the six layers is performed by applying the critical questions: what, why, how, who, where, when. This analysis produces the SABSA® Matrix (see Table 2).


2

Table 2. SABSA® Matrix - © 1995 – 2009 SABSA Limited | [email protected]

The first layer of the SABSA® model is the Contextual Security Architecture and this is the focus

of this paper. It identifies and captures the business context, i.e. the objectives, risks,

constraints, and enablers of the enterprise. This layer provides a description of the business

context in which the secure system must be designed, built and operated by asking six critical

questions:

• What? The business needs for information security.

• Why? Business risk in terms of assets, goals, threats, impacts and vulnerabilities.

• How? Look into the business processes that require security.

• Who? The organizational aspects of business security.

• Where? The business geography and location related aspects of business security.

• When? Time related aspects of business security – performance and deadlines.


3

Contextual Security Architecture Development Process

Figure 1. depicts the process being used in this project to develop the deliverables of the contextual layer and it shows how the deliverables map to the SABSA® Matrix for verification of completeness.

Business Requirements

Business Model (Drivers & Attributes

Analyze and Identify Key Business Drivers:

(Assets, Goals, Objectives)and

Other Requirements

Business Attribute Database

Organization & Relationships

Model

Business Process Model

Time Dependencies

Model

Geography Model

Business Risk ModelThreat

Database

Conceptual The

Business

Business Risk

Management

Business Process

Model

Business

Organization &

Relationships

Business

Geography

Business Time

Dependencies

Time

(When)

Assets

(What)

Motivation

(Why)

Process

(How)

People

(Who)

Location

(Where)

Analyze Business Risk of Assets

(Business Attributes)

Developing the Contextual Security Architecture

Figure 1. Contextual Security Architecture development process mapped to the SABSA® Matrix


4

Contextual Security Architecture Deliverables

The deliverables of the contextual layer are listed below. A description of how to develop these deliverables will be provided in the next sections.

• The business model – business drivers, (assets, goals and objectives) mapped to SABSA® Business Attributes

• The SABSA® Business Risk Model in the form of a risk assessment matrix, driven from the SABSA® Business Attributes

• The business process model

• The business organization and relationships model;

• The business geography model;

• The business time-dependency model.

Understanding the Business and Producing the Deliverables

The process of developing the deliverables starts with gathering business requirements. In order to produce the contextual layer deliverables that will enable specifying a secure architecture, an in-depth understanding of the business, its assets, goals and objectives is necessary. Also, there is a need to have an understanding of the business processes and functions, people and organizations and time and location dependencies.

The Business Attributes database (Appendix Figure 2.) are used to help in the process of identifying the business drivers to develop the Business Model. The business drivers in conjunction with the Threats Database (Appendix Table 3.) are used in the SABSA® Risk Assessment Method to develop the Business Risk Model. As part of the gathering of requirements and analyzing the business, an inventory of business processes is assembled as well as capturing the organizational structure, an inventory of sites, locations and territories and capture all time-related aspects of the business. All of this information is used in producing the rest of the deliverables in contextual layer.

Description of the Business in the Case Study

Intergalactic Banking and Financial Services, Inc.(IBFS) is a global group of companies that provide banking and financial services.

The business services that IBFS provides include:

• Retail banking

• current accounts

• direct debits

• standing orders

• debit and credit cards

• check and internet payments


5

• Corporate banking

• current accounts

• foreign exchange

• treasury, payments

• General insurance

• household

• motor

• travel

• healthcare

• Life insurance

• Pensions

• Personal investment products

• unit trusts

• annuities

• special investment products in each country or region

• Savings, loans and mortgages;

• Asset management (managing a portfolio of investments on behalf of clients);

• Custody and other agency services

• Securities trading

• Corporate finance

IBFS has many legacy standalone applications that have a stovepipe architecture, they have their own interfaces and their own data repository. Stakeholders have indicated that it is very difficult to integrate all these applications together or to share data between them. There is a need to provide a single central data repository for customer data - shared across all applications and a need for a data warehouse.

Also, accessing all these systems is not consistent. There is a need for an easy-to-use interface for customers, agents and employees. There is a need to improve the usability and implement single-sign-on.

Compliance is a major business driver, there are many legal and regulatory requirements. IBFS has to build into their systems and processes a series of technical and procedural control mechanisms that provide us with assurance that they are indeed compliant. In addition, there is a need to build a strong culture of compliance with the laws and industry regulations in each and every location.


6

Business Model The following are some of the captured business drivers based on information from the business, the interviews with key stakeholders and the use of the SABSA® Business Attributes:

Business Drivers Business Attributes

Customer Confidence Usable Protected Responsive

Investor Confidence Competent Credible Cost-Effective

Market Reputation Reputable Credible Brand Enhancing

Secure Systems Authenticated Authorized Confidential

Payment Card Information Data Security Confidential Compliant

Business Continuity Available Recoverable

SABSA® Business Risk Model The SABSA® Risk Assessment Method is used to develop the SABSA® Risk Model. This Risk Assessment Method has five steps:

Step 1 Capture business drivers and business attributes. Columns 1-4.

Step 2 Threat Assessment, list of threats relevant to business, that could prevent business from meeting requirements. Column 5.

Step 3 Impact Assessment, impacts from threats materializing and impact value (H/M/L). Columns 6-7.

Step 4 Vulnerability Assessment. Assessment of strengths and weakness as if nothing in place (Green Field Assessment). Columns 8-9.

Step 5 Risk Category - risk category (A, B, C, D) based on vulnerability and impact

• A – Red – Severe Risk (high impact, high vulnerability).

• B – Yellow – Significant Risk (medium/high impact, medium/high vulnerability).

• C – Green – Acceptable Risk (low/medium impact, low/medium vulnerability).

• D – Blue – Negligible Risk (low impact, low vulnerability). Column 10. [1]

Columns 11- 13 refer to the control objectives and vulnerability and risk values after the mitigating controls are applied.

1 2 3 4 5 6 7 8 9 10 11 12 13

ID Business Driver

Business Attributes


High-Level Threat

Business Impact

Impact Value

Potential High-Level Vulnerability

Green Field Vulnerability

Green Field Risk Category

High-Level Control Objectives

Target Vulnerability Value

Mitigated Risk Category

BD01 Stakeholder Confidence

BD01-1 Customer Confidence

Usable Protected Responsive

Ensure Customer feels doing business securely Ensure Investor

Customer information disclosed

Loss of Revenue Loss of Customer Confidence

H Customer loses trust, customer details disclosed to third parties

H A Implement security of customer data at rest and in-transit

L C

BD01-2 Investor Confidence

Competent Credible Cost-Effective

Maintain Shareholder confidence

Data Breach Loss of Revenue Loss of share value

H Customers and Shareholders loses trust, customer details disclosed to third parties

H A Implement security of customer data at rest and in-transit

L C

BD02 Market Reputation

Reputable Credible Brand Enhancing

Adequate data protection of customer, employee, corporate and vendor information

Disclosure of customer, employee, corporate and third-party vendor data

Loss of stakeholder confidence, reputation, market value

H Inadequate protection of sensitive data

H A Implement security controls around customer, employee, corporate and third-party vendor data

L C

BD03 Secure Systems

Authenticated Authorized Confidential

Adequate protection of systems. Appropriate policies for third party access.

Disclosure of customer, employee, corporate and third-party vendor data

Loss of Revenue, Penalties, Loss of Customer and Investor Confidence

H Insufficient account protection, inadequate network protection

H A Password Policies and Enforcement. Perimeter Protection, Intrusion Detection Network Segmentation

L C


8

1 2 3 4 5 6 7 8 9 10 11 12 13

ID Business Driver

Business Attributes


High-Level Threat

Business Impact

Impact Value

Potential High-Level Vulnerability

Green Field Vulnerability

Green Field Risk Category

High-Level Control Objectives

Target Vulnerability Value

Mitigated Risk Category

BD04 PCI DSS Complaint Confidential

Must go beyond PCI DSS Standards [3] [4]

Customer information disclosed

Penalties, Loss of Customer Confidence

H Inadequate protection of sensitive data Inadequate Network Protection

H A Implement PCI DSS Standards Segregate POS functions Implement encrypted P2P [3] Implement in-store EMV [6]

L C

BD05 Business Continuity

Available Recoverable

Retail Systems Available 100% during Business Hours Online Systems 24x7

Systems Unavailable

Loss of Revenue Loss of Customer Confidence

H No built-in resiliency or redundancy to deal with disruptive events

H A Redundant Systems, Perimeter Protection, Intrusion Detection Network Segmentation

L C

Business Risk Model

9

Business Process Model

The business process model takes an inventory of business processes and analyzes them to determine the types of security services needed. At this layer it is imperative to capture business functions, business processes, key activities, internal processes as well external processes. It must identify processes that happen at an enterprise level, within specific groups or divisions, lines of business and other corporate entities within the IBFS group of companies. All activities and functions performed by internal employees as well as customers, vendors and partners must be considered. In order to capture these processes a number of interviews were performed with many stakeholders who are directly involved with the business processes themselves. With all this information and the inventory of processes, analysis was performed to reduce these processes to sub-processes that have generic security requirements. These sub-processes are:

Business Interactions between business entities:

• Entity identification, all entities need to be uniquely identified.

• Entity authentication, the entity must prove the identity it claims.

• Entity authorization, access is provided only to entities that should have access.

Business Communications that must be provided appropriate level of protection:

• Telephone, point to point, conference calls, video conferencing.

• Leased lines

• Local Area Networks

• Wide Area Networks

• Internet and Web access

• Email

• File Transfers

• Online Chat and Instant Messaging

• Remote access


10

Business Transactions and information that must be provided security that complies with policies, standards, laws and regulations:

• Orders

• Invoices

• Payments

• Contract negotiation and agreement

• Information delivery

• Corporate, Employee and Customer information

• Health and PCI information

Organization & Relationships Model

Some of the aspects of Business Organization and Relationships that need to be examined in order to derive the business requirements for security include:

• Management hierarchies and their effect on authorization, governance and control

• Trusted interactions between suppliers and customers, the trust model that represents them and risk model associated with these relationships.

• Outsourcing ICT operations and managing the security policies and risks that accompany an outsourcing strategy.

• Strategic partnerships and joint ventures and how much information you share and the implied liabilities by such partnerships or joint ventures.

• Mergers and acquisitions and how security architecture supports changes in the overall structure of the enterprise. (Sherwood et al., 2005, p.212)

The organizational structure and internal and external relationships need to be well understood. Entities, both physical and logical need to identified. Clearly identify people, organizational groups and divisions, lines of business, organizational and business process roles to be able at a later point to translate these into security domains, organizational roles and access control based on these domains and roles.


11

Business Geography Model

The geography model considers the geographical location and location-related aspects of business security. IBFS is a global enterprise with presence in 84 countries. In addition to language and time-zone considerations, there are many factors that have to be taken into account because of the many diverse locations, laws and regulations. In addition, there has to be considerations about protecting and supporting multi-site operations around the globe, remote workers and remote customer and vendor access via the internet.

Time Dependencies Model

The Time Dependencies Model considers the business time dependencies and the time-related aspects of business security. For example, transaction times, applying security protection to ensure confidentiality and integrity without affecting the availability i.e. if the security mechanism is too slow and transaction time goes beyond acceptable timeframe, then the applied security is impeding the business instead of enabling it.

Other examples of time-related aspects are business deadlines, i.e. in a trading system the market closing time may have an impact on how security is implemented. (Sherwood et al., 2005, p.213).

Conclusion

SABSA is a proven methodology for developing business-driven, risk and opportunity focused Security Architectures at both enterprise and solutions level that traceably support business objectives. It is also widely used for Information Assurance Architectures, Risk Management Frameworks, and to align and seamlessly integrate security and risk management into IT Architecture methods and frameworks. (sabsa.org, 2017)


12

The Contextual Security Architecture is the first layer of the SABSA Model, this layer provides a description of the business context in which a secure system will be built. It is an essential step in defining a secure architecture, taking a shortcut to avoid this step is unlikely to be successful. (Sherwood et al., 2005, p.35)

Security has to be balanced against other requirements. Security has to be adequate in terms of support the business needs, risks, costs and level of protection. It has to enable the business not hinder it. Security has to be balanced against:

• Usability

• Inter-Operability

• Integration

• Supportability

• Low Cost Development

• Fast Time to Market

• Scalability of Security Level

Operational Costs (Sherwood et al., 2005, p.26). The SABSA® Framework and Methodology can be instrumental in achieving this balance.

References Sherwood, J., Clark, A. & Lynas, D. (2005). Enterprise security architecture: A business-driven approach. Boca Raton FL. CRC Press.

Sherwood, J., Clark, A. & Lynas, D. (2009). Enterprise Security Architecture: White paper. Retrieved from http://www.sabsa.org/system/files/SABSA_White_Paper.pdf

SABSA. (2017). The SABSA Institute. Retrieved from www.sabsa.org

Archistry. (2015, March 31). SABSA overview [Video file]. Retrieved from https://www.youtube.com/watch?v=yGqC7JqDN18

http://www.sabsa.org/system/files/SABSA_White_Paper.pdf

http://www.sabsa.org/

https://www.youtube.com/watch?v=yGqC7JqDN18

13

Appendix

Figure 2. SABSA® Taxonomy of ICT Business Attributes - © 1995 – 2009 SABSA Limited | [email protected]

14

Threat Category

Domain Mapping

Description Examples Information security Mapping P

eop

le

Pro

cess

es

Syst

ems

Exte

rnal

Processing and Transactions

* * *

Problems with service or product delivery caused by failure of internal controls, information systems or through weakness in operating procedures

Poor integration of processes

Need to maximize integration of software applications and eliminate 'islands' of functionality

Lack of conceptual thinking in systems planning

Inadequate ICT systems architecture

Transaction failure Inadequate exception reporting and transaction recovery in ICT systems

Reconciliation failure Inadequate exception reporting in ICT systems

Unauthorized trading Inadequate authorization, identification and access control in ICT systems

Technology * *

Failure to plan, manage and monitor the performance of technology-related projects, products, services, processes, staff and delivery channels

Failure to meet business requirements

Inadequate business requirements specification on ICT development projects

Failure to integrate with business processes

Need for ICT projects to support and integrate with business processes

Technical integration failure

Must successfully integrate chosen ICT product components

Inadequate technical architecture

Inadequate ICT systems architecture to ensure flexibility in response to changing business requirements

Lack of technical standards for construction

Badly designed and constructed ICT systems

Business Continuity

*

Loss or damage caused by unusual weather conditions or earthquakes or unpredictable causes

Loss or damage to operational facilities

Inadequate site selection for data centers or lack of redundant data centers

Table 3 – Threats Database (sample)

Final Project - Sergio Ginocchio · Final Project: Contextual Security Architecture Abstract This paper is written from the perspective of a security architecture consultant hired

Documents