Not all logs are created equal. The key is to get the most value for your dollar and avoid alert fatigue. This piece explains the basics of setting up logging and monitoring for a typical security operations center (SOC), including the importance of determining
your mission, using the right controls, choosing the right data log sources and deploying the best SIEM for the job.
Define the Purpose of Your SOC
We recommend either the CISO or SOC manager begin defining the purpose of the SOC. Usually, the mission typically involves protecting the crown jewels of the organization. This aligns the SOC with the business and helps map what touches and/or could potentially access these
items. This includes machines, employees, contractors – anything that could be a threat to what you identify as the crown jewels.
For example, a SOC manager might identify (and receive agreement from the rest of staff and the board) on the following as primary crown jewels:
- Customer/client data
- Employee personally identifiable information (PII)
- Our company intellectual property (IP) and financial data
What Your SOC Needs
Following that exercise, think about what the SOC needs to protect those crown jewels. The following are examples of what to monitor in real time to help ensure the detection of potential threats and vulnerabilities:
- Password changes
- Unauthorized logins
- Login failures
- New login events
- Malware detection
- Malware attacks seen by the intrusion detection system (IDS)
- Scans on open and closed ports
- Denial-of-service (DoS) attacks
- Errors on network devices
- File name changes
- File integrity changes
- Data exports
- New processes started or running processes stopped
- Shared access events
- Disconnected events
- New service installation
- File auditing
- New user accounts
Increasing Workload Activity
Before you can determine how to increase visibility, you need to first understand where that visibility needs to be improved. Most likely, it is around the crown jewels, but it could also be for cloud workloads. If cloud workload visibility needs to be
improved, consider starting with what the major cloud service providers (CSPs) provide in terms of value, including:
- Cloud audits logs. This service enables governance, compliance, operational auditing and risk auditing of your AWS account.
- Cloud flow logs. This lets you capture and log data about network traffic in your virtual private cloud (VPC). VPC flow logging records information about the IP data going to and from designated network interfaces.
- If you are starting from scratch, consider writing out some use cases and possibly start with something crucial like incident response. For more information, see this NIST guide to log management.
Determine the Best Log Data Sources
Figure 1 lists some common data sources in a suggested order of priority, starting with identity and access management (IAM) logs and primary security controls, and then the other categories as your program matures.
READ: Best Practices for MacOS Logging & Monitoring
Logs to Avoid
There are also categories of data you should not consider logging, such as:
- Data from test environments that are not an essential part of your software delivery pipeline.
- Data that could adversely impact compliance. For example, data associated with users who enable do-not-track settings should not be logged. Similarly, try to avoid logging highly sensitive data, such as credit card numbers, unless you are certain
your logging and storage processes meet the security requirements for that data.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in connection with such information, opinions, or advice.