How we must move security earlier in the development process

According to a 2017 study by the Ponemon Institute, respondents indicated that on average only 29 percent all mobile apps are tested for vulnerabilities. It therefore comes as no surprise as we watch breach after breach make headlines around the world.

Ponemon also reported the average total cost of a single data breach to be $3.62 million last year, but the true cost is hard to quantify. Reputation damage, loss of revenue and financial penalties drive that number even higher.

For those organizations fortunate enough to find vulnerabilities in their apps before release, one thing is universally true: The sooner a problem is found, the less it costs to fix. It seems obvious, then, that security should be a primary concern for developers from the first day of the software development lifecycle.

To the frustration of chief information officers and chief information security officers across the industry, this is not yet the case. But security can be moved forward in the process, and I will show how a three-pronged approach can help you place an appropriate focus on security early in the software development lifecycle.

Why developers don’t prioritize security

At most organizations, there’s an expectation that mobile apps should be delivered more quickly than other IT projects. Development timelines and budgets tend to get squeezed, and for developers, the need to deliver the app often supersedes the need to understand the security challenges that exist.

In addition, the analysts who define the functional requirements for an app tend to emphasize the business value they want to deliver, not the level of security they want to provide. The truth is, throughout the process of an app’s development, teams tend to trade speed for security. As a result, security tends to be deprioritized in the development process.

In the best of cases, the lack of attention to security needs during the development cycle is mitigated by some sort of screening or vetting at the end, and vulnerabilities are ultimately caught before the app is deployed. But by this time, developers have moved on to other projects, and must be pulled back to fix the problems, costing both time and money. In the worst-case scenarios, vulnerabilities are not found until after deployment, and the first anyone at an organization hears about an issue is when it has already been exploited.

This problem also has impacts beyond companies’ time and money. It can leave users, including those with access to sensitive personal information or vital infrastructure systems, vulnerable to zero-day attacks. That’s part of why the Department of Homeland Security Science and Technology Directorate is currently funding research into solutions for this very problem.

Mitigating the risk

CIOs and CISOs could spend months or even years defining comprehensive security requirements for every app. Ultimately, the security measures we employ must match the risk. How secure does an app need to be? What type of data is it processing? What is the actual risk?

Mobile app security will not improve if we simply appeal to developers to take security more seriously; most are quite aware of the seriousness. The real solution lies in making security concerns more prominent across the board, increasing awareness for all players about the risk of neglecting security in the early stages of development. By focusing on a three-pronged approach to adding security in the earlier stages of the software development lifecycle, we can make a real difference in delivering apps with security baked in throughout the process.

Educate, empower, enforce.

Better security begins with education across the enterprise. Most developers are well aware of the need to take security seriously. However, this awareness must extend beyond the developer and also reach business analysts, and others who set functional requirements for app development. By encouraging analysts to define security among functional requirements, they can help developers to prioritize security throughout the development process.

But developers are not off the hook; they must also understand the need to speak up if they’re under pressure to deliver functionality without taking security into account.

Product security begins with a security-oriented foundation. Organizations must empower developers to add security features in a way that is both time-and cost-effective. Some functions don’t vary much from app to app and are typically bundled into software development kits (SDKs) that can be used across projects. The companion to these are template applications. Developers need access to SDKs for security functionality, to use as a jumping-off point for building their own applications. By providing a stable base designed to be more secure on which developers can build future apps, we can greatly increase the odds that security is integrated beginning on day one.

Enforce compliance by adding automated security checks to the workflow. Finally, companies should put processes and policies in place that help enforce compliance to improve the security of the apps before they go out the door. Security checks must be integrated into every phase of the workflow, not just in the end stages.

One way to do this is to integrate security scan protocols that can perform an automated security check in 30 to 60 minutes. Each time a developer writes new code, a process of continuous integration can send it out for a scan, with results back by the time he or she gets back from lunch. The work is still fresh in the developer’s mind, and any flagged issues can be fixed without having to go too far back. By creating these systems, vulnerabilities can be remediated and resubmitted as part of the normal workflow.

“The man who removes a mountain begins by carrying away small stones.”

By educating and empowering their team and weaving security checks into their developers’ workflow, organizations can address potential vulnerabilities in manageable, bite-sized pieces soon after they’re introduced rather than as an enormous undertaking at the end. If security can be part of an automated process that doesn’t have a steep cost in terms of performance, budget or delivery dates, it’s a much easier sell to the analyst in terms of business value. And if it keeps breaches from appearing in future headlines, it’s a big win for both the company and the end user.

John Frizelle is the chief architect for mobile at Red Hat.

Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.