Conceptual Architecture: IBFS

Intergalactic Banking and Financial Services Inc:

Introduction

N. Kristina Villanueva
University of San Diego
Conceptual Architecture: IBFS 2

Table of Contents

Introduction 3

Main Body 4

Conceptual Security Architecture Deliverables 4

SABSA Business Attributes Profile 4

SABSA Business Risk Model 9

Assessment of Current Status 10

Description of the Architectural Layering to be employed 11

Major security strategy 6

The security entity model and trust framework 6

The security domain model 6

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

Discussion 4

Conclusion 4

References 4

Appendices 4
Conceptual Architecture: IBFS 3

Intergalactic Banking and Financial Services Inc:

Introduction
Security Architecture needs a holistic approach that enables your business to achieve its
objectives. We have learned of Intergalactic Banking and Financial Services, Inc.’s strategic
developments in harnessing new technologies- both to improve your efficiency in existing
business sectors and to enable new lines of business and new methods of marketing and
distribution. In response, we have produced an enterprise security architecture conceptual
model, which will enable this strategic development. The objective of this proposal is to
describe how the conceptual architecture addresses your business and security needs as well as
how the conceptual architecture fits into the SABSA model.

SABSA Model Overview

The SABSA model is a methodology that develops a security architecture that is based on
solving business-specific requirements that influence security strategy. It is comprised of six
layers where the successive layers are developed in sequence, except for the operational layer,
which is developed in parallel rather than sequentially. The first two layers are further
categorized into the strategy and concept phase of the model. In the first layer, the conceptual
layer, the business model, business strategy, assets, goals and objectives are defined. The second
layer, the conceptual layer, concludes of the strategy and concept phase, within which high-level
strategy is developed and agreed on. In this paper, we will conceptualize the business model to
establish the framework needed to proceed to the design phase of the SABSA model, where
additional resources will be assigned.
The SABSA model is comprised of six layers: contextual architecture, conceptual
architecture, logical security architecture, physical security architecture, component security
architecture and the final layer, the operational security architecture, which relates to each of the
various layers. Although distinct, each of the views of the SABSA Model relate to each other
and serves as a methodology of architectural development.

Pre-requisites - Contextual Security Architecture Deliverables

The effectiveness of our delivery of the conceptual model as outlined in the deliverables section
of this proposal, the following perquisites are required:
1. The business model – business drivers, including business assets, goals and objectives
mapped to SABAA Business Attributes;
2. The SABSA Business Risk Model in the form of a risk assessment matrix, driven from
the SABSA Business Attributes;
3. The business process model;
4. The business organization and relationships model;
5. The customer geography model;
6. The business time-dependency model

Conceptual Security Architecture Deliverables

The conceptual security architectural layer of the SABSA model is often referred to as the
architect’s view. We have developed your Business Attributes Profile pulling from expected
inputs of the SABSA Risk Assessment Method, which would have been developed in the
preceding contextual layer. Using the Business Attributes Profile, we then established Control
Objectives to achieve the required protection in terms of high level technical and management
Conceptual Architecture: IBFS 4

security strategies. In this layer, the architect also considered who will be involved in security
mangement and their technical abilities. With respect to logical and physcial security domains,
the architect’s view will consider where we would want to achieve protection. Lastly, the
architect’s view will consider when protection is relevant with respect to timebound concepts
such as keys, certificates and passwords.
There are several conceptual security architecture deliverables: (1). The SABSA Business
Attributes Profile, (2). the SABSA Business Risk Model, (3). Assessment of the status of security
against the SABSA Business Attributes Profile and Associated Control Objectives, (4).
Description of the Architectural Layering to be employed, (5). Break-out documents describing
security strategy, (6). The security entity model and trust framework, (7). The security domain
model and (8). A list of security related lifetimes and deadlines to be addressed at lower layers.
The deliverables together will represent the big picture and the strategic plan for IBFS’s
enterprise security architecture. At the conceptual layer of the SABSA model, the vision of the
future starts to take shape. In this second phase, a conceptualization of the types of solutions that
will satisfy the needs of the business will take form.

SABSA Business Attributes Profile.

In the preceding contextual layer, the Business Risk Model is developed, which includes
business drivers and business risks that are assessed using a simple qualitative scale. The
Business Attributes Profile is dependent on the completion of the Business Risk Model. The
process for developing the Business Attributes profile begins with assigning risk categories for
each threat. In the Business Attributes Profile deliverable, we mapped each business driver and
business risk to its corresponding Business Attribute.
This SABSA Business Attributes Profile deliverable is a conceptual representation of the
business and its requirements for security. Included below are the Business Attributes that apply
specifically to IBFS and should be signed off on by Senior Executives. The purpose of the
Business Attributes Profile will be to establish a metric framework that is directly tied to
business drivers. These metrics will be used on an ongoing basis to measure conformance of the
security management program with the performance standards that have been established in this
stage. The performance targets will also need to be signed off on by senior executives.

Private. The banking industry is based on trust and if IBFS were to breach that
fundamental trust, then its relationships, customers and reputation in the marketplace would
suffer enormously. In all information systems, the protection of that trust must be a primary
business requirement. IBFS is also aware of the reputation damage that can occur in this
industry sector when customers suffer losses at the hands of their bankers and insurers. IBFS
will always continue to maintain a strong policy of legal and regulatory compliance and to
exhibit due diligence in handling the affairs of our customers. The following business drivers are
mapped to the Private Business Attribute: Maintaining the privacy of personal business
information that is stored, processed and communicated by IBFS’s systems (BD17). The risk
management attributes class is concerned with the business requirements for mitigating
operational risk. This class most closely relates to the security requirements for protecting the
business itself. Tied to this business driver is the privacy business attribute, which is concerned
with the privacy of personal information should be protected in accordance with relevant privacy
or data protection legislation, and to meet the reasonable expectations of citizens for privacy.
Unauthorized disclosure should be prevented. There are two metric types for this business
Conceptual Architecture: IBFS 5

attribute: hard and soft. The hard metric will be the reporting of all unauthorized disclosure
incidents, including number of incidents per period, severity and type of disclosure. Under this
metric the performance targets include zero successful attempts at unauthorized disclosure and
alerts of unauthorized access attempts produced and delivered to system manager and business
owner monthly. The soft metric will be independent audit and review with respect to the
prevention of unauthorized disclosure of private information. The performance targets for this
metric will hold that the system passes review by independent legal and forensic authority to a
degree deemed acceptable by the legal group to prevent prosecution under EU Data Protection
legislation. Maintaining the privacy of personal and business information that is stored,
processed and communicated by IBFS’s systems (BD17).
Liability-managed. It is imperative to separate the information in corporate finance from
the people in securities who could use that inside information to make illegal deals. The
following business driver is mapped to the liability-managed business attribute: Ensuring that
employees using the systems are only granted authorized access within need-to-know and need-
to-use privileges (BD26). Legal and Regulatory Attributes describe the business requirements for
mitigating operational risks that have a specific legal or regulatory connection. The Liability-
managed business attribute holds that the system services should be designed, implemented and
operated to manage the liability of the organization regarding errors, fraud, malfunction and so
on. The responsibility and liability of each party should be clearly defined. The metric type for
this business attribute is soft. The suggested measurement approach is independent legal expert
review of all applicable contracts, Service Level Agreements, etc. The performance target is an
independent review by ABC Legal Group with respect to IBFS’s ability to demonstrate system
services are designed, implemented and operated to manage the liability of the organization
regarding errors, fraud, malfunction and so on.
Capturing New Risks. At this time, we are also evaluating the effect of the New Basel
Capital Accords (Basel II) and the repsonse that we shall have to make to that new regulatory
regime in operational risk management. The following are the associated business drivers:
Detecting attempted financial fraud (BD10); Preventing losses through financial fraud (BD9).
Risk management attributes describe the business requirements for mitigating operational risks.
This group most closely relates to the seucirty requirements for protecting the business. The
business attribute mapped to these business drivers is Capturing new risks, which asserts that
new risks emerge over time. The system mangement and operational environment should
provide a means to identify and assess new risks (new threats, new impacts or new
vulnerabilities). There are two metric types: hard and soft. The hard-metric type has a suggested
measurement approach of percentage of vendor published patches and upgrades installed. The
Performance target: a summary of reports of the percentage installed vendor patches, produced
and delivered to Juan Carlos, Chief Operating Officer monthly. The soft metric type suggested
measurement approach is independent audit and review against security Architecture Capability
Maturity Model of a documented risk assessment process and a risk assessment history. The
Performance target: Independent audit and review by ABC Consulting Firm with respect to
IBFS’s ability to demonstrate system mangement and operational environment ability to provide
means to identify and assess new risks.
Compliant. IBFS’s board of directors is very committed to strong governance and
executing these responsibilities with due diligence. That means we must build a strong culture of
compliance with the laws and industry regulations in each of our operating countries. At IBFS
we are involved in a broad span of lines of business that fall under the auspices of several
Conceptual Architecture: IBFS 6

different regulators, even within one country. We must also build into our systems and processes
a series of technical and procedural control mechanisms that provide us with assurance that we
are indeed compliant. There are also major international regulations aimed at preventing and
detecting money laundering. Insider dealing is another area where the industry is very sensitive.
The following are mapped business drivers: Ensuring that IBFS is always compliant with the
laws and industry sector regulations, and that the informatino security approach in the systems
directly and indirectly supports legal compliance (BD16); Providing means by which IBFS can
monitor compliance with its various information security policies and can detect, investigate and
remedy any attempted or actual violations of those policies (BD22). Legal and regulatory
attributes describe the business requirements for mitigating operational risks that have a specific
legal or regulatory connection. The business attribute mapped to the mentioned business drivers
is compliant, which asserts that the system should comply with all applicable regulations, laws,
contracts, policies and mandatory standards, both internal and external. The metric type for this
business attribute is soft. The measurement approach is an independent compliance audit with
respect to the inventories of regulations, laws, policies etc. The performance target is an
independent audit and review by ABC firm with respect to IBFS’s ability to pass compliance
audit.
Admissible. the European Union has very comprehensive set of legislation covering data
protection (the privacy of personal data that we collect during our business). We must also be
able to bring reliable documentary evidence before a regulator or a court of law. The associated
business drivers are: providing the ability to persecute those who attempt to defraud IBFS
(DB11); Ensuring that information processed in IBFS’s systems can be brought to a court of law
as evidence in support of both criminal and civil proceedings and that the court will admit the
evidence, and that the evidence will withstand hostile criticism by the other side’s expert
witnesses (BD14). Legal and regulatory attributes describe the business requirements for
mitigating operational risks that have a specific legal or regulatory connection. The business
attribute mapped to the said business drivers is admissible, which holds that the system should
provide forensic records (audit trails, etc.) that will be deemed to be admissible in a court of law,
should that evidence ever need to be presented in support of a criminal prosecution or a civil
litigation. The metric type would be soft. The measurable approach would be independent audit
and review against Security Architecture Capability Maturity Model by computer forensics
expert. The performance target is an independent audit and review by ABC firm with respect to
IBFS’s ability to provide forensic records that will be admissible in a court of law.
Flexible and Adaptable. The financial services business is very fluid where new
partnerships and joint ventures are being spawned continuously. The industry is in a constant
state of change regarding mergers, acquisitions, divestments and joint ventures. In all cases,
IBFS must ensure that it can integrate and disintegrate with the Information Communication
technology systems and network ingratitude that the business use, depending upon current
business strategy. Flexibility for an ever-changing business strategy is one of the most important
drivers for our information systems decision-making. Further, the join-venture concept requires
that both IBFS and the partner concerned need to give the other access into business information
systems but at the same time they need to maintain their independence and their own control.
The associated business drivers are as follows: Maintain the ability to govern (BD8); Protecting
other parties with whom IBFS has business dealings from abuse, loss of business or personal
information (BD25); Ensuring that security services can be extended to all user locations. These
business drivers are then linked to the flexible and adaptable business attribute in that the system
Conceptual Architecture: IBFS 7

should be flexible and adaptable to meet new business requirements as they emerge. The
measurable approach for this business attribute is independent audit and review against security
architecture capability maturity model of technical architecture. The performance target will be
an independent audit and review by ABC Internal Audit and Legal Group with respect to the
ability to provide proof of the transaction flow and individual accountability on all transactions.
Inter-operable. IBFS values excellent customer relationships management and customer
service. It must be acutely sensitive to the needs and expectations of our customers and potential
customers. IBFS’s customer’s expect smoothness and consistency in all these different
interfaces. Similarly, all interfaces and applications should always be aware of all previous
dealings with this customer, especially all the accounts, insurance policies, and investments that
he or she hold with us. Operational attributes are concerned with the ease and effectiveness with
which the business system and its services can be operated. IBFS considers inter-operability to
be among its top business attributes. That is, the system should be inter-operable with other
similar systems, both immediately and in the future, as inter-system communication becomes
increasingly a requirement. This business attribute is derived from multiple business drivers:
Maintaining the accuracy of information (BD7); Ensuring accurate information is available when
needed (BD41); Minimizing the risk of loss of key customer relationships (BD42). The hard,
measurable approach for this business attribute is to establish specific inter-operability
requirements. The performance target for this business attribute is exception reports detailing all
incident of manual adjustments to information and to identify and develop rules and data
elements for sharing.
Legacy-sensitive. The IBFS information systems application architecture is in the
process of being revised. It suffers from the problems of legacy applications that have a
stovepipe architecture; that they each have their own interfaces and their own data repository,
and it is very difficult to integrate them together or to share data between them. The business
imperative towards Customer relationship mangement (CRM) means that we must be able to
provide a single central data repository for customer data, and that this repository must be shared
across all applications. The associated business drivers are as follows: Providing assurance of
the correct functioning of IBFS’s systems and sub-systems (BD23); Ensuring that the security
architecture remains compatible with new technical solutions as these evolve and become
available and with new business requirements as these emerge, with a minimum of redesign
(BD38). Among the technical strategy attributes, which describe the needs for fitting into an
overall technology strategy, IBFS considered legacy-sensitivity to be a key business attribute. A
new system should be able to work with any legacy system or database with which it needs to
inter-operate or integrate. The metric type for this business attribute is soft. The measurement
approach is independent audit and review against securit architecture capability maturity Model
of technical architecture. The performance target is an independent audit and review by ABC
consulting firm with respect to the systems ability to work with any legacy systems or databases
with which it needs to inter-operate or integrate.
Architecturally open. Another major driver or constraint on security architecture is the
business strategy of outsourcing all operational services that are not regarded as core business;
this is especially the case with Information and Communication Technology services. The
guiding principle for IBFS’s security architecture must be that any platform and any network can
potentially be outsourced. The architect must enable this to happen with minimal disruption and
minimum impact on the ownership, policy-making and policy enforcement for each of these
physcial domains. The associated business drivers are as follows: Ensuring that the security of
Conceptual Architecture: IBFS 8

IBFS’s information is dependent only upon its system security measures and not on the security
competence of any other organization (BD28); Ensuring that the security architecture is
independent of any specific vendor or product and can support multiple products from multiple
vendors (BD37). The technical strategy attributes are a group of attributes that describe the needs
for fitting into an overall technology strategy. IBFS aims for an architecturally open business
attribute where the system architecture should, wherever possible, not be locked into specific
vendor interface standards and should allow flexibility in the choice of vendors and products,
both initially and in the future. The metric type for this business attribute is soft and the
measurement approach calls for an independent audit and review against security architecture
capability maturity model of technical architecture. The performance target will be: System
passes review by ABC consulting firm with respect to ability to allow flexibility in the choice of
vendors and products, both initially and in the future.
Usable. IBFS is concerned about the usability of business systems and about the
difficulty that security often imposes on legitimate business users. Using our systems must be a
pleasant, interesting and productive experience for the users; otherwise they will look elsewhere
for service. The associated business driver is ensuring that information security interfaces are
easy and simple to use (BD31). This business drivers traces to the user business attribute: which
is related to the user’s experience of interacting with the business system. IBFS considers the
usability to be of high importance. Specifically, the system should provider easy-to-use
interfaces hat can be navigated intuitively by a user of average intelligence and training level (for
the given system). The user’s experience of these interactions should be at best interesting and at
worst neutral. The measurable approach for usability business attribute will be the numbers of
licks or keystrokes required, the conformance with industry standards (e.g. color palettes) and
feedback form focus groups. The performance targets will be monthly report of on all customer
feedback relating to usability, report from quarterly customer and non-customer focus groups and
monthly report of numbers of clicks or keystrokes required sent to Brian Jones, Sr. Vice
President, Marketing and Distribution.

SABSA Business Risk Model.

Actual deliverable is dependent on inputs from the Contextual layer of the SABSA model
where we would expect the use of the SABSA Risk Assessment Method to adopt qualitative
measurement method that classifies risks into a series of bands. The following steps describe the
SABSA Risk Assessment Methodology that we would use to develop this key deliverable. See
Table 3 for a representative output deliverable of the Business Risk Model.
SABSA Risk Assessment Method: Step 1. Business drivers and assets are identified, where
assets refer to the things of value to the business that need to be protected. In the SABSA
approach, the business drivers and business attributes concepts are used conceptualize the notion
of assets.
SABSA Risk Assessment Method: Step 2. Threat scenarios that IBFS considers to be the
relevant threat model for the business are listed.
SABSA Risk Assessment Method: Step 3. Assess the business impact if the listed threat
scenarios were to materialize using a simple qualitative scale:
H – High Impact: could potentially do great damage to the business
M – Medium Impact: could do significant damage to the business
L – Low Impact: could do only minimal damage to the business
Conceptual Architecture: IBFS 9

SABSA Risk Assessment Method: Step 4. Assessment of strengths and weaknesses of

IBFS’s systems, processes and culture using the Green Field vulnerability assessment, where we
would ignore any additional controls that you have already put in place. Applying the green
Field vulnerability assessment as though nothing special had been done helps in the development
of the seuciryt architecture to assess the contribution of all the planned controls over and above
the green field situation before any security is built. A slight variation of the qualitative scale of
measurement is used for this operational security risk assessment:
H – High Vulnerability: easily exploited by the threat
M – Medium Vulnerability: possible for the threat to be exploited
L – Low Vulnerability: very difficult to exploit by the threat
SABSA Risk Assessment Method: Step 5. The risks are prioritized based on a calculation
using the impact rating and vulnerability rating described above, where each risk is assigned a
risk category. See Table 6 for the risk category table.

Assessment of the current status of security against the SABSA Business Attributes
Profile and Associated Control Objectives.
The purpose of the Business Risk Assessment described above is to state some control
objectives at the conceptual security architecture layer, which will drive through the detailed
design of controls at the logical, physical component and operational security architecture levels.
This risk assessment was used to develop a set of control objectives that conceptualizes the needs
of IBFS for mitigating the risks. Control objectives are synthesized from the Business Risk
Model (contextual layer) and from the Business Attributes Profile (conceptual layer). See Table
4 in appendices for the objective controls mapped to Business Attributes. The control objectives
selected for this proposal were based on the globally recognized Control Objectives for
Information and related Technology (CobiT) Framework to ensure effective enterprise
governance of information and technology. Specific focus on enterprise governance of
information and technology (EGIT) enables both business and IT people to execute their
responsibilities in support of business/IT alignment.
Once the control objectives are synthesized, we use this along with the Business Risk
Model to assess current state of security. To manage risk, you first need to identify the sources
of risk (threats) and assess their significance (the likelihood of the risk event and the impact on
your business assets should it materialize). Since this deliverable is dependent on a proceeding
layer of inputs, we will discuss what we would expect as an input, how we would process that
information and develop a representative output deliverable by describing how we would go
about developing the required deliverable. We would employ a risk assessment methodology to
develop the business risk model where we would assess the vulnerabilities (weaknesses in how
IBFS is operated) and the associated impact (the level of damage IBSF would sustain if a threat
event successfully exploited the vulnerability or weakness). These risks would be assessed with a
qualitative (low, medium, high) value. The purpose of this type of risk assessment is to (1)
understand the risk profile in detail and (2) make well-informed risk management decisions.

Description of the Architectural Layering to be employed.

We have adopted the multi-layered security approach, which increases the effectiveness
with multiple layers of security of different types. Multi-layered security avoids any single point
of failure. Protecting your customers’ privacy and trust is integral to your continued success and
having this multi-layered security approach is highly recommended. Addressing your existing
Conceptual Architecture: IBFS 10

vendor strategy, we propose the provisioning of security infrastructure required of security

services including common security services Application Program Interface (API) architecture
security middleware, security services on platforms (systems) and security services imbedded in
the network. At subsequent layers of the SABSA model, it is likely that vendor specific off-the-
shelf components will be selected; to integrate these products into your architecture, we propose
the construction of enterprise common security services API as a series of layered APIs. Note:
this API model implies a sound overall software architecture designed from the beginning to be
able to support the extensibility and functional substitution at the lower levels. Enterprise
common security services API will be maintained in-house by IBFS’s systems development
team.
Addressing the current state of stovepipe model legacy applications, we propose a
strategic architecture to ensure there is an overall vision of how applications are built and hits
integration capabilities. Provisioning a central data repository, shared between the applications
was considered in the conceptual layer. The central repository is surrounded by individual
applications which utilize the central data repository and the common services. Both the
common services and the applications are integrated through a series of common interfaces
(APIs).
We propose a security administration to provide application security, which is
summarized under the six as:
1) Authentication (the process of granting privilege)
2) Authentication (the process of verifying identity)
3) Access Control (the process of making access decisions based on checking
authorizations and authentication identity).
4) Audit (the process of writing, storing and reviewing records of all access attempts,
decisions and outcomes)
5) Administration (administering privileges and all associated activities)
6) Application-to-application communications security
There are several benefits to integrating application security including the ability for a
single authorization database. The industry is in a constant state of change regarding mergers,
acquisitions, divestments and joint ventures. Having a single authorization database will provide
better control over total user privileges, less risk of dormant accounts, and the ability to block or
delete a user’s access to all applications from a single action (for leavers). Further, having a
single sign-on for users will provide better password control and ease of use.

A series of break-out documents, each describing a major security strategy.

Role-Based Access Control

The Authentication, Authorization and Audit Strategy is mapped to control objectives and to the
Business Attributes Profile described above. Role-Based Access Control (RBAC) is a major
architectural approach needed to deliver the said benefits of an integrated application security
architecture. The RBAAC architecture will alleviate problems faced when integrating access
control in many legacy systems. RBAC will provide IBFS with a single central authentication
service where each user is registered only once on the centralized authentication service registry.
This reduces the risk of leaving dormant accounts and reduces the administration required,
especially following mergers, acquisitions and joint ventures. Further, RBAC allows for each
subject to be allocated one or more roles which are stored in the centralized subject registry.
Conceptual Architecture: IBFS 11

Each target system will then be setup to register roles rather than individual subject names in the
access control list. For an added layer flexibility, we propose cryptographic mechanisms where
the transmission of a password is replaced by a cryptographic authentication exchange protocol
between he client workstation and the central access manager (CAM); this effectively decouples
user-to-machine and the machine-to-machine interfaces, allowing great architectural flexibility to
adopt future technologies since any single mechanisms (user-to-client, client-to-CAM, CAM-to-
server) can be replaced with another mechanism without interfering with the working of others.
Lastly, RBAC provides the ability to hold every subject accountable for his or her actions as
local audit trails are stored at the target system.

System Assurance Strategy

Our system assurance strategy is concerned with the correctness, reliability and proper
operations of systems. We propose the following strategic areas of control for IBFS:
 Software integrity protection and anti-virus controls
 Content filtering to keep out unauthroized and illegal data
 Protecting the integrity of mobile code (e.g. Java applets, ActiveX, scripts)
 Functioning testing
 Penetration testing
 Security auditing
 Redundancy of componenets
 Fault-tolerant architecture

Directory Services Strategy

We propose a Directory service strategy, which is an example of security infrastructure
architecture described above; it is the centralized repository of much security-related information
about system objects. Each directory entry holds registration details of all objects of all object
classes in the form of a distinguished name plus a variety of attributes. The directory attributes of
objects will include all location and contract details, credentials, roles, privileges, certificates,
authentication values, status information, state variables and cryptographic keys.

The security entity model and trust framework.

The financial industry is based almost entirely on trust. We developed a security entity
model and trust framework to protect this asset. The actions of security entities need to be
controlled through authorization processes and through technical and procedural controls that
enforce the authorizations. Further there needs to be global unique naming of each entity and the
directory described above is the repository for holding infomration on all security entities.
At IBFS our security entity relationships are primarily bilateral in that two entities (e.g.
IBFS and our clients) make a specific contract to transact business and exchange infomration.
This security entity relationship implies a certain degree of trust, where both must trust each
other. There are also variable levels of trust that can be associated with a business transaction.,
and digital certificates can be used to broker such transactions. For certain applications at IBFS,
a security entity will also need a banker’s reference to testify credit worthiness and credit history
over an extended period. In this example of a business transaction, a high assurance registration
is appropriate. Further verifying credentials often involves transitive trust as is the case with the
use of birth certificates, passports, driver’s license, banker’s reference, personal references, are
all examples of transitive trust, where an independent trusteed third party is being used to verify
Conceptual Architecture: IBFS 12

some aspect of the claimed identify or trustworthiness. Difference levels of trust leads to
different classes of digital certificates. We propose the following guide for recommended level
of trust. See table 5 in the appendices for details.

The security domain model.

The security domain model is a powerful component of the security architecture. We
would define inter-domain relationships included identifying isolated security domains
independent security domains, sub-domains and super-domains. The key element there is the
trust in domains. The domain policy authorities must agree on a set of security policy rules for
governing the exchange of information between domains. This set of rules settle a set of common
security services and common security mechanisms. Logical domains will be protected by the
RBAC described above. Physcial domains will be protected by firewalls, doors, locks, gates,
guards, etc. so as to apply tamper resistant mechanisms.

A list of security related lifetimes and deadlines to be addressed at lower layers.

In lower layers of the SABSA model, the following security lifetimes and deadlines will
be addressed: Registration Lifetimes; Certification Lifetimes; Cryptographic Key Lifetimes;
Policy Lifetimes; Rule Lifetimes; Password Lifetimes; Token Lifetimes; Message Time to Live;
Stored Data Lifetimes; Data Secrecy Lifetimes; User Session Lifetimes; System Session
Lifetimes; Response Time-Out; Inactive Time-outs; Context-Based Access Control; Replay
Protection; Trusted Time; Time Stamps; Time Performance Issues.

Discussion

The conceptual layer of the SABSA model is the conclusion of what is called the strategy
and concept phase, within which high-level strategy is developed and agreed upon. The
conceptual layer is often referred to as the architect’s view since it is concerned with a high-level
overview of what assets need protection, why it’s important to the business and how to protect
those assets. It is the vision for the entire security architecture and aims to align the Business
with ICT.
IBFS’s strategy is based upon maintaining its leadership position in the marketplace.
This has been accomplished by continuing the restructure its organization and re-engineering it’s
business processes to keep abreast of a rapidly changing and developing financial services
market. Currently, IBFS is focused on harnessing new technologies to improve efficiencies in
existing business sectors as well as to enable new lines of business and new methods of
marketing and distribution. The conceptual layer will serve to provide a framework for
subsequent layers of the SABSA model to enable this business strategy.

Conclusion

You should work the introduction backwards recapping what the reader should have
learned and where they should go from here after reading the paper.
Clear demonstration of a return on value.
Your business strategy is based upon maintaining your leadership position in the
marketplace.
Conceptual Architecture: IBFS 13

In reading this proposal, you should now have a better understanding of how the
conceptual architecture addresses your business, its security needs, as well as how the conceptual
architecture fits into the SABSA model. Further, the reader should now understand the
significance in having a holistic approach with the security architecture as it enables your
business to achieve its objectives. With a sound security architecture, IBFS will continue to be a
leader in the market and leader in innovation.
Conceptual Architecture: IBFS 14

References

Sherwood, N., Clark, A., & Lynas, D. (2005). Enterprise Security Architecture: A Business-
Driven Approach. San Francisco: CMP Books.
Conceptual Architecture: IBFS 15

Tables
Table 1
Business Drivers for IBFS
Drive Number Business Drivers

BD1 Protecting the reputation of IBFS, ensuring that it is perceived as

competent in its sector
BD2 Providing support to the claims made by IBFS about its competence
to carry out its intended functions
BD3 Protecting the trust that exists in business relationships and
propagating that trust across remote electronic business
communications links and distributed informatino systems.
BD4 Maintaining the confidence of other key parties in their
relationships with IBFS
BD5 Maintaining the operational capability of IBFS’s systems.
BD6 Maintaining the continuity of service delivery, including the ability
to meet the requirements of service level agreements where these
exist.
BD7 Maintaining the accuracy of information.
BD8 Maintaining the ability to govern.
BD9 Preventing losses through financial fraud.
BD10 Detecting attempted financial fraud.
BD11 Providing the ability to prosecute those who attempt to defraud
IBFS.
BD12 Ensuring that the solutions provided for securing electronic
business services include a clear and unambiguous definition of
responsibility and liability for all parties at every stage of the
transaction.
BD13 Providing and maintaining the ability to resolve disputes between
IBFS and any other parties, quickly, efficiently and with minimum
cost.
BD14 Ensuring that information processed in IBFS’s systems can be
brought to a court of law as evidence in support of both criminal
and civil proceedings and that the court will admit the evidence,
and that the evidence will withstand hostile criticism by the other
side’s expert witnesses.
BD15 Ensuring that the informatino security approaches used in the
systems directly support compliance by IBFS with commercial
contracts to which IBFS is a party.
BD16 Ensuring that IBFS is at all times compliant with the laws and
industry sector regulations, and that the information security
approach in the systems directly and indirectly supports legal
compliance.
BD17 Maintaining the privacy of personal business information that is
stored, processed and communicated by IBFS’s systems.
BD18 Protecting against the deliberate, accidental or negligent corruption
Conceptual Architecture: IBFS 16

of personal and business information that is stored, processed and

communicated by the systems.
BD19 Ensuring that an entity that makes a business transaction cannot
later deny having made the transaction, and that the entity will be
bound by the contractual obligations associated with making the
transaction.
BD20 Ensuring that all users can be held accountable for the actions that
they take in making use of their access privileges.
BD21 Ensuring that all users can be held accountable for the actions that
they take in making use of their access privileges.
BD21 Ensuring that access privileges are designed and implemented in
such a way as to minimize the risk of a single individual having
excessive power that could be abused without easily being detected.
BD22 Providing a means by which IBFS can monitor compliance with its
various information security policies and can detect, investigate and
remedy any attempted or actual violations of those policies.
BD23 Providing assurance of the correct functioning of IBFS’s systems
and sub-systems.
BD24 Providing for the setting of policy and the control and monitoring
of compliance with policy by the authorities vested with
responsbilities for corporate governance n the sytem environment.
BD25 Protecting other parties with whom IBFS has business dealings
from abuse, loss of business or personal information.
BD26 Ensuring that employees using the system are only granted
authorized access within need-to-know and need-to-use privileges.
BD27 Ensuring the system security solution is cost-effective and provides
good value for money.
BD28 Ensuring that the security of IBFS’s information is dependent only
upon its system security measures and not on the security
competence of any other organization.
BD29 Ensuring that the granularity of system security services is
appropriate to business need.
BD30 Preserving the ability of authorized business users to maintain a
high level of productivity.
BD31 Ensuring that information security interfaces are easy and simple to
use.
BD32 Utilizing, where possible, commercial off-the-shelf products to
build information security solutions.
BD33 Ensuring that security services can be extended to all user locations,
to all interface types and across all network types that will be used
to support delivery.
BD34 Maximizing the economic advantage of the enterprise security
architecture.
BD35 Supporting security services through electronic communications,
without the need for phsycial transfer of documents or storage
media.
Conceptual Architecture: IBFS 17

BD36 Ensuring that system security solution comply as far as possible

with internal and external standards and best practices.
BD37 Ensuring that the security architecture is independent of any
specific vendor or product and can support multiple products from
multiple vendors.
BD38 Ensuring that the security architecture remains compatible with new
technical solutions as these evolve and become available, and with
new business requirements as these emerge, with minimum
redesign.
BD39 Adapting the security architecture to counter new threats and
vulnerabilities as they are discovered.
BD40 Ensuring that the required internal and external cultural shift is
achieved to support the security architecture.
BD41 Ensuring accurate information is available when needed.
BD42 Minimizing the risk of loss of key customer relationships.
BD43 Minimizing the risk of excessive loading on insurance premiums
due to negligence on IBFS’s behalf or lack of due diligence.
Conceptual Architecture: IBFS 18

Table 2
Business Attribute Profile IBFS
Business Business Metric Measurement Approach Performance Target
Attribute Driver Type
Private DB17 Hard Reporting of all Zero successful attempts at
unauthorized disclosure unauthorized disclosure.
incidents, including
number of incidents per Alerts of unauthorized access attempts
period, severity and type produced and delivered to system
of disclosure. manager and business owner monthly.
Private DB17 Soft Independent audit and System passes review by independent
review with respect to legal and forensic authority to a degree
the prevention of deemed acceptable by the legal group
unauthorized disclosure to prevent prosecution under EU Data
of private information. Protection legislation.
Liability- BD26 Soft Independent legal expert Independent review by ABC Legal
Managed review of all applicable Group with respect to IBFS’s ability to
contracts, Service Level demonstrate system services are
Agreements, etc. designed, implemented and operated
so as to manage the liability of the
organization with regard to errors,
fraud, malfunction and so on.
Capturing BD9, Hard Percentage of vendor- A summary of reports of the
New Risks BD10 published patches and percentage installed vendor patches,
upgrades actually produced and delivered to Juan Carlos,
installed. Chief Operating Officer monthly.
Capturing BD9, Soft Independent audit and Independent audit and review by ABC
New Risks BD10 review against Security Consulting Firm with respect to
Architecture Capability IBFS’s ability to demonstrate system
Maturity Model of a mangement and operational
documented risk environment ability to provide means
assessment process and to identify and assess new risks.
a risk assessment
history.
Compliant BD16, Soft Independent compliance Independent audit and review by ABC
BD22, audit with respect to the firm with respect to IBFS’s ability to
inventories of pass compliance audit.
regulations, laws,
policies etc.
Admissible DB11, Soft independent audit and Independent audit and review by ABC
BD14 review against Security firm with respect to IBFS’s ability to
Architecture Capability provide forensic records that will be
Maturity Model by admissible in a court of law.
computer forensics
expert.
Flexible BD5, Soft Independent audit and Independent audit and review by ABC
Conceptual Architecture: IBFS 19

and BD7, review against security Internal Audit and Legal Group with
Adaptable BD41, architecture capability respect to the ability to provide proof
BD42 maturity model of of the transaction flow and individual
technical architecture accountability on all transactions.
Inter- BD5, Hard Specific inter- Exception report detailing all incident
operable BD7, operability requirements of manual adjustments to information
BD38.
BD41, Identify and develop rules and data
BD42 elements for sharing.
Legacy- BD5, Soft Independent audit and Independent audit and review by ABC
sensitive BD38 review against seucirty consulting firm with respect to the
architecture Capability system’s ability to work with any
Maturity Model of legacy systems or databases with
technical architecture which it needs to inter-operate or
integrate.
Architectur BD28, Soft Independent audit and System passes review by ABC
ally open BD37 review against Security consulting firm with respect to ability
Architecture Capability to allow flexibility in the choice of
Maturity Model or vendors and products, both initially
technical architecture. and in the future.
Usable BD31 Soft Numbers of licks or Monthly report of on all customer
keystrokes required. feedback relating to usability and
delivered to Brian Jones, Sr. Vice
Conformance with President, Marketing and Distribution.
industry standards – e.g.
color palettes. Report from quarterly customer and
non-customer focus groups delivered
Feedback form focus to Brian Jones, Sr. Vice President,
groups. Marketing and Distribution.

Monthly report of numbers of clicks or

keystrokes required sent to Brian
Jones, Sr. Vice President, Marketing
and Distribution
 Conceptual Architecture: IBFS

Table 3

Business Risk Model Example

Target Vuln Value

Mitigated Risk Cat

Business Driver

High-level Contr. Obj.

Business Attributes

Business Requirement

High-Level Threat

Business Impact

Impact Value

Green Field Vuln Value

Green Field Risk Cat

ID

Potentially High-Level
Vuln
BD001 The
Customer
is King
BD Customer Usability Security feats. Customer be- Many cus- H Multiple H A Establish L C
001-1 experience Of any cus- comes frus- tomers go logins and Red consistent, Green
impacts tomer-facing trated by diffi- somewhere authentica- easy-to-use
competitiv business sys- cult login pro- else where tions, each authentication
e tem must not cesses and the experi- requiring a and login
advantage/ create diffi- other security ence is easier new pass- procedures
disadvant. culties in use feats. word
BD001-2 Business in Trustworthy Customers Customer de- Wide loss of H Inadequate H A Establish L C
the future Private who provide tails disclo- customer control over Red strong phy- Green
will be cus- Confidential private infor- sure to un- confidence. privacy of in- csial security
tomer- mation must authroized formation. surrounding
driven be confident parties and Censure or all customer
that it will be this becomes prosecution data in transit,
protected generally by the regu- during pro-
from disclo- known lators. cessing and in
sure. Eventual loss storage.
of operating
license. Establish
 Conceptual Architecture: IBFS 21

strong logical
security sur-
rounding all
consumer data
in transit, dur-
ing processing
and in stor-
age.
BD002 We Must
Comply
with the
Law
BD002-1 Data Compliant Must comply Customer Wide loss of H Inadequate H A Establish L C
protection Private with data details customer control over Red strong phy- Green
legislation Confidential protection disclosed to confidence. privacy of csial security
legislation unauthroized information surrounding
parties, and Prosecution all customer
this becomes by the data in transit,
generally regulators. during pro-
known. cessing and in
storage.

Establish
strong logical
security
surrounding
all consumer
data in transit,
during
processing
and in
storage.
Conceptual Architecture: IBFS 22
Conceptual Architecture: IBFS

Table 4
CobiT Control Objectives Mapped to Business Attributes
Business Control Objective Description Objective Purpose Statement
Attribute Objective
Private Managed Protect enterprise Minimize the business impact
Security information to maintain the of operational information
Services level of information security vulnerabilities and
security risk acceptable to incidents.
the enterprise in accordance
with the security policy.
Establish and maintain
information security roles
and access privileges.
Perform security
monitoring.
Liability- Managed Plan, scope and execute Enable the organization to
Managed Assurance assurance initiatives to design and develop efficient
comply with internal and effective assurance
requirements, laws, initiatives, providing
regulations and strategic guidance on planning,
objectives. Enable scoping, executing and
management to deliver following up on assurance
adequate and sustainable reviews, using a road map
assurance in the enterprise based on well-accepted
by performing independent assurance approaches.
assurance reviews and
activities.
Capturing New Ensured Risk Ensure that the enterprise's Ensure that I&T-related
Risks Optimization risk appetite and tolerance enterprise risk does not
are understood, articulated exceed the enterprise's risk
and communicated, and appetite and risk tolerance,
that risk to enterprise value the impact of I&T risk to
related to the use of I&T is enterprise value is identified
identified and managed. and managed, and the
potential for compliance
failures is minimized.
Compliant Managed Evaluate that I&T Ensure that the enterprise is
Compliance processes and I&T- compliant with all applicable
with External supported business external requirements.
Requirements processes are compliant
with laws, regulations and
contractual requirements.
Obtain assurance that the
requirements have been
identified and complied
with; integrate IT
Conceptual Architecture: IBFS 24

compliance with overall

enterprise compliance.
Admissible Managed Evaluate that I&T Ensure that the enterprise is
Compliance processes and I&T- compliant with all applicable
With External supported business external requirements.
Requirements processes are compliant
with laws, regulations and
contractual requirements.
Obtain assurance that the
requirements have been
identified and complied
with; integrate IT
compliance with overall
enterprise compliance.
Flexible and Managed Provide a holistic view of Support the digital
Adaptable Strategy the current business and transformation strategy of the
I&T environment, the organization and deliver the
future direction, and the desired value through a road
initiatives required to map of incremental changes.
migrate to the desired Use a holistic I&T approach,
future environment. Ensure ensuring that each initiative is
that the desired level of clearly connected to an
digitization is integral to overarching strategy. Enable
the future direction and the change in all different aspects
I&T strategy. Assess the of the organization, from
organization’s current channels and processes to
digital maturity and data, culture, skills, operating
develop a road map to model and incentives.
close the gaps. With the
business, rethink internal
operations as well as
customer-facing activities.
Ensure focus on the
transformation journey
across the organization.
Leverage enterprise
architecture building
blocks, governance
components and the
organization's ecosystem,
including externally
provided services and
related capabilities, to
enable reliable but agile
and efficient response to
strategic objectives.
Conceptual Architecture: IBFS 25

Inter-operable Managed Establish a common Represent the different

Enterprise architecture consisting of building blocks that make up
Architecture business process, the enterprise and its
information, data, interrelationships as well as
application and technology the principles guiding their
architecture layers. Create design and evolution over
key models and practices time, to enable a standard,
that describe the baseline responsive and efficient
and target architectures, in delivery of operational and
line with the enterprise and strategic objectives.
I&T strategy. Define
requirements for taxonomy,
standards, guidelines,
procedures, templates and
tools, and provide a linkage
for these components.
Improve alignment,
increase agility, improve
quality of information and
generate potential cost
savings through initiatives
such as re-use of building
block components.
Legacy- Managed Assets Manage I&T assets through Account for all I&T assets
sensitive their life cycle to make sure and optimize the value
that their use delivers value provided by their use.
at optimal cost, they remain
operational (fit for
purpose), and they are
accounted for and
physically protected.
Ensure that those assets
that are critical to support
service capability are
reliable and available.
Manage software licenses
to ensure that the optimal
number are acquired,
retained and deployed in
relation to required
business usage, and the
software installed is in
compliance with license
agreements.
Architecturally Managed Manage I&T-related Optimize available I&T
open Vendors products and services capabilities to support the
Conceptual Architecture: IBFS 26

provided by all types of I&T strategy and road map,

vendors to meet enterprise minimize the risk associated
requirements. This includes with nonperforming or
the search for and selection noncompliant vendors, and
of vendors, management of ensure competitive pricing.
relationships, management
of contracts, and reviewing
and monitoring of vendor
performance and vendor
ecosystem (including
upstream supply chain) for
effectiveness and
compliance.
Usable Managed Define and maintain Provide sufficient information
Configuration descriptions and about service assets to enable
relationships among key the service to be effectively
resources and capabilities managed. Assess the impact
required to deliver I&T- of changes and deal with
enabled services. Include service incidents.
collecting configuration
information, establishing
baselines, verifying and
auditing configuration
information, and updating
the configuration
repository.
Conceptual Architecture: IBFS 27

Table 5
Registration Assurance Level Implication for Level of Trust
Self-registration This allows very quick sign-up for customers
on a click-and-go basis. It is suitable only for
services publicly available within the user’s
environment where the only service provider
interest is in collecting general information on
how many and which users are registering for
the service. There can be no attempt made
here to ensure that the registered user is the
authentic owner of the name claimed.
However, this approach may be suitable for
certain web-based services.
E-mail registration This allows quick sign-ups by allowing the
user to be authenticated based upon the
possession of an e-mail address with a given
domain name, indicating that the user belongs
to an organization with that domain name.
The level of authentication is weak, and the
use of the domain name credentials will not
cover all situation, especially for staff with
other e-mail addresses. However, for certain
low-assurance applications, this may be
suitable.
Web-based credit card registration In this case the user self-registers but proves
more about his identity by supplying a valid
credit card number. This is still relatively
weak registration process in which it is easy
to supply a fraudulent card number, bot for
low-assurance applications where small
payments are involved and a level of fraud
can be tolerated, this may be a suitable
method. Suitable applications will include
low-value information services.
Telephone confirmation Adding a telephone confirmation process can
augment each of the previous three methods.
The user is telephoned at a number obtained
independently of the initial registration (‘out
of band’), and certain details are verified in
the conversation. This eliminates certain
types of impersonation.
Postal registration In this case the entity sends an application for
registration through the post, enclosing
documentary evidence of identity and
membership of the given business community.
The policy of the registration authority
Conceptual Architecture: IBFS 28

determines the strength of this process,

specifying whether copies or orignal
document are required and how many
documents of what type must be presented.
Personal registration This is where an individual must attend in
person to a registration office and present
credentials for verification. The registration
process can be made as rigorous as is required
for the business environment and is entirely
up to the registration authority in determining
the registration policy.
Transferred registrations Existing client databases can be used as
sources of registration data. In this case
previous registration details obtained for
another purpose are accepted as suitable and
are transferred to this application.
Delegate or multi-tiered registration In this case a registration authority registered
a sub-registration authority that is delegated
with the responsibility for registering user
within its own domain. These delegated
registration authorities are often known as
local registration authorities. There could
potentially several levels or tiers of
delegation.
Conceptual Architecture: IBFS 29

Table 6
Conceptual Architecture: IBFS 30

Category Color Code Description Required Actions

A Red Severe Risk Immediate corrective actions are
required either to reduce the
vulnerability or to reduce the
impact level, or both. These risks
are the highest priority.
B Yellow or Significant Appropriate corrective actions
Amber Risk should be planned and executed so
as to reduce the vulnerability or the
impact level.
C Green Acceptable These risks are acceptable, because
Risk either the vulnerability is at its
lowest possible, or the impact is
minor, but they should be
monitored to ensure that they do
not creep into the B category.
D Blue Negligible No action needed.
Risk