Using lessons learned from incidents to harden your SOC processes
Adversaries are constantly on the lookout for vulnerable systems, and the SOC must stay vigilant for any changes on the network. Managing and maintaining an efficient SOC involves streamlining processes and procedures. Using playbooks or adaptive response actions, an analyst can automate many of these processes. However, sometimes we find flaws within the environments we are monitoring. Patching vulnerabilities in systems is straightforward, but what if the process is the problem? This article discusses finding and addressing problems that arise from your processes, and how analysts can use Splunk Enterprise Security to save valuable time.
Considering the risks
After a problem has been acknowledged, organizations usually follow runbooks or other operational procedures to fix it. But having the right procedures is only part of the equation. Management teams usually approve changes in any current processes that get documented into runbooks, but maintaining and updating processes in those runbooks is a different matter.
Cybersecurity strategies (such as developing a risk management framework or investing in incident response planning) might not be updated as often as operational tactics, such as patch management or continuous logging. This can open you up to unnecessary risk.
Knowing the risks that exist in your environment helps with your organization's situational awareness. For example, an internal development server or other resource might host outdated code that is vulnerable to attack. The server team's patch management system might not have a profile for this resource, which could become a problem if there's security vulnerabilities bad actors can exploit. Another risk involves the use of a developer's corporate login credentials for access, potentially creating opportunities for exploitation if an account is compromised. Best practice is to use a jump server that requires separate login information to access the development server.
Consider researching shared Indicators of Compromise (IOC) intelligence for your industry vertical. Peers might have specialized knowledge based on their particular experience with a product or technology. These IOCs can be accessed through Splunk Threat Intelligence Management or access to ISAC/ISAO sharing.
Thinking outside the checkbox
A goal of many organizations is to pass audit or compliance checks. The conditions for passing an audit might be satisfied, however, there might be other blind spots. For example, a system might be required to have a software firewall, but other items or conditions might exist that make the system vulnerable, such as having local admin permission for local users.
Splunk Security Essentials and Splunk Enterprise Security contain out-of-the-box use cases to check for these potential insecure conditions. For example, to view privileged accounts in Splunk Enterprise Security, you can run the following SPL in your environment:
| datamodel "Identity_Management" High_Critical_Identities search
| search "All_Identities.category"=privileged
Using these out-of-the-box features helps you to address these vulnerabilities that might otherwise stay as blind spots.
Next steps
These resources might help you understand and implement this guidance: