If you have not been living under a rock recently, you would have read about the Capital One hack, its relationship to the use of cloud technology and how its motivating people to ask the wrong questions. You can brush up on the details of the hack/breach in this post.
Application, software & service would be used interchangeably in this post.
These kind of events are becoming a daily affair, mainly due to a simple reason; ease in which, a software/service can be deployed onto the cloud and DevOps responsible for the same, don't seem to understand all the gears and knobs (that could be modified) that are set to defaults, to get the service up and running in a infinitesimal short time. Security is not a bold line that differentiates the black, from the white. It's a nebulous grey area and needs to be understood, from each application 's requirements and its intended goal. Allowing port 80 for all IPs to a web server is an intended goal to serve traffic for the outside world, but that is not the same configuration, if it's meant to serve traffic only to the internal employees of the company. But the template to deploy that web server is the same for both the cases.
In pre-historic times, it would have been the responsibility of the administrator to understand these requirements to enforce and program these rules. But with Cloud Native, the role of an administrator has been merged with a developer to handle the new set of primitives, set forth by the trending agility of the infrastructure.
The aim of a developer is to develop and deploy a service, to help his company meets its financial goal. There are check lists to be followed, before deploying a service, but does it encompass all the backdoors, that come along with implementing new ideas? Does every developer follow it? When the aim is to develop and deploy ASAP, its human tendency to take short cuts; templates & default values support these shortcuts with unintended consequences. A big chunk of the DevOps responsibility is about operations, to maintain the uptime of deployed solution.
All it took was a simple misconfiguration of the service to flood an, otherwise iron fortress. Auditing tools like Qualys or container deployment platforms like CCP (Cisco Container Platform), helps you with tools to identify weakness in the deployed solution. But it still takes manual intervention to review the results, apart from flagging the obvious holes. Solutions like Istio provide a mechanism to automate the traffic security that flows between the containers of a Micro services architecture, but they can only do so much(based on configuration).
The missing link is to have a security review of the solution, as part of the deployment process. and not just rely on the supporting tools. Once you have a baseline and that constitutes the initial heavy lifting, the subsequent iterations would have to concentrate only on the delta. Security is not a destination, it's a goal that is alive, as along as the solution is deployed.
