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
New Cold Boot Attack Gives Hackers the Keys to PCs, Macs
Kelly Sheridan, Staff Editor, Dark Reading,  9/13/2018
Yahoo Class-Action Suits Set for Settlement
Dark Reading Staff 9/17/2018
RDP Ports Prove Hot Commodities on the Dark Web
Kelly Sheridan, Staff Editor, Dark Reading,  9/17/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: In Russia, application hangs YOU!
Current Issue
Flash Poll
How Data Breaches Affect the Enterprise
How Data Breaches Affect the Enterprise
This report, offers new data on the frequency of data breaches, the losses they cause, and the steps that organizations are taking to prevent them in the future. Read the report today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-17177
PUBLISHED: 2018-09-18
An issue was discovered on Neato Botvac Connected 2.2.0 and Botvac 85 1.2.1 devices. Static encryption is used for the copying of so-called "black box" logs (event logs and core dumps) to a USB stick. These logs are RC4-encrypted with a 9-character password of *^JEd4W!I that is obfuscated ...
CVE-2018-17178
PUBLISHED: 2018-09-18
An issue was discovered on Neato Botvac Connected 2.2.0 devices. They execute unauthenticated manual drive commands (sent to /bin/webserver on port 8081) if they already have an active session. Commands like forward, back, arc-left, arc-right, pivot-left, and pivot-right are executed even though the...
CVE-2018-11869
PUBLISHED: 2018-09-18
In all android releases(Android for MSM, Firefox OS for MSM, QRD Android) from CAF using the linux kernel, lack of length validation check for value received from firmware can lead to buffer overflow in WMA handler.
CVE-2018-17176
PUBLISHED: 2018-09-18
A replay issue was discovered on Neato Botvac Connected 2.2.0 devices. Manual control mode requires authentication, but once recorded, the authentication (always transmitted in cleartext) can be replayed to /bin/webserver on port 8081. There are no nonces, and timestamps are not checked at all.
CVE-2018-11852
PUBLISHED: 2018-09-18
In all android releases(Android for MSM, Firefox OS for MSM, QRD Android) from CAF using the linux kernel, improper check In the WMA API for the inputs received from the firmware and then fills the same to the host structure will lead to OOB write.