Voice of the DBA

Tag: Database Weekly

  • Would You Want to be on the Red Team?

    In the world of cybersecurity, a red team is a team of hackers that try to infiltrate a company, but at the request of the company. The idea is they look for vulnerabilities and issues and find them before criminal hackers do. They are the opposite of the blue team, who is trying to stop the red team and create defensive measures that prevent the red team from accessing data.

    Many large companies use red teams. Microsoft maintains a red team (and a blue team) that are constantly competing to break into their systems and defend them (depending on which side you are thinking about). I’m sure Amazon, Google, and other large companies do the same thing. It’s an interesting idea, though I bet this is a lot of repetitive work where you constantly repeat similar attacks with slight variations. There certainly is some creativity and research as well, and some acting if you social engineer situations, but it’s not the type of work I would want to do. I doubt it’s as exciting as Hollywood movies portray hacking.

    An organization could assemble a red team from external resources and use them to evaluate the security of your software, your infrastructure,  or even your people. There’s an article this week on getting started with a red team. Since companies are seeing more and more attacks against their systems, I would expect more to be proactive and either assemble or hire someone to test them. In fact, I bet there will be lots of cybersecurity people setting up their own companies to help here.

    Many of us might feel we are careful with security, and that we check for issues. I’m sure we do some of that, and many of us know how to secure things well. However, it’s easy to make a change and make a mistake. It’s easy to forget to include a group, or include the wrong group, in a security ACL. It’s easy to forget to check a setting or leave access open while we test and forget to go back and secure it properly.

    Attackers think differently. We can learn to do this, but it might be helpful to have someone else doing the attacking and then giving us a report on what to fix.

    Steve Jones

  • Reusing Tools for New Purposes

    One of the things you learn early on in programming is that you ought to reuse code whenever possible. This often means refactoring code into functions or methods. This ensures that the code is more easily maintained and that the knowledge and work of solving the problem is reused in many places.
    In database code we don’t do this too often. We certainly can reuse some code by encapsulating it in a view, but this often brings performance penalties. We often don’t want to reuse code in stored procedures and functions as embedding this into queries can cause lots of issues. In fact, it seems that much of the way databases optimize query performance isn’t that amenable to reusing code.

    That being said, I ran into an interesting case recently when thinking about maintenance in the cloud. Someone was asking about SQL Agent and the lack of support for it in many PaaS database systems. I understand that, and while there are some ways to do this, they feel complex compared to using a SQL Agent on a local instance, which is usually easy to set up and readily available. One of the speakers taking questions mentioned that they user shouldn’t forget about Azure Data Factory as an automation agent.

    That caught my attention as I hadn’t thought about it before. This week, there was a blog on that very topic and I read through it to see what I thought. While this isn’t as easy as SQL Agent, it does seem to be easier than Azure Automation, and likely more familiar than elastic jobs.  That’s if you already have ADF running in pipelines. In many ways, this feels like using the maintenance plans in SQL Server, though just the call a stored procedure task. Since many people use a solution like Ola’s, this is very easy to implement.

    I like that this pattern reuses skills and a system that you may already be using, transferring the skills from one area (ETL) to another (administration). This might not seem like much, but limiting the tools and technology, reduces complexity and means that each person needs to know less to support your environment. I’m a fan of code re-use, outside of T-SQL), and I think reusing other technology systems, where appropriate, is a good idea..

    Steve Jones

  • Maybe It Is DNS

    There are jokes about how often DNS is a problem. There are stickers, shirts, and mugs you can buy. There’s a classic haiku, which leads into a rant about the struggles of sysadmins. I will admit that I know a little about DNS, but I find myself confused at times and usually seek assistance from others when something doesn’t work. The old days of a single MX record and a few A records to map names to IPs has grown into a much more complex system.

    DNS usually works. In fact, it’s lower on my list of things to check these days, though I do often get a quick DNS check when I ping an address. There are some failures, and these days when large companies have issues, it can affect a lot of people. Akamai had an issue and knocked off a large chunk of the Internet. When Facebook had an issue recently, it not only affected customers, but the engineers that were trying to fix things. Some couldn’t even get into buildings. I guess relying on a single domain might be a bad idea.

    Most of us rely on DNS in our organizations, which means that a rising level of DNS based attacks is disconcerting. These are still behind the issues we have with ransomware and DDoS attacks, but when DNS doesn’t work, a lot of stuff shuts down. I could see a lot of people that work inside a company’s domain for most of their work being unable to accomplish anything.

    I tend to use a number of domains for my daily work. Evernote and Dropbox are essential, but if one were down, I could still do things with local copies. Red-gate.com is certainly important, but as long as SQL Server Central is up, I can do something different. Actually, if both were down, I could still write or create questions. I’m more bothered by slowness in my connection or machine than losing any particular service.

    I haven’t every been too worried about DNS security, but I left sysadmin work when it was a simpler time. These days, I suspect many organizations might want to be sure they are paying attention. If they use a lot of services connected to one domain, I might think about having a secondary domain connected to a few. If I were in charge, a sqlservercentraladmin.com might be one I’d set up.

    Steve Jones

  • What Do You Want to Know Before Negotiating Salary?

    Many of us are employed, and while we might have a salary review each year, we often don’t get to negotiate much about the amount. We might periodically ask for a raise of some sort, but what should we ask for? Most of us have accepted employment at some point, responding to the offer of a job. Do we know what a fair salary is for our position, in our location, with our experience?

    Human Resources and Personnel departments use surveys and information to set ranges of pay for different positions. They come to a salary negotiation with some idea of the market, which is a generalization of what an employee is worth. This could be quite different than what you specifically feel you should be paid. However, do you have any rationale for your demands?

    Every year Brent Ozar runs a salary survey. He gets lots of responses and does a better job of this than most other places I’ve seen. Including me. I’ve done this a few times, but I’d rather just let Brent run this and view his data. This year he asks you to look at the list of questions and give feedback.

    I think Brent has a good list of questions, but perhaps there is something you wish you’d have known before you last negotiated salary. Is there something that might help you decide if an offer (or raise) is fair? Perhaps you want to add a checklist of responsibilities (BI, DBA, dev, etc.).

    Maybe you think it would be interesting to know if there is on call work, or even the number of hours your employer expects you to work? Given the pandemic I might ask if the company is allowing remote work or expecting people to come back to an office. Some people have suggested these in the comments, but read Brent’s answers. He’s looking for a indicators or features that affect salary, not necessarily how you feel about the environment. I added one about non-monetary compensation like training, but feel free to comment on other suggestions as well.

    What’s really important here is that you take the survey when it comes out. Even if you don’t like the questions, getting this data compiled for our industry helps us all, so keep an eye out for the survey and fill it out to the best of your ability. Then get the results when they are published and use them to try and evaluate if you’re being compensated fairly.

    Steve Jones