Rome Wasn’t Built in a Day…and Neither is Your SecDevOps

As digital transformation has accelerated in the last decade, software development strategy has undergone it’s greatest transformation since software development became commercialized. DevOps emerged to meet market needs faster, but then DevOps teams found that security moved too slow to be integrated into their modern development pipelines. However, digitalization also makes cybersecurity more important (and more complicated) than ever, which has left Security and Development teams at odds as they try to work together.

The misalignment between development and cybersecurity teams leads to missed business opportunities, as new capabilities are delayed in reaching the market. In some cases, the pressure to close the gap has caused increased vulnerability, as development teams bend rules to work around security policies and standards.” (McKinsey, Cybersecurity: Linchpin of the Digital Enterprise, 2019)

Traditionally, security checkpoints stood between each point in the process to produce and release a finished product. And while in a waterfall environment, there was time to complete these without disrupting the workflow, in modern DevOps pipelines — with 67% of companies releasing weekly or more frequently- teams are now asked to make a tradeoff between speed and security.

To balance this, companies are now turning to SecDevOps to move security away from largely manual gatekeeping and compliance checkboxes that impede development velocity, shifting to looking at the holistic application security process and leveraging automation to integrate it into the SDLC. When they take this process based approached supported by tools — rather than driven by the tools and their limitations — they get hard ROI through not just producing more secure tools, but decreasing the cost associated with security that often blindly ends up in the non-functional requirements bucket.

However, integration of Application Security processes into DevOps doesn’t happen overnight. It takes time and the willingness to overhaul company culture to support the necessary changes. People must be excited, well trained, and appropriately managed so they can work efficiently within the new system, processes must be adapted, and a toolkit must be built. Rome wasn’t built in a day. SecDevOps isn’t, either.

SecDevOps: Not Just a Tool, a Way to Operate

While there is debate about the different terms associated with SecDevOps, DevSecOps, and DevOpsSec,, the reality is they’re just steps along the evolution to SecDevOps, starting with the status quo for 90% of companies, which is DevOps + Security, where security doesn’t occur until code is already in production, leading companies to play “AppSec Roulette” never knowing how much it will cost or how long it will take to fix the issues.

By shifting implementation of security practices earlier in the process so they’re present from the very beginning stages of development even before the first-line of code is written. This is not just about testing earlier — but providing information at every step to inform, educate, and govern. This means eliminating the low hanging fruit of errors that could be prevented (like misconfigurations) to understanding which vulnerabilities are the most critical on an individual project, version, and environment basis, and setting deadlines for the resolution of vulnerabilities. It must be a holistic approach to embedding security in every step of the development lifecycle. As Gartner notes, “IDE plug-ins are not a substitute .however, in the spirit of DevSecOps, they catch simple errors earlier on.”

It’s important to note that most development teams want to take a more active role in security. They’ve already seen the benefits of proactive management of operations in their workflow — hence the birth of DevOps — and the integration of Application Security is no different. It’s easier, more practical, and less costly to prevent or shore up holes in security during development than it is to wind up scrapping large bodies of code or repairing after the fact — especially once you’ve added additional layers of complexity created by frequent code releases.

The transition to DevOps wasn’t such a stretch; Dev and Ops speak essentially the same language. It’s like American English and English in the UK: different, but speakers of both can get the jist of what one another are saying. The transition to SecDevOps is more complicated. The development team is speaking American English and the security team is speaking the language of the uncontacted Sentinelese tribe. So, first and foremost, SecDevOps is a cultural transition. Each division must learn a common language so that effective communication can occur.

Movin’ on up to SecDevOps

As organizations evaluate where they stand on the SecDevOps maturity curve they should evaluate on three parameters: People, Process, and Tools. You’ll notice people come first; that’s because without an effective team, the processes and tools implemented to weave security into DevOps are irrelevant. It’s important to keep in mind that you can be in one phase of the maturity model in one area and a completely different phase in another.

Whether you’re an individual team or large enterprise you can begin implementing steps along the curve.

DevOps + Security

People

• It’s important to ensure team members understand that security and compliance are not the same. Compliance is a bare minimum; security is about how the product performs.
• Training doesn’t equate to awareness. Teaching team members security best practices is important and every developer should know them; creating a culture of accountability is better.
• When scanning is implemented early and often, it can take its toll on the team psyche and on individual confidence. Results from scanning should be used for teaching, not scolding.

Process

• Lay down the difference between controls and guidelines. Delineate between ‘must’ and ‘probably should’ so that team members can have autonomy within the requirements.
• Ensure that policies are applicable to each portion of a project. Do this before the project begins to prevent wasted time and frustration as team members try to follow non-applicable policies.

Tools

• Inventory the toolbox — this could be through your organization or free tools like OWASP or the NIST calculator. Transparency, prioritization, and centralization of security policies are the goal.
• Figure out how to supplement your processes with your SevDevOps tool kit. How can you use tools to automate, keep track of projects, improve communication between departments?
• Get your information out of Excel, Word, and PDF format. Centralized tools improve visibility and engagement across the company.

DevOpsSec

People

• Create a culture that encourages team members to take pride in developing secure code. Consider a reward system of some kind, even, whatever it takes to prioritize security.
• Choose a passionate evangelist and help mold them to become a champion of security. Train them extensively so that they can lead and champion the importance of security from start to finish.
• Ensure accountability is a core value. If you wrote the code, you fix the code. This ensures the right person is learning from a misstep and mistakes don’t become risks down the road.

Process

• Integrate self-attestation. Provide the team with insight into policy. Invite them to offer feedback and take that feedback into account when developing new policies.
• Integrate tools into current workflows so that team members don’t have to go out of their way. Bring security-promoting tools to the developers, don’t make them seek them out.

Tools

• If you’re not scanning now, start. Manual scanning not effective or efficient enough to be the answer when there are so many tools at our disposal to speed the process and improve results.
• Scanning should go beyond basic compliance scans but shouldn’t be done so often that they become burdensome. Find the right balance. This balance will vary from one team to the next.
• Learn to prioritize vulnerabilities found in scans. Make meaningful fixes and understand when a vulnerability is an acceptable risk. Perfection isn’t possible, so perfectionism must go.

DevSecOps

People

• Design collaboration. Don’t just let it happen; plan for it. How and when should each department look to the others for advice and collaboration? Lay it all out there.
• Collect feedback from the group and insist on transparency. Transparency isn’t always easy to come by; it’s a cultural value that must be instilled through time, repetition, and proof it works.

Process

• Integrate security into your pull request. Ask for feedback on potential changes and facilitate a conversation centered around the integration of security into the development process.
• Determine where you can reduce your security debt. Learn to prioritize which aspects of security debt are acceptable and which aren’t.

Tools

• Develop security standards for specific to each stage of development but avoid creating new silos to handle security within each phase.
• Integrate security into each phase by way of the people already doing the job. This creates accountability across the project and sends a secure product on to the next step every time.
• Find ways to integrate tools that work for you. Don’t try to stick a square peg in a round hole, but seek out tools that will work into your current workflows in each department.

SecDevOps

People

• Leverage AI and ML so that people keep their focus on doing what they do best and let the computers do the grunt work. Free up time and brain space wherever it’s feasible.
• Provide intelligent playbooks to help guide team members through the processes. This can help team members solve problems and ensures they’re up to date on protocol changes.
• Provide targeted training as needed to ensure every team member is up to date. Use mistakes as teachable moments, as guides to know when more or different training is needed.

Process

• Automated governance is used to guide processes. It’s necessary to ensure the integrity of a product, but there’s no need to leave all that yummy data out to dry. Use it!
• Quality gates are put into place to ensure products meet needs, not to act as restrictors. Use them to compare project parameters to the current product to determine which fixes to make.
• Improve policy recommendations since entire teams are up to date on security concerns. Determine if policies are applicable in the current project and treat landscape.
• Security profiling can be used at each stage to ensure the product’s safety, preemptively cutting down on security issues later in the game.

Tools

• Use a workflow platform to help streamline operations. There is simply too much data to manage when SecDevOps is effectively in place to avoid workflow tools

Achieving SecDevOps: What Does it Look Like?

The goal of SecDevOps is, ultimately, allowing people to work more effectively. The entire point of the improving the processes and adding integrated tools is to help teams work smarter and not harder, allowing creativity and innovation to blossom while tackling security and compliance issues during development rather than after the fact.

When the whole goal of DevOps is to essentially move through the production process as quickly as possible, any security gatekeeping that gums up the gears can seem counterintuitive. It’s a little like the tortoise and the hare: a steady, well-executed workflow that includes security from the beginning often proves more effective than a speedier siloed process that turns out a security-deficient product that must be rebuilt.

Things to Remember

Perfection Doesn’t Exist in SecDevOps

Perfect code doesn’t exist. Perfect security is a myth. There’s no such thing as risk-free, in business, development, or security. Perfection is not only impractical, it’s not possible. Instead, we must focus on fixing the big problems, mitigating risk the best we can, and continuing to move forward.

Adapt Security to Development, Not the Other Way Around

It’s critical that the security measures development teams are expected to abide by are integrated into their processes rather than asking them to reach outside of their current workflow for security tools. Ensure the tools are easily accessible and deployable from within their current platforms and workflows.

Security and Development are More Similar Than They are Different

While they may speak different languages, the foundational tenants that drive their processes are the same:

• Policies are just secure coding standards
• Vulnerabilities are just bugs
• Items to remediate are just the security portion of your technical debt

SecDevOps is about putting them on the same page so they can be strategic about security rather than reactive because of untimely information.

Information security must accept having zero vulnerabilities is neither possible nor desirable if it significantly slows down the pace of new service delivery and innovation. Gartner, 12 Things to Get Right for DevSecOps, 2019

Originally published at https://wabbisoft.com on February 1, 2020.