Voice of the DBA

Category: Editorial

  • Training at the Top

    Many of us see flaws and problems in the way that we code securely as we build software, as well as the way in which our infrastructure security is configured. There have been no shortage of times in my career when I, or a coworker, wondered why our company didn’t work to implement better security in its systems.

    Perhaps it wasn’t us. Perhaps it’s not a lack of desire, but maybe it was due to a lack of knowledge. I ran across a piece in Enterprise Security that notes we should have security training starting at the top, with our C-level executives. Far too many of them don’t necessarily understand the threats or nature of the threats because many of these threats didn’t exist 20, or even 10, years ago. Often we have management that has never faced these kinds of vulnerabilities.

    I think there’s certainly room for most of us to learn more about security, especially database security and SQL Injection as these are fundamental issues around some of our most important assets: our data. However when we want to implement stronger security, or limit access, we need the support of management, who themselves need to understand the issues, not just respond to whoever makes the best case, or complaints the loudest.

    The world has changed, in that our valuable assets can be transferred to our competitors, or common criminals, and we aren’t away of the disclosure. Or perhaps worse, our enemies could change some data and we might never know without the ability to perform comprehensive audits of our systems, something many of us might not be able to do. We certainly need technical capabilities, but also the time and support from management.

    I think there is a good case to ask our management make an effort to understand cybersecurity, and I’d urge you to pass this link along to your management.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.3MB) podcast or subscribe to the feed at iTunes and LibSyn. feed

     

  • DeveloperBall

    I’ve been fascinated by Moneyball and the efforts made in sports to assemble good teams using data more than opinions. I used to think about baseball more, but lately I’ve been intrigued by American football. There are challenges in assembling a team, with the constraints of a limited budget, existing contracts that cannot be changed, and the fact that one player isn’t a replacement for another, even when they have similar skill sets.

    That got me thinking that we could do this with our development teams. Certainly the skills that each of posses might be closer to one another than athletes, but that doesn’t change the need to have a variety of skills on a project. We need someone that writes great T-SQL, someone that can manage front end code, someone that can build and provision environments, someone to help test.

    I know that many of you can do all these things, but do you want to? Maybe more important, is it a good use of your skills as a developer to manage restores or schedule index maintenance? Those are tasks that might provide a welcome break, but they aren’t necessarily the tasks that I want you to be responsible for or even spend time performing.

    There is also the very, very high likelihood that the people hired in your environment have different levels of skills. In a group of T-SQL developers, or SSIS package builders, or any other group that each of you can learn from the others. And you should learn from others, since it’s entirely likely that some of you will leave, and others will need to handle the load left behind. After all, the next person hired is as likely to be the weakest team member as the strongest.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.0MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • Crafting Your Resume

    Your resume of CV is often the first glance that a hiring manager gets about your career. Even if you’ve been recommended by a friend or current employee, often a manager requires some summary of who you as a few paragraphs on a screen that they can study.

    I have my own advice, but this post from a manager at StackOverflow covers quite a few of the same things I recommend. I certainly agree with the first section, writing for humans. Over and over again I hear from people that make hiring decisions that they spend 30-60 seconds on a resume to get an impression.

    One minute. You should set a timer for one minute and let someone read your resume. Then take it away and ask the person for their impressions of what you know. In fact, maybe that’s a great icebreaker at a user group meeting or SQL Saturday. Find someone that hires others, or is an experienced person in your industry, and ask them to do just that.

    We learn a lot from experimenting and seeing what works well and what doesn’t. Many of us solve problems in code and realize later that we could rewrite things more efficiently. Why not do that with our resumes? We certainly can control how we present ourselves, be interesting, and more importantly, don’t waste the reader’s time.

    You get one minute, or less, to make a good impression, so spend some time crafting your resume. Control your brand and ensure that you let people know who you are. Do your best to communicate the skills you have, the things you do well, and the ways in which you are a good employee. Most of us will change jobs at some point, so why not be prepared to present yourself in the best possible way you can by working on your resume now.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio (2.4MB) podcast or subscribe to the feed at iTunes and LibSyn. feed

  • Security Convenience

    I wrote a question of the day recently that seemed to catch many people. The question had to do with mapping users when a login isn’t specified in the call. The behavior is to auto match existing logins with the same name. About 60% of the people answering the next day got it right, but a third missed it, expecting an error to be thrown.

    One of the commenters was surprised that more people didn’t know this. I’d hope people knew this, though to be fair, I bet lots of people manage security through SSMS or a GUI and never write security code. I know I did for years early on. However I really think that the third of the people that got this wrong in its behavior, are actually right about how SQL Server security should work.

    We do not want ambiguity when we configure security. We should be sure that rights granted (or removed) are exactly those that we expect. A strong security system should not tolerate any unexpected behaviors.

    Security should require specificity.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 1.6MB) podcast or subscribe to the feed at iTunes and LibSyn.