Application Security

10:30 AM
Connect Directly
E-Mail vvv

A Secure Development Approach Pays Off

Software security shouldn't be an afterthought. That's why the secure software development life cycle deserves a fresh look.

News headlines abound with stories of well-known companies falling victim to cyberattacks and data breaches. Some attacks — such as 2017's WannaCry ransomware — cause global mayhem and an immediate reaction from businesses, which scramble to issue and install patches. But there's a far bigger problem than the headlines would lead you to believe. It's a problem that is part of the approach that has, so far, been taken to software development, and one that is leaving tiny imperfections deep inside the infrastructure of organizations across the world.

Typically, software development follows a set process: the software development life cycle (SDLC). It's a best-practice plan that's been adapted over the years and dictates how software should be developed, maintained, and updated. Historically, security was an afterthought throughout the process until a few years ago when an additional "S": for "secure" was added, and those in DevOps found themselves with a new buzzword — secure software development life cycle, or SSDLC — and adopted manual security processes as part of the life cycle. But simply adding the S, without making any changes of the process, meant that code testing remained the priority instead of building in a specific security review of the code.

Although the distinction might sound minor, it's the difference between building software that is inherently secure from the start and building software that contains flaws that are discovered too late — or, in some cases, not at all.

So, although SSDLC isn't a new concept, we need to change the mindset on how it's implemented. Many businesses developing software believe that they're doing so securely. They're using tools like Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST), which can be useful at the implementation stage and testing phase, respectively, and have the benefit of ensuring that security is in the process at all (which is better than the traditional SDLC process). But by this point, it may well be too late — flaws can easily be missed, and those that are caught may not be easily fixable without time and expense.

The New Wave of SSDLC
The answer is to bring security into the development process from the very beginning — but DevOps and security have not, historically, been comfortable bedfellows. There's often a belief that security slows down the development process, which ultimately affects time to delivery. But by avoiding security until the end of the process, there's a huge risk that vulnerable products will be released. Clearly, neither option is ideal.

This is where automation comes in. Ideally, you need transparent integration and full automation of the security solution at all stages of the development process. As opposed to conducting the process manually, automating the process will provide findings and feedback continuously with every alteration in the code analyzed without the need for human intervention. The code can then either be returned to developers or virtually fixed, and a patch issued for the source code — all automatically.

Automation solves a number of the old problems associated with traditional SSDLC processes — it means security is a core element throughout and doesn't slow down DevOps. However, it also needs a level of oversight. Once the code is built and DevOps integrates testing tools and development tools, security metrics have to be defined — with no build approved unless it complies. During the requirements phase, security metrics will be drawn up, which match to the organization's high-level confidentiality, availability, and integrity objectives. This may include reference to regulations such as the EU's General Data Protection Regulation and the Payment Card Industry Data Security Standard, and security experts have to be involved to assist with threat modeling and review during the design and requirements phase.

What's more, true software security isn't only about ensuring the software itself is secure, but also securing the systems on which software runs. Software security needs to be part of an application security program that takes into account any concerns at the beginning of the development life cycle in a holistic way. Although a lot of the security requirements and processes are often relatively simple, and, to security specialists, fairly obvious, software developers often don't have the knowledge of security processes in as much depth as is required to meet the rigorous standards. Such metrics need to be overseen by a head of application security or security expert to add a layer of checks and balances.

Software security shouldn't be an afterthought. With ever-increasing instances of criminals taking advantage of flaws and vulnerabilities, bringing security into the development life cycle at the very beginning will ensure a far more robust end product. It might take slightly longer to deliver the software, but, in the long run, it will pay off.

Related Content:


Black Hat Asia returns to Singapore with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier solutions and service providers in the Business Hall. Click for information on the conference and to register.

Leigh-Anne Galloway started her career leading investigations into payment card breaches, where she discovered her passion for security advisory. Her keen eye for new technology has led her to work with companies such SilverTail Systems (acquired by EMC) and vArmour where she ... View Full Bio
Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
The Case for Integrating Physical Security & Cybersecurity
Paul Kurtz, CEO & Cofounder, TruSTAR Technology,  3/20/2018
A Look at Cybercrime's Banal Nature
Curtis Franklin Jr., Senior Editor at Dark Reading,  3/20/2018
City of Atlanta Hit with Ransomware Attack
Dark Reading Staff 3/23/2018
Register for Dark Reading Newsletters
White Papers
Current Issue
How to Cope with the IT Security Skills Shortage
Most enterprises don't have all the in-house skills they need to meet the rising threat from online attackers. Here are some tips on ways to beat the shortage.
Flash Poll
[Strategic Security Report] Navigating the Threat Intelligence Maze
[Strategic Security Report] Navigating the Threat Intelligence Maze
Most enterprises are using threat intel services, but many are still figuring out how to use the data they're collecting. In this Dark Reading survey we give you a look at what they're doing today - and where they hope to go.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.