Encryption isnt a fairy dust that developers can sprinkle over work that was done without application-level security in mind. Its not even a single attribute that can be added in varying degrees that trade off strength against performance. Different domains call for differing definitions of what kind of security is relevant, as well as what modes of security are feasible.
England-based nCipher, founded 10 years ago by brothers Nicko and Alex van Someren, has made its mark by wrapping enterprise-class infrastructure around the kernel of potential protection provided by strong encryption algorithms.
Company Marketing Vice President Richard Moulds and Data Encryption Product Manager Jeff Montgomery, both in Stoneham, Mass., spoke with eWeeks Peter Coffee about the need for developers to go beyond questions of algorithm choice and key length to make their application portfolios end-to-end secure.
It seems that application developers need a growing knowledge of data protection from the point of data entry through intermediate storage and during all interactions with users. What does the developer need to know about the role and the structure of crypto technology?
Montgomery: One of the first things that developers need to get their heads around is the threat model that theyre trying to protect against. Any organization thats implementing encryption has to have a clear understanding of what that is. It might be dictated by a compliance issue or regulation, or by their own policies. Does the enterprise only care about people stealing tapes? Or about access to points in the application stack?
Once they have a clear understanding of what that threat model is, they can begin to look at the types of integration strategies that they have to put in place; once they start looking at integration strategies, theyll need to look at the different technologies that are in place at different points in the stack.
From a technology standpoint, what types of approaches do they have to take? Thats going to depend on whether its a homegrown app or a packaged app. It might be a packaged app for which they have some access to the code, [or] for which there are well-defined entry and exit points.
Ultimately, it comes back to the level of security theyre looking for: What are they doing with the data? Whats the level of granularity? Whats the level of security they have to provide?
Its important to make sure that administrative accounts dont have all access to data: separating out the traditional file or database admin roles, pulling out the security admin role from that, putting a piece in place so there isnt any one superuser.
Is that something that platforms facilitate better today, compared with 10 or 20 years ago when pretty much by definition there was a "god user"?
Montgomery: There still is a "god user." I think the database vendors and packaged application vendors are starting to think about it. Theres an inherent issue in that these things are architected with these superusers. You have to change the administrative model. The only way to truly achieve [privilege] separation is to have a management process outside the scope of the application, which means you have to build into the application entry and exit points—where the application can make a request for, say, an encryption key thats managed by someone else.
We are seeing that. I know that SAP has put some hooks in there to try to facilitate that kind of thing. A lot of the homegrown apps that people have written dont have that in there, but people are going back in to retrofit that type of process.
Despite the best efforts of the largest application vendors, people still have a myriad of different business apps that theyre running in their environment. If you separate out the administration of keys and that separation of duties, you create a need for a management application to make sure that security policies are uniformly enforced across all the different applications that might access sensitive data.