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
COVID-19: Latest Security News & Commentary
Dark Reading Staff 10/30/2020
'Act of War' Clause Could Nix Cyber Insurance Payouts
Robert Lemos, Contributing Writer,  10/29/2020
6 Ways Passwords Fail Basic Security Tests
Curtis Franklin Jr., Senior Editor at Dark Reading,  10/28/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
How to Measure and Reduce Cybersecurity Risk in Your Organization
In this Tech Digest, we examine the difficult practice of measuring cyber-risk that has long been an elusive target for enterprises. Download it today!
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-27652
PUBLISHED: 2020-10-29
Algorithm downgrade vulnerability in QuickConnect in Synology DiskStation Manager (DSM) before 6.2.3-25426-2 allows man-in-the-middle attackers to spoof servers and obtain sensitive information via unspecified vectors.
CVE-2020-27653
PUBLISHED: 2020-10-29
Algorithm downgrade vulnerability in QuickConnect in Synology Router Manager (SRM) before 1.2.4-8081 allows man-in-the-middle attackers to spoof servers and obtain sensitive information via unspecified vectors.
CVE-2020-27654
PUBLISHED: 2020-10-29
Improper access control vulnerability in lbd in Synology Router Manager (SRM) before 1.2.4-8081 allows remote attackers to execute arbitrary commands via port (1) 7786/tcp or (2) 7787/tcp.
CVE-2020-27655
PUBLISHED: 2020-10-29
Improper access control vulnerability in Synology Router Manager (SRM) before 1.2.4-8081 allows remote attackers to access restricted resources via inbound QuickConnect traffic.
CVE-2020-27656
PUBLISHED: 2020-10-29
Cleartext transmission of sensitive information vulnerability in DDNS in Synology DiskStation Manager (DSM) before 6.2.3-25426-2 allows man-in-the-middle attackers to eavesdrop authentication information of DNSExit via unspecified vectors.