Voice of the DBA

Tag: security

  • SQL Census–From the Redgate Foundry

    The Foundry at Redgate Software is our version of Microsoft Research. Kind of. We tackle some projects that are interesting and might make good products at some point, but we’re looking at the in the investigative phase. You can read about the Foundry here.

    Some interesting work is taking place in the Foundry and there’s one project that I think is interesting and solves a problem that many of us have had, but I’m not sure how commercially viable this is in the real world.

    Maybe you can help us learn more.

    SQL Census

    SQL Census started as investigation into the area of security, something that is both very simple in SQL Server, but can also become a cumbersome, complex, nightmare.

    The work has progressed well, and there’s a product available. Sort of. It’s in the stage where we are trying to decide how to move forward with both future development and starting to sell this. For now, you can get a look at the tool and give us some feedback. We’re really looking for more information about

    • Do you need this for compliance purposes?
    • Will this help you better secure your environment
    • Does this meet permission management needs?
    • Something else?

    We’re like to get more users, especially those that have larger environments where there isn’t a single user or role that everyone has.

    If you’re interested, read a little about the product and give it a try.

  • The Worst Data Breech

    I noticed this week that Australia passed a law that requires companies to hand over user information, even if encrypted. Quite a few articles that point out this might require backdoors to be created in communication systems to comply with the law. Companies are required to provide plain text user communication if they can, or build tools to allow this if they do not have the capability. The proponents of the bill argue this is necessary for criminal prosecution.

    Perhaps they are right, but if this capability is required, this means that either companies will have backdoors built into their products that allow them to decrypt things you might have expected to remain encrypted. That’s disconcerting to me, not because Apple, Google, or someone else might read my communications, but because no company has really proven they can protect all the data they store.

    Can you imagine how many malicious actors might spent their efforts trying to find those backdoor encryption keys? What if there aren’t backdoor keys, but companies decide to build some sort of key logger into software that copies data before it’s encrypted. Can you imagine how problematic it might be to secure that data?

    I’m also concerned because this would mean that there could be a few keys that can be used to get access to encrypted data, something like “master keys” in door locks. In this case, the loss of a key might mean problems for huge numbers of people. The other option would be lots of backdoor keys, potentially a different one for each customer/device, in which case we have a large data set that I’m sure will get leaked. At that time, how likely will it be that we’ll be able to implement new keys for large numbers of people?

    I sympathize with law enforcement. In some ways, their jobs are much harder. In others, however, I think they have many more tools, and the need to weaken encryption doesn’t seem to be necessary. Many of us have a need to secure data, to protect it from unauthorized access. At a time when security is proving to be a challenge and record numbers of data breeches are occurring, do we really want tech companies to start building products with less security? I don’t.

    Steve Jones

     

  • Lax Security is Harmful for Employment

    Manure rolls downhill Since I live on a horse ranch with some slight hills, I can attest this to be true. At least, it’s true for horses and it’s true for short distances. Manure isn’t very friction free and often ceases movement quickly. The same isn’t likely true for bull droppings, but I haven’t done much testing in that area.

    Most of us would agree that those that are negligent in their jobs, especially with regard to security, ought to be punished. In some cases, this should lead to termination, though I think many of us technical people would prefer that management who doesn’t budget resources for security be the ones punished.

    I mentioned manure rolls downhill, and this article on the after effects of data breaches bears that out. Not only were there record numbers of issues last year, but the typical cost is nearly $4million. That’s likely some very expensive breaches and lots of relatively inexpensive ones, but even the low cost ones probably feel expensive to small companies that experience them. In the lists of breaches I’ve seen, lots of smaller firms (retail, law, etc.) are included, and tens of thousands of dollars might be expensive for them.

    One thing that article points out, there are an increasing number of C-level executives being terminated after breaches. I’d like to think that’s good, but I’m somewhat pessimistic that the next hire will find ways to improve security. There are lots of impediments to fundamental change in more organizations, so I suspect this trend leads more to short term employment for CIOs and others, and likely higher demands for salaries because of the risk of security issues inside the company. The further puts pressure on budgets, which is another impediment to better security.

    Note that it’s not just IT execs, but non-IT staff as well. Maybe I’ll be wrong and this will make a difference. Of course, IT staff are let go as well, often blamed for issues. There will always be some security issues, but I urge those of you with privileged accounts and access to sensitive data to be careful with your credentials and work to improve security when you see issues. Get written documentation when someone doesn’t allow security changes, in addition to noting your requests. This might not stop a data breach, but perhaps it will give you a better chance of not being blamed for security incidents.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Another Reason to Care About Security

    This is likely a short and quiet day for many of you with Thanksgiving in the US tomorrow. Most people have tomorrow off in the US, and those that do business with the US may have a quiet couple of days with little communication from the US. A good time to catch up on things.

    Before you go, I want you to think a bit about security today, and perhaps across the weekend before you come back. Security is important, and many of us that work in the data world know this. We see more and more data breaches occurring every week, with the rate of incidents at this point being a little over 4 per day. These are losses of data from all sizes and kinds of companies from household names to local law firms and retails organizations.

    Most of us work for some company that has data, and we know a portion of this deserves protection to ensure we don’t need to pay for identity insurance or get fined by the government. There’s another reason to care about security: branding. There’s a survey that just came out, which notes that consumers are likely to stop using a brand if there’s a data breach. There’s a report on the survey as well, if you don’t want to give up more data to get the data.

    Consumers note that many would stop working with a brand if there were a data breach, but that might not mean not using that service, just not using their online services. This makes some sense in some industries, but not others. I also know that consumers can be emotional and look to leave a service, like a mobile phone provider, after a breach, to move to a new provider. In many cases, this may create churn as most providers have had some breach, and it’s entirely possible whoever is last is the one losing customers this quarter.

    What I did find interesting is that more consumers are being careful what information they share, preferring to use official portals rather than email, even avoiding clicking on links. To me, this is only a matter of time before customers stop providing most voluntary information, or the start to make up data values. That might be a problem for those of us that look to analyze data for our employers. If quality falls, perhaps we’re less valuable.

    We need to do a better job of securing system, patching them against vulnerabilities, writing better software, and preventing exposure of data. We’ve gotten better in recent years, but we need to do more work, including avoiding keeping extra copies of sensitive data in development and test environments. It requires work to mask or remove this data, but it’s better than the risk of accidental exposure and brand damage.

    Steve Jones

    The Voice of the DBA Podcast

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