- Creating and using a threat-based model of assets and locations within their business to form SOC and Incident Response activities
- Setting up an intelligence team to aggregate sources of threat and security intelligence from myriad sources
- Reducing the number of skilled analysts “working” security events, and increasing their time to proactively “hunt” for attacks
This week, we look at how an organization who did not have a formal Incident Response and Security Operations team (Stage 1 in our maturity profiles) leapfrogged to Stage 3 and became an early “hunting” organization with the creation of a small team.
The organization is a global consumer business where more than half of their revenue is conducted online. They have a global network with data centers in Asia and Europe, Canada, and on the East and West Coast of the United States. Their security team is small (< 15 dedicated security team members) and part of a highly technical and networked skilled IT team that live and breathe ” Dev Ops.” Keeping services up and running, and customers happy is the business and IT priority.<
The Security team was primarily focused on architecture planning with the online teams; identity, access and fraud management; and infrastructure protection. They outsourced their SOC several years ago. Incident Response was built around a policy and process worked out with Legal and IT, and the major focus was responding to lost devices, IP theft and employee compliance issues.
When the company heard a competitor was hit by a targeted attack that included theft of key IP, an attack that was in the network for months undetected and took several weeks to resolve (with specialist third-party IR teams), they decided to take action.
The Security Architect recruited 2 internal skilled networking analysts with pen testing backgrounds and had them begin to proactively hunt for attacks, or cherry pick high priority alerts sent over from their outsourced SOC to quickly validate and respond. They began to track how long it took to detect threats in their network, baseline and track progress over time. This was the hardest hurdle to leap over; both in terms of finding the right training and starting point for the new team, and then drawing out what was tracked and reporting findings in a methodical matter. Previously, reported metrics focused on what malware was blocked with perimeter protection devices, and how many and how quickly official incidents were resolved.
Limited new budget was required, except for training (where they sent the members to specialist courses).Within 6 months, they had detected and validated over 10 targeted attacks within the network (which had not yet germinated to an exfiltration stage). By 18 months, they were starting to measure and report on dwell time of attacks, with the mean under 60 days. The Security Architect now regularly briefs the management team on the new measures, and is working with the Identity and Fraud security staff to set up an intelligence “virtual” team to inform both groups.
Here, an organization with limited in-house security resource but with an agile culture, and highly skilled, experienced network and security staff, was able to show the dividends of this change quite rapidly. This can be the exception rather than the rule, and changing culture and mindset is one of the most difficult transitions any organization can make. Increasingly, given the critical need for effective incident response today, a function that is built near overnight will be here to stay.