SOX Compliance on external systems using PowerShell scripts in Secret Server

25 02 2013

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.

Image

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.

Image

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.





Webinar: Secret Server Web Password Filler

20 02 2013

Sign up for the webinar here.

We will be covering:

  • the typical use cases
  • http versus https
  • CAPTCHA on login
  • changing form bindings
  • limitations
  • how to tell us about websites with issues
  • general Q & A

If you can’t make it at that time, we will also be recording the webinar.

Image

Sign up for the webinar here.





Devolution’s Remote Desktop Manager integrates with Secret Server

20 02 2013

Thycotic Software would like to thank our technology partner, Devolutions, for recently integrating their Remote Desktop Manager with Secret Server.

Remote Desktop Manager’s integration with Secret Server enables you to launch your remote access applications easily and securely without knowing the credentials. By using our publicly available Secret Server API, Remote Desktop Manager is able to retrieve Secrets with machine credentials and then launch a variety of applications like LogMeIn, pcAnywhere, TeamViewer and more. Using this combination of tools enables your users to log directly into applications without knowing the password increases your security posture. Secret Server provides full auditing information on credentials being accessed with Remote Desktop Manager, providing detailed reports on all applications launched.

Setting up Remote Desktop Manager to use Secret Server as the credential store is fast and easy. Start by creating a new Credential Store and select Secret Server from the list of credential options.

Image

Next create a new session and select the Secret Server credential repository.

Image

Using Remote Desktop Manager with Secret Server gives you even more flexibility and options for accessing your Secrets.





Sneak Preview: Bookmarklet 2.0

7 11 2012

Our team is working to make logging in to websites easier than ever with new bookmarklet functionality.

The new bookmarklet is able to work on any web page, and automatically log you in. It is only required that the web page has a secret in the Secret Server, and that the user be logged in to Secret Server.

This will greatly improve the compatibility over the web launcher. Sites that implement client-side validation, such as a CAPTCHA, were not compatible. With the new bookmarklet, the username and password will be filled out in the webpage itself, allowing the user to fill out just the CAPTCHA.

Form Filler

Above is an example of the bookmarklet working with Gmail. The bookmarklet will be compatible with recent versions of all major browsers. There isn’t an exact release date at the moment, but expect the functionality soon.





Sneak Preview: Dashboard Enhancements

18 10 2012

The next release of Secret Server has a lot of new functionality, in addition several tweaks to the user interface. We can catch a of glimpse of that now with one of the improvements to Secret Server’s dashboard. The Dashboard’s Secret View widget will now dynamically expand to take up the full width of the screen if there are no widgets to the right of it.

Fullscreen

This was a popular request, and it will allow users to utilize more of their screen space to work more effectively. Widgets can still be to the right of the Secret widget, just the way Dashboard works today.

Resize

This will be available in the next release of Secret Server, 7.9 along with many other exciting features. Expect the release within the next week or two.





Using a Web Launcher with Logmein

14 09 2012

Have you ever been in the situation where you needed to provide a full desktop to someone outside your organization? One way you might accomplish this is by creating a Logmein.com account allowing users to login remotely. A caveat to this solution is it requires external access to your Secret Server instance.

Follow these steps:

1. Create a Logmein account restricted to access only the target workstation.

2. Install the Logmein client on the target workstation.

3. Secure the internal workstation to include only the features you want users to use when accessed remotely.

4. Create a secret in a Secret Template that has the Web Launcher enabled. If you’re using stock Secret Templates the “Web Password” template will work just fine.

5. Enable the Web Launcher with these settings: Click Edit -> Launcher tab -> Configure Launcher Settings button -> Choose -> Type https://secure.logmein.com/login.asp for URL -> Finally click Test Launcher. If the launcher works, move on to Step 6. If the launcher doesn’t work, you may need to do some custom field mapping. Essentially the Email field from Logmein should be mapped to the username of the secret. Password is password, fairly obvious!

6. Create a user account in Secret Server that has read access to just this secret.

7. Hide the password from the users by clicking: Edit button for the Logmein account -> Security tab -> Edit button -> Check the Hide Launcher Password box -> Save.

Now, the target remote user should be able to login to Secret Server. When they do, they will have access to only this Logmein secret. Additionally, they will only be able to use the Web Launcher and not actually see the password. The end result is a remote user has access to a controlled internal system by simply logging in to Secret Server.

Note: The workstation being accessed remotely can be a virtual workstation. This would make it very easy to control content and access (if the virtual machine isn’t running, no one can access it).

Advantages:

  • This is very easy to use as it only requires a Secret Server account.
  • You’ll have an auditable history of when a user logged into Secret Server and the actions they took.
  •  Workstation login credentials don’t have to be shared or even visible.
  • This method of access works from multiple browsers and across operating systems and devices.




Secret Server and DoubleLock

13 09 2012

Do you have a need for additional security when storing your most sensitive data?

Where do you store the company’s banking account numbers and other critical financial data?  …top-level credentials for your customer database that contains Credit Card and Social Security numbers?  …credentials for classified system access?

When you need that additional layer of security within an already secure system, DoubleLock is your answer.  DoubleLock encrypts Secret data with an additional encryption key that is only accessible with an additional password that is unique per user, regardless of permissions or physical access to the machine running Secret Server. Private/public key encryption technology enables you to securely share access to the DoubleLock between users.

Benefits of enabling the DoubleLock feature include:

  • Secrets cannot be decrypted even if Secret Server is compromised.
  • Secrets cannot be decrypted even when someone is accidentally granted permissions to a Secret based on AD group membership.
  • DoubleLock provides an additional grouping of privilege to grant select individuals access to highly sensitive data.

There is one caveat to consider when using DoubleLock:

Resetting a forgotten DoubleLock password is irreversible and can result in permanent loss of the data. In the case that a user has sole access to a DoubleLocked Secret, the data will be lost and the Secret locked with that DoubleLock key will be deleted.  However, if another user has access to the Secret, they will need to re-assign you to the DoubleLock.

When resetting a DoubleLock password, a list of the assigned DoubleLocks and the Secrets they protect are displayed for the user.  Check that the secrets have at least one additional user with DoubleLock access.  This way, the data is not deleted due to a forgotten DoubleLock password.

To enable DoubleLock, a password will need to be created.  In Secret Server, click: Tools menu -> Create DoubleLock Password -> enter the desired Password (minimum 8 characters) -> Create Password.  Then, click on the Administration menu -> DoubleLock -> Create New button -> type a Name for your DoubleLock -> Save.

Now that a DoubleLock has been created, assign the appropriate users and secrets to the DoubleLock.  In more complicated environments, multiple DoubleLocks can be created.  Each of these DoubleLocks can be assigned their own set of users.  To assign DoubleLock to a secret, click the Edit button on the desired secret.  Then, click the Security tab -> check the Enable DoubleLock box -> select the appropriate DoubleLock in the dropdown menu -> Save.  Remember that the DoubleLock selected will already have a list of defined users.

As a safety net, always have at least 2 users for each DoubleLock to avoid the potential loss of data if the DoubleLock password has to be reset.





Sneak Preview: Secret Server Launcher for Mac

11 09 2012

The Thycotic Dev Team is hard at work with new functionality for Mac!  While I don’t have all the details, I do have a few items I can share.  Currently, we’re looking at an “end-of-Q4 2012” release date.  This date may slip, but it’s accurate for now.

Details I can share:

  • The Launcher will support Safari, Firefox, and Google Chrome.
  • The underlying technology uses is a NPAPI plugin. A quick install of a plugin is all it takes to enable the launcher for Mac.
  • Will support SSH and a built-in SSH client will be used.
  • Will support Microsoft Remote Desktop provided the Mac Remote Desktop application is installed.  See Figure 1 for the screenshot of Remote Desktop.  Figure 2 shows the Launcher Helper application in Firefox.

Figure 1

Figure 2

Features due out after the initial release (available in later updates):

  • Custom Launchers will be available in a subsequent update.  Remote Desktop and SSH will be the only launchers supported initially.
  • Session Recording functionality will be available in a subsequent updates.

The Dev Team is interested in hearing your comments, please post your questions and thoughts below!





Creating Custom Reports in Secret Server

30 08 2012

Secret Server contains robust reporting capabilities, as mentioned in on the Secret Server Report Features Page.  In addition to the default reports included with Secret Server (see Figure 1), additional reports are available for download in the Online Reports Gallery.  Beyond these options, users who aren’t familiar with SQL reporting, may also make a Custom Report Request from Thycotic Support.

Figure 1

One of Secret Server’s most popular features is the ability for users to create custom reports.  This allows users to build the reporting their organization requires.  To make a custom report, users will need some experience with SQL commands and reporting.  If you have experience, the following steps guide you through this process:

First, you need the code for the report you want to build.  The guide shows a report that allows users to see “What types of Secrets have expired?”  The SQL code is shown below:

-Begin SQL Code-

SELECT 
   st.SecretTypeName AS [Secret Template]
   ,COUNT(*) AS  [Number Of Secrets]
  FROM tbSecret s WITH (NOLOCK) 
   INNER JOIN tbSecretType st WITH (NOLOCK) 
    ON s.SecretTypeId = st.SecretTypeId
  WHERE 
   st.ExpirationFieldId IS NOT NULL
   AND s.ExpiredFieldChangedDate + st.ExpirationDays < GETDATE()
   AND s.Active = 1
   AND st.OrganizationId = #ORGANIZATION
GROUP BY
 st.SecretTypeName
ORDER BY
 COUNT(*) DESC

-End SQL Code-

Next, login to Secret Server with a user that has the Administer Reports role permission. Click on Reports -> Create it (located on the bottom right of the window). Assign a Report Name, a Report Description, and choose a Report Category in the dropdown menu (this is where the report appears). If your report should have a chart, choose the appropriate Chart Type in the dropdown menu. If you want your chart to appear in 3 dimensions, put a checkmark in the 3D Report box. Lastly, you’ll want to select your Page Size followed by pasting your SQL Code in the text box. Now, you can Preview the report and it will appear on the bottom of the same page. If you’re happy with the result, you can click Save and your report will appear on the main Reports page under the Report Category you selected.





How to Create a Custom Web Launcher in Secret Server

29 08 2012

Creating a custom Web Launcher in Secret Server is useful for several reasons.  First, it allows your organization to share online accounts without revealing the password.  Second, it saves time for Secret Server users.  It allows users to use one click from Secret Server seamlessly pass the credentials directly to the destination’s login page.  Used over time and across more than one site, it reduces the time spent on logging in.  It even helps to eliminate locked out accounts because the username and password don’t have to be typed in by a user.

To create a custom Web Launcher, start by using a Secret Template that has the Launcher feature enabled and configured to the Website Login type.  If you’re using a custom Secret Template, you can configure this by clicking Administration -> Secret Templates.  Select the desired Template in the drop down menu and click Edit. Click Configure Launcher and Edit. The box for Enable Launcher should be checked and the drop down menu for Launcher type to use should be Website Login.  Also, make sure the corresponding fields are matched properly (Password to the actual password field in the Secret Template and so on).  Make sure to click Save when making any changes!  Now your Secret Template is configured to use the Website Login Launcher.

Go back the secret you want to use to with the Web Launcher.  Click on Edit -> Launcher tab -> then Configure Web Launcher.  The URL should be populated in the field and you can click on View Page to verify you have the actual login page selected.  If not, browse to the actual login page and copy that URL to this field.  Then, click Next and Secret Server will evaluate the code to see if it can automatically pass credentials using the Web Launcher.  If you have the correct URL for login and the Web Launcher evaluates the login page as usable, you’ll see a list of Available Forms

You may need to experiment with different listings you may find in this field.  Many times, the choice is obvious.  In the case of twitter.com, the correct form is actually listed first.  Once you select a form, click Next and you may need to edit the mapped fields.  If the mapped fields are correct (user for UserName for instance) click Test Launcher.

If the launcher works, great job!  You’re done!  If it doesn’t work, make sure your fields are mapped correctly.  You may also want to click Reconfigure Web Launcher.  This will allow you to try a different form in the list of Available Forms.  Select a different form, try mapping fields again, and test the launcher.

Not all websites will allow the launcher to work, and even those that do may have exceedingly complex fields to fill out.  If this is the case, remember that you can contact support by posting in the Forums, by searching our Knowledge Base, or by contacting Thycotic Support directly!








Follow

Get every new post delivered to your Inbox.

Join 30 other followers