APRIL 2018CIOAPPLICATIONS.COM9Information security audits that result in a SOC2 or HiTrust certification are deemed as good benchmarks for a company's commitment to protect data. It's true that both force a company being audited to evaluate, correct and maintain internal processes, as well as technology infrastructure that protects data. They also require standards around password change frequency, security training for employees and patch management. All of these things help assure that the most common vulnerabilities are dealt with and that all reasonable steps are being taken to protect information. However, most of these methods are focused on putting a fence around applications and databases that were not necessarily designed with security in mind when they were built. I believe that the way the security space will evolve includes getting into the database architecture itself. What do I mean by this? Let's start by defining two types of data. The first is data that belongs to a person. This includes PII (Personally Identifiable Information) and PHI (Personal Health Information) as well as other categories. By definition, these are only sensitive, and therefore are targeted, because they are tied to a person. Knowing who the data belongs to gives it value. For instance, a birth date isn't valuable by itself but if it is tied to a person, it definitely does have value. Combine a birth date with gender and a geographic data point (like city address) and there are plenty of ways to figure out the exact person to whom the data belongs, even if their name is unknown. In contrast, individual data points like height, weight, BMI, salary, or prescription drugs taken are of no value without linking them to a person.The second type of data is harder to "de-identify" and harder to secure because it has value in and of itself. A list of software vulnerabilities or a decryption code is hard assets and valuable to someone who wants to cause harm. Sure, a list of people who are using the vulnerable software is of value too, but is not necessary to do real damage if the wrong person gets their hands on information like this.Architecting for security involves rethinking how you structure databases and applications. This includes when you should use logical versus physical separation of data as well as how you minimize the need to access the data points that create truly identifiable and therefore valuable information. If you create a random identifier to store with a transaction, and remove all the PII in the process, you've made the transaction data less valuable and reduced your risk. There are very few systems or workers who really need to know to whom that transaction belongs.At the end of the day, protecting information is hard. Broad use of strong encryption, like cryptography, is coming and will help companies protect data better. However, there aren't a lot of experts to help you figure out what it is and how to use it today, so don't expect to find a silver bullet out there waiting for you. As a technology leader, you need to take data security seriously and make it a priority. No matter what your role is in the organization, you need to convince those above and around you that your company needs to deal with this. If they haven't already, customers and consumers will soon be knocking on the door asking for more proof of protection against the latest threats. The risks are just too great.Three things to do this month are:· Get educated· Talk to your peers, go to a conference, listen to a security podcast· Spend some time and money on security architecture· Look for independent outside help but don't defer responsibility to them.· Ask your application, database and infrastructure teams a simple question: "Is our data secure?" Knowledge about your data and how it is stored is fundamental to surviving audits and designing protection that lets you sleep at night Tom Basiliere
< Page 8 | Page 10 >