This is the third post in a series on the future of information security, which will be the basis for a white paper. You can leave feedback here as a blog comment, or even submit edits directly over at GitHub, where we are running the entire editing process in public. This is the initial draft, and I expect to trim the content by about 20%. The entire outline is available. See the first post and the second post.

What it Means

The disruptions and trends we have described don’t encompass all advances in the worlds of technology and security, but they represent the ones which will most fundamentally transform the practice of security over the next decade. For example we haven’t directly addressed Software Defined Networks (although aspects show up in our cloud, hypersegregation, and Software Defined Security descriptions), malware ecosystems, or the increasing drive toward pervasive encryption (driven, in no small part, by government spying). Our focus is on the changes most fundamentally alter the practice of security, and the resulting outcomes.

The changes come in fits and spurts – distributed unevenly, based on technology adoption rates, economics, and even social factors. But aggregated together, they paint a picture we can use to guide decisions today – for both organizations and professionals. All these changes are currently in process, with plenty of real-world examples.

This report focuses on the implications for three groups: security professionals, security vendors and providers, and cloud and infrastructure providers. The people tasked with implementing security, the folks who create the tools and services they use, and the public and private IT departments managing our platforms and services.

Let’s start with some high-level principles for understanding how security controls will evolve, then dig into the implications for our three audiences.

Security Controls Evolution

There is no way to predict exactly how the future will turn out or how security controls will evolve as these trends unfold. But one key question with a few logical follow-ups, can quickly help identify how security controls will likely adapt (or at least need to) in the face of change.

How does this enable my security strategy?

What does the provider or technology give me? What does it do? What do I need to do? The purpose of this question is to examine how the lines of responsibility and control will shift.

For example, when choosing a new cloud provider, what security controls do they provide? Which can you manage? Where are the gaps? What security controls can you put in place to address those gaps? Does moving to this provider give you new security capabilities you otherwise lacked?

Or, for a new security tool like active defense: Does this obviate our need for IPS? Does it really improve our ability to detect attackers? What kind of attackers and attacks? How can and will we adjust our response strategy?

Here are two interrelated examples:

  • iOS 7 includes mobile device management hooks to restrict data migration on the device to only enterprise-approved accounts and apps, all strongly encrypted and protected by stringent sandboxing. While this could significantly improve data security over standard computers, it also means giving up any possibility of Data Loss Prevention monitoring, and needing to implement a particular flavor of mobile device management. However…
  • Cloud storage and collaboration providers keep track of every version of every file they hold for customers. Some even track all device and user access on a per-file basis. Use one of these with your mobile apps, and you might be able to replace DLP monitoring with in-depth real-time auditing of all file activity at the cloud level – including every device that accesses the files.

The combination provides a security and audit capability that is effectively impossible with ‘traditional’ device management and storage, but requires you to change how you implement a series of security controls.

Focus on your security strategy. Determine what you can do, what your provider or tool will do, who is responsible, and the technology capabilities and limitations – rather than how to migrate a specific, existing control to the new operating environment.

Implications for Security Practitioners

Security practitioners in the future will rely on a different core skill set than many professionals possess today. Priorities shift as some risks decline, others increase, and operational practices change. The end result is a fundamental alteration of the day-to-day practice of security.

Some of these are due to the disruptions of the cloud and mobility, but much of it is due to the continued advancement of our approaches to security (partially driven by our six trends; also influenced by attackers). We covered cloud computing in depth in our paper What CISOs Need to Know about Cloud Computing. Let’s look at the different skills and priorities we expect to be emphasized by the combination of cloud, mobile, and our six inherent security trends.

New Skills

As with any transition, old jobs won’t be eliminated immediately, but the best opportunities will go to those with knowledge and expertise best aligned to new needs. These roles are also most likely to command a salary premium until the bulk of the labor market catches up, so even if you don’t think demand for current skills will decline, you still have a vested interest in gaining the new skills.

All these roles and skills exist today, but we expect them to move into the core of the security profession.

  • Incident Response is already seeing tremendous growth in demand, as more organizations shift from trying only to keep attackers out (which never works) to more rapidly detection, containment, and remediation of successful attacks. This requires extensive security expertise and cannot be handed off to Operations.
  • Secure Programming includes assisting with adding security functions to other applications, evaluating code for security issues (although most of that will be automated), and programming Software Defined Security functions to orchestrate and automate security across tools. It requires both programming and security domain expertise to be truly effective. Some practitioners will find themselves more on the secure application development side (integrating security into applications), while others are focus on developing security applications themselves, but the same basic skills apply either way.
  • Big Data Security Analytics are needed to make sense of the massive security data sets we are already starting to accumulate. This skill is essential to better detection and remediation of security incidents, and critical for visualization and closing the action loop. Most security information and management tools are already migrating to big data platforms, but making sense of this information cannot be completely automated – especially as organizations add custom application feeds.
  • Security Architects help design secure applications, assess and recommend security controls and integration across different cloud and infrastructure providers (especially as we gain more ability to directly manage security in the infrastructure itself), and work with security programmers to design and implement internal security orchestration and automation applications.
  • Audit/Assessment and Penetration Testing increases in importance as we need to spend more time assessing external providers, and host more of our internal applications on Internet-accessible services. Vendor risk assessment of cloud providers is already a major challenge for most organizations – particularly making sense of the wildly divergent third party attestations, self-assessments, provider documentation, and contracts.
  • Chief Information Security Officers will continue to rise in importance and require experience in the skills sets we have described. The position will be as political as it is technical. The trend toward greater CISO responsibility and accountability started years ago, with organizations increasing reliance on Internet-based technologies, and cybercrime beginning to cause more visible losses. There is no reason to expect any of these trends to abate, and successful CISOs will need a solid grounding in the skills described above.

Shifting Priorities

In ten years the average security team will operate quite differently than most teams do today. Skills evolve and priorities change to align with the new ways organization consume and deliver technology, and the different capabilities of security tools and the platforms they protect.

We expect to see much greater emphasis on assessment and vendor risk management, including penetration testing. Some companies we talk with today already use hundreds of different cloud services – mainly smaller Software as a Service providers with niche offerings targeting particular business units or initiatives (such as short-term marketing campaigns). There is little consistency in security or documentation across them, and we don’t expect this to change any time soon. The native security capabilities of mobile platforms differ wildly, and their ecosystems of mobile applications are incredibly diverse.

It is already challenging to understand the security controls, baseline security, options, and Service Level Agreements for a single provider or platform. Things get harder when you consider the complexity of using this information to adapt security controls, align security strategy, and integrate the new service into security operations. Compliance and legal requirements increase the challenge. Lastly, this all needs to be considered in the context of the business use case. Assessment may need to account for dozens or hundreds of providers, platforms, and services – all innovating on a daily basis to stay competitive.

Many organizations we talk with today look at this as an outsourcing problem (at least – or perhaps to cloud computing instead). But we believe the fundamental technological differences of the cloud – such as abstraction and automation – matter more than multitenancy, and so will require technology assessment skills rather than simply RFPs and contractual evaluation.

Some providers bring more security to the table, others decrease it, and some merely shift the risks. All this needs to be tracked and evaluated on an ongoing basis. Then compiled into audit reports to meet compliance obligations.

As we mentioned, more resources will be dedicated to incident response. Right now spending on incident response technologies and operations is a small fraction of the typical security budget, but we expect this to shift – in some cases to comprise a majority of the budget – as security drops other operational tasks, and as advances such as hypersegregation harden platforms and push attackers to ever more advanced techniques. IR also ties together our trends of active defense and closing the action loop (including big data security analytics) to better detect and then contain attacks. Our infrastructure will become harder, and we will shift resources to detection and response.

Security will also focus more on integrating directly into IT operations at a deep technical level through Software Defined Security. This is enabled by the proliferation of APIs to manage infrastructure, platform, and service security features directly – rather than security relying so extensively on external boxes and rerouting traffic as we do today. We already see this happening with examples such as next-generation firewalls integrating with Software Defined Networking, IAM integrating with external services using SAML, and new logging and auditing features exposed by various cloud providers. We even see automated vulnerability assessments kicked off by cloud controllers when new instances launch.

All this is only possible due to the ongoing operationalization of security, which enables security professionals to focus where their expertise matters, even when it means letting go of security-sensitive tasks that can be easily managed, with guidance, by non-security IT Operations.