What Is DevSecOps and How Logs Can Help

In May 2017, Edmodo, a social education platform with more than 78 million registered users, was hacked. The event proved to be just one of many recent data breaches that have affected some of the web’s most high profile names.

Foremost among these was Yahoo, which recently released information on an August 2013 breach of more than one billion records. During the event, hackers were able to generate fake cookies that allowed the attacker to unlock user accounts without actually needing the account’s credentials.

Cookie theft or impersonation is only one of the security issues faced by online software platforms. Unvalidated redirects or forwards can cause a loss of trust and affect traffic almost immediately. Even simple tampering with a mobile app’s content can have disastrous effects.

Hacking is one of the major threats to every website or mobile app, but most organizations that have not experienced security breaches tend to underestimate the importance of security review, validation, and verification. As a result, software protection testing is sometimes performed at a late stage of the release cycle — when its ability to have a genuine effect on the code is limited.

Rugged DevOps to the Rescue

Until recently, enterprise organizations utilized security teams to review code and test software before release. Smaller organizations that could not afford to maintain a dedicated team for security activities would usually hire a third-party vendor to provide those services. However, security validation is a bottleneck and a barrier to release — as well as many other pitfalls. The security engineer does not know the software, infrastructure, and code and therefore might certify the software as secure without finding all of the potential vulnerabilities.

Rugged DevOps is a methodology that takes the traditional view of security teams as an obstacle and turns it upside down by implementing security into all aspects of design and deployment. Instead of security playing the role of a traffic cop and slowing down the release, a Rugged DevOps approach makes security activities part of every stage of the release, helping the delivery process to proceed quickly and safely.

The first stage is the creation of secure code, and it’s here that DevSecOps kicks in. Just as the Agile Manifesto makes everyone responsible for software quality, DevSecOps makes everyone responsible for security and defines practical steps to accomplish this. While Rugged DevOps requires the creation of a detailed security plan before actual development begins, DevSecOps extends this and instructs R&D on how to implement a security code review process based on the security plan to make it easier to adjust the code while developing it. DevSecOps involves security experts in the planning and coding steps as well as when reviewing code and exposing developers to unexpected uses of their code so that they can understand how to improve its safety.

The next part of the R&D process that is addressed by this methodology is testing. Security verifications are usually done towards the end of the release, often resulting in stressful, last-minute code changes. DevSecOps addresses this by creating automated tests to verify the software’s protection against misuse or infiltration. The automation suite should be robust, stable, and comprehensive enough to approve or prevent release. In addition to verifying threat protection, tests must also produce detailed logs for debugging and reviewing how the code behaves when used incorrectly.

DevSecOps takes security one step further in the Continuous Delivery (CD) process. According to this approach, all security testing activities should be carried out automatically as part of the build process. Only when security tests are an integral part of the build can R&D continue to develop the application with the knowledge that every commit will be verified. In this manner, the dread of creating new loopholes or weak spots is reduced significantly.

DevSecOps also addresses the most precarious step of the CD process — the deployment. Deployment risks range from ad content configurations to network traffic encryption and must be safeguarded against after every deployment. DevSecOps requires an automatic procedure that configures all of the components and secures all access points and communications. Once this is in place, DevOps teams can feel comfortable ceaselessly updating the production environment. For additional confidence, every action done on the services should be audited and logged with the same structure and syntax as the logs are created in the testing environments.

Why Is Logging Important?

Log analysis is the next part of the process. From a security viewpoint, it is vital that DevOps engineers in charge of the production environment understand how to read and analyze logs. Yet DevOps teams usually lack the knowledge and ability to identify security breaches or hacking attempts from a log record. Having a log management tool capable of reading and parsing logs and distinguishing between permitted and unauthorized activities is crucial for both tracking each action within the system and creating confidence in the application and the DevSecOps process.

Production log analysis can rely on the information and knowledge gained during security testing in the QA environment to identify patterns of hacking activities. However, centralized logging must be enabled, and operations performed on multiple services should have an identical key to allow the tool this power to build and evaluate a relationship schema.

It’s Not That Easy

According to recent figures, high-performing IT teams engaged in DevSecOps work patterns spend approximately 50% less time remediating security issues because problems are fixed throughout the entire lifecycle. Yet both developers and security experts might find the DevSecOps transition inconvenient. Adam Jacob, the CTO of Chef—a DevOps automation platform—acknowledged in a recent podcast that, although embedding security testing directly into the software delivery process is ideal, actually accomplishing this is “a whole other ball game.”

As he explained, “If you can’t figure out how to manage that security posture the same way you manage the rest of the software development process, it’s really difficult to then tell a software developer that it’s their responsibility to ensure that that posture is good or bad … You can’t really ask them to understand the posture of what it’s going to be like when it’s deployed.”

Security engineers may find themselves outside their comfort zone when automating their expertise and skills but, more importantly, when challenged to identify holes and disruptions. On the other hand, developers faced with constant reviews and requirements to address vulnerabilities not affecting the software’s functionality might find the process redundant and consider it an overhead.

The following suggestions may aid in the smooth implementation of DevSecOps:

Working in a dynamic environment with an agile mindset is less familiar to security engineers than to R&D professionals. The process of implementing DevSecOps is continuous and requires gradual improvement. Security engineers should determine the minimal viable product and release on this basis.
Embedding security champions into dev/agile teams who will “advocate for ‘security as a feature'” will create visibility for both the features and their security requirements. This should also improve collaboration.
Establish boundaries and decide what needs to be enforced, then operationalize through automation systems to align with the DevOps pipeline mode. As manual intervention is slowly pushed out, use logs to record as much information as possible about every verification or configuration that is done. Later on, use a log analysis tool to identify similar actions in the production environments.
Address security defects once they are detected, just as other functionalities, usability, or performance issues are approached. Tone down the hysteria about security holes and work on rational remediation plans that can gradually make headway on security fixes.

Conclusion

The WannaCry ransomware cyber attack further heightened awareness of security and protection. Organizations throughout the software industry understand that, unless extreme measures are taken, the risk of having their software or servers compromised constantly increases. DevSecOps suggests a set of steps and standards to facilitate continuous delivery, eliminate risk, increase trust, and, most importantly, keep software and servers secure.