Publication 1075, Tax Information Security Guidelines for Federal, State and Local Agencies and Entities, provides very detailed audit requirements, but how these requirements cut across various IT layers e.g., Operating System, Database, and Application to provide end-to-end auditing might not be as apparent and straight forward. Therefore, by providing a scenario based technical assistance memo, the IRS Office of Safeguards hopes to assist agencies in better understanding and implementing audit based requirements for Safeguards. Response IRS Publication 1075 outlines the requirements and guidelines to ensure that FTI is properly audited. Specifically section 5.6.2 and exhibit 9. An audit trail or audit log is a chronological sequence of audit records (otherwise known as audit events), each of which contains evidence directly pertaining to and resulting from the execution of a business process or system function. Audit records should be generated when subjects (e.g., system users or automated processes) perform business related activities with system resources (e.g., files, database objects). Audit records should also be produced when adversaries try to perform unauthorized activities on the system resources. Each audit record captures the details related to the underlying event e.g.,: Date and time of the event; Unique ID of the user; Type of event; Success or failure of event; Origin of the request; Name of the object introduced/deleted; and Description of modification to security databases. Ultimately, for the purposes of Safeguards, the audit trail (captured at various layers) should be comprehensive enough to historically recreate the sequence of events leading to successful and unsuccessful access attempts to FTI. Only when armed with this evidence can an agency begin to correlate a sequence of events that answer questions such as: Has an unauthorized access to FTI occurred? Was that particular user authorized to have access to FTI? Did they have a need-to-know at the time to gain access to FTI? Was the FTI altered in any way? Did the FTI leave the system? Was FTI disclosed? Exhibit 9 in Publication 1075 identifies the system audit management guidelines which identifies specifically the types of events, transactions and details needed to be captured for a complete audit trail. The audit trail shall capture all successful login and logoff attempts. The audit trail shall capture all unsuccessful login and authorization attempts. The audit trail shall capture all identification and authentication attempts. The audit trail shall capture all actions, connections and requests performed byprivileged users (a user who, by virtue of function, and/or seniority, has been allocated powers within the computer system, which are significantly greater than those available to the majority of users. Such persons will include, for example, the system administrator(s) and network administrator(s) who are responsible for keeping the system available and may need powers to create new user profiles as well as add to or amend the powers and access rights of existing users). The audit trail shall capture all actions, connections and requests performed by privileged functions. The audit trail shall capture all changes to logical access control authorities (e.g., rights, permissions). The audit trail shall capture all system changes with the potential to compromise the integrity of audit policy configurations, security policy configurations and audit record generation services. The audit trail shall capture the creation, modification and deletion of objects including files, directories and user accounts. The audit trail shall capture the creation, modification and deletion of user accounts and group accounts. The audit trail shall capture the creation, modification and deletion of user account and group account privileges. The audit trail shall capture: i) the date of the system event; ii) the time of the system event; iii) the type of system event initiated; and iv) the user account, system account, service or process responsible for initiating the system event. The audit trail shall capture system start-up and shutdown functions. The audit trail shall capture modifications to administrator account(s) and administrator group account(s) including: i) escalation of user account privileges commensurate with administrator-equivalent account(s); and ii) adding or deleting users from the administrator group account(s). The audit trail shall capture the enabling or disabling of audit report generation services. The audit trail shall capture command line changes, batch file changes and queries made to the system (e.g., operating system, application, and database). The audit trail shall be protected from unauthorized access, use, deletion or modification. The audit trail shall be restricted to personnel routinely responsible for performing security audit functions. The need and ability to perform auditing has been around for some time. Therefore, virtually all reputable vendors build auditing features into their operating systems, databases, and applications. Unfortunately, many of these features are typically disabled by default because many feel the processing of auditing activities carries with it system performance degradation. If planned and implemented wisely, the performance hit can be minimized by enabling the right auditing at the appropriate layers. Therefore, IRS requires any and all operating systems, databases, and applications that come in contact with FTI to enable their auditing features with respect to the actual FTI data. That is not to say that auditing should be implemented across the board for all layers simultaneously. It is important to selectively choose the most appropriate layer to audit against. For instance, if an application is being used then it makes sense to audit user transactions related to FTI within the application as opposed to at the operating system level because the application is more knowledgeable, given the context of the transaction. Therefore, it is wise to audit at multiple layers so that the burden of auditing is split up among the operating system, database and application. Collectively, the audit trail will achieve the end goal of capturing enough information to be able to see who had access to FTI and under what conditions. Collecting all of this audit data is only half the battle. It doesn’t do any good to collect it if it is never monitored, analyzed, protected and retained. Therefore, it is the combination of having policies and procedures in place along with the collection and correlation of audit logs from all systems that receive, process, store or transmit FTI that completes the auditing picture. To summarize, the agency must address the following areas for auditing: Audit and accountability policy and procedures must be developed, documented, disseminated, and updated Auditable events must be identified and captured Content of audit records should be understood and defined Proper audit storage capacity must be determined and allocated Audit logs must be reviewed periodically as defined by the policy Processes must be in place to handle auditing failures Audit logs must be monitored, analyzed and reporting Time stamps must be enforced to be able to correlate events from multiple sources The audit information is sensitive and must be protected Audit information shall be retained for 6 years. Technology-specific auditing examples Auditing can take place at a various layers of a system depending on the context of how the FTI is being utilized. Auditing capabilities are offered at the operating system, application, and database level to name a few. In most cases, auditing at a single layer will not capture the 17 items offered as guidance by Exhibit 9. It will be the combination of selectively auditing at multiple layers that completes the picture. The agency should try to meet the Exhibit 9 auditing guidance by examining the layer closest to the FTI data. For example, if FTI is stored in a database, then there is less value in auditing all the events at the OS level if the database has the capability to capture information relating to FTI data related transactions. Agencies can simply log system access events e.g., log-in / log-out at the OS level but capture everything at the table and/or record level in the database that contains FTI. Another scenario is when the FTI is stored in flat files. An agency can then look to the application that uses the FTI flat data files. If the application has the ability to audit when a user reads or updated the FTI then that is the appropriate place to perform as much auditing as possible. If an application is not used or does not offer a granular enough level of auditing, then the operating system auditing capabilities should be leveraged. In order to properly configure an operating system, database or application for auditing please refer to both vendor-provided configuration guidance and the IRS Safeguards Computer Security Evaluation Matrix (SCSEM) for a particular technology (available on the IRS website). However, we will enumerate a few common technology scenarios below to highlight the most common auditing problem areas associated with a given technology. One of the most common findings is not having a comprehensive audit policy and associated procedures implemented to ensure the system audits activities, generates audit reports, and archives audit data. The policy should clearly define the “who, what, where, when and why” with respect to audit logs. It should address all the requirements for auditing. However, many policies often describe the “what” is being captured but often neglects the “who” is involved with the logs and the process by which they are being monitored, reviewed, protected and retained. Expected in the policy and procedures would be some kind of schedule for reviewing particular audit logs. Here is an example (we would expect to see a similar process applied to any technology and its associated audit information): Audit Log - Daily Review – RACF System Administrator - The audit logs will be reviewed on a daily basis for the following violations: Data set access violations Resource access violations Program use violations Audit Log - Weekly/Monthly Review - RACF System Administrator & RACF SA Manager - The audit logs will be reviewed on a weekly/monthly basis for the following violations/changes: Failed logon attempts – RACF user violation report Special and operation privileges Audit Log - Quarterly Review - RACF Auditor team – The audit logs are to be reviewed on a quarterly basis for the following changes/accesses: Trusted STC accesses FTP userids/logonids/ACIDs accesses Global Control Options Included in this schedule of reviewing logs would be the process and workflow for dealing with violations and anomalous activities. Additionally, a quick report even in the form of an email to management whenever these activities occur would serve as evidence that auditing is being performed and reviewed. The following are three technologies with audit related findings and their associated remediations. They include scenarios for: Mainframe – RACF, Windows, and Cisco routers. Mainframe - RACF: There are a number of audit relating configuration settings. Below are top common auditing misconfigurations: 1. FINDING: RACF AUDIT operand is not in effect. DISCUSSION: Analysis of the SETROPTS global settings resource classes are not defined to the AUDIT operand. When enabled, the AUDIT operand ensures RACF logs (1) all changes to resource profiles (RACDEF) and (2) all uses of supervisor calls (SVC) and/or System Authorization Facility (SAF) calls requesting access to specified resources (RACROUTE REQUEST). RISK: If the AUDIT operand is not enabled, RACF will not log (1) all changes to resource profiles, and (2) supervisor calls requesting access to resources. Consequently, unauthorized access to the system and FTI could occur without detection. RECOMMENDATION: Enable the SETROPTS AUDIT operand for all active resource classes used to ensure RACF logs: (1) all changes to resource profiles; and (2) all uses of supervisor calls or SAF calls requesting access to specified resources. In effect the active and audit list of classes should be identical. 2. FINDING: STATISTICS processing is not in effect. DISCUSSION: Analysis of the SETROPTS global settings found the STATISTICS parameter set to NONE. STATISTICS processing records access to resources in specific classes that are protected by discrete profiles. The STATISTICS option permits an installation to record statistics on discrete profiles to see how their respective data sets and resources within specific resource classes are being used. Specific resources with unique security concerns, such as those with FTI, should be protected with a discrete profile. STATISTICS processing is used to determine how that resource is being accessed and how many times it is being accessed. RISK: If access to resource profiles are not audited, unauthorized access to the system and FTI could occur without detection. RECOMMENDATION: The agency should enable the SETROPTS STATISTICS parameter for all active RACF resource classes (ACTIVE CLASSES) defined for FTI resources. 3. FINDING: The ATTRIBUTES setting needs improvement. DISCUSSION: Analysis of the SETROPTS global settings found that OPERAUDIT and INITSTATS are not defined to the ATTRIBUTES operand. The system activities of personnel assigned system-level authorities must be audited at all times by activating INITSTATS, SAUDIT, OPERAUDIT, and CMDVIOL. INITSTATS records statistics on all user profiles in the system. RISK: If the ATTRIBUTES operand does not contain INITSTATS, SAUDIT, OPERAUDIT, and CMDVIOL then RACF will not log all the activities of personnel assigned system-level authorities. Consequently, unauthorized access to the system and FTI could occur without detection. RECOMMENDATION: Enable the SETROPTS ATTRIBUTES operand to include INITSTATS, SAUDIT, OPERAUDIT, and CMDVIOL. 4. FINDING: Access controls to SMF audit logs need improvement. DISCUSSION: Analysis of the access control list associated with SYS1.MAN* (denoted by SYS1.* high-level qualifier) identified the following control deficiencies requiring management attention and prompt corrective action: User Group TSXXXXX has ALTER authority to the SMF audit logs. User Group DPXXX has ALTER authority to the SMF audit logs. User ID TSXXXX has UPDATE authority to the SMF audit logs. RISK: Users with the ALTER access authority can create, modify, or delete the SMS audit logs thereby compromising the integrity of the audit trail. Consequently, unauthorized access to the system and FTI could occur without detection. Users with the UPDATE or READ access authority can access the SMF audit logs and potentially copy these files to their own libraries. Consequently, unauthorized access to the system and FTI could occur without detection. RECOMMENDATION: Remove users and user groups identified with ALTER access authority to the SMF audit logs and develop, approve, and implement written procedures for granting, restricting, and terminating emergency access to SMF audit files to resolve technical contingencies as needed. Windows: Auditing with Windows Server 2003 and XP is configured in several different ways, all depending upon what needs to be audited, and where those objects reside. Generally, the first step is to enable the specific type of auditing through the audit policy, which will usually begin the audit process at that point. Auditing is generally turned on through a security policy, which is another part of Group Policy. These security policies are generally accessed through Administrative Tools. The most common issue with Windows auditing is that the agency does not enable auditing for both “success” and “failure” on the following types: Audit Account Logon Events: Tracks user logon and logoff events. Audit Account Management: Reports changes to user accounts. Audit Directory Service Access: Reports access and changes to the directory service. If the system is a member server or XP system, directory service is NTLM-based, and consists of user accounts and group policies. Audit Logon Events: Reports success/failure of any local or remote access-based logon. Audit Object Access: Reports file and folder access. Must be implemented here, and then the individual file/folder must be configured for auditing within its properties in order to fully enable this feature. Audit Policy Change: Reports changes to group policies. Audit Privilege Use: Related to Audit Object Access: reports when permissions are utilized such as read, or full control. Audit System Events: Reports standard system events. Not security related. The second most common issue with Windows auditing is that the agency does not allocate enough storage capacity for these events. The following sizes should be the minimums: The value for “Maximum application log size” MUST BE set to a minimum of “16384 kilobytes." The value for “Maximum security log size” MUST BE set to a minimum of “81920 kilobytes.” The value for “Maximum system log size” MUST BE set to a minimum of “16384 kilobytes." The third most common issue is that the Event Viewer logs are not set to “Do Not Overwrite Events (clear log manually).” This prevents the logs from being overwritten which opens up the possibility of them being deleted prior to a system admin reviewing them or archiving them. In some cases where FTI is actually being stored on a Windows device it becomes necessary to audit the file or folder access where the FTI resides. This is a two part process where the audit policy must be changed, and then the file or folder must be flagged for auditing. From that point, items will appear in the Security log of the Event Viewer. Below are Microsoft’s instructions on how to enable this feature. Auditing User Access of Files, Folders, and Printers: Click Start, click Control Panel, click Performance and Maintenance, and then click Administrative Tools. Double-click Local Security Policy. In the left pane, double-click Local Policies to expand it. In the left pane, click Audit Policy to display the individual policy settings in the right pane. Double-click Audit object access. To audit successful access of specified files, folders and printers, select the Success check box. To audit unsuccessful access to these objects, select the Failure check box. To enable auditing of both, select both check boxes. Click OK. Specifying Files, Folders, and Printers to Audit: After you enable auditing, you can specify the files, folders, and printers that you want audited. To do so: In Windows Explorer, locate the file or folder you want to audit. To audit a printer, locate it by clicking Start, and then clicking Printers and Faxes. Right-click the file, folder, or printer that you want to audit, and then click Properties. Click the Security tab, and then click Advanced. Click the Auditing tab, and then click Add. In the Enter the object name to select box, type the name of the user or group whose access you want to audit. You can browse the computer for names by clicking Advanced, and then clicking Find Now in the Select User or Group dialog box. Click OK. Select the Successful or Failed check boxes for the actions you want to audit, and then click OK. Click OK, and then click OK. Cisco routers There are a number of audit related configuration settings. Below are the top common auditing mis-configurations: 1. FINDING: Sequence numbers are not used for syslog messages. DISCUSSION: Each system status message logged in the system logging process has a sequence reference number applied. The service sequence-numbers command makes that number visible by displaying it with the message. The sequence number is displayed as the first part of the system status message. RISK: Sequence numbering on syslog messages enables an auditing control to indicate if any messages are missing. Without visible sequence numbers some syslog messages may be lost during transmission and would not be accounted for, thus weakening the effectiveness of the system logging. This is turn weakens the integrity of FTI system’s audit trails. RECOMMENDATION: The agency should implement sequence numbering for syslog messages. Recommended commands to configure this are as follows: Router#config terminal Router(config)#service sequence-numbers 2. FINDING: NTP authentication is not used. DISCUSSION: Time synchronization can be authenticated to ensure that the local router obtains its time services only from known sources. By default, network time synchronization is unauthenticated. Uses pre-placed keys to establish a trusted community of NTP servers and peers. Cisco routers support only MD5 authentication for NTP. RISK: With a sophisticated attack, an attacker could use NTP informational queries to discover the timeservers to which a router is synchronized, and then through an attack such as DNS cache poisoning, redirect a router to a system under their control. Manipulating the time on a router this way could make it difficult to identify when incidents truly happened and could also be used to confuse any time-based security measures you have in place. This weakens the integrity of FTI system’s audit trails. RECOMMENDATION: The agency should use NTP authentication between clients, servers, and peers to ensure that time is synchronized to approved servers only. Enable NTP authentication with the ntp authenticate command. Define an NTP authentication key with the ntp authentication-key command. A unique number identifies each NTP key. This number is the first argument to the ntp authentication-key command. Use the ntp trusted-key command to tell the router which keys are valid for authentication. The ntp trusted-key command's only argument is the number of the key defined in the previous step. To enable authentication on the router and define key number 10: Router#config terminal Router(config)#ntp authenticate Router(config)#ntp authentication-key 10 md5 Router(config)#ntp trusted-key 10 If external NTP servers require authentication, you need to configure a router to use authentication when contacting those servers. To do this, perform the same steps listed previously to add an NTP authentication key; then use the ntp server command with the key argument to tell the router what key to use when authenticating with the NTP server. To authenticate NTP peers, configure the same key on both systems and use the ntp peer command with the key argument to configure authentication. 3. FINDING: Dedicated log servers are not used. DISCUSSION: Currently a dedicated log server is not used. A host should be configured for the sole purpose of storing logs from the routers. Log servers should be included as a part of network engineering to house and protect the router log files. Log servers should be sized with respect to the amount of traffic produced by the routers on the network, therefore correlating to the amount of log entries routers would produce. RISK: Without a dedicated, protected log server to house the router’s logs, there is risk of logs being deleted or overwritten from the router’s buffered memory before they are able to be analyzed. Security events indicating possible network attacks would go unnoticed allowing the network to be compromised without any advanced warning. RECOMMENDATION: The agency should assign a host as the dedicated log server. The log server should be connected to a trusted or protected network, or an isolated and dedicated router interface. Harden the log host by removing all unnecessary services and accounts.
