Voice of the DBA

Tag: security

  • 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.

  • Internal Controls

    I was browsing the Internet and stumbled on a small part of a larger story that struck me. Many of you may have heard of the story of Jamal Khashoggi, the journalist for the Washington Post that was killed. I hadn’t spent much time reading about the story, and I don’t really want to discuss that topic here. The politics of the situation are not relevent here.

    There’s a part of the NY Times background story that caught my eye when a quote was posted on Twitter. This is part of that quote: ” The intelligence officials told the Twitter executives that Mr. Alzabarah had grown closer to Saudi intelligence operatives, who eventually persuaded him to peer into several user accounts”. Essentially, an employee at Twitter was accused of accessing, and potentially disclosing, sensitive data about customers. This is what I want to discuss.

    In my career, there are quite a few times that I’ve had to access data to solve some problem, debug an application, or produce a report. In many cases, I’ve had to maintain some confidentiality of the data, not even discussing specifics with other employees that were not supposed to view that information. To me, that’s just part of being a professional. We handle all sorts of data, some of which we should never use outside of solving an issue or producing a report.

    As I thought about what was alleged here, I wonder how many social media companies have controls or auditing to determine who has accessed information. Would they be able to actually produce a report that validates some assertion that data was, or was not, accessed. I doubt many companies have these kinds of controls. Unless some Excel file or other export was on a file share, would there be evidence?

    Then I thought does anyone really do a good job of producing audit records for information access? I know some government and law enforcement systems do this (and some legal software), actually tying queries and results to some individual and even a piece of work. That’s not the nature of information for most of us, though perhaps it ought to be.

    Auditing data, especially for information access, could be a huge amount of data. Even keeping a record of all user access for a week in most SQL Server databases might be more data than many of us have in our database. I do think we ought to have the option, and I’d hope that we get more detailed, more capable, and more configurable methods of auditing SQL Server activity in the future (Hint, give us SQL Audit data in a csv).

    Steve Jones

    The Voice of the DBA Podcast

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

  • Republish: Data Breach Danger

    In Seattle today, delivering two talks, so you get a republish of Data Breach Danger.