Note to the CISO: Part 1 - The Evolving Application Security Landscape

THE APP SECURITY LANDSCAPE IS CHANGING, BUT THE CURRENT TECHNOLOGIES ARE STRUGGLING TO KEEP UP.

In a world where your smartphone is becoming the core authentication device for every Internet service, we need to understand how app development practices are impacting security and privacy.
 

Impact of Open Source and 3rd Party Dev on Changing Landscape of Mobile Applications.

The software development industry has drastically changed over the last decade.  In the early days of app development, much of the source code was written in house.  This gave organizations complete control and visibility into the inner workings of their application.  It was entirely up to them to ensure the software was of high quality and had a secure risk posture. Today’s software development environments rely heavily on third party open-source software. Many experts believe that up to 90% of an application’s code is made up of third party libraries.

Open-source generally has been positive for the industry, resulting in increased developer productivity and higher quality software. 

Open-source however has changed the security landscape for software development as well.  With proprietary in-house software development, the expertise and control over that software was also managed in-house.  Now, that expertise is largely outsourced to the open-source community.  Software developers may have little-to-no in-depth knowledge on the inner workings of the third-party libraries being used.  Organizations are largely dependent on the community for the security of these third-party libraries.

Common widespread use of third-party libraries also results in greater returns on vulnerabilities discovered by attackers.  A vulnerability found in a single library may then exist in hundreds or thousands of applications.  Open-source vulnerabilities are considered to be one of the biggest challenges faced by the software industry.

Attack vectors have evolved.

The shift to hyper connected and mobile computing has changed how attackers operate.  Traditional security relied upon protecting your network perimeter, with traditional attacks focusing on servers and network equipment.  Now, attackers are attacking applications.  Those attacks can come in the form of directly exploiting vulnerabilities often found in open source libraries, or repackaging applications or components of those apps to mislead users and steal information. The perimeter of your network is effectively pushed to a device in a user’s pocket.

The Status Quo for Application Security Scanning

There are many tools, techniques and best practices to dealing with today’s security challenges of open-source libraries and mobile app development.  One specific area of focus is Application Security Testing.  App Security Testing is the process of analyzing your application to identify and report on areas of vulnerability.  The 3 main types are SAST, DAST and IAST.  

SAST (Static Application Security Testing) functions without actually executing your application but rather by analyzing source code, bytecode or application binaries. SAST analysis looks for problems at the language and framework level, such as unsafe SQL calls.  However SAST analysis cannot detect runtime vulnerabilities which is where DAST comes in.

DAST (Dynamic Application Security Testing)  is designed to test for an application’s vulnerabilities from outside the app. A form of black box testing; DAST looks for vulnerabilities in your app much in the same way an attacker would.  

IAST (Interactive Application Security Testing) relies on instrumenting your code and analyzing your application from the inside while it is running.  This is a deeper form of DAST testing where deep knowledge and integration with the application is required - sometimes referred to as “glass-box” testing since unlike with DAST, you can see inside the box.

RASP (Runtime Application Self Protection) mentioned here for alphabet-soup completeness, isn’t so much a testing tool as it is a tool to create a shield for your applications in a way to self protect.  Examples could include terminating an attacker’s session in the event of a detected attack.  RASP requires deep understanding of the application, data and interaction which impedes scalability and limits how far it can be used as a protection mechanism.  Care needs to be taken to not actually create performance issues or attack vectors such as Denial of Service attacks by your application response.

All of these testing capabilities have their place in developing and/or deploying secure applications, however we believe there is still a gap to be addressed. Risks and vulnerabilities extend beyond the application itself into the Wild - the continually evolving application ecosystems and marketplaces.


Join us next week for our take on what’s needed to fill the gap in Part 2 - Contextually Aware Security Analysis is Here