The tendency for disconnection persists between developers and security watchdogs, but there are ways to get them on the same page. That is one of the goals of the Denim Group, which provides application security assessments and strategies for addressing risks. It can be complicated bringing security and developers together in the midst of transformation, especially in sectors that are heavily regulated. Denim Group has worked in such spaces, including government.
In 2013, Denim Group landed a research grant with the Department of Homeland Security’s Cyber Security Division that went toward further development of the technology behind ThreadFix, a platform for managing vulnerability of applications.
Dan Cornell, CTO and principal with Denim Group, spoke with InformationWeek during the DevOps World Conference about intertwining the needs of security and DevOps.
How do you approach resolving the conflicting demands of DevOps and security?
“For the last 15 to nearly 20 years, I’ve been focused on the security implications of the development that organizations do. Working with organizations making that transition to DevOps to also incorporate DevSecOps. I speak to developers as well as security.
Why can it be difficult for these teams to understand each other?
“There are a lot of security folks that have some programming experience but it’s knowledge from quite a while back. They’re not used to Web dev, mobile dev, IoT and all the stuff that’s happening now. Developers and security not understanding one another is a huge problem. When security comes in and says they are here to help, they run a scan and produce a 300-page PDF with a color graph on the front -- the development teams ask what they are supposed to do with that. Which of these items are important? If everything is important, nothing is important. That’s a real challenge but also a great opportunity for security. There are some natural things that come together when you look at DevOps as more of a cultural transition.
Is there common ground between them?
“With operations, they may need to innovate quickly and break a few things. It’s similar from a security standpoint, especially when it comes to the software and application aspects. There shouldn’t a separation. It is a tremendous opportunity when you look at some of the tool changes going on with pipelines. If you’re running an automated unit test or automated integration test, maybe it’s an automated performance check, things of that nature -- it’s very natural to also add some security testing. We’re going to look at aspects of the code; we’re going to test aspects of the running system, integrated app security testing. We’re going to look versions of the components that you’re using. We’re going to look at the compute that you are sitting on top of, the cloud configuration -- all the things that could be incorporated into the pipelines.
How does your technology come into play in such an equation?
“That’s been a big push we’ve had with our ThreadFix platform. ThreadFix came out of an experience we had working with a financial services firm. Security had to do some testing for an important Web application, ran a scanner, and a 300-page PDF was dropped off with the dev team. Security did a perimeter Web scan with a different technology a couple of months later, came up with a new 200-page PDF with a different color graph, went to the development team manager and said, ‘Here’s this other stuff. By the way, what did you do with the original vulnerabilities we gave you?’
“The dev team representative naturally asks how is this different from what was given before. The dev team manager went up to their line of businesses and said, ‘The security guy is actively wasting my time.’ The dev promised new features to a hotshot VP who promised them to an important customer. They’ve got performance bugs in production that are killing them. It’s not that they don’t care about security, but then a rock gets dropped on the security team.
How do you fix this problem?
“Neither group in that scenario was acting in bad faith. It was a data management problem and a communication problem. The security team didn’t know how to interact with the dev team. You still see that even in sophisticated organizations. If security wants to communicate with developers, they need to understand the tools they are using because that takes friction out of the process. We need to communicate the security issues through the tools that developers already use and work with. With the release of the Jenkins plugin, that’s going to the other side of the equation. If you want these teams to run security testing, they need to run it from these automation tools to drive these pipelines. It’s an idea that is starting to take off.
How did you land a contract with the Department of Homeland Security?
“It was under the Small Business Innovation Research (SBIR) program. We built out a technology called hybrid analysis mapping. If you look at the two major approaches for applications security testing there’s static analysis, which is a code review looking when at rest for patterns much like a compiler would go through to identify weaknesses in the code. Then there is dynamic analysis, which is running an application and saying, ‘I sent this request to the application, got a response back, and that pattern is indicative of these types of security issues.’ That provides you with the in-depth coverage you get when you’re looking at source code to make guesses about what is going on. We built a technology that allows you to correlate between those static and dynamic analysis results. We got two patents out of those efforts and we’ve included that as a portion of our ThreadFix platform.”
For more from DevOps World, check out these recent articles.