Voice of the DBA

Tag: security

  • Complex Constrained Security

    I was reading about Kerberos and authentication with SPNs recently. It’s a topic that seems to make sense and appears orderly, but when I’ve had issues with SPNs, it feels like voodoo and black magic sometimes might be needed to get things working. As I read through the document, trying to ensure I would learn a bit more about how impersonation and delegation work, I noticed this sentence:

    “As a security best practice, Microsoft recommends constrained delegation over unconstrained delegation.”

    That seems reasonable to me. We ought to limit where users can connect to specific systems to ensure good security. This makes perfect sense where we have systems like web servers or application servers and we should limit delegation to specific databases servers. This wouldn’t prevent all security breaches, but it would limit the scope of many.

    The complexity comes when we start to have multiple servers that might connect to multiple back ends, especially as we grow our architectures to include additional HA nodes with Availabilty Groups. Tightly linking security complicates the configuration and requires that our sysadmins setup new machines and properly add new delegation targets as machines change. DevOps and configuration as code can help here with ensuring that we always add the required security changes to the right machines.

    That still doesn’t make it easy to manage a tight security environment without lots of resources. As we rotate or retire machines, we need cleanup of the security settings that refer to these objects. If we rotate host machines, which is usually rare, we need to remember to update out configuration scripts to work with new machines and accounts. If we add nodes, we need additional lines in scripts. If we move to containers for database servers, this might require even more changes.

    None of these items is complex, but when you must repeat them for many systems, many accounts, and on a semi-rare basis, they add some overhead that is both tedious and difficult to keep up with for a staff. This is especially true as staff turns over. Do you want to let the new people know that they need to make all these updates while handling their “normal work”? I could see all these details becoming a chore because we’re human, we’re flawed, and we make mistakes.

    I like the idea of tighter security, but at a scale, at random times, in between all the other tasks we must complete, the tools and techniques we have don’t make this something that seems manageable. I don’t have solutions, but I think that we do need some better tools that ensure security can be both flexible and convenient, while enforcing the principle of least privilege. The management of systems at scale is helping (forcing?) companies rethink some security tools and features, but there is still work to be done to ensure our employees will correctly and consistently configure security.

    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.

  • The Pros and Cons of Terabyte Phones

    A few years ago I wrote a piece about the growth of storage in many devices and the large quantities of data that can be kept. I speculated that we might see terabyte mobile phone storage in a decade. That was 2014 and this past week Samsung announced they had created a 1TB embedded Universal Flash Storage chip for phones. You can already get a Note9 with 512GB of storage, so this isn’t a huge leap, but it does feel like a milestone.

    For many of us, that seems like a good move. We can keep all the photos, videos, movies, and more that we want on our phones. I take a lot of pictures in life, and lately I’ve struggled with a 32GB phone. I keep debating upgrading, just because I’d like more storage. There are certainly challenges with keeping all this imagery and video backed up, but that’s a separate discussion. I’d like to just be able to capture data and make decisions about how to protect it later. There are also plenty of transient items (movies, Pluralsight courses, and more) that I just want to keep on temporary storage for a limited time.

    More is better, but it also creates potential problems. With a 1TB, or potentially larger, storage on my phone, what about the problem of data loss and theft by insiders? Very few of us work in jobs where we can’t keep our mobile device with us. Many of us also work with sensitive data, and there is a potential for transferring a lot of data to a relatively innocuous device. These days we might not even need to plug in our mobiles with bluetooth file transfer programs. Even if we plug in a phone, that’s innocent and expected? Modern smartphones often need charging during the day.

    It’s not just us, but also contractors, consultants, and non-privileged users that might be able to move data. Certainly someone might act maliciously, but what about the potential for new types of malware? Android is more open and iOS, and there have been viruses. How long before there are some virus programs that try to connect to every SQL Server, Oracle, MySQL, etc. database when plugged into your laptop?

    That might seem far fetched, and certainly our databases grow larger and larger, but much of the data is text, and more ERP/CRM programs are in use that contain known schemas where worms, virii, and other malware might target specific tables. A terabyte can store a lot of text data, especially if it’s usernames and password hashes.

    I don’t know of any mobile to PC infections yet, but I do know there are lots of smart people out there. It’s just a matter of time before someone starts to try and exploit the capabilities of modern mobile devices, especially those with large storage capacities.

    Steve Jones

  • The Justification Database

    I saw an article on the security at various Department of Defense facilities that control the ballistic missile systems in the US. It’s interesting reading, especially if you want to shake your head at bad practices. I think this article summarizes just how quickly the digital world has grown faster than the ability of humans to keep up and adopt new practices, especially where constant staff turnover is the norm.

    This is a good read for anyone in an organization that must plan for security and account for new staff on a regular basis. It certainly made me think a bit about how information is presented, disseminated, and the view from the other side. It’s easy for me to consider security and focus on that from my position, but for others that are tasked with other jobs, their view is completely different.

    There was one item in here that made me stop and think. There is a section, titled “No database with written justifications”, that notes that there wasn’t a database of reasons why someone was granted access. Through random sampling, the found that lots of employees didn’t have forms filled in completely with justifications and approvals. In some cases there weren’t even forms. I assume these are digital forms, but they could be paper.

    That made me think about the ways in which I’ve granted access to individuals in databases in the past. Often in small companies the request is verbal or in email, with approvals made the same way. Certainly there’s no tracking. In larger companies there might be tickets in some helpdesk system, but how do I track those back to clicking in SSMS to add a user to a role?

    This week I’m wondering how well managed your system is for managing and approving security changes? If someone was concerned that a hacker gained access through social engineering, could you track down where, when, and why someone was granted access? Are you regulated or audited? I know some people have great processes that limit the potential for abuse, but I also know that far too many people use exceptions to get work done. I wonder how many of you allow for exceptions to your process.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Better Static Code Analysis and Security Scans

    I was listening to a talk from Stefan Simenon on their CI/CD transformation within ABN AMRO, a large financial company. One of the interesting things he noted was that they consider open source to be less secure, possibly with more vulnerabilities than in house written software. Their build pipeline will fail if a developer starts using new OSS components.

    I find that interesting, as the DORA 2018 State of DevOps report sees more use of OSS software in companies that are adopting DevOps. In general, I think that having many people able to view the source and find errors makes companies feel that open source is more secure. I think that’s likely more true, though it’s a bit of a philosophical argument. We can look at some data, but it’s hard to prove that one or the other is empirically more secure.

    The thing I agree with is that using new components without some review is not a good idea. Whether this is written in-house, copied from an Open Source project, or purchased from a vendor, we need to perform some testing and analysis of the code or component.

    This is also true in database code. When we get a query from a developer, it’s often easy to determine what is happening, but when the size of code grows, or there is a large stored procedure, we often don’t perform a detailed analysis. What’s worse, we don’t have good static code analysis tools for database languages. As much as I like what Redgate Software has done with SQL Prompt, I know this is rudimentary and is built to avoid code smells. There isn’t any detailed look at whether the code is secure, or if there might be unintended effects.

    There aren’t really any good tools I’ve seen, though I’m not even sure what I’d want here. How can a tool tell me that querying 4 tables and updating 3 more is OK, but an insert to some other table in a separate database is bad. That insert to the other database might be what a malicious actor wants to copy data elsewhere. The best thing to me would be some analysis of what objects are being touched and how, which could help alert developers to potential issues.

    Building static code analysis tools for database languages is hard, but it’s something that our industry needs to do. This is even more true when we start to have more programmability features, like the ability to execute other languages inside of our database engines. In those cases, not only do we need to ensure the code for another language passes test, but that we understand what types of interactions our database code has with those modules.

    Steve Jones

    The Voice of the DBA Podcast

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