Learn what regulations say about data protection and how encryption, tokenization, key management, and system logging can help keep your company in compliance.
With the rise of data breaches occurring all over the world, we’ve been watching closely to see how company leaders are responding to these incidents. To say the least, we have been shocked by what some government leaders and CEOs have said surrounding data security in their own organizations. We believe that some of these sentiments are highly misleading, if not downright false. That is why we have decided to compile these statements into five "myths" of data security. These myths come from direct quotes by CEOs and government leaders.
Myth #1: Encrypting social security numbers is not a standard in most industries, including banks.
Most banks and financial institutions adhere to state laws and industry regulations (such as FFIEC and GLBA) regarding the protection of social security numbers.
For example, California data privacy laws identify Social Security numbers as a critical piece of personally identifiable information (PII) that must be protected using “reasonable security procedures and practices appropriate to the nature of the information” such as encryption or redaction (1798.81.5) . The law upholds businesses within the state, financial or otherwise, to the same data security laws that the state itself must adhere to which state that any business owning or licensing computerized data containing personally identifiable information (PII) such as names and Social Security numbers must protect that data using encryption, redaction, or other methods that render the data unusable in order to avoid data breach notification (1798.29). The average cost of a data breach is $5.5 million (Ponemon, 2012).
The FFIEC IT Handbook action summary states that “Financial institutions should employ encryption to mitigate the risk of disclosure or alteration of sensitive information in storage and transit. Encryption implementations should include: Encryption strength sufficient to protect the information from disclosure until such time as disclosure poses no material risk, effective key management practices, robust reliability, and appropriate protection of the encrypted communication endpoints” (ithandbook.ffiec.gov).
Myth #2: Encryption is too complicated for my IT and database administrators.
Most database platforms such as SQL Server, Oracle, and IBM i are designed to easily implement encryption and encryption key management solutions. SQL Server and Oracle, for example, use Transparent Data Encryption (TDE) and Extensible Key Management (EKM) to easily encrypt data. IT professionals agree that these tools make encryption easier. “TDE is relatively straightforward” - Michael Otey, SQL Server professional (www.sqlmag.com). Encryption with TDE on SQL is “Easy to Implement and administer” -Brad M. McGehee, SQL Server professional, MCTS, MCSE+I, MCSD (http://www.bradmcgehee.com).
Learn how to set up TDE and EKM on SQL Server 2008/2012 in 10 minutes or less here.
Myth #3: Data breaches are usually caused by highly sophisticated hackers.
The top four mechanisms for a hacker to break into a company’s network are: exploiting system vulnerabilities, default password violations, SQL injections, and targeted malware attacks (Symantec, 2009). These techniques are not considered highly sophisticated. They are used often to penetrate networks with inadequate security.
Curious what the final two data security myths are? View "5 Data Security Myths Debunked: Part 2" to find out if there is really nothing you can do to prevent your company from being hacked and whether or not CEOs should be concerned about data security.