• Stairway to Database DevOps Level 3: Managing Code as a Team in Git
• How We Ate Our ​Own Dog Food​ To Level-Up Internal Testing with Redgate Clone
• Top 10 Methods to Improve ETL Performance Using SSIS
• From the SQL Server Central Blogs - Handling physical deletes from the source and continue populating your analytical data store
• From the SQL Server Central Blogs - The Evolution of Database Administration: From Administration to Database Reliability Engineering
• Practical Graph Structures in SQL Server and Azure SQL: Enabling Deeper Insights Using Highly Connected Data

• Extracting JSON

The Justification Database

This editorial was originally published on Jan 18, 2019. It is being republished as Steve is on vacation.

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 - SSC Editor

Join the debate, and respond to today's editorial on the forums