The Rise Of Cloud Platforms Such As AWS And Openstack, And The Exponential Growth In The World Of Automation Has Lead To Applications Being Written, Deployed And Operated In A Different Way. Cloud Native.

Cloud platforms work in a very different way to traditional platforms, such as traditional Datacentres, managed hosting and VMWare farms. They are completely self service so that engineers do not need to go through traditional infrastructure teams to gain access to resources, they are on-demand, meaning they are available almost instantly, they are “pay as go”, metered so you only pay for what you use after you use it.

The National Institute of Science and Technology published their “Definition of Cloud Computing” in 2011, many industry experts (the Clouderati) were consulted and this succinct but complete document, is the 5 commandments of cloud computing used by all cloud experts, if a service does not meet the 5 criteria, it is not cloud.

Additionally to the 5 characteristics, an almost 6th one is API’s. Virtually everything can be done on these clouds via an API, no manual dashboards and GUI’s to navigate, therefore everything can be scripted and automated.

What this has meant in practice is that cloud platforms DO NOT provide resiliency to a workload running in on it. For example, a workload running in a company datacenter on a VMWare farm, will use a feature called VMWare HA. If there is a fault with the underlying hardware and it fails, VMWare will bring that workload up on another server with just a temporary loss of service.

Additionally the storage will be highly available and may well be backed up as part of a service. All these things are able to provide you with an SLA for an individual workload. In a cloud platform such as AWS, there is no SLA on a single workload, the SLA is on the whole platform, or for each service on that platform.

This is because due to the levels of automation in the platform, the onus is on the application itself to look after its resources and manage failure. When a monitoring suite of tools detects failure it can quickly spin up new resources to replace it, via the cloud API’s and using features such as “Autoscaling” can do this in a very effective fashion.

This is called “Autonomic”, apps that can perform their own basic troubleshooting and resolution of issues. To support this workloads benefit from being smaller, so they can deploy quicker, and of course this works well with the “microservices” model.

New Technology

One of these new ways of working is PaaS and “Containers”, here applications are completely abstracted from underlying operating system, this changes the security risk profile and the methods of securing it.

Gone are the responsibility of security issues around OS and hardware, those are the remit of the service vendor who provide the platform, however network and application type security risks still need to be managed, but host based solutions may not work due to the lack of access to the “host”. However many security vendors are starting to build their solutions to work with containers. An example would be Trend Micro a world leader in Host Based AV and IDS, their deep security product now supports containers.

Cloud Security

Cloud has a very different security model to traditionally built applications. Traditionally many security controls e.g. firewalls, “IPS/IDS” and “WAF” were installed at the network perimeter intercepting traffic and were shared by many applications, they are manually managed by a dedicated team, that require a ticket to make a change and have SLA’s sometimes in the weeks rather than days. This does not work in a fast moving, dynamic cloud environment.

There is nothing wrong per se with perimeter security where appropriate, but at worst these tools need to support self service, users need to be able to utilise and consume these services via an API, at in some cases these solutions need to become host based where appropriate. Host based solutions are deployed along with the application and are managed by the squad. They will potentially follow guidelines and policies provided by a central group, but install, deployment and management is by the local team. A layered approach is then followed where a mix of perimeter and host based security is used where appropriate, but all supporting the continuous deployment that new ways of working require