The Data Breach – How did it happen?

I lost my laptop and it had a database backup on it.

My finance software used an ODBC connection and it had the password hard coded.

I was logging into a game on my phone and by accident, I typed in my domain password. “I only did it once”.

We gave the new contract DBA access to the databases so he\she could support the data warehouse.

Of course we can access the database remotely from any computer.

… and so many more.

Data security, we hear the headlines almost every day. Yesterday it was a bank, today it was a retail franchise and tomorrow who knows. Security experts have overwhelmingly agreed that the least effective approach to data security is “penetrate and patch”. It is far more effective to “bake” security into your database solution from its inception and throughout its life cycle. But in many cases, doing that is much more difficult than one can imagine. Firstly, most security experts are experts in securing networks, routers and operating systems, not a SQL server installation or application back-end. That, in many cases, is left up to the application manufacturer, the in-house DBA’s or outsourced contractors. Secondly, many DBA don’t have the time to drop everything and implement enhanced security measures that will only cause them more headaches and increase their overhead. Finally, many are happy to do only what is necessary to pass a data audit, knowing that most are paper audits and not actual “show me the encrypted data packet” type audit that will catch configuration issues that would allow an insider to steal your most prized assets.

Database communication encryption at rest and in play

Years ago, it was a common practice to only encrypt data while it was being used to complete a secure transaction. An example would be to only encrypt the data while specifically transmitting the credit card information. Once that was complete, the channel would again be unencrypted. Almost always, the reason given was that there was too much overhead on the server to keep everything encrypted or that it was just too cumbersome or complex. Often, the transaction would be segregated and placed into a shopping cart and only encrypted while in the shopping cart and nowhere else. Luckily, those days are over and whether it’s a credit card transaction or client computers working within a finance department, all data communication (from client to database and vice versa) should be encrypted. But data in play is not the only place where an insider can gain access to your data and database. Your databases should also be secure at rest. We can no longer rely on domain security to protect our data or databases. To that end, Microsoft has given us a fully integrated toolbox of data security features that include (but are definitely not limited to) the following:

Always Encrypted enables encryption inside client applications without revealing encryption keys to SQL Server. It allows changes to encrypted data without the need to decrypt it first.

Transparent Data Encryption (TDE) protects data at rest by encrypting all the user data in data files. TDE prevents users from attaching or restoring a database to another server as a way to access the data.

Support for Transport Layer Security (TLS), which has now been updated, protects data in transit and offers protection from such tactics as man-in-the-middle attacks.

Dynamic Data Masking (DDM) and Row-Level Security (RLS) help developers build applications that require restricted direct access to certain data as a means of preventing users from seeing specific information.

Data security has unquestionably become a major priority for Microsoft. A recent news story reported that the company “is spending $1 billion a year to make Microsoft products more secure.” The Microsoft data platform, including SQL Server and Azure SQL Database, is at the top of the list of products investing in security.

So how do you start down the path to a more secure data and database environment?

It’s easy, if you use Microsoft SQL Server you’re on the right track. With SQL server, Microsoft has already supplied you with the tools to a more secure data environment. In many cases, you just need to learn how to use and implement them.

Focused hands-on training that makes a difference

Our technical course “Implementing In-depth Data Security and Auditing for Microsoft SQL Server” is an intense database security training workshop/seminar essential for DBAs, developers and auditors who need to learn how to secure their databases, their data and harden their overall SQL Server installation. In addition to teaching the hands-on skills needed to secure your data and data access, this course digs deep into sound practices that apply to the entire process of security within your data infrastructure. Perhaps just as significantly, you will learn how to test audit your data to ensure what you have configured actually works.

Come join us for three days of Hands-on Microsoft SQL Server Security Training. Contact your LearnIT sales rep for more information, class dates and enrolment. A full syllabus can be found on the LearnIT website.