When
Ideally daily, but at least weekly, depending on requirements.
Your audit policy should be based on amount of system activity, number of users, exposure to users outside the LAN, the sensitivity of the data, etc.
What
The definition of auditing for our purposes is the review and analysis of management, operational and technical controls, and the process an operating system uses to detect and record security-related events. The records of such events are stored in a security log and are available only to those with the proper permissions. A computer system may have several audit trails, each devoted to a particular type of activity. The audit trail should allow the audit reviewers to reconstruct a complete sequence of security-related events.
Why
Audit logs provide an independent review and examination of records and activities to assess the adequacy of system controls, ensure compliance with established policies and operational procedures, and recommend necessary changes in controls, policies or procedures. Audit logs also provide a good way to determine if and how attacks take place and act as a key security and system administration tool for performance, which affects the "availability of service" security tenet. However, audit logs don't perform real-time intrusion detection and notification.
Strategy
Generally, you can audit logon events, object access, policy change, privilege use, process tracking, system events, system startup and shutdown and audit account management.
No matter what events you audit, the record should at least contain:
records of each action, together with trace or identification parameters; connection start and end times; and association of network activities with corresponding user audit trails. The audit trail should be backed up daily and stored separately. It's helpful to retain an online audit trail for at least 24 hours, and it's a good practice to keep all offline
To continue reading for free, register below or login
To read more you must become a member of SearchSecurity.com
audit trail data on magnetic media for at least one year (or longer as specified by your policy).
Keeping audit data for a specified period of time ensures that any events discovered during one time period can be traced to their origins in another time period, and investigations into security incidents can provide the best information possible to reconstruct the entire series of events.
Warning signs that indicate you need to review your audit trails are:
multiple unsuccessful login or file access attempts; concurrent user connections; out-of-the-ordinary changes in system or user activity; unexplained changes in system load; signs of a physical security breach; unexplained software in the system library; odd reports from users; and unexplained batch jobs or queues.
Develop and implement your audit policy and procedures in accordance with regulations applicable to your organization, or industry best practices. In your policy you'll need to determine what events will be audited, and at what level, how often to review the audit trail, and how to maintain, retain and safeguard audit trail data. These procedures should be reviewed at least annually or updated as needed to reflect new requirements.
Other points to remember:
--Targeted auditing: There could be legal issues associated with taking a closer look at an individual's activity, check with your legal counsel.
--Audit your firewalls, routers, database applications, and any other equipment and applications that record activity.
--Protect your audit trails.
--Use audit reduction tools to reduce the volume of records you have to look at.
More information
"A Guide to Understanding Audit in Trusted Systems" (June 1988) still has some good guidelines: http://www.radium.ncsc.mil/tpep/library/rainbow/ncsc-tg-001-2.html. Also, The NIST Handbook, Chapter 18 has information about auditing:
http://csrc.nist.gov/publications/nistpubs/800-12/handbook.pdf. If you have outsourced temporary and/or external auditing, see:
http://www.sans.org/resources/policies/Audit_Policy.pdf for a helpful agreement template.
About the author
Shelley Bard, CISSP, CISM, is a senior security network engineer with Verizon Federal Network Systems (FNS). An information security professional for 17 years, Bard has briefed and written infosecurity assessments and technical reports for the White House and Department of Defense, special interest groups, industry and academia. Please e-mail any comments to mailto:securityplanner@infosecuritymag.com
Opinions expressed in this column are those of Shelley Bard and don't necessarily reflect those of Verizon FNS.
Last week: Ports -- Don't have an 'open house' sign out
Next week: Who's afraid of auditing? Part 2 -- Understanding Unix auditing
