Voice of the DBA

Tag: security

  • The Blame Game

    Make no mistake, this is going to be something that happens again. The former CEO of Equifax blames their massive data breach on a bad scanner and a person. I’m not talking about a data breach, of course those are going to happen, and when they do, assume that every piece of data in the system is compromised. I know some digital forensic scientists are really talented, but is a company that didn’t necessarily pay attention to security in the first place going to ensure the analysis is done right? Not likely. Assume every record is compromised.

    In this case, the former CEO calls out a person that made a mistake, and then says technology failed. I don’t think that’s true, and I’d agree with Patrick McKenzie, who has a good thread on Twitter. A bad engineering decision, or even a process, is the result of multiple people making mistakes. Certainly there are people that must back up the Apache Struts patch person when they’re on vacation. Or there should be. If there isn’t, then that’s a management failure at multiple levels.

    The thing that concerns me is that we, as tech workers, are going to be blamed going forward. The individual isn’t named here, but I bet at some point they will be. And some, or many, tech workers will get sacrificed for a company that wants to show contrition and action for security mistakes. It’s common for someone to take the blame, but I haven’t seen a specific person be identified (or their inaction be called out) in the past. I’m sure some tech people were probably fired after previous incidents at large companies, but not publicly.

    While the person wasn’t named, there was a report that this individual was no longer employed. Fired? Quit? Who knows. Certainly it’s likely that once this breach became public, anyone who might have been responsible for watching CERT lists, applying patches, or anything to do with Apache Struts might be blamed. In fact, I don’t know I’d want to continue working at a company that might publicly blame my role for a massive breach. My career might be dead with that management, so I might as well move on. Much easier for everyone to blame me than accept responsibility.

    This is the first time I’ve seen an IT employee blamed. BA said an IT systems failure with their major issues. Yahoo and Target were hacked, but no one in IT was blamed. Sony didn’t blame their IT staff after their emails and films were released. Yet Equifax did. I hope this isn’t a sign of things to come.

    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.

  • Enabling Database Containment for an Instance – #SQLNewBlogger

    Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers. This is also a part of a basic series on git and how to use it.

    I wanted to test a contained database feature the other day and ran this:

    ALTER DATABASE [sandbox2] SET CONTAINMENT = PARTIAL WITH NO_WAIT
GO

    However, this didn’t work. I ended up with an error:

    Msg 12824, Level 16, State 1, Line 3

    The sp_configure value 'contained database authentication' must be set to 1 in order to alter a contained database.  You may need to use RECONFIGURE to set the value_in_use.

    The issue is that the server instance needs to have contained authentication enabled in order to pass any authentication requests to the database

    EXEC sys.sp_configure N'contained database authentication', N'1'
GO
RECONFIGURE WITH OVERRIDE
GO

    Now I can run the code again to alter the database for containment.

    SQLNewBlogger

    The issue was obvious to me since I’d dealt with it in the past, but this is something you could solve and write up in 10-15 minutes.

  • The Problems with Gods

    When I was learning how to work with computers early in life, I ran across various documentation and writings that would liken the root account to being a god on the system. Over the years, I’ve seen other articles that note will describe “God mode” in various software systems. There have even been science fiction books describing the god-like abilities of a person that obtains a privileged account on a system.

    To me, this is one of those places where our industry is immature. Having an account that can perform any task on a system, with no limits, is indeed like a god. This account can do anything, which is a double edged sword. Someone can reconfigure, fix, patch, update anything to ensure the system runs well. Or they can “rm /rf” the system.

    Recently Verelox had their entire system wiped out by a former administrator. There are a variety of problems with this story, not the least of which is leaving old credentials active. Mike Walsh wrote about some of the issues from a backup perspective. I would add from a security perspective that this is why an individual’s credentials need to be disabled immediately, and any well known, long time passwords need to be changed. We do this in the physical world by changing locks. We need to do this in the digital work as well.

    However, I see a overreaching account with unlimited privileges as fundamentally a bad idea. Sure, this makes installing software or reconfiguring our system easier, but perhaps we should be required to use separate accounts for all sorts of options. This is especially true when we build a distributed system across multiple machines. As the number of services and systems increases, the value from having one account able to accomplish every task outweighs the potential issues.

    Humans make mistakes. We make inadvertent ones when we’re tired or distracted. We make malicious mistakes we regret; we make emotional mistakes by overreacting to a situation. We make mistakes based on incorrect information. If we have all the power over a shared system, then we may easily make mistakes that could cause an extraordinary amount of damage.

    Our modern systems should include the ability for a separation of all duties and more default accounts that we configure. At the very least we should separate administration from auditing, and perhaps security as well. A slight inconvenience during setup is worth accidental issues in the future. Having separate accounts for different functions will also help to slow down the potential problems in the future by ensuring no one user account can be used to perform every function on a platform if it’s compromised.

    Steve Jones

    The Voice of the DBA Podcast

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

  • A SQL Server Bug and Data Security

    This week I saw a post from Microsoft Tiger Team on the issues with backup compression and TDE databases. Apparently when they added compression, they didn’t test a few edge cases. Or a few regular cases, like WITH INIT. There is a possibility that your data could be corrupted, which is a major problem. I have found the SQL Server backup and restore capabilities to be very solid over the years, so this is disturbing. If you use TDE, apply SQL 2016 CU7 for RTM or SP1 CU4 ASAP. Test your restores, and be sure you know what you can recover and what you can’t. If Mr. Murphy has anything to say about it, you’ll have an issue soon, so test your restores.

    Overall, SQL Server security is very good, but there are certainly issues with applications and devices that connect to SQL Server. You never know when some item that queries or alters data in SQL Server will cause issues. This week there were a couple notes from Bruce Schneier on FaceID and Bluetooth security, the latter of which has a vulnerability issue. Be sure you are aware of issues here to actually help protect yourself with your devices, but I was amazed to see this piece on infrared camera hacking. A POC on using light to jump air gaps is truly frightening. It seems that truly anywhere that we are processing data, we need to be thinking about security.

    The last few weeks are especially scary for many people, particularly with the Equifax breach. I know they have released numbers on people’s data, but I’d assume that everyone who has ever had credit in the US has a potential issue. I know I am being careful with credit and watching for issues myself. You should, too, and demand better security from companies you do business with. We can improve systems, but it will take more pressure to get companies to put more emphasis on better software and security.

    Steve Jones