In the previous parts of this series, we described two SQL Server auditing features – Change Tracking and Change Data Capture. We showed their characteristics, how to enable them, how to read the results, and listed their advantages and disadvantages
November 14, 2013How to analyze and read Change Data Capture (CDC) records
In the previous article, How to enable and use SQL Server Change Data Capture, we described the main features of SQL Server Change Data Capture and showed how to set it up. Now, we will analyze the records stored in change tables and describe the methods to read them
November 12, 2013Using SQL Server traces for SQL Server auditing – Part 3 – The out-of-the-box solution
In the previous part of the Using SQL Server traces for SQL Server auditing series, we described SQL Server traces technology, what it provides in terms of SQL Server auditing, and how it can be utilized via SQL Server Profiler and the native SQL Server fn_trace_gettable system function.
November 8, 2013Using SQL Server traces for SQL Server auditing – Part 2 – Querying a SQL Server trace
In the previous article we introduced and described the SQL Server traces technology, how it works and what it provides in terms of SQL Server auditing. In this article we’ll continue describing the default trace, and how it can be used with T-SQL, without SQL Profiler
November 8, 2013Using SQL Server traces for SQL Server auditing – Part 1 – The default trace
There are various scenarios that can cause problems with your SQL Server. These issues can come as a result of hardware/software performance issues, a physical failure of hardware components, and/or poorly written SQL queries among other things
November 8, 2013How to audit your auditing in SQL Server – tracking when triggers are disabled
SQL Server auditing triggers are mostly used to maintain the integrity of the information on a database, or to provide an auditing trail of data changes. A trigger is a special type of a database object which is automatically executed upon certain conditions – e.g. actions performed by the user. What auditing triggers must provide while auditing data changes are answers to the following forensic questions:
November 6, 2013How to enable and use SQL Server Change Data Capture
In the previous article, SQL Server Change Data Capture (CDC) – Introduction, we described the main characteristics of the SQL Server feature for tracking data inserts, deletes and updates – Change Data Capture. We also compared it to another SQL Server auditing feature – SQL Server Change Tracking
November 4, 2013SQL Server Change Data Capture (CDC) – Introduction
In the previous part of this series, How to read SQL Server Change Tracking results, we described SQL Server Change Tracking – its features, how to use it, and how to read the results. We also showed examples of the captured records. If you need to know is whether the row has been changed or not, the type of the last change, and which column was changed, without the details (old and new values, who, and when) about the change, then SQL Server Change Tracking is not the right auditing solution for you
November 1, 2013How to read SQL Server Change Tracking results
As described in the previous article of this series, What is SQL Server Change Tracking and how to set it up, SQL Server Change Tracking shows only the primary key column value for the changed rows, and the type of change – INSERT, DELETE, or UPDATE. Here we will explain change tracking functions, show code examples and demonstrate how to read the Change Tracking results
October 28, 2013What is SQL Server Change Tracking and how to set it up?
SQL DBAs are sometimes confused by the differences in SQL Server Change Tracking and Change Data Capture features. Not only can their names be mixed up, but also feature specifications. The goal of this series is to present each of 3 SQL Server auditing features (Change Tracking, Change Data Capture and SQL Server Auditing) and ApexSQL Audit – a complete third-party solution. We will show their features, similarities, differences, advantages, and disadvantages in order to help users determine the right tool for their auditing requirements
October 23, 2013Using SQL Server database snapshots to protect yourself against accidental data modification
Introduction
How often have you wished you could just quickly undo a DML statement without having to go through the lengthy process of restoring your database backup?
October 22, 2013How to audit SQL Server to comply with Basel II
What is Basel II
The Basel Capital Accord Basel II a set of international banking standards based on three mutually reinforcing pillars, issued by the Basel Committee on Banking Supervision in June 2004. It’s an improvement of the Basel I Accord, and it introduces a new approach to data management
Pillar 1 – minimum capital requirements – defines the minimum capital required to cover the risks that the bank might encounter. To put it simply – the financial institutions are required to have enough cash to cover potential risks.
October 16, 2013How to recover from a SQL Server database data-file corruption disaster
SQL Server database corruption recovery with transaction log backups
The worst-case scenario a DBA can encounter is a SQL Server database data-file corruption (due to physical or some other occurrence, the data files can be damaged and inaccessible)
October 11, 2013Audit failed SQL Server logins – Part 3 – the solution
Previously we’ve discussed failed logins, how they can indicate unauthorized SQL Server access attempts (Audit failed SQL Server logins – distributed queries, brute force attacks, and SQL injections), and using native tools to audit the failed logins and identify potential attack attempts (Audit failed SQL Server logins – using native tools to investigate failed logins).
October 10, 2013Audit failed SQL Server logins – Part 2 – using native tools to investigate failed logins
In the previous article of the Audit failed SQL Server logins series, we described the motives and most common methods used for unauthorized SQL Server access attempts. As a response, the best way to identify such attack attempts is to audit the failed logins
October 10, 2013Audit failed SQL Server logins – Part 1 – distributed queries, brute force attacks, and SQL injections
Failed SQL Server logins are common in various scenarios. Accidently mistyped credentials (user name or password), changed permissions, or expired password are some of the benign reasons for failed SQL Server logins. On the other hand, there are malicious failed logins – unauthorized attempts to access confidential data stored on a SQL Server instance, that are more of a concern
October 10, 2013SQL Server auditing and compliance for FERPA
What is FERPA
The Family Educational Rights and Privacy Act (FERPA) is a Federal law that protects the privacy of student education records. It gives students and their parents the right to access their education records, request to amend, and control over the record disclosure
October 9, 2013SOX survival kit for the SQL Server DBA
The Sarbanes–Oxley Act of 2002, Sarbanes–Oxley, Sarbox, or SOX is a US federal law “written by lawyers for lawyers”. It’s a regulation created to improve the quality and integrity of financial reporting, and ensure the financial and business information is factual and accurate.
October 4, 2013Meet GLBA compliance requirements for SQL Server
What is GLBA
The Gramm – Leach – Bliley Act (GLBA) was enacted in 1999. Its purpose is to protect consumer financial privacy. In order to meet GLBA compliance requirements, the financial organizations must inform their customers about the company’s information sharing and privacy practices. Customers must be given and explained their right to opt out (to say “no”) – if they don’t want their financial information shared with certain third parties
October 2, 2013Meeting PCI compliance requirements with SQL Server
What is PCI?
The Payment Card Industry Data Security Standard (PCI DSS, or just PCI) is an information security standard that protects cardholder and card payment information. The PCI DSS general requirements are designed to ensure a secure, monitored network, protect cardholder and transaction data, provide vulnerability management, strong access control measures, and maintain an information security policy
September 28, 2013
