Design, deliver, and run enterprise blockchain workloads quickly and easily.
Can a company have too much IT security?
Can a company have too much IT security? The answer might surprise you. Let’s consider a hypothetical scenario.
It’s Monday morning and new security features and software were put in place over the weekend, including encryption of data that’s stored on a local drive (called encryption at rest), as well as encryption of data that moves from one location to another within the company (known as encryption in flight).
You may feel more confident that a hacker won’t steal your data, but the increased security is starting to hinder your business. It took just a few seconds to retrieve a customer record on Friday. This morning it takes up to 20 seconds just to see the data. Updating customer records is just as troublesome, and the productivity of the call center has been cut in half as a result. The estimated loss of productivity is costing the company over $2 million a month. The expected impact on customer service, in terms of loss of business, goes well beyond that figure.
It’s the requirements, dummy
While the cry out there is that you can never have too much security, many companies have found that you can. As our hypothetical example demonstrates, turning on all sorts of encryption will certainly mean that your data is safer, but the cost of performance could impact the business in a negative way.
In many cases, the culprit is IT departments tossing technology at a problem. What’s missing is a nuanced understanding of the workloads and data, and how to best protect them. IT departments need to find the appropriate security solution to meet the needs of the company, not exceed them.
So how do you understand your security requirements well enough to match up a security solution and then pick the right technology? Here are three steps to achieve that goal.
Step 1: Define your applications and your data.
While we’d like to provide a general security solution to cover all applications and data stores, the reality is that each application has its own set of properties and thus its own security requirements. For example, if your data contains personally identifiable information (PII), such as patient data at a clinic, then you have security requirements that are dictated by law. This includes certain required encryption levels, and even required procedures and processes for handling the PII data. These procedures can vary a great deal from country to country.
So defining workloads means understanding compliance, but it also means understanding how the application consumes and produces data, and what that data is all about. HR data that could be sensitive may need to be encrypted at rest, but perhaps it’s overkill to encrypt it in flight as well. Some data that’s not sensitive needs minimal security and could perhaps skip encryption. An example would be sensor information coming from a machine in your manufacturing facility to report maintenance issues.
The trick is to deal with each workload independently. This means you have to make a detailed inventory of your systems and understand them at a pretty granular level. Most enterprises don’t like to go through this type of long and laborious process. Instead, they attempt to apply a general-purpose security solution that spans workloads. Do that and you’ll likely over-apply—or, worse, under-apply—your security. Both outcomes can be harmful to the business.
Step 2: Define your security solution patterns.
When you’re creating a security policy, it helps to first create a vision of security for each type of application and data store. By doing so, you’ll better understand what’s important to your organization and the resources you’ll require.
First, define security models and technology that can be applied to each workload or groups of workloads in your company, but do not map the requirements down to an individual technology just yet.
While many in IT tend to jump right into the security technology, even before they understand their requirements, that process tends to yield a target solution that does a poor job of solving the security problem for each workload.
Here are some examples of certain capabilities that could need security solutions. It’s typically a good idea to define them in simple terms, such as:
- Inventory data needs a mechanism to protect it from being removed or copied from the warehouse computers.
- Sensor data from the delivery trucks needs protection when it moves through the network.
- Several layers of access are required to view PII-related data at the clinic.
Look at each workload and decide how best to protect it. Then create a checklist of characteristics that may include the following:
- Compliance. This is usually based on the specific industry, such as healthcare or finance.
- Type of data. This means ranking the data on a scale of 1 to 10, where 10 is highly sensitive and 1 is not at all sensitive.
- Data governance. This refers to policies that surround the data. For example, you can’t update a customer record unless a pending sales record exists.
- Data updates per day. This is how many times the database is hit, and what current performance looks like at the application and database levels.
Step 3: Define your security solution.
After doing the work in steps 1 and 2, it’s now time to pick the technology that will meet your exact security needs, as defined by your workload. This is the most confusing step, considering the number of security solutions that are out there. You must test most to determine function and fit.
I’m not suggesting that you pick different technologies for each workload; you’ll find that many of the patterns we defined in step 2 are the same. It’s more about finding security technologies that fit the patterns or can at least make the short list for testing.
Security technologies that typically end up on the shopping list include identity access management (IAM), federated IAM, encryption, security management, data governance, configuration management, and proactive intrusion protection. These solutions are purchased and tested as products, but they are deployed around the patterns we identified in step 2, and they are tested as integrated solutions for each pattern. Testing determines if the product can work on its own, work and play well with the workloads it protects, and work and play well with other security technologies.
Understand your own path
Determining security levels is about matching needs with capabilities and matching capabilities with the appropriate technology. Security is not a “lock up everything” approach anymore. Many enterprises are under-secured, but just as many are over-secured. Both paths are expensive, either in money wasted repairing breaches or security systems that kill productivity and cost too much. Follow the three-step process above to get the best security at the best cost.
This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.