The Future of Security Ops: Embracing the Machines>
Security Boulevard – Mike Rothman
Some security practitioners remain resistant to the idea of automation, mostly because if done incorrectly the ramifications are severe, and likely career limiting. So weâve advocated a slow and measured approach, starting with use cases that wonât crater the infrastructure if something goes awry. We discussed two of those in depth, enriching alerts and accelerating incident response in the Regaining Balance post. The attraction of improving the number and effectiveness of your response to the avalanche of alerts received daily is obvious, and as such we believe technologies focused on this (small) aspect of security operations will become pervasive over the next 2-3 years. our focus on Trustable Automation, which means you tread carefully, building trust in both the automated process and the underlying decisions that trigger the process. Basically you iterate your way to broader uses of automation with a simple phased approach. 1 Human Approval: Automation with Significant Logging Automation with Guardrails We mentioned guardrails as one of the phases of implementing automation into your operational processes. Letâs dig a little deeper into some examples of how guardrails work within a security context. There are many other examples of putting guardrails around operations, network, and storage processes as well. But weâre security folks, so letâs look at security guardrails. Unauthorized privilege escalation: The trigger would be a log event of the escalation, and that would result in rolling back the change and firing off a high priority alert to the SOC. Rogue devices: itâs not in your CMDB (and it would be if it went through the enterprise provisioning process), nor is it a type of device that would be implemented by the enterprise networking team, itâs safer to just take the device off the network until you can figure out why itâs there and if itâs legit. Deploy new IPS rules: Finally, similar to the example used above (egress IP blacklist), IPS rules are automatically updated based on a trusted threat intel feed. But what happens if traffic from your biggest customer is blocked because the application traffic looks like recon? Another popular process for automation is handling phishing messages. It turns out phishing happens a lot and itâs pretty resource intensive to manually deal with every inbound message (shocking, right?). This is a perfect scenario for automation, which would look like this: Receive phishing message Block egress Investigate endpoint Pay it forward Exfiltration Response Since we just talked about an inbound use case (phishing), letâs flip our perspective and dig into an exfiltration use case. DLP alert fires Classify the issue Kick off an educational process 1 customer data. They can complete the training and be on their way, without requiring any human intervention. 2 Capture Endpoint Data Quarantine Device 1 urgent alert indicating an incident that needs to be investigated. 2 Determine Proliferation You can design the automated processes in the way that will work for your organization. As we mentioned above, you can get to full automation at the pace that works for you. No faster and no slower. Finally, letâs see how this type of approach would work if you need to integrate with services that donât run on-prem. Many organizations have embraced SaaS-based secure web services, yet some want more granular control over which sites and networks their users can access. Thus, you decide to supplement the built-in IP blacklist in the service with multiple other threat intel services to make sure you donât miss anything. Aggregate threat inte Block validated bad sites Monitor potentially bad sites
Link: https://securityboulevard.com/2018/01/the-future-of-security-ops-embracing-the-machines/