Over the past few weeks, I’ve been facilitating sessions at Evanta CISO events. If you’re not aware, these are discussions for CISO’s by CISO’s, held around the country and well worth the time. The topic for my sessions was AI & orchestration in cybersecurity, with more than 60 CISOs participating in five cities. While each venue had a slightly different emphasis, there were a number of broad trends across the country.
The first is that there’s both great interest, great skepticism and great caution about these technologies. Interest because, as one CISO put it, they have to reduce the time and resources required between “mole and whack”. Skepticism, because, as another put it, we’re at ‘peak hype’, and caution because of the lack of new skills required to take advantage of them.
The consensus was that orchestration is ready for prime time, and about 18 months ahead of AI, so let’s take that one first. While the topic was orchestration, the majority of CISO’s spoke of automation, both human initiated and fully autonomous processes. There’s a tremendous amount of grunt work in the SOC – having to remediate the 437thinstance of someone clicking on a flying toaster video is tedious and frustrating, so ‘automating the known’ is a high priority. About a third of the orgs are well along the way to having automation triggered directly from an event in the SIEM and not within an incident response workflow. About a third are using a human in the loop approach for all orchestration, and about a third are just starting the journey. For all, the goal is to move their staff up the value chain to more interesting work, which increases job satisfaction and reduces turnover. Sounds great, right?
One challenge is that you have to trust your model/system that’s generating incidents, to ensure that you don’t remediate inappropriately. Once CISO said that automation is like gun control – it means hitting what you aim at. Another organization has an explicit workflow for new incidents that requires automation (or triage as to why it can’t be). Nearly all expressed frustration at how much time and energy they are spending on gluing systems – both security and IT – together. One remarked that it’s like the late 1990’s again: everything is hub and spoke, and asked where the middleware for security? A number were very interested in being able to consume security as microservices delivered from the cloud. For those with managed security services, they’re planning to put orchestration and automation into their next renewal contracts.
And they plan to do the same for AI, assuming that the technology matures in time. Right now, only about a third of the orgs are using AI, and the vast majority of those are implementations of basic machine learning. Several were using cognitive to handle unstructured information, and only a handful were starting to explore using deep learning. There were a number of common goals and obstacles.
Almost universally the desire is to use AI to remove the noise and get to the signal. SIEM was acknowledged as the ante to get into the game, though a number of CISO’s are wondering if a advanced AI can replace a SIEM (and if the regulators will allow that). The ‘black box’ of deep learning is expected to be a problem with gaining approval from auditors.
A surprisingly large minority either had, or were looking to build a security data lake from scratch, and then implement their own incident discovery capabilities within the lake. The majority are looking for vendors to build COTS projects along those lines, again, as a replacement for a traditional SIEM. As a number agreed, those projects are expensive and high-risk – and they can’t afford mistakes with a limited budget. AI, and especially machine learning, within individual segments, like application source code analysis or user behavior analytics, was viewed as much more ‘real’ today than building a system to discover a rock in a data lake. I made a comment about many of those turning into data swamps, to a lot of knowing laughs around the table.
That triggered a good conversation about the need to ‘move security to the left’. For source code analysis there was wide agreement that security needs to get involved in the DevOps – or DevSecOps – process. For UBA a plurality spoke to cultural barriers to monitoring all the people all the time. Big Brother is something they want to avoid, and one described an internal marketing effort to rebrand it ‘Big Mother’ instead: Not watching over you, but watching out for you to keep you safe.
And that brought the group to the longer term goal: They want to have an AI consuming inbound security information (books, articles, alerts, threat feeds, news stories, and so forth), then consolidate it down into proactive actions and recommendations, including an initial, automated survey for IOCs in the environment – a push to hunters, instead of a pull from responders. Getting there requires both trust in the AI, and skills that don’t exist yet.
Skills were woven throughout the entire conversation, and a point of concern. Orchestration/automation frameworks require programming skills that don’t currently exist on the security team. For AI, particularly for those building their own data lakes, the largest obstacle is finding data scientists with security backgrounds. A number of orgs are going out into the colleges – and even high schools – to recruit cyber security students for internships, and steer their electives towards programming and data science skills. There was a strong consensus that existing programs need to evolve and add those to the core curriculum. They may not be needed today, but they will be.
In the end, there was universal agreement that our security programs need to change posture – to move from responding on our heels to hunting on our toes, and that AI and automation will make that possible.