The Future of InfoSec
Recently I had a conversation with my team manager, and the conversation turned to “where do you see the future of security going?” It didn’t take much thought to come up with an answer: more analytics, more automation, fewer people. Let’s approach these one at a time.
More Analytics
Not everything can be reduced to raw numbers, but don’t tell your manager that. Tracking things like mean time to resolution (MTTR) and ticket handling times and queue wait times is already standard practice for a well-organized SOC. In the near future we’ll see an increase in tracked statistics, including how well SIEM rules are performing, how many incidents a particular log/data source has discovered, machines/users who are compromised/risky more often, etc. These data points will be tracked in some dashboarding software like Tableau and visible to the whole team (if not the whole company). Everyone will be held accountable to the numbers. This means false positives need to be detected faster and tuned better.
Time to recover from an incident will be driven down as incidents occur more frequently but are detected faster/earlier. The ONLY way to accomplish this faster resolution time is…
More Automation
In the early 2000s, the world got a taste of security intelligence and automation with the rise of SIEM technologies. In the 20s we’re going to see this accelerate to include automated investigations and remediations. SOAR platforms like Resilient are the first step. Combine them with Ansible and you’re starting to understand the solution here. I’m imagining a world where QRadar/ArcSight/Splunk/Sentinel detects a threat, validates this incident against existing threat intelligence, maybe some ML/AI determines the risk score, and remediation is automatically triggered. In a cloud world, this means the container is purged and rebuilt from a known-good image. In an on-premise world this means making configuration changes to the server (disabling services, expiring passwords, etc). All done without human interaction, because the level of confidence increases every time the automation playbook runs successfully. Eventually companies come to trust the automation more than the humans, because automation runs the same way every time. There’s no human error to account for.
Systems start to be built on logical designs and repeatable patterns. Rebuilding a system is done with a push instead of manual configuration. Server specs are stored with the application code, and every server’s needs are documented in a YAML file. It’s not DevSecOps, it’s DevOps plus security.
Fewer People
Hiring in information security is hard. Borderline impossible. There are millions of reasons for this. Part is that companies don’t want to or can’t afford to pay security engineers what they want to make. Part is because there are so few security engineers at all. And part is because so many unemployed or underemployed security engineers are junior level in a field that demands experts. If you only have the budget for two or three infosec employees, you want to make the most out of their skills for the least amount of cash. Unfortunately, this means companies are stuck unable to fill many infosec positions, and the security engineers who have jobs are happy to stay at the top (read: at vendors or consultancy organizations). At a company where the CISO might only make $200k, why would they hire a security engineer at the same pay?
So what this means is, companies have to hire fewer people. Which means they need to do more with the few people they have. Which historically has meant outsourcing. Managed Security Services Providers (MSSPs) have been around for decades and most companies have at least one they trust. But this hits the MSSPs and the vendors, too. As hard as it is to hire for Walmart, Walmart’s vendors are similarly struggling to hire from the same talent pool.
This puts extra hiring stress on vendors. Already SIEM/SOC consultants are expected to be experts in every technology a company has and every threat they might face. If you’re looking to get hired as a vendor’s consultant in the 20s, you might also be expected to know Kubernetes, AWS/Azure, Python/Powershell, automation technologies like Anisble/Chef/Puppet, and basically anything listed in the next section. This will make consulting more expensive, but make your infosec operations cheaper, easier, and more repeatable.
The last bit I’ll mention is, if you’ve done the automation and the analytics properly and have your technologies configured properly, you can get away with hiring lesser experienced (read: cheaper) junior resources. After all, their main job responsibilities will be to babysit the automation, watch the analytics, and make minor changes to the playbooks. Investing in processes and technologies enables hiring cheaper resources. It’s a win-win.
Technologies to Watch
Of course, there are technology solutions to all of these problems.
Jupyter Notebooks – This is the most key technology I see shaping the next 10 years in infosec, and there’s really only one player in the space. The ability to write your playbooks and also have a one-click “run now” button for investigation/remediation is just too powerful. This has the added benefit of being easier to hire for: Python/Powershell programers are far more common and far cheaper than experienced security engineers/analysts.
Also keep an eye on technologies that enable these notebooks: data lakes, APIs, STIX/TAXII feeds, Azure Sentinel (a SIEM with Notebooks built-in).
Configuration Management – Chef, Puppet, Anisble, Salt, CloudFormation, etc. Being able to automatically configure security settings and logging from inside your application will be key to doing more with less. My vote is on Anisble not because it’s an IBM product but because it’s agent-less and works on so many platforms. Automatically remediating findings will be important to proactive security teams, especially as companies continue to move to the cloud. Most likely enterprise teams will have two of these: one for their cloud and one for on-premise. Companies with a single primary cloud vendor will have an easier time adopting configuration management workflows.
Container Management – Kubernetes is the obvious winner here, but whatever you pick doesn’t really matter. Discrete servers and bespoke VMs are already giving way to container orchestration. Docker Swarm, Dokku, Kubernetes, OpenShift, it doesn’t really matter. What matters is being able to deploy applications to a server while defining the OS, packages, firewall rules, etc that go with the application, all within the application’s code itself. Every time you push that application to a server, it should behave exactly the same way. If there’s a breach, it should be fixable by simply re-deploying the application.
Observability Tools – This one is probably the hardest right now. Traditional SIEMs already struggle with the idea of ephemeral machines. By the time the SOC receives an alert and begins their investigation, the VDI or container or DHCP lease may have already expired, making investigation difficult. You only have historical logs and likely can’t examine the container/VDI/etc live. And forget about forensic images. That means you need logs, as many logs as you can get, at the time the machine was running in the same config that was compromised. AWS CloudWatch/X-Ray, New Relic, DataDog, and other Application Performance Monitoring (APM) tools will become CRITICAL to understanding what happened while the machine was live. Of course you don’t want to keep a compromised container online, so you should hopefully remediate with Ansible and do your discovery with New Relic after remediation is done. Just try not to rely too much on IP addresses or container IDs that probably aren’t the same anymore. Tying a past incident to a present-day container will take more than a little work.
IAM – Oh boy is IAM important. Even more important is managing your IAM and maintaining roles across clouds and on-prem environments. Again, single-cloud companies have the advantage here, but even multi-cloud IAM has vendors (Sonrai Security comes to mind) willing to help manage the complexity. Too many breaches come because of poorly implemented IAM policies.
Honorable Mention – Any cross-platform tooling. The industry is going into a new shake-up and products are changing fast. Being able to switch on a dime and still keep the same security posture will be a real game-changer. STIX/TAXII is a great example, YARA is another. A bigger change in my world is Sigma. Unfortunately the QRadar integration isn’t super great due to QRadar’s unique real-time rules engine, but if you’re a customer of any other SIEM… write your rules in Sigma. Vendor lock-in is real and unavoidable but you should still seek out technologies that allow you to switch vendors or tools as easily as possible.
Conclusion
The next 10 years in security will be more interesting than the past 10 years. Existing vendors are being challenged not only by new security startups but also by new computing paradigms that fundamentally shift how and where security is performed. As Marc Andreessen pointed out, software is eating the world. The more you can perform in software (rather than wetware, aka humans), the more resilient your organization will be. And the more you can rely on cheaper junior resources, the more the entire world benefits.
Analytics tell you what you need to focus on, automation replaces manual labor, and this all allows you to perform the same tasks with fewer (or less experienced) people.
