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

6/12/2020
10:30 AM
Gary McGraw Ph.D.
Gary McGraw Ph.D.
Expert Insights
Connect Directly
Twitter
RSS
E-Mail
50%
50%

Building Security into Software

Part 1 of a two-part series about securing machine learning.

Every decade or so, we get an opportunity to build security in as a new field blossoms into the world. Mobile security provided one such opportunity about a decade ago. Though security people have been known to complain about the state of mobile phone security compared with, say, Windows 95, that's like comparing day to night.

Fast forward to today. One of the most important technical developments we're currently experiencing in hyper-real time is the "AI Renaissance." AI and, in particular, machine learning (ML) have been around for decades, but a resurgence in ML technology driven by incredible modern computational power and unimaginably large collections of well-organized data has even the most skeptical greybeards impressed.

Of course, security has an important role to play in ML (not using ML for security, mind you, but rather securing ML technology itself). In this two-part series, I'll explore ML security through the lens of building security in. We'll start with a quick refresher on software security.

7 Touchpoints for Software Security
In my 2007 book Software Security, I define and discuss seven touchpoints for software security. The touchpoints were intentionally created with reference to software artifacts (think source code or test cases) as opposed to any particular process for creating the artifacts. As a result, development life cycles like the waterfall methodology. In fact, the touchpoints are not a software methodology at all; they are meant to be process-agnostic.

Touchpoints are a mix of destructive and constructive activities. Destructive activities are about attacks, exploits, and breaking software. These kinds of things are represented by the black hat (offense). Constructive activities are about design, defense, and functionality. These are represented by the white hat (defense). Both hats are necessary:

My yin/yang cowboy hats logo above is based on the understanding that good security blends offense and defense in an inextricable balance. 

In the distant past, I presented the software security touchpoints in order from left to right. Although that works well, a better pedagogical approach is to order the touchpoints by their natural utility and present them in some sort of ranking. Some touchpoints are by their very nature more powerful than others, and the most powerful ones should be adopted first.

Here are the touchpoints, in what I consider the best order of effectiveness: 

1. Code review: Reviewing source code with an automated tool like Coverity, Fortify, or SpotBugs is a great way to carry out this touchpoint. This touchpoint finds (and hopefully fixes) security bugs.

2. Architectural risk analysis (ARA): Sometimes improperly called "threat modeling," ARA seeks to identify, rank, and mitigate design flaws. Design flaws account for 50% of software security defects in most software.

3. Penetration testing: Dynamically probing a running system for security problems is an important activity but often happens after the fact, making fixes that are much more difficult and costly. Note that pen testing should definitely not be the first and only touchpoint you employ.

4. Risk-based security tests: Testing security functionality, probing design flaws identified in an ARA, and regression testing against security bugs make up risk-based security testing.

5. Abuse cases: Many projects build use cases to understand how a system is meant to work. Abuse cases help determine what a system will do when it is under attack. Thinking about misuse before it happens is very powerful.

6. Security requirements: Just how secure does your system need to be? Who will attack it and why?  And most importantly, how much can you afford to do about it? These are questions addressed in security requirements.

7. Security operations: Even a system that is designed for security, properly pen tested, and debugged during development will be subject to attack. Keeping an eye on a running system (and making that task easier) is part of security ops.

In the field, the touchpoints have evolved over time into well-understood practices (some better understood and practiced than others). Many aspects of the touchpoints can, for example, be found in the 119 activities defined and measured by the BSIMM.

When a new technology wave sweeps over the security discipline - such as mobile code security, IoT security, or ML security - one important exercise is to think about how the seven touchpoints can be applied in order to make security progress.

When it comes to many technologies, source-code analysis is the easiest security touchpoint to apply first. Why that is the case should be obvious: Regardless of the process you may have used to come up with your code, your code can be subjected to static analysis. That is, just about every software project has code. Well, to a point: Static analysis of a dynamic node.js assembly may not be possible depending on when, where, and how the assembly is put together. In fact, the move to dynamic languages is having a deep impact on the base effectiveness of code review using a static analysis tool. 

Likewise, a DevOps approach elevates the importance of security operations (touchpoint 7), which is now defined in code itself. Containers are code, and container configuration is code. Container orchestration is code, too! So securing a system by design obviously must include operational aspects that may have been left to the IT guys in the past.

All details aside, there is a basic fundamental agreement that the software security touchpoints have a critical role to play in securing software (a field sometimes called application security).

In part two of this article, we'll explore these touchpoints and the very idea of how building in security apply to ML. 

 
 
 
 
 
 
Learn from industry experts in a setting that is conducive to interaction and conversation about how to prepare for that "really bad day" in cybersecurity. Click for more information and to register
 
Gary McGraw is co-founder of the Berryville Institute of Machine Learning. He is a globally recognized authority on software security and the author of eight best selling books on this topic. His titles include Software Security, Exploiting Software, Building Secure Software, ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Edge-DRsplash-10-edge-articles
7 Old IT Things Every New InfoSec Pro Should Know
Joan Goodchild, Staff Editor,  4/20/2021
News
Cloud-Native Businesses Struggle With Security
Robert Lemos, Contributing Writer,  5/6/2021
Commentary
Defending Against Web Scraping Attacks
Rob Simon, Principal Security Consultant at TrustedSec,  5/7/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-24119
PUBLISHED: 2021-05-14
A heap buffer overflow read was discovered in upx 4.0.0, because the check in p_lx_elf.cpp is not perfect.
CVE-2020-27833
PUBLISHED: 2021-05-14
A Zip Slip vulnerability was found in the oc binary in openshift-clients where an arbitrary file write is achieved by using a specially crafted raw container image (.tar file) which contains symbolic links. The vulnerability is limited to the command `oc image extract`. If a symbolic link is first c...
CVE-2021-22866
PUBLISHED: 2021-05-14
A UI misrepresentation vulnerability was identified in GitHub Enterprise Server that allowed more permissions to be granted during a GitHub App's user-authorization web flow than was displayed to the user during approval. To exploit this vulnerability, an attacker would need to create a GitHub App o...
CVE-2021-27737
PUBLISHED: 2021-05-14
Apache Traffic Server 9.0.0 is vulnerable to a remote DOS attack on the experimental Slicer plugin.
CVE-2021-32054
PUBLISHED: 2021-05-14
Firely/Incendi Spark before 1.5.5-r4 lacks Content-Disposition headers in certain situations, which may cause crafted files to be delivered to clients such that they are rendered directly in a victim's web browser.