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.
Ben Yoder is the Product Owner for Secret Server – you can find him at the Thycotic booth (#2644) at the RSA Conference in San Francisco this week. Stop by to chat to Ben about SOX, PowerShell scripting or other cool stuff.
Latest posts by jcogley (see all)
- New Webinar – Easily Manage and Secure all your Windows local administrator passwords - March 13, 2013
- SOX Compliance on external systems using PowerShell scripts in Secret Server - February 25, 2013
- Webinar: Secret Server Web Password Filler - February 20, 2013