Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

3/2/2018
10:30 AM
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

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
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
chloedigitalmaelstrom
100%
0%
chloedigitalmaelstrom,
User Rank: Strategist
6/20/2019 | 3:35:53 PM
Secure Software Development Life Cycle
"Software security shouldn't be an afterthought." This sums it up - utilizing security throughout the whole process rather than throwing it in at the end will make for a safe and secure end-product.

This article provides really clear insight as to why the security is an absolute necessity when it comes to development. The tech advisory business at which I work, Digital Maelstrom, has been utilizing this Secure Software Development Life Cycle for the past several years and it has consistently yielded great results. Following this life cycle proved to be so effective with our clients that we even began offering it as one of our main services under the umbrella of our Security pillar. Thanks for posting, Leigh-Anne.
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/9/2020
Russian Cyber Gang 'Cosmic Lynx' Focuses on Email Fraud
Kelly Sheridan, Staff Editor, Dark Reading,  7/7/2020
Why Cybersecurity's Silence Matters to Black Lives
Tiffany Ricks, CEO, HacWare,  7/8/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15105
PUBLISHED: 2020-07-10
Django Two-Factor Authentication before 1.12, stores the user's password in clear text in the user session (base64-encoded). The password is stored in the session when the user submits their username and password, and is removed once they complete authentication by entering a two-factor authenticati...
CVE-2020-11061
PUBLISHED: 2020-07-10
In Bareos Director less than or equal to 16.2.10, 17.2.9, 18.2.8, and 19.2.7, a heap overflow allows a malicious client to corrupt the director's memory via oversized digest strings sent during initialization of a verify job. Disabling verify jobs mitigates the problem. This issue is also patched in...
CVE-2020-4042
PUBLISHED: 2020-07-10
Bareos before version 19.2.8 and earlier allows a malicious client to communicate with the director without knowledge of the shared secret if the director allows client initiated connection and connects to the client itself. The malicious client can replay the Bareos director's cram-md5 challenge to...
CVE-2020-11081
PUBLISHED: 2020-07-10
osquery before version 4.4.0 enables a priviledge escalation vulnerability. If a Window system is configured with a PATH that contains a user-writable directory then a local user may write a zlib1.dll DLL, which osquery will attempt to load. Since osquery runs with elevated privileges this enables l...
CVE-2020-6114
PUBLISHED: 2020-07-10
An exploitable SQL injection vulnerability exists in the Admin Reports functionality of Glacies IceHRM v26.6.0.OS (Commit bb274de1751ffb9d09482fd2538f9950a94c510a) . A specially crafted HTTP request can cause SQL injection. An attacker can make an authenticated HTTP request to trigger this vulnerabi...