Back in the day, enterprise architecture was physical and singular, conveniently located in one place that could easily be managed and made secure.
But this is no longer the case, and the rush to digitisation is forcing organisations to move at unprecedented speeds. As a result, organisations that have adopted agile methodologies and DevOps practices have been able to modernise their environments, application stacks and deployments.
They are decomposing previously monolithic applications into microservices architectures, automating routine tasks, adopting Kubernetes (k8s) for container management, and moving to public cloud for agile service delivery.
While this has greatly enhanced convenience for organisations and their end users, it can come with associated security issues.
In many cases, DevOps have been implemented and distributed without security input, causing IT to have to patch issues as they occur. And, in some significant public incidences, after they occur.
So, what is the best way forward to ease the strain on security techs and prevent breaches – without creating user friction?
Moving away from centralised security
In many ways, the security needs of decentralising into virtualised environments have taken organisations by surprise.
Because centralised environments were well known and quantified, it was relatively easy to achieve uniformity of security controls, operations, reporting and alerting.
Changes to adopted technologies happened infrequently due to heavy investment, accumulated intellectual property, and the high cost of change.
Supporting multiple new environments brought a raft of challenges and considerations, such as a lack of maturity and capability, disparate cloud environments, a mishmash of technologies, unclear operations, poor visibility, difficult reporting, and low maturity.
In response to these challenges, the public cloud vendors gave us transit gateways, a central point of control where all traffic to and from tenants traverses.
In modern environments, with applications distributed across clouds, tenants, and data centres, it makes a lot of sense to have the security within the individual app. This ensures that security is inherent. In other words, it cannot be forgotten, removed, or bypassed. It also means that security is in place when and where it’s needed, and can be removed as part of the application decommissioning stage.
This model also presents the opportunity for security to ‘shift left’ in terms of being in place at all lifecycle stages and in all environments. This means security controls aren’t encountered for the first time at deploy and run, or in pre-production and production.
Taking security to the organisation
Security teams want to transition away from being the ‘office of no’. They increasingly want to take security to the organisation rather than dragging the organisation to security. The best way to achieve this is by allowing DevOps teams to consume security in the way that works for their needs. This means implementing and using security from the start of an app or program, rather than after.
For example, it would entail implementing security controls in earlier stages of the development lifecycle, e.g.: Threat Modelling, Static Application Security Testing, Software Composition Analysis. In addition, it would mean making later stage security controls available in earlier stage environments, e.g.: Web Application Firewall, Dynamic Application Security Testing, etc. in Dev and Test environments.
Of course, distributed security tends to bring new challenges. To achieve distributed security, it has traditionally meant that you have different technologies, stacks, and controls for different environments. This gives no economy of scale. The diversity of environments increases, and it becomes exponentially more difficult to support each new disparate environment and set of controls.
It also means that you get little consistency of security across different environments, which can lead to issues. Most importantly, you also have different alerting, reporting, and logging from each environment, which makes it tricky to manage or predict your environments.
The road ahead
In an ideal world, how does security work across a decentralised environment with multiple users, apps, and clouds?
The answer is a uniform stack that can be deployed anywhere it is needed.
The stack would be small form factor, suitable for modern environments, and support rapid deploy and decommission. It would also include comprehensive security controls that are mature and enterprise grade.
There would be a central control point: a single point to define policy once and deploy globally. Policy definition would be flexible and be network, identity, security, and application defined. The central control point would also provide centralised and uniform visibility, logging, and reporting.
And the entire solution would be 100% API driven to truly allow dev, sec, and ops teams to collaboratively move at the pace of the business.
Discussion about this post