GIRM - ARC Web Site Article IT Security Frameworks Access Control

5/14/2018 GIRM - ARC Web Site Article IT Security Frameworks Access Control - slidepdf.com

http://slidepdf.com/reader/full/girm-arc-web-site-article-it-security-frameworks-access-cont

CORPORATE EXECUTIVE BOARD NOVEMBER 2005IT Practice Project Support Desk KEY FINDINGS

IT Security Frameworks: Access Control

© 2005 Corporate Executive Board

Catalog No.: IREC14J4ML1

K EY QUESTIONS

What access control guidelines are

included in the high-profile ITsecurity frameworks?

What are the shared and uniqueareas of access control guidelines inthe high-profile IT securityframeworks?

TABLE OF CONTENTS

Overview 2

COBIT 5

ISO 17799 7

ITIL 9

The ISF Standard 11

NIST 800-14 15

SSE-CMM 18

SECURITY FRAMEWORKS PROFILED

EXECUTIVE SUMMARY

The single most problematic obstacle to regulatorycompliance is access management, according toregulatory auditors. The fluid and unprecedented levelsof access to information enjoyed by both internal andexternal constituents has rendered traditional, staticmethods of access control largely obsolete.

Organizations often have difficulty comprehensivelycataloguing the extensive control measures necessitated by complex information access environments. Thesecurity frameworks profiled in this brief provide, withvarying degrees of scope and detail, collections of best practices and tactical guidelines in order to assist ITorganizations in their attempts to establishcomprehensive and secure access control processes.

High-profile IT security frameworks that address accesscontrol include: COBIT (Control Objects for Information and related

Technology)

ISO 17799 (International Organization for Standardization)

ITIL (Information Technology Infrastructure Library)

The ISF Standard (Information Security Forum)

NIST 800-14 (National Institute of Standards andTechnology)

SSE-CMM (Systems Security Engineering-CapabilityMaturity Model)



IT SECURITY FRAMEWORKS: ACCESS CONTROL PAGE 2

OVERVIEW

IT Security Frameworks Aid Organizations in Identifying Wide-Range of Relevant Access

Control Objectives

The single largest source of difficulty in achieving regulatory compliance, according to auditors,is the failure to segregate access privileges to applications and the failure to set-up new access

accounts and terminate old ones in a timely manner.1

Traditional access control models no longer meet the requirements of information sharing as practiced by the vast majority of organizations – requirements that are created by the fluid andunprecedented levels of access to information enjoyed by both internal and external constituents.2 It is difficult for organizations to comprehensively catalogue the extensive control measuresnecessitated by such complex information access control environments.

The security frameworks profiled in this brief provide, with varying degrees of scope and detail,collections of best practices and tactical guidelines to assist IT organizations in their attempts toestablish comprehensive and secure access control processes.




OVERVIEW (CONTINUED)

IT Security Frameworks: Organization of Access Control Information

The various IT security frameworks take different approaches to organizing and presenting their access control guidelines. The following table briefly characterizes how each framework organizes its access control information. Namely, the table identifies the frameworks that do, and

do not, separate access control-related objectives from other security objectives by collectingaccess control guidelines into their own specific sections.

IT Security Frameworks: Organization of Access Control Information

Separates access control guidelines intospecific sections

Does NOT separate access controlguidelines into specific sections

ISO 17799

ITIL

The ISF Standard

NIST 800-14

COBIT

SSE-CMM

Source: Corporate Executive Board Research.

ISO 17799 Contains Highest Volume of General Guidelines; The ISF Standard Provides

Largest Amount of Tactical Detail

The following graph plots the IT security frameworks covered in this research brief according tothe tactical, implementation-related details versus the volume of general access control guidelines provided by each framework. Frameworks that provide a great deal of tactical detail in support of general guidelines are plotted further-out on the X-axis and those that contain a high volume of general access control guidelines are plotted higher-up on the Y-axis.

IT Security Frameworks: Depth and Breadth of Provided Access Control Guidelines

COBIT

ISO 17799

ITIL

NIST 800-14

SSE-CMM

The ISF Standard

Amount of Tactical Detail Provided

V o l u m

e o f G e n e r a l G u i d e l i n e s P r o v i d e d


Depth

B r e a d t h




OVERVIEW (CONTINUED)

IT Security Frameworks: Practice Area Coverage

The table below presents a snapshot of the shared and unique access control practice areas thatare explicitly covered in the access control sections of each security framework or, when aseparate access control section is unavailable, in the practice areas relevant to access control.

IT Security Frameworks: Scope of Access Control Coverage

Access Control Practice Areas COBIT ISO 17799 ITILThe ISF

StandardNIST 800-14 SSE-CMM

Centralized identification andaccess rights management

Network access control

Operating system access control Application access control

Managed allocation of accessrights

Management review of user

accounts

User control of user accounts Key/encryption/advanced

authentication management

Activity monitoring Violation and security activity

reports

Audit trail maintenance

Online data access security Secure teleworking access

Communication of end-user safeaccess responsibilities

Counterparty trust

Transaction authorization Non-repudiation

Intra-group coordination Anti-virus control Service constraints

Access configuration changecommunication





COBIT

Control Objects for Information and related Technologies (COBIT) is a collection of 318 controlobjectives that are categorized under 34 IT processes. The control objectives are non-technicalcontrols statements that define what elements must be managed in each identified IT process.These IT processes are then further classified into four process domains:

Planning and Organizing Acquiring and Implementing Delivering and Supporting

Monitoring and Evaluating

The IT control framework, produced by the IT Governance Institute, was first published in 1994and is now in its third edition. Version 4.0 of COBIT is slated for release in late November 2005.

COBIT does not collect access control practices into a single location in the framework. Instead, practices that are relevant to access control are presented along with general security practicesunder the “Ensure Systems Security” IT process in the “Delivering and Supporting” category. In

total, there are 21 control objectives under the Ensure Systems Security process. The following isthe subset of those 21 objectives that are most relevant to identity and access management.3

COBIT: ACCESS CONTROL PRACTICES

Identification, Authentication and Access

The logical access to and use of IT computing resources should be restricted by theimplementations of adequate identification, authentication, and authorization mechanisms,linking users and resources with access rules. Such mechanisms should prevent authorized personnel, dial-up connections, and other system (network) entry ports from access computer

resources and minimize the need for authorized users to use multiple sign-ons. Procedures shouldalso be in place to keep authentication and access mechanisms effective (e.g. regular passwordchanges).

Security of Online Access to Data

In an online IT environment, IT management should implement procedures in line with thesecurity policy that provides access security control based on the individual’s demonstrated needto view, add, change, or delete data.

User Account Management Management should establish procedures to ensure timely action relating to requesting,establishing, issuing, suspending, and closing of user accounts. A formal approval procedure

outlining the data or system owner granting the access privileges should be included. The securityof third-party access should be defined contractually and address administration and non-disclosure requirements. Outsourcing arrangements should address the risks, security controls and procedures for information systems and networks in the contract between the parties.

Management Review of User Accounts Management should have a control process in place to review and confirm access rights periodically. Periodic comparison of resources with recorded accountability should be made tohelp reduce the risk of errors, fraud, misuse or unauthorized alteration.




COBIT (CONTINUED)

User Control of User Accounts

Users should systematically control the activity of their proper account(s). Also informationmechanisms should be in place to allow them to oversee normal activity as well as to be alerted tounusual activity in a timely manner.

Security Surveillance

IT security administration should ensure that security activity is logged and any indication of imminent security violation is reported immediately to all who may be concerned, internally andexternally, and is acted upon in a timely manner.

Central Identification and Access Rights Management

Controls are in place to ensure that the identification and access rights of users as well as theidentity of system and data ownership are established and managed in a unique and centralmanner to obtain consistency and efficiency of global access control.

Violation and Security Activity Reports

IT security administration should ensure that violation and security activity is logged, reported,reviewed and appropriately escalated on a regular basis to identify and resolve incidentsinvolving unauthorized activity. The logical access to the computer resources accountabilityinformation (security and other logs) should be granted based upon the principle of least privilege, or need-to-know.

Counterparty Trust

Organizational policy should ensure that control practices are implemented to verify theauthenticity of the counterparty providing electronic instructions or transactions. This can beimplemented through trusted exchange of passwords, tokens or cryptographic keys.

Transaction Authorization

Organizational policy should ensure that, where appropriate, controls are implemented to provideauthenticity of transactions and establish the validity of a user’s claimed identity to the system.This requires use of cryptographic techniques for signing and verifying transactions.

Non-Repudiation

Organizational policy should ensure that, where appropriate, transactions cannot be denied byeither party, and controls are implemented to provide non-repudiation of origin or receipt, proof of submission, and receipt of transactions. This can be implemented through digital signatures,time stamping and trusted third-parties, with appropriate policies that take into account relevantregulatory requirements.

Cryptographic Key Management

Management should define and implement procedures and protocols to be used for generation,change, revocation, destruction, distribution, certification, storage, entry, use and archiving of cryptographic keys to ensure the protection of keys against modification and unauthorizeddisclosure. If a key is compromised, management should ensure this information is propagated toany interested party through the use of Certificate Revocation Lists or similar mechanisms.

Source: Control Objectives for Information and related Technology 3rd

Edition, IT Governance Institute, July 2000.




ISO 17799

ISO collects 132 controls under 39 IT process categories. Each process has a control objectiveand the specific controls provided suggest ways of satisfying that objective. The 39 IT processesare divided amongst 11 process domains:

Security Policy Organizing Security Asset Management Human Resources Security

Physical and Environmental Security

Communications and Operational Management

Access Control Information Systems Acquisition, Development, and Maintenance Information Security Incident Management

Business Continuity Management Compliance

The most recent version of ISO 17799 was published in June 2005 by the InternationalOrganization for Standardization and the International Electrotechnical Commission. Its predecessor, BS 7799, was first published in 1995. ISO 17799 is expected to be replaced by ISO27002 sometime in 2007.

There are seven IT processes, each with several specific controls, under the “Access Control”domain. In addition, several controls that were included under the access control domain in ISO17799:2000 have been removed or moved to different IT domains in the new ISO 17799:2005.Most notably, all of the access control mechanisms relating to systems monitoring have beenmoved from the access control domain to the operational management domain. But in order to provide a more complete overview of relevant access management guidelines in ISO 17799, thosecontrols remain in the list below.4

ISO 17799:2000 AND ISO 17799:2005 ACCESS CONTROL PRACTICES

Control Access to Information

Develop a policy and rules to control accesso Develop a policy to control information access

o Develop information access control rules

Manage the Allocation of Access Rights

Establish a user registration procedure Control the authorization of system privileges

Establish a process to manage passwords

Review user access rights and privileges

Encourage Responsible Access Practices Encourage users to protect passwords

Encourage users to protect equipment

Clear desk and clear screen policy




ISO 17799 (CONTINUED)

Control Access to Computer Networks

Formulate a network use policy Use enforced paths to control access Authenticate remote user connections

Use node authentication to control remote users Equipment identification in networks Control remote access to diagnostic and configuration ports Segregate internal and external networks

Restrict connection to shared networks

Establish shared network routing controls

Verify the security of network services

Restrict Access at Operating System Level

Use automatic terminal identification techniques Establish terminal log-on procedures

Identify and authenticate all users Set-up a password management system Control the use of all system utilities

Provide duress alarms to protect users Use time-outs to protect inactive terminals

Restrict terminal connection times

Manage Access to Application Systems

Regulate access to applications and information Isolate sensitive application systems

Monitor System Access and Use

Establish and maintain system logs

Monitor information processing facilities

o Establish procedures to monitor facilitieso Review the results of monitoring activitieso Study logs to identify security events

Protect logs by synchronizing clocks

Protect Mobile Equipment and Information

Protect mobile equipment and information Protect telecommuter equipment and information

Sources: ISO 17799:2000 , International Organization for Standardization, June 2000; ISO 17799:2005 , InternationalOrganization for Standardization, June 2005.




ITIL

The Information Technology Infrastructure Library (ITIL) consists of generally accepted best practices in seven distinct IT management areas. Access control best practices are collected inITIL’s Security Management publication.

An updated version of ITIL, produced by the UK government’s Office of Government Commerce(OGC), is scheduled to be released in mid-2007.5

ITIL: ACCESS CONTROL PRACTICES

Maintenance of Access Control

Ensure that effective control over access is maintained and includes the management of users,accounts, rights, means of identification and authentication (including passwords and tokens) andkeeping access rights up-to-date.

End-User Responsibilities Encourage customer organizations to address their responsibilities explicitly in the SLA.Encouraging security awareness is essential. Areas in which explicit user responsibilities should be established include:

The use of passwords Securing active sessions

Not leaving equipment and data carriers unattended

Procedures for import and export of software and data carriers (to prevent viruses and illegalsoftware)

Use of external sources (Internet and other external data communication) Backup

Responsibilities for laptop usage

Network Access Control

Control access rights and restrictions to network services for internal as well as external users Separate networks and create enforced paths through the separate network domains

Identify and authenticate computers systems, workstations, and PCs in the network

Control securely remote management (especially in relation to diagnostic ports) Explicitly set the security requirements for third-party network services

Computer Access Control

Identify and authenticate all workstations and terminals

Enforce a standard log-on procedure in which only the minimum of information is provided(e.g. avoid providing details of the system type or organization name)

Always identify and authenticate end-users to be able to trace all network activities to a natural person

Install duress alarms

Automatic time-out Institute time slots by limiting the use of IT resources to normal office hours

Lock-out after a fixed number of failed access attempts Implement more stringent log-in checks for off-site access




ITIL (CONTINUED)

Application Access Control

Use “roles” and “functions” in the applications themselves. Segregate duties for applicationssystem functions, system help, libraries, and the files of the programs themselves. For verysensitive information systems, an isolated computing environment without any shared facilities

can be established.

Anti-Virus Control Policy

Anti-virus software must be updated at both the server and the client:

Determine how frequently software needs to be updated

Purchase the correct number and type of licenses

Monitor updates receipt Manage the updating process for both networked and stand-alone systems

Monitoring and Auditing IS Activity

Record any exceptional or suspicious events in an audit trail

Monitor system use Synchronize system clocks Report on attempted virus infections

Source: ITIL Security Management , Office of Government Commerce, April 1999.




ISF: THE STANDARD OF GOOD PRACTICE

The Information Security Forum’s (ISF) The Standard of Good Practice (the Standard) publication presents detailed recommendations to mediate business risks associated with criticalinformation systems. Access control recommendations are included under the “Critical BusinessApplications” and “Computer Installations” sections. The latest version of the Standard, Version

4.1, was published by ISF in January 2005.6

THE ISF STANDARD: ACCESS CONTROL PRACTICES

Critical Business Applications: User Environment

Access Control

Users of the application should be identified (e.g. by a UserID), authenticated (e.g. by a password or token) and authorized (e.g. to use functionality required to perform their role).

System administrators should be subject to strong authentication (e.g. using fingerprints, irisscans, challenge/response devices featuring one-time passwords or smartcards).

There should be a method of ensuring that users do not share identification or authentication

details. There should be a process for issuing new or changed passwords that:

o ensures that passwords are not sent in the form of clear text e-mail messages

o directly involves the person to whom the password uniquely applieso verifies the identity of the target user, such as via a special code or through

independent confirmationo includes notification to users that passwords will expire soon.

Users’ access rights should be:

o restricted according to a defined policy, such as on a ‘need to know’ or ‘need torestrict’ basis

o restricted according to users’ individual roleso authorized by the application ‘owner’

o revoked promptly when an individual user is no longer entitled to themo enforced by automated access control mechanisms to ensure individual

accountability. Access to the application should be logged. Access logs should include sufficient information to provide a satisfactory audit trail (including users’ identities and locations, dates/times of accessand details of particular files or system utilities accessed).

Access logs should be:o set to include all security-related events (e.g. successful and failed access

attempts)o reviewed periodically

o retained for a specified period to comply with legal and regulatory requirements

o protected against unauthorized change.

Computer Installations: Access Control

Access Control Arrangements

Arrangements should be made to restrict access to the computer installation, and theinformation held in it.




ISF: THE STANDARD OF GOOD PRACTICE (CONTINUED)

Access control arrangements should be supported by documented standards/procedures, whichshould take account of:

o an information security policy, security classifications, agreements withapplication ‘owners’, requirements set by the installation ‘owner’ and legal,

regulatory and contractual obligationso the need to achieve individual accountability, apply additional control to users

with special access privileges and provide segregation of duties. Access control arrangements should cover access:

o by all types of staff (e.g. business users, individuals running the installation andspecialist IT staff, such as technical support staff)

o to all types of information and software. Access control arrangements should:

o restrict access in line with access control policies set by application ‘owners’

o restrict the system capabilities that can be accessed, for example by providingmenus enabling access only to the particular capabilities needed to fulfill adefined role

o

identify the location of terminals in useo prevent misuse of passwords, for example by using encryption, one-time

passwords or stronger authentication, such as token-based authenticationo minimize the need for special access privileges (e.g. UserIDs that have additional

capabilities, such as ‘Administrator’ in Windows systems, or special capabilities,such as UserIDs that can be used to authorize payments)

o be reviewed periodically

o upgraded in response to new threats, capabilities, business requirements or experience of incidents.


User Authorization

All users of the computer installation should be subject to an authorization process before theyare granted access privileges. The processes for authorizing users should:

o be defined in writing, approved by the installation ‘owner’ and applied to allusers

o associate access privileges with defined users, for example with UserIDs rather than passwords

o issue default access privileges of ‘none’ (i.e. rather than ‘read’)o ensure redundant UserIDs are not re-issued for use.

A file or database containing details of all authorized users should be established, which should be maintained by designated individuals, such as particular system administrators, and protectedagainst unauthorized change or disclosure.

Details of authorized users should be reviewed:

o to ensure that access privileges remain appropriate

o to check that redundant authorizations have been deleted (e.g. for employees whohave changed role or left the organization)

o on a regular basis (e.g. at least every six months)

o on a more regular basis for users with special access privileges (e.g. at least everythree months).






Access Privileges

Access privileges for business users should be assigned by application ‘owners’ (the individualsin charge of business applications supported by the installation) and access privileges for

computer staff (e.g. computer operators and system administrators) assigned by the installation‘owner’.

Before access privileges come into effect:o authorizations should be checked to confirm access privileges are appropriate

o details of users should be recorded (e.g. their true identity, associated UserIDsand access privileges to be granted)

o users should be advised of – and required to confirm – their access privileges andassociated conditions.

Access privileges should not be assigned collectively (e.g. UserIDs/passwords shared in agroup) unless special circumstances apply. Whenever they need to be assigned collectively, theyshould be documented, approved by the relevant business ‘owner’ and subject to additionalcontrols (e.g. restricted access privileges and contractual conditions).

Additional controls should be applied to special access privileges, including high-level privileges (such as ‘root’ in UNIX or ‘Administrator’ in Windows NT systems), powerfulutilities and privileges that can be used to authorize payments. These controls should include:

o specifying the purpose of special access privileges

o restricting the use of special access privileges to narrowly defined circumstanceso requiring individual approval for the use of special access privileges

o requiring users with special access privileges to sign-on using identificationcodes or tokens that differ from those used in normal circumstances.

A process for terminating the access privileges of users should be established to ensure that:o authentication details and access privileges are revoked promptly on all systems

to which the user had access

o access profiles/accounts are deleted

o

components dedicated to providing access, such as tokens or modems, aredisabled or removed.


Sign-On Process

There should be a sign-on process that users must follow before they can gain access to anysystems within the computer installation, which should enable UserIDs to be identifiedindividually.

Sign-on mechanisms should be configured so that they:

o display no identifying details until after sign-on is completed successfully

o warn that only authorized users are permitted accesso validate sign-on information only when it has all been entered

o

limit the number of unsuccessful sign-on attempts (for example a re-try limit of three)

o record all successful and unsuccessful sign-on attempts

o restrict additional sign-on attemptso limit the duration of any one sign-on session

o automatically re-invoke sign-on after an interruption of the process, for examplewhen a connection is broken





o advise users – on successful sign-on – of the date/time of their last successfulsign-on and all unsuccessful sign-on attempts since their most recent successfulsign-on

o do not store authentication details as clear text in automated routines, such as in

scripts, macros or cache memory. The approval of the installation ‘owner’ should be obtained before any important features of the

sign-on process are bypassed, disabled or changed.


User Authentication

All users should be authenticated, either by using UserIDs and passwords or by stronger authentication such as smartcards or biometric devices (e.g. fingerprint recognition) before theycan gain access to any information or systems within the installation.

Where authentication is achieved by a combination of UserIDs and passwords, users should beadvised to keep passwords confidential (i.e. to avoid disclosing them to anyone or writing themdown) and to change passwords that may have been compromised.

User authentication should be enforced by automated means that:

o ensure UserIDs are unique

o ensure passwords are not displayed on screen or on print-outso issue temporary passwords to users that must be changed on first use

o force new passwords to be verified before the change is acceptedo ensure users set their own passwords

o ensure passwords are a minimum number of characters in length, differ fromtheir associated UserIDs, contain no more than two identical characters in a rowand are not made up of all numeric or alpha characters

o ensure passwords are changed periodically (e.g. every 30 days) and morefrequently for users with special access privileges

o restrict the re-use of passwords (e.g. so that they cannot be used again within a

set period or set number of changes). There should be a process for issuing new or changed passwords that:o ensures that passwords are not sent in the form of clear text e-mail messageso directly involves the person to whom the password uniquely applies

o verifies the identity of the target user, such as via a special code or throughindependent confirmation

o includes notification to users that passwords will expire soon. Strong authentication (e.g. smartcards or biometric devices, such as fingerprint recognition)

should be applied to users with access to critical business applications or sensitive informationand to users with special access privileges or access capabilities from external locations.

Source: The Standard of Good Practice for Information Security Version 4.1, Information Security Forum, January 2005.




NIST 800-14

NIST 800-14, published by the National Institute of Standards and Technology, presentsgenerally accepted principles of IT systems security and common IT security practices. There are13 profiled practice areas with two areas, “Identification and Authentication” and “LogicalAccess Control,” collecting the best practices most relevant to access control.7

NIST 800-14: ACCESS CONTROL PRACTICES

Identification and Authentication

Identification

Unique Identification. An organization should require users to identify themselves uniquely before being allowed to perform any actions on the system unless user anonymity or other factors dictate otherwise.

Correlate Actions to Users. The system should internally maintain the identity of all active usersand be able to link actions to specific users.

Maintenance of User IDs. An organization should ensure that all user IDs belong to currentlyauthorized users. Identification data must be kept current by adding new users and deletingformer users.

Inactive User IDs. User IDs that are inactive on the system for a specific period of time (e.g., 3months) should be disabled.


Authentication

Require Users to Authenticate. An organization should require users to authenticate their claimed identities on IT systems. It may be desirable for users to authenticate themselves with asingle log-in. This requires the user to authenticate themselves only once and then be able toaccess a wide variety of applications and data available on local and remote systems.

Restrict Access to Authentication Data. An organization should restrict access to authenticationdata. Authentication data should be protected with access controls and one-way encryption to prevent unauthorized individuals, including system administrators, or hackers from obtainingthe data.

Secure Transmission of Authentication Data. An organization should protect authentication datatransmitted over public or shared data networks. When authentication data, such as a password,is transmitted to an IT system, it can be electronically monitored. This can happen on thenetwork used to transmit the password or on the IT system itself. Simple encryption of a password that will be used again does not solve this problem because encrypting the same password will create the same ciphertext; the ciphertext becomes the password. Limit Log-on Attempts. Organizations should limit the number of log-on attempts. Many

operating systems can be configured to lock a user ID after a set number of failed log-on

attempts. This helps to prevent guessing of authentication data. Secure Authentication Data as it is Entered. Organizations should protect authentication data as

it is entered into the IT system, including suppressing the display of the password as it is enteredand orienting keyboards away from view.

Administer Data Properly. Organizations should carefully administer authentication data andtokens including procedures to disable lost or stolen passwords or tokens and monitoringsystems to look for stolen or shared accounts.




NIST 800-14 (CONTINUED)


Passwords

Specify Required Attributes. Secure password attributes such as a minimum length of six,inclusion of special characters, not being in an online dictionary, and being unrelated to the user

ID should be specified and required. Change Frequently. Passwords should be changed periodically. Train Users. Teach users not to use easy-to-guess passwords, not to divulge their passwords,

and not to store passwords where others can find them.


Advanced Authentication

How to Use. In the use of the authentication system including secrecy of PINs, passwords, or cryptographic keys, physical protection of tokens is also required.

Why it is Used. To help decrease possible user dissatisfaction, users should be told why thistype of authentication is being used.

Logical Access Control Access Criteria

Identity (user ID). The identity is usually unique in order to support individual accountability, but it can be a group identification or even anonymous.

Roles. Access to information may also be controlled by the job assignment or function (i.e., therole) of the user who is seeking access. The process of defining roles should be based on athorough analysis of how an organization operates and should include input from a widespectrum of users in an organization.\

Location. Access to particular system resources may be based upon physical or logical location.Similarly, users can be restricted based upon network addresses (e.g., users from sites within agiven organization may be permitted greater access than those from outside).

Time. Time-of-day and day-of-week/month restrictions are another type of limitation on access.

For example, use of confidential personnel files may be allowed only during normal workinghours. Transaction. Another criterion can be used by organizations handling transactions. For example,

access to a particular account could be granted only for the duration of a transaction, e.g., in anaccount inquiry a caller would enter an account number and pin. A service representative would be given read access to that account. When completed, the access authorization is terminated.This means that users have no choice in the accounts to which they have access.

Service Constraints. Service constraints refer to those restrictions that depend upon the parameters that may arise during use of the application or that are pre-established by theresource owner/manager. For example, a particular software package may be licensed by theorganization for only five users at a time. Access would be denied for a sixth user, even if theuser were otherwise authorized to use the application. Another type of service constraint is

based upon application content or numerical thresholds. For example, an ATM machine mayrestrict transfers of money between accounts to certain dollar limits or may limit maximumATM withdrawals to $500 per day.

Access Modes. Organizations should consider the types of access, or access modes. The conceptof access modes is fundamental to access control. Common access modes, which can be used in both operating and application systems, include read, write, execute, and delete. Other specialized access modes (more often found in applications) include create or search. Of course,these criteria can be used in conjunction with one another.




NIST 800-14 (CONTINUED)

Logical Access Control

Access Control Mechanisms

Access control lists (ACLs). ACLs are a register of users (including groups, machines, processes) who have been given permission to use a particular system resource and the types of

access they have been permitted. Constrained User Interfaces. Access to specific functions is restricted by never allowing users to

request information, functions, or other resources for which they do not have access. Threemajor types exist: menus, database views, and physically constrained user interface, e.g., anATM.

Encryption. Encrypted information can only be decrypted, and therefore read, by those possessing the appropriate cryptographic key. While encryption can provide strong accesscontrol, it is accompanied by the need for strong key management.

Port Protection Devices. Fitted to a communications port of a host computer, a port protectiondevice (PPD) authorizes access to the port itself, often based on a separate authentication (suchas a dial-back modem) independent of the computer's own access control functions.

Secure Gateways/Firewalls. Secure gateways block or filter access between two networks, often

between a private network and a larger, more public network such as the Internet. Securegateways allow internal users to connect to external networks while protecting internal systemsfrom compromise.

Host-Based Authentication. Host-based authentication grants access based upon the identity of the host originating the request, instead of the identity of the user making the request. Manynetwork applications in use today use host-based authentication to determine whether access isallowed. Under certain circumstances, it is fairly easy to masquerade as the legitimate host,especially if the masquerading host is physically located close to the host being impersonated.

Source: Guttman, Barbara and Marianne Swanson, Generally Accepted Principles and Practices for Securing InformationTechnology Systems, National Institute of Standards and Technology, September 1996.




SSE-CMM

The Systems Security Engineering-Capability Maturity Model (SSE-CMM) is a reference modelto gauge the maturity of various processes related to information systems security. Theframework collects several base practices related to very specific security processes.

SSE-CMM Version 3.0, published by the International Systems Security Engineering Association(ISSEA), was released on June 15, 2003.

The SSE-CMM does not collect access control base practices into a single location in theframework. Instead, practices that are relevant to access control are distributed across multiplesecurity processes and are listed below.8

SSE-CMM: ACCESS CONTROL PRACTICES

Perform Intra-Group CoordinationThis type of coordination addresses the need for an engineering discipline to ensure that decisionswith regard to technical issues (e.g. Access Controls) are arrived at through consensus. Thecommitments, expectations, and responsibilities of the appropriate engineers are documented andagreed upon among those involved. Engineering issues are tracked and resolved.

Manage Security Services and Control Mechanisms

Each of the security services must involve establishing appropriate security parameters,implementing those parameters, monitoring and analyzing performance, and adjusting the parameters. These requirements are particularly applicable to such security services asIdentification and Authentication for the maintenance of users and authentication data, and accesscontrol for the maintenance of permissions:

Maintenance and administrative logs – record of maintenance, integrity checks, and operationalchecks performed on system security mechanisms.

Periodic maintenance and administration reviews – contains analysis of recent system securityadministration and maintenance efforts.

Administration and maintenance failure – tracks problems with system security administrationand maintenance in order to identify where additional effort is required.

Administration and maintenance exception – contains descriptions of exceptions made to thenormal administration and maintenance procedures, including the reason for the exception andthe duration of the exception.

Sensitive information lists – describes the various types of information in a system and how thatinformation should be protected.

Sensitive media lists – describes the various types of media used to store information in a

system and how each should be protected. Sanitization, downgrading, and disposal – describes procedures for ensuring that no

unnecessary risks are incurred when information is changed to a lower sensitivity or whenmedia are sanitized or disposed.




SSE-CMM (CONTINUED)

Protect Security Monitoring Artifacts

If the products of monitoring activities can not be depended upon they are of little value. Thisactivity includes the sealing and archiving of related logs, audit reports and related analysis: List all archived logs and associated period of retention – identifies where artifacts associated

with security monitoring are stored and when they can be disposed Periodic results of spot checks of logs that should be present in archive – describes any missing

reports and identifies the appropriate response Usage of archived logs – identifies the users of archived logs, including time of access, purpose,

and any comments

Periodic results of testing the validity and usability of randomly selected archived logs – analyzes randomly selected logs and determines whether they are complete, correct, and usefulto ensure adequate monitoring of system security

Identify System Security Context

Identify the purpose of the system in order to determine the security context. An expandedsecurity perimeter enables physical measures to be considered as effective safeguards for access

control in addition to purely technical measures. Identify how the system’s context impacts security. This involves understanding the purpose of

the system (for example, intelligence, financial, medical). Performance and functional requirements are assessed for possible impacts on security.

Interface elements are determined to be either inside or outside of the security perimeter.

Communicate Configuration Status

Communicate status of access configuration to affected groups. Status reports – should include information on when accepted changes will be processed, and

the associated work products that are affected by the change. Provide access permissions to authorized users

Source: Systems Security Engineering-Capability Maturity Model , International Systems Security Engineering Association,15 June 2003.




1 Worthen, Ben, “How to Dig Out from Under Sarbanes-Oxley,” CIO Magazine, 1 July 2005.2 Bouma, Tim, “Governance-Based Access Control: Improved Information Sharing, Reduced Risks,” CIO

Magazine, 20 June 2005.3 Control Objectives for Information and related Technology 3rd Edition, IT Governance Institute, July2000.4

ISO 17799:2000, International Organization for Standardization, June 2000; ISO 17799:2005,International Organization for Standardization, June 2005.5 ITIL Security Management , Office of Government Commerce, April 1999.6 The Standard of Good Practice for Information Security Version 4.1, Information Security Forum,January 2005.7 Guttman, Barbara and Marianne Swanson, Generally Accepted Principles and Practices for Securing

Information Technology Systems, National Institute of Standards and Technology, September 1996.8 Systems Security Engineering-Capability Maturity Model , International Systems Security EngineeringAssociation, 15 June 2003.

Professional Services Note:

The Corporate Executive Board has worked to ensure the accuracy of the information it provides to its members. This

project relies upon data obtained from many sources, however, and the Corporate Executive Board cannot guarantee

the accuracy of the information or its analysis in all cases. Furthermore, the Corporate Executive Board is not engaged

in rendering legal, accounting, or other professional services. Its projects should not be construed as professional advice

on any particular set of facts or circumstances. Members requiring such services are advised to consult an appropriate

professional. Neither Corporate Executive Board nor its programs are responsible for any claims or losses that may

arise from any errors or omissions in their reports, whether caused by Corporate Executive Board or its sources.

Corporate Executive Board

2000 Pennsylvania Ave NWWashington, DC 20006

Telephone: 202-777-5000Facsimile: 202-777-5100

www.executiveboard.com www.irec.executiveboard.com

Documents

GIRM - ARC Web Site Article IT Security Frameworks Access Control