Voice of the DBA

Author: way0utwest

  • Close, but no MCM Cigar

    I failed.

    There’s no other way to say it, but I’m not really disappointed or discouraged. I’m actually fairly upbeat about it. I went into the Microsoft Certified Master test thinking that I’d fail because it aims to be a high end certification. I felt like I had a huge knowledge gap going through the study resources on the SQLskills MCM page.

    I plugged away, and learned a lot. I listened to content on long car trips and airplane rides. I read white papers at night and while waiting for kids at various events. I practiced working through some of the code examples, and came up with new ideas along the way. And I got a lot of notes, so many notes that I didn’t even review half of them as the test got closer.

    And I was surprised. As I wrote about my test experience, I think I was well prepared, and I knew more than I thought. Every question made me think and made me deduce some solution, but very few of them had me throwing up my hands and feeling like a complete idiot.

    My score was close to passing. It wasn’t the single digits I joked about on Twitter, nor was it the low 200-300 score I was thinking I might end up with. The passing score is 700, though it isn’t clear if that’s out of 1000 or 800 or 743. We don’t know how the exam is scored, and I’m not sure if that’s good or bad, but that’s a separate blog.

    In my case, I got a 620 with bar graphs that listed my relative strength in a few areas. I scored highest in Scalability and Availability, with my graphs about 8/10 of the way across. In Recoverability and Managability I had about 7/10 of the total distance. That’s not surprising since I think those administrative areas are my strongest skills.

    In security I was about 6/10, which is a little surprising. I thought I knew SQL Server security very well, but I’ve always been a “practical” security guy, and not necessarily conforming to what the MCM might see as the best way to implement security. Definitely need to work on this area a little more. In Performance, I was about halfway, which is probably true. Without spending a lot of time on this in a practical sense in recent years, I’m relying on my memory in studying and not using field-skills.

    Developer Support, which I assume means XML, Spatial, CLR, and other similar code oriented areas I was the lowest, about a 4/10. That’s not surprising since I don’t write a lot of code and really haven’t spent much time in those areas. They feel to be a little outside of the core of what I really enjoy in SQL Server, and I’m sure I didn’t focus here all that well. I know I listened to the SQL CLR prep four or five times and was still slightly confused as to what was covered.

    There were no areas that were incredibly weak, but a few that need improvement, and I know that I have a few things in the manageability to work on after the test. I won’t go into specific areas, but suffice it to say that one particular topic had 3 or 4 questions and I struggled with them talking about a certain implementation of the technology that I hadn’t spent much time on.

    Moving On

    What do I do from here? I was thinking this was a one-shot deal for me and I’d get an assessment of where I stood. I definitely got that, and the results seem to mirror what I would have thought were my strengths and weaknesses. My higher-than-expected score has me wondering a little about which of these is true:

    · I know more than I thought

    · The exam doesn’t test real world skills as much as I thought

    It’s hard to know which is true. I don’t do a lot of real world work, but I read a lot, and I talk with many people about what real world problems and solutions they use. So I have a wide set of knowledge, but not necessarily deep in places. The exam can only test me on the areas it tests me, and with a limited time, there is only so much it can test.

    I have the chance to take the exam again as there are still vouchers available and I think I will. I’d like to try again to pass it since I have a little competitiveness left in me and I thought I was close after taking the exam. If I can improve in a few areas, I’d think I would do better, though I expect different questions and would need to review all the material again.

    The lab? That’s a whole ‘nother story. The lack of practice in some areas might have me fumbling around more than I could afford in a limited time frame. I have less confidence I would pass that, though more than I would have had a few months ago. That’s if I could sit still for 6 hours and focus on SQL Server that long.

  • Why Use the Principle of Least Privilege?

    This SQL Injection could be a problem in data entry

    SQL Injection is not the fault of the SQL Server. Brian Kelley pointed that out, and reminded me that SQL Injection isn’t an case of malformed SQL. It’s legitimate code, including SQL commands that we might use from any query connection, especially an administrative one. We regularly issue update and delete commands from our applications, and SQL Injection takes advantage of this to issue an update the we might not be expecting.

    Would you expect this input handwritten injection from an application? Or this table guessing attempt? You wouldn’t, but they can come through data entry in your application if the input isn’t well sanitized. Someone setting all your prices to $0.01 or all of your customers to “W3 0wnz U!” isn’t what you want to happen. You can’t necessarily prevent all of these patterns  or check for every permutation, but you can prevent things like ‘shutdown’ or ‘drop table’ from being run by your application. Even adding a new user to the database system isn’t something I would want to allow.

    Education is the key here. As Andy Leonard (blog | @AndyLeonard) would say, design patterns are important. When developers have an understanding of the issue, many of these things will be avoided. Having standard ways to begin building an application, checking for bad input, and setting up database users and permissions easily, should make this easy for anyone that wants to code against a database. We still have work to do here to build better frameworks, and ORM tools that require elevated permissions to the database are not the answer. They might become the answer, but they aren’t a better solution right now.

    Grant Fritchey wrote a nice piece about developers and DBAS, noting the need that we both have the same goals, but need to learn to communicate better.  This is one area where we ought to make an effort to communicate better, pass along education about security issues, and work to make life easier for developers to work with a database.

    That also means teaching them to work with the minimum privileges needed in order to make an application work, just in case someone plans on submitting some input you didn’t expect.

    Steve Jones

    The Voice of the DBA Podcasts

  • SQL Injection Everywhere

    I hope no one SQL Injects my washer

    I was doing the laundry the other day and thinking about SQL Injection. I have this fancy front load model that lets me load fabric softener and bleach into containers for release later, and it occurred to me that if my washing machine were connected to the Internet with some API, it’s possible someone could SQL Inject or buffer overrun a string that might release a stream of bleach into my colors.

    Not terribly dangerous, but it could be annoying, and it is exactly the type of hack some bored teenager would come up with. Then I started thinking about what else they might do. I wrote about the possibilities with cars recently, but what else could a hacker do in a connected world. What if someone could ignite my oven? Likely it wouldn’t do much more than cost me money. Turning up my fridge might make a mess of food, but not dangerous. However what if someone could turn off the lights when they saw you start running down the stairs?  That could be dangerous.

    What if they could remotely enable your sprinklers while you were at work. In some places that could result in a fine. Allowing that to happen a few times might get you arrested. Locking or unlocking your car doors (already a remote possibility) could endanger you. I’m sure there are more malicious possibilities I haven’t thought of, and as we move to a more connected world, I worry we will discover them only when some crime has been committed.

    I like the convenience of adding digital controls and remotes to more parts of our lives, but I do worry that we are doing so in a way that ignores security. Linking the convenience items of our lives to remote digital controls can be dangerous enough. Adding in more essential items, like heating, engines, etc., to the same control bus could be fatal.

    SQL Injection will likely be around for a long time, and it will get used in many new ways as more and more aspects of our lives are digitized. All developers should be aware of how an injection attack occurs, and code to be sure that we don’t allow any un-sanitized input into any of our databases, and that we also require separate authentication for the parts of a system that need more security.

    Steve Jones

    The Voice of the DBA Podcasts

  • T-SQL Tuesday Reminder – Coming next week

    Matt Velic is hosting T-SQL Tuesday this month. You have a week to get a post ready on the apply operator.

    To help you out, here’s the BOL page on Using the Apply operator. It’s an operator that essentially lets you invoke a table valued function for each row of a result set. Not necessarily the most efficient way to get some things done, but it can be a powerful way of combining complex data that requires a function to interpret.