Focus on enterprise security with background in IAM & cloud security
This article is part of the Enterprise Cloud Security Series with Part I - Introduction which introduces the space and how it differs from on-premise security. Part II - Foundation covers the security consideration for building the cloud foundation.
This article focuses on building security in the application development process.
The security of application can, at a high level, be classified into the following:
Developing a secure application requires that the application is designed and developed to be secure on a secure development platform (Reflections on Trusting Trust).
CNCF has done a great job putting together a security white paper based on the NIST Application Security Container Guide, Center for Internet Security (CIS), NIST Security Strategies for Micro-service, and OpenSCAP. It covers the typical lifecycle of development, distribution, deployment, and runtime of applications. Due to its focus on cloud-native development, it is a bit light on some aspects like unique considerations for securing SaaS and PaaS services.
The overall approach of DevOps is to ensure that security is achieved as the following types of artifacts flow through the process.
As part of the DevOps, the following stages form the part of the process
Across these stages, the various aspects of security must be monitored and addressed to ensure that the application is “secure-by-default”. This “shift-left” approach to application security can reduce the time, effort, and cost of fixing these security issues during runtime. The following aspects of security are typically addressed as part of DevOps processes.
Security of the DevOps platform consists of securing all the technical components, enterprise processes with the idea that resistance to developers’ flow increases as the application moves from development to production. Each enterprise has to find the right balance of the developer’s freedom with security and operational controls needed to ensure business objectives. A sample CI/CD flow is shown below:
DevOps consists of different components that need to be secured. Apply the V.L.A.D.R. criteria to structure the approach below.
Depending on the delivery model (IaaS, PaaS, or SaaS) and applicable shared responsibility, the enterprise may be responsible for managing the basic platform security aspects like technology vulnerabilities, logging, and resiliency. Code repository poses a unique set of security challenges like process vulnerabilities, access, and data which should be considered appropriately.
The code repository is a type of database since it contains business and trade secrets, algorithms that can result in a loss if exposed. Keeping that in mind, code repositories should be handled similarly to data within the enterprise. This would typically involve separating the code repository based on sensitivity. Organization policies to secure data at rest by encryption with organization-managed keys may mean that SaaS code repository can not be used for sensitive code.
Access to the code repository forms another important part of the process. Strong controls regarding user’s access should be adequately be supplemented by control over identities (e.g., API keys) and access of scripts and other automation processes (e.g., automatic key rotation, service identity for authentication). It is important to ensure that API keys and similar tokens have the same level of access control as user/service accounts (e.g., SAML authentication may enforce device authentication, which API keys may miss). All the access should be based on the principle of least privilege with, where possible, the use of UEBA (User & Entity Behavior Analysis) to continuously fine-tune the access and with periodic access reviews. Additional network access control may be required to be put in place for sensitive repositories to reduce the attack surface.
Code repository in most of the cases also stores other aspects of the DevOps (e.g., CI/CD pipeline definition, application configuration, SAST/DAST configuration, vulnerability exceptions), which can become a source of process vulnerabilities. It is important to ensure that appropriate pre-commit hooks; scanning processes are in place to detect changes to CI/CD pipeline that circumvent enterprise processes, shared secrets/API keys/private certificates in the code base, ignore false-positive vulnerability without exception, and so on. The enterprise should review the developers’ toolsets and use-cases to identify these process vulnerabilities and deploy controls to address them.
Besides basic platform security aspects like technology vulnerabilities, logging, and resiliency that enterprise may be responsible for depending on the delivery model and corresponding shared responsibility, registry-specific process vulnerabilities and access model along with data continue to be the focus.
Depending on the degree of control in place, applications may not have access to a public repository during the development and distribution phase. The repository may operate as a proxy for external dependencies like libraries, VM Images, container images, and tool plugins (e.g., approved terraform providers). Moreover, additional controls may be in place to scan the external dependencies and generated artifacts for vulnerabilities, sensitive information.
Access to the registry is another aspect that plays an important role. This access can be of significant importance when the repository operates as a proxy to public repositories. The ability to add or remove the external repository allowed can have a significant impact.
Most registries also support the ability to sign and encrypt the artifacts, which provide data-level security.
CI/CD automation platform provides a way to execute the build process and deploy the artifacts. This platform needs to ensure that the process being executed is aligned with enterprise policies (e.g., the application should not have critical severity vulnerability before deployment in production) and deployment is being with the least privilege access. In addition to that, the build and packaging tools should be from trusted sources and publishers (including extensions like terraform provider plugins) to ensure that artifacts being generated are not compromised during the build process. Due to the involvement of secrets/keys, it is important that automation is executed on the platform with limited accessibility and with an adequate level of encryption of data at rest and in motion.
Furthermore, adequate environment hygiene (e.g., delete all the files after build, encrypt and store state files using BYOK on an alternate storage system) should be maintained during and after execution of the build and deployment process to ensure that details about the application, including secrets/service account passwords are not present on the file system after the CI/CD pipeline has been executed.
Adding security to development and operational processes in any enterprise can be a significant daunting task further exacerbated by the changes in culture within most enterprises. Maintaining this balance between developer’s choice and enterprise security posture can be a significant challenge with the rollout of DevOps within organizations.
Also published at Medium's subdomain.
Create your free account to unlock your custom reading experience.