In this series, we’ve been examining the core concerns of the New Enterprise Application Landscape . In my last post, we looked at enterprise mobility. Today we’ll explore another core principle: Application Security.
The State of Application Security
It seems like nearly every week there’s a new data breach exposing thousands or even millions of personal records: social security numbers, credit card numbers, addresses, even health records. Pair that with a thriving underground for such data and it’s not hard to understand why customers don’t want to entrust us with their data.
This is hardly a new issue. Over twenty years ago, Kevin Mitnick became famous for his ingenuity in hacking and social engineering. So why is this only now becoming such a big problem? The problem is twofold: first, there is a vastly greater amount of digital data in the world today. Secondly, there are so many more vectors for attack. Mitnick used social engineering and dumpster diving because there were so few ways to access systems. Today, every system is networked and nearly every application talks to multiple subsystems and external applications. Add into the mix the hybridization of cloud and on-premise systems and the number of ways that malicious or unauthorized users can potentially compromise a system dramatically increases.
With so many points of exposure, and with such valuable data available for the taking, it should be no surprise that vulnerabilities are being found and exploited on a daily basis.
Approaches to Supporting Enterprise Application Security
Obviously, this is a topic that can and has filled many books, so I’ll limit my comments to a few key areas. The core message I’d like to deliver is this: Security is Paramount. translate . We cannot afford to cut corners on application security, every aspect of our enterprise application stack must be hardened against intrusion. With that in mind, let’s look at a few core components of an enterprise application security strategy.
The traditional approach to data security has been to harden the perimeter of the network, so as to eliminate attack vectors. This has included physical security measures to eliminate access to the machines running your applications as well as using DMZ subnets, closing all unused ports and requiring secure tunnels such as VPN. Such measures are certainly still a critical component of an overall security strategy, and one that most enterprises do well. A notable exception to this success has been securing public terminals such as card readers on ATMs, vending machines, and point of sale systems. No matter how good, however, perimeter security is not adequate in an environment where many systems, both internal and external need access to sensitive data.
The proliferation of web and mobile applications has opened up many new attack vectors. People have been successful at accessing a great deal of sensitive, unauthorized data through the use of attacks like cross-site scripting, sql injection, user impersonation, phishing and certificate spoofing. Specific approaches to preventing such attacks is beyond the scope of this article. The key point here is that any application development effort, whether internal or external facing, must include a robust security analysis to identify and mitigate any vulnerabilities. Likewise, we must insist that the software we purchase from vendors or development shops be held to the same standard.
Encryption of data can be a very effective means of securing a system. Cost used to be a significant limiting factor in the application of encryption, so only the most sensitive data was ever protected. Recently, however, encryption algorithms have become increasingly hard to crack and technologies for applying such encryption are now widely available at reasonable cost. As such, enterprises are well served in including encryption in their security toolbox, not just for highly classified data, but for all sorts of sensitive or protected data. Given that, let’s consider the two primary forms of encryption.
In-transit encryption is the securing via encryption of data being transferred between two systems. The most common example of such encryption is SSL. Whenever we visit a site over https any data transferred between our browser and the server hosting the site is encrypted. This model prevents man-in-the-middle type attacks where someone is intercepting our communications at some point between our system and the system with which we are communicating. In addition to SSL, there are numerous other models for implementing in-transit encryption, and they are well documented with robust tooling for their implementation. Given such ubiquity, in-transit encryption should be the rule for all inter-communication between our systems.
Much less common is the use of at-rest encryption. As the name implies, at-rest encryption is the securing of data where it resides. The reason so many recent attacks have been so successful is that once the hackers were able to breach the perimeter security or find a vulnerability in a consuming application, the data was available in plain text, or at best basic, easily crackable ciphers. The best way to mitigate this is by ensuring that all sensitive data is encrypted at rest. Whether the data resides in a database or file system, it can and often should be encrypted at-rest. Consuming applications can then be built to decrypt such data at runtime and only for so long as is necessary.
Information Rights Management
Information Rights Management (IRM) is the discipline of programmatically applying rules about how a particular set of data can be used. For example, preventing certain files from being downloaded or printed, or preventing applications from taking screen-shots. IRM is typically achieved through the use of metadata associated with the primary data. An example of this would be the read-only flag available for windows files. This metadata instructs the windows operating system to prevent the modification of the file. Another example would be the prevention of playing video or audio files without the authorization of the content owner.
IRM is still in its infancy outside of file-systems and dedicated document management systems such as SharePoint, but it’s easy to see how these principles can be applied to other systems which require granular control over the actions that users can take on data. Expect to see significant growth in this area as enterprises require ever more control over their data and IP.
The Future of Enterprise Application Security
A colleague recently asked me: “what if there was a break in and nobody cared?” It was a powerful question, because it led me to think about what conditions would have to be met to make me not care about a data breach.
Imagine an ecosystem where sensitive data is always encrypted, an ecosystem where data is stored encrypted on the source system, transferred encrypted, and stored encrypted on the consuming application. An environment where applications can only perform those actions which are expressly permitted by the data itself.
In such a world, I wouldn’t care if my perimeter was breached, I wouldn’t care if my application was compromised. Heck, I could hand an identity thief a thumb drive with every bit of sensitive data that my company owns, and it wouldn’t matter one bit because there would be no way for them to convert it into a usable form. In the near future, we’ll see all sensitive data being encrypted throughout its entire lifecycle and all systems that consume that data adhering to IRM policies which are carried along with the very data to which the policy applies.
This is the future of Enterprise Application Security.
About Chris Sorel
Chris is a senior architect with Statera, focusing on enterprise application architecture and application development. Chris has spent many years in the industry evangelizing user-centric design and the role of custom software in helping companies stay innovative. When he’s not helping our clients, he can be found hiking one of Colorado’s 14ers or rock climbing in one of the front range canyons.