Experts talk application security at RSA

We asked a couple of AppSec experts and BSIMM participants about 2019 application security trends, challenges, obstacles, and solutions. Here’s what they said.

The original version of this post was published in Forbes.

It has become a cliché because it’s true: Application security is a journey, not an event.

But the way an organization takes that journey can make a lot of difference—a few wrong turns can even mean success or failure.

Sponsorships Available

Sponsorships Available

Sponsorships Available

That was the reason, in 2006, for the creation of the BSIMM—Building Security In Maturity Model. The goal was to study software security initiatives (SSI) at companies in various industry verticals, and then compile the data into an annual report so participants could learn from one another—what their peers are doing, what is working and what isn’t working. It’s been called “a software measuring stick” and a “what’s happening now” guide for improving application security.

The BSIMM report, now in its ninth iteration, has grown to 120 participating companies in eight verticals: financial, independent software vendors (ISV), tech, healthcare, Internet of Things (IoT), insurance, cloud and retail.

So, who better to talk about the state of application security today than a couple of BSIMM participants?

Jay Kelath, director of product security for Dow Jones, and Kyle Lai, head of KLC Consulting, who works mainly with large energy firms, agreed to talk last week at the RSA Conference in San Francisco about trends, challenges, obstacles and solutions to the ongoing, never-ending journey to better application security, along with a bit about their experience with the BSIMM.

2019 application security trends

What do you see trending in AppSec/software security this year? Are those trends good or bad?

Kelath: I see two trends across the board—one on the technology tools side and the other on the engineering side.

On the tools side, most of it is focused on IAST (interactive application security testing) and DAST (dynamic application security testing)—new technologies that will revolutionize application security. I’ve not personally bought into the whole thing yet—it’s pretty rough when you test it out—but the promise is there. It will help.

Second is solutions-oriented application security. AppSec teams have focused on finding issues and then having developers fix them. Things are slowly changing to building solutions that engineers can use.

This is the direction that we are going at Dow Jones. We’re trying to build common solutions for issues around authentication, encryption and cross-site scripting—that kind of stuff.

It’s easier for us to develop a solution for a particular technology and then tell the developers, “Hey, do you want to use authentication? Here’s a library, a pattern or a tool to use.” That kind of solutions-oriented engineering security is gaining traction.

Lai: Everyone is moving to the cloud and containers, so there’s more to worry about—containers, API and serverless technologies, for example. We have seen a lot of breach incidents within the cloud, so the emphasis from management is on making the cloud more secure. And while awareness is good, there are challenges not being adequately addressed.

2019 security challenges and threats

What security challenges/threats in 2019 are common to most industries?

Kelath: The one area where I see difficulties is in new development patterns that are serverless, where the tooling is not well-defined. That is a huge gap—if you want to inspect lambda code, there aren’t many mature tools out there—we are still mostly relying on tools from 10 years ago.

But more and more development is happening serverless in all these areas. If you look at the infrastructure piece, it’s Docker containerization. There are some tools that help, but a holistic view is missing. The gap in those areas is widening.

SQL injection and XSS were defining vulnerabilities for web applications and kick-started the app security trend. We need researchers to come up with something similar for serverless and other new technologies to get visibility for security.

Lai: There is a knowledge gap in understanding cloud security. And we have a gap in skilled cloud security expertise. The cloud security landscape has expanded, but we don’t have enough skilled human resources. It’s common across all industries.

Also, security technologies and security tools don’t often match the speed of delivery. I’d like to see security tools that work faster.

The current state of DevSecOps

Do you see measurable progress in organizations putting the “Sec” component into DevSecOps?

Kelath: “DevSecOps” or “SecDevOps” has been thrown around as a term quite a bit, and nobody has really defined exactly what it is. Everybody seems to have their own definition. I have my own definition too. We look at it as part of engineering—one of the steps for building solutions for engineers.

We build the tooling into the workflow that developers use and then push the results into that same workflow. It’s less about security tooling and more about the process. We have developed some tooling, processes and automation around this and have seen that it is 30–35% more likely that people will fix bugs.

The reason is, let’s say you have a two-week sprint. If you do a scan two or three weeks later, find vulnerabilities and tell the developers, they’ve already moved on. They are doing something else, and they don’t want to come back and take the time to fix those bugs.

In our pipeline, we have automation to identify issues in a few minutes and then push it into their workflow, and because of the immediate feedback, they fix it.

Lai: The first comment that comes back from the development team when we tell them we have this nice security tool that we want them to put into the development pipeline, they say, “Yes, it’s great, we’ll do it, but only if you don’t slow us down.” That’s always the challenge. We always seek more automation for both speed and accuracy. When you’re trying to build something to be released into production, you always have to have accuracy for identifying vulnerabilities is most important, because you might have to break the build if it has a critical security defect.

The future of software security

Are there promising technologies and solutions available now to make security more of a mainstream element of software development?

Kelath: The most promising is the IAST / runtime app self-protection (RASP) space. Like I said before, it holds promise, but it’s very immature at this stage—even some of the leading vendors have big gaps. It’s been tough to implement in our environment. But when things are ironed out, I think it will be much better.

Lai: There are tools for static analysis and dynamic analysis that have been around for a while, but I think we need to explore technology that can be more in line with the CI/CD pipeline. The tools now available aren’t ready to meet our needs yet. When we are using the Docker container technologies or the serverless technologies, those are moving very fast, so we really need to have tools that can integrate within those areas of the pipeline. Work needs to be done in this area.

Government regulation of IoT

Some security experts are becoming increasingly vocal in arguing that it will take government regulation to improve the security of connected products and services. Do you agree?

Kelath: I agree to some extent, because if you look at IoT devices, medical devices and so forth, which have the ability to kill people if they are hacked, it needs some oversight and regulation. There do need to be some guardrails in place. But not like a software company kind of thing. It becomes very onerous from a security perspective. You don’t want checkbox compliance, because that doesn’t lead to good engineering at all.

Lai: I agree to a certain extent. In some cases, without a firm mandate, companies will say it costs too much and won’t do it. It’s always about the bottom line. But government should only provide security guidelines at a high level—it shouldn’t mandate details about implementation. Also, larger companies typically have the budget to do it, but smaller businesses may need budget-friendly help.

Why you joined the BSIMM Community

What got you interested in participating in the BSIMM?

Kelath: The catalyst was that it was pretty much the only “framework” for application security that’s out there. Second was knowing how you are doing with your peers. Executive management is always interested in figuring out how well the other companies are doing, how to get to the next level and what that next level looks like. So we are using BSIMM exactly for that purpose.

Lai: We wanted to understand what our peers within the industry were doing. Our software security group is new, so we wanted to track our progress over the next few years. We were also attracted to the industry peer communication and knowledge sharing.

Why to participate in the BSIMM

If you were trying to convince a business colleague to participate in the BSIMM, how would you pitch it?

Kelath: One would be that it measures where you are, and this is the only game in town to do that. Second is that it provides you a path to follow, a strategy. It gives you data about what you should do.

Lai: I’d say it will give you a great benchmark of where you stand among your peers in software security compared to other similar companies. And since we are all concerned about software security, you’re communicating with people who are fighting similar battles, seeing similar challenges and trying to solve similar problems. There is a lot of sharing among colleagues that features frank open discussion. I personally benefit when we are doing a PoC [proof of concept] from people who have already done something similar and who may be using a similar tool and understand what some of the challenges are. It’s kind of like having a nice roadmap to help you navigate.

***

This conversation has been edited and condensed for clarity.

Join the BSIMM Community