How Audit Logs Help Confirm and Correct Security Policy
Learn the important elements of security policy, which include laying out your assets and explaining what it means to be secure.
Join the DZone community and get the full member experience.Join For Free
There are many possible definitions for the term “security policy,” but all of them share certain elements in common. A security policy should lay out what assets, both physical and digital, an organization wishes to protect. It should explain what it means to be secure and to behave securely. In short, a security policy identifies what assets are to be protected, what kinds of risks such protection is meant to defeat or mitigate, and how security can be established, measured, and monitored. And nothing works better for the measurement and monitoring part than regular examination and automated alerting from security audit logs.
Walking Down the Audit Trail
An audit trail is a log file that contains chronological information about accesses made, changes applied, and activities undertaken, with a special emphasis on security. An audit log provides a kind of journal of all the activities that affect specific operations, procedures, or events that occur. Audit records are generated when things like this happen and provide documentary evidence of a sequence of actions and events, while identifying the actors involved as much as available data will permit.
Auditing involves collecting and managing large amounts of data, so not everything gets audited as systems run. Audit records typically result from activities that involve money (financial transactions), sensitive or proprietary data (intellectual property, confidential or classified information, and so forth), health care information (patient and other medical records), and security information of all kinds.
Auditing security is, in fact, a cornerstone for making sure that security policy is correctly implemented, enacted, and applied. That’s why processes and data associated with audit trails run in privileged mode. This permits the audit facility to access and supervise all actions from all users. Only those with the highest levels of permission are permitted to access security audit information because it documents all information assets, all access controls, authentication methods and credentials, and much, much more.
In many environments, no single user even at the highest levels of privilege can stop or alter auditing, nor change an audit log. Keeping the audit log pristine and unchanged is the only guarantee that security actions can be tracked, responsible parties identified, and changes to access controls and sensitive, proprietary, or classified information tracked and made transparent to those with a need to know about such things.
Principles of Information Audit
At the highest level of detail, information audit involves the view of a chronological series of system activities as they occur. Careful examination of the records that compose an audit trail enable the reconstruction of events and activities. They also document the changes that are made when security configuration data is created, modified, or deleted. Certain aspects of security data will be closely tracked and perhaps even generate alerts when specific events occur. These could include creation, modification, or deletion of security principal records (account information and credentials for individuals or groups granted the highest level of privilege in defining and assigning access rights, or identifying and classifying information assets). They will also typically include accesses made to high-value intellectual property, financial and personnel records, sensitive, proprietary or classified information, and so forth.
Authorized security principals are aware that everything they do that is related to security will be logged and is subject to subsequent review and analysis. Sometimes, such analysis may even be delegated to third parties (perhaps in the context of legal discovery, law enforcement investigation, or compliance auditors). Responsible parties wishing to maintain and enforce secure information policy and practices want their actions to be an open book. Auditing and alerting on high-impact security changes can also provide important flags when bad actors obtain unauthorized access, whether on the part of insiders or because of external penetration and system compromise.
What Security Audits Can Reveal
Ideally, digging into a security audit trail should confirm that things are configured and working as they should be, with nothing untoward going on. In such idyllic circumstances, that trail will confirm that security policy has been correctly implemented and is being enforced as such.
Other benefits from extracting data from audit logs might include evidence that users have obtained permissions and credentials to which they’re not entitled. Beyond providing the impetus to adjust those things accordingly, this might also spur further review of audit trails to see if those over-extended permissions have been misused or abused. By filtering on the identities involved, it is relatively easy to see if anything unauthorized or unwanted might have occurred. If so, damage assessment and remediation must become the next task to complete and undo or mitigate those results.
In general, a review of your security audit trail(s) should illuminate how your security infrastructure is working. It should also help you adjust your security configurations to keep them current, and to stay in sync with security policy. Make this kind of a review part of your regular security routine, and you’ll be much less likely to be surprised later on by unexpected compromise or unauthorized access to your information assets.
Ed Tittel is a long-time technology writer, researcher and consultant. The author of numerous books and courses on information security (including certification-oriented and end-user topics), Ed can be contacted through his website at www.edtittel.com.
Published at DZone with permission of Ed Tittel. See the original article here.
Opinions expressed by DZone contributors are their own.