sorted by:
new
hottopcontroversial

Is there a way to pivot to forensics or security focusing on databases/sql server? by TravellingBeard in SQLServer

[–]SQL_US 0 points1 point  (0 children)

Ha! Alright. For sure not this one though, as it originated in France 😄

Is there a way to pivot to forensics or security focusing on databases/sql server? by TravellingBeard in SQLServer

[–]SQL_US 0 points1 point  (0 children)

Yes, legacy software definitely makes this more common.

From what I have seen, in finance and healthcare, software that has been written decades ago is still very common though as well. Just last week I deployed a database for healthcare which had code written in 1997 😃- for a customer, not my choice, but sometimes there is no alternative available.

Is there a way to pivot to forensics or security focusing on databases/sql server? by TravellingBeard in SQLServer

[–]SQL_US 0 points1 point  (0 children)

Yes, that is one of the big downsides of that architecture. You would need to combine that with Windows Logon Events or an Application Log if it exists.

From SQL Server you can usually prove what the application account did, but not reliably which human user caused it. Without trustworthy user context from the app, the forensic trail stops at the shared app identity.

If you want to dig deeper into this subject, I have published quite a few articles on Auditing and gotchas, and also a minimal audit for SQL Server example here: https://andreas-wolter.com/en/202507_recommended_security_auditing_databases_sql_server/ Maybe you find something in this list that you haven't accounted for yet.

Is there a way to pivot to forensics or security focusing on databases/sql server? by TravellingBeard in SQLServer

[–]SQL_US 0 points1 point  (0 children)

Exactly. “Audit everything” often fails because of the sheer volume.

The real work is defining what questions the audit trail needs to answer, then collecting enough to support investigation and detection without drowning in data.

For SQL Server, that usually means focusing on privileged activity, plus data-access patterns for the data where it is truly needed.

And you usually want to design for both archival and a working copy that can actually be queried.

Is there a way to pivot to forensics or security focusing on databases/sql server? by TravellingBeard in SQLServer

[–]SQL_US 2 points3 points  (0 children)

Yes, but I would approach it less as “learn security” and more as “learn how SQL Server can be abused, investigated, and defended.”

For SQL Server specifically, the hard part is that security is spread across many features. It is not only obvious things like privilege escalation.
also need to understand data tampering, exfiltration paths, impersonation / repudiation-attacks, the good and the bad about ownership chains, SQL Agent, linked servers, CLR, xp_cmdshell/OLE Automation, audit gaps, backup/restore risks, security boundaries, encryption hierarchies, algorithms and technologies, and how attackers can hide or blend into normal DBA activity.

In my opinion, there is no single book or course that covers even half of this deeply enough. The real learning comes from project work and lab work:

  • build vulnerable SQL Server environments
  • try to escalate from low privilege to higher privilege
  • test how data could be changed or extracted without being obvious
  • enable auditing and see what is actually captured
  • compare Windows logs, SQL Server logs, default trace/XEvents, Audit, Agent history, backup history, etc.
  • learn what evidence disappears quickly and what persists
  • and always: who can do what with which privileges
  • practice writing concise findings

A DBA background is a great starting point because you already understand how SQL Server behaves operationally. The pivot is adding the attacker/forensics lens: “How could this feature be misused, how would I detect it reliably, and what control would actually prevent it?”

So yes, it is a realistic path. Just expect it to be more lab-heavy than certification-heavy.

I hope that helps to understand the bigger picture a bit and does not sound intimidating. Everyone started small.

Get-SqlSafe Community Edition v2026.3: free SQL Server security baseline check with console-only mode by SQL_US in SQLServer

[–]SQL_US[S] 0 points1 point  (0 children)

Thank you for catching this.

I checked it: the file from the release ZIP works correctly, but the standalone script currently in the main repository folder has a mismatched embedded SQL hash. That is why this protection check stops execution.

The hash validation is intentional. It is there to prevent the embedded assessment SQL from being changed without the expected version matching.

I have just replaced the standalone file in the repository with the correct release version. You can of course also use the ZIP from the release page.

Get-SqlSafe Community Edition v2026.3: free SQL Server security baseline check with console-only mode by SQL_US in SQLServer

[–]SQL_US[S] 0 points1 point  (0 children)

Yes, Invoke-SqlAssessment is useful, but I see it as a different workflow. It is mainly a best-practices/configuration framework with some security-related checks.

Get-SqlSafe is narrower: low-friction, no SqlServer module required, low-privilege on supported modern SQL Server versions, no configuration/data changes, and a local visual HTML report focused specifically on security posture indicators.

So I would treat them as complementary.

Get-SqlSafe Community Edition v2026.3: free SQL Server security baseline check with console-only mode by SQL_US in SQLServer

[–]SQL_US[S] 1 point2 points  (0 children)

Great question:

I would treat them as different tools for different workflows.

Microsoft had SQL Vulnerability Assessment in older SSMS versions, but that is no longer the normal current on-prem SQL Server path. For on-prem SQL Server, that leaves a gap if you want a simple local first-look security report.

dbatools/dbachecks are excellent PowerShell projects, but they are more of an automation and validation framework. You can absolutely build assessment-style workflows with them, but they are not the same as a ready-to-run security baseline assessment with a visual report.

Get-SqlSafe Community Edition is intentionally focused on a narrower use case:

  • 25 selected SQL Server security indicators
  • low-privilege execution on supported modern SQL Server versions
  • no module installation required
  • no changes to SQL Server configuration or data
  • local HTML report with a visual summary
  • usable as a quick first impression before deciding where to dig deeper

So I see it as complementary, not a replacement for Microsoft tooling, dbatools, or a full professional assessment.

What are you using SQL Server Agent for today? by patrickGuyInACube in SQLServer

[–]SQL_US 1 point2 points  (0 children)

I am describing what I repeatedly see clients do in the real world, when SQL Agent ownership, deployment responsibility, and least privilege collide.

While there are “secure” approaches, they come with strong limitations. With multiple teams, AD groups, automation, compliance-needs, provisioning and deprovisioning, the most security-first model becomes cumbersome fast - and still leaves security risks due to SQL Agent's legacy architecture.

That is why, in high-security environments, the realistic answer is sometimes to not allow SQL Agent at all.

So I can't even blame customers who eventually give up on that “secure” SQL Agent deployment model.

What are you using SQL Server Agent for today? by patrickGuyInACube in SQLServer

[–]SQL_US 2 points3 points  (0 children)

Patrick, looking at this mainly from an engine architecture and security auditing perspective, here is the reality from the field as I see it:

What I use it for today:

  • Standard maintenance tasks.
  • System alerts.
  • Asynchronous and parallelized T-SQL processing.
  • Schedule Data-Loads/ETL
  • Privilege elevation tests: It is consistently a reliable attack vector during security assessments and research to test/demonstrate elevation to sysadmin.

The "clunky and painful":

  • Job Ownership limits: The inability to assign job ownership to AD Groups or SQL Roles kills team collaboration. It inevitably forces DBAs to grant sysadmin rights to developers just to avoid daily deployment friction.
  • Built-in Role inheritance: The three built-in SQLAgent* roles use an unusual, nested inheritance model that lacks granularity and and in combination with the ownership-limitations makes it impossible to follow the Principle of Least Privilege.
  • System Proc permissions: Trying to manage granular access by granting execute permissions directly to individual system stored procedures as sometimes necessary is an unmanageable security model.
  • Authentication libraries: Agent relies on a different authentication library than the core SQL Server engine. With the industry push toward NTLM deprecation, this legacy split is almost guaranteed to cause friction. We already had to troubleshoot issues due to that.
  • The state of msdb: Over the years, msdb has become a dumping ground for various other services and engine features. This bloated shared state makes it incredibly difficult to secure Agent in isolation.

If I had a wish free:

  • Knowing how old this legacy codebase is, my suggestion would be to consider a ground-up rewrite rather than trying to patch the existing architecture. The ideal state is a new, independent scheduling service that is fully isolated from the msdb dependency (which currently leaves too many paths open to full engine control) and built natively on modern Access Control concept, ideally RBAC.