Application security redux: It’s All about the Apps (Part 7)

If you would like to read the other parts in this article series please go to:


In this article series, we started in Part 1 with a broad overview of application security, some of the different types of application security issues, and coding defects, as well as types of app vulnerabilities. In Part 2, we began with a look at how to protect applications from tampering or access and also took a closer look at the special case of mobile applications. In Part 3, we discussed how you can block undesirable applications and restrict what users are able to do with the apps that you do allow them to use.

In Part 4, we started to explore Microsoft’s AppLocker, and in Part 5, we delved into the use of PowerShell to configure and manage AppLocker. In Part 6, we discussed the new ability to control apps in Windows 10 mobile devices.

It all comes down to the data

Application security, when you get down to the nitty-gritty, isn’t really so much about protecting the applications themselves as it is about protecting the data that’s generated, processed or stored within those applications. Sure, we want to avoid having to deal with reinstalling apps that are corrupted by attackers, and we want to control which applications can be run on the company’s devices and network, but the really important, irreplaceable element in all of this is the data.

Application data comes in a variety of different forms – text files, documents, numbers and spreadsheets, photos and videos, slideshows, lists, and so forth – and that’s what makes securing it all more complicated. In addition to the variance in form, data also varies in importance: some is mission-critical, some is of trivial importance, and much of it falls somewhere in between. Another way that data can be categorized, and the one we usually think about when we talk about data classification in the context of data security, is the level of sensitivity or confidentiality.

Some data is safe for public release; some requires minimal controls, and some – such as customer credit card and bank account numbers, employees’ personal information, patients’ medical data, the company’s trade secrets, etc. – could cause a disaster if it got into the wrong hands. Some of the foregoing fall under government regulations and exposure could result in fines or worse. Short of that, a data breach could seriously damage the organization’s reputation and result in lost business.

Securing such data, whether under legal mandate or not, is probably the single most vital part of your application security strategy, since the ramifications of failure to do so are so serious. Yet many companies obviously haven’t figured out how to do data security right; according to Breach Level Index (BLI) statistics, more than seven hundred million data records were breached in 2015.

It’s complicated

Data security is one of those things that sounds simple in theory (Just encrypt it, right?) but becomes complicated in practice. The problem is that not only do we have many different types of data, but that data exists in many different locations, and the same data has to be secured differently depending on its current state – that is, whether it’s at rest, in transit or in use.

Data can reside on local hard drives, on local network file servers, on local network storage devices (NAS or SAN), or somewhere in the cloud. Some data exists only while it’s in the volatile memory (RAM) of the computer or device. Then there’s mobile device data, which presents a different and more challenging threat model in comparison to data on a desktop computer or server. And as if that weren’t enough, we also have to contend with data when it is arguably in its most vulnerable state of all: while it’s moving between one location and another – especially when it’s being transferred across the public Internet.

Another complication that arises in regard to securing application data is that security is, by its very nature, user-unfriendly. Encrypting data takes time and processor cycles, which slows down most systems. Worse from the users’ point of view, it often makes it more difficult for them to access the information that they need in order to get their work done. They have to jump through hoops, enter passwords or otherwise authenticate to decrypt the information. Security and convenience will always live on opposite ends of a continuum; the more you have of one, the less you have of the other. Thus many users will be resistant to any security measures that don’t operate in a completely seamless fashion.

The data security solutions matrix

In fact, while encryption is at the heart of data security, there are a number of different types of encryption, some of which are more secure than others. We’ll take a look at some of those a little later in this article.

Protection of data starts with restricting who can access the computer system and/or the network, and that is accomplished through policies that require strong authentication to log on. Username and password authentication is still the standard in many organizations, but multi-factor authentication is becoming more popular. Organizations have many options in that regard today, including smart cards, tokens, smart phone authentication, fingerprint, iris/retinal scans, pattern recognition, PIN or facial recognition technologies as a second factor in addition to traditional credentials.

Just because a user is trusted to access the computer or network, however, that doesn’t mean he/she is trusted to access all of the data that’s stored there. Thus a second step in protecting sensitive data is to implement effective access controls. Access controls involve setting permissions regarding which authenticated users can access specific files, folders or drives/volumes, and exactly what they can do with the data when they access it (read only, modify, delete, etc.).

Next, we come to ways to encrypt the data when it’s at rest. We won’t go into the technicalities of various commonly used crypto algorithms – DES, RSA, AES, etc. – or the basic encryption methods (symmetric, asymmetric and hashing). We also won’t go into the specifics of encryption keys, key management and key exchange. There are many resources out there on the web that cover that information, and you have only to do a web search for “cryptography” to find yourself awash in far more detail than you could ever want.

For purposes of this discussion, data on disk is generally encrypted in one of two ways: at the file level (which involves encrypting individual files and/or folders) or at the disk/volume level (which involves encrypting the entire drive or volume). In Windows, file level encryption is generally done using the encrypting file system (EFS) and volume level encryption is done using BitLocker.

Data in transit is a different story. The encryption methods used to encrypt stored data generally don’t protect the data when you send it across the network. To prevent an attacker from intercepting it and reading it, it needs to be encrypted. Web-based data traffic is usually encrypted using Transport Layer Security (TLS), which is the newer iteration of Secure Sockets Layer (SSL). Non-web data can be encrypted using VPN protocols such as IPsec or SSH tunneling. Email can be encrypted using S/MIME or PGP.

Finally, sensitive data needs to be protected from the possibility that an authorized user, who has been granted access to the data, might – either deliberately or accidentally – share it with persons not authorized to access it. This could involve forwarding email, copying and pasting information from a Word document, printing the content and leaving it where someone could see it, and similar scenarios. On Windows networks, this can be prevented by implementing Active Directory Rights Management Services or Azure Rights Management. With Rights Management, the owner/sender of a file or message can set rights on it that restrict what the recipient can do with it. You can block the ability to forward, modify, copy, or print, and you can even set a time period after which the file is no longer accessible by the original recipient.




Data at rest

Untrusted users

Password authentication

Multi-factor authentication

Data at rest

Unauthorized access

Access Controls

Stored data encryption:

File level encryption

Disk/volume level encryption

Data in transit

Capture and unauthorized access

Network encryption

VPN protocols


Documents and email

Sharing by authorized users with unauthorized users

Rights Management

Wrapping it up

We’re almost at the end of this multi-part series that takes a fresh look at application security, and next time in Part 8, we’ll wrap up both this topic – how we can secure the data generated, processed and stored by our applications – and the entire series, as we delve a little deeper into the challenges inherent in developing an effective data security strategy and particularly the problems of securing mobile device data and securing data that’s stored in the cloud.

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top