Voice of the DBA

Tag: security

  • Classifying Sensitive Data

    Our databases store all kinds of data in them, depending on the purpose of your database. Most of us create tables and store data in response to some requirement or necessity in our organizations. Our decisions should be driven by good design principles, and I’d hope they are, but we do need to find a place to put all the data that our system will receive.

    Depending on the sensitivity or personal nature of data, we may have to alter the way we store data (perhaps encrypt it) or alter the security for parts of the system. This is almost an ad hoc, deal with it at that time task. The exceptions might be when I’ve had to conform to a regulatory statute, such as SOX, PCI, HIPAA, etc. In those cases, I’ve often had to ensure the entire database is protected in some way that ensures it meets the requirements of the statute.

    The time when I have had to think about individual columns of data is usually when building a development database where potentially sensitive information can’t be transferred to development machines. In that case, because of the effort of changing data, I’ll try to build scripts that change out individual columns and ensure that sensitive data doesn’t get copied. However, the data that may be deemed sensitive for one company, isn’t always classified that way for another.

    At least that’s been my experience. I shared some of this with the Redgate Foundry, who is running research into data classification. They’re looking for people to share opinions, but the project has me curious. I’ve always felt intuitively we could classify data in tables, but perhaps that’s too simplistic a way of looking at the problem. I know that legal groups struggle with some this problem with email and file server documents. Classifying the content in different ways is a challenge.

    Is it the same in databases? I’m not sure. I don’t know if there complex rules needed or if this is a simple problem that we easily solve and rarely deal with. I’m curious from those of you that deal with highly regulated industries. Is data classification something that you work with often? How do you decide the data classes and does this impact your administration of the database? If you don’t classify the data, do you worry about the sensitivity of the bits in your database? Let us know today.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Move a Stored Procedure to a New Schema–SQLNewBlogger

    Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

    One of the things I needed to do recently was move an object. I was testing the WideWorldImporters database and created an object in the dbo schema. That’s the default for me, which is fine. However, in this case I wanted it in a different schema.

    The way to do this is with the ALTER SCHEMA command. There is a TRANSFER option, which takes the original schema and object name.

    In my case, I had the dbo.GetOpenPurchaseOrderCount procedure in my database.

    2017-06-07 14_40_29-SQLQuery1.sql - (local)_SQL2016.WideWorldImporters-RR (PLATO_Steve (53))_ - Micr

    I used this command to move it.

    ALTER SCHEMA Website
    TRANSFER dbo.GetOpenPurchaseOrderCount

    And then verified things moved.

    2017-06-07 14_40_37-SQLQuery1.sql - (local)_SQL2016.WideWorldImporters-RR (PLATO_Steve (53))_ - Micr

     

    SQLNewBlogger

    This was one of those quick items where I checked the ALTER commands, thinking it was in there. I didn’t see a changeobjectschema procedure, and since this was a new skill, it was a 5 minute blog.

  • Securing the Things

    I would venture to guess that a lot of the data that will be produced in the next few years will come from various “things” that are implemented by companies, users, and governments. We tend to refer to the Internet of Things (IoT) as those computing devices that are small, specialized, and connected computing device that sends data elsewhere. Sensors, special purpose devices, and more make of the IoT spectrum, including many industrial and manufacturing hardware.

    Computers grew by leaps and bounds from approximately 250 worldwide in 1955 to one million in 1980 and 30 million by 1986. In 2015, the world saw 238 million computers sold worldwide. If we add smartphones, we had around 120 million sold in 2007 and 1.4 billion sold in 2015. Tablets add to this, but really, the large market is going to be IoT devices. 15 billion connected in 2015 with an estimate of 75 billion by 2025. I would wager that is going to be a low prediction.

    One of the major concerns with these devices is security, and with good reason. There have been hacks against many of these devices, and few have been designed or sold with security in mind. Quite a few devices assume a strong network perimeter inside of an organization, but history has shown us that these barriers aren’t always secure. What might be more disconcerting is that many of the hacks originate inside of the network boundary, whether from insiders or compromised devices. There’s a nice write up on the need for security with IoT. Microsoft recently proposed that we regulate privacy and security for the IoT devices.

    Many of these devices will generate data that we will use as data professionals. In fact, I expect a tremendous amount of data to be generated. If devices are hacked, we may end up with lots of suspect data. Even devices are secure, they may fail or have intermittent errors. How to we detect errant data and remove it from our data sets? How can we be sure anomalies aren’t just problems or failures in the device (or network)? These will be challenges for us moving forward.

    I don’t know that I think specific regulation is required, but I’d like to see some sort of framework devised. I think encryption should be required, as well as guidelines for the security of connections and data management. Perhaps a list of valid technologies could be used, growing and changing over time, including removing older items that might be outdated. For example, DES shouldn’t be allowed in any new deployments, and it really should be removed from old ones, though with some grace period. That means a regular investment in software development and upgrades that evolves our systems over time. Especially with regard to data security.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Software Has Bugs

    Every once in awhile I have someone I meet complaining about software quality, usually with regards to some piece of Microsoft software. I’ll invariably hear how there shouldn’t be bugs in SQL Server or Windows, and Microsoft isn’t testing their software. This person will claim that they write software with no bugs. I can’t remotely believe this is true, aside from small, somewhat trivial applications. All software has bugs, but there’s no way to disprove anyone’s assertions unless you can get to their software and examine it.

    I do think that some people think their software is more bulletproof than it really is, perhaps because no one really does test the limits of their work. It’s easy to assume that there aren’t problems when no one has ever probed deeply in the different ways the code might execute. After all, this is one of the reasons that developers turn in code that they think works, but in which others find bugs. They haven’t explored enough different inputs against the software. This is also why I think unit testing needs to be constant and evolutionary, growing and changing as you find new issues and bugs in your code.

    Recently a vulnerability was found in the Samba software, and apparently it has existed for seven years. This means lots of software was vulnerable, and everyone should be patching as soon as possible. I don’t know how many people have port 445 open to the Internet, or even open locally, but plenty of people might now know about the issue, so patching makes sense. Scans of the Internet have turned up hundreds of thousands of devices, some of which are running versions that can’t be patched.

    This isn’t meant to complain about Samba, but point out that this is code that is open source, lots of people have looked at and developed against, and I would guess no shortage of security people have checked this for potential vulnerabilities. And still a bug slips through.

    Security isn’t hopeless, but it’s also hard. Software development, with few boundaries limiting the choices developers can make, allows new interactions among the building blocks of code that have never been seen before. Building code is much, much more complicated than any physical structure because we don’t have any of the inherent limits of the physical environment. This means that we will, and do, struggle to test all of our software.

    I don’t think we’ll ever eliminate all bugs, but we can vastly improve quality (as many companies have), by moving to a more DevOps development style where we seek to constantly improve quality as a part of software development. We also have more and more developers also seeking to improve their skills, learning new and better patterns throughout their careers, and hopefully, building better software.

    Steve Jones

    The Voice of the DBA Podcast

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