What’s the difference between IT security and application security? And what do all those acronyms mean? Learn more in our quick cyber security primer.
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. (For an example, see Fuzzing Does Not Mean Random.)
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.
In most organizations, 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 organization.
IT security is part of the information technology group, which is generally responsible for supplying the computing infrastructure for an organization. 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 organization 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.
Also known as product security, the application security team is responsible for the security of software produced by the organization.
Flaws and vulnerabilities in an organization’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 minimizing risk in application security. Organizations using an SSDLC are always thinking about security, from the design phase through implementation and maintenance.
Security activities 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.
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, SIEM, IDS, and 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, 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 centerpiece of application security is the adoption of an SSDLC, which uses a proactive approach to minimize 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:
If you were asked to create categories for food, you would probably do it based on the eventual goal:
The goal with application security is to minimize 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 categorization (SAST/SCA/DAST) does not make selecting a full, balanced meal of tools straightforward.
The most important thing is to keep sight of the overall goal, despite the tangle of acronyms. The overall goal is minimizing risk. 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 modularized, 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.