If you’re a System Administrator who is also tasked with providing audit data for security compliance, you have an interesting challenge. Server, application, database, Web, and file activity logs are a few examples of what you need to collect if required by the regulatory body. Here are some best practices that should help you ALWAYS be prepared for future audits.
DOCUMENT, DOCUMENT, DOCUMENT!!! Documentation is hands down the most tedious part of preparing for an audit. However, if you are diligent in documenting everything, you will reap rewards well beyond passing an audit. If you have been tasked with preparing for audits, organizing your policies and procedures and thoroughly documenting EVERYTHING is critical. Creating a system map can help you organize specific reports for the specific requirements. Always approach documentation with a mindset of “If I am not here, can anyone follow these procedures?" Finally, always remember that audits are on-going processes. It’s best to schedule review sessions and regularly revise your documentation throughout the year. Typically, I recommend reviewing at least once a quarter.
Clearly understand your compliance requirements and DON'T SKIP ANYTHING. Every regulated industry is different. Understanding what is required for your specific industry can be a challenge. Some compliance requirements are clearly defined while others provide only vague details. Also, it is your responsibility to understand new compliance requirements. If at all possible, either talk to a QSA (Qualified Security Assessor) or review online guidance from a QSA. They are trained in the compliance requirements for specific industries. For example, here is a simplified checklist for PCI posted by QSA, Charles Denyer http://www.pciassessment.org/pci-dss-framework/pci-compliance-audit-requirements-and-checklist-part-i. Also, here is a simplified template for HIPAA that does a great job of breaking down each requirement https://www.aace.com/files/aaceversionhipaamanual-second_edition.pdf.
Identify devices, systems, and applications. Now that you have documented everything and have a clear understanding of your requirements, identify which of your devices, systems, and applications must be monitored for compliance. If you are a one-man security, networking, helpdesk, and system admin shop, your job is a bit easier as you control everything. Life gets a little more difficult when you have to meet with every IT department and explain why you have to start collecting logs from their systems. Either way, it’s best to complete this task as soon as possible, especially if you are deploying a SIEM or Log Management solution. They may require additional applications to collect logs.
Configure the proper audit policies on servers and applications. Getting an in-depth understanding of any regulation requires that you collect the right information from the right devices. For example, PCI provides some detail on what should be collected from your audit logs. See page 56 of this document for a complete list of details: https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf
- User identification
- Type of event
- Date and time
- Success or failure indication
- Origination of event
- Identity or name of affected data, system component, or resource.
HIPAA is a bit more general:
- Section 164.308(a)(1)(ii)(c), Information system activity review (required), which states organizations must "implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports." Reference: http://www.gpo.gov/fdsys/pkg/CFR-2007-title45-vol1/content-detail.html
- Section 164.312(1)(b), Audit controls (required), which states organizations must "implement hardware, software, and procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information." Reference: http://www.gpo.gov/fdsys/pkg/CFR-2007-title45-vol1/content-detail.html
- Record actions. Record actions related to electronic health information in accordance with the standard specified in §170.210(b). Reference: http://www.gpo.gov/fdsys/pkg/CFR-2013-title45-vol1/pdf/CFR-2013-title45-vol1-sec170-210.pdf
- Generate audit log. Enable a user to generate an audit log for a specific time period and to sort entries in the audit log according to any of the elements specified in the standard at §170.210(b). [TM4] http://www.gpo.gov/fdsys/pkg/CFR-2013-title45-vol1/pdf/CFR-2013-title45-vol1-sec170-210.pdf
Automate reporting wherever possible. When collecting audit trails, you will quickly see that the data volume is immense and it will seem impossible to review it all.
a. Develop or configure automated reporting and schedule reports specific to your compliance requirements. It's always beneficial to create or schedule a good mix of both summary and detailed reports based on what information you need to provide. Remember to date/time stamp each report and keep a detailed record of the date, time, and person that reviews these reports. Many technologies provide this information automatically. Just know that this is critical information that a compliance auditor will require.
b. Leverage any real-time/near real-time alerting and notification. Most of today's Log Management solutions provide some form of alerts or notifications, which is a good practice in general and provides proof that you are actively reviewing your logs.
Meeting compliance regulations can be challenging when it comes to collecting the necessary audit trails. Hopefully, these suggestions give you some ideas or jog your memory and motivate you to start that compliance review!
This post is part of our Best Practices for Compliance Series. For more best practices, check out the index post here: Best Practices for Compliance