Can’t Have Too Much Security? Sure You Can!

Can’t Have Too Much Security

Can’t Have Too Much Security? Sure You Can!

Written by David Linthicum exclusively for Nelson Hilliard

How to Understand Your Requirements

It’s Monday morning, and there is a new surprise at work.  New security features and software have been put in place over the weekend including encryption of the data when stored on the local drive (encryption at rest), as well as encryption of data that moves from the disk to the application (encryption in flight).   

While you may feel more secure in terms of a hacker stealing your data, however, something new is happening.   While it took a few seconds to retrieve a customer record on Friday, today it takes 15-20 seconds just to see the data.   Updates are just as troublesome, and the productivity of the call center is cut in half.    The estimated loss of productivity is over $2 million dollars a month.   The impact on customer service in terms of loss of business goes well beyond that.   

While the cry out there is that you never can have too much security, many companies have found that you indeed can.   As with our example above, turning on all sorts of encryption will certainly mean that your data is safe, or safer, but the cost of performance could impact the business in a negative way erasing most of the benefits.    

In many cases this is just IT security overdoing it, tossing technology at all problems.   Missing is an understanding of the workloads, the data, and how to best protect them.    After understanding the requirements, then finding the right security solution to meet the needs, not exceed them.   Or worse, falling short of the security needed, and it’s “hacked city.” 

Moreover, there is emerging security technology that’s making a real difference out there.   Identity and access management (IAM), for instance as well as multi-factor authentication (MFA).   Of course, this also means that these emerging technologies will likely be leveraged incorrectly by some enterprises, it seems that the number of option out there affects our ability to pick the right one.    

It’s the requirements dummy

So how do you understand your security requirements well enough to match up a security solution, and then pick the right technology?    There are some best practices and a process that you should understand.   

Step 1:  Define your applications and your data, and do so for each workload.   

While we wish we could provide a general security solution for applications and data stores, the reality is that each application has their own set of properties, and thus security requirements.   For instance, if the data contains PII (personally identifiable information), such as patient data, then you have security requirements that are dictated by law.   This includes encryption levels that you must leverage and even procedure and processes for handling the PII data.    These vary a great deal from country to country.    

Defining workloads means understanding compliance, but also understanding how the application is consuming and producing data, and what that data is all about.   Again, HR data that could be sensitive my need to be encrypted at rest, but perhaps it’s overkill to encrypt in flight as well.  Some data, that’s not sensitive, such as sensor information coming from a manufacturing machine to report maintenance issues, and not providing direct control, needs minimal security, perhaps skipping encryption. 

The trick to this is that you have to deal with each workload autonomously.   This means that you’re going to have to inventory your systems and understand them at a pretty detailed level.   Most enterprises don’t like to go through to type of long and laborious process and attempt to apply a general-purpose security solution that span workloads.   Doing that you’ll likely be over applying, or under applying security.   Either is harmful to the business.   

Step 2:  Define the security solution patterns that you need to apply.   

This means that we attempt to define patterns of security models and technology that we can apply to each workload or groups of workloads.    We do this to understand what types of security we can apply in general, not mapping our requirements down to technology yet.   

This logical security planning means that we’re not yet considering the limitations of the security technology as of yet, but instead creating a vision of security for each type of workload considering all of the requirements that are known at this point.    While many in IT tend to jump right into the security tools, even before requirements, that has a tendency to end up with a target solution that does a poor job in solving the security problem for each workload.   

Examples of security patterns are those that deal with certain capabilities, such as encryption, identity, policies, federation, etc.    Look at each workload and define which patterns are right to properly protect that workload, including creating a checklist that may include the following:

  • Compliance, which is usually based on the specific industry, such as healthcare, finance, etc.
  • Type of data, which mean ranking the data from a scale of 1 to 10, where 10 is highly sensitive, 1 is not sensitive at all.   This is typically done by system, not database or data store.   
  • Data governance, including what policies surround the data.   For example, you can’t update a customer record unless a pending sales record exists.   
  • Data updates per day, or how many times the database is hit, and what current performance looks like at the application and database levels.
  • Network transmissions, or how many time the data moves from one system to another over a network.   Such as the user interface processing talking to the remote database server, what type of data is being placed the wire, and how is current networking performance.

Step 3:  Define your technical security solution.   

If we’ve done our work in Steps 1 and 2 it’s now time pick the technology that will meet our security needs exactly as defined, by the workload.    This is the most confusing step considering the number of security solutions that are out there, and the fact that most need to be tested by you 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.   Thus, it’s about finding security technologies that fit the patterns, or least can make the short list for testing.

Things that are typically on the shopping list include IAM, federated IAM, encryption, security management, data governance, configuration management, proactive intrusion protection, etc.    This is purchased and tested as products, but deploy around the patterns we identified in Step 2 and tested as integration solutions for each pattern.   This means that we can determine that not only to the product work on their own but they are able to work and play well with the workloads that they are protecting, as well as the other security technology. 

Understanding your own path

This is about matching the need with the capabilities, and matching the capabilities up with the technology.    Security is not a “lock everything up” approach any more, and many enterprises or under secured, but many are also over secured as well.   Both paths cost money, either in money wasted around repairing breaches, or security systems that kill productive and cost too much.


Remember to Subscribe to our Youtube Channel for the Latest Cloud Computing Tech Jobs, News, and Cloud Shows.


David S. Linthicum is a managing director and chief cloud strategy officer. David is internationally recognized as the worlds No.1 cloud computing industry expert, pundit and thought-leader.

(Disclosure: David Linthicum’s views in the blogs, video shows and podcasts are his OWN and are NOT financially sponsored by Nelson Hilliard)

Connect with David on LinkedIn and Twitter

At Nelson Hilliard we specialise in cloud technologies, sourcing the top 20% of cloud professionals inspired to work for you through our specialised marketing and profiling. If you are interested in having a quick talk to me regarding your employment needs please feel free to reach out.

You can also check my availability and book your 15 minute discovery call here.

Brad Nelson