Press "Enter" to skip to content

Category: Security

System-Versioned Ledger Tables

Randolph West has a series on ledger tables in SQL Server. First up is a primer on the topic:

System-versioned ledger tables leverage the same technology: there is a table with current data in it, and an underlying history table which keeps track of changes. However, it uses a cryptographic chain that provides digital forensic evidence of tampering. Yes, if you’ll pardon the use of this phrase, I’m talking about a blockchain.

This is not a cryptocurrency. No one is using expensive graphics cards to produce a fiat currency in someone’s basement. Instead, each transaction affecting the database in question is cryptographically hashed using a SHA-256 algorithm and then stored somewhere off-site.

Part two separates out the two types of ledger table:

This week we will look at the different types of ledger table: append-only and updatable.

Unlike temporal tables, a ledger table can be append-only which makes it immutable. You can only insert data and therefore it does not need a history table. In fact, you may be using append-only tables in your data warehouse already. While this is secure, it may not be practical.

Part three covers limitations:

Every choice we make is a trade-off. New features have limitations, and ledger tables are no exception.

Some of these limitations are perfectly sensible. For example, the whole point of ledger tables is to ensure that we can provide tamper evidence. This necessarily means you can’t turn it off once it’s enabled, unless you drop the database entirely — this is just one scenario where a full defence-in-depth strategy is required.

Part four is the one I’ve been waiting for—an explanation why you probably don’t need this:

After writing several posts about a neat feature in Azure SQL called system-versioned ledger tables, it reminded me about something I’ve wanted to say for a number of years now, outside of snarky tweets.

Here goes:

You don’t need a blockchain.

In the vast majority of use cases, you need a properly audited relational database system with ACID compliance and a good recovery strategy.

There are very specific use cases in which data hashes and ledger tables make sense.

Comments closed

Four DBA ToDos in a New Role

Lee Markum has a starting point for DBAs in a new role:

You’ve just been hired into a DBA role at a new company, or you’ve been given the DBA keys at your current company. Maybe you’re a SysAdmin and your boss has informed you that you are now supposed to manage the SQL Servers as well as everything else on your plate. In any of these situations, you may have some confidence in your skills, but especially in the case of being a new hire, you have absolutely no true idea of what you’re walking into.

In these scenarios, where do you start? Start with these four areas.

Click through for the four areas. I completely agree with Lee on these for DBAs, including the order.

Comments closed

Starting SSMS with a Different Windows Login

Jack Vamvas does a thing I wish we could do innately in SQL Server Management Studio:

I  am logged onto my desktop with my primary Active Directory ID.  I need to log onto a SQL Server with SQL Server Management Studio (SSMS) with another Active Directory ID – the alternative ID has   valid  SQL Server security privileges on the target SQL Server. 

How can I log onto the target SQL Server with the alternative login  , remain on my desktop and use the alternative Active Directory ID ?

By the way, if you need to connect to a remote domain but your machine isn’t a member of that domain, add the /netonly flag to Jack’s answer. I’ve had to do this before when VPN’d into a network with a laptop not registered on that domain. Another tip is that, if you do this a lot, you might want to create a Windows shortcut which includes the full command.

Comments closed

Setting File Permissions inside a SQL Server Container

Anthony Nocentino wants to set some permissions:

This post will walk you through setting file permissions on database files copied into a container. The SQL Server process sqlservr running in containers runs as the non-privileged user mssql. The appropriate permissions on files are needed, so the SQL Server process has the proper access to any database files, log files, and backup files.

Click through for the process.

Comments closed

Slot Machine Company Data Breach

Jonathan Greig reports on a data breach:

Nevada Restaurant Services (NRS), the owner of popular slot machine parlor chain Dotty’s, has disclosed a data breach that exposed a significant amount of personal and financial information. 

In a statement, the company confirmed that “certain customers” were affected by the breach and explained that the information includes Social Security numbers, driver’s license numbers or state ID numbers, passport numbers, financial account and routing numbers, health insurance information, treatment information, biometric data, medical records, taxpayer identification numbers and credit card numbers and expiration dates.

I don’t normally link to data breaches too often because if I did, this site would be renamed to Curated Data Breaches given how frequently they occur. But what I want to know is, why in the world does a slot machine company have passport numbers, health insurance information, and medical records? What are they doing with that information? Slot machines are pretty simple: put quarter in, watch the screen light up and speakers make a bunch of happy noises, repeat until you run out of quarters. Unless there’s some sort of business arrangement where they put slot machines in the Nevada hospitals…

Also, the fact that credit card numbers and expiration dates were lost makes me wonder if they were actually PCI compliant.

1 Comment

Data Personas and Data Platform Rights

Craig Porteous wants us thinking about roles and permissions:

There are a great number of factors that contribute to an organisation’s data maturity, both technical and non-technical. The non-technical factors often have the biggest impact however. Such as how open to change the business’s upper management is, how much data is embraced by department and team leaders, and the training and support provided to utilise new technologies. All of these factors set the expectation and appetite for change within the business much more than the role out of a new product or technology.

Data Personas are one such area that contribute greatly towards Data Maturity as they define responsibility and access beyond the roles and job titles of team members. Individual team members may fit multiple personas or none at all. There are five core Data Personas that need to be established within an organisation for effective data governance and management with some additional personas on the periphery that can map a bit more to specific technical roles. The number of personas will vary depending on the maturity of the organisation’s data platform and their use of data but the core personas are relevant to all organisations.

Click through for an example set of personas and what kinds of rights they would need, broken down in a matrix of environment and data layer.

Comments closed

Reviewing Encryption Code Snippets from Stack Overflow

Scott Contini explains some problems with popular encryption code snippets on Stack Overflow:

I’m not doing this to shame those who have made mistakes: Instead, I want to do my part to help fix the problem. As an AppSec specialist, I get really tired of having the same discussions over and over. I try real hard to make it easy for people to do the right thing: I point them to code that is safe to use, such as Luke Park’s Secure Compatible Encryption Examples. Despite this, there are the occasional teams who just continue to resist, even before the code has made it to production which is the best time to fix it. This makes everybody’s lives more difficult: it wastes my time to have to explain to them why their code is wrong, and it forces the teams to have to do a lot more work later because once the bad cryptography is in production, they need a migration plan to fix it.

Read on for a great explanation of common problems in encryption code.

Comments closed

Azure Linux VM Agent Vulnerability

Nir Ohfeld finds another vulnerability:

Wiz’s research team recently discovered a series of alarming vulnerabilities that highlight the supply chain risk of open source code, particularly for customers of cloud computing services.

The source of the problem is a ubiquitous but little-known software agent called Open Management Infrastructure (OMI) that’s embedded in many popular Azure services.

When customers set up a Linux virtual machine in their cloud, the OMI agent is automatically deployed without their knowledge when they enable certain Azure services. Unless a patch is applied, attackers can easily exploit these four vulnerabilities to escalate to root privileges and remotely execute malicious code (for instance, encrypting files for ransom).

This has been patched, but it’s really ugly. H/T Ben Stegink.

Comments closed

Role-Based Access Control in Snowflake

Warner Chaves explains how role-based access controls work in Snowflake:

The data access privilege granularity is the lowest level of securable that you will use to provide data access. This can theoretically go all the way down to rows and all the way up to full databases. 

I usually recommend that people start out with using Schema as their data access securable granularity. Database is usually too broad and you will inevitably have to re-do your roles and table level. Below is too specific to turn it into a general methodology—you would end up with way too many roles. See the FAQ later in this post on how to mix and match granularities if needed.

Once you have the granularity defined, you then create back-end roles at that level.

Read on to see what those roles look like. It’s a pretty standard RBAC setup.

Comments closed