Voice of the DBA

Tag: security

  • Not So Unbreakable

    Nothing is unbreakable

    There’s a report on Dark Reading that says some researchers think Oracle is not working on security as hard as they should. The proportion of security fixes has diminished, which some people think implies that they are not taking security as seriously as they should. The window of time between the disclosure and the patch has grown wider, which is troubling, especially when newer software displays vulnerabilities.

    I’ve been proud to work on SQL Server over the last 6 years from a security perspective as there have been very few security patches issued, and correspondingly, few vulnerabilities disclosed. It’s possible Microsoft has muzzled some researchers, but I doubt it. I would guess that if any serious security issues existed in SLQ Server 2005, 2008, or R2, we’d have heard about them. I think the security engineering process that is used for SQL Server has truly resulted in more secure software.

    It’s possible that Oracle faces a resource issue with all their acquisitions, but for a billion dollar company that employs over 100,000 people, they shouldn’t be having resource issues with their development process. It’s a question of accepting greater development costs in order to ensure their software is secure.

    This is one area where we ought to have independent security researchers that can discuss, debate, and disclose vulnerabilities, after a limited amount of time. That would help us at least understand the security risks we face, and perhaps pressure companies to build better software.

    Steve Jones

    The Voice of the DBA Podcasts

  • Layers of Security

    Every little bit of security helps

    I haven’t configured many firewalls in my time, but if I were doing that job, I’m sure I’d be included in this report that says half of all firewalls are improperly configured. Firewalls are confusing, complicated, and it’s incredibly easy to make a mistake when you are dealing with the complex rules of Windows networking and various application requirements. These days I call a friend, who’s a firewall expert, to do any changes for me, and let him implement the rules. It’s a slow, annoying process to watch, but I also understand that it is complex task, and he does a much better job than I’d do. Probably because he’s more patient.

    For the database administrator, however, this should be a wake-up call that lets you know you can’t rely on the firewall to protect you. If you have a small 3 machine, one subnet network, maybe, but in most enterprises there are many subnets and complex rules to implement. That means that your company might not be a soft chewy center protected by a hard shell. It might be a soft center protected by Swiss cheese that does little to limit the influx of unauthorized requests.

    Good security involves lots of strict policies, strong passwords, and many layers. Depending on someone else to provide security for your database instance is not only a bad idea, it could be a reason to remove you from your position. Good administrators, and developers, will ensure that they enable security on their servers, limit access to authorized users, and grant appropriate rights.

    It’s a good habit to get into, and it’s good practice for developing an application that will remain secured once it’s deployed.

    Steve Jones

    The Voice of the DBA Podcasts

  • 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