You are on page 1of 42

Security Architecture 2002

TABLE OF CONTENTS
Executive Summary ........................................................................................................ 1
1. Introduction General Security Services .................................................................... 2
2. User Types and Roles .............................................................................................. 6
2.1. User Types ....................................................................................................... 6
2.2. Anonymous...................................................................................................... 6
2.3. B2C (Business to Consumer) ........................................................................... 6
2.4. Business to Business/ Business to Producers (B2B/P) .................................... 6
2.5. Business to Employees (B2E) ......................................................................... 6
2.6. User Roles ....................................................................................................... 6
3. Information Classification .................................................................................... 7
3.1. Business Secret ................................................................................................ 8
3.2. Business Private ............................................................................................... 8
3.3. Business Confidential ...................................................................................... 9
3.4. Public .............................................................................................................. 9
4. Security Architecture Goals ............................................................................... 10
4.1. Identification and Authentication ................................................................... 10
4.2. Authorization and Entitlement........................................................................ 10
4.3. Integrity ......................................................................................................... 10
4.4. Non-Repudiation............................................................................................ 11
4.5. Privacy........................................................................................................... 11
5. General Security Goals ...................................................................................... 12
5.1. End to End Logging ....................................................................................... 12
6. Existing architecture .......................................................................................... 13
6.1. Identification.................................................................................................. 13
6.2. Authentication services .................................................................................. 13
6.2.1. B2C Identification, and Authentication ...................................................... 14
6.2.2. B2B/P Identification, and Authentication ................................................... 14
6.2.3. B2E Identification, and Authentication ....................................................... 14
6.2.4. Anonymous Identification and Authentication ............................................ 14
6.3. Authentication, data structures and cookies .................................................... 14
6.4. Entitlements and Authorization Services ........................................................ 15
6.4.1. B2C and B2B/P Channel Issues.................................................................. 15
6.4.2. Entitlement and Authorization System ....................................................... 15
6.5. Integrity ......................................................................................................... 17
6.6. Non-Repudiation............................................................................................ 18
6.6.1. B2C Non-Repudiation ................................................................................ 18
6.6.2. B2B/P Non-Repudiation............................................................................. 19
6.6.3. B2E Non-Repudiation ................................................................................ 19
6.6.4. Non-Repudiation and the Interactive Voice response System ..................... 20
6.7. Privacy........................................................................................................... 20
6.8. Issues around username and password systems .............................................. 20
7. Existing Architecture Identity Management ....................................................... 21
7.1. Creation of Electronic Identities ..................................................................... 21

i
7.2. Disabling and Removal of Electronic Identities .............................................. 21
7.3. Modification of an Electronic identity ............................................................ 22
7.4. Personalization............................................................................................... 22
8. Engineering Future State.................................................................................... 22
8.1. Identification and Authentication Services ..................................................... 22
8.2. New Directory Structure must be Deployed ................................................... 22
8.3. Authorization and Entitlement Services.......................................................... 22
8.4. Integrity ......................................................................................................... 22
8.5. Privacy/Integrity ............................................................................................ 23
8.6. Non-Repudiation services .............................................................................. 23
8.7. Public Key Infrastructure ............................................................................... 23
Appendix A: General Directory Services ....................................................................... 23
General Directory Architecture .................................................................................. 24
Synchronization between the Core and Client Directories .......................................... 24
Appendix B: Public Key Infrastructure (PKI) Services .................................................. 26
General PKI Architecture .......................................................................................... 26
Trust Model ........................................................................................................... 27
Scalability & Single Points of Failure .................................................................... 28
Appendix C: Network design and Access ...................................................................... 29
General Architecture ................................................................................................. 29
Two, Three and N-Tier Application Architecture Support...................................... 29
Network Load-Balancing ....................................................................................... 31
Security Services ................................................................................................... 31
Technologies Used ................................................................................................ 31
Network Access......................................................................................................... 32
Definition .............................................................................................................. 32
Architecture ........................................................................................................... 32
Consumer .............................................................................................................. 32
B2B/P .................................................................................................................... 32
VPN and Other Special Network Access ................................................................... 32
Definition .............................................................................................................. 32
Architecture ........................................................................................................... 32
Technologies Used ................................................................................................ 33
Non Standard out-bound access ............................................................................. 33
Appendix D: Digital Signature Services ........................................................................ 34
PKI Architecture ....................................................................................................... 34
Desktop & software deployment considerations ......................................................... 34
XYZ Information Classification Policy.......................................................................... 35
Bibliography ................................................................................................................. 37

Table Of Figures
Figure 1. Methods of Trust .............................................................................................. 3
Figure 1 Entitlements System......................................................................................... 17
Figure 3. Synchronization between the Core and Client Directories .............................. 25

ii
Figure 4. The PKI Trust Model...................................................................................... 27
Figure 5. Generalized Secure Network Architecture ...................................................... 30

iii
Revision History

iv
Executive Summary
Security is normally viewed as those measures taken to keep something safe from
unauthorized access. All around us, we have the visual impact of guards, fences, alarms,
signs and all manner of locking devices that we equate with the notion of security. While
this has been the traditional role of security in our society it is not a fully accurate picture
of what security does for us. All of the methods mentioned previously, exist for a more
important reason, which is to allow those with similar levels of trust to work in a worry
free environment. If we think about a home, the use of locked doors, windows, and
alarms are more about allowing those within the home freedom of movement within their
own domain rather than a fortification against an external threat. The use of guards and
passes at a place of employment allows freedom of movement and sharing by the
employees within those premises.

It is this same notion of freedom of movement and sharing that has catapulted Systems
Security from its backroom habitat to the forefront in publicity. The normal low profile
and visibility of security is related to its historical role as a protective mechanism rather
than an enabling one. With the advent of commerce via electronic media, the Internet and
its related delivery channels, Security has moved from its historical protective role to that
of enabler of electronic business. While this new role for security still requires all of the
protective methods of its heritage, it is now being crafted to apply these methods in such
a way as to allow sharing between consumers and businesses in a trusted environment.

The following document outlines the Architecture for applying security to these same
issues of sharing and trusts at XYZ. The over-arching goal of our Security Architecture
is to enable business via electronic media both within The Company and outside with our
prospective customers, existing clients and business partners.
There are several issues that are outside of the scope of this document. These include
legal issues, policy issues and Disaster Recovery and Business continuity Planning.

1
1. Introduction General Security Services
1.1. Scope
This document describes what web based security services are available in XYZ now and
what web based security services will be available in the near term. This document does
not deal with existing Main Frame applications or legacy applications.

1.2. Audience
This document is for developers, vendors, partners, and XYZ Architects.

1.3. Definitions
The security architecture is the blueprint for joining the various services that comprise a
security complex into a cohesive whole that implements the notion of a trusted, shareable
environment for e-business. The following services provide an extensible security
complex for today’s business requirements and beyond.

• Identification/ Authentication – The ability to determine whom an individual is and that


the presenter of that identity is indeed the owner of the identity.

• Authorization/Entitlement – The ability to determine what information a user is


authorized and entitled to see, interact with, transmit, update, or carry with them beyond
the premises of the corporation. These entitlements can be based upon corporate data
classifications or upon the extension of business relationships. (i.e., a consumer has the
right to see their policy information, but only a sales agent with a relationship to that
client can see that same policy information)

• Integrity – The ability to ensure that data has not been modified in an unauthorized
manner when in transit or while being stored.

• Non-Repudiation – the ability to prove that a specific individual performed a specific


action at a specific time.

• Privacy – The process by which information is protected from eavesdropping as well as


protecting data during transmission and storage.

1.4. Identification and Authentication


An identity is a unique value that is used to track a user in a computer system. The most
common form of identity is a username. Typically, these identifiers are public
knowledge. However, when an identifier is presented to a computer system, some type
of secretive authentication method must occur in order to validate the user’s identity.
Authentication methods come in several variations:

• Something you know

• Something you have

• Something you are

2
Something you know is the most common method of authentication. An excellent
example of this is the use of ACF2 ID and password within XYZ. Employees are
assigned a unique ACF2 id that will identify them to the systems throughout the
organization. Whenever that ID is presented to a system, the user is requested to supply a
password as well. Something you have is a stronger authentication alternative to
username and password. Some examples of something you have include OTP-FOB
Cards, and Digital Certificates. Note that since most digital certificates are held in
software they can be copied possibly without the owner knowledge. This is not the case if
the certificate is held in hardware. Thus a digital certificate, depending on how it is stored
lies between something you know and something you have.

For a person to take over the identity of another, that person must have possession of the
“thing” that the individual uses to identify and authenticate them self. Something you are
is the strongest method of authentication. It is the strongest method because it is the
hardest thing to forge. These methods include biometrics such as fingerprints or retinal
geometry. It is important to note that, even though these alternatives offer an increased
level of security, they still must be authenticated prior to being trusted by the system.

High

Data
Sensitivity

Low
Something Something Something
you know. you have. you are.

Authentication Methods

Figure 1. Methods of Trust

The methods of trust placed in an identity are based on the method of authentication.
Clearly the stronger the method of authentication the greater the trust in that identity and
therefore the more services may be offered. The method of authentication required is
driven by the sensitivity of the information or the action being undertaken. Figure 1
illustrates the levels of authentication. The weakest form of authentication is something
you know. Since anyone can be told a username and password any person can easily
impersonate another person. A stronger method of authentication is having something
such as an OTP-FOB card or private key. The strongest method of authentication

3
available is something you are. This includes fingerprint or retinal geometry. Most
authentication systems use some combination of these methods for example a smart card
and a PIN to unlock it.

1.5. Authorization and Entitlement


After a user is identified and authenticated, there must be some way of determining what
information the user can access and what actions the user can perform in the system. For
example, the methods used in determining if a client is entitled to access an application,
view information or change information on a policy is called the Entitlement service. The
Entitlement service implements two basic components.

• Roles - Roles define what an individual can and cannot do. Typically these roles are
stored in a directory either as group membership or as a collection of user attributes in the
directory. .

• Rules - A method of applying roles to a function. Rules need to be supplied to the


application in some trusted manner that binds the roles to a user or process.

1.6. Integrity
Integrity ensures that information, whether stored on some media (hard drive etc.) or
communicated between two parties is protected from unauthorized modification. Integrity
services can be provided by encryption, detailed audit trails, logging and other controls.
1.7. Non-Repudiation
Non-repudiation is the ability to prove that an individual performed an action, and
optionally, prove the action occurred at a specific time. The proof must be strong enough
that the person performing the action cannot later reasonably deny that the action was
taken. An example of non-repudiation is a notarized signature or a security camera that
proves a person’s physical presence. Non-repudiation relies on very strong identification
and authentication of the user. When strong non-repudiation is required, the need for
strong authentication often precludes the use of usernames and passwords as the sole
method of identification. Non-repudiation has several implications:

• Does XYZ need to provide proof that an individual preformed a specific action? If so,
then a stronger1 identification and authorization method should be employed to identify
the user.

• Does XYZ need to provide proof that an approved individual preformed a specific action
at a specific time? If so, then a stronger 2 identification and authorization method should
be employed to identify the user as well as requiring a timestamp from a trusted time
source.

1
In this case “stronger” means stronger then a user name and password. To prove a person did something a
biometric may be required. See Identification and Authentication for more information about methods of
authentication.
22
In this case “stronger” means stronger then a user name and password. In this case a hardware token
may be sufficient. See Identification and Authentication for more information about methods of
authentication.

4
1.8. Privacy
Privacy is the foundation of any security architecture. Depending upon the sensitivity of
the information it must be rendered unreadable to any unauthorized people whether it is
stored on some media, or transmitted over a network. It is the ability to supply
information only to those who are permitted to see it and have a need-to-know and to
keep it away from those who are not. For example, access to customer policy
information, which may contain sensitive financial information, should be viewable only
by a specific group of employees such as agents or brokers.
Privacy is broken up into two (2) classes. Who can see the data in transmission, and who
can see it while in storage. Privacy is related to several other areas that will be dealt with
including, user roles, data classification and authorization.

5
2. User Types and Roles
2.1. User Types
There are three basic user classes, henceforth termed users: Anonymous, Business to
Consumer (B2C), and Business to Business/Agents/Brokers. These will be denoted B2B,
and B2P for business to producer. An employee can fall into any of these roles depending
on what function the employee is performing. Each user class may be required to access
different services and thus different kinds of security services. Thus individuals in the
B2B class may be required to supply a token to authenticate while a B2C user may only
require a username and password. The Goals and Recommendations sections will deal
with the individual requirements.

2.2. Anonymous
These are users that have no existing relationship with XYZ or choose not to identify
themselves. The level of access to XYZ is very limited for anonymous users.

2.3. B2C (Business to Consumer)


The Consumer class is broken down into two subsets. Unless otherwise noted,
Consumers will be used to denote this class as a whole throughout this document.

• Clients – a Client is an individual that holds one or more XYZ financial contracts. A
Financial contract is a XYZ Policy.

• Prospects – a Prospect has a relationship with XYZ, but does not own a financial
contract. For examples someone applying for a policy or is filling out a financial plan.

2.4. Business to Business/ Business to Producers


(B2B/P)
These are all classified together as fundamentally as business to business. Any
transactions with these parties involve the movement of money, services or information
that is often proprietary and critical to XYZ functioning in an orderly and legal manner.
In most cases all these groups will be dealt with together.

2.5. Business to Employees (B2E)


This is when an individual is acting as an employee of XYZ. This case is different since
the user is assumed to be trusted and will have access to internal functions and systems as
a part of their job.

2.6. User Roles


A user role is representative of the relationship that a person has with the corporation. An
analogous example is found in the family unit, each member has a role (i.e. father,

6
Mother, Child, Grandfather, Grandmother, Uncle, Aunt, etc.), from our own experience
we know and can see that each family member can fulfill multiple roles. For example,
someone can simultaneously be a Father, Grandfather, and Uncle. The role designation is
determined by the relationship that particular individual has with the other members of
the family. By juxtaposing this well known and broadly experienced example onto a
corporation we in turn can recognize that an individual person or external corporate entity
can fulfill or take on multiple roles with the corporation, in this case XYZ. The
corporation is also similar to the abstract concept of the family in the functions it
performs. For example the family entity is thought of as the clearing point for food,
clothing, shelter and support for family members. In like terms the corporation provides
goods and services, acts as a housing and support for its employees and can also be a
partner in a joint venture. Because the corporation has the same multi-faceted role we
find in a family, we recognize that the corporation itself also takes on different roles.
Therefore we can define interactions between an individual and the corporation by
outlining the roles they play and the bounding functionality those roles assume. These
defined interactions then become our macro transactional definitions and levels of access
can be determined by functionality and relationship inherent in the roles associated with
the entities of the transaction.

An example at XYZ is the interaction defined by the corporation as the issuer of a Life
Insurance Policy, the sales agent as the customer facing representative and the consumer
of the financial contract. In this interaction the role of the corporation is one of provider
with the risk assumed by the corporation. The sales agent is the liaison role between the
issuer and the consumer. The role of the sales agent provides functional access to both
the corporation’s records and the consumer’s information. The consumer has access to
the credentials of the sales agent and information on the issuer’s goods. While the
corporation, due to the risk burden, has access to all information on the sales agent, and
the consumer with related financial and health information beyond what the agent can
obtain.

By the above example we can see that the roles bounded both the functional interactions
and information extent of that interaction. By defining and harnessing the actual business
roles within the corporation and solidifying the rules associated with role interactions, the
information security and privacy becomes well defined and concrete.

3. Information Classification
Sensitive XYZ information must be classified according to the XYZ classification model.
Initially, the policy will apply to information covered by the privacy initiative mandated
by legal and regulatory statutes, e.g., Gramm-Leach-Bliley Act (G-L-B), to protect
nonpublic information XYZ holds on its customers. Ultimately, the policy will apply to
all confidential XYZ information.
For a complete list if the information classification guidelines see XYZ Information
classification Policy.

Information Owners are responsible for determining the sensitivity level of information
assets and classifying that information according to its sensitivity and value to the

7
Company. Information Owners are also responsible for changing the classification level
of an information asset.

Information Custodians are responsible for protecting information resources in


accordance with the Information Owners’ specific directions.

The Chief Information Security Officer (CISO) is responsible for managing all aspects of
the information security function enterprise-wide and has the final decision on controls to
protect XYZ information and information systems. The CISO may refer conflicts related
to privacy classification to the Chief Privacy Officer of XYZ.
Users of classified information are responsible for complying with the security controls
designated for the appropriate classification level.

This information is to be used in conjunction with the XYZ Security Roles and
Responsibilities of which details are available at the Information Classification
Guidelines and the Records Protection Policy.

Once the data is classified then a determination can be made about how it should be
protected. A matrix of minimum controls that should be placed on data can be found in
the Information Classification Guidelines
XYZ has 4 classes of information.

3.1. Business Secret


The most up to date definition can be found at Information Classification Policy
• Information that is extremely valuable to the financial success of XYZ. Available only to
named individuals. Very high risk.

• Unauthorized disclosure/destruction would result in grave damage to XYZ: significant


loss of customers, loss of market share, and damage to reputation and confidence in the
Company.

• Requires extraordinary protective measures and procedures; highly restricted access. In


some instances, this data may be so sensitive that it should not be stored on electronic
devices such as laptops. Protection must be absolute.

• Very small proportion of overall company information (1%). Access and viewing only

Examples: business strategies; product development; Merger and Acquisition plans;


financial transactions in excess of specified dollar amounts; and notes that contain
information restricted to only top level executives.

3.2. Business Private


The most up to date definition can be found at Information Classification Policy
• Information that is valuable to XYZ. High risk.

8
• Unauthorized disclosure/destruction would cause damage to XYZ: loss of customers,
embarrassment to the Company, and violation of federal and/or state regulatory
requirements resulting in fines or litigation against the Company.

• Requires protective measures beyond Business Confidential. In certain instances, e.g.,


data on laptops, minimum controls to safeguard Business Private information may not be
sufficient and stronger security safeguards must be employed. Protection is qualified.

• In certain instances, e.g., disputes over classification regarding G-L-B privacy data, the
CISO may refer the matter to the Chief Privacy Officer for resolution.

• Possibly 20-30% of XYZ information falls into this category. Access and viewing is only
for a particular group or persons designated by the Information Owner.

Examples: information that falls under privacy-related statutes, i.e., G-L-B or HIPAA;
nonpublic personal customer information; sensitive customer-identifying information;
customer medical data; certain customer documents; and summarized customer data.

3.3. Business Confidential


The most up to date definition can be found at Information Classification Policy
• Information that is valuable to XYZ. Medium risk.

• Unauthorized disclosure/destruction would cause damage to XYZ: loss of some


customers and some embarrassment.

• Requires protective measures and procedures, but not to the extent of Business Private.

• Wide spectrum of information falls into this category (30-40%).

Examples: financial transactions below a specified amount; non medical personnel


records; business plans; marketing strategies; budgets; security review findings; and
customer account data.

3.4. Public
An up to date definition can be found at Information Classification Policy
• Information that is available from public sources, routine office correspondence available
to the general public. Low to no risk.

• Minimal or no harm to the Company if stolen or destroyed.

• Requires minimal protective measures.

• Approximately 25-35% of information falls into this category.

Examples: advertising materials; public reference materials; and information found in the
XYZ Annual Report.

9
4. Security Architecture Goals
The security architecture is designed to permit all authorized users (B2B/P, B2C, etc.) to
view or modify their data, and purchase New York goods and services. For a complete
description of user classes please refer to chapter 2 “User Types and Roles”.
These goals are expressed as services that XYZ can use to protect itself, its clients,
partners and agents while doing business.

4.1. Identification and Authentication


Identification and Authentication is the ability to determine who an individual is and that
the holder of that identity is indeed the owner of the identity. It is a method of controlling
risk by ensuring that XYZ is conducting business with an approved party. At a minimum
the following Identification and Authentication goals should be achieved:

• B2B/P/E connections must be authenticated based on the kind of information/function


being accessed (See the Information Classification Policy and the XYZ Classification
matrix for recommend methods once a data classification has been made). This means
that a user may be authenticated based on a UserID and password or token.

• B2C connections will mostly use a username and password. The choice of authentication
method depends upon the sensitively of the information that the consumer will access and
what is acceptable to the user population

In general Passwords or any kind of authentication information may not travel through
any section of any network unencrypted. Nor may any authentication information
password be permanently stored or cached on any system that is not the Directory
server3. Any page that requires the entering of a password must be a page protected by
SSL. Once the user is authenticated the user will be given some kind of data structure that
can be passed to the applications.
The over all goal of the XYZ security architecture is to make Identification and
Authentication to any application or system a Network Service. This means that an
application will use this service but will not be responsible for maintaining any user
credentials.

4.2. Authorization and Entitlement


There must be a consistent method of applying entitlement services to applications.
These methods must both be technical and procedural. Thus one method can be used for
all (or at least most) types of users. After a user authenticates they must be entitled to
access only those financial contracts associated with that user. There must be a consistent
way to connect individuals to financial contracts sold and maintained by XYZ.

4.3. Integrity
Data integrity is the systems and processes by which data is preserved between the
present time and the time of the last authorized access. All data that is entrusted to XYZ

3
Note that session caching is permitted, as this is not long-term storage.

10
must be protected against unauthorized modification. This protection must apply to data
in transit as well as data stored in XYZ infrastructure.

4.4. Non-Repudiation
Non-repudiation is the ability to prove that a specific individual performed a specific
action at a specific time. Not all transactions require non-repudiation. As with
identification and authentication, non-repudiation is a method used to mitigate risk by
having “proof” of a user’s action. In electronic interactions non-repudiation is often done
via a digital signature, though this is not the only method.

• For B2B/P electronic transactions the level of non-repudiation must be at least as good or
better then what is currently offered via a paper transaction. Since many B2B/P parties
have digital certificates, a digital signature and possibly a trusted time source is
recommended. This is in addition to the recording of source and destination IP address,
date, resource accessed, and any legal requirements and or agreements.

• For B2C the requirements for non-repudiation are not as strong as with B2B/P due to the
level of authentication that is available to XYZ and the current lack of easily distributed
cryptographic tools. The level of non-repudiation must be at a slightly higher level then
what is offered via a paper transaction. At a minimum the use of a valid username and
password, a record of the date and time, source and destination IP address, and action
taken should be required. This record must be stored in a way that is tamper proof.

4.5. Privacy
XYZ has the goal of maintaining the privacy of a prospect, customer, employee or agent.
Regardless of the role of the person that conducts business with XYZ, we have the
responsibility of fulfilling not only the letter of today’s laws but also the spirit of our
corporate value of integrity. It could be argued that our most important business
proposition with our customers is one of trust. Based upon this trust they place their
assets and future security with our company. In the electronic age that we find ourselves
in, this trust must now be extended to the information and interactions that occur across
the new media channels being implemented as part of the national and international
Internet infrastructure.

In achieving its privacy goals XYZ must:

• Maintain the Privacy of all information and interactions that occur in B2C, B2E and
B2B/P transactions with XYZ via the Internet, Extranet and Intranet.

• Maintain privacy of information supplied to XYZ after it is in our possession.

• Provide the consumer or business partner with options on maintaining the privacy of
information they keep in their possession

• Ensure that XYZ proprietary information is private once it leaves the confines of the
closed corporate network.

11
Maintaining the privacy of information and interactions can be accomplished by using
cryptography and good systems administration. Cryptography implements protocols
during information transmission such as SSL4 or during storage AES5 that encrypt
information using key that is known only to the sender and receiver.
The second goal can be met using a combination of technical means along with policy
and procedures.

5. General Security Goals


The following security goals do not fall into any one specific category however they are
part of any general security architecture.

• Any external access from an un-trusted network to an application or service must pass
through the De-militarized Zone (DMZ) for identification and authentication.

• Any type of service should be supported via the shared connection to the Internet. The
channel and the kind of information accessed will determine what kind and level of
security services required.

• All E-commerce software development initiatives must support industry standard security
API’s.

• The architecture must support authentication and authorization of users across multiple
Web servers and web applications, with a reduced sign-on capability including
interfacing with existing legacy systems. All portions of the architecture must support
this requirement.

• All XYZ Web applications must be able to use a network service to identify and
authenticate users of the site. The solution must allow users who authenticate at
www.xyz.com or other web property owned by XYZ to access all permitted applications
and services. Re-authentication may be required if a user wishes to access a service for
which the original method of authentication is deemed insufficient by the owing business
unit or other authorized party.

• XYZ must be able to control access to objects at a very fine-grained level. At a minimum
the architecture must support the ability for controlling the reading, writing, and
executing of objects at the URL level.

• All security services for any application should be verifiable by a third party if required.
This will allow regular review of permissions by the security administrators or auditors to
ensure an up to date and rational system of permissions.

5.1. End to End Logging


Logging is not a standard overall service. In general each individual service performs
logging but for electronic transactions more information will be needed to fully track who

4
Secure Socket Layer
5
Advanced Encryption Standard

12
a user is and what the user does. End to end Logging is also critical to non-repudiation
(see 6.6 for more information on non-repudiation).
For an electronic transaction on the Internet the following should be available in a single
log. Users IP address, users authenticated identity, trusted time date stamp, resource
accessed/action preformed, and session ID. The session ID is needed to a single user can
be tracked as they perform multiple actions.

6. Existing architecture
XYZ has made several strategic decisions about how security services will be offered.
This section describes how XYZ will offer the security services described above on the
Internet, Extranet, and Intranet.
The strategic decisions that are of most concern to this document is the use of Directory
Services with a LDAP Directory and the centralization of Authentication, Authorization
and Entitlements, as a network service independent of any application.

6.1. Identification
Most Identification will be done with a Username and either a password, OTP-FOB card
or Entrust Certificate. The username will be stored in the corporate directory (LDAP) as
will the certificate, if it is used. If a password will be used then the password will also be
stored in the directory. Passwords will be required to meet length rules, complexity rules,
aging rules, and password history rules.

Multiple usernames and multiple methods of authentication will be supported for a single
user. The basic identifier for internal users is the ACF2 ID, which is already loaded in the
directory. Multiple Usernames will be bound together under a single account in the
LDAP directory. The use of the LDAP directory will permit all the usernames to be
managed since they all exist in a single location.

Multiple forms for authentication will be used to support deeper and deeper electronic
access into the XYZ infrastructure.

6.2. Authentication services


Authentication can be done many ways. XYZ has several supported methods. These
include Username/password, OTP-FOB and digital certificate (Entrust).

The issue is how these authentication methods will be accessed. XYZ has made a
strategic decision to use SiteMinder to deal with all authentications for “web”
applications. Siteminder can be used to “proxy” the different methods of authentication
including LDAP password, Entrust, and OTP-FOB by means of web forms. Siteminder is
a leading product in the user management space.

Access to all systems will be based on what the sensitivity of the data is, what
compensating controls exist and what authentication methods the system will support.
Siteminder is the clearly preferred choice when ever possible and cost effective

13
Authentication for web, Domino, and SAP applications can be done via Siteminder and
access to pages can be based upon group membership (LDAP), roles (LDAP) or logic
based on the individual’s LDAP record. See the section on Entitlements and
Authorization Services below for more information.
For systems that do not have HTTP access, OTP-FOB (via ACE server), local password
Entrust certificates or Microsoft Active directory can be used directly though this is
strongly discouraged. Access without the use of Siteminder is discouraged since it avoids
the central logging that the Siteminder system offers the Enterprise.

6.2.1. B2C Identification, and Authentication


A username and password should be the standard method for Identification and
Authentication for the B2C class. Stronger methods can be used but the cost of
deployment of tokens must be clearly defined, and the sensitivity of the materials
accessed is key issues6.

6.2.2. B2B/P Identification, and Authentication


Due to the nature of the relationship between XYZ and a Producer, or B2B user, the
authentication methods used may need to supply a stronger proof of identity than a
username and password. In some cases a standard Username and password in the
directory may be sufficient but in other cases a token (OTP-FOB or certificate) may be
needed. The kind of Identification and authentication required would depend on the
sensitivity of the information accessed and the method by which the information is
accessed. See The Security Matrix (Data classification/ Security Service)

6.2.3. B2E Identification, and Authentication


Depending on the method of access this will be either username/password or username
with OTP-FOB. All of the username and passwords will be LDAP based.
The kind of Identification and authentication required would depend on the sensitivity of
the information accessed and the method by which the information is accessed. See The
Security Matrix (Data classification/ Security Service)

6.2.4. Anonymous Identification and


Authentication
Anonymous users are identified by default as anonymous.

6.3. Authentication, data structures and cookies


After any connection is identified and authenticated the user will be supplied with some
kind of data structure to act as proof of the process. The underlying assumption is that the
data structure will be a cookie7. This data structure should be available to all applications.
6
See the authentication and data sensitivity matrix in. http://xyz.pdf.
7
There are issues with cookies and services that must cross DNS domain boundaries. Some of these issues
can be resolved by placing cookies in the URL instead of the local disk.

14
It is assumed that the data structure will contain some role information from the
Directory. The token will also be used to help make access control decisions. The token
is the bridge between the identification and authorization process, the entitlement
process, personalization, and possibly cross application sign-on. This token can contain
names and other generally “public information.” Cookies are accessible to the user and so
must be protected from tampering via some kind of signing process. At a minimum, the
cookie must be signed by the system that generated the cookie. Additionally, the data
structure must have an expiration timeout for idle-time as well as a global expiration
timeout. Cookies that contain any ‘private’ information must be encrypted both in
transmission and while stored in the users computer.

6.4. Entitlements and Authorization Services


As with Authentication XYZ has made a strategic decision to make Entitlements and
Authorization a Network Service. Thus applications and systems will go to this service to
entitle users and the applications will not hold local tables of user’s entitlements. To
supply Entitlements and Authorization as a network service XYZ has made a strategic
decision to use Siteminder is one of several vendors to supply this kind of system. The
description here is general and SiteMinder meets this model but during any
implementation information on how Siteminder implements these services must be
referenced.

6.4.1. B2C and B2B/P Channel Issues


For both the Internet and IVR channel all connections must be treated the same. Any
differences lie within the method of identification and authentication used. Depending
upon a user’s class, the user will be entitled by the same system in different ways. All
entitlement information, regardless of the user’s class, will be held in the Directory,
Entitlement, or profile database. All network connections must pass through the same
system. The system will then permit or deny access to resources based upon the user’s
credentials.

6.4.2. Entitlement and Authorization System


The Entitlement and Authorization system will be made up of several parts:
• Directory server – The Directory holds most application role and group information
about an individual or process.

• Policy server – The policy server takes role information and can make access control
decisions based on several variables: on the object requested by the user, and information
held in the directory about the users. The Policy server can also access information about
the user stored in other databases in XYZ.

The policy server can be access via a plug-in (see below) on the proxy/application/web
server, and if necessary an API. Note that the API method will require explicit approval
from the CISO. The use of the API ties XYZ to a specific vendor and underlying
technology that makes the overall system very inflexible.

15
• Entitlement Plug-in (to a web or application server) – The plug-in can run on a proxy
server web server or application server. For web page access the plug-in intercepts an all
page requests and enforces access control decisions based on consumer’s roles. For other
applications that are not web-based owners can write functions that check the user’s
record in the directory and make access control decisions based on the data. This is not
the preferred method but it may be acceptable it is not the most acceptable option since it
can cause directory load in unexpected ways and it requires more directory accounts with
a higher level of access. Often in these cases the account used to view a users information
also must update properties and if the account is wildly used this account may have to be
given much more access then it should have. Such privileged accounts need a great deal
more care and one of the goals of this architecture is limit what systems can change
directory data to a few well-understood and controlled accounts.

3) The application needs fine grained


entitlement information about consumer. This
information by its nature is not contained in
1) Consumer is identified, the cookie supplied at authentication.
authenticated and a token Application makes a call to the Entitlement
(cookie) supplied. The cookie server asking for more entitlement
has some kind of ID and basic information about this consumer.
role information.
Consumer
1

4) Entitlement server can look in


the directory, or other database
for consumer information. The
2 entitlement server can supply
Proxy the information to the
with application. An example of
1 supplied information is the role
Plug-in
of a third party with respect to a
given instrument.
The application can then decide
Authentication/
what extra application privileges
3 Entitlements
the consumer is granted.
Services

Application 1, 4
1
4
2) Consumer request access to
an object. Proxy / application
server checks credentials and
the consumer is granted access
to the general object.
Authentication Directory
Database
Other Database
(ACE, NT other..)
Profile, entitlement etc.

16
Figure 1 Entitlements System
• Other Profile Database and relational databases – The relationships that govern what
an individual XYZ client can do and what that client can see are very complex. It is clear
that the Enterprise Directory on its own cannot support the level of complexity required.
Applications must have access to a level of fine-grained entitlement information. It will
be possible for an application to query the entitlement server and the entitlement server to
query a disparate set of relational databases for consumer entitlements. Figure 2 depicts
the different components of the entitlement system and the interaction of these
components.

The overall flow is the following:


Rules are generated in the Policy server. These rules define who can see what pages and
access what functions. These rules are based on
• What method of authentication the user can access
• What (LDAP) group(s) the user is a member of
• What other attributes or of combinations of attributes the users LDAP directory
entry has.
• It is possible to access other XYZ Databases to get role information (SQL, Active
Directory, Security Server, Oracle etc.) but these have not been implemented at
this time.
Once these rules are setup and the directory populated with groups and or attributes, the
information owners will be able to add or remove group membership or attributes. This
will give the information owner/application owner control over who is in what group.

Finally Security administration will (with help from the information/ application owner)
configure the policy server to permit or deny access to resources based on what roles a
particular class of users has.
In general many of these issues will be dealt with as the new application is developed but
this gives a feeling for the various steps that must be taken in this architecture.

Authorization is usually done on “page by page” though finer grained control is


possible.

6.5. Integrity
The requirement for data integrity depends upon the kind of data being protected.
In order to determine what method of data integrity should be applied it is necessary to
understand the sensitivity of the data. Data can be classified using the data classification
scheme described in XYZ Data Classification Policy. Data integrity services include:

• Digital signatures attached to documents. An individual, system or process can apply


these digital signatures. The signatures can be layered to determine exactly what the
history of the document is.

• Hash’s of documents that are stored off line. This includes hashes of web pages to
automatically check for unauthorized changes to XYZ’s web presence.

17
• Access controls to files and directories and automatically storing revisions to files.

• Read only copies of data that is staged for presentation on web serves.

• The use of SSL, SSH for data transmission and server authentication to preserve
integrity.

• Strong logging of data access and changes.

• The use of various methods of authentication.

• The use of Secure Email for internal and Intra-Company messaging may also be an
option8

The owner of the information (i.e. business unit) must approve of the method of release
of private data. In addition for XYZ as a whole to better maintain private information, all
information should be classified before its release. For a list of minimum protective
actions see XYZ Data Classification Policy for data classification scheme.

6.6. Non-Repudiation
Non-Repudiation can be offered in different levels depending on what is required. In
general the level of Non-repudiation offered electronically should match or exceed the
level available in a similar paper transaction.
There are several tools to supply Non-Repudiation in an electronic transaction.
• Logging – Including source and destination IP address and methods for
guaranteeing the integrity of the logs
• Time Stamp – from a trusted source
• Various methods of authentication – to show an approved Party/individual
preformed an action. This is usually combined with logging.
• Digital Signatures
• Various combinations and permutations of these basic services.

6.6.1. B2C Non-Repudiation


Due to the limitations of usernames and passwords for B2C it is not possible to offer
strong non-repudiation. The best non-repudiation that can be done with a username and
password is to record the following information in a protected manner:
• The username that accessed the site.
• The time the access took place.
• The source IP addresses.
• The action was performed.
• Forcing the user to login again and record that successful login at the time of
transaction.

8
Secure Email is being explored in a pilot in early 2003.

18
This level of non-repudiation may be sufficient for many needs but it does not show the
presence of a specific individual only knowledge of a certain username and password. A
consumer can simply state that their username and password was stolen by someone, told
to a third party, or overheard. For users with a token or a certificate the level of non-
repudiation can be increased.

The level can be increased with the use of digital signatures on files and email. Digital
signatures may need to include a trusted time stamp. Contractual means can be used to
better secure the binding between an individual and a username/password9

Note: The non-repudiation offered by the IVR is weaker then that offered by a user name
and password since it is unclear where the user of the IVR is located.

6.6.2. B2B/P Non-Repudiation


For users with a strong well-managed password10, token or a certificate, tying the
password token/certificate to an action can increase the level of non-repudiation. Digital
Signatures can be used by any entity that participates in the XYZ PKI or in a PKI that
XYZ has cross-certified. For any action that requires strong non-repudiation there are
several options. For all of these it is assumed that there is a clear business/legal necessity.

• Digital signature via the XYZ PKI with a trusted time source

• For a holder of a token (OTP-FOB). Proof of authentication using a trusted time source
and a trusted log and tying the token to a specific action. Like asking for the value of the
token and the PIN at the time of the transaction and recording the successful
authentication in a secure manner.

• Data being encrypted using a prearranged shared key. The method of encryption must be
at an appropriate level.

At this time strong non-repudiation is only available for agents at this time. Strong non-
repudiation requires membership in a PKI and a public/private key pair.

6.6.3. B2E Non-Repudiation


Employees fall between the B2C and the B2B/P. Employees have a well-managed
password due to the use of the directory but they also can handle very sensitive
information. Employees may also have access to Lotus Notes, which has its own PKI and
digital signing.

9
A contractual requirement that the users is responsible for the security of the password and have XYZ
supply an easy fast way of changing a password if a user needs to change it.
10
Strong and well managed in this case means a password with sufficient complexity, length and is
regularly changed. In addition the use of the password is watched for irregular activity

19
6.6.4. Non-Repudiation and the Interactive Voice
response System
Note that the level of non-repudiation offered by the IVR is weaker then that offered by a
user name and password since it is unclear where the user of the IVR is located.

6.7. Privacy
There are two kinds of privacy that need to be addressed in this architecture. The privacy
during transmission and the privacy of information once it is in XYZ’s possession.
To maintain privacy during transmission requires the use of cryptographic tools or private
connections11. For Web access SSL with a 128 key is considered best practice. Other
methods of encryption are used for transmission (Secure Transport, PGP etc.) in these
cases the strength of the encryption must be equivalent to 128 bit SSL. The other kind of
interaction that often needs Privacy is Email. This includes email with third parties and
customers. In some cases PGP can be used but PGP is not in wide use for end users in
XYZ. Other options for secure Email are also being explored12. At the present time
Email is not secure if sent out side of the XYZ network. If Email does not leave XYZ
systems the Email still can be viewed by Notes and LAN administrators.

Maintaining the privacy of information that is held by XYZ is a more complicated issue.
There are some technical solutions such as encrypting elements in a database or file but
these are limited solutions. The issue that must be addressed is who needs the data and
can that individual see the data. These issues require legal and contractual agreements in
addition to the technical tools.

Privacy is dealt with very differently in different regions. The EU and the US have very
different legal structures and controls over the sharing of customer and private data.
Before data is shared between these regions legal counsel must be consulted. This also
holds true between the US and the Asia Pacific region where banking and privacy laws
can be very complex

6.8. Issues around username and password


systems
Using usernames and passwords is the simplest and weakest form of identification and
authentication in use today. Due to the relatively static and non-confidential nature of the
information currently being supplied to consumers, a username and passwords may be
sufficient. There may also be times when a username and password may be sufficient for
access but not for more sensitive information. The identification and authentication
methods must be sufficiently modular so that one can be layered on top of another or one
can replaced by another. In this architecture, identification and authentication are based in
the Directory and not in the application. This permits the layering and the replacement of
identification and authorization services on an as-needed basis. Due to the static nature of

11
Private connections do not eliminate a third party from seeing the data but it does limit access to XYZ
offices, large telecom vendors, and anyone sitting on the local network next to the receiver of the data.
12
Secure Email is being explored in a pilot in early 2003.

20
the data that is currently planned on being delivered13, usernames and passwords should
be sufficient access controls.
Based upon the stated goals of XYZ, usernames and passwords may not be sufficient for
the functionality planned for eighteen to twenty-four months from now. This analysis
comes from the need to “sign” transactions such as purchase, claims, and the changing of
consumer information on a financial contract. There are often legal requirements for such
transactions that are beyond the scope of this document. Users that are not consumers
may be required to have a physical token based upon the sensitivity and level of access.
For an average policyholder this is onerous but for large consumers who maintain many
financial contracts this may be a viable option. Individual consumers can be given
certificates that are sealed by XYZ and delivered to the user after a username and
password is supplied. See the Digital Signature section for more information

7. Existing Architecture Identity Management


Underlying the issues of Identification, Authentication, and Entitlements is the idea of
Identity Management. For the purpose of this document an identity is a record in the
LDAP Directory of a person

Identity management is a special case having of dealing with how users are controlled.

7.1. Creation of Electronic Identities


Except for some self identified consumers identities are not created on the directory. All
other users in the directory must be owned by a responsible party in XYZ. Identities are
generated by feeds to the directory. The feeds include al HR systems (for employee
information), Corporate Security and several others. As information is entered into these
systems that data then causes records to be added removed or modified. Once in
existences the directory can add additional information but the existence of the record is
the responsibility of the authoritative system. Thus the identities are created by the
system that owns them. At this time the directory does not own any user records.

The uniqueness of each record is guaranteed by the directory structure and the
administrators of the process that update the directory using the data feeds.

7.2. Disabling and Removal of Electronic Identities


Removal of a record in the directory will only happen when the owning system removes
the record. Disabling of an identity can happen in a number of ways, including:
• By the authentication system after too many failed login attempts, lack of use or
other criteria determined by the security group
• By a directory administrator
• By the CISO or his chosen representative
• At the request of the user
Depending on how an account was disabled it can be re-enabled via manual or self-
service.

13
As of 09/0220

21
7.3. Modification of an Electronic identity
Once an identity exists in the directory it must be given attributes. Some of these come
from the data streams that feed the directory and some from other sources in XYZ.
The two ways that identities get modified beside from the data streams, is for an identity
to be added to a group, or for the recorded to be given an attribute. In both cases it is the
group/attribute owner who authorizes this change (or the owner of the data that
membership in the group supplies access to).
Since an individual party owns each data element in the directory there is no overlap of
responsibility. This means that as new applications and resources become available
identities will be modified over time.

7.4. Personalization
Since identification information is available in the directory this information can also be
used to support personalization and customization. The policy engine (Siteminder) will
supply HTTP headers to an application in support of personalization. In most cases this
will be some kind of name and possibly a unique ID. This information can be used to do
personalization in the application. The architecture does not support any personalization
function nor will it support records in the directory just having to do with personalization.

8. Engineering Future State


8.1. Identification and Authentication Services
Siteminder must be fully integrated into the environment. At the present time as
applications get reworked and new applications are deployed Siteminder will be applied

8.2. New Directory Structure must be Deployed


In 2002 a directory project is under way to completely redesign and upgrade the
directory. The new directory is a critical part of the overall architecture. Without a
directory that can support the necessary load the overall security infrastructure will grind
to a halt...

8.3. Authorization and Entitlement Services


Developers need to be trained to use the new entitlement system. This will require a
change in mindset from the current way of doing things with the security server. The
differences include application’s directory design, roles in applications, coding methods
to access the cookies, cookie design etc. At the present time there is a concept of
Operations for the Entitlements and authorization system and the developers work book.
These documents will have to be finished.

8.4. Integrity
XYZ has recently published a data classification schema policy and Data protection
matrix. All data transmitted in XYZ must be classified and the required controls applied
from the matrix.

22
8.5. Privacy/Integrity
Much of XYZ’s confidential data needs to be sent and shared with many parties as a
business requirement. Some methods of ad hoc communication must be deployed to
support general communication in a secure method. At the present time XYZ is exploring
secure Email to meet this need. In addition the issue of database encryption and Voice
over IP will need to be examined and dealt with.

8.6. Non-Repudiation services


Non-repudiation is quickly changing as the laws and practices around electronic
commerce develop. At the preset time strong non-repudiation is not available for B2C but
this will change rapidly as technologies improve and the legal framework becomes clear.
These issues must be reviewed every 6-12 months to determine if there is a need for
strong non-repudiation in XYZ and what technologies are available.

8.7. Public Key Infrastructure


One of the principle problems with the use of the current PKI in XYZ is the amount of
extra hardware and software that is required to give an agent access to the XYZ PKI. At
the present time Entrust is the “standard” method of access for PKI services. Entrust
should be abandoned for a more generally accessible certificate structure.
Though a PKI can support a stronger level of authentication getting the PKI to do this can
be hard both technically and procedurally. Due to the overall expense and complexity
along with a lack of corresponding security may limit the overall expansion of the present
PKI.
Right now it is unknown if PKI will become the wave of the future or if PKI will be
overtaken by some other technology XYZ must be aware of these changes.

Appendix A: General Directory Services


The XYZ directory will form the backbone of the security infrastructure. It should be the
central store for all identification and authentication information as well as most
entitlement information (roles). The Directory should contain the following security
information:

• All Usernames associated with a single Financial contract-ID (Defined in the


Identification and Authentication section)

• User passwords and other shared secrets in a protected format

• User role information

• User group information

The payload of the Directory must also meet all regularity controls. In general the
Directory should not hold individuals private information. The Directory must have the
following basic attributes:

23
• The Directory must have a LDAP V3 interface.

• The Directory server must have a well-developed internal security model. The model
must be flexible enough to permit the distribution of user administration responsibilities
with a minimum of exposure. Administration of the Directory will be a complicated task
since many parties (helpdesk staff, d.b.a., consumers, etc.) must be able to view or
change the data contained in the Directory.

• The Directory must support a dynamic replication model. The model must support both
limited and full replication of specific sections of the Directory called nodes.

• The Directory must be deployed with the ability to support Meta-Directory services.

General Directory Architecture


The Directory should be replicated in a limited form and distributed to the places to
where it is needed. It is assumed that there will be a core Directory server(s) that will be
the primary, but not necessarily the master Directory server. The core Directory will be
used to push out and route changes to Directory information to the various directories
distributed across XYZ. The limited directories that will be distributed are called client
directories. Client directories will hold all Directory information that is locally required.
This information could include usernames, password information, and role information
from the core Directory. This local information may or may not be replicated back to the
core Directory. The client directories are meant to be semi-autonomous systems that are
fed from the core but can grow as needed and can support data that the core Directory
cannot or should not handle

Synchronization between the Core and Client


Directories
The Directory contains information critical to the daily operations of the organization and
as such, must be protected and controlled. This leads to a very centrally managed view
where all updates must be reflected in the core directory first. Because the client
directories are read-only mirrors of portions of the core directory, any update to the core
is reflected in the client directories. Additionally, the Directory must, in some cases,
support almost real time updates, which implies that a client directory must be able to
make changes to core information and have that information propagate to the core
Directory and to the other client directories. This entails a very distributed control of
Directory information and may lead to a client directory to have write permission over
information that is beyond its scope.

When data is shared between a client directory and the core there must be a process in
place to synchronize data on an attribute-by-attribute basis. This process must also be
able to support a multi-master update model. This model will allow certain data elements
to be mastered at the core and other data elements to be mastered by both the core and at
the client level. This system must have the capability do determine how fast a change is
propagated through the system. Some changes can happen slowly (Name changes) while
some must happen very quickly (password changes).

24
Figure 3. Synchronization between the Core and Client Directories

Consumer Consumer
Directory 1 Directory 4

Replication and Core Replication and


Synchronization Synchronization
services Directory services
1 and 2 Services 3 and 4

Consumer Consumer
Directory 2 Directory 3

Consumer directory 1 is a read only Consumer Directory 4 was seaded from the
replica of a slice of the core directory. core but clinets and the core are permitted to
make chages to selected attrubutes. Change
Consumer directory 2 is seaded from the contorl, data propagation, role backand and
core direcotory but in addtion contians syncronization is dealt with using the
informaiton in support of serveral Replicaiotn and syncronizaiton services.
applicaiorns that need directory services
but the data is not needed /in appropate Consumer directory 3 has some attributes that
for the Core directory service. are mastered on the core services and some
attrubutes that are localy mastered. Changes
the replicaion services ensures that to the locally mastered attrubutes are
changes are updated in the consummer replicationed and pushed up to the entire
directorys undre the agreeded time/ sysetm.
change limites.

25
Appendix B: Public Key Infrastructure (PKI) Services
The fundamental principle of PKI is based upon the establishment of trust among entities
that need to communicate securely. Hence the founding of a third party trusted by two or
more parties that can electronically prove that the communication is authentic,
confidential and it maintains integrity with explicit commitment to non-repudiation
services. This entity is known as a Certification Authority (CA). This authority issues a
digital stamp of approval, called a Certificate, to any party that is identified within the
boundaries of corporate PKI policies. In reality, it is a digital document that binds a
public key to the physical identity, or another attribute, of the party requesting the
certificate. An end entity - henceforth termed customer - applies for a certificate from a
trusted third party, and it will only accept transactions from other customers certified by
the same third party. Customers can be people or applications such as web applications.
Access to the administrative function of a CA is often restricted to a very few number of
people. A compromise of CA access by malicious individuals will cause serious damage
to the entity and the customers using PKI.

Before issuing a certificate, a set of information must be collected, verified and archived
by another corporate agency named Registration Agency (RA). This information will
identify and authenticate the certificate requestor. More importantly, it will establish a
relationship of trust between the customer and the CA. The registration process may be
automatic or part of another registration infrastructure or process, like the case of a new
employee being issued a Certificate with his/her new ID Card or like submitting a web
based request form. The function of an RA, whether using an automatic or a manual
process, is to gather relevant information, according to certain guidelines set by
Corporate Standards and Policies, and then to approve issuance of a digital Certificate to
customers where the relationship is well documented and understood.

General PKI Architecture


It is assumed that all of the peripheral support infrastructure, such as Backup and
Recovery, Information Security (IS) Policies, and Disaster Recovery are in place. It is
also assumed that the underlying data telecommunication protocols will be TCP/IP
whereas LDAP14 will be used for communicating with X500 directory services over IP.
With that in mind, it is prudent to suggest that the PKI architecture should rely on a
limited number of users and CA Administration agents on selected engineering and
trusted staff. It is assumed that there will be a maker/checker process in place for
generation of digital identities. The roles of CA administration will have to be segregated
into three: Number 1 officer will have the ability to perform operations services, which
include Administration Services and Key Management Services. Number 2 officer will be
able to do everything that Number 1 Administrators can do, plus have the ability to set
security policy and cross-certification with other CAs. Finally, operations officers will

14
For more information on LDAP refer to
http://www.leland.stanford.edu/group/networking/directory/doc/ldap/ldap.html

26
be able to add, enable, disable, change Distinguished Names (DNs), recover users and
revoke Certificates.

Trust Model
Because of the complexity of trust relationships among various entities, and because of
its wide scale attractiveness as a practical solution, PKI deployment faces potential risks
and liabilities. This makes it more critical to deploy an infrastructure that is XYZ specific
and meets its global strategic needs. The proposed architecture then should be flexible to
support autonomous or pseudo-autonomous infrastructures. The PKI architecture, shown
in figure 4, will be based upon a single root CA. In this structure the relationship is based
around a one-directional multilevel (i.e. multiple virtual PKI) trust tree structure. The tree
is multithreaded and can support 0 or N threads with one root structure at the top. If N>0
then, excluding the lowest level of the tree, each level is an autonomous CA that has a
mono-trust relationship with all its children threads below it, as well as its parent thread
above it. In this structure a root CA issues all certificates, and thus certificates’ movement
is restricted down the hierarchy. This structure can be better controlled since each path, to
the principal entity, is easily traced. Inherent in this structure is the absolute trust of the
root CA by all the subordinate certificates. This means that a compromise of the root CA
may lead to a potential compromise and forging of any digital signature(s) for any/all
signature verifier using a path via root which makes the protection of the private key of
paramount importance. The PKI technology used will support root CA private key
protection using hardware based or biometric access controls.

Root CA

Parent CA Parent CA

Parent CA Parent CA Parent CA Parent CA

Child Child Child Child Child Child Child Child

Figure 4. The PKI Trust Model

Due to the complexity of non-repudiation and its associated support structure, the
classification policy of client clusters along the lines of confidentiality, integrity and non-
repudiation, will be supported by the architecture. If the client base has minimal or no
non-repudiation requirements, with adequate compensating controls and business risk
acceptance, then an unmanaged PKI can be used with an autonomous level 1 CA, as a
sibling of the proposed architecture. On the other hand, if a cluster of clients has a hard
non-repudiation requirement, then a separate managed PKI can be used with autonomous
level 1 CA.

27
With this PKI architecture as described above, some I-net systems, such as B2B for
example, might make use of multiple internal distinct CA’s. In order to promote
interoperability, these CA’s may be interconnected through the issuance of CA
certificates (or cross-certificates) to each other as dictated by usage and policy.
Although, data integrity and Privacy is often resolved with encryption from PKI
technology vendors, SSL is by far the preferred transport layer encryption of choice, for
its practical use, market penetration and technology interoperability. Despite, that the PKI
technology will support encryption, use of encryption technology must be application
specific since there are many technology and legal factors involved which are beyond the
scope of this document.

Scalability & Single Points of Failure


The architecture engine will provide monitoring capabilities and threshold notification
prompting analysis of system upgrade. The architecture should at least span two
geographically distant areas to handle fault tolerance. And because of the criticality of a
deployed PKI, the fault tolerance site should be hot whereby services are transparently
directed to it.

28
Appendix C: Network design and Access
Network access relates to all persons and entities that are XYZ policyholders, business
partners or managers of XYZ financial contracts. This includes consumers (B2C), B2B/P
etc.
This section describes in very general terms how the XYZ DMZs are constructed. The
discussion is quite general as it is designed to help educate an intelligent up uninformed
user about how the XYZ DMZ operates.

General Architecture
Regardless of the user class, the medium and means of network transport, and the data
being accessed, generalized network architecture can be used to provide support for
various types of application architectures, scalability and performance at all levels, and
access to various types of data sources. All classes of user will be supported thorough
same basic architecture. The difference in how users are treated is determined by the
methods of identification authentication and entitlements the user can access. Please refer
to the appropriate sections of this paper for different requirements pertaining to
identification, authentication and entitlements.
The one way that traffic is segregated is by direction. There is an “inbound” DMZ, and
“outbound DMZ” and a “third party” DMZ. These three DMZs correspond loosely to in /
out and both directions. The overall architecture of each DMZ is the same just the clients
and services they support may be different.

This generalized architecture is shown in Figure 5. Although four different networks


“layers” are identified on the diagram, not all layers are required for all applications, and
the usage of all four to support a single application (or consumer group) is discouraged.
The two layers that will be common to almost all application architectures will be the
load-balanced presentation service network (indicated as Network 2 in the figure) and
the load-balanced replicated data services network (indicated as Network 4). These two
networks provide the fundamental building blocks of any application: the presentation
layer (Network 2) and the data source layer (Network 4). The presentation layer would
typically be implemented as a web server, and the data source layer would be
implemented as a database.
The entire network architecture would typically be implemented as a DMZ between the
untrusted network (e.g., the Internet) and the trusted network (e.g., XYZ’s Intranet).
However, this architecture could also lend itself to be implemented at a co-location
facility off-site at a hosting vendor. To simply the discussion, the term DMZ is used
throughout this section to denote either case.

Two, Three and N-Tier Application Architecture Support


Each DMZ can support two, three or N-tier application architectures. In a two-tier
application architecture, the presentation layer (Network 2) and the data source layer
(Network 4) would be all that would be required. Three tier architectures would include
the application services layer (Network 3) between Networks 2 and 4 to provide the
additional tier of services. Theoretically, any number of application tiers could be added

29
between the presentation and data services layers to support N-tier application
architectures. In practical circumstances, most applications are limited to a 3-tier
architecture.

Figure 5. Generalized Secure Network Architecture


XYZ has strongly considered segregating DMZ’s based on the number of layers in the
application architecture. Two tier applications should be placed in one DMZ; three tier
applications in another. Providing multiple tier application support in the same DMZ
segment is not impossible, but segregation is preferable to simplify the network design.

30
In the end the segregation was done in two ways. First by creating an In-bound, Out-
bound and Third-Party DMZ and in each DMZ there is the option to create Trusted Zones
(private V-LANs) to further segregate traffic. This design gives most of the flexibility
required with out the expense of all the extra hardware and support.

Network Load-Balancing
All layers, except the first, are front-ended by a network layer load-balancing device that
can provide scalability across multiple systems of the same type. When selecting various
types of systems and technologies, it is imperative for XYZ to select those that can be
load-balanced at the network level. These technologies are generally referred to as
“stateless”; indicating that state information is not maintained across transactions. Each
transaction to a system is independent of any other.
Some systems may require limited state information and require consumers to access the
same system during the course of a full user session. To support these applications, most
network load balancing devices include a “sticky” setting that directs user sessions to the
same system over some finite window of time (generally on the order of a couple of
minutes). This window of time is reset every time the same user accesses the system.
Although this sticky setting can provide a solution for these types of applications with
state requirements, abusing the sticky setting (by using large windows of time) can defeat
the load-balancing purpose of the device. Such functionality should be used with caution
in high-volume environments.

Security Services
As with any DMZ environment allowing access from untrusted networks, additional
security services should be included in the overall design. Specifically, network based
intrusion detection (as shown in the figure) will be a key component of proper early
warning of intrusions. Additionally, host-based intrusion detection and general event
monitoring (e.g., log file analysis, etc.) should also be considered for each system in the
DMZ to provide enhanced security services.
Monitoring policies (such as for intrusion detection) are specific to the DMZ segment
based on the platforms and application services used in the overall architecture and the
specific network segment of the monitoring point. In general greater priority is being
given to relevant attacks observed in the data services network (Network 4) than those in
others.
Technologies Used

• Network Layer Load-Balancers


• Real-Time Synchronous Databases
• Host and Network Based Intrusion Detection

31
Network Access
Definition
Consumer network access relates to all services and functionality available to consumers
over the network, including the Internet. Regardless of the actual network that
consumers access the information from, all these networks are considered untrusted and
users must be properly identified prior to access being granted. Furthermore, additional
security precautions must be provided for when access is allowed from these untrusted
networks.

Architecture
The architecture for consumer network access will take on either a 2 or 3-tier
architectural model (described above) based on the application being supported.
Additionally, segregation based on application and consumer type may also factor in the
total number of DMZ segments used to implement consumer network access. Different
DMZ segments can be used to support different applications or consumer groups.
Common services (such as DNS or authentication) can be provided in Network 1, the
non-load balanced network segment, based on particular XYZ requirements.

Consumer
Consumer network services would most likely be placed in a single DMZ segment in
either a 2 or 3-tier application architectural model. Small consumers, such as individual
policyholders, would be grouped together based on specific applications they were
accessing or type of policyholder (e.g., life insurance policyholder).

B2B/P
Agents and organizations with a B2B/P relationship would most likely be grouped
together, similar to consumers, since the types of application functionality given to one
would be similar to the rest. Depending on specific circumstances, separate DMZ
segments could potentially be constructed for extremely large consumers. This would
also allow easier facilitation of co-branding XYZ’s services through these very large
consumers.

VPN and Other Special Network Access


Definition
VPN and other special network access addresses the cases of non-standard consumer
based network access. Some limited number of employees, agents, and partners may
require access privileges greater than normal and thus stronger controls and a modified
infrastructure are required to support it securely.

Architecture
In the case of consumer VPN support, the generalized network architecture (shown in
Figure XX), can be reduced to Network 1 only if the purpose of the VPN is to provide

32
access to internal XYZ production network and systems. In this case, application servers
denoted Service A and Service B could be VPN proxy servers providing connectivity
between remote consumers and internal XYZ resources. Additionally, other network
segments providing presentation and/or data services could also be added to this
architecture if stronger data Privacy and integrity was required beyond that of typical
SSL enabled web servers.

Any user with VPN access to the internal network must be identified and
authenticated via a token. More dedicated VPN connections can be used between XYZ
and establish partner networks instead of installing dedicated network circuits. Internet
based VPNs may not provide sufficient throughput, however, to support these types of
business-to-business connections. In the case of Point to Point VPNs physical access to
the facility is considered sufficient authentication as long as there are ACLs on the XYZ
side to limit access. XYZ has been carefully evaluating the network throughput
requirements of an application prior to implementing it on any VPN.

Other types of network access can be provided through proxy-like services when
positioned in Network 1 as Service A or Service B. Depending on the particular
application and/or service offered, additional network components such as the
presentation and data services layers would be included.

Technologies Used
• Strong methods of Identification and Authorization

• VPN Proxy Servers

Non Standard out-bound access

In the case where an internal XYZ user needs access to a service, running on the internet
and on a non-standard port some things are available. The recommended method is NOT
to have holes in the outbound firewall be opened. If the application is “proxy-able” there
are options that do not require holes to be punched in the outbound firewalls. If possible
the application should be SOCKS enabled (by the vendor). If the application is not
SOCKS enabled but is proxy-able a SOCKS client can be placed on the user’s machine
(or server) that will then move all traffic from this machine on the special ports to the
SOCKS proxy.
The SOCKS proxy must be configured and it may require a user to log-in before access.

33
Appendix D: Digital Signature Services
Informational
By leveraging the internal PKI and the associated public and private keys, XYZ can
produce a legally binding digital signature that can be used to sign documents and
transactions. The level of trust tied to the signature is directly related to how the user is
identified and authenticated. Should the identification method employed be weak or
insufficient, the validity of the digital signature will be called into question. It is
imperative that multiple forms of identification be required when digital signatures will
be used. Some of the methods used to identify a user can be Biometrics, Hardware
Tokens or trusted Digital Certificates.

The ability for an individual to sign an electronic document may be a requirement for
certain types of transactions. A good example of where a digital signature would be
required is the submission of a claim form or supporting documentation.

While the technical process of signing a document or transaction is beyond the scope of
this paper, it is vital to note the importance of the strength of the identification and
encryption processes. Both the identification and encryption processes must be
implemented with the strongest methods available. If it can be proven that the encryption
or identification method is weak or flawed, the Digital signature will not stand up in a
court of law.

PKI Architecture
In order to sign a document or transaction, a trusted public/private encryption key pair
must exist. In most cases, this will be issued in the form of a digital certificate from an
organizations internal PKI. Often, this involves deploying software to the desktop along
with the certificate. It is important to note that, as with all other aspects of the PKI, digital
signatures are only as trustworthy as the PKI itself. If the PKI is open to subversion, then
the integrity of the digital signatures will be compromised as well. It is important to note
that any audit or review of digital signatures will also encompass a review of the PKI, its
infrastructure and operational procedures. Once both the certificate and software have
been deployed to the desktop, digital signatures can become a routine part of the
workplace. Memos, emails, and transactions can all be signed thereby ensuring non-
repudiation.

Desktop & software deployment considerations


While the deployment of software is still a practical option for most organizations, it is
not practical when customers are required to sign transactions and documents.
Alternative methods for supplying customer with digital certificates must be developed to
effectively leverage the digital signature process. Several companies exist that will issue
digital certificates to end users for the purpose of digital signing. They all offer different
levels of user validation varying from a verified email address all the way to a validated
and verified identity. The certificates that are offered are generally to be used from a web
browser that can present the certificates whenever it is requested. Companies will often

34
form partnerships and trust relationships in an effort to reduce costs and increase the level
of security. Two of the leading companies in the certificate space are Verisign for end-
user consumers and CertCo for business-to-business transactions. This classification
schema has been used in XYZ. It is presented here as reference to help business owner
and developers determine what level of security is needed for new applications.

XYZ Information Classification Policy


At XYZ, information resources are critical assets. However, not all of these assets have
the same value, and consequently do not require the same level of protection. XYZ has
developed an information classification model to selectively protect these resources
against loss or misuse and ensure appropriate controls are enacted to that affect.
The purpose of this policy is to set forth the XYZ Information Classification model. The model
establishes guidelines to be used for applying the proper level of protection for XYZ information
assets.
The scope of this policy is enterprise-wide and applies to all XYZ and subsidiary employees,
agents, consultants, vendors and their representatives, contract programmers, brokers, and other
independent contractors who handle or process sensitive XYZ information.
Sensitive XYZ information must be classified according to the XYZ classification model.
Initially, the policy will apply to information covered by the privacy initiative mandated by legal
and regulatory statutes, e.g., Gramm-Leach-Bliley Act (G-L-B), to protect nonpublic information
XYZ holds on its customers. Ultimately, the policy will apply to all confidential XYZ
information.
Information Owners are responsible for determining the sensitivity level of information assets and
classifying that information according to its sensitivity and value to the Company. Information
Owners are also responsible for changing the classification level of an information asset.
Information Custodians are responsible for protecting information resources in accordance with
the Information Owners’ specific directions.
The Chief Information Security Officer (CISO) is responsible for managing all aspects of the
information security function enterprise-wide and has the final decision on controls to protect
XYZ information and information systems. The CISO may refer conflicts related to privacy
classification to the Chief Privacy Officer of XYZ.
Users of classified information are responsible for complying with the security controls
designated for the appropriate classification level.
This policy is to be used in conjunction with the XYZ Security Roles and Responsibilities of
which details are available at http://xyz.abc.html, the Information Classification Guidelines, and
the Records Protection Policy.
This policy is effective on the date of publication.

35
Bibliography
Directory Services
XYZ Phase 1V2 .doc that deals with the current directory
XYZ Phase 2V5.doc which deals with schema and directory topology redesign.
XYZ Phase 3V6.doc that is full directory architecture.

37

You might also like