Data isn’t safe anywhere. Pay a zillion dollars for security, and it’s not going to stop the bad guys from getting in. Just ask the federal government. Or Target. Or Home Depot. Or TJX. Or Sony. Or Anthem.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Maybe it’s better to save all that money, spend zero on security, and simply let the bad guys saunter in through the front door. After all, they are coming. Talk about great ROI. But, we know that would be a hard sell to the CEO, especially in this age of Gramm Leach Bliley information security requirements, HIPAA, and COPPA, the FTC’s Children’s Online Privacy Protection Act.
As a developer, you have several alternatives for dealing with data security. You can build multiple rings around data sets and hope for the best. Of course, that doesn’t protect you if the bad guy is an employee who is already on the inside. (No wonder we don’t hear much about intrusion protection anymore.)
There’s the concept of app wrapping, cloaking a mobile application in a shroud of parameters that might be configured to prohibit local data storage on the device, or self-delete the app after three failed password attempts, or bar saving files to any third party service, such as Dropbox or Google Drive. Fortunately, with app wrapping, you can build your app without much regard for these issues, and apply the cloak as a wrapper around your finished code.
The latest discussion centers around whether to encrypt everything that isn’t already publicly available. The idea makes sense — let the bad guys steal all the data they want, but if it’s utterly unusable, perhaps they’ll eventually give up. Unfortunately, in practice, it gets much more complicated.
You need to think about every employee’s or customer’s device needing to decrypt data in order to use it. That’s big-time processing overhead, depending on the amount of data, not good when your mission in life as an application developer is to keep cutting response times. And when the transaction is completed, you’ve got to re-encrypt for transmission back to the database, wherever it resides. More overhead. And you’ve to build all this into your program code. There’s also the huge issue of key management.
As a developer, how concerned are you with transactional or at-large data security? A lot, because it’s the right thing to do, or not at all, because security is someone else’s job? Are you called into meetings on data and systems security? And are security protocols different, depending where files live?
Share your opinions about application-level data security. We’d like to know about your experiences, and you’ll know that you’re not the only one out there pondering the same questions.