Voice of the DBA

Tag: security

  • Slow Fixes

    Moving Slow

    Today we have an editorial reprinted from Jan 15, 2006 as Steve is on vacation.

    There’s an interesting piece at the Washington Post on Microsoft’s delays in releasing patches, with some analysis showing that when the flaw is disclosed to the public, a patch comes out much quicker. After some analysis over the last 3 years and researched the dates Microsoft knew about the issue and the dates that the patches were released.

    Surprise, when everyone knows, the patches come out quicker. It seems that the piece is intended to take a shot at Microsoft’s patching process, and maybe it is, but there are some interesting things in there to talk about. First of all is the time lag.

    Is this any different from any software vendor or even internal corporate software? If your boss knows, or the client knows, don’t you work a little harder and a little quicker? Isn’t it more critical and don’t you rush things in addition to working harder when it’s a “public” patch that is needed?

    I’m sure we all do. And it’s human nature to put more effort into something that’s widely perceived as an issue and less effort if you know that you may have more time. We all do that and our work schedules, effort, and productivity change depending on a variety of things, including the importance of the work.

    The piece also leaves open a number of questions and mentions this, noting that the analysis might be flawed. There’s no mention of if the rushed (or delayed) patches had to be repatched later. There’s concern over patches applying to one area, but other similar flaws found in other parts of the software remaining unpatched. That’s something for sure that should be examined in looking for re-patches or whether things are rushed. There’s also the lack of examination on what else was happening inside Microsoft, and whether people working on other projects had to be pulled off them.

    We all know that delays things as well. They take time to get their head back into code, they may be annoyed, a critical person could be out, etc. Not to mention that the statistical methods might not be the best ones, but I’ll leave that to the mathematicians to figure out.

    Patching is hard. As is finding bugs. I think Microsoft has done a much better job over the last 3-4 years and the quality of software, at least SQL Server, has improved. However there is still definitely room for more improvement.

    Steve Jones

    (published at http://www.sqlservercentral.com/articles/Editorial/72365/)

  • Cloud Hacking

    Hackers are training for the cloud challenges

    Not everyone is down on the cloud. Apparently someone found a great use for pay-as-you-go computing in the cloud by using it to hack wireless networks. What’s next, someone using Amazon’s Mechanical Turk to find security holes in police patrols of local businesses? It constantly amazes me just how someone will take a technology that is very handy and turn it into a tool used for criminal purposes. I suppose we just have to live with this use of technology and learn to protect ourselves as much as possible.

    I think that security will be one of the bigger impediments to cloud adoption than anything else. Sure there’s the cost factor of data transfers, and trying to determine how to manage the costs of large bursts. There’s the need to integrate local and cloud development codebases, and potential patching/version issues. However those are not large issues when compared with the potential security issues that come with cloud computing.

    Even as we move to private cloud structures, we may have security issues with more resources being grouped under one large services umbrella and the difficulties of managing security for large numbers of users. We want to use groups to make management easier, but the more people you manage and the more groups that become involved, the more likely it is that you will have some security hole in your system.

    I think we’ll start to find more hackers that will discover, and take advantage of, hole in cloud security that we haven’t thought of. As they do, we’ll see more resistance from companies in migrating their infrastructures. At least until it becomes more cost effective to do so. Then we’ll discover that many of those security issues don’t seem to matter quite as much.

    Steve Jones

    (published at http://www.sqlservercentral.com/articles/Editorial/72385/)

    The Voice of the DBA Podcasts

  • It’s Almost Always the Humans

    Today we have an editorial reprinted from Sept 19, 2005 as Steve is on vacation.

    Most breaches of security, stolen data, etc. are almost always the result of some breakdown in the human factor of the equation. By that I mean some interaction between the human “bad guys” and some human in the company. It could be stealing a laptop, sorting through trash or even paying for it. Or perhaps this method.

    I saw this article about bank fraud, but not the kind I expected. After all, I got called last year by my cell phone provider in a similar situation. You are late on your bill, make a telephone payment, presumably because you’re short of time. In my case I didn’t even call them back, which I should have. In this case, the individual writing just called and made a payment over the phone.

    A short time later a suspicious charge appeared. The person tracked it down to customer service that had been outsourced and someone at the outsourcing company was selling or passing along information to criminals that would use it in some type of identity theft crime. No word on what is happening with the investigation or even which company it is.

    To me, this the worst method of saving money, and if this results in security breaches, the name of the company should be publicized. Most of these corporations are not losing money. They are racing to make more, increase the stock price, whatever, and in doing so, they are sending out a piece of their core business. Customer service should be a cornerstone of any company. That is how you show that you are the place someone wants to do business. I’m not sure I even agree with outsourcing IT since that data is critical and vital to your company as well, but there is no way customer service is not a core part of your business.

    If you’re missing that point, you’re missing the function of a business in the world.

  • ETL Security Holes

    The addition of DTS to SQL Server meant that more and more of us could grab data from a variety of sources, easily, and move it to SQL Server systems. SSIS enhanced our capabilities and made it fairly simple for non-programmers to grab web service data, and other formats, and quickly decompose them into relational formats. This made it more likely that we would build data warehouses or reporting systems, and easily keep them up to date with data from our OLTP systems.

    However the ease of using ETL (extraction, transformation and loading) processes to move data did not include the moving the same security controls and restrictions to these new systems. That can create a big security holes, especially when you have secondary systems used for decision support that might not be contained in the production network and not audited to the same level as other production systems.

    Whenever you move data around, there ought to be some set of guidelines for the security protocols required. That can be hard to track when you are pulling data from a secure system and your connections look like every other connection. One of the dangers that I suspect we will run into with Powerpivot is that secure data will be downloaded to Excel worksheets on insecure systems, and all of the controls that we have in place for protecting sensitive information are ignored when we pull data for analysis elsewhere.

    Our data security has gotten better, but we have a long way to go. If you are working with ETL processes, and especially with end-users, make sure that some sort of security policy is in place to help protect this data from being accidently disclosed. It’s not a great suggestion, but until we have better security tools to allow policies to follow the data, that is all we can do.

    Steve Jones

    (originally published at http://www.sqlservercentral.com/articles/Editorial/72157/)

    Podcasts