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
Higher Education: 15 Books to Help Cybersecurity Pros Be Better
Curtis Franklin Jr., Senior Editor at Dark Reading,  12/12/2018
Worst Password Blunders of 2018 Hit Organizations East and West
Curtis Franklin Jr., Senior Editor at Dark Reading,  12/12/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
10 Best Practices That Could Reshape Your IT Security Department
This Dark Reading Tech Digest, explores ten best practices that could reshape IT security departments.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-20161
PUBLISHED: 2018-12-15
A design flaw in the BlinkForHome (aka Blink For Home) Sync Module 2.10.4 and earlier allows attackers to disable cameras via Wi-Fi, because incident clips (triggered by the motion sensor) are not saved if the attacker's traffic (such as Dot11Deauth) successfully disconnects the Sync Module from the...
CVE-2018-20159
PUBLISHED: 2018-12-15
i-doit open 1.11.2 allows Remote Code Execution because ZIP archives are mishandled. It has an upload feature that allows an authenticated user with the administrator role to upload arbitrary files to the main website directory. Exploitation involves uploading a ".php" file within a "...
CVE-2018-20157
PUBLISHED: 2018-12-15
The data import functionality in OpenRefine through 3.1 allows an XML External Entity (XXE) attack through a crafted (zip) file, allowing attackers to read arbitrary files.
CVE-2018-20154
PUBLISHED: 2018-12-14
The WP Maintenance Mode plugin before 2.0.7 for WordPress allows remote authenticated users to discover all subscriber e-mail addresses.
CVE-2018-20155
PUBLISHED: 2018-12-14
The WP Maintenance Mode plugin before 2.0.7 for WordPress allows remote authenticated subscriber users to bypass intended access restrictions on changes to plugin settings.