Voice of the DBA

Tag: security

  • Not having TDE in all editions is stupid

    A must read for those looking to protect their data

    The whole point of encrypting data at rest is to protect the database if physical files or backups are lost. In the Books Online (BOL) page for Transparent Data Encryption (TDE), it notes that “…, in a scenario where the physical media (such as drives or backup tapes) are stolen, a malicious party can just restore or attach the database and browse the data. One solution is to encrypt the sensitive data in the database and protect the keys that are used to encrypt the data with a certificate. This prevents anyone without the keys from using the data…”

    That’s what TDE is designed for, but the machines that are most likely to be stolen, laptops that contain Express Edition instances, can’t implement TDE. Why not? It’s an “Enterprise only feature”. Why? I assume this is a sales technique to force those companies required to implement data at rest protection will pay more for their instances, but in reality this results in less security for lots of SQL Server applications.

    Recently a healthcare organization was in the midst of performing an encryption rollout to laptops and an unencrypted desktop was stolen with sensitive data on it. I know that TDE wouldn’t prevent this, but how many machines lose data that is unencrypted? How many applications built with Visual Studio store data, potentially sensitive data, on a local Express instance? I know that people can encrypt their entire disk (and they should), but what about their backups? What about copying a file to another machine? There are no built in protections, when there easily could be.

    I can understand partitioning, Resource Governor, and a few other items being Enterprise only, but a security feature? That strikes me as a poor decision all around.

    Steve Jones

    The Voice of the DBA Podcasts

  • A Welcome Intruder

    Have you every tried to get past your own security?

    One of the things that many large companies do is hire companies to evaluate their security. This often involves some sort of test of the security systems by an individual whose experise is breaking into companies. There are some experts who study the techniques used to break security, but I suspect that often former hackers/crackers are hired because they have practical experience breaking into systems.

    However for most companies, the security is only examined when there is an actual issue. I know most IT people that manage web systems are told about security lapses when the site si defaced, or when your data is discovered posted in some other location.

    This Friday I wanted to ask this question:

    How many of you have attempted to penetrate your own systems?

    You could do it yourself or get a friend to try, but have any of you actually performed some type of penetration test and what did you do? I typically haven’t at most of my jobs, but I have spent time thinking about how I would penetrate the systems and then made an effort to close any holes.

    My feeling is that most of the data breaches or losses occur because of attacks against the weakest links in the security system: humans. Social engineering, which taking advantage of most people’s good nature and desire to help others, is usually the biggest problem. Theft of laptops is also an issue, but I think the targeted attacks specifically aimed at your company is fairly rare. The exception would be SQL injection attacks, which spring up constantly at site after site, mostly because of poor development practices.

    We can get better at securing our systems, but it takes some effort, and a belief that we are vulnerable. Maybe setting up a test against your own systems will convince you, or more importantly, your boss, that it is worth the time spent better securing your systems.

    Steve Jones

    The Voice of the DBA Podcasts

  • Power Tools at Work

    This editorial was originally published on Jan 17, 2007. It is being republished as Steve is on vacation. 

    Now this could be fun. Just imagine your boss comes to your cube with an electric drill, a sledgehammer, and a circular saw. Oh, and don’t forget the safety glasses. You’ve got work to do.

    That’s what is happening in some IT shops as old data drives need to be destroyed with no hope of the data being recovered. I saw this article on data demolition and thought that might actually be a fun afternoon at work. Destroy some old data drives, ending their usefulness like the fax machine in “Office Space” 🙂

    Data security is becoming a bigger issue all the time in the corporate world. And as more companies store more and more data on disk, the issues with disposal must be dealt with by more and more IT groups.

    I guess you could hire a firm and get this before and after picture:

    Now this might be fun.

     

    but I’d think that defeats the purpose somehow. It’s the physical access outside your company that can be the problem. Going to a vendor specializing in destruction could be a problem since it gives criminals a single source (or a smaller source) or vendors they can bribe to get critical data. Better off letting different people in your company destroy the data at random intervals. That way no one can predict where and when the data will be destroyed.

    Plus it would be fun 🙂

  • More SQL Injection

    If you can't prevent this in your application, you need to think about upgrading your skills.

    One milly-yon sites hit by a SQL Injection attack. That happened according to a headline I saw recently, with an attack similar to Lizamoon affecting seven figures worth of ASP.NET sites. How can this still be happening on large scales? I’d like to think that this was mostly at small sites that people had set up for themselves, but I’m sure some decent sized companies were involved in this.

    This isn’t good for your brand as a developer. If you don’t know what SQL Injection is, you shouldn’t be developing software. If you don’t know how to code to avoid it, you shouldn’t be hired by anyone to build software. If you can’t write a stored procedure around a query or built a parameterized call to a database engine, you need to learn how or find another career.

    It’s sad that years after we’ve had the SQL injection problem make headlines, and change the way many companies write software, we will have thousands of applications being used every day that are still vulnerable to this type of attack. There is a lot of old code out there, but it can’t remain. We are regularly adding new data to our systems, and new data to applications. There’s no excuse for companies not making a complete review of older code and updating it to avoid unvalidated input or passing through queries that could be hacked.

    Educate yourself, save these headlines for your boss, and ask that no new applications, including third party ones, be purchased if they haven’t updated the code to prevent SQL Injection attacks.

    Steve Jones

    The Voice of the DBA Podcasts