As businesses look to continue their transition into the cloud, an assessment of security needs and understanding of cloud native business ecosystems becomes essential. Novel, complex, and evolving threats require that businesses have elastic and observable application development, with solutions tailored to specific security needs.
Identifying individualized security requirements and the security team’s skill sets should be top of mind when selecting new software tools, with focal areas of consideration including the implementation readiness of identity access management, familiarity with container security, and current ability with security observability posture across the attack surface.
Cloud Native - What does it mean?
With traditional architectures primarily confined to on premises data-centers, cloud native computing is a radically different approach to enterprise IT. Rather than rely on locally installed software or forcing users to connect to on-site data servers via VPN, cloud native capitalizes on the cloud’s inherently agile nature.
Through its ability to host wide-scale application containerization, it equips developers with the ability to quickly deploy, manage, and observe the orchestration of applications across multiple servers. Building and running applications through cloud native services enables engineers to excel at scale, and harness the power of technologies such as Kubernetes, Docker, serverless functions, APIs, and Kaftka.
Alongside cloud tooling and services available from industry leading cloud providers, developers can accurately manage microservices and serverless functions - a panoramic ability unique to cloud native architecture.
The Impact of Security In Cloud Native Organizations
Cloud-Native applications are cost-effective, scalable, and accessible due to the fact that they are built within the cloud and therefore preemptively architected to run in public clouds such as AWS, Azure, and GCP. Eliminating hardware and software configurations found in non-native organizations allows developers to deliver novel services quickly and effectively (and at an unprecedented rate).
As the nature of a cloud native environment can be thought of as a new way of architecting applications through the break-down and reuse of services however, its rapid creation and destroyal of the containers that define its agility pose a subsequently significant security risk. Only through the appropriate securing of an organization's cloud native environment will it deliver the myriad of opportunity for application development sustainably and safely.
The shared responsibility model - Does your team understand it?
Having a comprehensive understanding of the shared responsibility model is crucial, as it has been discovered that by 2025, 90% of the organizations that fail to control public cloud use will inappropriately share sensitive data. An additional statistic published by Gartner found that through 2025, 99% of cloud security failures will be the customers fault.
As defined by AWS, the shared responsibility model contends that the customer assumes responsibility and management of the guest operating system (including updates and security patches), other associated application software as well as the configuration of the AWS provided security group firewall. As responsibilities vary depending on the services chosen, organizations must carefully consider the applicable laws and regulations of services they choose and the integration requirements of those services into their IT environment.
Image provided by AWS
Detailed above, AWS is responsible for the protection of infrastructure. This includes hardware, software, networking, and facilities that run AWS Cloud services.
The AWS Cloud services that a customer selects will determine the configuration requirements necessary to adequately fulfill their share of the responsibility model.
Identity Access Management
Identity Access Management (IAM) is defined as a framework of business processes, policies and technologies that facilitates the management of electronic or digital identities. Within identity access management are the benefits of single sign-on systems, two-factor authentication, multi-factor authentication, and privileged access management. Providing the ability to securely store identity and profile data as well as governance functions, identity access management ensures that only data that is necessary and relevant is shared.
Making sure the processes are in place to adequately monitor access points is imperative for a successful implementation of Identity Access Management, and a process your team should establish before adoption. The capabilities of the cloud are vast, with a nimble and agile nature streamlining the access to information and application utilization. However, with the cloud's capabilities also come the risks of vulnerabilities, and identity access management can significantly strengthen an organization's posture.
By automating tasks through Identity Access Management, organizations are granted granular access control and auditing of assets on premises and in the cloud. Assigning appropriate user permissions in SaaS and development tools can be the determining factor of how secure your team's infrastructure remains.
A continuous process, appropriately securing containers requires perpetual attention. By integrating container security into your organization's development process, automating it to remove the number of manual touch points, and extending implementation from within the maintenance and operation of the underlying infrastructure of your organization, a significant amount of risk mitigation can be obtained. Thinking of container security as something that has to be a continuous delivery with its own life cycle is imperative to the hardening of your organization's attack surfaces.
When the goal of cybersecurity is to ensure that whatever is built continuously works as intended, and only as intended, container security must be operative and dynamic.
Considering the novelty of Kubernetes, adopting a dedicated security solution is critical to appropriately protecting containerized workloads and services. Containers are built and destroyed on very short life-cycles within the developer environment, making the idea of "shifting left" and implementing security practices earlier in the development cycle obligatory in staying ahead of risk.
Does your organization have strong observability across the cloud?
The wider the observability an organization has of its cloud architecture, the more accurately and expediently identified performance problems can be traced and addressed. Having the ability to quickly remediate threats in your cloud ecosystem, developer environments, and business applications is a baseline standard required for the successful ongoing monitoring of an organization’s architecture, though the consistency in reporting across multiple surfaces has not always been available.
Observability is an evolved state of Application performance monitoring (APM), and is derived from an area of engineering concerned with automating control of a dynamic system called control theory - e.g, the flow of water through a pipe, or the speed of an automobile over inclines and declines - based on feedback from the system. If afforded to an organization, acute observability enables teams to discover and address ‘unknown unknowns’ (issues outside of exceptional conditions previously watched for), catch and resolve issues early in development (defined above as ‘shifting left’), scale observability automatically (telemetry can be gathered from the moment Kubernetes clusters are spun up and spun down through the specification of instrumentation and data aggregation), and enable automated remediation or self-healing application infrastructure.
Asking yourself if your team has strong observability - if any at all, along with members who possess the correct skillsets to implement and act on discoveries - can be the difference between an operational cloud undertaking and an exceptional one.