Attacks/Breaches

10/29/2018
10:30 AM
Matt Rose
Matt Rose
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
100%
0%

AppSec Is Dead, but Software Security Is Alive & Well

Application security must be re-envisioned to support software security. It's time to shake up your processes.

There's no denying that an enterprise's application ecosystem must be protected, especially when the average total cost of a breach comes in at $3.62 million. But thwarting increasingly severe and frequent threats requires a holistic approach to security, one that places emphasis on managing not only application vulnerabilities but all software exposure.

In fact, the term "application security" should be removed from an organization's vocabulary and replaced with the broader term "software security." Software serves as the backbone to much of the digital transformation taking place within organizations today, which means it's time for CIOs, security leaders, and DevOps roles to come together and understand that the approach to securing software needs to evolve as well.

Mobile, cloud, the Internet of Things, microservices, and artificial intelligence, for example, have made software more complex. However, the emphasis remains focused on speed over security, disregarding the DevOps process, sometimes entirely. Historically, traditional security approaches have slowed the speed of development by acting as deliberate benchmarks that developers must "check off" in order to resume coding activities.

This alone gives essential security practices a bad reputation within an organization, but it also adds to the misguided stigma that developers are a source of the issue. Suddenly, you have a divided force that opens an enterprise up to software exposure. We see careless oversights and avoidable mistakes being made throughout all stages of the software development life cycle (SDLC). Addressing complex software development and related vulnerabilities requires a shift away from a siloed security approach to one that encompasses software as a whole and integrates it from the start of the SDLC.

Let's review the definitions of software and applications. Software is "organized information in the form of operating systems, utilities, programs, and applications that enable computers to work"; an application is "a program or group of programs designed for end users and written to fulfill a particular purpose of the user." We tend to use the word application as a simple way of talking about user interfaces. But really, the security of an app extends well beyond the UI to include back-end systems and integrations.

Based on the definitions above, the following statements apply:

  1. Software is the umbrella for anything written in code; an application is a component of software and just as vulnerable.
  2. Applications allow a user to perform a task or activity while software executes that task or activity.
  3. Application security came about as initial security testing focused on testing a running application, much like quality assurance testing, and ignored the back-end software components.
  4. If something is written in a coding language, then it needs to be tested to ensure it is secure. All software is written in a coding language.
  5. Software is the ecosystem of technology while applications are the entry point into that ecosystem.

Today, the complexity of software certainly perpetuates the security problems we're facing. Organizations such as Panera, Facebook, and Lord & Taylor, to name a few, have learned the hard way that vulnerabilities within an application often signal greater software exposure because, at the end of the day, an attack or hack implicates both. And with the one-year anniversary of Equifax mega breach just behind us, it's a stark reminder that we need to understand what's in a software stack. In the case of Equifax, an exploited vulnerability in the popular open source web software Apache Struts led to the compromise of almost 150 million people's personal information. There's much work to be done to improve the state of software security.

These four priorities are a good place to start:

  1. Organizations need to move beyond the barriers and limitations of traditional gated security approaches and move to a new era of full visibility and control over their software exposure at any stage of the development life cycle.
  2. Proper and consistent training should be funded and provided across entire organizations.
  3. Remediation efforts need to be made into actionable insights that address vulnerabilities within the entire SDLC.
  4. Everyone that touches software and participates in the security of it needs to be forward thinking, forgetting the typical nuances of the past.

Long gone are the days where organizations could be unprepared for and caught off-guard by compromised data and other cyber-incident damage. Attacks are only going to grow in frequency and complexity, as will software itself. As such, application security must be re-envisioned to support software security. AppSec is dead. Software security is alive and well.

Related Content:

 

Black Hat Europe returns to London Dec. 3-6, 2018, with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier security solutions, and service providers in the Business Hall. Click for information on the conference and to register.

Matt Rose has over 18 years of software development, sales engineering management, and consulting experience. During this time, Matt has helped some of the largest organizations in the world in a variety of industries, regions, and technical environments implement secure ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
scarabeetle
50%
50%
scarabeetle,
User Rank: Author
11/8/2018 | 8:52:36 AM
S-SDLC is key
Software security IS the right path.  I agree with the previous commenter that having the static and dynamic testing built-in to the build process that keeps security testing proactive, rather than reactive (after deployment) is key.  
username007
50%
50%
username007,
User Rank: Apprentice
10/29/2018 | 12:33:37 PM
Wait what?
I stopped doing Application Security about a year ago mostly due to the burn out of working with new kids being taught in school the insecure way to code all the way to the old school dev that has been coding since the Com64 thinking "if it ain't broke don't fix it"; however the point here is I have been doing this for some time too.

Now, Matt Rose seems to think that for whatever reason the industry should shake what it has already worked so hard on and just throw it away. Software Security is not the same thing as Application Security. They can NOT be intermingled and they are in so way similiar. Building an application, something an end-user actually uses, should not be treated the same way the back end database gets built. One gets handled with configuration management, I.E. company policies on how something should be configured and can be audited easily, while the other is handled with vulnerability management, I.E. with reactive response such as code review, penetration testing, or vulnerability scanning.

DevOps and Agile do not have the time that security needs to do all of our checking. So with that, Security needs to be baked into the SDLC process, not bolted on like some crap Captcha. Individuals that show the aptitude, need to be dubed security champions within their team, to help make sure best coding practices are followed.

We, as senior staff, need to stop trying to change things just for the sake of change or because we learned new words and think they need to go in a different order. This post wreaks of someone living in the Waterfall days, knowing just enough about security to cause more harm than good.

AppSec is not dead, but arrogance over how it should be handled needs to be.
'PowerSnitch' Hacks Androids via Power Banks
Kelly Jackson Higgins, Executive Editor at Dark Reading,  12/8/2018
The Case for a Human Security Officer
Ira Winkler, CISSP, President, Secure Mentem,  12/5/2018
Windows 10 Security Questions Prove Easy for Attackers to Exploit
Kelly Sheridan, Staff Editor, Dark Reading,  12/5/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
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-8651
PUBLISHED: 2018-12-12
A cross site scripting vulnerability exists when Microsoft Dynamics NAV does not properly sanitize a specially crafted web request to an affected Dynamics NAV server, aka "Microsoft Dynamics NAV Cross Site Scripting Vulnerability." This affects Microsoft Dynamics NAV.
CVE-2018-8652
PUBLISHED: 2018-12-12
A Cross-site Scripting (XSS) vulnerability exists when Windows Azure Pack does not properly sanitize user-provided input, aka "Windows Azure Pack Cross Site Scripting Vulnerability." This affects Windows Azure Pack Rollup 13.1.
CVE-2018-8617
PUBLISHED: 2018-12-12
A remote code execution vulnerability exists in the way that the Chakra scripting engine handles objects in memory in Microsoft Edge, aka "Chakra Scripting Engine Memory Corruption Vulnerability." This affects Microsoft Edge, ChakraCore. This CVE ID is unique from CVE-2018-8583, CVE-2018-8...
CVE-2018-8618
PUBLISHED: 2018-12-12
A remote code execution vulnerability exists in the way that the Chakra scripting engine handles objects in memory in Microsoft Edge, aka "Chakra Scripting Engine Memory Corruption Vulnerability." This affects Microsoft Edge, ChakraCore. This CVE ID is unique from CVE-2018-8583, CVE-2018-8...
CVE-2018-8619
PUBLISHED: 2018-12-12
A remote code execution vulnerability exists when the Internet Explorer VBScript execution policy does not properly restrict VBScript under specific conditions, aka "Internet Explorer Remote Code Execution Vulnerability." This affects Internet Explorer 9, Internet Explorer 11, Internet Exp...