AIX

   Introduction This section identifies control concerns and risks in an AIX installation and contains a list of questions the auditor might ask to obtain an overview of the effectiveness of controls in the computer environment. Below each control concern, is a reference to the page(s) in this manual where the issue is addressed. This section also identifies the tests that might be performed at an AIX installation. The concerns and test are not meant to be a comprehensive list, nor is performing all the tests necessary in every situation. Selecting procedures, if any, to be performed is a matter of judgement after assessing the risks at a particular installation. AIX is supplied with good documentation. Some of this documentation is stored on a CD-ROM disk and is accessible by most system users. When commencing a review of an AIX installation, the following should be obtained. Details of the equipment and significant applications used. A diagrammatic representation of the various components of the network, including their location and method of communication. The diagram also should show the extent of use of differing hardware platforms and software products. If different applications are used at different locations and/or servers, these too should be noted. Identification of system responsibility (e.g., system administrator), who knows the root password, and who is the security officer. A list of user groupings, their purpose, and their members. A copy of the company security policy and procedures applicable to users and system administrators. A list of the security features used, and strategy adopted by the security officer. This strategy may include, for example, the procedures followed by the security officer in reviewing and controlling security.    A copy of the program and system change control procedures and any related documentation (e.g., changes control request/authorization forms). A copy of the disaster recovery plan applicable to the site(s). This is not essential for the completion of a review, and may not constitute part of the scope of the review. However, with computer systems becoming an ever increasing component of a company’s operations, it would be prudent to review the plan. Control concerns in this section are similar to those in other computer environments. Within the AIX environment, (as with UNIX environment) there are some unique risks that relate to AIX installations that are not found in traditional IBM mainframe environments. One of the main differences is that there is usually considerably less IS staff in an AIX environment that one would typically find in a mainframe environment. This could results in a lack of segregation of duties. Another risk that is greater in UNIX environments (as opposed to mainframe), is that the command shell provided for users is considerably more powerful. For all intents and purposes the traditional UNIX shell can be considered to be a programming language/environment and hence the potential for the unauthorized creation, development of, and changes to software programs is increased. Readers should refer to the Ernest & Young Technical Reference Guide Audit, Control and Security Features of the UNIX Operating System (EYI Number FF0079) for additional guidance in this area.    Users Profiles The concerns listed here relate to local users (rather than network users) password controls. Control Concern Users are not uniquely identifiable and accountable for their activities. Risk If users cannot be uniquely identified, they cannot be held accountable for their actions. Without user accountability, user control over systems are not effective. Overview Questions 1. How are user profiles determined? (Are there “standard” user accounts for different employee levels? Do functional managers determine their staff’s access capabilities? Are the accounts determined by the system administrator/security officer?) Are any group shared user accounts used? Why are these necessary? What standard settings are used in defining a user account? Have these been defined in the /ect/security/mkuser.default file? Are guest accounts active on the system? What access privileges have they been granted? How are they controlled? Are there any user profiles that are automatically defined when the system was installed that are currently not required? If so, have they been deactivated? 2. 3. 4. 5.    Audit Procedures If group shared user accounts exist, determine their identity and what controls are in place to control group members’ activities. Review the contents of the /etc/passwd file, to determine if each user account has a unique UID (User ID) number. Compare a sample of the contents of the /etc/security/.ids file to the /etc/passwd file and ensure that the next user and group Ids (contained in the /ect/security/.ids file) are correct with respect to the /etc/passwd file. If not, establish reasons for the disparity. Evaluate controls in place to restrict the user of guest accounts. For example, terminal restrictions may be used to restrict use to a specific terminal where the activities of the person using the account can be monitored. Another method used could be for the guest account to automatically load a program and disallow access to a shell (use the Isuser command to obtain in full list of each profile’s attributes). Inquire if obsolete standard user profiles installed with the operating system have been disabled (to reduce the risk of unauthorized access). Run the usrck - n ALL command. Review the report contents and inquire about any unusual settings. Control Concern Only authorized users can access the system. Authorized users can only perform functions to which they have access. Risk Users have unauthorized access to the system. Users have more access capabilities than they are authorized to have. User account of former employees are still active when they should not    be. Former employees’ user Ids are granted to new employees. Consequently, new employees incorrectly obtain access to files belonging to former employees. Overview Questions 1. 2. 3. 4. What procedures are followed to create a new user account? What procedures are followed to remove a user account? Who authorizes the creation/deletion and access capabilities of user accounts? Is there documentary evidence of the authorization? Are former employees’ UIDs re-assigned to new employees? If so, what procedures are in place to ensure that new employees do not obtain inappropriate access to files belonging to former employees? Is a review performed to establish which user accounts have not logged in for a period of time and the reasons therefore? What procedures are in place to identify files belonging to dismissed employees and reallocating them to appropriate employees? 5. 6. Audit Procedures Review the appropriateness of procedures to create or delete users and to determine if they comply with company security policy (if available). Review the documentation supporting the user creation/deletion process for appropriateness and compliance with the company security policy. If no policy is enforce, review and document the current procedures. Using the user account names in the /etc/passwd file, select a sample of profile names and match them to a list of personnel authorized to have access to the system. In addition, check these names to the personnel records to determine if these users are currently employed.    Review procedures for reallocating files belonging to retired/dismissed employees to current employees. Inquire if the system administrator/security officer performs a regular search for “orphaned” files. If necessary/appropriate use the find (find/ -nouser-print) command to locate such files. (The UID number rather than a user name will be reflected as the owner of a file.) Control Concern Default setting granted to new users are inappropriate. Risk Users are granted inappropriate group membership. Users are granted inappropriate system access. Overview Questions 1. 2. 3. What security strategies have been adopted with regard to defining the user and admin capabilities in the /etc/security/mkuser.default file? Are normal users granted access to standard UNIX shells? If so, which ones and why? Are users granted access to individual home directories, or are common home directories used? Audit Procedures Review the following files to determine if the settings are appropriate in terms of the company’s security policy and objectives.    /etc/security/mkuser.default /etc/security/login.cfg /etc/security/user Control Concern Environmental settings are inappropriate in restricting access to user’s “home” directories. Default file permission bits for newly created files are inappropriate. Risk Private/confidential data stored in a user’s “home” directory can be accessed by non-authorized users. (Examples of inappropriate access may include world and/or group read, write and execute access to a user’s home directory and/or sub-directories of the user’s home directory) Files created by users have inappropriate default ACLs allowing inappropriate “world” and “group” access capabilities. User configuration files (e.g., .profile file in the user’s home directory) should only be writeable by the security officer/system administrator and the user. An alteration by any other user of these settings could cause a security loophole by disabling security features, or adding other variables (e.g., adding another host to the .rhosts file). In addition, an unauthorized user could obtain valuable security information about a user such as special search paths, passwords, and user IDs for other systems. Overview Questions 1. 2. 3. Do all users have individual home directories in which they can store their personal files? Where are user’s individual configuration files (e.g., profile files) stored? What ACLs have been set on individual user configuration files that are    stored in their own directories? Are users able to change their own files? 4. What environmental settings have been set (e.g., time-out due to inactivity) in the global environmental files /etc/profile and /etc/environment ? Is the standard set of attribute settings (defined in /etc/security/user) used for all users? Which users have different settings and why? Do any users share the same configuration files, and if so how is this done? In terms of company policy and standards, what is the default unmask value? In terms of company policy and standards, what is the default PATH setting? 5. 6. 7. 8. Audit Procedures Review the ACLs of the user’s “home” directory to determine who, other than the user in question, has access permissions to that directory. Determine if these permissions are appropriate. Review configuration files /etc/profile, /u/$HOME/.profile, and /etc/security/user to determine if the access rights on these files are appropriate. Review the appropriateness of the contents of the environmental security settings contained in the /etc/profile, /u/$HOME/.profile, and /etc/security/user files. Ensure the configuration file contains a unmask value of 077 (i.e., full owner rights and no rights for the group or the world) or 027. If a site has adopted an alternative unmask value, discuss the reasons for this with the security officer.    Review the PATH setting contained in the /etc/environment, /u/$HOME/.profile files and determine if the current directory is specified. (NOTE: The current directory will be specified by a period, “.”). If it is specified, it should be specified at the end of the PATH setting. Control Concern Users’ group membership profiles are inappropriate to prevent unauthorized access. Group attributes (the setting of the administrative attribute and the defining of a group administrator) are inappropriately set. Risk Users are members of an inappropriate group and have unauthorized access to applications and data. Groups may have been inappropriately setup (e.g., all users belonging to one or very few groups). Normal users should not have access to the group to which a root user belongs (system) or any other administrative group. Administrative groups should have only root and/or other system users as members. Membership of certain “high access” groups (e.g., system and security) is inappropriately set resulting in normal users having inappropriate access capabilities. Group administrators maybe inappropriately chosen and/or set. Overview Questions 1. 2. How are groups used in the overall security structure? What procedures govern the group administrators in defining and    3. 4. redefining group membership? Who approves such changes? To which group(s) do system users belong? Which normal users are also members of the system and other administrative groups (e.g., bin, sys, adm etc.), and why is this so? Audit Procedures Obtain a list of all groups and group membership and inspect group membership for reasonableness. (This can be obtained by running the lsgroup - f ALL command under root privileges). Review the /etc/security/group file or the lsgroup -f ALL output and determine if group and other system users belong. (Only root and system users should be members of these groups) Run the /etc/grpck (grpck-n ALL) command and review the results. Control Concern Users have access to a command prompt that may result in access to utilities, shell scripts, applications, and data files to which they should not have access. Risk A user may have access to a command prompt, allowing access to utilities and shell scripts that could provide information regarding other user’s data or applications. A user with shell prompt access, may create a shell script that has undesired/unintended consequences for the security of applications or data on the system. Poorly defined search path commands may result in users having unauthorized access to directories/files and gaining inappropriate knowledge of the structure of the server.    Overview Questions 1. 2. 3. 4. Are restricted shells used? What measures have been taken to prevent users from accessing shell prompts? Do normal users have access to the shell prompt? If so, why? Is a menu application program used as a user interface, thereby eliminating the need to grant shell prompts to users? If so, what measures are used to prevent shell prompt access? If not, how are such prompts controlled? Are user PATH commands structured in such a way as to reduce or limit the user’s ability to move between directories on the file server? (This question is especially relevant when restricted shells are used.) What shells have been authorized for use on the system? 5. 6. Audit Procedures Review the list of shells in the /etc/security/logon.cfg file and match them to the list of authorized shells. Verify that users are using authorized shells. The lsuser command can be used to obtain a list of users and their shell attributes. (Isuser - a shell ALL) Review the PATH setting contained in the /etc/environment, and /u/$HOME/.profile files and determine if the current directory (denoted with a period, “.”) is specified. If it is specified, it should be specified at the end of the PATH setting. Control Concern User password controls are weak.    Risk Poor passwords and password controls often result in compromised system security. Poor password formation and poor password control negate user accountability. Poor password controls allow unauthorized users to enter a system more easily. “High risk” users should have password expiry interval shorter than the average user. A user profile could have been created by directly editing the /etc/passwd file rather than through SMIT, resulting in a password stored in the /etc/passwd file rather than in the /etc/security/passwd file. Overview Questions 1. Are password guidelines and a password policy in place that addresses password use and control? If so, do they specify the following password characteristics: • • • • • • Maximum life of password? Minimum life of a password? Minimum number of alphabetic characters in a password? Minimum number of non-alphabetic characters in a password? The minimum number of characters that are required to be different between old and new passwords? The minimum number of times a single character can appear in a password.    2. 3. 4. 5. 6. Do all user profiles require passwords? Is a password discovery program periodically used by the system administrator to identify inappropriate passwords? Are users educated in good password selection techniques? Are “Two-Key” authentication systems used for select user profiles? Are alternative (to system password mechanism) authentication systems used? If so, with which groups of users? Audit Procedures Review the /etc/passwd and the shadow password file (/etc/security/passwd) to identify users who do not have passwords and inquire as to the reasons. Compare the contents of the two files to establish if there are any users who do not have their passwords stored in the /etc/security/passwd file. (This also can be done by using the pwdck -n ALL command). Review the /etc/security/login.cfg file pw_restrictions settings for compliance with the company security policy. Tour user work areas to look for evidence that users may have documented their passwords. Ask users if they are aware of a password security policy and its contents. For those user profiles that are using the “Two-Key” authentication systems, review the setting contained in the /etc/security/user file. Determine if the mechanism is defined and working as described. For those users where alternative authentication programs are used, review the settings in the /etc/security/user (for the definition of which authentication programs to use) and /etc/security/login.cfg (for the definition of alternate authentication programs) files to establish if the mechanism is defined as described. Consider testing the authentication program, if appropriate. Run the /etc/pwdck (pwdck -n ALL) command and review the reports for    security weaknesses. File and Directory Access The concerns listed here relate to both file and directories and the Access Control Lists (ACL) that control access to those resources. Control Concern Either users are creating directories/files with inappropriate ACLs (resulting in possible unauthorized access to such files) or a user/hacker is loading programs and data files to the system in an unathorized manner. These files, if SUID programs, could compromise access security. Risk Users may have created directories and files with inappropriate ACLs. Users may have changed the ACL on the wrong directory/file or used inappropriate ACL settings, resulting in possible inappropriate access to these files. Hackers or users with malicious intentions could write programs or shell scripts that have not been tested. These untested programs may have undesirable consequences. Furthermore these files might be available to all users via inappropriate ACL settings. Overview Questions 1. 2. Does the installation have a list of directories and files that should have “world” writeable, readable, and/or executable ACLs? Are regular reviews performed to determine the owner and the nature of these (world readable) directions and files? Audit Procedures    Using the find command, extract a list of all directories and files that are “world” writeable, readable, or executable, and review the list with the systems administrator to establish the validity of this access. If the systems administrator performs a regular review of such files, asses the evidence of the review. Control Concern User directory ACLs allow inappropriate “world” and group access to files contained therein. Risk User directories are normally assigned to individual users and are reserved for the exclusive use of that user. The user may store confidential data in this directory that may be compromised by inappropriate access to these programs and data. Overview Questions 1. 2. 3. Is a user’s home directory reserved for the user’s exclusive use? Are data and program files for use by an entire department stored in a department directory or are they stored in an individual’s directory? Are files that contain confidential data stored on the system? Audit Procedures Using the find (find/home -type d -exec ls-ed {}\; -print) command extract a list of the access permissions of the users’ directories and select a sample of permissions and review to determine if the permission bits are appropriately set.    Control Concern Users who execute application programs also have the ability to change the contents of the application files and directories. Risk Users may change program files without required authorization and avoid conforming to normal change control procedures. Overview Questions 1. 2. What ACL permissions have been set up for program files and directories? Does the security officer review these permission bits on a regular basis? Audit Procedures Using the find command, extract a list of the ACLs of the program files and directories. With the assistance of the system administrator, review this information to establish the appropriateness of the ACLs. If a regular review of program file and directory permission bits is undertaken by the system administrator, review the working papers to ensure these bits are appropriately set. If application program are defined to the TCB, run the tcbck program against this class of files. Control Concern Extended ACLs have been inappropriately set, resulting in an undesired level of security.    Risk Extended ACLs may not restrict certain users form altering or accessing directories and files in an unauthorized manner. Overview Questions 1. 2. 3. Are extended ACLs used on this system? If so, briefly describe their use. Who (which type of user) uses extended ACLs? Are reviews ever performed to test the integrity of these extended ACLs? If so, who performs the reviews, what procedures are followed, and what is done with the results? Audit Procedures Extract a list of directories and/or files where extended ACLs have been used. With the assistance of the system administrator, review the settings looking for possible security weaknesses. TCB Control Concern Standard UNIX tools and utilities are inadequately protected by the use of file permissions bits. Risk Malicious program code could be “piggybacked” in the code of standard utilities. Hackers and users with malicious intent could replace or modify standard utilities.    Several utilities have very powerful capabilities and are intended for use only by system administrators. If the file permissions bits are altered, these utilities could be used by other users (e.g., the shutdown command shuts down the server in a controlled manner, and should only be executed by the root user). Overview Questions 1. 2. 3. 4. Are all standard tools located in the directories they were in at installation? Have the more powerful and “dangerous” tools being moved to nonstandard directories? Have any of the standard tools supplied at installation been changed? If so, were such changes authorized and has the TCB been updated? Have device drivers and other configuration “tools” that are not required been moved/deleted? Audit Procedures Review the owner, group, and world file permissions bits of the files in the directories /etc, /dev and /bin and other system directories to determine that these are appropriate. (In general, most should be owned by the root or by some other system user). Files in the /etc directory should not generally be writeable by all users. Determine that the file /etc/shadow does not have any “world” rights, and the /etc/passwd file has only read “world” rights. Files in the /bin directory also should not generally be writeable by “world” users. Review the shell files (csh, ksh, sh, rksh, rsh) and determine these files only have executable rights. Their date stamps should all be the same date. Determine that files in the /dev directory are accessible according to the    intended use. (e.g., tape devices should probably not be accessible by regular users.) If the systems administrator periodically reviews the contents of these directories for inappropriate files or files that have unusual date stamps, review working papers for evidence of an appropriate review. Control Concern The trusted computing base contains file definitions that it should not contain. The trusted computing base does not contain file definitions that it should. Risk Verifications of the TCB do not provide an adequate basis upon which system security is based. Overview Questions 1. 2. What changes have been made to the TCB database file (/etc/security/sysck.cfg)? How often is the tcbck program run? In what mode is it run? What corrections (if any) are made based on the report? Audit Procedures Run the tcbck program and discuss the results with the system administrator (use the command tcbck -n ALL). Restrictions over Root/Superuser Access The concerns listed here relate to the use and control of root or superuser profile.    Control Concern Unauthorized users have access to the system as root/superuser. Risk If too many people have the ability to su (substitute user) to root, or can login as root, then access security can be easily compromised. Overview Questions 1. 2. 3. Who should know the root password? Who can su to root? When users use the root profiles, do they log onto the system directly using the root profile or do they log on with their own profiles and use su? Is the root user forced to use a trusted communication path? Have restrictions been placed on terminals from which the root profile cna login? Can the root user use the rlogin command? 4. 5. 6. Audit Procedures Request a list of users who should know the root password and determine if this knowledge is appropriate. Review the /etc/security/user file, review the following settings for the root user and establish if they are appropriately set. telnet rlogin    su sugroup ttys    Control Concern Several users who have access to the root password can change the password. Risk Poor control over the root password could result in compromising system security. Overview Questions 1. 2. 3. 4. 5. 6. Is a two key authentication system used with the root profile? Is an authentication system other than passwords used with the root profile? How many users have access to the root password? Do they all perform system administrator functions? What controls are in place to safeguard the root password? How often is this password changed? Who determines the new password and how are authorized users informed of the change? Audit Procedures Review the root password change control procedures and comment on their adequacy. Where a two key authentication system is used, review the settings in the /etc/security/user file to verify the activation of the two key system. (An alternative is to type in the command lsuser -a auth1 root).    Control Concern In emergency situations, where the root profile and password are often used to bring up the system, the password may be accessed by personnel not Risk When the root password is used in an emergency, by personnel not normally entitled to know or use the password, an opportunity for unauthorized access to the system is created. Overview Questions 1. 2. Who can gain access to the root password in an emergency situation? What procedures are followed to obtain the password, and then to subsequently change it? Audit Procedures Review the emergency procedure to determine the adequacy of controls over the use and changing of the root password. Control Concern Users who are members of the same group(s) as root may gain unauthorized access to files and directories to which the root is also a member. Risk Access to files and directories owned by root, or owned by a group which root belongs are sensitive. Unauthorized use could compromise systems security.    Overview Questions 1. 2. 3. 4. To which group(s) does root belong? Do all members of these groups have the same access rights as root? Which group is root’s default group? Does the root’s unmask value grant any access rights for newly created files to a group? Audit Procedures Inquire as to which group(s) root belongs, and determine if such membership is appropriate. (Information can be obtained from the command lsgroup -n ALL Typically the only other members of these group(s) are system users). Review the unmask settings in the root .profile file, and confirm it is set appropriately. (Luser -a unmask root) Using the find command, extract a list of all files and directories whose owner is root but whose group ownership is not a group to which root belongs and/or is not an operating system defined group. Discuss findings with the system administrator to determine if such usage is appropriate. Output and Printers The concerns listed here relate to security over printed information. Control Concern The accurate identification of output is vital to ensure that all output is delivered to the proper user.    Risk Users may obtain unauthorized access to confidential information. Overview Questions 1. 2. 3. What controls are in place to ensure that users receive only their output? How is output identified as belonging to an individual user? Are printer headers used to identify output? Control Concern Location of printers can form an important part of the controls surrounding the identification and distribution of output. Location of printers which allow public access or are in unsecured locations can result in users gaining unathorized access to information contained on computer printouts. Risk Printers that are located some distance from the users may discourage users from collecting their output on a timely basis, increasing the possibility that the contents of the output will be seen by unauthorized personnel. Overview Questions 1. 2. Where are printers located? Are the printers located next to a user who is responsible for controlling the output?    Audit Procedures Review the location of printers and controls over output. Control Concern Control of printer queue must vest in a responsible user, as this user can hold, redirect, and/or delete a print job from a print queue. Risk A print queue operator could hold a print job and print it later in the day. The user whose printout has not been processed may be induced into resubmitting the print job in order to collect it. The held job could then be released and the output collected without the user being aware that an unauthorized copy existed. Overview Questions 1. 2. 3. Who controls the print queues? What functions can these users perform over jobs in the print queue? What review/control procedures are in place to safeguard output submitted to print queues? Audit Procedures Review the adequacy of controls over print queues. Networks Security features over networks and network communication are complex. Control Concern    If trusted hosts are defined to the system, then reliance is placed on the security of other systems. These systems’ security may be weaker than local requirements. Risk If the security on the trusted system is poor, then access security of the local system could be compromised. Overview Questions 1. 2. 3. 4. 5. 6. Are trusted hosts connected to local systems? If so list these trusted hosts. Why are trusted hosts used? Does the /etc/hosts.equiv file contain a plus sign (+)? (Then plus sign allows any host to attach as a trusted host). Do the systems named in the /ect/hosts.equiv file relate to other systems in the organization? Are users permitted to have .rhosts files in their home directories? Which users have .rhosts files in their directories? How are these controlled? Audit Procedures Compare the list of trusted hosts provided by the system administrator to the contents of the /etc/hosts.equiv file and obtained explanations for any variances. If the /etc/hosts.equiv file contains systems over which the organization has no control, arrange for a review of the security of those systems or obtain a report from that organization’s auditors as to the security over those systems. Review the /etc/hosts.equiv file for a plus sign(+). If it exists, inquire as t the    reasons for its presence. Using the find command, search the file system for all .rhost files should be setup by the system administrator, and only changed with the security officer’s permission.) Control Concern The finger program could be used by an unauthorized person to gain information regarding the users of the system. Risk The unauthorized use for the finger program may result in user profile names and last login dates used by unauthorized people to identify users who seldom use the system. Such usage might not be detected. Overview Questions 1. 2. Has the finger program been disabled? If it is use, what purpose does it serve? Audit Procedures Log-on and run the finger program to determine if it has been disabled. If the finger program has not been disabled, what information can be obtained by its use? Control Concern Inappropriate settings in the FTP and anonymous FTP daemons may result in appropriate access to the system. Risk By default, all user profiles are granted the use of the FTP program. High risk users (e.g., root) as well as most end users should be    restricted from using the program in case these users’ passwords have been compromised. Unauthorized personnel may use FTP to access data and programs from remote locations after hours or where their activities will not be questioned by fellow workers. If anonymous FTP is allowed, then any person could (if permitted) write files to the system that contain suspicious program code. Overview Questions 1. 2. 3. 4. 5. Are FTPs and anonymous FTPs used? If so, determine validity for such use. Has the use of FTP been restricted to a separate server so as to localize the potential risks of using FTP? Which users are subsequently restricted from using FTP? (By default all users are granted use of FTP.) Have specific directories been assigned for files sent and received by FTP, thereby restricting FTP access only to those directories? Does the anonymous FTP facility allow files to be read and written to the system? If writing of files is allowed, what procedures are used to review these file prior to their transfer to other parts of the system. Who performs the transfer? Who performs the review? Audit Procedures Review the contents of the /etc/ftpusers file. Users who have been denied the use of FTP should be listed here. Note: This file is not created upon system installation and the system administrator needs to actively create it. Review the directory access permission bites of the directories used for FTP and anonymous FTP users to receive and transfer files.    Review and comment on the procedures governing the transfer of files received by way of FTP to the production system. Review any documentary evidence of such procedures. Control Concern UUCP may be setup incorrectly allowing inappropriate access to the system. Risk Poor/inadequate/inappropriate unauthorized access to files. Overview Questions 1. 2. 3. 4. 5. 6. 7. 8. 9. Is UUCP installed and used on the system? Which systems/sites are connected with UUCP? What is UUCP used for? Which commands/programs are executed with UUCP? What security features have been set to restrict the unauthorized use of UUCP? Do the security measures used in UUCP differ between connected systems? Is the dial back security feature used, and if so with whom? Does each UUCP connected system have its own unique login name? Are sequence checks performed before each connection is made? Is UUCP logging enabled? If so what activities are logged, and who reviews the log? UUCP settings may result in    Audit Procedures Review the contents of the /usr/lib/uucp/Systems file and agree the listed names with the authorized list of UUCP system links and their telephone numbers. Each system must have a login ID and a password. (These are contained in the login script - the section after the phone number.) Review the permissions file (/user/lib/uucp/permissions) for any inappropriately set permissions. This also can be done by running the program /user/lib/uucp/uucheck with the -v flag. This program will read the permissions file and display its contents. Review the shell script /user/lib/remote.unknown and establish what action is taken with unknown systems that have attempted to connect to the local system. Determine what procedures exist to review the UUCP log. Control Concern NFS services in the NFS configuration files have not been set correctly, thereby allowing unauthorized access to files and directories. Risk Incorrect setting of the NFS services may result in granting access to unauthorized users. When the system software was installed, the NFS security settings were not set, resulting in virtually no NFS security. Overview Questions 1. 2. 3. Is a NFS service provided on the system? In what circumstances are NFS volumes used? Which of the following options are used in the specification on NFS    access? access lists ro and rw restrictions root annon secure NFS What guidelines have been established to govern the use of these options? Have the guidelines been followed? 4. 5. Who edits the /etc/exports file? Is NFS activity monitored? If so, what method is used? Audit Procedures Review the /etc/exports file. Identify which volumes do not have access lists associated with them. These volumes (without access control list definitions) are mountable by all hosts and thus should only be for public use. Review authorization for mounting specific directories/volumes by specified hosts. Compare this authorization to the contents of the /etc/exports file. Review the appropriate use of the ro and rw restrictions. Where the annon option is used, review the restrictions placed on the UID identifier. This UID should have very restricted capabilities on the system. (Review the /etc/security/user, .profile and /etc/group files to establish the restrictions on the user.) Review the /etc/exports file for the granting of root access. If root access is permitted, establish the reasons therefore. Determine controls to detect/monitor the activities of a root user on the NFS volume(s). Run the shownmount command with the -a option to list all the currently active mounted NFS volumes. If a host has mounted an unusual directory or a system directory, discuss with the system administrator. (Note: None of the    file system should be exported as root). Control Concern The inetd program may be activating services or daemons that are not required. Risk System daemons are providing non-required or unauthorized services that are not in compliance with security policy or that may weaken security. Overview Questions 1. 2. 3. What service daemons are authorized to be loaded on the server? Has the /etc/inetd.conf file been altered to disable any daemons since system installation? Is the /etc/inetd.conf file defined to the TCB? Audit Procedures Review the contents of the /etc/inetd.conf file with the system administrator. Discuss the possibility of removing daemons that are not necessary or that provide information about the network that may be used inappropriately. Review the ACL of the file (Default is: -rw-r--r--- owner is root and group is system) Control Concern Modems and their control strings may be incorrectly set resulting in inappropriate access to the system. Risk    Incorrectly set modem control strings may result in disconnected user sessions remaining open. A third party could dial in and receive the active session thereby gaining control of system resources, with the access rights of the disconnected user. Modem control strings with inappropriate ACL settings could be altered by users resulting in incorrect modem control. Overview Questions 1. 2. 3. 4. 5. 6. Are modems used? circumstances? If so, for what purpose and under what Are dial back modems used, and with whom are they used? Are modems and their telephone lines physically secured? Are modems ports deactivated after normal business hours? Are modem disconnected when not in use for long periods? Is modem activity monitored and if so how? Audit Procedures With the assistance and permission of the system administrator, dial in and log onto the system. Force a line/modem failure (e.g., by removing the telephone connection or switching off the modem) during the session. Reconnect the modem and check that the session has terminated. Review the file permissions of the modem configuration/control files, to determine who owns the files and who can make changes to the files. Inquire if these configuration files are periodically reviewed/defined to the TCB. Review the physical security controls over the modems and their telephone lines. The telephone lines should be separate from the client’s telephone system to minimize the risk of tampering.    If dial back modems are used, consider verifying the telephone numbers used. Review modem monitoring activities and evidence of review procedures. Control Concern Errors may reside in the system software. Risk Hackers and other unauthorized users may gain unauthorized access to the operating system using known bugs. Overview Questions 1. 2. 3. What version of the operating system is used? What is the latest version available? Is there a procedure to obtain information about known errors? If so what is it? What is the procedure followed to implement software updates? Are error corrections implemented on a timely basis? Audit Procedures Identify the version of operating system currently used (use the command oslevel). Inquire as to the sources of information used to identify relevant error/fix information. (e.g., IBM publications, CERT advisories, etc.) Very that bug/fixes and new versions of the operating system are implemented on a timely basis. OTHER SECURITY ISSUES Control Concern    Poor physical security and maintenance can result in a denial of system service due to equipment failure or sabotage. Risk Loss of computer services will adversely impact the organization. Overview Questions 1. 2. What physical security measures have been taken to limit and monitor access to the server, the console, and the communication equipment? Is an uninterruptable power supply (UPS) installed to provide sufficient power for a reasonable period of time to allow for a controlled shutdown of the server? When the UPS last serviced and tested? What physical security measures have been taken to limit the damage that could be inflicted to the system by a natural disaster? Is the temperature in the computer installation kept at an optimal level? Is air conditioning equipment located a safe distance from the server and peripheral equipment, and is it serviced regularly? What fire detection, prevention, and fire fighting equipment has been installed? 3. 4. 5. 6. 7. What anti-static equipment has been installed? Audit Procedures Review the physical security over the computer installation and/or the server and discuss perceived weaknesses with management. Control Concern The system key switch is set in an inappropriate manner and/or the key is not kept in a secure location.    Risk Loss of the system keys could result in the system remaining in an inappropriate mode preventing the loading of system maintenance software. With access to the server and the keys, a person could set the server to maintenance mode and bypass security controls and/or load unauthorized software on the system. Overview Questions 1. 2. 3. 4. Where are the system keys located? Who has access to the system keys? (During normal operation and in emergency situations) What position is the system key lock on the server set to? Is there a record of the system key numbers? Audit Procedures Review and evaluate the procedures governing the control of the system keys. Inspect the server and establish that the key switch is set in the “secure” mode. If it is set in any other mode, establish the reasons therefor.    Control Concern Proper backups of the systems directories may not be correctly taken resulting in loss of software or data. Risk Loss of software or data can result in loss of service or incorrect decisions made, due to incorrect or incomplete data. Overview Questions 1. 2. 3. 4. Describe the backup methodology. (What is backed up? How often are backups made? What type of backups? Where are they stored, etc?) Is off site storage used? If so, is there 24-hour access? Is it secure? Which backup versions are stored there? When was the last time a restore procedure was tested? Was the restore successful? Is a specialized backup program used? If so: Has a copy of the backup program been stored off-site? What information has been backed up with this software? Has the backup and restore been tested? 5. Is specialized or generic backup media used? Audit Procedures Evaluate the backup procedures and discuss any perceived problems with management. Inspect the backup log to ensure it is properly maintained. Inspect the backup media to ensure they are clearly labeled.    Inspect the storage location of the backup media for physical safety and security. System Auditing Control Concern Inappropriate user activity is not recorded, investigated, or monitored. Risk Inappropriate user activities are not identified and security loopholes are not discovered and/or investigated. Overview Questions 1. 2. 3. 4. What type of logs are active on the system? How often are they reviewed? Who reviews them? What action is taken if a security breach is noted? Audit Procedures Obtain a copy of the logs and review the logs with the security officer for signs of inappropriate activities. Determine that logs have been reviewed throughout the year and that followup action has been taken. Review the logs for users who have not logged on the system for a lengthy period of time. Ask is these users are still employed. Determine whether the security officer investigates unusual login times (e.g.,    late at night or on weekends).