I don’t know what the future of cybersecurity consulting will be, but I have some thoughts.

Back in the late 1900s, cybersecurity wasn’t really a thing. To the extent that it was, it was owned by a very small group who were both techy and a little naughty in the νοῦς, as they say. A typical cybersecurity engagement involved rocking up to a customer, him giving you a cable, and you going at it for love and money, getting pwns every which way before lunch. It was the proverbial Wild West.

This didn’t last for ever, and pretty soon big money began to realize it just needed to get IT and web devs on board with doing things in such a way that their business couldn’t be rm -rfed by a single SQL injection. They started to VLAN and firewall not out of operational duty only but also out of security-defensive concerns. PHP discouraged the mysql_ functions. Operating systems, too, encouraged less blasé attitudes. Cybersecurity was becoming mainstream, but not less fun.

The next evolution coincided with a shift to more mature development patterns. Infrastructure deployments were moving to the ‘cloud’, and code was being built on for-purpose machines with well-defined and auditable build and deployment pipelines. This didn’t inherently include any change in security practice from the get-go, but it pretty quickly became clear that the code quality checking tools could easily be altered to verify not only the form-quality but also the security-quality of the commits. Thence DevSecOps, with its container scanning and developer-located security regimen, dropped onto stage. No longer would lazy bad code be accepted.1

And thus we arrive at the present state of the cybersecurity industry. The trailblazers who understood the proper use of these new digital technologies had largely done the work of exposing the risks of misuse, both as bug classes and instances. The natural progression of things is such that practices and protections would be developed to guard against these badthings happening in the first place—indeed, before the code has left the developer’s machine, if possible. At the same time, copycats could easily attempt to imitate the brilliance of the pioneers at much less cost (it is easier to learn Newton’s laws than be Newton).

This migration of security from an ugly overhead pre-deployment to something approaching secure-by-design is a huge credit to the cyber geeks of yesteryear, and is also the cause of their protégés’ present woes. It no longer makes the most sense to do your development and deployment and then have it reviewed by costly security professionals the way it once did. The specialist knowledge applied in those assessments has been discovered and shared, and is now the property of the developers too. Why wouldn’t they want to bake that knowledge into their products from the get-go?

Obviously they would, and they should.

For cybersecs, all of this means that a shift in approach is required. Run-of-the-mill web app assessments are basically grunt-work now. They don’t even make sense from a practitioner’s perspective: not only are they basically boring, but it is no longer necessary only to discuss the flaws in a finished product, because the product owners, for the most part, have a greater (security-)technical understanding and can be spoken to directly rather than indirectly through the flaws in their output. Even more so with API assessments: these can much more robustly be undertaken by scripts than humans, and should be—in the devops pipeline.

It is possible to have a guard at the door of every house; it’s better to have locks. ‘Specialists’ used to pump petrol. Sharp rocks are rounded. It’s nature’s way.

The value into the future (AI excepted) seems to me to be found in being embedded within organisations, driving not only the process but also the people in their habits and practices to ensure a secure outcome from the outset.

That will require a different set of skills:

  • It will be more people-focussed and personable, requiring actual ability to communicate with humans—we all know this is a common deficit in cybersecurity nerds
  • It will require a greater level of organisation and clarity of output
  • It will require greater team play—security consulting has long been largely an individualistic affair
  • It ought to command higher pricing vis-à-vis the old style grunt-work (which it will eventually largely replace)
  • It will reduce the need for those with the current typical cybersec professional’s skillset

Overall, this process is nothing more than efficiency driving towards sunrise. The impact that an individual consultant can have in a this forward-thinking role is massively greater than by pushing out twenty routine 4+1s. It has already been happening for a number of years with great success, and I can’t see anything preventing it from predominating.2

If you aren’t up to it, be a researcher, or downgrade to development.

Finally, if you’re heavily invested in cybersecurity outfits, you may want to consider these points more carefully.

  1. Indeed, the more forward-looking organizations had already implemented this kind of ring-fencing of the communal code repos. Many moons ago, like, 3.6 era, I made a Firefox plugin which was rejected due to a single (and quite safe, might I add) use of innerHTML. ↩︎

  2. For smaller businesses, there will remain a role for occasional visits to configure and check DevSecOps pipelines, but this is essentially the same role time-limited. ↩︎