Cloud has Changed Teams, Security Should Change Teams, Too

The cloud security story is a good one. The major public cloud providers have successfully created world-class implementations of highly scalable IT components. Centralization of security controls within cloud services gives small and medium businesses flexible access to a standard of security they usually wouldn't be able to adopt.

Complicated layers of logical security controls can be implemented at the push of a button thanks to shared interfaces, on-demand resources, and service templates.

Cloud providers are even getting better at providing secure-by-default configurations. On the other hand, one of the most important misconceptions we still see is that security comes ‘for free’ in the cloud. Realistically, there are still factors that are the responsibility of cloud customers.

Despite cloud:
Security still has implementation costs.

Work is required to understand the value of a change, the vulnerabilities applicable to the change, and the best options for mitigating risk. Work is also required to develop any necessary mitigations. 

Security has consumption cost.

For example, components that scan payloads for malicious indicators, transfer and store audit logs, or support service redundancy all increase the cloud resource costs of the service and need to be accounted for. 

Security is still your responsibility.

While cloud services allow the offloading and outsourcing of certain security tasks from the cloud customer to the cloud provider, the accountability for ensuring secure service fulfillment always rests with the cloud customer. It is the customer's responsibility to understand all applicable security requirements and verify that they are supported by their cloud services provider. 

Failure to understand these costs and how to efficiently plan for them will often result in control gaps, and each outstanding gap increases the risk of a costly data breach. Today's attackers are also benefitting from the scale and low-cost toolsets. It's no longer reasonable to assume that an internet-facing service can exist unchecked for any period of time. Today's products must be secure prior to interfacing with the outside world.

We need cost-efficient security during initial development. As the saying goes, an ounce of prevention is worth a pound of cure.

The next question is how we integrate cost-effective security practices into software development, so let's look at team makeup, implementation sequence, and release procedures.  

For organizations to meet the shifting needs of their customers, development teams must continuously change their products, features, and capabilities. A very common approach that aligns with cloud is that of a cross-functional team using an agile workflow supported by some amount of DevOps skillset and release automation. New changes get delivered to production more often than in the past: anywhere from once every few weeks to several times a day.

In the past, security has been built into product development as friction and obstruction. For example: 'you can't release this thing you built until you change x and y.' This approach by its nature can be misaligned and even adversarial with the flow of value.

If security is seen as oppositional to value, it risks being skipped or ignored.  The fact is that service value is usually measured over time, so any given functionality can only generate its expected value if it continues to operate over time. We need a solution rooted in the idea that the goal of security is to keep services delivering value as they were intended to and to prevent incidents that would impact the continuous value delivery capabilities of the organization. 

If we agree that functionality must be secure before it hits production, security is essential to value protection, and cloud security is not a given, how do we efficiently meet security objectives when the rate of change in our products keeps increasing?  It turns out that development teams pay close attention to the way requirements are communicated.

We must communicate security requirements with language and priority equivalent to their effect on service value. Service fulfillment can be quantified with key performance indicators, and so should service protection. 

This is all leading up to the last piece of the puzzle, and the part that is so critical with the cloud. Your cloud provider manages their procedural security scope, and you manage yours. Using cloud resources instead of on-premise ones reduces your procedural security responsibility but does not affect your need for security expertise.

Your requirements don’t change because of service composition.

Value-oriented product teams still need the same skillsets covering security, infrastructure, and data handling. They also need the ability to interpret cloud APIs and verify implementation without being able to check under the hood. Teams will need these skills at two critical points: the translation of security objectives into chosen technology, and the implementation of security controls into product components. 

Include security professionals on development teams.

Security Architects present a specialized perspective that is needed at the product level and grounded in the language of security.

Where the Solutions Architect is primarily concerned with service fulfillment, the Security Architect represents service confidentiality, integrity, and availability. They have the knowledge to guide technical implementation to a state where it is not just resilient and fault-tolerant, but auditable and demonstrably compliant. They work with the team on a regular basis and can clarify requirements in real-time.  

Software developers need deeper security knowledge.

Use of CI/CD pipelines results in less and less time between a line of code being written and that code being executed in a live service. We know that systems should be put in place to automatically scan code and screen for common vulnerabilities, applications and networks should be penetration tested, and running systems should be monitored for indicators of compromise. However, the software developer is still responsible for building security into the product, writing the code securely, and configuring cloud resources to meet security requirements. We must invest in the security competency of software developers to fully integrate security in the software development lifecycle. 

Cloud has caused or coincided with several changes in the way software products are delivered, and the threats facing those products are consistently rising. Successfully delivering product value over time depends on our ability to understand how costs, teams, architecture, and procedures have changed in the cloud.

We need people with the right expertise sharing common language in the value stream, and every stage in a product’s lifecycle must consider security to achieve product goals.