Ron Faith, President and CEO of Datacastle, and I had an interesting conversation about security and data protection. We both agreed that it is surprising, but still true, that many enterprises still view security as an afterthought.
This lack of focus allows some to get by without too much trouble. Others, however, discover that finding and responding to a breach can be an embarrassing and costly process.
Why is security an afterthought?
IT decision makers appear to focus on functional capabilities of their applications, driving down costs and application performance because there is a clear link to enterprise revenue and profitability. IT folks long ago learned that they didn't have time or the resources necessary to do everything, so they've become focused on the 20 percent of the requests that satisfy 80 percent of the business requirements.
Security, unfortunately, isn't high on their list because the link to revenues and profitability is much more indirect and it is much more difficult to measure. This can lead IT to take short cuts that typically work out just fine. The big penalty comes when what was done (or not done) results in data loss.
This 80/20 mindset also often leads to a situation in which IT decision makers think about protecting their systems and data only after one of their friends suffers a serious breach and are publically embarrassed or they discover their own company has experienced a breach.
Has a breach already happened?
It used to be that attackers used a "smash and grab" approach. That is, they would break through, grab customer or business data and leave a mess behind. Although there are many more attacks today, more of them are based upon "social engineering" that results in the attacker gaining access to enterprise systems by tricking staff into providing necessary credentials.
Once those credentials are in hand, the attackers log in, set up camp and wait for useful data to show up. More and more often, Faith pointed out, enterprises have experienced a security breach but don't yet know it because they either don't have a security audit regularly scheduled or they don't have tools that conduct analysis of their own operational data that can tease out indications of an attack, successful or otherwise, long before human IT analysts are likely to discover them.
Some tools that can help
Faith pointed out that there are a number of relatively simple tools and procedures that can be put in place to reduce the "attack surface" the enterprise exposes on the network, including the following:
- Encryption: Encrypting data while it is at rest and while it is in motion makes it harder for attackers even if they have already made a home in the enterprise network. Even if they're able to grab data, it won't be in a form that makes it easy to use.
- Enterprise Key Management: What makes a good key or any other security credential, for that matter, also is difficult for staff to remember or use effectively. Deploying some form of enterprise key management that will act as a repository makes it possible to use longer, more complex keys without also requiring staff to become mentalists.
- Deduplication: Although this might seem to be coming from left field, the use of global network optimiization tools, such as a global deduplication strategy, will not only improve network performance and optimize network costs, but it will also make it far harder for intercepted data to be used. Attackers would have to have access to much more data to be able to recreate the actual data stream.
- Think end to end: Many of today's data breaches start out on a staff member's smartphone, tablet or laptop. Merely securing the enteprise network is no longer enough. Malware can enter the enterprise through a user device and slowly make its way into other areas on the network.
- Analytics: Taking the time to analyze operational meta data concerning data use can lead to preventing data loss. If a staff member's account is being used to access enterprise data from unusal locations or at unusual times, a breach might be in progress. If that account is being used to access information that doesn't fall within the scope of that staff member's responsibilities, that is also a key indicator that something is wrong.
Faith brought up some excellent points, but, of course, these points are only the beginning. While these items are important to consider and demonstrate the boundaries of Datacastle's products, security is a far bigger concern and deserves a thoughtful, thorough approach.
Security must be baked in during the process of application and workload development. Adding it on later is like trying to add the flour after the bread has been baked. That, of course, is unlikely to produce acceptable results.
Does your enterprise build security in while developing and deploying workloads, or is it something added to the mix later?
This article is published as part of the IDG Contributor Network. Want to Join?