Chapter 1. Digital Transformation
Technology is reshaping practically every industry vertical, and businesses need to adapt or they will be left behind. This tidal wave affects all businesses, requiring them to perform a digital transformation to face the new times.
Digital transformation typically includes two main parts:
-
Becoming a technology company if you’re not one already
-
Accelerating delivery of technology solutions, notably via DevOps and the cloud
The term cloud native is used to describe organizations, applications, and development processes designed for this new reality and its new platforms.
Let’s dive deeper into what each of these bullets means.
Becoming a Technology Company
For certain industries, digital transformation requires changing how they transact with customers, turning physical goods into digital ones. Banks and shops are moving from physical branches to online portals and ecommerce, passengers hail taxis through mobile apps instead of hand waving or calling a taxi station, and media is increasingly produced through crowdsourcing and consumed over the internet instead of via cable TV.
Such massive changes also require rethinking how to secure the org (organization) and adjust priorities. As more customer data and business transactions shift online, digital disruptions or breaches become more costly, and therefore the importance of cybersecurity grows. To address the change, security budgets must allow for a bigger spend on cybersecurity, security teams need more cyber-related skills, and even the chief security officer (CSO) may be required to master different skills or be placed elsewhere in the org.
Every business aspires to become “a technology company that does X,” which in turn means adopting a technology-focused security program.
Accelerating Technology Delivery
The second focus of digital transformation is speed. Although responding faster to market needs has always been a powerful edge in business, the pace has never been quicker. Thanks to technology and process innovations, businesses have gone from annual releases to shipping multiple times a day. Users have grown to expect such constant updates, and businesses that fail to adapt will struggle financially.
This speed is made possible by two primary forces: the cloud and DevOps. Each term represents a family of technologies and practices, respectively, and has a significant impact on security. Let’s take a moment to define them.
The Cloud
The cloud represents a series of technological developments that turned hardware into APIs, letting developers access and control physical resources purely with software. The shift to software introduces dramatic ease and flexibility and is best exemplified by elastic compute, pioneered by the Amazon Web Services (AWS) Elastic Compute Cloud (EC2) service. EC2 allows users to rent a virtual machine (VM) by the hour and spin it up or down with a simple API call. This allows a service to adapt its capacity dynamically, using little compute when demand is low, incurring low costs, while automatically scaling up to handle surges in demand and avoid losing business.
Elastic compute and the broader family of cloud technologies combine to give developers full control over rich infrastructure controls. These include additional APIs to control other infrastructure components, such as storage and network access; developer-oriented replacements to IT tooling, such as containers and Infrastructure-as-Code (IaC) solutions;1 and new technology paradigms that build on this elasticity, such as serverless.
The cloud unlocked the opportunity for any company to provide operational excellence previously reserved to a select few and do so with dramatically lower costs. However, for a company to tap into the power of the cloud, it also has to change its IT processes, which is where DevOps comes in.
DevOps
DevOps changed the way software is built and maintained. It is predicated on independent development teams, who are able to own the application end to end. The most immediate manifestation of that is having developers also operate the application, dubbed “you build it, you run it,” hence the name DevOps. However, the term has grown to encompass a broader autonomy for development teams, including empowerment to make more business decisions, choose the underlying technologies they use, and more.
This autonomy powers speed, notably in the form of continuous delivery (CD). Instead of shipping updates in large, infrequent batches, CD means shipping small improvements regularly, often multiple times a day. Each incremental step is verified with automated tests to avoid delays, and observability tools to flag problems in production as soon as they happen.
Such constant updates allow the business to adapt to customer needs faster, which improves its commercial performance. This continuous flow of faster delivery leading to faster market adaptation is most commonly portrayed as an infinity loop, as shown in Figure 1-1, replacing older waterfall, left-to-right models.
Figure 1-1. A continuous DevOps practice
Cloud Native
Organizations that started building technology in this DevOps and cloud surrounding are often referred to as cloud native companies. Their developers embrace on-call responsibilities, monitoring dashboards regularly and being paged if the service goes down, whereas their ops teams focus on building platforms that make it easier to build operable software.
Such software engineering organizations are often called cloud native development teams because they are designed—across people, process, and technology—to leverage the cloud to the max. The term has grown to also encompass organizations that modernize their practices and adopt such cloud native practices, on both public and private cloud platforms.
Similarly, applications built using cloud native development are referred to as cloud native apps. This isn’t just a historical honorific, but rather, a description of how these applications are maintained. It implies that these apps are constantly updated, can scale to large volumes, and leverage infrastructure automation to provide a better customer experience.
Organizationally, it’s important to understand that cloud native applications have a bigger scope than their predecessors had. Older applications are made up mostly of code and open source libraries and rely on a central IT team to provide them with infrastructure, such as hardware, VMs, network access, databases, and more.
Cloud native apps, by contrast, include such underlying infrastructure as part of their scope. Hardware and VMs are replaced by containers and managed through Dockerfiles stored in the source code’s repository;2 network configuration is specified in IaC files such as Terraform and Kubernetes configurations; and databases or similar supporting apps are provided as services in the cloud platform itself, and managed by the application team itself.
This change in the scope of the application is shown in Figure 1-2, using a somewhat arbitrary before-and-after view of pre-cloud and cloud native apps.
Figure 1-2. Cloud native applications include a much broader scope
Security and Cloud Native Development
The security industry, unfortunately, hasn’t kept up with this market shift. In the vast majority of organizations, security teams still cling to their past methodologies. They continue to employ minimally changed practices, despite dramatic changes to those they help protect.
Despite DevOps preaching end-to-end ownership by independent teams, security is typically owned by a separate team. At best, this split causes bottlenecks as application teams wait for a central team to assess an app or review findings. At worst, it leads to serious security flaws being overlooked because development teams lack tools and knowledge in security, and security teams lack knowledge of the app.
Infrastructure security continues to rely on the same IT-oriented practices, ignoring the fact that these layers became part of the broader cloud native application scope and are managed by developers. These practices again cause delays and security oversights, with neither development teams nor IT teams being set up to address the risk properly.
These approaches are doomed to failure because they go against the change the business strives to achieve.
Conclusion
Digital transformation is aptly named; it transforms organizations, changing their business trajectory to be technology focused, with the tools and practices required to succeed. This change is far reaching, affecting anything from org structures and business incentives to development methodologies and technology stacks.
Cloud native applications are designed to thrive in this new reality. They rely on independent teams, able to deliver customer value end to end. They use DevOps methodologies and cloud technologies to empower these teams to succeed. Unfortunately, security functions haven’t kept up with this change and are continuing to operate largely the same as before, making them ineffective and a burden on the business.
To secure cloud native applications successfully, security practices need to undergo a transformation that matches the one that development took on. We have to embrace a dev-first, Cloud Native Application Security approach and anchor our practices to this new organizational reality.
In the next two chapters, we’ll dive deeper into what dev-first security and Cloud Native Application Security mean, and how you can successfully implement them in your organization.
1 Containers are lightweight packaging of operating system and files, offering a type of virtual machine but smaller and lighter, allowing better agility and speed. IaC solutions are tools that define infrastructure in code or declarative files, often stored in repos as part of the app, and can automatically apply those definitions on an infra platform.
2 Dockerfile is the most common way to define what a container should hold. These are human editable files, typically managed as source code. Running a build command on a Docker image creates a container image.