Modern computers are almost certainly the most complex things ever designed and built by man. It's not uncommon to have software applications that contain tens of millions, or even hundreds of millions, of lines of source code. And that complex code runs on processors that might be even more complex—there are now generally available processors that comprise tens of billions of transistors.
But that complex technology, though it may seem to work well enough for many purposes, also contains an unprecedented number of bugs, and some of those create security vulnerabilities that hackers can exploit. This means modern computers will probably never be perfectly secure. This is a side effect of having complex technology.
The usual way to measure bugs is by defect density: the number of bugs per thousand lines of code, or per KLOC. With even a small number of defects per KLOC, that leaves you with lots of bugs in a typical application. Some of those bugs will create security vulnerabilities.
It turns out that the people in my company's Fortify division have lots of data about the trends over time in terms of the number and types of vulnerabilities. Some of their thoughts on this, and related topics, are now available in the Application Security Research Update 2018.
What I found the most interesting about this report, however, was its thinking about how software works from a high-level point of view, and using that to think about where to encrypt sensitive data. This is a hot topic in the age of the EU's General Data Protection Regulation (GDPR).
Framing the notion of data encryption
The TCP/IP protocol suite (named for two of its components: the Transport Control Protocol and the Internet Protocol) defines the communications protocols used in most of today’s computer networks. One notable feature of TCP/IP is how it abstracts the functionality of a computer network into four layers that we think of as comprising a "stack." In this stack are multiple logical layers that process information between adjacent layers.
The TCP/IP stack comprises four layers: application, transport, IP, and network access (sometimes called the link layer), as shown in Figure 1. As the arrows in Figure 1 suggest, information passes only between adjacent layers in the TCP/IP stack. So a process running at the transport layer can pass information to a process running one layer away at the IP layer, but not to one running two layers away at the network access layer.
Similarly, it's useful to think of encryption as taking place at different levels in the TCP/IP stack, thus creating a notional "encryption stack" that closely parallels the TCP/IP stack.
The Transport Layer Security (TLS) encryption used by secure websites, for example, operates between the application layer and the transport layer. IPSec encryption, used to create virtual private networks (VPNs), operates at the IP layer. Link encryptors operate at the network access layer. Full-disk encryption (FDE) operates below the network access layer, as does database encryption.
Why to encrypt at various levels
There are good reasons to encrypt at different places relative to the TCP/IP stack, but when you encrypt at a particular place in the stack, the encryption only protects against threats that target at that layer or below.
If you protect data with FDE, for example, you protect the data while stored on encrypted disks. When the data leaves the disks and moves to the network access layer, however, it's no longer protected.
So if a cybercriminal manages to steal a hard disk that is encrypted with FDE, he will probably be unable to access its contents. But if he intercepts information being transmitted across a network, the FDE provides no protection .
Similarly, malware that reads data from a hard drive protected with FDE will be unaffected by the FDE; once the encrypted data is read from the hard disk, the FDE no longer protects it.
Likewise, database encryption protects data only while it is stored in a database. When the data is read from the database, the protection provided by encryption is lost, so attacks that operate at most levels of the encryption stack will be unaffected by database encryption.
And if you are using TLS to encrypt data between the transport and application layers, that will protect against attacks that target the transport layer, the IP layer, and the network access layer. But it will not protect against attacks that target processes running at the application layer. Once data that encrypted with TLS gets passed up the stack to the application layer, the TLS encryption can't protect it.
Encryption at the application layer
The interesting idea in the Application Security Research Update 2018 report is that it is possible to think of operating system components as having a similar hierarchy that is roughly comparable to the TCP/IP stack, and that it is also possible to think about encryption relative to the components of this much more complicated stack.
Clearly, there are many advantages to encrypting at the application layer. What is less obvious is how to extend this general model to thinking about the relative benefits of encrypting in different parts of more general and complex software, such as an operating system.
Fortunately, the Fortify research team has already thought about this. You can find some of their thoughts on the topic in the report. That alone makes it worth the effort to download it.
Keep learning
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed fast on the state of app sec testing with TechBeacon's Guide. Plus: Get Gartner's 2021 Magic Quadrant for AST.
Get a handle on the app sec tools landscape with TechBeacon's Guide to Application Security Tools 2021.
Download the free The Forrester Wave for Static Application Security Testing. Plus: Learn how a SAST-DAST combo can boost your security in this Webinar.
Understand the five reasons why API security needs access management.
Learn how to build an app sec strategy for the next decade, and spend a day in the life of an application security developer.
Build a modern app sec foundation with TechBeacon's Guide.
