Securearch by Rnye

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
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: T4lesfromthecrypto@gmail.com
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.
12/4/2017 SECURE ENTERPRISE ARCHITECTURE 1

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 Cryptography in storage (protected)
“business enabling” especially for internet technologies
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; VPN Solution
application to secure procurement for travel for
Multifactor authentication
business managers; communication application includes
enhanced function (e.g. speed, interface) 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, Customer relationship management and customer Single-sign on for users
VP of eBusiness service will be enabled and/or enhanced
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, System will not be burdensome on financials; system Cloud computing solutions: Scalable and flexible
CFO will be flexible to enable integration and disintegration characteristics
of business units
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 Single-sign on mechanisms, System to remain in control Single-sign on for users
Marketing of flow of information throughout network and be
sensitive to laws and regulations (EU) 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 RBAC Model: Standards / Protocols compliant with legacy
networks; System will improve on-time transactions and systems
will communicate with legacy networks; system will be
scalable up and down as integration and disintegration Identified data objects and comprehensive directories to
occurs provide on-time system updates
System and applications have scalable characteristics
Ho Siew Luan Documentary evidence of physical and logical controls Physical controls (e.g. key card) and logical access
(Sarah), Director of architecture. will account for range of compliance controls (e.g. Directory) to system
of Compliance needs. Specifically, to reduce insider trading
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)
Business
Business Risk Business Process Business Business Time
The Business Organization &
Management Model Geography Dependencies
Relationships
Security
Business Security Entity Security-Related
Control Strategies & Security Domain
Attributes Profile Model & Trust Lifetimes &
Objectives Architectural Model
Framework Deadlines
Layering
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 COLLECTI ON

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 SNAPSH OT
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, Architecture is sensitive to the needs of customers; Customer will not be pushed to
products, but will be in control by browsing applications
VP of eBusiness
Helmut Meyer, CFO Expensive security platforms and solutions: “cost a lot in past without demonstrable
benefits”
Brian Jones, Excessive requests for login credentials; systems to stay independently secure while
exchanging marketing information
VP of Marketing

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), Staying compliant; insider trading; keeping the corporate financial and trading
departments separate (e.g. data, communications)
Director of Compliance
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, Customer relationship management and customer service will be enabled and/or
enhanced
VP of eBusiness
Helmut Meyer, CFO Clear ROI breakdown; system will be flexible to enable integration and disintegration
of business units
Brian Jones, Single-sign on mechanisms, System to remain in control of flow of information
throughout network and be sensitive to laws and regulations (EU)
VP of Marketing
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
Ho Siew Luan (Sarah), 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, MEDIUM: Looking for architecture to enable business by suiting customers’ needs to
stay competitive
VP of eBusiness
Helmut Meyer, CFO HIGH: Recommends to the board of directors whether business units need to be sold
off
Brian Jones, MEDIUM: Networked throughout financial world; Controls IBFS marketing team
VP of Marketing
Ranjit Patel, CIO HIGH: Oversees and manages entire network and vouches for systems capability
Ho Siew Luan (Sarah), 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 AT T RIBUTES 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
Logical access control mechanisms
Physical access control mechanisms
Stored Data Confidentiality

Event log browsing tools
Event log analysis tools
Reporting tools
Integrity
Development lifecycle controls
Delivery and installation controls
Productions system configuration controls
Software Integrity Protection 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
Roles
Fixed role associations with entities

Entity Authorization
Real-time role association with entities
Authorization certificates
Non-repudiation
Digital signatures
Notarization servers
Non-Repudiation
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 FUNCTIONS

SUB-LAYER
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 Transport Layer End-to-end flow control

(TCP, UDP, etc.) Error control and session management
3 Network Layer Network Layer Network naming, addressing, directory, and routing control
(IPv4, IPv6, ICMP, IPSec, IGMP, etc.) Network Protocols
2 Data Link Layer Sub-net Link level protocols

(MAC, PPP, SLIP, ATM, etc.) Transmissions media access control
1 Physical Layer Sub-net Physical transmissions

(Ethernet (IEEE 802.3), WiFi (IEEE
802.11), USB, Bluetooth, etc.)
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- Intercepts all subject requests to access control objects and
Access Control Enforcement implements the decisions as to whether these requests will be
Function 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 Two-factor authentication for VPN (Virtual Private Network) access as an optimal
(used for Customer login) 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 Make sure HR has signature of every current and new employee has comprehended
(Signed off) 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
TRUSTED TRUSTED AUTHENTICATION
USER HOST? NETWORK?
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 YES YES LDAP – Database Access

Site PKI / Cert – VPN/ Communications / Payment / EDI
from Providers
Corporate Workers on YES NO Kerberos Realm 3– Database Access
VPN 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:
Support 100 simultaneous users without performance degradation,

and up to 150 users with no more than a 30% reduction in response
Example Time Constraints Noted: 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 LIFETI ME

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

Securearch by Rnye

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Securearch by Rnye

Uploaded by

Copyright:

Available Formats

VERSION 1.

SECURE ENTERPRISE ARCHITECTURE

A proposal for Intergalactic Banking & Financial Services, Inc

Prepared by iNFORMATICS, Inc.

PROPOSAL INTENDED FOR: David Smith, Group Chief Financial Officer

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

SUBJECT: Secure Enterprise Architecture Proposal

PROJECT ASSUMPTIONS: Details

12/4/2017 SECURE ENTERPRISE ARCHITECTURE 1

12/4/2017 SECURE ENTERPRISE ARCHITECTURE 2

3.1 THE CONCEPTUAL LAYER & IBFS CASE STUDY

MANAGER SYSTEM CONCERNS SECURITY STRATEGY

12/4/2017 SECURE ENTERPRISE ARCHITECTURE 3

12/4/2017 SECURE ENTERPRISE ARCHITECTURE 4

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

12/4/2017 SECURE ENTERPRISE ARCHITECTURE 5

4.1 INFORMATION COLLECTI ON

IBFS Case Studies

4.2 POSTINTERVIEW SNAPSH OT

12/4/2017 SECURE ENTERPRISE ARCHITECTURE 6

Management involvement & influence level:

12/4/2017 SECURE ENTERPRISE ARCHITECTURE 7

5.1 ISO/IEC 27001:2013

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

12/4/2017 SECURE ENTERPRISE ARCHITECTURE 8

(Sherwood at al., 2005)

12/4/2017 SECURE ENTERPRISE ARCHITECTURE 9

Operational Security Architecture Layer (Manager’s View)

12/4/2017 SECURE ENTERPRISE ARCHITECTURE 10

6.2 SABSA ® BUSINESS AT T RIBUTES PROFILE

12/4/2017 SECURE ENTERPRISE ARCHITECTURE 11

12/4/2017 SECURE ENTERPRISE ARCHITECTURE 12

8.1 LAYER CHANGES

12/4/2017 SECURE ENTERPRISE ARCHITECTURE 13

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

8.1.2 APPLICATION SECURITY: COMMON SECURITY SERVICES API

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

12/4/2017 SECURE ENTERPRISE ARCHITECTURE 14

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

8.1.4 APPLICATION LAYER SECURITY SERVICES

8.1.4.2 Approach: Role Based Access Control (RBAC)

12/4/2017 SECURE ENTERPRISE ARCHITECTURE 15

Physical access control mechanisms

Stored Data Confidentiality

Event log analysis tools

Development lifecycle controls

Delivery and installation controls

Productions system configuration controls

Software Integrity Protection Production system change control

Production system management authorization

Crypto-checksums on object code images

Fixed role associations with entities

Trusted third party certification and arbitration

12/4/2017 SECURE ENTERPRISE ARCHITECTURE 16

8.1.5 MIDDLEWARE SECURITY SERVICES

8.1.5.1 Approach: Possible Explicit & Implicit Hybrid Model

12/4/2017 SECURE ENTERPRISE ARCHITECTURE 17

8.1.6 DATA MANAGEMENT SECURITY SERVICES

Objectives of data management (non-security):

8.1.6.1 Approach: Applying Data Integrity Protection

8.1.6.2 Data Security Management Services