Source: darkreading.com
If you believed everything you read, artificial intelligence (AI) is the savior of cybersecurity. According to Capgemini, 80% of companies are counting on AI to help identify threats and thwart attacks. That’s a big ask to live up to because, in reality, few nonexperts really understand the value of AI to security or whether the technology can effectively address information security’s many potential use cases.
A cynic would call out the proliferation of claims about using AI for what it is — marketing hype. Even the use of the term “AI” is misleading. “Artificial intelligence” makes it sound like the technology has innate generalized intelligence that can tackle different problems. In reality, what you have in most cases is a machine learning (ML) algorithm that has been tuned for a specific task.
The algorithms that are embedded in some security products could, at best, be called narrow (or weak) AI. They perform highly specialized tasks in a single (narrow) field and have been trained on large volumes of data, specific to a single domain. This is a far cry from general (or strong) AI, which is a system that can perform any generalized task and answer questions across multiple domains. We are a long way from those type of solutions hitting the market.
Having a technology that can do only one job is no replacement for a general member of your team. So, any notion that AI is going to solve the cyber skills crisis is very wide of the mark. In fact, these solutions often require more time from security teams — a fact that is often overlooked.
For example, take the case of anomaly detection. It’s really valuable for your security operations center analysts to be able to find any “bad stuff” in your network, and machine learning can be well-suited to this problem. However, an algorithm that finds way more “bad stuff” than you ever did before might not be as good as it sounds. All ML algorithms have a false-positive rate (identifying events as “bad” when they are benign), the value of which is part of a trade-off between various desired behaviors. Therefore, you tend to still need a human to triage these results — and the more “bad” the algorithm finds, the more events there are for your team member to assess.
The point is not that this is a particularly surprising result to anyone familiar with ML — just that it’s not necessarily common knowledge to teams that may wish to employ these solutions, which may lead to inflated expectations of how much time ML may free up for them.
Whereas the example above was about how ML algorithms can be targeted at doing some of the work of a security team directly, algorithms can also be used to assist them indirectly by helping users avoid making mistakes that can pose a risk. This approach is exciting because it starts to look at reducing the number of possible events coming into the funnel — rather than trying to identify and mitigate them at the end when they contribute to a security event. It’s not just solving the most obvious issue that may bring about the desired outcomes in the long term.
The other issue that is easy to overlook when considering ML is that of data. Any ML algorithm can only work when it has enough data to learn from. It takes time to learn; just think, how many Internet cat pictures do you need to show it before it recognizes a cat? How long does the algorithm need to run before the model starts to work? The learning process can take much longer than expected, so security teams need to factor this in. Furthermore, labeled data, which is optimal for some use cases, is in short supply in security. This is another area where getting a “human in the loop” to classify security events and assist in the training of the algorithm can be required.
