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
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Why CISOs Need a Security Reality Check
Joel Fulton, Chief Information Security Officer for Splunk,  6/13/2018
Cisco Talos Summit: Network Defenders Not Serious Enough About Attacks
Curtis Franklin Jr., Senior Editor at Dark Reading,  6/13/2018
Meet 'Bro': The Best-Kept Secret of Network Security
Greg Bell, CEO, Corelight,  6/14/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-12294
PUBLISHED: 2018-06-19
WebCore/platform/graphics/texmap/TextureMapperLayer.cpp in WebKit, as used in WebKitGTK+ prior to version 2.20.2, is vulnerable to a use after free for a WebCore::TextureMapperLayer object.
CVE-2018-12519
PUBLISHED: 2018-06-19
An issue was discovered in ShopNx through 2017-11-17. The vulnerability allows a remote attacker to upload any malicious file to a Node.js application. An attacker can upload a malicious HTML file that contains a JavaScript payload to steal a user's credentials.
CVE-2018-12588
PUBLISHED: 2018-06-19
Cross-site scripting (XSS) vulnerability in templates/frontend/pages/searchResults.tpl in Public Knowledge Project (PKP) Open Monograph Press (OMP) v1.2.0 through 3.1.1-1 before 3.1.1-2 allows remote attackers to inject arbitrary web script or HTML via the catalog.noTitlesSearch parameter (aka the S...
CVE-2018-10811
PUBLISHED: 2018-06-19
strongSwan 5.6.0 and older allows Remote Denial of Service because of Missing Initialization of a Variable.
CVE-2018-10945
PUBLISHED: 2018-06-19
The mg_handle_cgi function in mongoose.c in Mongoose 6.11 allows remote attackers to cause a denial of service (heap-based buffer over-read and application crash, or NULL pointer dereference) via an HTTP request, related to the mbuf_insert function.