Ë
By Security Features • January 9, 2020

Preventing Data From Becoming A Liability

images-5 According to The New York Times, my personal passwords have been hacked six times, to say nothing of my birthdate and Social Security number. Data theft and cybercrime has become one of the fastest-growing "industries" in the world, with 1.3 billion personal profiles being stolen in 2018 alone.   The average cost to a company in the U.S. when a breach occurs is now $8.19 million.

We talk so much about the value of data that we forget that data is also a liability. Handled the wrong way, data can be a career killer.

One problem I frequently encounter in my work is organizations storing certain types of data together in a single table. If a compromise happens, this makes it easier for hackers to reconstitute a complete profile. The classic example is storing personally identifiable information (PII) data — such as names, addresses and birthdates — together with the payment card industry (PCI) data such as credit card numbers and expiration dates. Best practices call for separating the data in addition to encryption, one-way hashing and other mechanisms. Tokenization is another powerful mechanism for greatly reducing the attack surface area.

There are three things you can do to transform your data from a liability into an asset:

1. Train people on the proper handling of data.

Even many people in IT don't know how to handle data properly. They must be made aware of the issues and trained on the proper actions.

Not all data requires the same level of protection. Training in data sensitivity ensures everybody understands which data is under regulatory scrutiny, what can be shared, what can be shared in aggregate and which data elements need to be stored separately.

Many organizations make the mistake of commingling data with different sensitivities. If you merge 500 gigabytes of sensitive data containing customer credit cards into a data lake containing 10 terabytes of public social media data, any auditors are likely to ask you to secure all 10.5 terabytes of data, no matter the sensitivity of the individual elements.

Data handling should be a major focus of training. If a credit card number is being displayed on a receipt or statement, for example, only the last four digits should typically be displayed. This should extend to any system logging. Capturing the full credit card number in a log is an invitation for disaster.

People must also be made aware of the requirements for regulatory compliance, such as to never persistently store credit card verification and identification numbers (CVV/CID). Regulations are constantly evolving, so people must be kept abreast of developments like GDPR, PSD2, PCI or the latest California Consumer Privacy Act and how they affect the company's business.

2. Protect your data from end to end.

Hackers will attack the weakest link in your security chain. It's not just about storing the data in a secure database; it must start with data collection. If a user is entering something on a desktop or a phone, it should be encrypted at the point of origination rather than sending it in the clear.

The same applies to data in transit. Even on an internal network, best practices call for acting as if an intruder was on the network monitoring traffic. All data in transit must be encrypted, perhaps even double encrypted at both the element and transport level.

If an intruder has access to the file system or application memory, then any intermediate files or workspaces are also subject to compromise. There are mechanisms to secure data in process as well.

Finally, you must secure data at rest. Sensitive data should be stored encrypted — even extending to archives and backups — whether on premise or in the cloud.

3. Build security in from the beginning and automate whenever possible.

Typically, information security is an afterthought in building a new software application or implementing a new system. Once the implementation is finished, the security team starts testing it, resulting in a long list of things to fix before the system can go live. Suddenly, the launch date is in jeopardy, and there is resentment and recrimination on both sides — and the security that results is not as tightly integrated as it should be.

When I worked for a major financial services provider, we had similar problems with security testing coming so late in the development process. Instead, we asked the security team to become part of the early planning and development sprints for any new application. We got early feedback on what would make for a more secure approach, and the relationship between the developers and the information security team became more collegial and cordial.

One lesson I also learned from this experience is to perform automatic log scans for oversights and vulnerabilities. The best way to do this is to incorporate it in the early stages of your continuous integration, continuous delivery (CI-CD) pipelines. With the volume of work and the speed that business requires, it's just not possible to do such things manually. Automation is imperative.

Security as a business enabler.

Of course, some of the unauthorized data access we might catch will be people at our own company who have a legitimate business need for the data. Inadequate access can stifle ideas and innovation. The logs can serve as a starting point for a larger discussion on how the company can make better use of its data.

Yes, data can be a liability, but so can overly stringent data security. Security should be a business enabler, providing a secure foundation for trusted relationships between the organization, its employees, its customers and its partners. That way, we can move beyond the fear that our data is a potential liability and know that it has become a true asset for the organization.

 


The post "Preventing Data From Becoming a Liability
" appeared first on Forbes.com written by Anil Somani