Voice of the DBA

Tag: security

  • T-SQL Tuesday #35 – Soylent Green

    tsqltuesdayThis month’s host is Nick Haslam (b | t) and he bases his question on the movie Soylent Green, which I haven’t seen. This month he asks what the most horrifying thing you’ve seen in SQL Server. It’s been a long few weeks for me, so I‘ll keep this short.

    As an FYI, if you want to host or participate, contact Adam Machanic.

    Horrifying

    The thing that first comes to mind for me is my first job in Denver. I had interviewed with a small financial services firm looking for a DBA. We thought it was a good fit and I came out to start work in early 1999. Fortunately my wife stayed back in Virginia to sell our house and I was alone since I ended up working a lot.

    The first surprise I had when I arrived for work was that not only was I responsible for the databases (v6.5), but that I was also going to manage the network administrator. He wasn’t that experienced and needed some guidance because we were experiencing daily problems.

    The second surprise was that all of our applications used the sa account. We had 3 or 4 standalone workstations devoted to loading pricing and position information every morning from clients, all using SA. We also had a web application and a thick client application (VB6) that allowed clients to authenticate with a name and password (stored in plain text) in the database, but the connection to SQL Server as with sa.

    However the most horrifying thing was that all developers used the “sa” account to connect to our database servers, in development, QA, and production, with the same password.

    A scary situation.

    The daily issues actually helped here. I started to tackle our problems, requiring the developers to fix the applications one by one, using a normal user account. It required months just to convince our management that stability was compromised by developers making changes in production, but we were able to change the sa password in all environments and make it different. We then started to require applications to use difference accounts, and a year later, we had ad least provided more stability by removing the “quick fixes” made in production.

    All sorts of poor practices at that job, and when I left after almost two years, there were still numerous issues.

  • Outsourcing Security

    firewall
    Are security services like this going to be outsourced in the future?

    Security is becoming more of an issue for many companies. Increased regulation, more scrutiny from the media, and customers that are more concerned about their data handling and privacy are forcing companies to spend more resources to ensure better security. However building secure systems takes skill and experience, something many companies lack. Acquiring those skills can be hard, and I think as an industry, we do not disperse information on secure coding well. If we could get developers and administrators to read about security with the same level of interest they show in the iPhone 5 v the Galaxy S3 v the Lumia 920 debate, perhaps things would be different.

    One vendor is betting that companies will look to outsource security needs. Webroot has moved to a hosted service, confident that customers will move to the new service for its ease of implementation and arguably better protection. By controlling the software themselves, and updating it as quickly as possible to meet new threats, Webroot can do a much better job of ensuring security than most companies can by managing the service themselves.

    That’s an interesting idea, and it’s similar to the idea of threat detection that Bruce Schneier wrote about a decade ago. This doesn’t solve application issues, but it can improve security for threats that attack your network. That’s if the vendor actually does their job correctly.

    There are any number of issues with this model, but as more companies get comfortable with the idea of renting services and platforms, moving to the “cloud”, I can see this idea growing. For us in the data world, this means that we have another group to interface with, potentially audit to ensure they are not violating any data protection. As far as your actions if you find issues? That can be complicated, but it certainly will require that your communication skills are strong.

    The Voice of the DBA Podcasts

    We normally publish three versions of the podcast each day for you to enjoy. Today there is no podcast due to Steve being ill. Hope to have the podcasts return tomorrow.

  • Rewrite the Coding Rules

    Cryptanalyses
    It’s becoming more important to code securely.

    Security is a problem in technology. Whether it’s technological misconfiguration, social engineering, or brute force attacks, we see a constant stream of headlines about security issues. The situation is not likely to change anytime soon as security isn’t seen as a priority by many companies. If that’s the case, then is there anything that can be done to improve security?

    Security expert Dan Kaminsky says that we need a fundamental change in the way we write code. By rewriting the way that code is developers, rewriting the rules, we can reduce the vulnerabilities in our applications. One theory is that our languages and the coding techniques used are making it entirely too easy for vulnerabilities to creep into code.

    It’s an interesting theory, especially these days when it seems so many of our applications are under attack. I suspect that we have lots of poor habits ingrained in many developers. People are loathe to change and they like to continue working in ways that have worked for them. However the world of security in software changes constantly. What might have made you a very effective and productive developer five years ago might make you a liability today.

    I believe that we need to somehow build new coding methods, but even more importantly I think people that provide sample code and framework need to do so in a way that showcases best practices and good habits from a security perspective. That includes presenters, who should never show security issues, even if it’s for the sake of simplicity. Raise the bar and your audience will come along with you.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Data Worms

    The FLAME malware
    Are we going to see more and more targeted cyberwarfare attacks in corporations? I wouldn’t be surprised.

    Effective data administration include backups. I would argue this is the most important part of managing your data since no matter what happens, backups give you the ability to recover your system. Whether it’s an accidental data modification by a user, a hardware failure, a natural disaster or some other event, having a copy of your data (or log) on some other system or media can be the difference between getting back to work and having to go find other work.

    For the most part we’ve been concerned over disasters that are random, and while they may be destructive, their effect is usually limited in scope. SQL injection attacks often affect a single system, and with a good backup, you can usually recover your data quickly. However that may be changing as the world grows closer together.

    The Shamoon malware has been causing problems lately and making companies rethink their incident response. The worm has wiped workstations and destroyed data. Destructive software is nothing new, but as more and more cyber warfare takes places at the government level, it’s likely that retaliation might target civilian targets, especially successful companies. I’d hate to think that destructive malware might target databases, but I’m sure it will. The SQL Slammer worm was a complete disruption of our database services for days at JD Edwards almost a decade ago, but it could have been much worse if that malware had been written to be destructive.

    We don’t have default names and passwords in SQL Server, but we should make sure all accounts have strong passwords. There’s also some value in not configuring all systems identically. It makes management easier, but it also makes a successful attack that much more successful.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.