During the course of my commercial career, I’ve seen significant evolution in cyber security; in particular, how it is viewed by an organisation. At the beginning, security was a somewhat side-lined activity, often under the remit of Information Technology. However, as cyber-connectivity increases for us, both professionally and personally, the attack surface for organisations increased exponentially.
Cyber criminals took advantage of this, along with systems implemented before security was a consideration for new products. A number of high-profile cyber breaches and continuous attacks highlighted the importance of security in products and operations, and admittance into risks tracked directly by the Board. However, the interjection meant that for many organisations, security was initially set up as a top-down function. While the practice may be suitable for governance and compliance, security involvement is often added late in the product or service development lifecycle. As a result, recommendations by the security function may not have the full context of previous business and design conversations, and security assurance will require retrofitting rather than being ‘built-in’, which is inefficient. Security issues are discovered late, at the point when delivery teams are under a tremendous amount of pressure, with frustrations all round and a real possibility of delayed delivery that may come with financial and reputational damage.
Paradoxically, the increased visibility on security has generated its own momentum. As more eyes literally are diverted to systems and products, by security researchers and hackers, we ‘discover’ more security vulnerabilities in our products. Even in products and systems where due diligence was conducted on or before release. This is partly why vendors release periodic vulnerability advisories. With the best will in the world, it’s simply impractical to produce a ‘perfect’ product in modern product lifecycles which are increasingly aggressive as consumers are used to, and expect agility and efficiency. Given the sheer volume of known vulnerabilities as well, addressing these late in the product cycle could overwhelm delivery teams and increases the risk of critical vulnerabilities being omitted.
This has led to the next evolutionary step in security - embed security professionals within the product teams. This is a way of working advocated by DevSecOps. The integration of security professionals or product specialists with an interest in security is the most efficient and frictionless way of integrating security into modern product pipelines. Security input and oversight from the beginning means security can be embedded rather than retrofitted. Having security expertise within the products team makes sense, since they will have full accountability for the solution, including security. Additionally, the product team are closer to the business requirements as well as design decisions, thus ought to provide more suitable security guardrails. Indeed, this is precisely the team structure many organisations are migrating to as part of their transformation programmes.
From being a somewhat unloved side function, security has now evolved to be an integral part and a key stakeholder, through a process of steady evolution. This last step in the current evolutionary process requires cultural change and implementing a bottom up approach, that will complement existing security frameworks. Are we ready?