unisys ClearPath Enterprise Servers OS 2200 Security Overview September

Transcription

1 unisys ClearPath Enterprise Servers OS 2200 Security Overview September

2 NO WARRANTIES OF ANY NATURE ARE EXTENDED BY THIS DOCUMENT. Any product or related information described herein is only furnished pursuant and subject to the terms and conditions of a duly executed agreement to purchase or lease equipment or to license software. The only warranties made by Unisys, if any, with respect to the products described in this document are set forth in such agreement. Unisys cannot accept any financial or other responsibility that may be the result of your use of the information in this document or software material, including direct, special, or consequential damages. You should be very careful to ensure that the use of this information and/or software material complies with the laws, rules, and regulations of the jurisdictions with respect to which it is used. The information contained herein is subject to change without notice. Revisions may be issued to advise of such changes and/or additions. Notice to U.S. Government End Users: This software and any accompanying documentation are commercial items which have been developed entirely at private expense. They are delivered and licensed as commercial computer software and commercial computer software documentation within the meaning of the applicable acquisition regulations. Use, reproduction, or disclosure by the Government is subject to the terms of Unisys standard commercial license for the products, and where applicable, the restricted/limited rights provisions of the contract data rights clauses. Unisys and other Unisys product and service names mentioned herein, as well as their respective logos, are trademarks or registered trademarks of Unisys Corporation. All other trademarks referenced herein are the property of their respective owners.

3 Contents Section 1. Introduction 1.1. OS 2200 Security Goals Documentation Updates Section 2. The Secure OS 2200 Environment 2.1. Defense in Depth Secure System Architecture Availability Software Security System Overview MAC and DAC OS 2200 Security Levels Section 3. Identification and Authentication 3.1. Overview of Authentication Methods Traditional Exec User-id/Password Authentication Programmatic User-id/Password Authentication Configured Password Profiles Single Sign-on OS 2200 Host Sign-on Using Workstation Credentials Impersonation Hacker Frustration Section 4. Access Control 4.1. Controlling System Access Controlling Access to Transactions Controlling Access to Files Access Control Records Database Access Controls Administrators Processing Rights Resource Control Section 5. Cryptography 5.1. Data Encryption Ciphers Message Digests Digital Signatures iii

4 Contents 5.5. Public Key Infrastructure Tape and Disk Encryption Database Encryption CIFS ZIPUT Encryption Section 6. Network Security 6.1. TLS and SSL Cipher Suites Secure FTP Secure Communication APIs Secure Terminal Sessions BIS Sessions Network File Sharing Web Transaction Server Unisys Stealth Secure Messaging Section 7. Audit and Assessment 7.1. System Log File Monitoring Security-related Events Apex Reports and Information Displays SECMGR Reports TeamQuest Log Analyzer Intrusion Detection System PCI Compliance iv

5 Contents v

6 Contents vi

7 Section 1 Introduction This overview provides an introduction to the security-related features and benefits of the ClearPath Forward OS 2200 system architecture, operating system, and software products. It introduces the following important security concepts: The following security concepts and system security products are described in this overview. Secure environment: The OS 2200 operating system and underlying hardware and firmware, which have been designed together to meet a wide range of security requirements. Identification and authentication: Confirming the user and computer program identities. Access control: Enforcing security policies to ensure that users are authorized to access system resources and data. Cryptography: Ensuring that messages and data can be read by authorized parties only. Network security: Ensuring that data in transit can be secured and only authorized users can use the network resources. Audit and assessment: Verifying compliance with security policies and monitoring and analyzing security-related events. Throughout this document, references to product information and related documents are included to help you to implement and manage a secure networking and data processing environment OS 2200 Security Goals The following are key goals for OS 2200 security: Data Confidentiality and Integrity Control access to protected data by validating the security attributes of users before letting them access the data. Provide options for protecting data through encryption. Control the use of security-sensitive system interfaces. System and Data Availability Identify users and give system access to authorized users only

8 Introduction Promote system and data availability with redundancy and fail-over options. Inhibit denial of service attacks by regulating external access and internal resource usage. Secure Integrated Enterprise Support interoperable security, so that ClearPath OS 2200 servers can be fullyfunctional members of secure heterogeneous enterprises. Log security-related events with enough information to permit detection of attempted policy violations and facilitate incident investigation. Allow programs to securely share resources while protecting private resources. Efficient Security Administration Make it easy to be configured securely. Allow flexible security configuration to conform to site security policies. Support efficient security auditing and assessment Documentation Updates This document contains all the information that was available at the time of publication. Changes identified after release of this document are included in problem list entry (PLE) To obtain a copy of the PLE, contact your Unisys representative or access the current PLE from the Unisys Product Support website: Note: If you are not logged into the Product Support site, you will be asked to do so

9 Section 2 The Secure OS 2200 Environment The OS 2200 security system is designed to protect data from unauthorized access, modification, or exposure, while keeping systems and data available to support your business. If the system is used properly in conjunction with other vital security measures, your site and your data will be well protected and available. OS 2200 security is based on a combination of hardware and software architecture, including features that you can deploy to meet the requirements of your security policies. OS 2200 is flexible enough to let you choose the protections that you need and deploy and administer them efficiently Defense in Depth Defense in depth provides multiple layers of protection against attacks that can harm your enterprise. From physical security to network perimeter firewalls to safeguards in the hardware, firmware, and software on data center servers, each layer contributes to the safety of your data and your customers access to it. The ClearPath OS 2200 environment provides for multi-level data confidentiality, integrity, and availability protection: Access controls at the heart of OS 2200 file security promote the protection of your data. Encryption is an option when you need privacy for sensitive data. Database management software provides additional security; its finer-granularity access controls can protect individual fields and groups of data items. The OS 2200 transaction processing infrastructure provides additional security for transaction processing programs. OS 2200 resource control helps prevent the denial of service that can result from a runaway process monopolizing a shared resource. Data mirroring solutions are designed to keep your business-critical data available even if access to a file or disk is disrupted. Complementing the OS 2200 data privacy and integrity mechanisms are the user authentication controls that govern entry to the server, along with firewalls and other security measures in your corporate network

10 The Secure OS 2200 Environment 2.2. Secure System Architecture The OS 2200 system architecture, the OS 2200 operating system, and security software work together to provide tools you can use to control access to you systems and data. The security features of OS 2200 system architecture are included in all OS 2200 systems, on both custom hardware and Intel-based servers. Address space isolation OS 2200 server hardware and firmware isolate address spaces to keep one process from accessing the memory of another unless it is explicitly allowed, helping to keep data private and confine the effects of any bugs or attempted exploits. Locks and keys A lock and key mechanism permits controlled, secure sharing of code and data. Each memory bank is protected by a lock, and each executing thread has a key. Rings Concentric rings of security provide architecturally-defined privilege levels that protect the operating system kernel and privileged subsystems. Separate data and control stacks OS 2200 architecture includes a dual-stack architecture that helps prevent buffer overflow exploits. For more information about how security is central to the OS 2200 system architecture, read the Unisys white paper, ClearPath OS 2200: Unsurpassed Security Availability ClearPath OS 2200 offers a number of solutions that help keep systems and the data on them available to applications and users by minimizing both planned and unplanned downtime. Among them are the following: Redundant componentry such as mirrored memory, binding of NICs, multiple hardware paths to storage, redundant fabric interconnect components, and Extended Transaction Capacity (XTC) clusters. Automatic fail-over. Extensive error recognition, fielding, retry, and recovery actions built in to the hardware, drivers, and software. Integrated management of incoming messages, database updates, transaction state, distributed transaction management (e.g., two phase commit) with system software support to recover these processing aspects to a consistent state quickly in the event of a failure. Data reorganization without loss of availability

11 The Secure OS 2200 Environment For more information see the ClearPath OS 2200 Integrated Recovery Conceptual Overview ( ) and the Availability section of the Unisys white paper, ClearPath OS 2200: Unsurpassed Security Software Security System Overview Many security attributes of the system are determined by configuration parameters specified when OS 2200 is installed. Others, including security attributes of users, files, and other system objects, are established using security administration software, including Apex, processor and TeamQuest SIMAN. The security officer and administrators set up system-wide security attributes using these tools. All users can use those same tools, in addition to the Executive Control Language (ECL), to control the security attributes of files and other objects that they own. System software for communications, transaction processing, file transfer, message processing, and other core functions supports additional security configuration options MAC and DAC OS 2200 access controls include the concepts of Mandatory Access Control (MAC) and Discretionary Access Control (DAC). DAC controls are discretionary because the file owner can grant access to other users at his discretion, whereas MAC controls are mandatory because the file owner cannot grant another user the right to override them. MAC and DAC are discussed in more detail in the Access Control section of this overview OS 2200 Security Levels OS 2200 security options give you the flexibility you need to tailor your security environment to fit the security requirements of your site. They are organized into four levels, from fundamental security through security levels 1, 2, and 3. Each level is cumulative and builds on the previous level. Fundamental security and security levels 1 through 3 each provide sets of capabilities that you can individually enable. Each increased security level provides additional protections for sites with more stringent security requirements. Your decisions on which security level to deploy and which capabilities to enable depend on your evaluation of the tradeoffs between ease of use for external and internal users and the degree of protection required. Fundamental Security Fundamental security offers basic protection for the ClearPath enterprise computing environment. It establishes security controls at the system level and provides limited additional security based on an individual user s identity

12 The Secure OS 2200 Environment Fundamental security includes the identification and authentication, cryptography, network security, and audit and assessment features described in later sections of this overview. It includes many of the access control features described in the Access Control section of this overview. Security Level 1 Security level 1 provides additional protections beyond fundamental security. The primary benefits of security level 1 over fundamental security are: Enhanced access control Finer-grained allocation of processing rights Greater protection of the transaction processing environment (TIP) and databases. For more information contrasting fundamental security with security level 1, refer to the white paper ClearPath OS 2200 Security Benefits of Security Level 1. For the steps involved in moving from fundamental security to security level 1, refer to the white paper ClearPath OS 2200 Security Migrating from Fundamental Security to Security Level 1. Security level 1 includes the following features, most of which are discussed further in the Access Control section of this overview: File ownership With security level 1, private files are private by owner, not by account or project as with fundamental security. Cataloging a file as private restricts access to the owner of a file. The creator of a file is that file's owner. Mandatory Access Control (MAC): Clearance Levels Clearance levels categorize users, files, and subsystems in a system in a hierarchical fashion. Discretionary Access Control (DAC): Access Control Records The owner of an object can create an access control record (ACR) and attach it to the object to allow access to other users. Users are allowed access to the object according to conditions specified in the ACR attached to the object, if they first meet mandatory access control validation criteria. Special access controls on files in the Multi-Host File Sharing environment. TIP file security and default TIP user-id. Optional machine-generated passwords that are not easily guessed. Residue removal designed to make sure that programs cannot read data left behind by prior users. MAC and DAC for subsystem access. Enhanced auditing capabilities through additional security log entries not created in fundamental security

13 The Secure OS 2200 Environment Security Level 2 Security level 2 builds on fundamental security and security level 1. Features of security level 2 include the following: Mandatory Access Control (MAC): Compartments User-id records identify not only a clearance level range for a user, but also a set of compartments that can be accessed. A user can access a file only if his user-id includes all of the compartment sets that the file belongs to. Tape volume security through MAC and DAC Printout labeling Detection of improperly labeled and non-labeled objects Symbolic clearance levels TIP message security Security Level 3 Security level 3 provides the most complete software and hardware protection available within a very restrictive execution environment

14 The Secure OS 2200 Environment

15 Section 3 Identification and Authentication Identification associates a system user with an OS 2200 user-id. It can be done directly from the user-id the user enters when logging onto the system or by mapping the user s network identification to the internal OS 2200 user-id. Authentication verifies the identity of a user, providing assurance that users are who they claim to be. It can be performed on the OS 2200 server or on another server that passes proof of authentication to OS 2200 using secure protocols. Identification and authentication are the first steps in protecting your corporate data assets, and they are a prerequisite to maintaining an accurate audit trail of your system s users and events. The ClearPath OS 2200 operating system gives you a full set of user authentication choices, ranging from plugging into a centralized identity management system for the enterprise network, to user-ids and passwords managed by OS 2200, to smart cards and biometric devices. Each user s security record specifies that user s authentication type, so you have the flexibility to give each user an authentication type that fits his role. You can even provide authentication methods unique to your system. Regardless of how your users are authenticated, OS 2200 is designed to protect your system s resources, permitting only authorized access based on a user s authenticated identity and assigned privileges Overview of Authentication Methods OS 2200 provides password-based authentication in the Exec. It also provides additional authentication modules (AMs) for interoperability with Windows Active Directory, Kerberos, LDAP, and certificate-based authentication methods. These in turn allow enterprise single sign-on solutions to include Dorado servers. The Authentication and Session Initiation Subsystem (ASIS), released as part of User Authentication, provides the interface between the Exec and authentication modules, which reside outside the Exec and thus can be installed and updated without stopping the system. Some of the authentication methods described below require Message Integration Services, which supplies the network components. The AMs for these authentication methods are released along with Message Integration Services

16 Identification and Authentication For more information, see ClearPath Enterprise Servers User Authentication Administration Guide ( ) and Messaging Integration Services for ClearPath OS 2200 Help ( ) Traditional Exec User-id/Password Authentication Without using ASIS, users are authenticated by supplying a user-id and corresponding password that the Exec validates against the security database Programmatic User-id/Password Authentication ASIS provides the AUTH_USER and AUTH_CONTEXT API calls for programs such as Connectivity Services that need to validate a user-id/password combination. AUTH_USER supports validation against the local or domain database and allows the caller to specify the authentication module to use. Network authentication can use AUTH_USER with domain credentials (domain (optional), username, and password) or AUTH_CONTEXT with tokens. It can also use the SSPI APIs provided with Message Integration Services Configured Password Profiles Configured Password Profiles (CPP) allows a site to strengthen the requirements for user passwords, while using sign-on validation based on a user-id/password combination. With CPP, a site can use best practices for passwords and comply with PCI DSS, HIPAA, and other industry standards and regulations regarding passwords. The Configured Password Profiles authentication module (AM 19) enforces systemwide password rules for demand, TIP session control, and BIS sign-ons to OS 2200 systems by users whose security record says they use Configured Password Profiles. You can customize the set of rules to satisfy your site s security policies. Configured Password Profiles can require a new password to have: Minimum and maximum length (up to 32 characters) Minimum number of Alphabetic characters Upper case characters Lower case characters Special characters Character groups No easy-to guess sequences Repeated characters Sequential characters (for example, 34567, cdefg) Keyboard sequences (for example, qwerty, zxcv) Configured Password Profiles also supports:

17 Identification and Authentication Password reuse control Number of previous passwords that cannot be reused Previous passwords saved based on number or age Variance controls How different a password must be from the user-id How different a new password must be from the current password How different a password must be from personal information Password strength display with user choice User-supplied dictionary of words that may not be part of the password (forward or reverse) Additional configuration options include: Double solicit of a new password Login constraints based on time of day and day of the week (for example, only 8 AM to 5 PM on Monday through Friday). Update the legacy security database passwords Make the first password expiration period for a user-id a random number. Make the initial password the legacy password and retain it until it expires based upon the legacy last password change date Maximum time a password reset by the administer is valid Self-password reset after successfully answering a configured number of security questions Minimum number of days before the password can be changed Maximum number of days before the password must be changed Enhanced password expiration warning message For more information, see Configured Password Profiles in ClearPath OS 2200 Apex Help ( ) Single Sign-on OS 2200 supports three forms of single sign-on. In each of these, the user authenticates himself to his workstation, using whatever the workstation requires. This can be multi-factor authentication, using, for example, biometrics and smart cards in addition to a passphrase or PIN. A configuration setting, Disable traditional Exec authentication, together with configured authentication methods for each user, provides the access protections associated with multi-factor authentication to the OS 2200 host for users who do not need to log in directly. Windows Kerberos Kerberos is a network authentication protocol that enables users to securely prove their identity over an unsecured network, using a protocol that depends on a trusted third party. Windows Kerberos user authentication for OS 2200 is provided by a combination of AM2 and Message Integration Services. The user s workstation must use a UNISCOPE emulator that supports Kerberos tickets

18 Identification and Authentication Furthermore, both the 2200 hosts and the user s workstation require connection to a Windows Domain Server, which acts as the trusted third party. Because the Kerberos ticket includes a validated network user-id, the workstation user is not asked to supply either the user-id or the password when opening a session to the OS 2200 host. The network user-id from the Kerberos ticket must match a network user-id in the OS 2200 security database; after logging on, the user runs under the OS 2200 user-id corresponding to the network user-id. The authentication type in the OS 2200 security record is not used for Kerberos authentications. Setting it to 0 will let the user have an option of traditional Exec userid/password login. However, setting the authentication type of Windows Kerberos (AM2) can be convenient mnemonic for a user who is only allowed to log on using Kerberos. Windows NT LAN Manager (NTLM/NTLMv2) Windows NT LAN Manager (NTLM) is a network authentication protocol that uses a challenge-response mechanism that enables clients to prove their identities without sending a password to the server for authentication. NTLMv2 is an enhancement of NTLM that improves the authentication and session security mechanisms. These protocols are often used for systems that want single sign-on but do not use the Kerberos authentication mechanism within a Windows domain. Windows NT LAN Manager authentication is provided by a combination of AM3 and Message Integration Services. The user s workstation must use a UNISCOPE emulator that supports NTLM tickets. Furthermore, both the OS 2200 host and the user s workstation require connection to a Windows Domain Server, which validates the credentials in the NTLM ticket. Because the NTLM ticket includes a validated network user-id, the workstation user is not asked to supply either the user-id or the password when opening a session to the OS 2200 host. The network user-id from the NTLM ticket must match a network userid in the OS 2200 security database; after logging on, the user runs under the OS 2200 user-id corresponding to the network user-id. The authentication type in the OS 2200 security record is not used for NTLM authentications. Setting it to 0 will let the user have the option of traditional Exec userid/password login. However, setting the authentication type of Windows NT LAN Manager (AM 3) can be a convenient mnemonic for a user who is only allowed to log on using NTLM. TLS/SSL Certificates TLS/SSL (Transport Layer Security / Secure Sockets Layer) certificate authentication provides single sign-on to the OS 2200 host for the user who has already been authenticated to his workstation using a smart card or another workstation authentication method. A user at a workstation must use a UNISCOPE emulator that supports TLS/SSL certificate authentication. The path from the workstation to the host must be configured to use both client and server authentication

19 Identification and Authentication AM4 supports TLS/SSL certificate authentication by using the client X.509 identify certificate supplied as part of establishing a secure connection to the OS 2200 host. AM4 compares the CN (common name) field in the certificate with the network userid field in the OS 2200 user-id record. After logging on, the user runs under the OS 2200 user-id corresponding to the network user-id. SSL is supported for compatibility with older systems, but it is vulnerable to attacks that are not possible when TLS is used. OS 2200 supports TLS levels 1.0 through 1.2. When configuring your Communications Platform, use the highest level of TLS supported by the workstations that will access the system OS 2200 Host Sign-on Using Workstation Credentials Two authentication modules let the user use the same user-id/password for access to the OS 2200 host that they use for logging onto their workstations. It is not the same as single sign-on, since the user must enter the credentials, but it provides a convenience that might be of interest if the site s security policy allows the same credentials to be used for both the workstation and the OS 2200 host. Windows Username/Password The Windows username/password authentication method, provided by a combination of AM7 and Message Integration Services, lets users use the same logon credentials on the OS 2200 host that they use on their Windows system. It can be used from any workstation running a UNISCOPE terminal emulator. Windows username/password authentication solicits the user-id and password the same way as traditional OS 2200 sign-ons. The username and password entered must match the Windows username and password configured in the Windows Domain Server. The user-id entered must either exactly match either a network user-id in the OS 2200 security database or, if no matching network user-id is found, an OS 2200 user-id. Regardless of whether the match was the network user-id or the OS 2200 user-id, the authorization type in the security record must be Windows Username/Password (AM 7). After logging on, the user runs under this OS 2200 userid. OS 2200 Windows username/password logon credentials are passed to your OS 2200 server in clear text. To protect the logon credentials from malicious users, you should configure your session to use the SSL/TLS protocol provided by Communications Platform or Communications Platform for Open Systems. Lightweight Directory Access Protocol (LDAP) The Lightweight Directory Access Protocol (LDAP) method for user authentication is provided by a combination of AM12 and Message Integration Services. This authentication method lets users use the same logon credentials on the OS 2200 host that they use on their workstations, using an LDAP server that supports open LDAP protocols, rather than requiring a Windows domain server

20 Identification and Authentication TIP, demand, and BIS applications can use LDAP authentication from workstations running any UNISCOPE terminal emulator. The AUTH_USER API can be used with LDAP from any 2200 application program. Message Integration Services validates the user-id and password supplied by the user against the identifier and password in the LDAP server. Message Integration Services uses the UID attribute as the default for the unique user identifier. The LDAP identifier must match the network user-id in the OS 2200 user-id record, and the authentication type in the user-id record must be Lightweight Directory Access Protocol (AM 12). After logging on, the user runs under the OS 2200 user-id corresponding to the network user-id. With LDAP, password change is not supported at authentication time. You must use your LDAP server administration interface to change user passwords. LDAP logon credentials are passed to your OS 2200 server in clear text. To protect the logon credentials from malicious users, you should configure your session to use the SSL/TLS protocol provided by Communications Platform or Communications Platform for Open Systems Impersonation When a run calls an OS 2200 subsystem, the Exec switches the execution environment to the subsystem s, then switches back when control returns to the caller. Subsystems can use an OS 2200 Exec interface, SEC$IDENT$, to obtain the security identity of a caller. The identity includes the user-id, project, and account. On security level 1 and higher it also includes the clearance level, and on security level 2 and higher it also includes the compartment set. The interface allows retrieval of the security identity for the calling activity, the calling run, the caller of the subsystem, or an active step in a TIP session control environment. For more information, refer to the chapter Security Identification in the OS 2200 System Services Programming Reference Manual ( ). In some circumstances, it is appropriate for a subsystem to use the security attributes of the caller, rather than those of the subsystem. The Exec provides another interface, SEC$SWITCH$, that can switch to and from the caller s security attribute set. In fundamental security, only the security officer can use this interface. In higher security levels, other users who have the SSSWITCHUSER privilege can also use it. For more information, refer to the chapter Security Administration in the ClearPath OS 2200 System Services Administration Reference Manual ( ). The Apex agent and BIS 2200 are examples of software that uses impersonation to process information requests using the security attributes of the authenticated user that called them. The OS 2200 Connectivity Services (CS2200) subsystem provides an impersonation function based on an authenticated user that opened a connection. It gives a privileged

21 Identification and Authentication CS2200 agent program the ability to impersonate the authenticated logged-in user and process information requests using the security attributes of that user. For more information, see the Connectivity Services (CS2200) User s Guide ( ) Hacker Frustration Hackers often try to break into a system by repeatedly guessing user-ids and passwords until they find a valid combination. OS 2200 offers multiple hackerthwarting algorithms to help defeat these attempts. For example, one algorithm provides an increasing delay time between successive invalid attempts to submit a log-in credential. The delay time is quadrupled for each incorrect response and after the user has exceeded the maximum number of invalid attempts, OS 2200 communication software disables the terminal session. Another hacker frustration algorithm keeps prompting for credentials but ignores the responses after a configured number of unsuccessful attempts

22 Identification and Authentication

23 Section 4 Access Control Access control relies on authorization, the security practice of permitting access to systems and files through applied security policies and file access restrictions. ClearPath OS 2200 access control is primarily identity-based, with some aspects of role-based, attribute-based, and knowledge-based access control. Identity-based access control. System access is based on the authenticated identity of the accessor. Identity is also a key factor for access to files and other objects on the system. Identification and authentication, which are necessary for accurate access control, are discussed in section 3. Role-based access control. Access control records (ACRs) attached to system objects can define object access based on user-id group, rather than individual user-ids. These groups can correspond to roles, such as finance, catalog preparation, etc. Enterprise Relational Database Server for ClearPath OS 2200 (RDMS 2200) enforces additional role-based security. Attribute-based access control. Attribute-based access control applies to three types of access. o OS 2200 can base system access decisions on the network location of the accessor as well as a combination of user identity, time of day, and day of week. o ACRs can define object access based on a combination of user o execution attributes and time. Access to system resources, such as the instruction processor and pools of available memory, is based on run attributes run mode, scheduling priority and other execution options, and resource quotas. This type of access control, often called resource control, supports the security goal of availability. Knowledge-based access control. Object access can be based on knowing read and write keys in fundamental security. In higher security levels, read and write keys can be used on owned files if the system is so configured. The ability to execute certain controlled interfaces can be based in part on having assigned a certain system file with the correct read and write keys; in security level 1 and higher security levels, this control is applied after other controls have been satisfied. Restricting access only to authorized users and programs helps prevent intrusion into a system and unauthorized data access. This section explains how user access to systems and files can be controlled using these four types of access controls

24 Access Control 4.1. Controlling System Access The most basic method of controlling system access is to allow only those users with valid credentials to log on to your system. The security database contains the defined user-ids, associated passwords, and other user attributes, which determine whether access is allowed for a user. Users who are disabled or fail identification and authentication checks are not allowed system access. In addition, users whose authentication type is Configured Password Profiles, described in section 3, can be allowed or denied access based on the time of day and day of the week. Access can also be based on the remote terminal. SILAS (System Interface for Legacy Application Systems) includes an ACCESS-LIST configuration statement that can permit or deny access based on the network, subnetwork, or individual host requesting access. These access lists can control access to TIP and demand sessions as well as configured application groups. For more information about access control based on remote terminal identification, refer to PID and ACCESS-LIST in the ClearPath OS 2200 System Interface for Legacy Application Systems (SILAS) Configuration and Operations Guide ( ) Controlling Access to Transactions Access to a TIP transaction may be limited by the application itself, by TIP session control, or by application environments such as the Display Processing System (DPS 2200), the Online Terminal Security system (OTS 1100) from Formula Consultants, Inc., or UniAccess from Applied Information Sciences. TIP session control provides individual accountability in transaction processing. When TIP session control is configured, individuals requesting access to a TIP application are required to supply a user-id and password. All of the features for 2200 system signon, including hacker frustration, apply equally to TIP and Demand sessions. After a TIP session is established, TIP session control delivers the individual's security attributes to every transaction program executed during the session. When the transaction program requests access to any secured object in the 2200 system, the Exec reference monitor uses these attributes to decide if access should be allowed. The opening and closing of every TIP session are recorded in the system log file. All events that appear in the system log can then be traced to the individual transaction system user responsible for creating them. For more information about configuring TIP session control, see the description of the STEPCONTROL stream generation statement ClearPath OS 2200 Exec System Software Installation and Configuration Guide ( ). For transactions that use the Message Common Bank (MCB), fields in the transaction configuration can restrict the transactions that can be accepted based on the logical terminal number

25 Access Control For more information, refer to P$ID and terminal class in the ClearPath OS 2200 Message Control Bank (MCB) Administration and Operations Guide ( ) and the ClearPath OS 2200 Transaction Processing Administration and Operations Reference Manual ( ) Controlling Access to Files Fundamental security provides access controls on files based on the user s ability to specify keys at the time the file is assigned, and on access restrictions based on the user s project-id or account. Read or write keys can be specified when a file is cataloged, or a file can be cataloged as private by account or project, depending on how the FILES_PRIVATE_BY_ACCOUNT system parameter is configured. In addition, file cycles can be created as read-only or write-only. Security levels above fundamental security support controlled resource access based on user identity. Access control includes protecting files that must be shielded from unauthorized reading and malicious or unintentional modification while allowing them to be shared as necessary. This can be achieved by using discretionary access control (DAC) and mandatory access control (MAC). DAC controls are discretionary because the file owner can grant access to other users at his discretion, whereas MAC controls are mandatory because the file owner cannot grant another user the right to override them. DAC includes object ownership and OS 2200 access control records (ACRs). Security level 1 lets you implement MAC through clearance levels, which can be useful if you require a hierarchical structure to your access authority. Files are automatically classified in a range from most confidential to public domain depending on the clearance level of the creator and can only be accessed by those who possess a sufficient clearance level. In security level 2, user-id records identify not only a clearance level range for a user, but also a set of compartments that can be accessed. A compartment is a logical grouping based on interest or category, such as accounting, payroll, and personnel. A user can access a file only if his executing compartment set (a subset of all the compartments allowed for his user-id) includes all of the compartment sets that the file belongs to. For more information on clearance levels and compartment sets, see Mandatory Access Control (MAC) in ClearPath OS 2200 Apex Help ( ). Access to an object through DAC is enforced only after access to the object has been granted by mandatory access controls. TIP File and Database Access Control The security level 1 and higher transaction environments can use TIP file security, a configurable feature that extends the OS 2200 file security protection features to TIP files. This feature allows all TIP files contained in TIP/Exec file containers to be defined

26 Access Control as public, private, and ACR-controlled. The MAC protections of clearance levels and (in security level 2) compartment sets also apply to TIP files when TIP file security is configured. If you use TIP file security, you must use TIP session control, since the user attributes determine if access to the TIP file is allowed. For more about TIP security, see ClearPath OS 2200 Transaction Processing Conceptual Overview ( ). In security level 1 and higher, Enterprise Network Database Server for ClearPath 2200 (DMS), Enterprise Relational Database Server for ClearPath OS 2200 (RDMS), and Business Information Server for OS 2200 Environments (BIS) can use ACRs for database access control. Application groups are at the intersection of TIP and Universal Data System (UDS) data bases. In security level 1 and higher, each user-id s security record defines the application groups that a user can access Access Control Records ACRs apply to files and other system objects. They allow the owner of an object to give access to other users under conditions that the owner specifies. Objects include: User, Exec, and TIP files DMS schemas, areas, records, and sets User-ids Subsystems The owner of an object can create an ACR and attach it to the object to allow or deny access by other users. An ACR is identified by the combination of the name and owner. Two different owners could have ACRs with the same name and completely different access restrictions. Using ACRs Access restrictions in ACRs specify the type of access controlled; read, write, execute, and delete are the most common. When a subsystem is treated as an object, it can have an ACR indicating who may invoke it as an object. The object owner always has access. ACRs additionally grant access to specific userids, user-id groups, accounts, or projects. They can also allow or deny access based on time of day and based on combinations of attributes. User-id Groups User-id groups provide a means to simplify access control administration by allowing user-ids to be aggregated into groups that can be used in ACR access restriction expressions. This provides a convenient way to give the same file access rights to

27 Access Control many users while maintaining separate user-ids for system access, billing, and auditing. Groups can include other groups. A user-id or group can belong to more than one group, providing flexibility when one person does more than one job. When an ACR controls access to a set of files via a user-id group, new users can be granted access to the set of files by just adding their user-ids to the group Database Access Controls ClearPath OS 2200 database management software uses the underlying architectural features mentioned in section 2. They protect the main memory and the disk files associated with the database. Database security is based on the OS 2200 user-id that comes from an interactive, transaction, batch, or BIS log-on; via ODBC or JDBC; or through an API that invokes the OS 2200 security kernel. Only users with the proper security attributes are allowed access. Suppose your company s business policy allows a particular set of users to update the database using batch programs or transactions, but it doesn t allow those users to update the database using ODBC or JDBC. This policy can be implemented using ODBC and JDBC configuration attributes. When tables are created with DATA ACCESS CONTROL ACTIVE and with an owner, then access to the data is restricted to the table owner. This database feature is available on all system security levels. For a user other than the table owner to access data in the table, the owner must grant the user access. The granularity of RDMS 2200 security allows privileges to be granted such that the user can only access: The table A specific version of the table A view over the table. A view can be used to allow access only to: A subset of columns of the table (e.g., can see a person s address but not the salary) A subset of rows of the table (e.g., only those rows pertaining to the user) Only an average of a set of the table rows Users can be granted privileges to SELECT, INSERT, UPDATE, or DELETE records. Role security simplifies the granting of privileges by allowing a user-id to be placed into a role. The role is granted privileges instead of each individual user. Whenever a user attempts to access database data, but is denied based upon security attributes, this failed attempt is recorded in the OS 2200 system log file

28 Access Control The Business Information Server (BIS) software that runs on ClearPath Dorado servers is integrated with the Exec for authentication, authorization, and impersonation. BIS runs can also call Cipher API to encrypt or decrypt data. In addition, BIS provides its own access and authorization controls. For example, programmers are limited in which BIS runs they can change, and the BIS administrator can use the run registration report to limit which drawers each run can touch. To help the BIS administrator, Unisys provides security best practice recommendations Administrators One user-id is designated as the security officer. This user-id has the highest levels of security administrative capabilities on the system. OS 2200 security provides four administrative privilege levels: The security officer (the equivalent of a Unix super-user) An administrator, designated by the security officer or an administrator to maintain a set of user-ids but otherwise unprivileged. Administrators can perform all user-id installation and maintenance tasks. A subadministrator, designated by the security officer, an administrator, or a subadministrator to maintain a set of user-ids but otherwise unprivileged. Subadministrators can install user-ids and maintain those they have installed, but they are more restricted than administrators in the processing rights they can give to the user-ids they create. A subadministrator can be given or denied the right to create other subadministrators. An unprivileged user The security officer, administrators, and subadministrators can use Apex, the SECMGR processor or TeamQuest SIMAN to define access rights and processing rights, manage user accounts, and maintain the security database. In addition, specific privileges may be configured for otherwise unprivileged users to allow them to perform specific administrative tasks. These are discussed further under Processing Rights, in this section. As an administrator, you can do the following: Establish system-wide security settings, such as the security level, options within each security level, and logging settings, in support of enterprise security policies. Establish user account policies to be used in OS 2200 account management. Establish resource usage policies. Configure password policies that apply to system users. (See Configured Password Profiles in section 3.)

29 Access Control Run reports to verify conformance with security policies. Reports are discussed in section Processing Rights Processing rights fall into two categories: privileges and privileged system interfaces. Enforcement of a user s rights and restrictions when the user executes programs complements the authorization controls provided by MAC and DAC. For example, a user-id created solely for system administration might be given a privilege to override certain access controls and might be allowed to use system interfaces that are restricted from use by ordinary users. In fundamental security, the security officer has all processing rights, and other users can assign the file SYS$*DLOC$ with the correct read/write keys to get a fixed set of 15 privileges. Security level 1 and higher levels provide fine-grained allocation of processing rights that allows users to be granted only the rights needed to perform their jobs. This is called the principle of least privilege, and it is an important part of many security policies. In OS 2200, these processing rights are privileges and privileged system interfaces. OS 2200 security administration tools let you specify in a user's security record the privileges and privileged system interfaces to be assigned to that user-id. Privileges Certain users may need to override the default security system restrictions to do their jobs. The typical end user does not need any special privileges. Privileges must be assigned to users who install products, who perform administrative tasks, or who start or execute products with special requirements such as Communications Platform, File Administration System (FAS), or the Integrated Recovery Utility. For example, the FAS program used for backing up or restoring data uses privileges that bypass ACR and clearance level checking to allow it to back up any owner s files. Privileged System Interfaces Certain system interfaces (ERs and Call interfaces) must be controlled to maintain security. Unisys Apex, SECMGR, or TeamQuest Site Management Complex (SIMAN) let you specify the privileged interfaces accessible by a user-id. For example, only the user-id for the Communications Platform (CPComm) or Communications Platform for Open Systems (CPCommOS) subsystem should be allowed to use the privileged system interface that initializes a network. Default Privileges and Interfaces Unisys-supplied runstreams define a set of user-ids with the privileges and interfaces needed by the standard Unisys-supplied subsystems and background runs. They also define a default set of ACRs and attach them to the subsystem files