How to Improve DevOps Security

DevOps provides an environment with a great potential to improve security. Practices such as automation, collaboration, continuous testing, better feedback loops, and others provide an opportunity to integrate security as a component of the DevOps processes.

Usually, a wide range of security flaws and risks exist in the cloud environment, containers and other resources developers rely on when making applications. This includes the third-party code, tools, networks and other components of the development systems. Without proper tools, control and protection, these areas can lead to unstable and insecure apps. Some factors that increase vulnerabilities include;

• Wrong configurations and weakness in containers
• Insecure in-house and third-party code, privilege exposures, etc.
• Security flaws in the scripts or CI/CD tools
• Malicious insiders
• Insecure infrastructure and employee behavior.

In this article, sponsored by Downosaur, a tech company that provides services status notifications for teams, we will see why companies are not adopting DevOps security, and what they can do to change.

Why companies are not adopting security practices in DevOps

Although automating processes and integrating different teams are practices that help improve application security, most software companies are not utilizing them in their DevOps programs. Challenges include culture, security, and development teams work independently, lack of skills and tools, resistance to change, not prioritizing security, lack of automation and more.

Lagging security practices

While it is now faster to create applications, most security teams are unable to move at the same speed as the DevOps practices.

DevOps makes it easier to release applications faster, such that, what would traditionally take over a year and a half becomes possible in six or fewer weeks. However, the infrastructure, automation and other DevOps tools continue to alter the development environment in a way that makes the traditional approach to security ineffective.

Conflicting goals between security and developers

Although developers want to release the software to the market as fast as possible, the security teams may slow things down as they test the code and applications for vulnerabilities. And if they identify flaws during the tests, they will ask the developers to address them first, hence delaying the release further.

Not taking security seriously

Generally, organizations want to accelerate the processes of rolling out new applications. In so doing, they may want to skip some steps such as those that can identify security flaws in the code. In addition, they may avoid adding security to the code.

The developers may view adding security or any anything that slows down their development processes as a hindrance or obstacle to their ability to compete. Most often, this approach leads to shipping applications that are vulnerable or not fully tested on security issues.

Lack of skills

Building security into DevOps requires a new set of priorities, tools, and skills. Most often, the traditional security professionals may not have adequate skills to deal with the dynamic DevOps environment. For example, they may not be familiar with APIs, writing code and scripts, neither have the knowledge to automate and integrate traditional security tasks into the DevOps environment.

Using DevOps to facilitate security

More and more software companies are now viewing DevOps as an effective platform to enforce compliance and security. With a proper approach and security strategy, DevOps practices allow the teams to discover and address potential security issues and vulnerabilities faster than the traditional approaches.

Instead of adding security as an add-on, developers should integrate it into the entire development cycle, while monitoring and testing along the way and addressing any vulnerabilities before moving to the next process along the development chain. Effective measures that can help improve DevOps security include;

Changing the organization’s mindset and culture

It is essential to bring down the wall between the development, operations, and security. Changing from the traditional security practices is one of the main challenges when merging security with DevOps.

Companies should create a culture where everyone, including other departments, contributes to the security of the apps and processes. This avoids leaving the responsibility of securing the DevOps systems to the security department or professionals.

Ideally, the organizations should work hard in developing a culture whose by-product is security. This should;

• Promote cooperation between the development, operations and security teams.
• Make everyone responsible for security by shifting it from being exclusive to inclusive.
• Eliminate the traditional bureaucratic and communication barriers.
• Develop clear communication pathways between development, operations, and security teams.

Increase Investments security skills, tools, and processes

As the DevOps technology matures, potential threats increase and organizations must invest more to improve security. This includes availing the necessary tools, staff, skills and continuous training. The software companies need to empower everyone with the basic skills to handle security and its processes when developing the apps.

In addition, the management, developers, operators and the security teams must work as a team and support each other.

Integrate security in the application development processes

Unlike the traditional approach of looking at the security of the finished product, the best practice is to apply the security and testing from early stages and throughout the development cycle.

The best practice is to add security as you build the applications and then making it part of the system instead of as an add-on, or an afterthought. In addition, harden and test the CI/CD pipelines without relying so much on the developer-friendly defaults.

Enforce security at all levels, perform security needs assessment and automate most of the processes as much as possible. Automate security testing, updates and other repetitive tasks across the entire infrastructure.

Add automation

Automating most of the processes along the entire development pipeline increases the speed and efficiency. In addition to improving consistency and predictability, automation reduces the chances of human errors during manual processes.

The best practice is to add automation from the initial stages, when developing and testing code, configuring the infrastructure, during deployment and any other applicable process.

Common tasks to automate include continuous integration, continuous testing, continuous scanning and monitoring, scanning code, version control, orchestration, containerization as well as configuration management and deployment.

While automation will work to some extent, it is still necessary to use manual testing to catch some of the issues automated scripts misses out. Other limitations of automatic testing include the inability to test usability, and the fact that it is only applicable to predictable events.

Secure code and the development environment

To develop clean applications, it is critical to have a secure infrastructure. Ideally, this means protecting the cloud and on-premise environments, and ensuring that there is adequate protection against internal and external attacks.

The best practice is to secure the code, IDE, base images and anything else all the way to the complete application and operating environment.

Also, regularly evaluate and address vulnerabilities in trusted third-party code, cloud platforms, continuous integration components and other resources in the development processes.

Secure all data

Besides the infrastructure and applications, you must also secure the data at all points, as well as during rest and when in use.

Sensitive data types such as private information, credit card, or health care have greater risk and therefore requires specific security controls and compliance at all levels whether in storage, processing or transmission.

Perform static, dynamic and penetration testing

The static application security testing (SAST) examines application binaries, source as well as bytecode for security vulnerabilities. It helps to identify and mitigate security issues early in the development.

The dynamic application security test (DAST) examines the applications as it runs and can identify unusual behaviors that are indicative of security vulnerabilities.

Penetration testing involves simulating multiple real-world attacks, and what hackers can do to gain access to the application.
Establish internal controls and practices

• Only give the employees the rights and access they require to perform their tasks
• Advice employees to use smart passwords and avoid reusing old passwords or share a password or its variation across different accounts. In particular, enforce a policy where they must use secure passwords that combine letters, special characters, and numbers.
• Create and document processes that all should follow in securing the apps, environment, and data.
• Develop and promote security best practices
• Log access and events

Reduce the attack surface

Do not forget the legacy security practices such as a web application firewall and other protection measures.

• Secure and harden infrastructure and operating systems
• Reduce the attack surface on APIs and harden those that require exposure.
• Follow security best practices
• Use a web application firewall to block external threats
• Perform regular updates and patches to security tools

Conclusion

Incorporating security practices into your DevOps processes helps in creating an effective security layer for the environment and applications. This, in the long run, ensures security and compliance in a more proactive and efficient way.

Comments

[Max Shash]

Hi Amos,

Good article.
I now see that the Downosaur is down (seems like someone else bought their domain).
Any ideas if they are alive?

[Amos Kingatua Ndegwa]

Hello Max,
Thanks for the feedback.
I am not sure about what happened. Did a few things for them but haven't been in touch with them for some time.
Thanks,
Amos