What is Accelerated Database Recovery?

Accelerated Database Recovery (ADR) came out in SQL Server 2019 and is an enhanced way for SQL Server to do database crash recovery. It uses a new Streaming Log (SLOG) feature that allows much faster redo and undo phases of the process by tracking any non-versioned actions.

The Persistent Version Store is another new component to the process. It holds row versions in the database itself, either on the data pages being modified or in a separate system table. This persisted version store is very similar to how read committed snapshot isolation uses row-versions to allow for read and write queries to operate without blocking each other. This holding mechanism for row versions is cleaned up periodically by a background process that removes unneeded row versions. This persisted version store, in combination with the SLOG, allows a couple of things.

First, in the redo phase there is no longer the need to read the transaction log serially from the oldest uncommitted transaction forward to the time of the crash to replay and redo records for creating a consistent state in the database. Instead, SQL Server uses the SLOG to recover any non-versioned actions from the oldest uncommitted transaction forward up to the point of the last checkpoint. This is much faster. Once the last checkpoint is reached, only then will SQL Server start reading the transaction log for any redo work.

Second, in the Undo phase, the SLOG is used again to undo any non-versioned operations, and the persistent version store is used to simply switch the database rows back to whatever the proper current row was at the time of the crash.

Traditional Recovery: Picture from https://learn.microsoft.com/en-us/sql/relational-databases/accelerated-database-recovery-concepts?view=sql-server-ver17

Recovery using Accelerated Database Recovery: Picture from https://learn.microsoft.com/en-us/sql/relational-databases/accelerated-database-recovery-concepts?view=sql-server-ver17

Why would you want to enable Accelerated Database Recovery?

Accelerated database recovery can save you and your clients from extended outages due to long rollback times under heavy load. I’ve seen rollback times of 45-60 minutes be reduced to seconds with this feature enabled. The use-case I had was during SQL Server patching clients weren’t always out of the system as requested. In some cases, the client activity had a lot of changes in-flight when patching was applied and the traditional recovery method took a very long time after the server rebooted.

I enabled ADR and never had that problem again. This feature can also save you from pain you inflict on yourself. If you’re running a query to make a lot of changes and it is decided to kill the query, causing rollback, then the ADR feature can execute rollback almost instantaneously. This is much better than waiting a long time for single threaded rollback of a query that has been running a long time.

How to determine if Accelerated Database Recovery is enabled?

The system table sys.databases can be queried to show whether this feature is enabled or not.

SELECT name
FROM sys.databases 
WHERE is_accelerated_database_recovery_on = 1;

How to enable Accelerated Database Recovery?

An exclusive database lock is required to enable Accelerated Database Recovery. This means the change should be done in a maintenance window where no activity is expected. The feature can be enabled in the presence of other activity using the termination clause WITH ROLLBACK [IMMMEDIATE | AFTER {Number} SECONDS | NO_WAIT] . Using the  IMMEDIATE option will immediately rollback other transactions so that the ALTER statement will complete. The NO_WAIT option will terminate the ALTER statement if it can’t be executed immediately. Choose one of the three options.

ALTER DATABASE [<db_name>] SET ACCELERATED_DATABASE_RECOVERY = ON WITH ROLLBACK [IMMMEDIATE | AFTER {Number} SECONDS | NO_WAIT;

What sp_configure settings should be adjusted for Accelerated Database Recovery?

First, the ADR Cleaner Thread Count option in sp_configure controls the number of cpu threads to use for the background cleaner process that removes old row versions from the Persisted Version Store. This option was introduced in SQL Server 2022. It is advisable not to set this to a large number. You can increase it from the default of 1 to 2 or perhaps 4 to ensure that Persisted Version Store cleanup is happening quickly enough across a large number of databases.

-- Configure ADR cleaner to use 4 threads
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;

EXEC sp_configure 'ADR Cleaner Thread Count', 4;
RECONFIGURE WITH OVERRIDE;

Second, the ADR Pre-allocation Factor setting can also be adjusted. If the “just in time” mechanism to allocate pages to store rows in the persisted version store is above zero by a significant amount, then this sp_configure option can be set to allocate pages ahead of time for the version store. There is an extended event called tx_version_optimized_insert_stats that can be reviewed to see what the “just in time” value is. The value to check is labeled “foreground_allocation_percent.”

The default value for the ADR pre-allocation factor is 4. The number of pages allocated at any one time is 512 X the ADR Pre-allocation Factor. It isn’t recommended to set this fact too high because pre-allocating too many pages can cause contention.

-- Configure ADR Preallocation Factor
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;

EXEC sp_configure 'ADR Preallocation Factor', 6; -- Defaults vary based on workload
RECONFIGURE WITH OVERRIDE;

Is a Long Rollback Costing You Downtime?

SQL Server recovery issues can turn a routine maintenance window into a multi-hour outage. The SERO Group specializes in exactly this kind of proactive SQL Server management. Schedule a free discovery call and let’s talk about your environment.

The post An Overview of Accelerated Database Recovery appeared first on The SERO Group.

• A runaway transaction filling up a log file or even an mdf file in a user database or tempdb.
• Someone or some process took an extra backup that wasn’t planned for.
• A new database was created with larger than expected files sizes.
• An application is using the Volume Shadow Service to make backups of databases to a local volume.

This last scenario related to volume shadow service is what I want to talk about today. This one can be a little confusing at first because your organization may get a low disk space alert that doesn’t seem to make sense. The alert may indicate that there is less than 10% free space, but looking at the volume in Windows Explorer doesn’t show that at all. It turns out that VSS files aren’t visible to Windows explorer. You might come across this when investigating the following error, “Volsnap – 36 – The shadow copies of volume E: were aborted because the shadow copy storage could not grow due to a user imposed limit.”

To investigate what is happening, try some of the VSSAdmin commands, like this:

vssadmin list shadowstorage

The output pf this PowerShell command will show what volumes are being backed up by VSS, and what the target volume is for those VSS files. If the volumes are already low on space, deleting some of the shadow copies may be the first thing needed. This can be done with the following command:

vssadmin delete shadows /for=<ForVolumeSpec> [/oldest | /all | /shadow=<ShadowID>] [/quiet]

Then a limit can be placed on the amount of storage allocated to VSS files using this command:

vssadmin resize shadowstorage /for=<ForVolumeSpec> /on=<OnVolumeSpec> [/maxsize=<MaxSizeSpec>]

Keep in mind that someone will need to determine first if the older VSS files are needed prior to executing the delete and resize commands.

Tired of Chasing SQL Server Alerts?

Dealing with disk space issues on your SQL Servers? That’s exactly the kind of problem The SERO Group solves every day. Schedule a free discovery call and let’s take a look.

The post How to Use VSSADMIN Commands To Manage Low Disk Space appeared first on The SERO Group.

As I sat there, I ended up reflecting back on 2025. I found myself gravitating to these three questions:

• What went well this year?
• What did I learn?
• What should I focus on next year?

If you’re a leader, I’m guessing you rarely get this kind of thinking time during your workday. I know I don’t. Our calendars are packed with calls, team meetings, and those “quick questions” that turn into two-hour troubleshooting sessions.

But here’s what I’ve learned: the quality of your strategic decisions is directly tied to the quality of your thinking time.

And thinking time doesn’t happen by accident. You have to protect it.

What Went Well This Year?

When I asked myself this question, I didn’t think about our biggest projects or flashiest achievements. I didn’t think about when we migrated almost 2,000 databases as part of an upgrade project. Or the performance tuning we did that resulted in a $36,000 reduction in annual Azure spend for a client.

Instead, I thought about the relationships we strengthened. The trust we built with clients. The problems we solved before they became crises.

For you, this might look like:

• The audit that went smoothly because your security documentation was solid
• The successful disaster recovery test that was possible because you kept refining the process
• The team member you mentored who’s now ready for more responsibility
• The support resources you provided your team through a trusted partner

These aren’t always the things that make it into board reports. But they’re the foundation that everything else is built on.

What Did I Learn?

This year reminded me of something Eisenhower once said: “Plans are worthless, but planning is everything.”

The need for planning cannot be overstated. It’s critical. Even if the plan doesn’t always work out the way you intended.

The plan itself wasn’t the point. The thinking I did while creating the plan was the point.

Because I’d thought through our capacity, our ideal client profile, and our service delivery model, I could adjust quickly when reality didn’t match my spreadsheet. I knew which opportunities were a good fit for us and which ones to let go. Because we’ve intentionally built a small but incredibly talented team that genuinely wants to see our clients succeed, we were able to identify and create ways to help them.

I watched the same dynamic play out with clients. The institutions that had documented their SQL Server environments, tested their disaster recovery plans, and mapped their compliance requirements adapted quickly when needed. They were positioned for success even when the unexpected happened.

Planning isn’t about predicting the future. It’s about building the muscle memory to respond when the future surprises you.

What did you learn this year about planning and adapting? Maybe it was:

• That your three-year technology roadmap needs quarterly reviews, not just annual ones
• That the disaster recovery plan sitting in a SharePoint folder isn’t the same as a tested DR plan
• That “we’ll address that next quarter” eventually becomes “why didn’t we address this sooner?”
• That having an expert on call beats having a plan to find an expert when something breaks

These lessons matter. Write them down. They’re not just hindsight—they’re your blueprint for better decisions ahead.

What Should I Focus On Next Year?

For me, the answer was clear: I need to help more financial institutions and healthcare organizations understand that they have options. Most CIOs think they have two choices for database management: hire a full-time DBA (expensive and hard to find) or make do with whoever can “figure it out” (risky and unsustainable).

There’s a third option: fractional DBA services that give you expert oversight without the full-time price tag.

For you, your focus might be different. Maybe it’s:

• Finally getting your SQL Server environment documented and audit-ready
• Building a disaster recovery plan that you’ve actually tested
• Move a little further along the SQL Server Maturity Curve
• Finding a partner who understands banking compliance, not just databases

Whatever it is, the key is to actually choose something. Not everything. Something. And move toward it. Make progress.

The Power of Quiet Reflection

Here’s the thing about those early Saturday morning moments: they’re rare. And precious.

During the week, we’re in execution mode. We’re responding, reacting, solving, and fixing. That’s necessary work. But it’s not strategic work.

Strategic work requires space. It requires stepping back from the urgent to focus on the important.

So, here’s my challenge to you as we wind down 2025 and usher in the new year:

Block Off Time Just to Think, Then Protect It

Maybe it’s Saturday mornings before your family wakes up. Maybe it’s a long walk at lunch. Maybe it’s 90 minutes with your calendar blocked and your office door closed.

Whatever it is, protect it. The decisions you make during that quiet time about where to focus, what risks to address, and which partnerships to invest in will help shape your entire year.

Your Turn

As you think about the year ahead, I’d encourage you to ask yourself those three questions:

1. What went well this year? Celebrate it. Learn from it.
2. What did I learn? Write it down. It’s wisdom you paid for.
3. What should I focus on next year? Pick one or two things. Not everything.

And if one of those focus areas is “finally get our SQL Server environment to a place where I’m confident, not just hopeful,” let’s talk. That’s exactly what we help institutions do.

If you’re a CIO wondering whether your SQL Server environment is as healthy and secure as it should be, I’d be happy to have a conversation. No sales pitch. Just two people talking candidly about database management. Schedule a time here.

The post Why Quiet Reflection Leads to Better IT Strategy Decisions appeared first on The SERO Group.

However, over time, many SQL Server environments quietly drift out of alignment with security best practices. Configurations age. Backups go untested. Access privileges expand without oversight. Multiple vendors are granted elevated access. And without a clear owner, risks grow quietly until something breaks.

5 SQL Server Security Actions to Take

Here are five simple, high-impact actions you can take to reduce SQL Server risk and strengthen your institution’s security posture:

1. Know What SQL Servers You Actually Have

Untracked or “orphaned” SQL Server instances are more common than you think. Over time, shadow IT, legacy systems, or test environments can go unnoticed. As CIO, make sure you have an up-to-date inventory of all SQL Server instances. Get a comprehensive list, along with who’s responsible for maintaining each one.

2. Review Who Has Access—and Why

Access control is one of your biggest areas of exposure. Application vendors often want elevated permissions, especially during the initial installation. Developers or business analysts may have been granted elevated permissions in the past to troubleshoot a query for an important report. The same is true for data engineers.

To check just how many hands are in the cookie jar, ask your team to provide a list of:

• All logins with sysadmin or elevated privileges
• All databases owned by someone other than sa or another designated account
• Any use of shared or generic SQL accounts

Restrict access to only what users need, and tie access to individual, auditable accounts.

3. Make Sure Backups Are Encrypted and Verified

A backup strategy isn’t just about having copies of your data—it’s about knowing those backups will work when you need them most. Ask your team how often backups are tested and whether they’re encrypted. Encryption ensures that sensitive financial data isn’t exposed if backup files fall into the wrong hands.

Equally important is regular verification using tools like RESTORE VERIFYONLY or full restore tests and integrity checks. A corrupted or incomplete backup doesn’t help you during a crisis.

Confirm there’s a clear retention policy in place that aligns with regulatory and business requirements. Backup success logs should be reviewed, and failed jobs should never go unnoticed. Don’t wait until something breaks to find out your recovery plan has holes.

Ask your team:

• Are backups encrypted to protect sensitive data?
• Are they tested regularly using tools like VERIFYONLY or, better yet, with complete test restores followed by an integrity check?
• What’s the retention policy, and is it enforced?

One bad backup can turn a small incident into a costly disaster.

4. Confirm That Audit Logs Are Running and Secure

Audit logs can be an invaluable tool for spotting suspicious activity and proving compliance. However, since audit logs are helpful only if they’re complete, accessible, and protected, make sure that:

• Auditing is enabled on all production servers.
• Logs are stored securely and encrypted.
• Someone is reviewing logs regularly to flag unusual activity.

5. Assign Clear Ownership for SQL Server Security

Securing your SQL Server is a key component of a multi-layered approach to security. But SQL Server security isn’t a “set it and forget it” project. It needs ongoing attention.

If your team doesn’t have a dedicated DBA, consider bringing in outside help. A trusted SQL Server partner (like The SERO Group) can help you monitor, maintain, and secure your environment without adding headcount.

Final Thoughts

SQL Server often holds your institution’s most sensitive data. These five actions can help improve your data security posture and reduce risk.

If you’re unsure where your SQL Server environment stands, or if your team is simply stretched too thin, we can help.

At The SERO Group, we specialize in helping banks and financial institutions reduce risk, improve reliability, and maintain compliance without the cost of a full-time DBA. Let’s schedule a quick call to talk through your current setup and see where we can support you. Schedule a no-obligation discovery call with us to get started.

The post 5 SQL Server Security Priorities Every Bank CIO Must Address appeared first on The SERO Group.

If your organization relies on SQL Server, you can’t afford to take its security for granted. This post outlines key strategies to secure your SQL Server and strengthen your organization’s overall data protection efforts.

1. Harden Your SQL Server Configuration

Out-of-the-box installations of SQL Server aren’t secure by default. Misconfigured servers are one of the top causes of successful cyberattacks, and even small oversights—like unnecessary enabled features or open ports—can provide a foothold for attackers.

Start with a hardening baseline, such as the CIS® Benchmarks™ for SQL Server. These community-developed best practices provide a comprehensive checklist for reducing risk—from setting appropriate authentication requirements to disabling unused services and ensuring proper auditing configurations.

Many organizations are surprised by how many of their SQL Server settings fall short of these benchmarks. Evaluating against their standard is a low-cost, high-impact step toward improving your security posture.

2. Keep Patches and Updates Current

SQL Server patches and cumulative updates don’t just include performance improvements—they also fix known vulnerabilities that cybercriminals can exploit.

Whether you’re running SQL Server on-premises or in the cloud, patch management needs to be part of your ongoing operations strategy. Implement a structured update process that includes:

• Testing patches in staging before production
• Coordinating patch timing with other application dependencies
• Automating patch notifications and scheduling when possible

Waiting too long to apply patches can leave you vulnerable for months, especially as exploits for known issues are often publicly available shortly after disclosure.

3. Implement Role-Based Access Control (RBAC)

Not everyone needs full access to everything. One of the simplest and most effective ways to reduce risk is limiting access privileges based on the principle of least privilege.

Use role-based access control to ensure users only have access to the databases, objects, and actions necessary for their job. Avoid using sysadmin-level accounts unless absolutely necessary, and regularly audit permissions to identify over-provisioned users.

In addition, always use Windows Authentication where possible. It integrates better with Active Directory policies and enables centralized password and identity management.

4. Monitor and Audit Database Activity

Even well-configured SQL Server environments can be breached. That’s why real-time monitoring and auditing are critical for detecting threats early and responding quickly.

SQL Server’s built-in audit features allow you to track logins, permission changes, data access, and schema modifications. This data can help identify unusual patterns that may indicate a compromised account or insider threat.

In our blog post on SQL audit features, we highlighted how auditing can deter malicious activity, support compliance efforts, and provide vital information during forensic investigations.

For enhanced protection, consider integrating audit logs with a Security Information and Event Management (SIEM) platform for centralized monitoring and alerting.

5. Protect Against Ransomware and Data Exfiltration

Ransomware attacks against database systems are becoming more sophisticated—and more costly. In addition to encrypting your data, some threat actors now exfiltrate data and threaten public leaks if a ransom isn’t paid.

To protect your SQL Server:

• Segment your network to prevent lateral movement
• Regularly back up your databases and test your recovery process
• Encrypt sensitive data both at rest and in transit
• Use endpoint protection and file integrity monitoring tools

Don’t forget physical security too—especially if you host SQL Server on-premises. Server room access should be restricted, monitored, and logged.

Need Help Securing Your SQL Servers?

SQL Server security is a constantly evolving challenge—and it’s easy to miss critical vulnerabilities when you’re focused on daily operations.

At The SERO Group, we specialize in helping organizations like yours secure their SQL Server environments, identify weaknesses, and stay ahead of threats. Whether you need a comprehensive SQL Server CIS® Benchmarks™ Assessment or want to take our free SQL Server Security Self-Assessment to get started, we’re here to help.

Let’s work together to protect your data and build a more secure SQL Server environment. Contact us today to learn more.

The post Five Ways to Protect Your SQL Server from Cybersecurity Threats appeared first on The SERO Group.

Since 2015, the FFIEC CAT has helped financial institutions assess cybersecurity risks and maturity levels. However, the FFIEC recently announced that the CAT will sunset on August 31, 2025. Now, banks must determine the best alternative to ensure continued compliance and security. The FDIC’s official announcement encourages institutions to adopt a risk-based approach that aligns with broader industry standards. Yet, this shift leaves many banks searching for a practical, structured replacement that integrates seamlessly with financial IT environments.

Top Three Replacement Options for the FFIEC CAT

Read about each of the three best replacement options, or skip ahead to the next section to see our top recommendation.

1. Center for Internet Security® (CIS®) Benchmarks™

CIS® Benchmarks™ provide security configuration recommendations to help organizations safeguard their IT environments, including Microsoft SQL Server.

Benefits of CIS® Benchmarks™:

• Proactive Defense Against Cyber Threats: Financial institutions face growing threats, including ransomware, insider threats, and zero-day exploits. The CIS® Benchmarks™ offer security recommendations to help mitigate vulnerabilities before attackers can exploit them.
• Industry-Recognized Security Recommendations: Developed through a collaborative, expert-driven process, the CIS® Benchmarks™ align with global security frameworks and are widely adopted by organizations seeking to enhance their security posture.
• Microsoft SQL Server Security Hardening: The CIS® Microsoft SQL Server Benchmark™ includes detailed recommendations to help reduce attack surfaces, strengthen authentication, and enforce encryption—all essential for banks handling sensitive financial data.
• Specific Alignment with FFIEC Guidelines for Stronger Security: CIS® Benchmarks™ offer specific security recommendations tailored to IT infrastructure.

2. National Institute of Standards and Technology (NIST) Cybersecurity Framework (CSF) 2.0

The NIST CSF 2.0 is a widely recognized framework designed to help organizations manage cybersecurity risks using a flexible, risk-based approach.

Benefits of the NIST CSF 2.0:

• High-Level Framework for Risk Management: The NIST CSF 2.0 is structured around six key functions: Govern, Identify, Protect, Detect, Respond, and Recover. These functions help banks develop a comprehensive cybersecurity strategy that aligns with regulatory expectations.
• Broad Application Across Industries: Unlike the FFIEC CAT, which was specifically designed for banks, the NIST CSF 2.0 applies across multiple industries.

3. Financial Sector Cybersecurity Profile (FSP)

Designed specifically for financial institutions, the FSP aligns with NIST CSF 2.0 and existing financial regulations to provide a banking-focused cybersecurity framework.

Benefits of the FSP:

• Regulatory Compliance Simplification: The FSP integrates best practices from FFIEC, NIST, ISO, and other regulatory bodies, helping financial institutions map cybersecurity controls directly to compliance requirements.
• Scalability: Unlike one-size-fits-all models, the FSP provides tiered recommendations based on a bank’s size, complexity, and risk exposure. This makes it an effective, adaptable solution for financial institutions of all sizes.

Why CIS® Benchmarks™ Are a Great Choice for Banks

Industry experts designed CIS® Benchmarks™ to provide prescriptive security recommendations for real-world threats. Unlike broad frameworks, CIS® Benchmarks™ offer actionable configuration guidance, making implementation and measurement easier. Financial institutions benefit from standardized security settings that align with industry regulations and best practices. By following CIS® Benchmarks™, banks proactively harden Microsoft SQL Server environments and reduce cybersecurity risks.

How to Implement CIS® Benchmarks™ in Your Cybersecurity Strategy

Here’s how financial institutions transitioning from the FFIEC CAT can leverage CIS® Benchmarks™:

• Microsoft SQL Server CIS® Benchmarks™ Assessments: Regularly assess SQL Server configurations using CIS® Benchmark™ recommendations to help improve security and maintain compliance.
• Automate Compliance and Monitoring: Utilize security tools that support CIS® Benchmark™ assessments to monitor compliance and security configurations through automated processes.
• If Your Institution Already Has Access to NIST CSF 2.0, Get Specific Recommendations: Align risk assessments and security policies with the NIST CSF 2.0 while using CIS® Benchmarks™ for implementation guidance.

Partnering with The SERO Group for a Secure and Compliant Future

Looking for a structured cybersecurity approach because of the FFIEC CAT sunset? The SERO Group offers assessments based on CIS® Benchmark™ recommendations to help banks enhance security and maintain compliance. Schedule a no-obligation discovery call with us today to learn more.

The post Farewell, CAT: FFIEC Cybersecurity Tool Will Sunset This August appeared first on The SERO Group.

Just to be clear, storing sensitive information as a clear text string is a really, really, really bad idea.

Not encrypting information in a database can cause serious problems. As just one example, if the database is compromised, all user passwords could be exposed. Data breaches are becoming more and more common. If the authorities come knocking on your door, you need to be able to show them that you at least made a concerned effort to protect that data.

Encrypting text that will need to be decrypted

In some cases, you may be able to store your sensitive data as strongly encrypted text that will never need to be decrypted. For example, hashing a password used for your application login and then just comparing the hashed password for the login instead of the actual password. But, in most cases, being able to decrypt the sensitive data is going to be necessary.

In these cases,  ENCRYPTBYPASSPHRASE (available in SQL Server 2008 and up) offers one of the simplest ways for you to encrypt sensitive information in a way that can also be decrypted (by using DECRYPTBYPASSPHRASE). At its very basic, ENCRYPTBYPASSPHRASE requires two mandatory arguments: a passphrase used to generate the encryption key and the text to be encrypted.  Notice that it specifies a passphrase, not password. There is an important difference between these two.

A passphrase vs. a password

As described in the ENCRYPTBYPASSPHRASE documentation: 

A passphrase is a password that includes spaces. The advantage of using a passphrase is that it is easier to remember a meaningful phrase or sentence than to remember a comparably long string of characters.

Many people don’t realize that you can use a space as a legitimate special character in most passwords. By doing this, you can generate a much more secure password sentence (or phrase) instead of a single word. An example of a passphrase may be something like “I forgot my password!”

Just to be clear, a space is not required in your passphrase for ENCRYPTBYPASSPHRASE. If you wanted to use a GUID for your passphrase or a random string such as “Zgt9$Ex%*unZO8Z},” that is perfectly acceptable.

Using ENCRYPTBYPASSPHRASE

For the examples in this post, I am going to use the encryption passphrase “This is my Passphrase!”, and the text to be encrypted is “ABC123”.

The basic syntax is:
ENCRYPTBYPASSPHRASE(‘encryption passphrase’, ‘text to encrypt’)

There are other arguments that can be used with ENCRYPTBYPASSPHRASE (see MSDN Doc), but for this simple example we are just using the two mandatory arguments.

To view the encrypted value of the text “ABC123”, you would use this script:

SELECT ENCRYPTBYPASSPHRASE(N'This is my Passphrase!', N'ABC123');

That SELECT statement will return a VARBINARY value such as: 0x0100000093EEC20B790EF208B1FB631F0AB3028E3A8C196643C4BD578528A0DFAE7AB45B

It is important to note that the VARBINARY value returned from ENCRYPTBYPASSPHRASE is nondeterministic, meaning that even with the same input it will not generate the same output every time.  So you can run the exact same SELECT statement multiple times and get a different result each time.

Thankfully, this output has no bearing on using the DECRYPTBYPASSPHRASE function. As long as you have the correct passphrase, DECRYPTBYPASSPHRASE will successfully decrypt any of those VARBINARY results to their original value.

Storing an encrypted value in a table

Now that we know how to encrypt a sensitive text string, let’s take a look at how to store that encrypted value in a table.  Since the value returned from ENCRYPTBYPASSPHRASE is a VARBINARY data type, that is how we want to store it since this is also the data type required by DECRYPTBYPASSPHRASE.

The first thing we need to do is determine the size of our encrypted column in our table. The VARBINARY values returned by ENCRYPTBYPASSPHRASE can vary in size, with maximum size of 8,000 bytes. The size of the returned value is going to depend on the size of the actual text being encrypted. You can use the DATALENGTH function to help figure that out. If you have a way to control the maximum allowed length of the sensitive text value you want to encrypt, use that size for your table column, but try not to use VARBINARY(8000) if you don’t have to.

Here is a simple example of storing our encrypted text in the [Password] column of a table:

CREATE TABLE dbo.Users ([UserName] VARCHAR(50), [Password] VARBINARY(50))
 
INSERT INTO dbo.Users ([UserName], [Password])
VALUES ('Charlie Brown', ENCRYPTBYPASSPHRASE(N'This is my Passphrase!', N'ABC123'))
 
SELECT [UserName], [Password]
FROM dbo.Users

Using DECRYPTBYPASSPHRASE

Now that we have our sensitive text encrypted, we need to be able to decrypt it as well.  This is easily done by using the DECRYPTBYPASSPHRASE function with the same passphrase we encrypted our text string with. However, DECRYPTBYPASSPHRASE also returns a VARBINARY value, which we will have to convert to a string.  This can be done by adding a CONVERT function to our SELECT statement.

SELECT [UserName], CONVERT(NVARCHAR, DECRYPTBYPASSPHRASE(N'This is my Passphrase!', [Password]))
FROM dbo.Users

Now you should see your decrypted value returned correctly in clear text. ENCRYPTBYPASSPHRASE offers a quick and easy way for you to encrypt text in SQL Server and can be useful for encrypting sensitive information if you need to be able to decrypt it later. 

Want to work with The SERO Group?

Want to learn more about how The SERO Group helps organizations take the guesswork out of managing their SQL Servers? Schedule a no-obligation discovery call with us to get started.

The post How to Encrypt Sensitive Text in SQL Server with ENCRYPTBYPASSPHRASE appeared first on The SERO Group.

6 steps to ensure SQL Server compliance and pass your next audit

Let’s look at 6 key steps to get your SQL Servers audit-ready.

1. Document your SQL Server environment.

First things first: document your SQL Server estate. Create a comprehensive inventory of all your SQL Server instances. Include your production instances as well as your lower-level systems—dev, test, QA, demo, etc. 

But this isn’t just a list of SQL Servers; it’s your roadmap. Map out which databases correspond to which business applications. Even better, document your server configurations and security settings. 

When auditors come, you’ll have a clear, bird’s-eye view of your entire environment.

2. Review and tighten access controls.

Security is paramount in finance and healthcare. Therefore, auditors will want to review your SQL Server’s security measures.

Implement the principle of least privilege across your SQL Servers. This means giving users only the access they need. Audit your user accounts and permissions regularly. Are there any lingering accounts from former employees? How many people have elevated permissions? Are passwords hardcoded into configuration files or connection strings?

3. Implement robust logging and monitoring.

You’ll want to know when permissions have been changed. Was someone recently given elevated permissions? You’ll want to know that. Did someone leave the company? You’ll want to track when their access was removed from the SQL Server or database.

SQL Audit can help with this. It can capture changes to your key system’s security role membership, who added or removed a user from a server or database role, when they did it, etc. But you’ll have to enable and configure SQL Audit before you need it. It’s not enabled by default.

You’ll also want to review your SQL Server logs regularly and establish a log retention policy that complies with your industry regulations.

4. Ensure data encryption.

If you have data that you want to keep private, implement Transparent Data Encryption (TDE) to protect your data at rest. Encryption is equally crucial for data in transit.

Additionally, you’ll want to encrypt your SQL Server backups. If a breach happens and backup files are stolen, the bad actors won’t be able to access them without the key.

Remember, your encryption is only as good as your key management—keep those keys secure and well-managed.

5. Maintain patch management records.

Establish a regular patching schedule. Many companies have a monthly maintenance window. When a new update is released, it’s first deployed to a lower-level system, such as a test. Once vetted there, it can be deployed to the production environment.

We always read the release notes for each update to determine if it includes a critical security patch that should be deployed ahead of schedule. If so, we work with our clients to get the update before the Change Advisory Board (CAB) to review, approve, and deconflict the patch before the next maintenance window.

Document your patching process and implementation dates. This will show auditors that you’re proactive about security and system maintenance.

6. Conduct internal pre-audit assessments.

Start preparing for an audit in advance by documenting the processes you’re already following, such as:

• Performing regular vulnerability scans on your SQL Servers.
• Restoring backups to ensure they meet your company’s Recovery Point Objectives (RPOs) and Recovery Time Objectives (RTOs).
• Testing and refining your Disaster Recovery plan.

When you can show auditors that you’ve already identified and addressed potential issues, you demonstrate a proactive approach to compliance.

Stay audit-ready with proactive maintenance.

Preparing for an audit isn’t fun, but it doesn’t have to be a nightmare. The key is ongoing maintenance and dedication. Don’t think of audit preparation as a one-time event; consider it an ongoing process that keeps your SQL Servers secure, compliant, and performing at their best.

Ready to take the next step? Conduct a mock audit to gauge your readiness, and consider enlisting SQL Server experts for support. Your SQL Servers—and your peace of mind—are worth it.

Want expert help preparing for your next audit?

To learn more about how The SERO Group helps organizations stay audit-ready, schedule a no-obligation discovery call.

The post Audit-Ready SQL Servers: The Complete Game Plan appeared first on The SERO Group.

Let’s dive into some of the major risks you might face while managing your SQL Server estate. We’ll also explore some practical ways to mitigate those risks and keep your SQL Server estate running smoothly and securely.

Six Common Business Risks in a SQL Server Estate

Risk 1: Data Breaches

Data breaches are an obvious and constant threat. Hardly a day goes by without a security incident or data breach making the news. A single successful attack can expose sensitive information, damage your company’s reputation, and lead to hefty fines or lawsuits.

Securing your SQL Server estate is essential, and securing the perimeter is not enough. The best security is multi-layered.

To fortify your SQL Server defenses:

• Implement strong access controls and use multi-factor authentication.
• Regularly update and patch your SQL Server instances.
• Encrypt sensitive data both at rest and in transit.
• Conduct regular security audits to identify and address vulnerabilities.
• Train your teams on security best practices and the importance of data protection.

Risk 2: Disaster Recovery

Disasters happen. Sometimes large-scale events like a tornado, flood, or a disruption to your cloud provider’s region may affect your business. Sometimes disasters are more localized, like a hypervisor or operating system crash.

Regardless, without access to your data, operations can be significantly hampered or even completely offline. So, being prepared to quickly recover from such events is crucial for business continuity.

To improve your disaster recovery readiness:

• Develop and regularly update a comprehensive disaster recovery plan.
• Regularly test your disaster recovery procedures to identify and address any weaknesses.
• Consider cloud-based disaster recovery solutions for added flexibility and reliability.
• Ensure your team is well-trained on disaster recovery procedures and their individual roles.
• Implement high availability solutions like clustering or Always On Availability Groups.

Risk 3: Data Loss and Corruption

A common misconception is that data loss or corruption isn’t really an issue anymore. It is.

Database corruption can still happen. Users with higher levels of access can still accidentally delete needed data. And bad actors can still gain access to key systems and encrypt everything. And the results can be painful.

To protect your valuable data:

• Implement a robust backup strategy with regular backups stored securely off-site.
• Test your backups regularly to ensure they can be successfully restored.
• Implement change tracking and auditing to quickly identify and rectify data issues.
• Educate users about the importance of data integrity and proper data handling procedures.
• Use log shipping or Always On Availability Groups for critical databases.

Risk 4: Compliance and Regulatory Issues

Who has elevated permissions to your SQL Server estate? You’ll want to know and review that list regularly. When were users created and given access? When was the access removed? These are good questions to ask and answer, but that may not be enough.

If your company operates in a regulated industry or geographical location, you may be subject to regulatory requirements such as GDPR, CCPA, HIPAA, and others. Ensuring your SQL Server estate complies with relevant laws is crucial. Non-compliance can result in significant fines and legal headaches.

To navigate the complex world of data regulations:

• Stay informed about regulations that apply to your industry and data types.
• Implement data masking and row-level security to protect sensitive information.
• Cleanse data that is copied to lower-level systems such as dev, test, and QA.
• Regularly audit your compliance efforts and maintain detailed documentation.
• Use SQL Server’s built-in compliance features, such as Transparent Data Encryption and SQL Audit.
• Consider working with compliance experts to ensure you’re meeting all requirements.

Risk 5: Performance Issues

Poorly performing SQL Servers are more than just an annoying inconvenience. They can frustrate users, drive away customers, and affect your company’s bottom line. As the amount of data in your SQL Server estate grows, maintaining optimal performance becomes increasingly challenging.

To keep your SQL Servers running at top speed:

• Create a performance baseline.
• Regularly monitor performance metrics to identify bottlenecks.
• Optimize queries and indexing strategies.
• Implement proper capacity planning and scaling.
• Consider upgrading hardware or moving to cloud-based solutions when necessary.

Risk 6: Talent Shortage

SQL Server is a robust and reliable database platform. However, to achieve peak performance, reliability, and security, it must be regularly maintained. However, finding, recruiting, and retaining skilled SQL Server professionals can be a significant (and expensive) challenge.

To address this talent risk internally:

• Invest in ongoing training and professional development for your existing team.
• Create a positive work environment that encourages growth and job satisfaction.
• Offer competitive compensation and benefits packages to attract and retain top talent.
• Utilize managed services or cloud solutions to supplement your in-house expertise.
• If you rely on an Accidental DBA, provide them with the resources needed to succeed.

Managing Your SQL Server Estate

Managing a SQL Server estate is no small feat, but with the right strategies and precautions, you can significantly reduce your risks and keep your data operations running smoothly. Remember, it’s not about eliminating all risks – that’s nearly impossible. Instead, focus on identifying, understanding, and mitigating these risks to the best of your ability.

Remember, you’re not alone in this journey. Don’t hesitate to leverage external expertise when needed, whether it’s for specialized tasks, security audits, or strategic planning. With the right approach and resources, you can turn these challenges into opportunities to showcase the true value of a well-managed SQL Server environment.

Want to work with The SERO Group?

Want to learn more about how The SERO Group helps organizations manage their SQL Server estates? Schedule a no-obligation discovery call.

The post Reducing Business Risks for a SQL Server Estate appeared first on The SERO Group.

The late-2023 Xfinity breach, where 36 million customers had their personal information compromised, serves as a stark reminder of the ever-present threat of cyberattacks.

What happened?

The Xfinity breach stemmed from a vulnerability in Citrix software, dubbed “Citrix bleed.” Hackers exploited this vulnerability to gain access to a wealth of customer data, including names, contact information, usernames, passwords, birth dates, parts of Social Security numbers, and answers to security questions. These security questions can be used to attack other accounts at other institutions.

Recommitting to data security in 2024

The Xfinity breach is yet another a wake-up call for businesses to reassess and reaffirm their data security measures.

Securing SQL Server

For businesses, this breach underscores the importance of a robust and multi-layered approach to data security. These measures should consider and include hardening the SQL Server environment.

Here are some key steps to take:

• Minimize the attack surface: Uninstall unused SQL Server components such as SQL Server Reporting Services, SQL Server Integration Services, and other software and services to reduce potential vulnerabilities.
• Leverage Windows Authentication: This can enhance security by eliminating the need for separate passwords for database access.
• Leverage role-based security: Assign roles with specific permissions to limit access to sensitive data.
• Implement the principle of least privilege: Grant roles access only to the data the members of the role need to perform their jobs.
• Conduct regular audits: Track role membership changes. monitor user access for suspicious behavior.
• Consider SQL Server’s Transparent Data Encryption (TDE): This encrypts data at rest, adding another layer of security to sensitive data.

Securing user accounts

The most common vector for breaches over the past several years has been phishing. Users click on realistic looking links sent by bad actors. These links compromise their systems.

Education is the best prophylactic for phishing attempts and ransomware. Additionally, you can harden the environment by:

• Using strong, unique passwords for all accounts. Prohibit easily guessable passwords like birthdays or pet names.
• Enabling two-factor authentication (2FA) whenever possible. This adds an extra layer of security by requiring a second verification factor, such as a code sent to your phone, to log in. These should be table stakes in security.
• Being cautious about what information you share online. Avoid posting personal details on social media or other public platforms.

Additional tips

The Xfinity breach was just one of many in 2023. These serve as sobering reminders that no organization or individual is immune to cyberattacks. Municipalities, hospitals, banks, and every other industry are constantly under attack.

If you’re not sure where to start with hardening your SQL Server, here are a couple of resources to help:

• SQL Server Security Best Practices
• Protecting SQL Server from Ransomware

If you’d like some assistance, assessing your SQL Server environment, reach out. We’re happy to help.

The post New Year Resolution: Recommitting to Data Security and Lessons from the Xfinity Breach appeared first on The SERO Group.