Log Management and Compliance

This section is under development

Objective

To discuss log management and compliance in relation to industry-specific compliance regulations. Regulations discussed will be PCI, SOX, HIPAA, etc.

Process

Below are general guidelines for getting the logs necessary to meet your compliance needs. These are just guidelines and may need to be modified based on your business needs.

 1. Identify what logs are needed based on compliance regulations.

 2. Configure devices with the necessary information to send logs to a SIEM or other logging mechanism.

 3. Verify logs are being received by the SIEM or log management server.

 4. Use business cases to generate alerts when necessary.

 5. Review the logs after network maintenance and upgrades.

There are many tools both paid and open source that can be used to collect and store the logs necessary to meet compliance needs. Here we will focus on the open source tools and be as vendor neutral as possible.

 Elastic Stack(ELK Stack): This is a group of tools that can be used to store, search and visualize the logs and data that you are collecting

 OSSIM: The open source version of Alienvault. This tool can collect and normalize the logs you are sending to it. This can also be configured to do Intrusion Detection(IDS) and integrates with the Open Threat Exchange(OTX) which 
        is community-based threat feeds.

 Security Onion: This is a security distribution that is based on Ubuntu. This has many tools that can be configured to store, log, alert and visualize the data being sent to it.

 OSSEC: This is an agent-based service that can collect windows event logs and Linux event logs.

This is not an exhaustive list by any means there are always new tools coming out, and being used. Keep in mind that one tool may not meet all of your requirements. In many environments, more than one of these tools will be required to meet your specific needs.

Ticketing

Tickets or documentation of incidents is required by all regulations. There are even some specific reporting requirements that we will get to in another section. Ticketing is mainly used by a SOC or internal security person to track their investigations and keep all documentation in a central location. As to keep with the open source theme we will steer clear of paid products.

 TheHive: This is the most SOC or security specific platform. This open source incident response system allows teams to collaborate on tickets and track actions taken during an investigation. This system allows the analyst to 
          integrate with MISP (Malware Information Sharing Platform). This tool has other pieces that can be integrated to enrich the information available. More specific information about this tool can be found on their site. 
          https://thehive-project.org/

There are many more ticketing systems that can be used to track incidents and investigations. A quick google search will turn up quite a few. This as with other open source tools with need to fit what you are looking to do and achieve based on your business goals and requirements.

Reporting

Reporting can mean a couple of different things in security. It can mean reporting of an incident or it can mean reporting for an auditor. The requirements for both may differ based on the regulations that affect your organization.

Common Report types:

 Access Report - This is a report that can track the access to systems. i.e Successful or failed Windows logons, or SSH authentications. 
 
 Account Lockouts - This report will show all accounts that were locked out in a specified time frame. 

 Asset Reports - These reports will be specific to the regulation and may only require a subset of assets.

 Password Changes - A report that tracks when users passwords are changed. 
  
 Firewall Changes - Tracks changes that have been made in the firewall.

 Malware Events - A report to track malware detections by Anti-Virus, or Anti-Malware systems.

 Active Directory Changes - Tracks all users added removed along with group changes in the environment.

 Vulnerability reports - A report that tracks vulnerability in the environment.

This again is not an exhaustive list but something that you can build upon and baseline based on your business requirements.

Budgeting

Budgeting for log management and compliance is going to be based on the storage and processing power necessary to meet the requirements your organization faces. The more storage and processing power that you need, the higher your budget. For example, if you need to store 90 days of active logs in a database for quick searching, that is going to increase the amount of processing power needed to support the database and the amount of storage needed to keep those logs as compared to only needing to keep 30 days. Some regulations require that you keep 1 year or more of raw logs in the event you need to go back to investigate an incident the longer you need to keep them the more expensive it is going to get. You will also want to take into consideration the need to back these logs up in the case of a disaster.

Communications

Communication from a SOC is going to depend on who the target audience is.

SOC -> C-Level: In this case, the main things the C-Level is concerned about is what happened, what did you do about it, and how can we stop it from happening again. You will want to try to do this in about a page, anything more and you will start to lose them.

Analyst -> Analyst(inter SOC communication): Here you will want to be technical, explain what you have seen, done and what you did to get where you are. Explain what tools you have used and what conclusions you have come to. Be as detailed as you possibly can even include screenshots of the commands and searches you ran. This will help the next analyst pick up where you left off in the investigation. This is the same if you are escalating to a Sr. Analyst.

As with most sections, there may be another form not listed here. That could be included based on your business case.