Integrating Security with DevOps on Oracle Cloud (Part 1 of 2)

 Sanjay Basu

 

Modern development organizations are increasingly using cloud computing attributes like elasticity, API-driven infrastructure as code (IaC), and native immutability for their DevOps and agile development practices. Through DevOps, organizations are seeing these outcomes:

• Speed up software development and systems deployment cycles
• Reduce the time and cost to transform an idea into a finished product
• Unify agile software development and operations, removing barriers to an integrated and iterative process
• Industrialize the tools and techniques of development and operations with automation at the core

In the many engagements in which we've helped customers migrate and develop applications in Oracle Cloud, I have found that security is often a critical missing element in customer DevOps processes. In these cases, security is treated like a siloed and gated activity which, when missed or applied too late, leads to missed project deadlines and vulnerable systems.

In this series of blog posts, I describe how you can help weave security into every aspect and phase of DevOps processes. First, let's focus on some key DevOps components.

Continuous Integration

Continuous integration (CI) is the process for quickly integrating new code into an existing software product. Activities are driven by workflows to implement, test, and merge features. A small set of features is added in the branch of the main source code. Those features are submitted for review and automated functional and unit tests. After successful testing, the code is merged with the main branch in the repository for deployment.

Continuous Delivery

Continuous delivery (CD) is the process of using automation to deploy software into services that customers use. In the CD process, one step triggers the next. For example, merging code changes into the CI pipeline triggers the deployment of the updated software package on a new infrastructure. A successful deployment starts an automated testing cycle. When testing is complete, the infrastructure is promoted to a new staging environment where user acceptance testing (UAT) occurs. Successful UAT triggers the replication of this environment into production, and the staging and production infrastructures are destroyed.

Infrastructure as Code

The CD process is possible because of the automation of cloud IaaS attributes. Oracle Cloud Infrastructure exposes all the services to operators (and developers) through well-defined APIs and code. Oracle Cloud Infrastructure services also natively support open source provisioning tools like Terraform and Ansible. These tools help enable customer DevOps teams to programmatically construct immutable infrastructures by using code. This process makes the creation and destruction of environments through CI/CD pipelines not only possible programmatically but also reduces the number of errors compared to when it is done manually.

Putting Security in DevOps (Continuous Security)

CI, CD, and IaC are integrated components of DevOps, whereas security teams are traditionally outside of DevOps, often not aligned with the software development teams. Security teams primarily interact with the operations teams, but that interaction can be periodic rather than continuous. While the operators focus on up time and response times, the security engineers generally focus on vulnerabilities and associated risks that might lead to compliance issues. Most of the time, the security teams react to incidents and various cyberthreats. On the surface, it’s difficult to integrate security with DevOps processes.

To successfully implement DevOps, developers and operators should work on the same team for the same development project. Similarly, to help secure DevOps, the security team should work closely with the developers and operators so that there is no barrier. To accomplish this, use automation, which is proving to be a great dissolver of silos. To make security an integral part of DevOps (as in DevSecOps or SecDevOps), the security team needs to build and test controls iteratively, in step with the new features being developed, integrated, or deployed using the CI/CD pipeline.

This cyclical process of running security tests throughout the lifecycle of the application is also referred to as a continuous security process.

Pillars of Continuous Security

Continuous security has three major pillars:

• Test-driven security (TDS): Test-driven security (TDS): As new features are added, the security posture must be continually refined and updated. New or modified security controls might be added (or sometimes removed). These controls must be continually tested during the development and deployment cycles using automated security test suites (commercial or in-house). For more information, read about how to integrate Jenkins with Oracle Cloud services for automated testing.
• Automated responses to threats and events: Cloud native applications must be built for resiliency. Because even carefully designed and tested software can contain security vulnerabilities, a robust security monitoring system should be in place to identify any intrusions and infections in real time. Automated incident responses should be put in place to protect services. These services are generally provided through a Cloud Security Operations Center (cSOC). As new immutable infrastructure is built, the cSOC monitors the environment as it changes. For more information, read about how to build and operate a cSOC on Oracle Cloud.
• Risk assessment and security controls updates: As new features are released in production using the CI/CD pipeline, security compliance checkers and application vulnerability assessment systems should measure and record any new risk exposure. Risks that are identified during new feature integration require revisiting the security controls framework, which should be modified to mitigate those risks. Oracle Cloud Access Security Broker (CASB) provides an exhaustive list of cloud security controls and risk assessment services based on automated machine learning.

What's Next

In this post, I covered the basics: the overall approach to CI, CD, and IaC, and then building security into DevOps by moving toward continuous security, which involves test-driven security, incident detection and response, and risk assessment.

In the next four parts, I'll explore the following topics:

• Part 2 explores how applications can be secured using Oracle Cloud services such as Web Application Firewall (WAF), CASB, and Oracle Identity Cloud Service, along with Oracle partner ISV software and services.
• Part 3 focuses on securing IaC. It covers how to achieve deployment security (Terraform and Ansible) and network access and entry point security; how to test security lists and add a bastion host; and how to secure database access by using table encryption, roles and permissions, and asserting permissions through a deployer.
• Part 4 is all about securing transmission. It covers various cryptography technologies pertaining to PKI and SSL/TLS (TLS handshake, PFS); how to enable HTTPS and obtain certificates; and best practices for using certificates on LBaaS, including testing TLS and enabling Strict Transport Security and Public Key Pinning.
• Part 5 covers the secure delivery pipeline, including best practices for managing access controls and permissions for GitHub, the Oracle Cloud Infrastructure Registry, and Oracle Cloud Infrastructure public APIs. It also covers Oracle Cloud access controls—managing permissions by using instance principals and compartment policies, and best practices for distributing secrets.

Resources and Acknowledgements

For more information, see the Oracle Cloud Infrastructure documentation.

I’d like to extend a sincere thanks to Johnnie Konstantas for technical review.