Yesterday a friend asked me if I would take on an independent role sorting out all of the security issues for their new system.
I thought about it a bit and realise the depth of the misconception of what security was all about nowadays. Yes, it’s true that 20 years ago security was something that would be handled by a different team. Operators would set up perimeter firewalls and manage all the passwords and deployment rules. Any interaction from outside the organisation would be thoroughly vetted (by software, that is) to make sure it was okay before it got near any of the company software, with input and output validated and sanitised long before it reached the developers’ code.
Nowadays, it’s different. Systems are complex composites of cloud services. And even handling the passwords to access those services is the responsibility of the developers. So is figuring out how to deploy software and do upgrades. Indeed, these days of continuous integration, there is rarely an operations team at all. There might be a few highly stressed people managing disasters of one kind or another in a Security Operations Centre, yes, but “24-hour guardian of the software system” no longer exists as a separate role.
That is why Developer Centred Security is so important. Because ONLY developers get to decide about security. Whereas 20 years ago the security group would run their own services and never speak to developers, nowadays they are forced to work with them. Like the woman in the picture above, security specialists have to influence developers. I told my friend the best I could offer would be helping the developers to get security right.
The role of security specialist has changed from being an outward-facing software configurer to being an inward-facing persuader.
Think of that next time you need to recruit software security staff.