Language is tricky, especially in areas where it is evolving quickly. Software security is a young and volatile field where new terminology ebbs and flows continually.
Language is tricky, especially in areas where it is evolving quickly. Software security is a young and volatile field where new terminology ebbs and flows continually. Part of the challenge of having a fruitful conversation is simply ensuring that both parties agree on the meaning of the words they are using.
Like characters in a Russian novel, every concept and technology seems to have at least three different names, making it hard to keep your eyes on the big picture. In this article, I will draw the outlines of some of the different areas of software security to help nail down the terminology.
THE GREAT SCHISM
In most organisations, software security responsibility is divided between IT security and application security. At the most fundamental level, IT security is about buying software, while application security is about building software. Said another way, IT security is about operating software, while application security is about developing software. The core mission of both groups is bringing risk down to an acceptable level for the organisation.
IT SECURITY
IT security is part of the information technology group, which is generally responsible for supplying the computing infrastructure for an organisation. This includes network equipment and configuration, laptops, servers, printers, and mobile devices. IT is usually responsible for software applications as well, including directory services, single sign-on solutions, and multifactor authentication, not to mention applications such as Microsoft Office and whatever else employees use to get their jobs done.
On top of all this, IT security is responsible for keeping applications and servers updated, educating users about software security, managing the configuration of networks, detecting malicious activity, and responding to security incidents. It is an outrageous mountain of responsibility.
IT security is mainly focused on operations, keeping systems running so that the organisation continues to function. Clearly, IT security’s job would be much easier if the systems and software they protect were built better in the first place.
APPLICATION SECURITY
Also known as product security, the application security team is responsible for the security of software produced by the organisation.
Flaws and vulnerabilities in an organisation’s product can lead to all manner of unpleasantness. Although downstream customers usually bear the brunt of security incidents, product failures can lead directly to lost revenue and irreparable reputation damage for the software creator.
The adaptation of existing development processes into a secure software development life cycle (SSDLC) is the primary mechanism for minimising risk in application security. Organisations using an SSDLC are always thinking about security, from the design phase through implementation and maintenance.
OF SMOKEY BEAR AND FIRE EXTINGUISHERS
Security can be proactive or reactive. Proactive security focuses on reducing risk, such as properly extinguishing campfires in the forest. Reactive security is about limiting the magnitude and severity of a problem, such as using a fire extinguisher to put out a fire.
IT SECURITY IS MAINLY REACTIVE
A firewall is a classic example of a reactive solution; it reduces exposure to known external threats. Antivirus software is a classic reactive security technology, as it defends (to some degree) against known malware but is powerless when faced with new, unknown malware.
Likewise, security information and event management (SIEM), intrusion detection systems (IDS), and intrusion prevention systems (IPS) are all technologies designed to let you know if something is going wrong, to help you respond quickly and contain damage.
You will also hear people talk about network security, which is essentially the subset of IT security dealing with firewalls, SIEM, and similar technologies.
Another common term is endpoint security, which deals with software that runs on desktops, laptops, and mobile devices to thwart known attacks. This includes antivirus software and newer entrants grouped in the category of runtime application self-protection (RASP).
IT security can take some proactive security steps, mainly during the procurement process for new systems and software. If IT security is proactive about requiring vendors to follow best practices for application security, and if IT security has the ability to perform their own security testing on potential purchases, they can make informed decisions and lower risk when acquiring new infrastructure and applications.
APPLICATION SECURITY IS MAINLY PROACTIVE
Application security, by contrast, is almost entirely proactive. Application security is focused on locating and fixing as many weaknesses as possible before releasing a product into the big, bad world.
The centrepiece of application security is the adoption of an SSDLC, which uses a proactive approach to minimise risk at every phase.
The implementation and testing phases of the SSDLC are fertile ground for acronyms, sprouting a variety of terms to describe different kinds of software security testing:
• SAST (static application security testing) refers to tools that examine an application’s source code to look for weaknesses. This is, in essence, automation of a manual code review.
• SCA (software composition analysis) means looking at an application’s source code (and sometimes its executable files) to determine which third-party software components were used, and assessing known vulnerabilities and license compliance.
• DAST (dynamic application security testing) means any testing that is done on a running application. This is a nebulous term that does not always mean the same thing to different people. Disparate technologies that technically fall under the DAST moniker include network scanning for known vulnerabilities, but also fuzzing for unknown vulnerabilities and the next entrant, IAST.
• IAST (interactive application security testing) is a kind of dynamic testing in which the tool is able to observe data flowing inside the application and can, in some cases, replay dataflows to verify findings.
• MAST (mobile application security testing) is testing performed on mobile apps, which has its own nuances.
THE TERMINOLOGY ISN’T GREAT, BUT WE’RE STUCK WITH IT
If you were asked to create categories for food, you would probably do it based on the eventual goal:
• To create a visually appealing meal, you could categorise foods by colour, such as green, orange, and brown.
• To create a nutritionally balanced meal, you could categorise foods as proteins, carbohydrates, fats, sugars, and so forth.
• To create a delicious meal, you could categorise by taste, such as sweet, salty, bitter, and sour.
The goal with application security is to minimise risk, which means locating and fixing as many weaknesses as possible during application development. Ideally, we want a balanced portfolio of security testing tools that results in the safest, most secure application. Unfortunately, the generally accepted categorisation (SAST/SCA/DAST) does not make selecting a full, balanced meal of tools straightforward.
DON’T LET YOUR DREAMS BE DREAMS
The most important thing is to keep sight of the overall goal—that of minimising risk— despite the tangle of acronyms. In application development, this means adopting an SSDLC, which includes a variety of security testing that is automated and integrated with your existing development processes.
You’ll need to choose the security testing that makes the most sense for your application, which does not necessarily align cleanly with the accepted terminology. The exact types of tools will depend on the application type, the language in which it was developed, the platform where it runs, how it is modularised, the other systems with which it interacts, and so forth. Based on the specifics of your application, choose a set of tools that will help you locate and eradicate weaknesses, allowing you to drive down risk to an acceptable level.
Contributed By Jonathan Knudsen, Senior Security Strategist, at Synopsys Software Integrity Group Pictures 123RF
