Part 1 and part 2 of this article described configuring ApexSQL Audit to meet PCI DSS 3.1 standard developed to ensure security of cardholders’ payments and data. In this part, the requirement sections 10-Track and monitor all access to network resources and cardholder will be described. For more details about differences between PCI DSS 2.0 and PCI DWW 3.0 and differences between PCI DSS 3.0 and PCI DSS 3.1, check the official PCI Security Standards Council LLC documents Summary of Changes from PCI DSS Version 2.0 to 3.0 and Summary of changes from PCI DSS Version 3.0 to 3.1January 6, 2016
From time to time, DBAs find themselves in a situation where a SQL Server database becomes too large for their production environment and needs to be shrunk in size in order to free space and allocate it back to the system.
Before shrinking a SQL Server database or database files, it is very important to understand how the process works and what are the immediate consequences of the shrinking process.January 4, 2016
The purpose of the SQL Server index is pretty much the same as in its distant relative – the book index – it allows you to get to the information quickly, but instead of navigating through the book, it indexes a SQL Server database.January 4, 2016
Part 1 of this article described configuring ApexSQL Audit to meet PCI DSS standards that developed to accomplish and to enhance security of payment card data. In this part, the requirement sections 7-Restrict access to cardholder data by business need to know and 8-Identify and authenticate access to system components will be described.December 14, 2015
The PCI DSS (Payment Card Industry Data Security Standard) is a multidimensional security standard designed as a set of technical and operational requirements to protect data of credit card holders. The PCI DSS applies to all entities that store, process or transmit cardholder data, including software developers of applications and devices manufacturers when used in those transactions
This standard originated in 2005 and was created by the PCI SSC (Payment Card Industry Security Standards Council) organization. The PCI SSC organization is founded by American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa, Inc., with a goal to improve security of payment account data via the PCI Security StandardsDecember 11, 2015
In Automating daily transaction log reading, we’ve shown how to automate the process of pumping transaction log data into SQL Server tables with ApexSQL Log. The proposed solution revolved around the creation of a batch file which runs ApexSQL Log CLI commands. The batch file is then scheduled with a Windows scheduler to run on a daily basis. The result is a regular daily update of 2 tables, specifically created by ApexSQL Log to hold audited data, which are populated with fresh auditing results each night.December 9, 2015
When confronted with a disaster recovery scenario with a very large database, but a small group of effected records, an opportunity exists to both speed the process and reduce risk of further damaging data, by updating more rows than necessary, simply by narrowing the subset of compared records.
ApexSQL Data Diff offers the ability to narrow the rows that should be synchronized, so only affected rows are updated. But, if the filtering isn’t done properly, “false positives” are risked, rows that are flagged as different/changed and should be synchronized, even if they weren’t in the subset of affected rows. Synchronizing these rows will update “good” data and roll back any production changes that may have been made, further damaging the data.November 6, 2015
A SQL database source control “label” or “tag” (aka revision tag) (name depends on the particular source control system) represents a snapshot in time of the source control repository and its contents. It can be saved as a reference for the future use. When the database development cycles reach a particular milestone e.g. a new build, a source control label can be created as a checkpoint. The team can continue to work on the database but revert to the source control label at any time.October 27, 2015
Having a team of developers working on the same (shared) database can be challenging for many reasons. It is critical to ensure that all changes are properly tracked and that each developer is informed about the status of objects currently used by the rest of the team. When using a shared database, all changes will be applied against the database before they are committed to the repository.October 9, 2015
Part 1 of this series shows how ApexSQL Audit should be set up for implementing the Administrative safeguards section of the HIPAA compliance (CFR 45 Part 164, Subpart C – Security Standards for the Protection of Electronic Protected Health Information developed to undertake protection of EPHI). In Part 2, the ApexSQL setup for fulfilling the remaining parts of the Administrative safeguards are discussed.September 22, 2015
Having a SQL Server database under source control is rapidly becoming the norm vs the exception in many software development teams. Using any development model (dedicated or shared), requires the team to establish a workflow and a set of rules. The dedicated model, though, allows a developer to act as an independent part of the process mainly in case the central server/repository is down. In this case, the team can continue to work unhindered. This article will focus on using the dedicated development model for SQL Server source controlSeptember 17, 2015
In Part 1 of this article it was presented how to set up ApexSQL Audit to implement Administrative safeguards standards of the HIPAA regulatory (the 45 CFR Part 164, Subpart C – Security Standards for the Protection of Electronic Protected Health Information that is developed to accomplish protection of electronic protected health information (EPHI)). In this part, the rest of the Administrative safeguards will be presented, while in the Part 3 we will provide ApexSQL Audit settings which will allow you to fulfill the HIPAA’s Technical safeguards and Policies and procedures and documentation requirements sectionsSeptember 14, 2015
The Health Insurance Portability and Accountability Act of 1996 (HIPAA) sets guidelines mandating the adoption of Federal privacy protections for health information of individuals which gives patients an array of rights with respect to that information. The HIPAA Privacy Rule ensures federal protections for individually identifiable health information and gives patients a range of rights with respect to that information. The Security Rule defines administrative, physical and technical safety measures to ensure the availability, confidentiality and integrity of electronic protected health information.August 31, 2015
Simply archiving information to audit a database is one thing, but successfully reconstructing an audit history to provide meaningful forensic data is another. It is important to be able to see a full history of user changes, as well as to be able to reverse changes that may have been accidental or malicious.
Ideally, such value-added information can be obtained without requiring a prodigious amount of archived data or creating significant performance impact on audited servers.
In this article, we are going to present two different approaches and solutions to before and after auditing.August 11, 2015
The following auditing implementations are recommended on a database level as part of any database security auditing system:
- Schema level auditing:
- DDL activity
- Changes made to stored procedures and triggers
- Changes to privileges, users, and security attributes
In the first part of the series, we’ve showed how to perform a point in time restore using SQL Server Management Studio and ApexSQL Log. In the second part of the article, we’re going to introduce two more solutions – performing a virtual restore (in time) with ApexSQL Restore, and performing a full point in time restore with ApexSQL Backup.July 31, 2015
The first part of the article provides a common application settings information and described how to meet the COBIT 4.1’s PO2.4 – Integrity management control objective requirements.
This sequel will describe recommended settings of the ApexSQL Audit that helps meeting the COBIT 4.1 control objectives:July 28, 2015
Achieving SOX compliance requirements is the mandatory for all publicly traded companies. But when it comes to most IT teams, SOX compliance can be quite vague and confusing. SOX compliance is not written with technology mandate in mind, but rather a mandate for accounting, legal, and financial reporting. In the SOX Act there’s no reference can be found to anything specific related to IT. It is often said that SOX was “written by lawyers, for lawyers”July 23, 2015
This article explains how to create filegroups and move indexes into a different filegroup, and how to backup a database without indexes with the purpose to reduce the amount of data required to perform backups thus reducing backup time and space required.July 2, 2015
Why running DBCC CHECKDB?
DBCC CHECKDB checks the logical and physical integrity of all the objects in a database and provides information of any corruption.
As performing DBCC CHECKDB is a resource exhaustive task it is recommended to run it on a production server when there is as less traffic as possible, or even better, as one of the ways to speed up the DBCC CHECKDB process, is to transfer the work to a different server by automating a process and run CHECKDB after a database restore. As a backup process is a copy of a database and a restored database will be exactly the same as an online database therefore if there were any inconsistencies or issues they will be in the backup, and found in a restore. By using this approach both restores will be tested and backups verified without any impact on a production database.June 22, 2015