Industry executives and experts share their predictions for 2019.  Read them in this 11th annual VMblog.com series exclusive.

Contributed by Mike Bursell, chief security architect, Red Hat

Making better use of your security experts

Over the next 12 months, I'm hoping we're going to see a de-insularisation of security within the business and a move to automated processes. As everyone comes to terms with the growing customer expectation of speed to market and requirement for near instantaneous innovation in services, expecting security to perform a "sign-off" and function before any product or service goes live has become completely unsustainable. You have three options:

1)    Come up with "set-in-stone" business-wide security rules and hope that you can manage the inevitable exceptions that almost every project will generate;

2)    Acknowledge that you can't move fast enough with existing processes and try to fix problems as you notice them;

3)    Find a way to move your security expertise into automated processes that are both fast and scalable.

The first of these is never going to allow you to move quickly enough to cope with the increasing speed of deployment. Whether you adopt agile methodologies such as DevOps for all of your development immediately or gradually across your teams, a fundamentally reactive approach will see you losing ground to your competitors and new movers in the market. The second option will, sooner or later, lead to a breach or service disruption that you are unable to manage and is the sort of strategy that will get you called into your CISO's or CFO's office for a very brief and even more uncomfortable conversation. The last option, then, is the one that you need to embrace, but what does it mean and how do you implement it?

The first thing to do is move your security experts out of their "ivory tower".  To be fair, most security groups or departments are much less insular than this in practice, but perception is everything.  In 2019, make it a priority to encourage greater mixing of your security expertise through the various departments with whom they work.  Not in a "look, here's a security person, call on him/her if there's an issue" way, but by getting them involved and invested in the work of their colleagues in different departments and functions, so that both "sides" see the benefit, and stop thinking of each other as the opposition, but as colleagues.

On its own, this isn't enough: however many security people you have, they still won't scale.  You need to encourage skills transfer.  We can never expect every person in your organisation to become a security expert, but if they know the basics, and know who to turn to when they realise that they are moving out of their comfort zone, then you're already scaling your security capability into the wider business.  This should also help your security experts to realise that their expertise is still relevant and useful: there's a careful balance here between encouraging information transfer without dilution that needs to be carefully monitored.

Once you've managed to get security into the hearts and minds - well, minds, at least - of the rest of your organisation, it's time to think about how you start moving the expertise that your security group brings into the processes that your development, testing, operations, audit and governance teams run day-to-day.  This is where you can really start to scale out.  If your security experts can identify what points in the development process are security-critical - choice of base container images, for instance, or maybe where monitoring of your operations can actually aid your auditing process - there are opportunities for you to automate increasing parts of your security function into the processes themselves.  This is absolutely not about making the work of your security experts redundant, but about releasing them from humdrum daily "unblocking" tasks and allowing them to concentrate more on interesting, valuable tasks where they can come up with innovative processes themselves.

##

About the Author

Mike Bursell joined Red Hat in August 2016, following previous roles at Intel and Citrix working on security, virtualisation and networking. After training in software engineering, he specialised in distributed systems and security, and has worked in architecture and technical strategy for the past few years.  His responsibilities at Red Hat include forming security strategy, external and internal visibility and thought leadership.  He regularly speaks at industry events in Europe, North America and APAC.

Professional interests include: Linux, Open Source Software, security, distributed systems, blockchain, NFV, SDN, virtualization (including Linux Containers and hypervisors).