Voice of the DBA

Tag: security

  • Letting People Go Securely

    This editorial was originally published on Mar 15, 2009. It is being re-run as Steve is away on the 2013 SQL in the City tour.

    The world economy appears to be in shambles, with many companies cutting back in all facets of their business. We hear regularly in the US that people are being let go from their jobs as positions are trimmed and companies look to save money.

    When someone is let go, typically they are asked to leave the premises on the day. I’ve seen escorts that walked people out or watched them pack up. In some extreme cases I’ve seen people escorted out the door while another employer packed their things and brought them out. For IT workers, it’s a little different since they often have privileged access to systems. In addition to removing their personal belongings, having  an IT worker leave means that passwords and possibly accounts need to be changed to ensure that the company is safe.

    However when someone resigns and gives their two weeks’ notice, I often see that many people are expected to work their final two weeks, brain dump their knowledge to others, perform documentation, or even continue doing their job. In all of the positions I’ve resigned from I’ve worked out my time, even doing some last minute SQL Server development on a Friday afternoon, my final day of work, with plans to leave town the next morning for a new job.

    There was only one place that I worked with a different policy. In that company, if someone with above normal privileges, which included upper management and IT administrators, they were escorted out of the building immediately if they gave notice to terminate their employment. That surprised me, but I understood it. People were paid for their two weeks notice, but management didn’t want anyone to have access to company funds or systems if they planned on leaving. I saw an article recently that provides some justification for this, with a survey showing 59% of people leaving a company steal data.

    On the surface this makes sense, but does this help prevent data loss? I don’t think so. What happens is that employees that are likely to steal data will just take the data before they give their notice. You haven’t changed their behavior, but by not allowing them to work out their notice, you punish the remaining employees who have to suddenly pick up work from their ex-colleague.

    There isn’t a good way to protect data from employees that want to steal it. But you can put in place auditing, and smarter systems that allow monitoring and auditing of your systems. They won’t prevent issues, but hopefully they’ll allow you to detect and respond to them.

    Steve Jones

    The Voice of the DBA Podcasts

    Everyday Jones

    The podcast feeds are now available atsqlservercentral.mevio.comto get better bandwidth and maybe a little more exposure :). Comments are definitely appreciated and wanted, and you can get feeds from there.

    Overall RSS Feed:  or now on iTunes! 

    Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

    I really appreciate and value feedback on the podcasts. Let us know what you like, don’t like, or even send in ideas for the show. If you’d like to comment, post something here. The boss will be sure to read it.

  • IT Security

    IT security is a concern for many businesses. At least that’s what a survey at the recent Black Hat conference concluded. Most of the respondents couldn’t be sure that a foreign state-sponsored attack had not occurred in their networks. About half of the people were not confident that their staff could even detect an attacker. That’s a little scary as many of the people felt their systems might come under attack within the next year.

    Digital technology has changed the world in many ways, but one of the most amazing to me is how it has leveled the environment in which all of us can interact. No longer does communication, publication, research, even war require the resources of a country or even a large organization. In the cyber world an individual can make as much impact as a large entity. As with most things, this is a double edged sword, and I’m sure many of us will find that vandalism, as well as malicious attacks on our systems will increase in the future.

    However the threats, or perhaps the consequences, aren’t severe enough yet. Most companies allow shoddy code, vulnerable to SQL Injection, to pervade their internal (and sometimes external) applications. Security training is limited, and review of third party applications is extremely lax. The respondents at Black Hat are making efforts, but those are a self-selective group. Most organizations would never send an employee to Black Hat events or even monitor the trends and information published by groups like SANS.

    I do believe that security will become more and more of an issue. I suspect, however, that until businesses are liable, and decide to purchase insurance, we won’t see much change. Once insurance premiums start to depend on the level of security you implement, I suspect we’ll see the quality of application code increase.

  • The Challenges of Being Safe

    This editorial was originally published on Mar 19, 2009. It is being re-run today as Steve is away at DevConnections.

    One thing we recommend is to make sure that production data is always kept safe, which means that you keep control of where it lives and how it’s used. I saw a post recently where someone needed to send data to a business partner and wanted to obfuscate it.  I think that is a great thing to do and was glad to see someone asking for advice.  Sending data to business partners is required, but you want to be sure that you are not necessarily giving away too much information, especially identity, privacy, or financial information that you shouldn’t.

    However what about your test and development environments? I’ve seen people obfuscate data here, but not always. In fact, not usually. This is despite the fact that you might turn over developers often, expose that data to testers, or other people that might not normally have access, and the fact that these environments almost never have auditing enabled.

    We need to mimic production environments and data, but there are quite a few challenges with doing this in a safe and secure manner. Just having scripts to obfuscate data is a challenge in and of itself. I’d love to see a tool built that would do this automatically, though I wonder how many companies would actually buy it. I’m not sure there’s a great market for tools here until insurance companies start require it for your “data loss insurance.”

    But building those scripts is both hard and time consuming. How do you decide what to obfuscate? What values do you use? How do handle PK/FKs to ensure that things match up correctly if you’ve used personal information, like a SSN, as a key field?

    Beyond that, there’s much more. What about ensuring that data matches up correctly? Can you really determine if there is an issue with some calculation or relationship if you have random data. After all people many times will have favorite accounts that they know well and understand what the data should look like. A developer may expect certain order details or address information, and use that as a benchmark when developing new code. If the data is random every time his environment is refreshed, does that slow his productivity? How do you test things like URLs and emails if data is randomized?

    And what about when you alter your schemas? How much work is there to update your scripts?

    And what about mistakes? How often has someone pointed development code at a production server? What happens if they accidently run an obfuscation script against production? If you’ve scrambled data around, would you catch it quickly enough to restore before too many transactions were sent through?

    Using some type of data obfuscation or randomization is a great way to help ensure that your production data is kept safe, but it definitely makes for a much more complex environment, and likely, more headaches for DBAs and developers.

    Steve Jones

    The Voice of the DBA Podcasts

    Everyday Jones

    The podcast feeds are now available atsqlservercentral.mevio.comto get better bandwidth and maybe a little more exposure :). Comments are definitely appreciated and wanted, and you can get feeds from there.

    Overall RSS Feed:  or now on iTunes! 

    Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

    I really appreciate and value feedback on the podcasts. Let us know what you like, don’t like, or even send in ideas for the show. If you’d like to comment, post something here. The boss will be sure to read it.

  • Secure Programming

    This editorial was originally published on Mar 19, 2009. It is being re-run today as Steve is away at DevConnections.

    Writing secure software is hard. The way most people learn software, from simple examples that slowly build our knowledge, doesn’t encourage complicated solutions that provide robust error checking, error handling, and secure practices. Most examples that I’ve seen in the world include “dumbed down” code that is easy to understand and explain in a class or seminar.

    And that’s the code that often gets used by developers.

    They go with the simple example, and enhance it, not really concerning themselves with best practices, or even great practices. In fact, if you search for sample code on the Internet, read articles on various sites about programming, or buy a book from an “expert” it seems that more often than not, the code isn’t well written from a security perspective. Yet that’s the code, and the mentoring, that many developers get.

    And for a DBA, that code is a nightmare.

    Too often the code samples and practices that are taught to people include dynamic SQL built in the application with little to no thought about SQL Injection. And it doesn’t matter if the application is at fault. As the DBA it’s often your phone that rings, and you that end up explaining to your boss why all the products on the site cost $1, or why every customer’s name is “0wned by S&p#rG##k.”

    The NSA, along with a number of other companies, is trying to do something about poor programming practices. They have release a list of the 25 most dangerous programming mistakes. What’s interesting is that some government agencies, and hopefully companies soon, are using this list as a litmus test for vendors. Software companies are being asked to guarantee that their software contains none of these mistakes.

    I think it’s a great idea, and I wonder how well it will be enforced. Microsoft and Oracle, among quite a few other software vendors, provided input into the list. You’d hope that their software would be fixed, or at least all new software would comply with the recommendations and not contain any of these mistakes.

    Steve Jones

    The Voice of the DBA Podcasts

    Everyday Jones

    The podcast feeds are available atsqlservercentral.mevio.com. Comments are definitely appreciated and wanted, and you can get feeds from there.

    You can also follow Steve Jones on Twitter:

    Overall RSS Feed:  or now on iTunes! 

    Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.