Step one is identifying and understanding the visibility requirements of your SOC and categorizing these requirements into Must haves and Nice to haves. This will guide you in identifying the necessary detection rules and the corresponding data sources and influencers. But how do you pinpoint those requirements?
A common way to start is identifying your current data sources and how they can be ingested. This could be achieved by going through each category of data source in order, identifying which integrations are available for each, and mapping them to different use cases to see which ones are most applicable to your environment.
An even better, more structured approach is identifying your current data sources and prioritizing them based on their importance to your organization. Ask yourself what data and assets have the highest value — these should have the highest visibility and protection. This usually involves some type of threat profiling: the process to identify and categorize potential threats to an organization’s information systems. The main goals are to understand who might attack you, why they might do it, and how they are likely to proceed, given your information systems.
A good way to start your profiling journey is by answering questions, such as:
-
What type of organization are we?
-
Who could be interested in attacking us?
-
What assets would attackers be interested in?
-
How can they attack these assets?
Once these questions have been answered, you can turn your attention to new ones like, “What tools/assets have interesting logs/data?” and “What assets have critical IP (Intellectual Property)?” all with the goal of identifying relevant threat use cases. After that, you can finally find a way to map this to integrations that are available OOTB and identify which data sources would require custom integrations.
When working on the “valuable assets/data” question, it’s a good idea to document the result. Below is an example on how to map types of data to what’s important to an organization. If operational data is the highest priority — which it probably is — start identifying categories of data related to operations and then the individual logs.
Here your Must haves and Nice to haves begin to emerge. What are your top five data sources linked to your most valuable assets (i.e., operational data)? Are you able to identify which data sources need additional information or enrichments? At the same time, it’s a good idea to start thinking about how you would prefer to be notified about issues for each of these and how severe a temporary loss of this data would be.
Here is an example of a starting point for priority mapping an organization:
| Priority | Data source type | Log | Assets to protect |
| Priority 0: Operational data | Endpoint, Network, Cloud, Security tools | Firewall Syslog, Windows endpoint system logs, Anomaly/(threat intel) | IP assets, Business critical applications, Customer data, Financial transactions |
| Priority 1: Management tools | Auth management, Tool management | AWS CloudTrail, Azure AD logs | Internal company assets, User accounts, API keys, Administrative access, Configuration files |
| Priority 2: Infrastructure tools | Applications, Databases, IT tools | Database logs, syslog | Servers, Databases, Network devices, Development environments |
| Priority 3: Other tools | Monitoring tools, Visualization tools |
This also provides you with an excellent start for documenting your visibility, to be more informed when reviewing it, as well as a building block for when you want to onboard new data sources in a structured way. This way you will know why you are onboarding a new data source as well as the value it brings, and you’ll have a proactive way of working instead of reactive.
Leave a Reply