Back in the day enterprise architecture was physical and singular, conveniently located in the one place, which could easily be managed and made secure.
Now, the situation has reversed. The rush to digitisation is forcing organisations to move at unprecedented speeds. Organisations that have adopted agile methodologies and DevOps practices have been able to modernise their environments, application stacks and deployments, decomposing previously monolithic applications into microservices architectures, automating routine tasks, adopting Kubernetes (k8s) for container management, and moving to public cloud for agile services delivery.
While this has greatly enhanced convenience for organisations and their end users, it has come with some significant security issues.
Within this pace of change, security has, mostly, been a laggard. 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 examples, after they occur.
So, what is the best way forward to ease the strain on security techs, while preventing breaches, without creating user friction?
In many ways, the security needs when decentralising into virtualised environments has taken organisations by surprise. As we’ve moved out and away from our traditional centralised security controls, the distributed controls we have at hand aren’t really sufficient.
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 changed infrequently because of heavy investment, accumulated intellectual property, and 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 mish mash of technologies, unclear operations, poor visibility, difficult reporting, and often 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, i.e.: it cannot be forgotten, removed, or bypassed. It also means that security is in place when and where it's needed and 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 life cycle 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.
Security teams want to transition away from being the ‘office of no’ by taking security to the organisation, rather than dragging the organisation to security. In our opinion, 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 a program, rather than after.
Called security ‘shifting left’, this means implementing security controls in earlier stages of the development life cycle, e.g.: Threat Modelling, Static Application Security Testing, Software Composition Analysis; and making later stage security controls available in earlier stage environments, e.g.: Web Application Firewall, Dynamic Application Security Testing, etc. into Dev and Test environments.
Of course, distributed security tends to bring a bunch of 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 as 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. Arguably most importantly, you also have different alerting, reporting, and logging from each environment, which makes it really hard to manage or predict your environments.
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 business.
F5 can help you realise such a vision. Find out more.