Application Security

Overview

DevSecOps enforces the idea that every employee and team is responsible for security, and that decisions need to be reached efficiently and put into action without sacrificing security. Getting new code out to production faster is a goal that often drives new business, however in today’s world, that goal needs to be balanced with addressing security.

Read More …

DevSecOps is being adopted and introduced within the software development cycle to bring more stability for the application even in the longer run. It’s like integrating IT operations, development, and security under a ‘single automation’ strategy. The idea is to not only ensure security all through the application development, but also bring down the time and accelerate the development cycle.

Most of the times Security becomes a roadblock for rapid application development and any kind of IT innovation. With DevSecOps the equation changes and the test code is brought under scrutiny for all security checks and validations. Sometimes security and compliance monitoring tools are not enough for security testing purposes. That’s when DevSecOps comes in to accelerate and foolproof the strategy.

Read Less …

No delay in fixing security

Reduces vulnerabilities

Continuous improvement, Continuous Security

Top Challenges

Policy Coverage

First and foremost, you must confirm that the tool actually covers the risks you need it to cover. Many products have surprising shortcomings in this area. See the OWASP Benchmark Project for help.

Accuracy

Accuracy (eliminating both false positives and false negatives) is critical. Inaccuracy means humans have to fix results which will destroy your pipeline. You should carefully test your tools to be sure they accurately verify what you need.

Speed

You need to test whether tools are fast enough to work as a part of your DevSecOps pipeline. That may be microseconds, seconds, or minutes…but probably not hours and certainly not days.

Scale

Consider the size of your application portfolio and whether the tools you select are capable of operating continuously, in parallel, across that entire portfolio. Be sure to factor in the number of people you will need to make that work.

Process Fit

You should verify that the tools are useful without complex installation and process. When well-meaning security folks buy tools for development and operations teams it can cause friction if they aren’t compatible with their technology stack or workflow. Engage the actual users in the evaluation process and conduct pilots to confirm they will be easy to install and use.

Integrations

Verify that the tool integrates with the tools that people in your DevOps tool chain are already using. Look for well-documented, supported REST APIs and SDKs in a variety of languages, IDE plugins, webhook support, ChatOps integrations like HipChat and Slack, notifications with PagerDuty and VictorOps, and SIEM integrations like Splunk.

Core practices

DevSecOps takes a very agile approach to security, breaking down massive security tasks into incremental improvements that are performed as normal development tasks. These small batches of work include continuous verification, so that security builds over time instead of repeatedly starting over from scratch.

Once we’ve identified the next security challenge, our normal engineering process can execute on the improvement. In this section, we explore four core practices to any DevSecOps initiative. Of course, your DevSecOps process might be considerably more complex. See the next section for more ideas, or add your own practices to this basic cycle.

Why should you always focus on your most critical security challenge? Generally, working on anything else won’t change your security posture very much. It doesn’t help to close the attic window when the garage and front door are wide open. In DevSecOps, we get the work flowing by creating small batch sizes. So, in most cases, we want to work on the most critical security challenge to our enterprise first. Still, don’t be afraid to choose a partial measure or a tiny improvement to your most critical challenge. Working in small increments makes sure we stay on track.

When deciding what to work on next, the team looks at all the potential security “work” available and makes it visible. The team might add new features, pay down some technical debt, make an architectural improvement, fix defects/vulnerabilities, or do something to improve the team’s tools or practices to improve quality, security, or productivity.

It’s important that the team use their threat model and security architecture to make an informed decision about the next most critical security challenge. What is the cost to the company of certain kinds of attack? What is the cost of implementing preventive measures for those attacks? Try to use data from both internal and external sources to figure out the next thing to do that will most effectively reduce risk.

Once you’ve decided on a security challenge to tackle, you’ll need to choose a defense strategy. A defense strategy isn’t a single security mechanism or product. A defense strategy can combine technical security mechanisms, secure coding practices, procedural controls, supporting processes, training, background checks, and more. We are using the term “defense strategy” broadly to include anything that you rely on to prevent a breach. Your defense strategy for a particular challenge can (and probably should) comprise one or more primary defenses and a set of supporting defenses as well.

Your strategy is right when you can easily answer with confidence when anyone asks, “How do you protect against X?” Having a clear, concise, defensible answer to this kind of question can not only provide an easy path to compliance but can also provide business advantage over competitors.

Your defense strategy doesn’t have to be perfect from the very start. It’s far better to start with a basic defense and evolve it over time. In fact, after you implement a basic defense, you may choose to work on another more pressing threat. The key to DevSecOps is to continuously reprioritize based on the threat and your existing defenses. The ability to respond quickly is critical for a world of continuously changing threats.

The work of actually implementing the security defense shouldn’t be any different than any other feature, and should to the maximum extent possible, be delivered as code or configuration with everything in source control. Managing security in this way makes it possible to test and redeploy at any time, ensuring that defenses are in place, working correctly, and properly configured.

A key part of DevSecOps is ensuring that the defense strategies have been properly implemented, configured, and operated. Security testing is the way to verify that your actual security controls match your intended defenses. In DevSecOps, we focus on automating those tests by “turning security into code,” so that we can run them frequently without requiring humans, particularly security experts, in the critical path.

Below is a DevSecOps security testing funnel to help you choose a security verification technique for the particular security challenge we are working on. This may seem obvious, but don’t blindly rely on the wrong tool. Take a minute to select the simplest, fastest, most accurate way to check that your defense implementation is correct, complete, and configured.

For example, testing for proper clickjacking protection is simple if you simply examine HTTP responses for the proper security headers. But it would be very difficult to verify this by looking at the source code, as there are so many ways that this might be accomplished.

DevSecOps organizations recognize that you can never test yourself secure, so they adopt a balanced approach that focuses on minimizing vulnerabilities during development, and on identifying and preventing vulnerabilities from being exploited in production. While these two activities have traditionally been separate, DevOps has brought them together and DevSecOps projects support the full software lifecycle.