Security is often the first criterion considered by most decision makers in enterprises when they decide to adopt any new technology. The ability to deploy securely, then protect and react to security threats, is paramount to success. This has been true since the dawn of computer systems and will remain no different for the foreseeable future. Overall IT system security is compounded by the risk of losing business due to exposed, leaked, or mismanaged customer data. There are dozens of examples just in the past decade of businesses going under due to security events.

The once-dominant internet search giant Yahoo, while in acquisition discussions with Verizon, announced it had been the victim of an attack. The hack exposed the real names, email addresses, dates of birth, and telephone numbers of 500 million users in 2014. This was surpassed months later by another announcement from Yahoo of a security event that compromised 1 billion accounts and passwords. These events knocked an estimated $350 million off the acquisition price of Yahoo by Verizon.

There are dozens of examples similar to Yahoo, where improper management, inadequate response, and poor architecture decisions have led to equally bad outcomes for companies. In 2014, eBay had 145 million user accounts compromised, Heartland Payment Systems in 2008 had 134 million users' credit cards stolen, Target in 2013 had up to 110 million customers' credit/debit card and contact info stolen—and the list goes on. Each security breach costs these companies millions in fines, broken consumer trust, and an untold amount of lost business revenue.

We know security is an important element of any IT system, so why and how did these companies fail? They certainly did not lack the resources, manpower, or willpower to get it done. The answer to this question leads us to cloud native security methodology.

In the pre-cloud world, IT assets were housed in a centrally managed, on-premises location. In the best of circumstances, physical access to these data centers was controlled and monitored (often lax enforcement would set in). In the worst of cases, the compute resources were dispersed across multiple locations, with poor tracking and monitoring of physical assets. Inconsistent hardware, poor access control, and deficient overhead management would lead to a weak security posture.

The general approach to security is to insulate these resources with a hard outer shell. Maintaining the security boundary was tantamount to having secured the entire IT landscape. It disregards threats that could arise from the inside, or what to do with a threat once it has penetrated this shell. This shell is oftentimes a firewall placed at a critical network junction, where all traffic could be monitored. IDS/IPS (Intrusion Detection Systems and Intrusion Protection Systems respectively) are deployed in similar fashion. Once a threat can bypass the secured network exchange point, the entire stack running behind the firewall becomes an attack surface. There is very little to stop an attacker from exploiting vulnerabilities once inside the protected edge. Furthermore, there is very little protection from threats emerging from within the protect shell:

This outdated security posture often comes hand-in-hand with an outdated security operations and organization model. Security teams report to different managers and are aligned to separate goals than the development or infrastructure teams. The security team is usually not aligned to the end business goals (capturing more market share, increasing revenue, decreasing infra costs, and so on)—they're perceived and operate as inhibitors to development and innovation.

Oftentimes this perception is not far from reality, but at no fault of the security engineers. The organizational model for how security engineers work with developers and infrastructure architects creates this friction. Instead of being viewed as partners working towards the same goal, adversarial zero-sum relationships become the norm. It's become du jour for architects and developers to gripe about the lack of agility injected into the sprint process by security engineers. The fail fast and innovate mentality of the developers runs headlong into the control change and review mentality of the security organization.