The following is an excerpt from Security Controls Evaluation, Testing, and Assessment Handbook by author Leighton Johnson and published by Syngress. This section from chapter 11 explores access control.
There are many NIST Special Publications for the various AC methodologies and implementations. Each one has a specific area of AC that it covers. Here are just some of the SPs available for review and reference as the controls are identified, implemented, and evaluated:
- 800-46 (Telework)
- 800-77 (Internet Protocol Security (IPSec))
- 800-113 (SSL)
- 800-114 (External Devices)
- 800-121 (Bluetooth)
- 800-48 (Legacy Wireless)
- 800-97 (802.11i Wireless)
- 800-124 (Cell Phones/PDA)
- OMB M 06-16 (Remote Access)
Logical Access Controls
Logical ACs are the primary means of managing and protecting resources to reduce risks to a level acceptable to an organization. They are tools used for identification, authentication, authorization, and accountability. They are software components that enforce AC measures for systems, programs, processes, and information. The logical ACs can be embedded within operating systems, applications, add-on security packages, or database and telecommunication management systems. In applying management-designed policies and procedures for protecting information assets, logical ACs are the primary means of managing and protecting these resources to reduce risks to a level acceptable to an organization. For example, the concept of AC relates to managing and controlling access to an organization’s information resources residing on host- and network-based computer systems. Assessors need to understand the relationship of logical ACs to management policies and procedures for information security. In doing so, assessors should be able to analyze and evaluate a logical AC’s effectiveness in accomplishing information security objectives.
Inadequate logical ACs increase an organization’s potential for losses resulting from exposures. These exposures can result in minor inconveniences up to a total shutdown of computer functions. Exposures that exist from accidental or intentional exploitation of logical AC weaknesses include technical exposures and computer crime. For assessors to effectively assess logical ACs within the system under review, they first need to gain a technical and organizational understanding of the organization’s IT environment. The purpose of this is to determine which areas from a risk standpoint warrant special attention in planning current and future work. This includes reviewing all security layers associated with the organization’s IT information system architecture.
These layers are as follows:
- Network layer
- Operating system platform layer
- Database layer
- Application layer
Paths of Logical Access
Access or points of entry to an organization’s information system infrastructure can be gained through several avenues. Each avenue is subject to appropriate levels of access security. For example, paths of logical access often relate to different levels occurring from either a back-end or a front-end interconnected network of systems for internally or externally based users. Front-end systems are network-based systems connecting an organization to outside untrusted networks, such as corporate websites, where a customer can access the website externally in initiating transactions that connect to a proxy server application which in turn connects, for example, to a back-end database system in updating a customer database. Fronteend systems can also be internally based in automating business, paper-less processes that tie into back-end systems in a similar manner.
General Points of Entry
General points of entry to either front-end or back-end systems relate to an organization’s networking or telecommunications infrastructure in controlling access into their information resources (e.g., applications, databases, facilities, networks). The approach followed is based on a client–server model where, for example, a large organization can literally have thousands of interconnected network servers. Connectivity in this environment needs to be controlled through a smaller set of primary domain controlling servers, which enable a user to obtain access to specific secondary points of entry (e.g., application servers, databases). General modes of access into this infrastructure occur through the following:
- Network connectivity
- Remote access
- Operator console
- Online workstations or terminals
Logical Access Control Software
IT has made it possible for computer systems to store and contain large quantities of sensitive data, increase the capability of sharing resources from one system to another, and permit many users to access the system through internet/intranet technologies. All of these factors have made organizations’ information system resources more accessible and available anytime and anywhere.
To protect an organization’s information resources, AC software has become even more critical in assuring the confidentiality, integrity, and availability of information resources. The purpose of AC software is to prevent unauthorized access and modification to an organization’s sensitive data and use of system critical functions.
Security Controls Evaluation, Testing, and Assessment Handbook
Author: Leighton Johnson
Learn more about Security Controls Evaluation, Testing, and Assessment Handbook from publisher Syngress
At checkout, use discount code PBTY25 for 25% off this and other Elsevier titles
To achieve this level of control, it is necessary to apply ACs across all layers of an organization’s information system architecture. This includes networks, platforms or operating system, databases, and application systems. Attributes across each commonly include some form of IA, access authorization, checking to specific information resources, and logging and reporting of user activities.
The greatest degree of protection in applying AC software is at the network and platform/ operating system levels. These layers provide the greatest degree of protection of information resources from internal and external users’ unauthorized access. These systems are also referred to as general support systems, and they make up the primary infrastructure on which applications and database systems will reside.
Operating system AC software interfaces with other system software AC programs, such as network layer devices (e.g., routers, firewalls), that manage and control external access to organizations’ networks. Additionally, operating system AC software interfaces with database and/or application system ACs to protect system libraries and user datasets.
Logical Access Control Software Functionality
- General operating system AC functions include:
- Apply user IA mechanisms.
- Restrict log-on IDs to specific terminals/workstations and specific times.
- Establish rules for access to specific information resources (e.g., system-level application resources and data).
- Create individual accountability and auditability.
- Create or change user profiles.
- Log events.
- Log user activities.
- Report capabilities.
- Database and/or application-level AC functions include:
- Create or change data files and database profiles.
- Verify user authorization at the application and transaction levels.
- Verify user authorization within the application.
- Verify user authorization at the field level for changes within a database.
- Verify subsystem authorization for the user at the file level.
- Log database/data communications access activities for monitoring access violations.
Assessing ACs and AC systems:
- Start with obtaining a general understanding of the security risks facing information processing, through a review of relevant documentation, inquiry, observation, and risk assessment and evaluation techniques.
- Document and evaluate controls over potential access paths into the system to assess their adequacy, efficiency, and effectiveness by reviewing appropriate hardware and software security features and identifying any deficiencies or redundancies.
- Test controls over access paths to determine whether they are functioning and effective by applying appropriate testing techniques.
- Evaluate the AC environment to determine if the control requirements are achieved by analyzing test results and other evidence.
- Evaluate the security environment to assess its adequacy by reviewing written policies, and observing practices and procedures, and comparing them with appropriate security standards or practices and procedures used by other organizations.
- Familiarization with the IT environment:
- This is the first step of the evaluation and involves obtaining a clear understanding of the technical, managerial, and security environment of the information system processing facility. This typically includes interviews, physical walk-throughs, review of documents, and risk assessments, as mentioned above in the physical security control area.
- Documenting the access paths:
- The access path is the logical route an end user takes to access computerized information. This starts with a terminal/workstation and typically ends with the data being accessed. Along the way, numerous hardware and software components are encountered. The assessor should evaluate each component for proper implementation and proper physical and logical access security.
- Interviewing systems personnel:
- To control and maintain the various components of the access path, as well as the operating system and computer mainframe, technical experts often are required. These people can be a valuable source of information to the assessor when gaining an understanding of security. To determine who these people are, the assessor should interview with the IS manager and review organizational charts and job descriptions. Key people include the security administrator, network control manager, and systems software manager.
- Reviewing reports from AC software:
- The reporting features of AC software provide the security administrator with the opportunity to monitor adherence to security policies. By reviewing a sample of security reports, the assessor can determine if enough information is provided to support an investigation and if the security administrator is performing an effective review of the report.
- Reviewing Application Systems Operations Manual:
- An Application Systems Manual should contain documentation on the programs that generally are used throughout a data processing installation to support the development, implementation, operations, and use of application systems. This manual should include information about which platform the application can run on, database management systems, compilers, interpreters, telecommunications monitors, and other applications that can run with the application.
- Log-on IDs and passwords:
- To test confidentiality, the assessor could attempt to guess the password of a sample of employees’ log-on IDs (though this is not necessarily a test). This should be done discreetly to avoid upsetting employees. The assessor should tour end user and programmer work areas looking for passwords taped to the side of terminals or the inside of desk drawers, or located in card files. Another source of confidential information is the wastebasket. The assessor might consider going through the office wastebasket looking for confidential information and passwords. Users could be asked to give their password to the assessor. However, unless specifically authorized for a particular situation and supported by the security policy, no user should ever disclose his/her password.
- Controls over production resources:
- Computer ACs should extend beyond application data and transactions. There are numerous high-level utilities, macro or job control libraries, control libraries, and system software parameters for which AC should be particularly strong. Access to these libraries would provide the ability to bypass other ACs. The assessor should work with the system software analyst and operations manager to determine if access is on a need-to-know basis for all sensitive production resources. Working with the security administrator, the assessor should determine who can access these resources and what can be done with this access.
- Logging and reporting of computer access violations:
- To test the reporting of access violations, the assessor should attempt to access computer transactions or data for which access is not authorized. The attempts should be unsuccessful and identified on security reports. This test should be coordinated with the data owner and security administrator to avoid violation of security regulations.
- Follow up access violations:
- To test the effectiveness and timeliness of the security administrator’s and data owner’s response to reported violation attempts, the assessor should select a sampleof security reports and look for evidence of follow-up and investigation of access violations. If such evidence cannot be found, the assessor should conduct further interviews to determine why this situation exists.
- Identification of methods for bypassing security and compensating controls:
- This is a technical area of review. As a result, the assessor should work with the system software analyst, network manager, operations manager, and security administrator to determine ways to bypass security. This typically includes bypass label processing (BLP), special system maintenance log-on IDs, operating system exits, installation utilities, and I/O devices. Working with the security administrator, the assessor should determine who can access these resources and what can be done with this access. The assessor should determine if access is on a need-to-know/have basis or if compensating detective controls exist.
- Review ACs and password administration:
- Ensure password control is active for all accounts and users. Ensure password complexity and renewal requirements are enforced for all users and accounts. Ensure password criteria for elevated privilege accounts are more complex and longer than for standard user accounts as part of Separation of Duties review.
- Restricting and monitoring access:
- There should be restrictions and procedures of monitoring access to computer features that bypass security. Generally, only system software programmers should have access to these features:
- BLP: BLP bypasses the computer reading of the file label. Since most AC rules are based on file names (labels), this can bypass access security.
- System exits: This system software feature permits the user to perform complex system maintenance, which may be tailored to a specific environment or company. They often exist outside of the computer security system and, thus, are not restricted or reported in their use.
- Special system log-on IDs: These log-on IDs often are provided with the computer by the vendor. The names can be determined easily because they are the same for all similar computer systems. Passwords should be changed immediately, on installation, to secure the systems.
- There should be restrictions and procedures of monitoring access to computer features that bypass security. Generally, only system software programmers should have access to these features:
- Auditing remote access:
- Remote use of information resources dramatically improves business productivity, but generates control issues and security concerns. In this regard, IS auditors should determine that all remote access capabilities used by an organization provide for effective security of the organization’s information resources. Remote access security controls should be documented and implemented for authorized users operating outside of the trusted network environment. In reviewing existing remote access architectures, IS auditors should assess remote access points (APs) of entry in addressing how many (known/unknown) exist and whether greater centralized control of remote APs is needed. IS auditors should also review APs for appropriate controls, such as in the use of virtual private networks (VPNs), authentication mechanisms, encryption, firewalls, and IDS.
IDENTIFICATION AND AUTHENTICATION
IA is the process of proving one’s identity. It is the process by which the system obtains from a user his/her claimed identity and the credentials needed to authenticate this identity, and validates both pieces of information.
LOG-ON IDS AND PASSWORDS
Features of passwords:
- A password should be easy for the user to remember but difficult for a perpetrator to guess.
- Initial passwords may be allocated by the security administrator or generated by the system itself. When the user logs on for the first time, the system should force a password change to improve confidentiality.
- If the wrong password is entered a predefined number of times, typically three, the logon ID should be automatically and permanently deactivated (or at least for a significant period of time).
Token Devices, One-Time Passwords
A two-factor authentication technique, such as a microprocessor-controlled smart card, generates one-time passwords that are good for only one log-on session. Users enter this password along with a password they have memorized to gain access to the system. This technique involves something you have (a device subject to theft) and something you know (a personal identification number). Such devices gain their one-time password status because of a unique session characteristic (e.g., ID or time) appended to the password.
Biometric ACs are the best means of authenticating a user’s identity based on a unique, measurable attribute or trait for verifying the identity of a human being. This control restricts computer access, based on a physical (something you are) or behavioral (something you do) characteristic of the user.
Management of Biometrics
Management of biometrics should address effective security for the collection, distribution, and processing of biometric data.
Management should develop and approve biometric information management and security (BIMS) policy. The auditor should use the BIMS policy to gain a better understanding of the biometric systems in use.
Single Sign-On (SSO)
Users normally require access to a number of resources during the course of their daily routine. For example, users would first log into an operating system and thereafter into various applications. For each operating system application or other resource in use, the user is required to provide a separate set of credentials to gain access; this results in a situation wherein the user’s ability to remember passwords is significantly reduced. This situation also increases the chance that a user will write them down on or near their workstation or area of work, and thereby increase the risks that a security breach within the organization may occur.
Read an excerpt
Download the PDF of chapter 11 in full to learn more!
To address this situation, the concept of SSO was developed. SSO can generally be defined as the process for consolidating all organization platform-based administration, authentication, and authorization functions into a single centralized administrative function. This function would provide the appropriate interfaces to the organization’s information resources, which may include:
- Client–server and distributed systems
- Mainframe systems
- Network security including remote access mechanisms
The SSO process begins with the first instance where the user credentials are introduced into the organization’s IT computing environment. The information resource or SSO server handling this function is referred to as the primary domain. Every other information resource, application, or platform that uses those credentials is called a secondary domain.
The authorization process of AC often requires that the system be able to identify and differentiate among users. For example, AC is often based on least privilege, which refers to the granting to users of only those accesses required to perform their duties.
Access rules (authorization) specify who can access what. Access should be on a documented need-to-know and need-to-do basis by type of access.
Having computer access does not always mean unrestricted access. Computer access can be set to many differing levels. When IS auditors review computer accessibility, they need to know what can be done with the access and what is restricted. For example, access restrictions at the file level generally include the following:
- Read, inquiry, or copy only
- Write, create, update, or delete only
- Execute only
- A combination of the above
Authentication of an individual’s identity is a fundamental component of physical and logical AC processes. When an individual attempts to access security-sensitive buildings, computer systems, or data, an AC decision must be made. An accurate determination of identity is needed to make sound AC decisions.
A wide range of mechanisms is employed to authenticate identity, utilizing various classes of identity credentials. For physical access, individual identity has traditionally been authenticated by use of paper or other nonautomated, hand-carried credentials, such as driver’s licenses and badges. Access authorization to computers and data has traditionally been authenticated through user-selected passwords. More recently, cryptographic mechanisms and biometric techniques have been used in physical and logical security applications, replacing or supplementing the traditional credentials.
The strength of the authentication that is achieved varies, depending on the type of credential, the process used to issue the credential, and the authentication mechanism used to validate the credential. This document establishes a standard for a PIV system based on secure and reliable forms of identification credentials issued by the federal government to its employees and contractors. These credentials are intended to authenticate individuals who require access to federally controlled facilities, information systems, and applications.
About the author:
Leighton Johnson is the CTO and Senior Security Engineer for Information Security and Forensics Management Team (ISFMT), a provider of computer security, forensics consulting & certification training. He has more than 38 years of experience in Computer Security, Software Development and Communications Equipment Operations & Maintenance. Primary focus areas have included computer security, information operations & assurance, software system development life cycle focused on modeling & simulation systems, systems engineering and integration activities, anti-terrorism/cyber terrorism, database administration, business process & data modeling. Mr. Johnson just completed service as the AT/COOP task lead for a DOD Field Agency, based in Alexandria, VA. He recently was the CIO for a 450-person directorate within Lockheed Martin IS&GS covering nine locations within the Eastern and Midwestern parts of the U.S. Mr. Johnson previously served as Security Operations Program Manager for a US DOD Field Agency, based in Arlington, VA. He is a member of the CSA CloudSIRT working group developing the model for response collaboration among cloud providers, responders and users; the CSA Security-as-a-Service working group developing the definitions for SECaaS requirements and models, as well as a member of the IEEE Education working groups on Cloud and on Computer Software Security.