2013: A Security Odyssey

31 12 2013

What did 2013 hold for Thycotic Software? New partners, software releases, and other exciting milestones. Join us for our movie themed year-in-review.

This year, in the wake of dozens of newsworthy data breaches, the landscape for IT security broadened with every headline. The importance of securing privileged credentials and managing identity went from a “nice to have” to a “need to have” seemingly overnight. It became more apparent from IT teams across the globe that a spreadsheet was no longer a trusted, secure repository to manage privileged passwords in an organization.

So what did this mean for Thycotic? Keeping a close eye on security trends, we listened to our customers and built the features they requested to solve their most essential use-cases in privileged account management. But that wasn’t all we did.

Here are just a few highlights of what made 2013 a defining year for Thycotic Software.

Let it snow, let it snow? More like, let it grow, let it grow!

Inc. Magazine named us one of the Top 5000 Fastest Growing Companies in the US, and #33 in the top 100 fastest growing companies in DC. We couldn’t be more honored to receive this privilege. Our growth is attributed directly to our fantastic customers and our intelligent, hard-working team.

Lions, Tigers, and Splunk – Oh, My!

This year we announced several great partnerships, ending the year with an official announcement of our partnership with Splunk to release the Secret Server App for Splunk Enterprise. We’re proud of all of our new partnerships, and especially of our rapidly growing technology integration partner program. You can read more about the Splunk integration with Secret Server in our press release.

Come fly with me, let’s fly, let’s fly away.

We broke a personal record at Thycotic by sponsoring over 35 tradeshows across the world in 2013. We’ve presented dozens of keynotes, spotlight sessions, thought leadership interviews and spoke directly with thousands IT security and operations professionals in every major vertical about their security needs. Thanks to our dedicated team who worked round-the-clock to make those events a major success.

Release the kracken!

This year we’ve had several exciting releases to our products Secret Server, Password Reset Server and Group Management Server based on direct requests from our customers.

For Secret Server, some notable new features are: SAP support for natively changing passwords on SAP accounts; expanded API to increase automation in scripting; Custom Columns for a more tailored dashboard view; Website Password Changing to automatically change passwords for Windows LIVE, Google and Amazon accounts; SAML Support for increased security and single-sign on convenience; and Improved Discovery for Scheduled Tasks and Application Pools, now discoverable by Secret Server.

Other new product features are Active Directory Attribute Integration to let employees easily update their own AD information with Password Reset Server, and Group Renewal for Group Management Server to remind Active Directory group managers to double check their group membership from time to time.

So what’s next for 2014?

We think that 2014 will trump this year in success stories, growth, partnerships and products. We hope you join us every step of the way. Join us on LinkedIn and Twitter for the latest news in cybersecurity and be sure to stop by our booth at RSA 2014 in San Francisco as we kick off another thrilling year in IT security.  Also Thycotic is hiring, join the Thycotic team – read these great Thycotic reviews and see the latest Thycotic videos.






The Value of SIEM and How to Integrate with Secret Server

1 10 2013

What is a SIEM tool and why should I use one?

SIEM (System Information and Event Management) tools are a type of software that pulls in log and audit information from multiple sources across your network. This can include access logs for building entry, computers, servers, network devices, databases and applications. SIEM tools can aggregate all the data pulled so that you can get a clear picture of what is going on across your network by correlating events. It also provides real-time alerting in the case of security breach.

Here’s a quick example of how a SIEM tool can identify a breach. Say an employee – let’s call her Sarah – comes to work every day around 9:00 am EST. She’s an IT admin, so she beeps into the building with her key card, logs into her computer and starts checking on the status of her assigned servers. But, one day her computer is accessed in the middle of the night, long before she typically comes in. She hasn’t beeped back into the building and her VPN connection was never activated. This could be a security breach and someone better start asking questions. If the company had a SIEM tool, it would have alerted the company that something was wrong.

Secret Server can easily integrate with your existing SIEM tool. As a privileged account manager, Secret Server records a full audit of credential usage – who accessed what and when.  Secret Server can take this audit trail and send all of its information to the SIEM tool using Syslog or CEF format. Once the data is in the SIEM tool, it will compare events from Secret Server to other usage audits throughout your network.

Now, say that Sarah’s company used Secret Server with a SIEM integration for all admin passwords. One night, someone logged into one of Sarah’s servers as the local admin, but there was no indication that anyone logged into Secret Server to retrieve the password. The SIEM tool would be able to tell that a login occurred without Secret Server and flag it as a potential breach. The SIEM tool would then alert the company of the potential breach.

Secret Server is partnered with two SIEM tools, HP ArcSight and Splunk, Inc., with more integrations in the works. Find out more about Secret Server’s SIEM integration and syslog output on our support page!





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.





SSL Certificates, License Keys & More in Secret Server

27 08 2012

Do you have copies of your SSL Certificates, Licensing Data, and Support Documentation?  Of course!  Can you easily search for all of those files with a single term?  Maybe.  Is it well-organized, access-controlled, and verified?  Maybe not.

Secret Server supports the functionality above by simply building a Secret Template with the proper settings.  For example:  Instead of using DFS or a SharePoint plug-in to store your documentation and important files, why not leverage Secret Server?  You’ve already committed your Admin username and password.  By editing a Secret Template, you can easily create a designated file location for each workstation, server, and appliance in your network.  Once you’ve created the template, you’ll know precisely where all your documentation is stored.  When coupled with adequate Disaster Recovery plans (Microsoft SQL Clusters, Mirroring the database, or a frequent database backup), you’ve added additional layers of protection to your critical technical documents.

Storing documents in Secret Server has distinct advantages beyond access control and redundancy.  First, Secret Server admins can require fields to contain data before saving new secrets.  While you can’t control the quality of the documents that people might store – but at least you will know that a document was saved.  Second, these documents are encrypted in the Secret Server database.  Third, the documents can be relayed to a coworker or a third party with a simple http link.  (Note the previous blog post about this.)

Secret data saved using the "Hardware - Remote Desktop" Secret Template.

Secret data saved using the “Hardware – Remote Desktop” Secret Template.

Making a Secret Template may take some thought about what your organization finds useful.  However, once you’ve created a template, it’s very easy to edit, copy, and enhance.  One potential side benefit of structuring the above information is data in Reports.  Using some extra data points like I have in this Template may be of benefit in Secret Server Reports.

Thycotic’s Secret Template Gallery contains the content for the Secret Template I created above.  The Template can be found by searching “Hardware Remote Desktop” or by using this direct link.  Import this or any template by clicking Administration -> Secret Templates.  Paste the XML into the Import Secret Templates text box and click the Import button.

If you think you have a great and useful Secret Template, comment below!  We want to hear about it and what makes it useful.





Using Secret Server Links to Securely Transmit Sensitive Data

24 08 2012

Having been a Systems Engineer, I’m familiar with the problem of sharing credentials.  My method for sharing login credentials with a colleague consisted of access to a spreadsheet with everything or a Post-it that would be shredded (hopefully).  However, with Secret Server, System Admins are easily able to share credentials with colleagues by sending them a simple URL format:

http://SERVERNAME/VIRTUALDIRECTORY/SecretView.aspx?secretid=SECRETNUMBER

  • “SERVERNAME” is the DNS name or IP Address of the server that hosts Secret Server.
  • “VIRTUALDIRECTORY“ is the name of the Virtual Directory used when Secret Server was installed.  Typically, this is “SecretServer”.
  • “SECRETNUMBER” is the actual number associated with the secret data as found in your instance of Secret Server.  This number increases sequentially as secrets are added.

For instance, the secret of a test server I have installed is shared with this link:  http://192.168.0.2/SecretServer/SecretView.aspx?secretid=52

Note: Using this link requires Secret Server login permissions and permissions for that user to at least view the secret you’re trying to share.

The elegance of this method is that users can share credentials between them through email.  The use of the data and permission to use the data is still controlled by a Secret Server Administrator.  It’s worth mentioning is that all of this activity is logged and reportable within Secret Server.

Admins with the need for additional security can link to a secret that has a Launcher enabled and the password is hidden from users.  This way, an Engineer can directly link to a secret’s launcher with a coworker.  The coworker can use the credential to login via Remote Desktop (or any other launcher functionality) to a server without knowing the actual credentials.

Hide Launcher Password is a feature that allows the password field of a secret to remain hidden from view or clipboard access, but still usable by the launcher.  The activity is completely logged in Secret Server and nothing was written down, able to be copied, or shared with anyone but those that have express permissions in Secret Server.  Enable this security feature by clicking the Edit button for a secret, then Security tab -> Edit button -> check Hide Launcher Password -> Save button.

The use of links go beyond email.  Admins could also use these links in support documentation for applications or systems.  In the documentation, a link to Secret Server data can be embedded in place of the actual admin credentials.  This would negate the need for a document-based password protection scheme.





Unlimited Administrator Mode Suggestions from a Secret Server Admin

20 08 2012

While responding to a different but related forum question, a Secret Server Admin made a good point:  Split the ability to enable Unlimited Administrator Mode and the ability to use it.  This is outlined in the Secret Server Best Practices Guide.  Here is a quote from the forum post:

1.) I encourage this on all SS installs. Separate the roles of both Enabling Unlimited Admin mode and Unlimited Admin from a user. Configure SS to require that one (or more) people are the only ones that can enable Unlimited Admin mode but not be an Unlimited Admin. The opposite for the Unlimited Admin, they shouldnt be able to put SS in Unlimited Admin mode. This prevents a single person from having the ability to flip the god switch.
2.) Setup event subscriptions/notifications that email all users of SS when Unlimited Admin mode is enabled.
3.) Direct all users to the appropriate report(s) that show what an Unlimited Admin did while that mode is enabled.

Splitting these roles into two different users or groups of users adds an additional layer of accountability to Secret Server.  One Administrator will not have the ability to authorize a switch to Unlimited Administrator Mode and consequently gain access to all of the secret data stored in the database.

Do you have questions, comments, and concerns about Unlimited Administrator Mode?  Please post in our forums:  http://www.thycotic.com/products_secretserver_forums.html





Secret Server SMTP Authentication

7 08 2012

As a tie-in to our previous blog post Secret Server and Secure LDAP, SMTP Authentication was another important feature released in Secret Server version 7.8.000036. SMTP Authentication was implemented as a direct result of customer requests. Many of our clients work in environments that require secure messaging. In this release and beyond, Secret Server now has the ability to authenticate to an SMTP server, use SSL, and even specify a custom port.

Some background: Notifications sent via email from Secret Server can contain sensitive information (but never passwords, of course.) The most common risks include spam, false or fraudulent claims, personal threats, social engineering risks (phishing, imposters, etc.), or even virus & malware propagation. While this solution does not offer protection against compromised accounts, it does severely limit the risks associated with running SMTP servers. In response, many organizations require SMTP authentication and SSL connections to their internal servers (as well as other requirements beyond the scope of Secret Server.)

We recommend using SMTP Authentication and SSL if possible. Enable SMTP Authentication is a short and simple process. You can access these settings in Secret Server with the following clicks:

Administration -> Configuration -> Email (see below)

SMTP Authentication options in Secret Server

SMTP Authentication was another important feature released in Secret Server version 7.8.000036. Access it via: Administration -> Configuration -> Email

As with any blog post, Secret Server, or general Thycotic Software question, please comment below or find support information here:  http://www.thycotic.com/products_secretserver_support.html.





Secret Server and Secure LDAP

23 07 2012

In April 2012, we released Secret Server v7.8.000036.  This was the first release to include support for Secure LDAP often referred to as LDAPS (and not to be confused with SLAPD!)  Subsequent releases of Secret Server will support LDAPS.  Since the release of LDAPS, it has remained a bit of an unintentional secret (no pun intended).  If you have Secret Server installed, check to see if you can enable Secure LDAP in your environment.

Using LDAPS:

Upon installation, Secret Server will use port 389 for LDAP traffic to Domain Controllers.  This does NOT mean passwords are transmitted in clear text.  It means that user and group names will be translated in clear text.  Passwords will be transmitted using Kerberos/NTLM.  However, with LDAPS available, all traffic including the user and group names will be encrypted.

Before enabling LDAPS, there is one feature that can potentially be affected.  If you are using a Domain Controller on Windows Server 2008 R2, Integrated Windows Authentication is supported with Secure LDAP.  However, if you are using Windows Server 2008 or older, Integrated Windows Authentication will have to be disabled when Secure LDAP is used.

How to enable LDAPS:

  1. Click on Administration -> Active Directory -> Edit Domains -> Select the domain you wish to edit (you can also create a new one here.)
  2. Click on Advanced as highlighted in the figure below.
  3. Put a check in the Use LDAPS box.
  4. Click Save And Validate.

 

Secret Server will now attempt to use LDAPS over port 636!  As with all Secret Server updates, the release notes are always published here:  http://www.thycotic.com/Secretserver_releasenotes.html.








Follow

Get every new post delivered to your Inbox.

Join 30 other followers