Download - SEURE ENTERPRISE ARHITE TURE - E-PORTFOLIO...VERSION 1.0 DE EMER 4, 2017 SEURE ENTERPRISE ARHITE TURE A proposal for Intergalactic Banking & Financial Services, Inc onceptual Layer

VERSION 1.0

DECEMBER 4, 2017

SECURE ENTERPRISE ARCHITECTURE

A proposal for Intergalactic Banking & Financial Services, Inc

Conceptual Layer

Prepared by iNFORMATICS, Inc. RYAN NYE, UNIVERSITY OF SAN DIEGO CSOL 510 MODULE 7

Confidential

12/4/2017 SECURE ENTERPRISE ARCHITECTURE 1

1 SECURE ENTERPRISE ARCHITECTURE

PROPOSAL INTENDED FOR: David Smith, Group Chief Financial Officer

Juan Carlos, Chief Operating Officer

Rosemary Brown, Senior Vice President

Helmut Meyer, Group Chief Financial Officer

Brain Jones, Senior Vice President

Ranjit Patel, Chief Information Officer

Ho Siew Luan, Director of Compliance

WRITTED BY: Ryan Nye, Security Architect, Informatics, Inc

(MS CSOL Student)

REVIEWED BY: Mike Hallman, Owner & Founder of Informatics, Inc.

(Professor)

SUBJECT: Secure Enterprise Architecture Proposal

Start Date: October 24, 2017

Published Date: December 4, 2017

Questions: [email protected]

PROJECT ASSUMPTIONS: Details

Architecture Layer: Conceptual

Preceding Layer Inputs: Contextual

Budget: Large to accompany new systems and hardware

Size of Company: Global, located in 84 countries

Projects: Back-office computer network

Financial trading application

Cryptographic process improvement

Middleware layer and common services API

Disclaimer: The chosen case scenario is for learning purposes only. The plan presented in the case scenario is fictitious and are not intended to be implemented without professional consultation. Reference herein to any specific commercial products, processes, or services by trade name, trademark, manufacturer, or otherwise does not constitute or imply its endorsement, recommendation, or favoring by the U.S., State, or local governments, and the information and statements shall not be used for the purposes of advertising.

Confidential


2 CONTENTS 1 SECURE ENTERPRISE ARCHITECTURE ..................................................................................................................................................................................................... 1

3 EXECUTIVE SUMMARY ........................................................................................................................................................................................................................... 3

3.1 THE CONCEPTUAL LAYER & IBFS CASE STUDY ............................................................................................................................................................................ 3

4 DELIVERABLES SUMMARY...................................................................................................................................................................................................................... 5

4.1 INFORMATION COLLECTION ....................................................................................................................................................................................................... 6

4.2 POSTINTERVIEW SNAPSHOT ....................................................................................................................................................................................................... 6

5 LAWS, REGULATIONS, AND STANDARDS ............................................................................................................................................................................................... 8

5.1 ISO/IEC 27001:2013 .................................................................................................................................................................................................................... 8

6 SABSA MODEL OVERVIEW ..................................................................................................................................................................................................................... 9

6.1 POST-CONCEPTUAL LAYER ........................................................................................................................................................................................................ 10

6.2 SABSA ® BUSINESS ATTRIBUTES PROFILE ................................................................................................................................................................................. 11

7 SABSA ® BUSINESS RISK MODEL .......................................................................................................................................................................................................... 12

8 ARCHITECTURAL LAYERING .................................................................................................................................................................................................................. 13

8.1 LAYER CHANGES ........................................................................................................................................................................................................................ 13

8.1.1 PLATFORM & NETWORK SECURITY SEPARATED............................................................................................................................................................ 14

8.1.2 APPLICATION SECURITY: COMMON SECURITY SERVICES API ........................................................................................................................................ 14

8.1.3 PLACEMENT OF SECURITY SERVICES IN ARCHITECTURAL LAYERS................................................................................................................................. 15

8.1.4 APPLICATION LAYER SECURITY SERVICES ...................................................................................................................................................................... 15

8.1.5 MIDDLEWARE SECURITY SERVICES ................................................................................................................................................................................ 17

8.1.6 DATA MANAGEMENT SECURITY SERVICES .................................................................................................................................................................... 18

8.1.7 NETWORK SECURITY SERVICES ...................................................................................................................................................................................... 19

8.1.8 PLATFORM SECURITY SERVICES ..................................................................................................................................................................................... 20

9 DEFENSIVE SECURITY STRATEGY .......................................................................................................................................................................................................... 21

9.1 PREVENTION ............................................................................................................................................................................................................................. 21

9.1.1 AUTHENTICATION, AUTHORIZATION, & AUDIT STRATEGY ........................................................................................................................................... 21

9.1.2 SECURITY SERVICE MANAGEMENT STRATEGIES ........................................................................................................................................................... 22

9.1.3 SYSTEM ASSURANCE STRATEGY .................................................................................................................................................................................... 23

9.1.4 DIRECTORY SERVICES ..................................................................................................................................................................................................... 25

9.1.5 ROLE-BASED ACCESS CONTROL & SINGLE SIGN-ON ...................................................................................................................................................... 26

9.1.6 SCHEMA DEVELOPMENT................................................................................................................................................................................................ 27

9.1.7 PUBLIC KEY CRYPTOGRAPHY & KEY MANAGEMENT ..................................................................................................................................................... 27

10 SECURITY DOMAIN & TRUST MODEL ............................................................................................................................................................................................. 30

10.1 LDAP .......................................................................................................................................................................................................................................... 31

10.2 THE NEW KERBEROS SERVER SYSTEM ...................................................................................................................................................................................... 31

10.3 VPN ............................................................................................................................................................................................................................................ 31

11 SECURITY DOMAIN MODEL ............................................................................................................................................................................................................ 32

12 SECURITY-RELATED LIFETIMES & DEADLINES ................................................................................................................................................................................ 33

12.1 TRUSTED TIME .......................................................................................................................................................................................................................... 33

12.2 CRYPTOGRAPHIC LIFETIME ....................................................................................................................................................................................................... 33

13 CONCLUSION .................................................................................................................................................................................................................................. 34

14 REFERENCES.................................................................................................................................................................................................................................... 35

Confidential


3 EXECUTIVE SUMMARY

3.1 THE CONCEPTUAL LAYER & IBFS CASE STUDY

Informatics, Inc strives to provide a sound security architecture to maintain security costs and increasing usability for end-users. We take a holistic, enterprise-wide view when designing the system to make sure the systems run as smooth as before. One of our principles is consistency across the network to reduce complexity and simplify tasks for management. We use the SABSA Six-layer model in building our architectural proposal.

In the conceptual model, the Architect takes the ideas from the owner, and matures the overall idea by which the business requirements of the enterprise may be met (Sherwood at al., 2005). Additionally, the Architect defines the fundamental concepts that guide the selection and organization of the logical and physical elements of the lower layers of abstraction. The contextual layer defines what business attributes to protect (e.g. user attributes, legal and regulatory attributes), why the protections are important (e.g. business risks by priority), how to achieve those protections (e.g. cryptographic infrastructure strategy and/or role-based models), who is involved in security management (e.g. security team relationships, inter-domain trust relationships), where you want to achieve protection in terms of security domains (e.g. logical – PKI structure, physical – CISCO LAN subnets), and when is the protection relevant (e.g. expiration of keys, certificates, passwords, sessions, time-stamping functions). Once these items are realized and documented by the Architect, it is up to the designer to create a meaningful logical framework.

Intergalactic Banking & Financial Services, Inc (IBFS) requests a security strategy concurrent to their IT infrastructure upgrade process. The conceptual layer relates of the SABSA ® Model directly to the security solutions. Below is a snapshot of the security solutions to address their concerns with the system:

MANAGER SYSTEM CONCERNS SECURITY STRATEGY

David Smith, CEO Excellent service to be maintained by security system “business enabling” especially for internet technologies

Cryptography in storage (protected)

PKI Cryptography in transmission (efficient)

TPM (cryptographic hardware)

Key management Solution

Data redundancy

Business continuity / Data backup

Business threat intelligence platform (Offensive Strategy)

Juan Carlos, COO Multilingual applications; Secure reliable VPN; application to secure procurement for travel for business managers; communication application includes enhanced function (e.g. speed, interface)

VPN Solution

Multifactor authentication

Secure Virtual Meeting Solution

Enables Travel Procurement Security

Business Expense Policy

Application translatable to many languages

Allows for culturally sensitive messages for holidays in region

Rosemary brown, VP of eBusiness

Customer relationship management and customer service will be enabled and/or enhanced

Single-sign on for users

Simple interface

Confidential


Simple and secure to manage new products and connections to those resources

DNS Solution: Secure from phishing attempts

Users educated on social engineering attempts upon sign-up and during active campaigns

Helmut Meyer, CFO

System will not be burdensome on financials; system will be flexible to enable integration and disintegration of business units

Cloud computing solutions: Scalable and flexible characteristics

Application reporting to derive key statistics from big data to enhance sales

Cryptography rework to decrease computations and improve customer experience

Physical and logical controls to decrease fraud attempts and improve audits

Brian Jones, VP of Marketing

Single-sign on mechanisms, System to remain in control of flow of information throughout network and be sensitive to laws and regulations (EU)

Single-sign on for users

Multifactor authentication

Secure & efficient timeout schemes

Datacenter under control of IBFS; Sensitive to laws in other countries (EU)

Comprehensive Information use policy

Ranjit Patel, CIO Standards and protocols to interface with legacy networks; System will improve on-time transactions and will communicate with legacy networks; system will be scalable up and down as integration and disintegration occurs

RBAC Model: Standards / Protocols compliant with legacy systems

Identified data objects and comprehensive directories to provide on-time system updates

System and applications have scalable characteristics

Ho Siew Luan (Sarah), Director of Compliance

Documentary evidence of physical and logical controls of architecture. will account for range of compliance needs. Specifically, to reduce insider trading

Physical controls (e.g. key card) and logical access controls (e.g. Directory) to system

Comprehensive documentation

Enabled segregation of duties and prevents interdepartmental spying for insider trading

Comprehensive Security Policy

Reader Consideration: This architectural layer is described as “able to design the forest rather the trees”. Meaning, the architect is concerned with the overall shape and size of the forest, tree locations, density, and overall mix of tree species. This document will provide an introductory view of the security strategies to be deployed.

Confidential


4 DELIVERABLES SUMMARY

The deliverables for IBFS matched to the SABSA model are as follows:

Assets (What) Motivation (Why) Process (How) People (Who) Location (Where) Time (When)

The Business Business Risk Management

Business Process Model

Business Organization & Relationships

Business Geography

Business Time Dependencies

Business Attributes Profile

Control Objectives

Security Strategies & Architectural

Layering

Security Entity Model & Trust

Framework

Security Domain Model

Security-Related Lifetimes & Deadlines

Specific Deliverables:

1) SABSA ® Business Attributes Profile. Includes selected business attributes, definitions, metric types, measurement approaches.

2) SABSA ® Business Risk Model. Includes statement to include control objectives

3) Assessment of the current status of security against the SABSA ® Business Attributes Profile and associated control objectives

4) Description of the architectural layering to be employed, and the major security strategies and concepts mapped to the control objectives

5) A series of breakout documents, each describing a major security strategy

6) The security entity model and trust framework

7) The security domain model

8) A list of security-related lifetimes and deadlines to be addressed at lower layers

(Sherwood et al., 2005, p. 116)

When referring to graphics or tables the following will be provided:

DOCUMENT REFERENCE: FinalProject.Week7.RYANNYE

Confidential


4.1 INFORMATION COLLECTION

1) Structured interviews with business managers pg. 45-54 2) Business Requirements pg.86 3) Objectives pg. 65 4) Conceptual Layer pg. 217-284 5) Referencing existing materials and collecting technical information pg. 160-161 6) ISO 7) Case studies, see table below:

IBFS Case Studies

IBFS Interview Notes pg. 45-54

Hypothetical Questions Asked pg. 158

IBFS Cryptographic processing pg. 282

IBFS Internet Bank pg. 176-177

IBFS RTSS pg. 87-89

IBFS Securities Trading Division pg. 63-68

Directory Infrastructure at IBFS pg. 128-131

Additional case studies…pg. 751-752 (Index)

4.2 POSTINTERVIEW SNAPSHOT

iNFORMATICS, Inc.

October 27, 2017

Ryan Nye, Security Architect Internal Memo: Post Interview Snapshot

Concerns of management:

David Smith, CEO Architecture should ensure customer’s confidence to maintain their private information

Juan Carlos, COO “Operate on a truly global scale”

Rosemary brown,

VP of eBusiness

Architecture is sensitive to the needs of customers; Customer will not be pushed to products, but will be in control by browsing applications

Helmut Meyer, CFO Expensive security platforms and solutions: “cost a lot in past without demonstrable benefits”

Brian Jones,

VP of Marketing

Excessive requests for login credentials; systems to stay independently secure while exchanging marketing information

Confidential


Ranjit Patel, CIO System updates to show accurate balances and not be in violation of SLA; Remaining in control of network when assets are outsourced; Excessive requests for login credentials; disintegrating business unit network when they are sold off

Ho Siew Luan (Sarah),

Director of Compliance

Staying compliant; insider trading; keeping the corporate financial and trading departments separate (e.g. data, communications)

What we will need to get their agreement to the conceptual security architecture:

David Smith, CEO Excellent service to be maintained by security system “business enabling” especially for internet technologies

Juan Carlos, COO Multilingual applications; Secure reliable VPN; application to secure procurement for travel for business managers; communication application includes enhanced function (e.g. speed, interface)

Rosemary brown,

VP of eBusiness

Customer relationship management and customer service will be enabled and/or enhanced

Helmut Meyer, CFO Clear ROI breakdown; system will be flexible to enable integration and disintegration of business units

Brian Jones,

VP of Marketing

Single-sign on mechanisms, System to remain in control of flow of information throughout network and be sensitive to laws and regulations (EU)

Ranjit Patel, CIO Standards and protocols to interface with legacy networks; System will improve on-time transactions and will communicate with legacy networks; system will be scalable up and down as integration and disintegration occurs



Documentary evidence of physical and logical controls of architecture. will account for range of compliance needs. Specifically, to reduce insider trading

Management involvement & influence level:

David Smith, CEO HIGH: Overseen growth of the organization through a series of major acquisitions. Decision maker of company’s direction

Juan Carlos, COO MEDIUM: Manages technical team’s evaluation of communication technologies

Rosemary brown,

VP of eBusiness

MEDIUM: Looking for architecture to enable business by suiting customers’ needs to stay competitive

Helmut Meyer, CFO HIGH: Recommends to the board of directors whether business units need to be sold off

Brian Jones,

VP of Marketing

MEDIUM: Networked throughout financial world; Controls IBFS marketing team

Ranjit Patel, CIO HIGH: Oversees and manages entire network and vouches for systems capability



HIGH: System needs to enable compliance or the architecture will not be approved

Confidential


5 LAWS, REGULATIONS, AND STANDARDS

5.1 ISO/IEC 27001:2013

The standards applied will follow the ISO standards. ISO standards are reviewed every 5 years to ensure its applicability and effectiveness. The website describes the standards as the following:

“ISO/IEC 27001:2013 specifies the requirements for establishing, implementing, maintaining and continually improving an information security management system within the context of the organization. It also includes requirements for the assessment and treatment of information security risks tailored to the needs of the organization. The requirements set out in ISO/IEC 27001:2013 are generic and are intended to be applicable to all organizations, regardless of type, size or nature” (ISO.org, n.d.).

35 control objectives

ISO/IEC 27002 specifies some 35 control objectives (one per “security control category”). These control objectives provide guidance concerning the need to protect the confidentiality, integrity and availability of information (ISO27001.com, n.d.).

Example

DOCUMENT REFERENCE: FinalProject.Week7.RYANNYE “ISO Controls” tab

Confidential


6 SABSA MODEL OVERVIEW

(Sherwood at al., 2005)

Infamous American Designer of the 1940’s Charles Eames said, “Recognizing the need is the primary condition for design” (Eames, n.d.). For a Security Architect, the quote is applicable, as the needs of the business and identifying key motivations for are recognized first. The enterprise builder may use the SABSA model. The model divides the architectural building process into six layers and asks six questions on each layer: what, why, how, who, where, and when. In this document, an audit layer is added to make it an all-inclusive seven-layer model. Each layer is dependent on the plans of the preceding layer until built, where it will ultimately be managed and inspected.

Confidential


6.1 POST-CONCEPTUAL LAYER

The following are layers to be worked by the security team after the Conceptual layer is completed. Below, I present a description of the layers, the six W’s on each layer, and how the layers are interconnected.

Logical Layer (Designer’s View) When the designer takes over from the Architect, the designer transforms the Architect’s plans into a logical structure to enable physical engineering of the plan. The designer is concerned with what business information presents a logical representation of the business (e.g. graphing protocols for trusted third parties), why the security policy is in place and its requirements (e.g. certificate authority and physical domain policies), how the logical security services fit together into a complex system and meets operational requirements (e.g. system assurance, integrity protections, entity authentication), who uses the specified security framework to create a schema showing attributes and privileged roles (e.g. users, admins, auditors), where specifically in the security domain and/or inter-domain relationship (e.g. logical or physical security domains), and when the security process is implemented (e.g. registration, login, session management). When the designer’s plan is finished and can answer all six questions, the work is handed over the builder who can turn logical drawings into a real composition.

Physical Layer (Builder’s View) The builder is tasked to build the physical security infrastructure involving tangible components that meet the requirements of the designer’s plan. The logical plan is translated into hardware, software, and supporting infrastructure technology to be placed on site. The builder focuses on what business data models and security-related data structures to build upon (e.g. tables, messages, pointers, certificates), why the structures are in place and identifying rules driving logical decision-making (e.g. conditions, best practices, procedures), how security mechanisms will be hosted (e.g. encryption systems, virus protection software at end-user devices), who will be dependent on the security system and their interactions with the system (e.g. users acceptance of screen formats, administrations ability to configure security), where exactly the security system is placed (e.g. location of physical layout of hardware, software, and communication lines), and when the control structures are executed (e.g. sequences, events, lifetimes, and intervals). During the building stage of forming physical systems, the builder will pull the expertise from various experts (the tradesman) to materialize the plan further.

Component Layer (Tradesman’s View) At the component layer, the tradesman is utilized to carry out the builder’s plan. The tradesman are product specialists in hardware, software, or other services. These specialists are concerned with what the data structure specifications ask for, why they are in place and influencing forces in the system’s structure, how those products and tools fit the proposed system, who uses the secure system and control systems in place (e.g. users, admins, and access control lists), where the computer processes occur or node-addresses are used, and when crucial steps are initiated (e.g. timing of process, sequencing of key events). After the work is done by the builder and tradesman, it is now the turn of the manager to run the security system throughout its operational lifetime. Operational Security Architecture Layer (Manager’s View) The system is now built and ready to be run by an individual with knowledge of the security system(s) in place. The manager’s job is to establish what processes ensure operational continuity in terms of maintaining security of data and information (i.e. keeping confidentiality, integrity, availability, auditability, and accountability), why the processes are important (i.e. to minimize failure or disruptions of certain programs or processes), how to perform the security-related operations (e.g. administration of software, locations of backups, emergency response procedures), who provides support to the security system (e.g. responsibility hierarchy), where to maintain security of the manager’s domain (e.g. the site, network layout, and platform), and when to schedule and execute security-related operations. When these questions are answered, the security system is operational, but may not be auditable. This creates a seventh supporting layer to the SABSA model.

Audit Layer (Inspector’s View) – Added to the SABSA Model The inspector is concerned that the security architecture is “complete, consistent, robust and fit-for-purpose in every way” (Sherwood et al., 2005). The inspector can be internal or external auditors, or the systems quality assurance personnel. The inspector will look for what establishes a secure or vulnerable system (e.g. identification of critical systems and their respective controls), why the system is secure or vulnerable (e.g. weak password policy, strong physical controls), understanding how the users perform the controls on the system (e.g. HR hiring process, administration of public keys), who has access to change or alter those controls (e.g. managers wearing multiple hats), where the security controls are located on the network or software, and when those controls are tested during the year or executed on a daily basis. These questions related to the inspector’s view are not recognized by the SABSA model since the correct implementation of the six layers will enable successful audits when answering the “who” question on each layer.

Confidential


6.2 SABSA ® BUSINESS ATTRIBUTES PROFILE

The business attributes profile is a tool used to justify the business driver (increase value) by assigning key attributes that promote a business stance in the areas of:

• Usability of the system and interfaces

• Management of the system

• Operational attributes of the system

• Risk management of the organization

• Legal & regulatory issues of the business

• Technical and feasibility issues

• Overall Business Strategy

The business attributes can be used in two ways: First, we can use as a pick-list to prompt your thinking on business drivers - start with attribute list to create list of related business drivers. Second, we can use as a cross-check for completeness of the business drivers -start with a list of business drivers and cross-check against business attribution list. "The one-to-one mapping of business attributes to business drivers is not a necessity" (Sherwood et al., 2005, p. 89). For this project, we used the list as both cross-check and prompt to obtain the 51 business drivers.

Example

DOCUMENT REFERENCE: FinalProject.Week7.RYANNYE “Business Drivers”, “Business Attributes”, “Attributes Profile&Metrics” tabs

Confidential


7 SABSA ® BUSINESS RISK MODEL

The SABSA ® Business Risk model is a qualitative measurement method that classifies risk into a series of band. First, we match business drivers to business attributes (from a predetermined list). Second, we pull the relevant threats from a database and assign them to the business drivers. Third, we estimate what impact this would have on IBFS. Fourth, we look into what specific vulnerabilities would compromise the network. Fifth, we assign a risk category using the following model:

We then provide risk mitigation by providing control objectives. In the SABSA ® Risk Model provided to IBFS, we have provided both ISO controls and specific risk mitigation procedures.

The developed SABSA ® Business Risk model for IBFS can be found at the following:

DOCUMENT REFERENCE: FinalProject.Week7.RYANNYE “Business Risk Model” tab

SNAPSHOT

Confidential


8 ARCHITECTURAL LAYERING

DOCUMENT REFERENCE: FinalProject.Week7.RYANNYE “Layered Security”, "MultiTierSecurity", "Security Strategy View" tabs

8.1 LAYER CHANGES

The security solutions provided are to coincide with the changes IBFS will me making to their overall information system. Specifically, the architecture accommodates the following changes:

• Back-office network

• Financial trading network & single sign-on

• Middleware development

• Common Services API

• Enhanced secure remote access for traveling managers

• Directory developments and user role assignment

Confidential


8.1.1 PLATFORM & NETWORK SECURITY SEPARATED

“Another major driver or constraint on security architecture is the business strategy of outsourcing all operational services that are not regarded as core businesses. This especially applies to ICT services. We shall of course always own our business applications and their data, but increasingly we shall not be responsible for operating the platforms and networks on which these applications are hosted…“ -R. Patel, CIO (Sherwood, 2005, p.52)

Distinction of security domains for platforms and networks supports an outsourcing strategy. The security architecture will treat platform and network under their own security policy so that no major operational difficulty is encountered at the time of outsourcing (Sherwood, 2005, p.222).

DOCUMENT REFERENCE: FinalProject.SupportingDoc.Week7.RYANNYE “SeparateSecDomains” tab

8.1.2 APPLICATION SECURITY: COMMON SECURITY SERVICES API

“…Like many organizations in this industry sector, we suffer from the problems of legacy applications that have a stovepipe architecture. That is to say, they have their own interfaces and their own data repository, and is very difficult to integrate them together and share data between them.”-R. Patel, CIO (Sherwood, 2005, p.51)

To integrate these various products into your architecture you need to construct the enterprise common security services API as a series of layered APIs" (Sherwood, 2005, p.223). The products on the platform can be changed and replaced without the applications needing to be changed as the installation is completed on the API architecture. Benefits include:

• Third party applications are integrated using adaptor and utilizing entire security infrastructure

• Preserves Flexibility

• Limits development costs

• Single Sign-on for users increasing productivity

• Single registration for users increasing administrative ability and lowering chance of oversight

• Single sign-on for administrating the users increasing productivity and lowering personnel costs

DOCUMENT REFERENCE: FinalProject.SupportingDoc.Week7.RYANNYE “CommonServicesAPI” tab

8.1.2.1 Daisy Model

The development of common services will alleviate the stop-pipe architecture by connecting to a single data repository that is currently in development. This is modeled as a daisy as all applications (pedals) connect to a central interface.

The most important part of this infrastructure of the provision of a central data repository (warehouse), shared between the applications. Ranjit Patel, Chief Information Officer, has informed the informatics team this is currently in development.

DOCUMENT REFERENCE: FinalProject.SupportingDoc.Week7.RYANNYE “AppSecDaisy” tab

Confidential


8.1.3 PLACEMENT OF SECURITY SERVICES IN ARCHITECTURAL LAYERS

Placement of security services are in the following layers:

Middleware Security Services: Within middleware layer

Data Management Security Services: Within database and possibly part of middleware security services

Network Security Services: Within the network

Platform Security Services: Within the individual platforms

FAQ: Why do we want to avoid application security within the Network Layer?

Application security at the network layer would be “unsound because it locks application security into network topology dependence”. For example, when the network topology changes, the application security is at risk. The reading recommends “separation and independence of application security and network security is the best architectural approach”.

8.1.4 APPLICATION LAYER SECURITY SERVICES

8.1.4.1 AUTHORIZATION

The main component regarding application security is about authorizing the user in the system and how much access to system resources that user will have. A user can be allowed or denied by various components of the application:

• Application functions

• Read, update, and create options

• Application transactions limitations

• Dual controls: approval for an action

• Context-based controls

The checklist for good application security would be the following:

✓ Granting privileges (Authorization) ✓ Verifying identities (Authentication) ✓ Access controls (processes used to check identity and privileges) ✓ Auditability (ability to see changes made) ✓ Administration (ease of making changes to user profiles) ✓ Application-to-application communications security

8.1.4.2 Approach: Role Based Access Control (RBAC)

See section titled “Role-Based Access Control (RBAC) and Single Sign-On”

Confidential


8.1.4.3 Application-to-Application Communications

As IBFS expands, the need for applications to interface with newly acquired business applications is a business requirement. The requirement will be to protect the data during transmission. There are four main specific security services needed will be:

Confidentiality

Stored Data Confidentiality

Logical access control mechanisms

Physical access control mechanisms

Event log browsing tools

Event log analysis tools

Reporting tools

Integrity

Software Integrity Protection

Development lifecycle controls

Delivery and installation controls

Productions system configuration controls

Production system change control

Production system management authorization

Crypto-checksums on object code images

Regular inspection of object code images and checksums

Anti-virus tools

Authenticity

Entity Authorization

Roles

Fixed role associations with entities

Real-time role association with entities

Authorization certificates

Non-repudiation

Non-Repudiation

Digital signatures

Notarization servers

Transaction logs

Trusted third party certification and arbitration

DOCUMENT REFERENCE: FinalProject.Week7.RYANNYE “Security Strategy View” tab Application Security Services

Confidential


8.1.5 MIDDLEWARE SECURITY SERVICES

Objectives of the middleware layer (non-security):

• Seamless interactions between application components via consistent APIs

• Transparency of node, service, and data locations

• Scalability and extensibility

• reliability and availability

• Vendor, platform, operating system and networking protocol independence

The middleware service is to locate and identify nodes and data resources on the system with simplicity. For security purposes, the server location is hidden within the middleware as the applications do not need to know location and distribution of the servers.

Objectives of placing security services placed within the middleware layer are as follows:

• Provide a secure infrastructure upon which applications can run

• Offer explicit security API calls to applications

• Enforce logical and physical security domains and domain polices

• Protect itself from logical attack

• Be capable of creating a trusting operating environment for entities that have established trust relationships

8.1.5.1 Approach: Possible Explicit & Implicit Hybrid Model

There are two approaches to providing security services within the middleware layer: explicit and implicit. Explicit services are called through an API (currently in development). The implicit service is provided transparently to the application. A hybrid form of both types of services may be used to expand its security perimeter.

Explicit security provides an audit trail of digitally signed transactions for evidence purposes. The signature keys belong to and are in control of the user. This will be useful for non-repudiation characteristic of transaction and ensuring responsibility of user actions. Implicit service may provide encryption and authentication services outside the application to provide adequate security to the middleware layer. Some additional security provided by implicit security:

• Entity authentication

• Entity authorization & role management

• Logical domain access

• Physical middleware node-to-node authentication, confidentiality, and message integrity

• Traffic flow confidentiality

• Real-time security monitoring, intrusion detection, and reporting

Confidential


8.1.6 DATA MANAGEMENT SECURITY SERVICES

Objectives of data management (non-security):

• Metadata management

• Relational database management

• Object oriented management

• Management systems

• Database access

• Data warehousing

• Data mining

• Transaction processing monitoring

The data management solution provided to IBFS will implement security with both access restriction and protection of informational resources. The data management security has the following functions:

• Access control to data

• Authorization based on business need

• Segregation of write access

• Data availability, integrity, confidentiality protection

• Authentication of SQL requests and responses

8.1.6.1 Approach: Applying Data Integrity Protection

Integrity protection mechanisms maintain a high level of confidence in the quality of stored data. The following mechanisms can be applied:

o “before” and “after” image journals with checkpoints, rollback, and roll forward to restore a database to a specific business position for business continuity

o Field contents validation o Field limits validation o Two-phase commitment of distributed database transactions o Using database views as an access control mechanism o Using stored procedures and triggers to provide secure encapsulation of sensitive functions and prevent

access to powerful functions in native form o Using triggers to enforce special access rules at the specific object or subject level

8.1.6.2 Data Security Management Services

To manage the service successfully, an administrator may need a process to prioritize sensitivity and criticality of data. Second, the administrator will need a process to designate stewardship roles. Third, the use of a standard naming convention for data objects (X.5 to be used). Fourth, the support for standard data formats to provide inter-operability with other organizations.

Confidential


8.1.7 NETWORK SECURITY SERVICES

Network consists of the following in blue from the OSI model:

OSI# LAYER NETWORK SUB-LAYER

FUNCTIONS

7 Application Layer (HTTP, HTTPS, FTP, SMTP, SSH, SMB,

POP3, DNS, NFS, etc.)

6 Presentation Layer (MIME, XDR)

5 Session Layer (TLS/SSL, NetBIOS, SOCKS, RPC, RMI,

etc.)

4 Transport Layer (TCP, UDP, etc.)

Transport Layer

End-to-end flow control Error control and session management

3 Network Layer (IPv4, IPv6, ICMP, IPSec, IGMP, etc.)

Network Layer Network naming, addressing, directory, and routing control Network Protocols

2 Data Link Layer (MAC, PPP, SLIP, ATM, etc.)

Sub-net Link level protocols Transmissions media access control

1 Physical Layer (Ethernet (IEEE 802.3), WiFi (IEEE

802.11), USB, Bluetooth, etc.)

Sub-net Physical transmissions

8.1.7.1 Approach: Separation of Security Services

As we can see from the functions above, network and application security should be kept separate due to flexibility concerns. The provision of application security within the network layer would be architecturally unsound, because it locks the application security into network technology dependence. Additionally, the application security would ne inherently dependent on the security standards placed in the network layer” (Sherwood et al, 2005, p.233).

If the system utilizes IPSec to provide a VPN service this will still provide limited protections. As most intrusions occur from insiders, the protection from outside malicious actors provide little support for the connected architecture.

8.1.7.2 Network Security Service Summary

For a comprehensive list of network security services please refer to the following document:

DOCUMENT REFERENCE: FinalProjectSupportingDoc.Week7.RYANNYE “NetworkSecServices” tab

Confidential


8.1.8 PLATFORM SECURITY SERVICES

Information processing layer refers to platforms which refer to:

• Personal computers, laptops, PDAs, and visual display units (VDUs)

• Switches, hubs, routers

• Servers of all types o File o Database o Multimedia o Data push o Application o Optical disk o Mail

• Telephones, fax machines, cell phones

• Hardware security modules (HSM),PIN pads, Smart cards, biometric devices

• Terminals, printers, scanners

• Cameras, audio recorders

• Transponders, barcode readers

• Network interface devices

• Process control devices; plant controllers, control room consoles

• Storage devices

• Mainframe hosts and servers

8.1.8.1 Platform Security Strategic Principles

First principle is to reduce vulnerabilities in the information processing platforms and infrastructure. Second, to segregate and isolate production platforms and environment from those used for development and testing. Third, to provide and maintain highly trusted execution environments for highly sensitive data processing. Fourth is to provide secure storage environments for highly sensitive non-volatile stored data.

8.1.8.2 Platform Security Service Summary

For full listing of services, see the following document:

DOCUMENT REFERENCE: FinalProject.Week7.RYANNYE “Security Strategy View” tab Communications Security Services

Confidential


9 DEFENSIVE SECURITY STRATEGY

9.1 PREVENTION

9.1.1 AUTHENTICATION, AUTHORIZATION, & AUDIT STRATEGY

The IBFS authentication, authorization, and audit strategy will consist of a directory will roles assigned to all employees. This provides a key solution for compliance who need the Corporate Finance and Stock Trading departments separate to avoid insider trading.

Snapshot:

Item Description

Subject Entity requesting access, which can be a human user or an external system acting on behalf of a user.

Object The resource to which the subject is requesting access. The object can be a data structure (e.g. file, database), an application function, a computer system, a peripheral

Confidential


Reference Monitor- Access Control Enforcement

Function

Intercepts all subject requests to access control objects and implements the decisions as to whether these requests will be granted or denied

Access Control Decision Function Makes the decision as to whether the access request will be granted or denied

Subject Registry Contains all information on registered subjects including their names, their authentication data and their acccess privileges

Access Control List (ACL) A control list associated with each object listing the subjects or groups of subjects that are allowed to make access to that object

Audit log Sub-system Stores comprehensive data on all requests for access, whether or not they are successful in being granted

Access Control Decision Process

Is the subject registered?

has the registered subject been successfully authenticated?

Does the subject's privilege profile contain an authroization to access this object?

Does the access control list attached to the object authorize this subject to tube granted access?

DOCUMENT REFERENCE: FinalProjectSupportingDoc.Week7.RYANNYE “Access Control” tab

9.1.2 SECURITY SERVICE MANAGEMENT STRATEGIES

Various security services exist for business needs. We refer you to the following table for a selection of security services matched to strategy:

Snapshot:

We can use the list as both a checklist and shopping guide to make sure product as all important mechanisms matched to the security strategy.

DOCUMENT REFERENCE: FinalProjectSupportingDoc.Week7.RYANNYE “Security Service View” tab

Confidential


9.1.3 SYSTEM ASSURANCE STRATEGY

The goals of system assurance is correctness, reliability, and proper operation of the system. The following areas require a level of assurance for the three characteristics:

• Control over systems development

• Control over production systems operations

• Software integrity protection and anti-virus controls

• Content filtering to keep out unauthorized and illegal data

• Protecting the integrity of mobile code

• Functional testing

• Penetration testing

• Security auditing

Risk can be evaluated by three main characteristics. Threat, asset, criticality, and system vulnerability. When all three crossover to high risk, the risk must be prioritized to the top of the list.

(Wilson, 2013)

Confidential


The graphic below refers to a flowchart draft of the new IBFS Risk Management system.

Snapshot:

DOCUMENT REFERENCE: FinalProjectSupportingDoc.Week7.RYANNYE “Operational Risk Management” tab

Confidential


9.1.4 DIRECTORY SERVICES

"...this infrastructure will be built in the form of a relational database compliant with an internationally recognized standard such as X.500. Access to the directory services is to be gained through the enterprise-wide middleware - which is being developed as another company-wide infrastructure project… too difficult and expensive to re-engineer these directories, and so the meta-directory approach provides a means to integrate them as they are, supporting legacy applications while still providing a completely new directory interface to new applications" -R.Patel, CIO (Sherwood, 2005, p.128)

As we saw with the graphic in the previous section, the directory authenticates users to the network. The directory service contains entity object such as users, roles, groups, and hardware. File system objects involved may be “container” or “leaf” objects. The file objects take upon a hierarchal structure. We will need to manage privileges to all users to restrict access to system areas for which they are not authorized. The protection against high level changes to users are evident: without the directory service, no other service can remain operable.

Snapshot:

DOCUMENT REFERENCE: FinalProjectSupportingDoc.Week7.RYANNYE “Directory Naming” tab

FAQ: What aspects could you allow non-security personnel access to possibly change?

Information under their control such as personal contact information and address.

Confidential


9.1.5 ROLE-BASED ACCESS CONTROL & SINGLE SIGN-ON

IBFS made large investments into their IT infrastructure over the years. Those investments include data centers, applications, and investments to connected systems overseas. The system infrastructure is now outdated containing stove-pipe architecture which segregate data that requesting multiple logins for access. Additionally, these systems may contain slower processes compared to today’s technology. Due to the size of these legacy systems, reengineering is not an option due to cost.

To decrease the amount of administrative work to access each target system by IBFS managers, we will be using a RBAC strategy. The Role-Based Access Control (RBAC) avoids many issues associated with legacy access control sub-systems. First, a single central authentication service is set up to authenticate all users for the information systems. This is easier than the legacy method to register each user to each information system which increase administrative work and cost of security administration. Second, the RBAC can decouple users from many functions within the systems all at once based on a role (e.g. accounting, maintenance, templates) with one registration. The legacy method would require configuration for each system and increases time for setup. Third, the RBAC reduces the likelihood of leaving dormant accounts for personnel who left the company and reduces inconsistency of access privileges. This contrasts directly with legacy systems which use multiple registrations and configurations leaving room for inconsistency. Fourth, the users in a RBAC are mapped to defined job functions within the system (e.g. create new entry fields, printing function, accounting components, logistics areas) which provide assurance the users are restricted to specific areas in the information system (segregation of duties). The maintenance of changing roles are easier in the RBAC as only one user registry/matrix will need to be changed. A summarized list of benefits include:

• Static role definitions

• Ease of administration of users and their privileges

• Low administration overhead

• Single sign-on for users

• Stable security policy

• Stable, auditable configuration

• Flexible policy, configuration according to business needs

• Improve control over the joining, moving, leaving of subjects (users) and access privileges

Snapshot:

DOCUMENT REFERENCE: FinalProjectSupportingDoc.Week7.RYANNYE “RBAC” tab

Confidential


9.1.6 SCHEMA DEVELOPMENT

Informatics will push IBFS to develop its database schema. The benefits of creating an entity schema include maintaining

the integrity and quality of the data stored in the directory. Second, a directory schema reduces duplication of data

(polyinstantiation). Third, the schema imposes constraints on the size, range and format of data objects stores in the

directory. Fourth, it provides a well-documented and predicable method for directory-enabled applications and services

to access and modify the collection of directory objects. Fifth, the schema helps slow down the effects of directory

entropy, in which over a period with constant use by many entities, “the contents of the directory tend to move towards

chaos”.

The six main role types under a schema are:

1) User roles

2) Business Manager Roles

3) System manager Roles

4) Operations Management Roles

5) Administrator Roles

6) Auditor Roles

9.1.7 PUBLIC KEY CRYPTOGRAPHY & KEY MANAGEMENT

To increase compliance, we will be using a PKI (public key cryptography) strategy for VPN connections and closely connected business entities. This strategy will safeguard customer information from data leakage and safeguard corporate information from insider trading. The four benefits that Public Key Cryptography provide are: authentication, integrity protection, encryption key management, and non-repudiation. Authentication and integrity components are assumed when each party generates a public-private key pair to initiate a secure connection (asymmetric cryptographic relationship). The private key is used to create a digital signature on messages sent to the receiving party who can verify the signature with a public key. Encryption key management is realized from the system which uses different keys to authenticate message and encryption. Rules in key management issues are established from a certificate authority(CA), certificate policy (CP), and certificate practices statement (CPS). Non-repudiation is achievable because each party generates a unique key. The trusted independent certification authority can be uniquely linked to the party that created them. This provides another issue which is trusting the certificate authority.

SUPPORTING CONTROL CONTROL DESCRIPTION

Key Management Key management is important in cryptography because it is one of the three major constraints of a cryptographic system. The other two constraints being algorithm strength (based on block cipher vs. stream, home grown vs. peer-reviewed) and cryptologic protocols used to defend against various of attacks (e.g. replay, MITM, spoofing, and dictionary) (Sherwood et al., 2005).

If the key management system is weak, the attacker can obtain the keys and crack the most complex encryption system. The lecture provided an example on how scripts were made to locate keys in a Windows system. The script located the key in the Root file structure in a shadow file, then copied them on their own computer. Then, used additional tools to crack the encrypted files (University of San Diego, n.d.)

Two-Factor Authentication (used for Customer login)

Two-factor authentication for VPN (Virtual Private Network) access as an optimal security measure to protect against online fraud and unauthorized access for clients that connect to their networks from a remote location.

Confidential


SUPPORTING CONTROL CONTROL DESCRIPTION

Toopher – user can use safe zones, where customers don’t need to enter 2FA code or phrase when near their home or work

Web Application Firewall (WAF) Web servers and databases protected from malicious online attacks by investing in a web application firewall (WAF). A network firewall’s open port allows Internet traffic to access websites, but it can open up servers to potential application attacks, such as database commands to delete or extract data sent through a web application to the backend database, and other malicious attacks.

Vulnerability Scanning Vulnerability scanning checks the firewalls, networks, and open ports. It can be a web application that can detect outdated versions of software, web applications that aren’t securely coded, or misconfigured networks. To meet PCI compliance, you must run vulnerability scans and produce a report quarterly.

Patch Management If servers are not updated and/or managed properly, the data and applications are left vulnerable to hackers, identity thieves and other malicious attacks against your systems.

Antivirus Antivirus software detects and removes malware in order to protect data from malicious attacks.

(Technical Security, N.D)

NO FTP Connections Open FTP connections can cause issues on the network (Pham, 2015).

TPM TPM Hardware to seal the volume master key. The volume master key to be protected by the internal hardware component. If an attacker copied the data, they will not be able to unencrypt with a pin/password.

Employee Read Policy (Signed off)

Make sure HR has signature of every current and new employee has comprehended policy.

Demystifying PKI: How is a digital certificate and credit card similar?

The digital certificate identifies a user and issues a key, while a bank identifies a customer and issues a credit card. Both encryption key (signed certificate) and credit card have encrypted components to ensure that transmission (messages) and transactions (purchases) are from the identified user (non-repudiation). Additional controls like protecting the passcode (to view message) and PIN for the bank card (to complete transaction) are needed to authenticate those actions.

Why is the use of PKI to establish symmetric key techniques so important?

This creates chains of trust to decrease risk and increase usability. It is impractical for one entity to dole out certificates for all business cases where relationships differ entity to entity. Therefore, PKI and it’s trust infrastructure, will ensure levels of responsibility and decrease administrative issues in maintaining keys.

In other words, why don’t we use PKI for the transmission of data all the time instead of establishing a symmetric key?

PKI is not designed for all business functions. There are administrative issues concerning PKI. For example, all the participants in the PKI community must have or agree on the following:

-A universally unique naming standard -A registration authority (RA) that registers all members of the business community -Key generation software or hardware for every participant -A certification Authority (CA) that certifies public keys of the community in the form of digital certificates -A certification procedure to prevent the introduction of false keys

Confidential


-Directory service to publish the certified public keys (digital certs) -Provision to inform when a digital certificate is revoked -Expiration dates for certificates -A trusted time service for generating time and date stamps for certificates and other cryptographic protocol units

(MarkLogic, n.d.)

Confidential


10 SECURITY DOMAIN & TRUST MODEL

In the conceptual layer, we rate the security of the hosts running on the IBFS network. The tiers of hosts are divided into customers, providers/partners, corporate workers on-site, and corporate workers off-site using VPN. These all make up their own security domain. The connections to CompanyX will be authenticated through various technologies: Kerberos server, LDAP, or PKI.

TRUST MODEL

USER TRUSTED

HOST? TRUSTED

NETWORK? AUTHENTICATION

Customers NO NO Kerberos Realm 1 – Records Access 2FA – Message sent to email/phone to help secure host

Providers / Partners

YES NO Kerberos Realm 2 – Database Access PKI / Cert – VPN / Payment / EDI to IBFS Insurance

Corporate Workers on Site

YES YES LDAP – Database Access PKI / Cert – VPN/ Communications / Payment / EDI from Providers

Corporate Workers on VPN

YES NO Kerberos Realm 3– Database Access PKI / Cert – Access to Local network

For extended model see:

DOCUMENT REFERENCE: FinalProject.Week7.RYANNYE “SecEntity&Trust” and “Trust Model” tab

Snapshot:

Confidential


10.1 LDAP

Lightweight Directory Access Protocol (LDAP) is an authentication protocol for accessing server resources over an internet or intranet network. The Active Directory (AD) is used to identify trusted local users on the network. But what if the user is trusted but on an insecure connection? For that, we use the Kerberos server for authentication and protection during the transmission of cryptographic keys (MIT, 2008).

10.2 THE NEW KERBEROS SERVER SYSTEM

Kerberos uses a ticket granting system to first identify its users before allowing access to a server with sensitive files (e.g. ePHI, Corporate data). Identifying employees is for Kerberos since it can link to the Active Directory (use components of the LDAP). Therefore, the issue is with the customers who will be hard to keep track of. We discuss our solution as a Kerberos / PKI hybrid using multiple realms to segregate user groups.

10.3 VPN

Virtual Private Networks (VPNs) provide point-to-point encryption within the network layer. Many of the data streams from IBFS branches to Corporate is completely encrypted. There is limited merit for utilizing VPNs to protect network confidentiality because it provides little protection inside the enterprise itself. For example, the VPN provides encrypted communication across the world to protect from outsider threats but the data transmitted will ultimately have to be secured from unauthorized viewing at the receiving point. Our reading presents most security incidents occur on-site and not over the communication channel.

FAQ: How do the terms Unconditionally Trusted and Conditionally Trusted relate to one another with respect to the concept of Trusted Entities?

Unconditionally trusted entities are those that can misbehave without the violation of the policy being detected. A conditionally trusted entity is one who’s misbehavior will be detected by the security policy.

Confidential


11 SECURITY DOMAIN MODEL

A security domain is a set of security elements subject to a common security policy defined and enforced by a single security policy authority. The security domain consists of security elements, policy, and rules. The element may be a security entity (e.g. type of user) or object (e.g. data structure, database, computers). The security policy is created and assigned to the elements or objects. The policy may be governed by a security policy authority. For users in a PKI setup, the certificate authority governs the policy.

For example model see:

DOCUMENT REFERENCE: FinalProject.Week7.RYANNYE “SecurityDomain & Lifetimes” tab

Snapshot:

Confidential


12 SECURITY-RELATED LIFETIMES & DEADLINES

Noted Time Requirements:

Example Time Constraints Noted:

Support 100 simultaneous users without performance degradation, and up to 150 users with no more than a 30% reduction in response time.

Be available 99.99% of the time during normal working week

By re-designing the application so that (a) the standing order date information is duplicated in the customer record in plaintext (unencrypted) and (b) reversing the sequence of process steps three and four… eliminating nine million record decryptions, saving 7,065 seconds out of a total of 9,000 seconds, which is about 78.5% saving

12.1 TRUSTED TIME

Trusted time is used as a universally agreed value to secure communication (i.e. Protocols) between multiple systems. The

time stamp used in a protocol helps prevent message delay, message replay or message re-sequencing by an

unauthorized eavesdropper. The time stamp is protected by cryptographic mechanisms. If the time is tampered with by

an opponent, they will allow the receiver to accept a message that is “out of time”.

Importance of Trusted Time: Replay Attacks

A replay attack is when “an opponent captures whole messages or data exchanges and replay them later to gain some advantage”. The opponent eavesdrops without being detected, collects login/password information (authentication data), and then replays the data at a later time to masquerade as the authorized user. Even when data is encrypted, the attack still works as the encrypted stack can be reused. To avoid this, the encryption mechanism has a “one-time” value called a “nonce value”. This ensures the message cannot be repeated and often may result in an error. Sound encryption methodologies suggest the system not to provide error details to prevent attackers from learning more about the system.

The nonce value may be created from a time-stamp because it does not require a state variable (additional mechanisms) to be stored for the nonce. Security considerations with this method include making sure that receiving parties have the correct time and it cannot be manipulated. Manipulation of system time may allow the receiver to accept an expired time stamp. This gives rise to the need of a trusted time service.

Additionally, the nonce value may use random numbers in challenge-response protocols, sequence numbers checked by the encryption system, or a combination of these techniques.

12.2 CRYPTOGRAPHIC LIFETIME

The key factor in cryptographic lifetime is the level of exposure to “possible cryptanalysis by opponents”. The user should follow the security policy when establishing lifetime that should of factored in the type of usage, strength of algorithm, key length, and system architecture.

Confidential


13 CONCLUSION

The architecture proposal aligns with many IBFS goals and securely protects assets across the world. We see that if the right security services are employed and correctly implemented, all outsourced services will be kept relatively safe.

The six SABSA layers, and the added audit layer, combine to create an intelligent seven-layer scheme to develop a security architecture. By each team on every layer answering the six questions relating to what, why, how, who, where, and when, will provide clear direction for the personnel and timely construction to meet deadlines. As mentioned, if the six-layer model is done correctly, there is a high level of assurance for the security system in place and little attention toward the audit layer (with respect to adequate vulnerability testing of the system). The flow of information starts vague in the contextual layer to highly specified in the component layer. Therefore, the speed of completion and accuracy of subsequent layers are dependent on the accuracy of the preceding layer. Importance should be placed on how plans, designs, and instructions are communicated with the development team and external parties.

The security architecture should be kept secret and too daunting for attackers to figure out. This quote by an American Architect Louis I. Kahn, creator of monumental buildings, directly applies to security architecture: “A great building must begin with the unmeasurable, must go through measurable means when it is being designed and in the end must be unmeasurable” (Kahn, n.d.).

ROI Consideration

Enhanced encryption technology to protect data will allow lowered price for cyber security insurance and avoid costly lawsuits. “Encryption can add nearly 20% to an organizations ROI in security, and render data useless in the event of a breach” (O’Leary et al., 2017).

Confidential


14 REFERENCES

Eames, C. (n.d.). In Arch.Simplicable. Retrieved on October 26, 2017, from https://arch.simplicable.com/arch/new/101-quotations-for-enterprise-architects

ISO.org. (n.d.). ISO/IEC 27001:2013. ISO.org. Retrieved on December 11, 2017, from https://www.iso.org/standard/54534.html

ISO27001.com (n.d.) ISO/IEC 27002:2013 Information technology — Security techniques — Code of practice for information security

controls (second edition). Iso27001security.com. Retrieved on December 11, 2017, from

http://www.iso27001security.com/html/27002.html

Kahn, L. (n.d.). In BrainyQuote. Retrieved on October 26, 2017, from

https://www.brainyquote.com/quotes/quotes/l/louiskahn117396.html?src=t_architecture

MarkLogic Community. (n.d.). External Security. marklogic.com. Retrieved from https://docs.marklogic.com/guide/security/external-auth

MIT Kerberos Consortium. (2008). Why is Kerberos a credible security solution? Kerberos.org. Retrieved from http://www.kerberos.org/software/whykerberos.pdf

O’Leary, D., Nelson, J., Green, P., Grahn, A. (2017, March 28). 7 Key Elements of a Successful Encryption Strategy. Forsythe.com. Retrieved from http://focus.forsythe.com/articles/364/7-Key-Elements-of-a-Successful-Encryption-Strategy

Onlinetech.com. (n.d.). Technical Security. Onlinetech.com Retrieved on December 11, 2017, from http://www.onlinetech.com/compliance-security/secure-hosting/technical-security

Pham, T. (2015, December 7). Encrypting Data to Meet HIPAA Compliance [Web Log Post]. Onlinetech.com. Retrieved from http://resource.onlinetech.com/encrypting-data-to-meet-hipaa-compliance/

Sherwood, J., Clark, A., Lynas, D. (2005). Enterprise Security Architecture, A Business-Driven Approach. Boca Raton, Florida: CRC

Press.

Wilson, S. [RSA Conference 2013]. (2013, May 30). Why Companies Fail with Compliance Initiatives - Seth Wilson [Video File].

Retrieved from https://www.youtube.com/watch?v=RrGamuOHIlU

University of San Diego. (n.d.). Module 5 Presentation, Physical Security Architecture [Video File]. Retrieved from

https://ole.sandiego.edu

Download - SEURE ENTERPRISE ARHITE TURE - E-PORTFOLIO...VERSION 1.0 DE EMER 4, 2017 SEURE ENTERPRISE ARHITE TURE A proposal for Intergalactic Banking & Financial Services, Inc onceptual Layer

Top Related