Apps rule. They’re everywhere. Every
business with an online presence has web applications—sometimes hundreds
or thousands. There are about 2 million available on the Google Play store and
another 1.83 million on the Apple App store, according to Statista.
Which is good—and bad.
Everybody knows about the good. Apps enable everything from entertainment to
education, fitness, friendship, efficiency, and convenience—magical
convenience.
The bad: Cyber attackers know all this too. They also know that software is rarely perfect and not all organizations prioritize secure application development.
That, predictably, makes apps a favourite “attack surfaces” of hackers looking to get inside your device or your system.
But there are ways to increase the good and decrease the bad.
Web apps are a top attack vector
The most recent Verizon Data Breach Incident Report (DBIR) found that web applications are among the top three attack vectors in eight of the nine industry verticals it covered. They are No. 1 in four of them.
There is no mystery about this. If an attacker can exploit a vulnerability in an app, it offers what that attacker is seeking—potentially unlimited access. Insecure applications put organizations at risk in multiple ways—financial, legal, brand damage, and more. Which is something everybody should know.
Tim Mackey, technical evangelist at Synopsys
But there is a major gap between “should know” and “do know”. So, given that the online world remains riddled with application vulnerabilities, it makes sense to put extra focus on one of the most fundamental elements of how to do that: application security, or AppSec.
Know what’s in your code
For starters, you have to know what you own. While most organizations create proprietary software, virtually all—99%, according to the 2018 Synopsys Open Source Security and Risk Analysis (OSSRA) report—also use open source.
Which is why software composition analysis (SCA) is useful. It helps find open source components in an app while it’s in development.
Know how your apps will be used
Beyond knowing that, developers need to know how an app is going to be used. “The core challenge is that appropriate tooling and strategies will depend upon your development paradigm,” said Tim Mackey, technical evangelist at Synopsys.
“For example, in a highly agile DevOps-centric engineering team where the applications are deployed as microservices in containers, there are capabilities within containerized deployments that can be described as security mitigation models—the results of which are more difficult to attain when developing IoT firmware or mobile applications.”
Use the right tools
There are also multiple tools for software security testing throughout the software development life cycle (SDLC):
- SAST (static application security testing)
- DAST (dynamic application security testing)
- IAST (interactive application security testing)
- RASP (runtime application self-protection)
- Penetration testing
They all play a role in delivering a product that, while it won’t be bulletproof (nothing is), will be secure enough to discourage all but the most motivated and expert hackers.
While it may seem like splitting hairs, it is important to note that these tools don’t “build” anything on their own, any more than a hammer, saw, screwdriver, and drill build a cabinet on their own. They help the builder.
But, of course, to provide any help, those tools have to be used. So do software testing tools. And the reality is that security testing is too often perceived as a drag on development—that it makes teams less likely to meet their deadlines.
Create security requirements
One reason for that, according to Sammy Migues, principal scientist at Synopsys, is that security testing isn’t always written into the specifications for an app.
He notes that while product managers specify what features an app should have, which also take time to build, nobody frets about features slowing down development.
“When the product management industry learns to write non-functional security requirements, then developers will build security in, allotting the proper time estimates to achieve the acceptance criteria that include building security in. So, no friction,” he said.
Enable developers
Another reason is a lack of incentives to push development teams to make security a priority. Mackey said if a software vulnerability that could have been caught and fixed leads to an exploit, it’s not the development team that suffers the consequences, at least at first. “It’s the production operations team that bears the bulk of the cost in remediating the issue,” he said. “The core cost to development teams occurs after the forensic analysis is complete, when they need to rework or refactor their code.”
“So anything not deemed a ‘feature’ will be perceived as a speed bump to functional feature development.”
Will privacy concerns boost secure application development?
However, ironically enough, the privacy laws now blossoming throughout the world could force companies to improve their app security, Mackey said. The cost of failing to do it will be greater than the cost of doing it.
“For example, if data on a user is collected, GDPR dictates that the collection occur under limited scenarios and that users have a right to receive an accounting of what data an organization collected but also how it was used,” he said.
“The security aspect of this is that now data collection no longer is ‘because it’s useful’ and data retention is no longer ‘as long as I need it’ because in reality, the only information subject to a data breach is what was collected and retained.”
Ultimately, he said, this paradigm change will be good for both the companies that make apps and the consumers who use them.
Don’t wait for privacy laws: Start now
For those who take secure application development seriously, besides the available tools, there is a roadmap to doing it better, called the BSIMM—Building Security In Maturity Model. The annual report on software security initiatives (SSI), observed mainly from eight industry verticals, came out last month. Now in its tenth iteration, the BSIMM covers 119 “activities” already in use.
Migues, a co-author of the report since it began, called those 119 activities “perhaps the best collection of controls ever amassed for the purpose of building security capabilities into an organization’s SSI. It captures the state of the industry—what’s being done right now.”
So the means for secure application development are available. Now all it takes is doing it.
