SOX Compliance on external systems using PowerShell scripts in Secret Server
A critical component of many compliance mandates such as SOX, HIPAA, and PCI is guaranteeing that user activity is audited. Secret Server maintains an internal audit trail for user actions and access to shared privileged accounts, but it doesn’t necessarily guarantee that external systems maintain their own audits. After several customer requests, Secret Server can now be configured to audit external systems through custom PowerShell scripting to enhance auditing when a privileged account is used on an external system.
For example, we can look at Microsoft SQL Server’s auditing. How can an Administrator ensure that auditing of an account is in place when that privileged account is used?
Secret Server can be used to combine custom PowerShell scripts with its one time password (OTP) feature called CheckOut. This allows a user to access a password from the repository but Secret Server will change it to a new random password afterwards. Administrators can also upload PowerShell scripts to Secret Server and set them to run before an account is checked out, and after it is checked back in. This can be used to ensure that various compliance actions occur before or after a password is used.
In the below example I’ve created a Secret for an account with access to the AdventureWorks database, and set up an Audit Specification in Microsoft SQL Server.
In Secret Server I can now safeguard that the auditing I’ve set up for SOX, PCI, or HIPAA compliance is enabled whenever a user accesses the database with the AdventureWorksAdmin user.
On the Secret for the AdventureWorksAdmin user, I’ve enabled CheckOut. Now when a user accesses the account the password will be changed once they are finished. Next I uploaded a PowerShell script that ensures the Audit Specification is enabled on AdventureWorks, and set it to run before the Secret is Checked Out to the user.
This Hook guarantees that auditing is turned on by preventing CheckOut if the PowerShell script fails. If for any reason the script can’t ensure that the compliance auditing is enabled, then it will return an error and the user won’t be granted access the AdventureWorksAdmin SQL Account. The CheckOut feature will also change the password after the user is finished with the Secret, so users are forced to go through Secret Server to access the privileged account. This now provides named user audits in Secret Server that are tied to a specific shared account, and Microsoft SQL Server is guaranteed to maintain its own auditing whenever that account is used.
Latest posts by jcogley (see all)
- SOX Compliance on external systems using PowerShell scripts in Secret Server - February 25, 2013
- Devolution’s Remote Desktop Manager integrates with Secret Server - February 20, 2013