You just purchased a new network device or server and realized that Secret Server doesn’t contain a specific password changer for it. You figure the best you can do is store the static credentials in Secret Server, but there’s no way Secret Server could actively manage password changing, right? Think again! Secret Server has a variety of ways you can customize password changers, no matter how complex your environment.

SSH

SSH password changers can change passwords for ANY of your SSH-compatible devices. Modify an existing SSH password changer or create your own. Enter the SSH commands in Secret Server, replacing actual credentials in the commands with values that reference the credentials stored in the Secret. The same will work for any device accessible for password changes over Telnet.

A few examples:

• Configure a Dell DRAC password changer:

http://support.thycotic.com/KB/a166/how-to-manage-drac-passwords-with-secret-server-using-ssh.aspx

• Use the built-in Cisco password changer (customizable):

http://support.thycotic.com/KB/a251/heartbeat-and-remote-password-changing-for-cisco-accounts.aspx

• Use the built-in Unix Root account password changer:

http://support.thycotic.com/KB/a369/heartbeat-remote-password-changing-unix-root-accounts.aspx

LDAP

Secret Server comes with several LDAP password changers configured for Active Directory, DSEE and OpenLDAP. You can either customize the existing password changers or use one as a template to create your own custom configurations, for example to change passwords for 389 Directory Server. Customizable settings include enabling SSL, method of authentication, and username authentication format. See the article below for details:

• Use and configure custom LDAP password changers:

http://support.thycotic.com/KB/a183/ldap-password-changing.aspx

Web Passwords

Secret Server’s web password management includes Remote Password Changing for Amazon Web Services, Google, and Windows Live accounts. Configure these options under the Remote Password Changing tab for any Secret using the Web User Account password changer.

Password Changing for Additional Account Types

Secret Server contains password changers for many other account types as well. While these are not all customizable, they include many commonly used account types such as Oracle, SQL Server, SonicWall NSA and more. A full list of included password changers can be accessed here.

See the Secret Server User Guide for more info on creating and testing custom password changers.

Did you create your own custom password changer? Share it with others on our forum.

Send us your ideas and suggestions any time. Post new feature requests and see what other customers have requested at feedback.thycotic.com.

THANK YOU to all of our customers. We hope you know how much we value you every day, and it’s thanks to you that we received a perfect score from Forrester for customer satisfaction. You have given us your feedback on products, stopped by our booth at trade shows to chat, and shared your IT security challenges with us. Without this feedback, we wouldn’t be where we are today.

Forrester Research also provides us with great insight to help us better understand the enterprise IT security landscape and, ultimately, learn how to satisfy our customers. The latest feedback from Forrester comes in the form of the new Forrester Privileged Identity Management Wave.

For the latest Wave, Forrester evaluated Secret Server 8.2, which was released July 2013 (version 8.4 is the latest at the time of publishing). We answered questions about Secret Server, provided demos and gave information for their scoring criteria. Thycotic enterprise clients spoke to Forrester analysts about their experiences with Thycotic Secret Server and Thycotic. Forrester also helps us spread the word about our great products, and we thank everyone who helped us with this Wave.

Forrester just released the official PIM Wave today Monday February 3rd 2014. To summarize – Thycotic customers are satisfied, and Thycotic continues to add more features and functionality to Secret Server in 2014.

For a more detailed review, please take a look at our Forrester Research PIM Wave Thycotic Analysis

Yep, you guessed it. We’re going to talk about big data. You’ve probably heard the buzz term a million times this year, but here’s an important question for any IT administrator and management team: What role does big data play in making your organization more secure?

Pairing security information and event management (SIEM) with strong privileged account management and password practices combines the best of both worlds for folks looking to strengthen their internal security posture. Just imagine, you could know when an employee started to view an unusual number of passwords because the SIEM tool immediately alerted your security team, preventing a potential insider threat.

The SIEM market includes several vendors that offer strong, enterprise-class tools for proper SIEM management, and that integrate out of the box with Secret Server.

On Thursday, February 6, join us and HP ArcSight as we take a deeper look into how Secret Server integrates with SIEM tool HP ArcSight and what that means for customers and their security plan. Join the webinar to see:

• A full demonstration of the integration.
• Common examples of how SIEM technology pairs with enterprise password management to enhance security.
• Live question and answer session with both Thycotic and HP ArcSight.

Event details

Integration Spotlight: HP ArcSight and Thycotic.

Thursday February 6, 11:30am EST.

Hosted by: Ben Yoder from Thycotic, and Eric Shou and Morgan DeRodeff from HP.

Interested in learning more? Register for the webinar now.

HIPAA, or the Health Insurance Portability and Accountability Act, is meant to protect specific health information gathered and used by the healthcare industry. Many people are familiar with how HIPAA affects their privacy as individuals, but not everyone may know how HIPAA shapes an organization’s security practices. A recent breach at St. Joseph Health Center exposed personal information of over 2,000 individuals and reinforces the concern for data security. With technology everywhere we look, the technical safeguards required by HIPAA are extremely important in ensuring that our information remains protected.

Let’s review exactly how Secret Server can assist your organization in achieving HIPAA compliance. From a privileged identity management standpoint, here’s what you need to know:

1.       Protect your information systems  This one is a given, but not everyone takes the time to do it! Make sure all of your servers (ALL of them – not only those that specifically handle personal health information) have strong, unique passwords that are rotated frequently. Don’t leave any easy targets for intruders to exploit. Require users to change their passwords often and enforce strong password requirements.

Secret Server provides the ability to manage server and systems accounts, not only by storing them in a central repository, but also by changing them on a regular, scheduled basis. Improve password strength by configuring password requirements for Secret Server’s random password generator.

Have too many servers on your network to keep track of? Secret Server can automatically discover the local Windows and service accounts on your network and pull them into Secret Server to be managed.

2.       Encrypt data in transit   Especially personal health information (PHI), but this applies to all information that secures the systems storing and transporting PHI as well. Use SSL/TLS to encrypt data being sent over the network.

Secret Server encrypts all sensitive information before it’s stored and as a web-based application supports the use of SSL/TLS encryption for access. What does this mean? Your passwords and any other private information such as credit card numbers, pin codes or even documents are encrypted and stored securely in one central repository.

3.       Record access to data   HIPAA requires measures to ensure data isn’t modified or deleted without authorization. Keep an accurate record of who has access to which systems or information and why.

Once your accounts are managed by Secret Server, it will be your central point for sharing and auditing access to privileged credentials. Secret Server keeps an audit of who views and edits credentials, showing you who had access, which system or data they needed access to, and when. You can even require comments to keep a more comprehensive audit trail of why a user accessed the data.

4.       Provide documentation   Have reports and audit logs available in case any information is requested for review. Secure access to documentation so you are able to track exactly who has the ability to review it.

Secret Server contains a number of built-in reports that will give you an overview of the status of your passwords, who has access to credentials and data, and more. Use a read-only user role to allow auditors to access reports and documentation without the ability to view or edit sensitive information.

Do you work in the healthcare IT industry? Share your experience meeting HIPAA requirements in the comments below.

2014 marks Thycotic’s 5^th year exhibiting at the RSA cybersecurity conference. RSA is one of the largest gatherings of IT security professionals and analysts in North America. This year, the conference takes place February 24-28^th 2014 at the Moscone Center.

Thycotic to unveil new Secret Server features

We’re excited to demonstrate not-yet-published Secret Server features before they’re officially released at booth 415 during RSA expo hours. Our team will also give demos of our other IT products and are available to answer any questions you have on our products or password management best practices. Product Manager Ben Yoder and CEO Jonathan Cogley will be there, as well as many more of our great team. Look for our 20X20 black and green booth, you can’t miss us!

What to expect from RSA

Informations sessions cover a variety of security hot topics: hackers and threats, governance, risk and compliance, cryptography, data privacy and more. IT security professionals come eager to discover the latest in security technology, debate fiery issues and mingle with the best in breed vendors and industry experts. Oh, and don’t forget the rocking vendor parties that pack the evenings; complete with food, drinks and entertainment of all kinds amidst the backdrop of a lively San Francisco nightlife.

Awesome keynote lineup

RSA 2014 boasts an impressive speaker lineup worth checking out, including Nawaf Bitar of Juniper Networks, Art Gilliland of HP, James Comey of the FBI and a special closing keynote appearance by Stephen Colbert guaranteed to bring some hilarity to the mix.

Thinking about attending? Register for RSA 2014 here.

See you there!

A typical day in IT:

It’s another day-in-the-life of an IT administrator and you have yet another 1,000 problems to solve. Around noon you receive a ticket saying Bob is having trouble with his computer’s performance. Instead of grabbing lunch, you RDP into his computer to figure out the problem. You need admin credentials to see what’s going on, so you use your Domain Administrator account.  Turns out Bob needs to update a driver. It was a simple fix and you disconnect from the user’s computer, happy to have a couple minutes left to grab a sandwich.

Later that day you see login alerts from your SIEM tool for several machines you don’t typically access. Alarmingly, they happened while you were picking up your sandwich. Your password is strong and well above the company’s password recommended length, including alphanumeric and symbols. How was it used?

Turns out, the person who “borrowed” your credentials didn’t have to figure out your password. Instead, they infected Bob’s less secure computer and waited for you to log in using your Domain Administrator credentials. When you used RDP to enter Bob’s machine they captured the clear text hash of your password. Congratulations, your hash was passed.

What is Pass-the-Hash?

A Pass-the-Hash attack is where an attacker captures and uses the plain text hash of a user’s password instead of their plain text password. It allows an attacker to impersonate another user, typically a privileged account. This type of attack can affect ANY network using Windows machines. For the attacker, the advantage getting a hash instead of the password is it can be done without a brute-force attack, which is not as effective and takes a lot more time.

How is the Hash acquired?

Hashes can be acquired through a variety of methods, two being the most common. The first is to retrieve the hash from a SAM dump for the local machine users. The second is to grab the dump of a user’s credentials stored by Windows in the LSASS.exe process, allowing the attacker to retrieve the hash of any account that connects to the machine for example; an RDP-connected domain accounts. This is how the attacker compromised the Domain Administrator’s credentials from Bob’s computer in the scenario above.

How can Secret Server mitigate the threat of Pass-the-Hash?

While Pass-the-Hash attacks have existed for the last 17 years, the threat is now bigger than ever, with tools to exploit this vulnerability continuously improving. Currently the best way to protect yourself from a Pass-the-Hash threat is to upgrade to Windows 8.1 and Server 2012 R2. The new Windows updates have built-in security measures, including making the LSASS.exe a protected process, adding new security identifiers, and changing RDP so it no longer stores the remote login’s credentials on the target machine.

It is typically not practical to upgrade every computer in an organization quickly, and a network would still be vulnerable during the upgrade process. However, there are other protective measures that can be taken by using Secret Server. For example, organizations can use Secret Server’s Check Out feature and configure it to automatically change the password after each RDP session’s Check Out is complete. This would render any hash that was captured during the session useless; when the password is changed, the hash also changes. Secret Server can also restrict which computers can use an account by restricting the launcher inputs. These measures mitigate the chance of a Pass-the-Hash attacks by greatly reducing the amount of time a hash is valid and decreasing the computers accessible for attack on privileged accounts.

Incorporating a new tool into your company’s overall security architecture can be a tricky and time-consuming process. Fortunately, Thycotic Secret Server has a several features that streamline the process of complying with your existing corporate requirements. In this post, we will take a look at a few ways Secret Server can work in conjunction with your existing security policy to improve policy compliance and your user experience.

Enforce Password Compliance with Group Policies

Secret Server’s group policy feature allows you to set polices for local and domain account passwords, such as minimum password age, password length and password complexity. Secret Server adheres to the group policy when changing local Windows or Active Directory passwords. For example, if a password change is attempted with a weak password, Secret Server will return an error message to explain the password complexity requirements. Or, if a password change fails because it was too weak, Secret Server can send an email alert to administrators.

To eliminate the possibility that users will set weak passwords or use prohibited characters, Secret Server can automatically generate passwords using the preset password requirements. The result: secure, randomly generated passwords that are guaranteed to meet your group policy requirements each time they’re changed, whether automatically by using Auto Change or manually by a Secret Server user.

Restrict Access with Restricted Launcher Inputs

Group policy can also be used to restrict remote access to servers, which is a great way to decrease the area of attack for an account. However, with a large number of accounts this can be difficult to keep track of. Secret Server provides the ability to restrict launcher inputs to allow users to only see and connect to machines that have been whitelisted for each account. This simplifies the process for end users, who no longer need to keep track of details of their privileged account access, and allows administers to configure more granular access control in a way that is clear and fully audited.

Simplified Web Password Management

Finally, a policy that we have talked about before is allowing a user’s browser to store credentials. Auto fill for browser credentials is certainly convenient, but it does not provide an audit of usage, making it a bit of a problem for the security department. Instead, organizations can disable the browser’s password auto fill option and add those credentials to Secret Server. Users can then use the Secret Server Web Filler to directly log in to websites. This makes your environment more secure by tracking who accessed each web credential and it ensures passwords are stored securely within Secret Server instead of a user’s individual browser.

Check back next week to hear our team’s recap of RSA 2014 San Francisco.

In a continuation of our discussion around the strengths of combining secure privileged account management with SIEM capabilities, we’re excited to announce our new alliance with Tenable Network Security!

Integrating Secret Server with Tenable’s log correlation engine, SecurityCenter Continuous View, will provide administrators with improved oversight of their organization’s security practices.

What is Tenable SecurityCenter Continuous View?

Tenable SecurityCenter Continuous View provides organizations with a uniquely integrated vulnerability and SIEM functionality, helping them move from periodic assessment to continuous and instant identification and response for security and compliance threats.

How does it integrate with Secret Server?

Secret Server works with Tenable SecurityCenter CV by sending event engine logs to the tool in the form of syslog. SecurityCenter CV now has built-in support for processing Secret Server events, such as Heartbeat success, Secret expiration and user login activity. For a more detailed description of supported events see Tenable’s forum page.

The benefits of integration:

Incorporating event logs from Secret Server into the rest of your collective SIEM data allows you to maintain more comprehensive records of user access to privileged credentials for every account you manage through Secret Server, from workstations and servers to network devices and many more. Ultimately, this means your administrators have access to faster and more reliable attack detection and mitigation.

For more information:

See our Syslog Integration Guide for details on configuring Secret Server to log events to your SIEM tool.

Secret Server 8.4, released in January, included additional ways to update Secret security settings via the web services API. This week, we’ll show you how to use PowerShell to access the Secret Server web services API and configure security settings for Secrets.

Web Service security settings: What’s available?

The web services API can help you configure Remote Password Changing and advanced security settings, including:

These settings correspond to those you will see in the browser interface on the Remote Password Changing and Security tabs of a Secret.

The sample script we’ll use today creates a new Secret and then updates it to use the Require Approval for Access security setting. Because this setting also requires Approvers, our PowerShell script includes parameters to set both a user and a group as approvers. For the entire script, see our KB article HERE.

Review: Authentication

First, provide your Secret Server URL in the script. You’ll be prompted for your Secret Server login credentials at runtime:

If you’re using a domain account, add a similar line for the domain. See Using Web Services with Windows Authentication (PowerShell) if you use Integrated Windows Authentication.

Generating Passwords

Utilize the password generator to create new, randomized passwords when you aren’t using an already-existing password:

Create the Secret

Create a Secret by providing the Template ID, new Secret name, field ID’s and value, and destination folder with the AddSecret method. Helper functions findFieldId, findTemplate and findFolderId take care of automating the process of determining ID’s, if you don’t already know these ID values.

Update Secret security settings

Once your new Secret has been created, modify its security settings using the result of AddSecret. In this case, we’ll utilize another method to obtain the object type necessary for adding groups and users, and create new records (one for a user, one for a group). Then we’ll add them to the Secret as approvers:

Finally, we’ll use the UpdateSecret method to apply our new security settings to the same Secret we created earlier.

Keep errors in check!

Don’t forget to use an error-checking function to assist with debugging and determine whether there are any errors to return for each web services call you make:

For an example of retrieving and updating Remote Password Changing settings for existing Secrets, see our previous blog post on the web services API.

For additional resources on using the web services API, see our Knowledge Base and Web Services API Guide. Troubleshooting your own script using Secret Server web services? Our technical support team is always available to help! Contact support HERE.

Secret Server 8.5 adds a slew of new features and functionality. These new features are pretty awesome, so we decided this release deserves a little extra showcasing. Check back each week through April to learn something new about 8.5 and how it will increase your team’s overall security and productivity. Today we are going to focus on taking control of launched sessions. Enjoy!

While every action to a Secret is audited, administrators of the Enterprise Plus edition have the option to add Session Recording for sensitive accounts or servers. For those of you who are not already familiar with this feature, Session Recording records a video of the session launched from Secret Server and stores it in the Secret audit.

Introducing Session Monitoring:

Those of you with security responsibilities get excited, because 8.5 brings you a whole new level of control. Session Monitoring is a new feature that gives Secret Server administrators the ability to see what sessions currently are open.

Administrators now have a real-time view of all the sessions launched from Secret Server, can watch the live feed of a session, and terminate sessions immediately or send a message directly to the user. Imagine seeing a list of active sessions directly from your dashboard, be able to stream the live video feed and end the session immediately, or send a note, like, “Hey Bob, I need the server. Can you finish up soon?”

Session Recording Enhancements:

With the 8.5 release, we added Microsoft Video Codec 9 to our list of available codecs (joining XVID, DIVX and Microsoft Video Codec 1). We also changed how the sessions are stored, to give you more storage space flexibility.

Why did we do this? Depending on how many sessions you record, how long each session lasts, and what video codec was used, video recordings can take up a lot of space within the Secret Server database!

What did we change to make this better? First, we now allow administrators to choose where session recordings are stored, whether in the database or a disk. Second, we now have a configurable expiration date for videos. Once a video is expired, Secret Server will automatically purge the old recording, freeing up your disk space.

Secret Server Session Recording Edit

Stay tuned next week…

Secret Server 8.5 is packed with features to improve functionality and your security options. Check back next week to learn more about 8.5. Want a sneak peek? We’ll be discussing performance enhancements to Discovery, Remote Password Changing and Heartbeat. Do you already have a favorite 8.5 feature? Let us know in the comments!

It’s no secret – managing IT passwords is a major hassle. Spreadsheets are a temporary bandage to a bigger security issue, and simple password vaults don’t scale to meet the real security needs of an IT team.

Security, team sharing and scalability are important points when picking your IT password management tool. With our limited-time offer of Secret Server Express edition with expanded users and Secrets (what we call credentials in the tool), we want to give you 5 reasons to seriously consider switching to the Express edition of our enterprise-class password management tool.

1.) You’re sick of using spreadsheets to manage IT passwords. Spreadsheets are the security bane of any IT team’s existence. With all of the shared credentials stored in a single encrypted spreadsheet, there’s no way to separate accounts out based on team member needs. Plus, once that spreadsheet is hacked you can say goodbye to your network. The eggs have been successfully swiped from the basket.

2.) People are still using “Password” for shared admin credentials. Weak passwords are often the culprit of compromised accounts. Generating strong, complicated passwords adds a layer of protection to managing privileged accounts.

3.) Half of your team writes passwords down on sticky notes. Do we even have to elaborate here? It’s the 21st century…c’mon people!

4.) Our Express edition costs a whopping $10. A year. Yup. We’re not kidding. And if you buy before Friday, April 25, 2014, you lock in expanded users and Secrets (100 users and 1,000 Secrets). Oh, and the yearly fee goes directly to support our community charity partner Reading is Fundamental, the nation’s largest non-profit child literacy organization.

5.) We scale as your security needs grow. Eventually you may need to meet compliance mandates and enforce more complex security practices around managing privileged accounts and identities. When you buy a simple tool, you’ll have to shop around for a more robust solution later on. Express edition scales into any of our enterprise-grade editions swiftly and easily, reducing time and effort in strengthening your security posture – from small business to the enterprise.

So, do you think it’s time to switch? Try Secret Server Express today and let us know what you think.

Express edition offer of 100 users and 1,000 Secrets is good through Friday, April 25, 2014. Purchases made by this date are guaranteed the higher user and Secret limits, even when you renew each year. Purchases after April 25, 2014 will receive the standard 10 users and 100 Secret limits.

Secret Server 8.5 adds a number of new features and functionality. These new features are pretty awesome, so we decided this release deserves a little extra showcasing. Check back each week through April to learn something new about 8.5 and how it will increase your team’s overall security and productivity. Today we are going to focus on speed and scalability. Enjoy!

An upgrade to .NET Framework 4.5.1 isn’t the only major change Secret Server 8.5 brings with it. Our latest version of Secret Server also includes scalability enhancements for Remote Password Changing, Heartbeat and Discovery. Simply put, a lot of processes just got a whole lot faster.

Multi-threading Magic

Remote Password Changing, Heartbeat and Discovery can now take advantage of multi-threading to improve performance and scalability. Secret Server will utilize 80% of your server’s processors, leaving a remaining 20% to maintain performance of Secret Server’s interface. What does this mean? Greater performance with overall speed scaling with the power of your Secret Server machine.

You can see the maximum degrees of parallelism of your primary server on Secret Server’s Diagnostics page.

Speedy Remote Password Changing & Heartbeat

With multi-threading, Secrets queued for Remote Password Changing can now have their password changes handled simultaneously. This gives you seriously increased speed! Additionally, Remote Password Changing uses intelligent batching to manage the queue of Secrets, ensuring that Secrets and privileged accounts are never changed in the same batch. The scalability improvements also apply to Secrets using Agent for Remote Password Changing.

Before the 8.5.000000 upgrade, password changes were executed one at a time:

After 8.5.000000 upgrade, multiple password changes are executed at once:

Lightning Discovery

Secret Server’s Discovery feature, in addition to using a multi-threaded approach for scanning your machines, takes an improved approach to service account scanning to reduce scan time by up to 20 seconds per computer. Combining these two enhancements to Discovery makes scanning hundreds or thousands of computers faster than ever before!

Are the speed enhancements to Remote Password Changing, Heartbeat and Discovery your favorite 8.5 feature so far? Don’t worry there is more to come! You’ll just have to check back next week for the next 8.5 feature showcase. Here’s a little hint, we’ll be talking membership. See you next week!

In our ever expanding ecosystem of technology integration alliances, Thycotic has added another leader in SIEM technology to our list of out-of-the-box integrations. Now, Secret Server event logs integrate with LogRhythm’s Security Intelligence Engine to improve network visibility for users.

LogRhythm’s Security Intelligence Platform is known for combining enterprise-class SIEM, log management, file integrity monitoring and machine analytics to provide broad and deep visibility across an organization’s entire IT environment. Using Syslog format, Secret Server can ship important syslog data into LogRhythm to compare events and ensure a more successful audit for your organization. By pairing Secret Server with LogRhythm, administrators can better monitor successful and failed user logins to privileged accounts, secret expirations and unsanctioned changes to administrator privileges.

Out of the box, Secret Server comes standard with 44 different events tracking more than 20 unique data fields, as well as the ability to create custom events based on your organization’s security policy.

A few examples of SIEM events that come standard with Secret Server.

Implementing an enterprise-class privileged account management tool such as Secret Server with a SIEM solution not only helps organizations reach password compliance and mitigate risk, but also removes the complexities associated with the management and monitoring of privileged account credentials across a network.

For more information on how to successfully integrate SIEM solutions with Secret Server, read our Value of SIEM blog post and integration guide here.

Secret Server 8.5 adds a number of new features and functionality. These new features are pretty awesome, so we decided this release deserves a little extra showcasing. Check back each week through April to learn something new about 8.5 and how it will increase your team’s overall security and productivity. Today’s post focuses on implementing better user access control with Group Ownership. Enjoy!

This week we’re spotlighting the Group Ownership feature. Remember when giving a user group administration privileges meant trusting them with access to membership for all groups in Secret Server? That practice is long gone. Now, administrators can delegate group membership privileges to other users for their specific groups only. The result? Less burden on Secret Server administrators to manage groups, and more control for teams over their own individual groups.

Underlying Concept

Ready for the details? Here’s how it works:

An administrator (or any user with the Administer Groups role permission), chooses a local group to edit. By default, the group is managed by “Group Administrators,” but administrators can now select one or more “Group Owners” to manage the group instead. Group Owners can be multiple individuals and/or other groups. Once a group has been switched to the “Group Owners” model, Group Administrators will no longer have inherent permissions to make any changes to that group. As soon as a user is designated a Group Owner, they’re automatically assigned the Group Owner role. The Group Owner role will allow them to access the Groups administration page, where they will see only the groups they’re an owner of and have the ability to add or remove group member and owners.

Control Folder/Secret Permissions using Group Membership

With the addition of Group Ownership, delegating Secret and Role permissions becomes a more streamlined process. After providing a group permissions to a specific folder and then assigning a Group Owner, the Group Owner will be able to manage membership of the group, which effectively controls permissions to that folder of Secrets.

Stay tuned next week for a look at the new SSH Proxy features! Hopefully you’ve had a chance to test drive the new 8.5 features in Secret Server, what do you think? Do you have a favorite 8.5 feature? Share your favorites in the comment section below.

Secret Server 8.5 adds a number of new features and functionality. These new features are pretty awesome, so we decided this release deserves a little extra showcasing. Check back each week through April to learn something new about 8.5 and how it will increase your team’s overall security and productivity. This week we take a look at using Secret Server as a proxy for your SSH Launchers. Enjoy!

Secret Server’s SSH Proxy feature, added with version 8.5, allows increased security of the servers you connect to through SSH. This feature forces any SSH connection made through a Secret Server Launcher to be proxied through your Secret Server web server.

Proxing through Secret Server gives you two major benefits: The ability to enter just one IP address (your Secret Server IP) as an approved SSH connection for your servers and the opportunity for keystroke logging once an SSH session is initiated. This means that instead of including a number of your users’ client machine IP ranges, you can now specify your single Secret Server IP. Once sessions are initiated, you will also get enhanced session monitoring abilities through keystroke logs.

Configuring proxying in Secret Server is simple:

Specify your bind IP address, public host information, and port. Then create a banner to be displayed to users whenever they make an SSH connection through Secret Server. You have the option to provide a host private key or generate a new one.

If you want, you can enable an Inactivity Timeout to control how long a proxied Launcher session can remain idle before the connection is automatically closed.

Improved Session Monitoring

Whether your SSH Launchers use proxying or not, Session Monitoring (covered in Part 1 of our Introducing Secret Server 8.5 series) is a feature that will help you keep track of (and optionally, terminate) your users’ launched sessions.

However, proxying your SSH connections through Secret Server provides the added capability to record and then save or search through text from the SSH session.

Launchers compatible with SSH Proxying

The SSH Proxying feature applies to not only the PuTTY Launcher, but any custom Launchers you create, such as SecureCRT. Just select Proxied SSH Process as the Launcher type when configuring the custom Launcher in Secret Server.

Don’t worry, our Secret Server 8.5 blog post series is not over yet! Next week we’ll be covering changes to PowerShell.

The recent OpenSSL vulnerability CVE-2014-0160, or “Heartbleed” is affecting millions of SSL-enabled web servers worldwide; estimates are somewhere between 60% and 80% of servers are affected by the deadly bug. It’s the perfect example of a worst-case scenario: Heartbleed gives attackers the ability to reveal your server’s private SSL key by recovering just enough SSL key material.

We’re fortunate to announce that Thycotic has remained completely unaffected by this vulnerability, as our solutions are built on a Microsoft stack that doesn’t use any form of SSL technology. Our customers and partners can rest assured. However, it’s important to let others know what they can do to avoid an attack during this time.

While many tech news and media sites are advising consumers to rapidly change all web passwords that may have been affected by the Heartbleed bug, there’s still a risk for IT administrators, web admins and developers managing servers affected by the vulnerability. Question is… how do you prevent an attack while vulnerable?

Keep servers safe during Heartbleed

Website administrators were advised to patch their OpenSSL libraries on their servers to address the problem. But Heartbleed goes deeper than just patching OpenSSL. OpenSSL includes a general purpose API that software developers can use as part of their software. This is where static linking comes into play.

Static linking. Developers may choose to statically link to OpenSSL. Static linking allows developers to include OpenSSL within their software and it becomes embedded at compile time. Since the OpenSSL library is embedded in the software, upgrading the OpenSSL package on the operating system alone won’t update the OpenSSL version that software programs may have linked to statically.

Update all software, not just SSL. It is highly advisable that all software that makes use of OpenSSL technology be updated. Software vendors that statically link to OpenSSL should release updates for their software immediately by using a patched version of OpenSSL.

Keep clear, steady communications with customers. Make sure that as you’re updating systems and sending patches you’re also communicating these actions with your customers regularly. Consumers are rapidly changing web passwords and scrambling to protect their most valuable, personal data. Clear communications to your customer base (whether consumer or business) will help everyone stay on the same page and mitigate the most risk by using best practices during this time.

Secret Server 8.5 adds a number of new features and functionality. These new features are pretty awesome, so we decided this release deserves a little extra showcasing. Each Thursday post since the 8.5 release highlighted a new Secret Server feature. Check out our previous posts to learn how 8.5 will increase your team’s overall security and productivity. This week we’re finishing up our series with the benefits of PowerShell 3.

Secret Server has an  increasing list of built-in password changers for a wide variety of platforms, including Active Directory, Windows/Unix/Mac, networking devices, databases, and any platform that can connect with an SSH/TELNET connection. Also, Secret Server can update many service/application account dependencies out-of-the-box.

However, there can be unique password changing dependencies, such as when actions have to be daisy-chained after a password change, like restarting a specific device or application. For those situations, PowerShell provides additional flexibility to save time and maintain security.

With the 8.5 release of Secret Server, and the upgrade to .NET 4.5, Secret Server now makes use of the full PowerShell 3 capabilities. The main benefit of this upgrade is eliminating PowerShell’s “Double-Hop” issue, where PowerShell did not allow users to log into one platform (in this case Secret Server) and then jump to another server with those credentials. Now, PowerShell scripts can authenticate Active Directory credentials over multiple connections. This allows you to run PowerShell with an Active Directory Secret to perform multiple tasks across the network. This will be useful for organizations that need to update custom dependencies after a password change, such as SharePoint and IIS metadata. Get full instruction on avoiding PowerShell Double-Hop here.

Want to learn more about using PowerShell with Secret Server? Check out instruction for using PowerShell with Secret Server.

We hope you’ve enjoyed the latest enhancements to Secret Server with our latest release. Of all the 8.5 features, which is your favorite? Let us know in the comment section below. If there is still a Secret Server feature you still wish to see, be sure to cast your vote here.

Part 1: Form your DR plan

Just like any tool that enhances your company’s security, the security of the tool itself is of ultimate importance. That means no backdoors and no way for Thycotic or anyone other than yourselves to decrypt your data. This is really important, but a disaster recovery plan is critical to ensure your organization’s data and hard work will be preserved in any scenario. Secret Server is designed with multiple DR options – below is a guide to the fundamental points of Secret Server disaster recovery. Don’t forget to review your disaster recovery plan regularly to make sure it meets your current needs.

The “absolute minimum” backup plan

At minimum, have a backup of your encryption.config file and database. This is the MOST IMPORTANT part!! We can’t emphasize this enough. If you lose your database, you lose your data, and if you lose your encryption.config file, you lose any ability to read that data.

For your security, we do not have copies to anyone’s encryption.config file.

Back up your encryption.config file by copying it from your Secret Server application directory. See Choose your backup option, below, for more information about taking a manual backup of your SQL database.

The comprehensive backup plan

Backing up your database and encryption.config file will allow you to restore Secret Server in an emergency, but will likely require the assistance of technical support if you don’t have the application files as well.

For a more comprehensive backup, back up the entire Secret Server application directory. This will preserve not only your encryption.config file but also the application files matching the Secret Server version of your database and files such as the web-appSettings.config that you may have customized with additional settings.

Choose your backup option

So how do I perform the backups, you might ask?

• Back up files through the Secret Server UI. Do this from Administration > Backups. Specify a file path to back up the files. From this page, you can either perform a backup right away or configure automatic backups. For further details, see the Backup/Disaster Recovery section of the User Guide.
• Back up files through Windows on the server(s) hosting Secret Server. This involves (1) taking a backup of the database through SQL Server Management Studio, and (2) sending the Secret Server application directory to a .zip file. See How to manually backup Secret Server for instructions.

Choose your backup paths wisely. Remember that you’ll need the files in the event that your primary servers go down, so backing them up to the same local server won’t do you any good.

Whether you choose to manage backups through Secret Server, manually, or with another tool in your environment, make sure they’re done regularly, and as a standard process before major changes are made to the server, such as migrating or upgrading Secret Server.

Know the important  accounts

Know which accounts are running your application pool and connecting Secret Server to the SQL Server database.In the event that you need to set up Secret Server on a backup server, you will need to know which account(s) to use to run the application pool and connect Secret Server to the SQL database. These accounts are configured during installation. For more information about the accounts (including how to determine the identity running your application pool), see the Installation Guide.

Know your local admin account password

Can’t log in with domain credentials? When troubleshooting login issues for domain accounts, you’ll need to have the ability to log in with a local account that has administrative rights. (Remember that local admin account you created when first installing Secret Server?) Knowing these credentials will allow you to log into Secret Server when your domain authentication isn’t working and access Active Directory sync issues. Keep a reminder of this account in a safe place, such as a safe; if Secret Server is down, you won’t be able to log in to find it. One suggestion: store a cleartext export of your most important Secrets as a printed copy in a safe or other physically secure location. See the User Guide for more information about cleartext exports.

Make use of our support number

If you are preparing for disaster recovery or find yourself in an actual DR situation, our technical support team is available to help! Give us a call and we’ll help you get things sorted out.

Contact Support

Keep an eye out for Part 2 of our disaster recovery review, where we’ll cover how to use your backups to restore Secret Server in a DR scenario.

What is the biggest threat to your sensitive information? The security breaches at Shionogi Pharmaceuticals, South Carolina Department of Revenue and the United Way weren’t caused by external threats – they were initiated by an insider; a seemingly trustworthy employee or ex-employee of the company that had privileged account credentials allowing access to the organization’s most sensitive information.

Is your organization protected from insider threats? Join Martin Kuppinger of KuppingerCole and our very own Jonathan Cogley and Ben Yoder next Tuesday as they discuss best practices for thwarting insider threat and mitigating risks to prevent your organization from becoming the next target.

Learn more and register for the webinar HERE.

Part 1: Protocol Selection

Here at Thycotic we have a wide range of recommended security best practices for our customers, and one of the first things we recommend is setting up SSL, or Secure Socket Layer, for Secret Server.

Setting up SSL is fairly trivial once an SSL certificate is obtained. Once it’s set up, SSL provides a few different security layers. The first security layer is that web traffic is encrypted between the client (such as a browser) and the server. This prevents eavesdroppers from seeing data communicated between the client and server. The second is providing confidence that the client is communicating with the server it believes it is communicating with, which mitigates Man in the Middle attacks .

There is a lot that can be done to enhance the protection provided by SSL, and the first step is understanding the SSL protocol versions and features.

SSL and the Version Negotiation

SSL is commonly used interchangeably for SSL and TLS, or Transport Layer Security. TLS is SSL’s successor. There are different versions of TLS and SSL, and each version supports different features.

When a client establishes a connection with a server, the first step is a negotiation, where the client and server have to agree on what protocol version to use. The negotiation between client and server usually starts with the most secure option and progresses to least secure. Both the client and server have the right to refuse a protocol version, and they go down the list until an agreement can be made.

A key reason for this negotiation is it provides the ability to remove old and untrustworthy versions of SSL or TLS. If a vulnerability were ever to be discovered in one of the versions, servers and clients can be updated to refuse communication through that version. Likewise, new protocols can be added to a client’s or server’s list of supported options. Because a server could support a newer protocol version than the client browser supports, the version negotiation is needed to settle on a version that is supported by both sides.

Disable Unsecure Versions: SSL 2.0

SSL 2.0 is widely considered broken, and unsafe for secure communication regardless of the strength of the digital certificate. Most clients will refuse to use SSL 2.0 for this very reason. Just in case, it’s a good idea to disable SSL 2.0 from the server-side where Secret Server is installed to proactively stop clients from using an old version of SSL.

SSL 3.0 is still considered safe for use and is supported by almost every major browser – even Internet Explorer 6 supports version 3.0. Therefore, there is little reason to have SSL 2.0 enabled and turning it off should not be a problem.

Fortunately, Windows Server 2012 and 2012 R2 already disable SSL 2.0, so there is no action to take there, but if you use other versions of Windows Server, such as 2008 and 2008 R2, you will have to disable SSL 2.0 manually.

Disabling SSL 2.0 is easy enough for those older platforms. Microsoft has a support article available on their site under KB 187498 that walks through the process and provides a tool to automate the change.

Enable Secure Versions: TLS 1.1 and 1.2

As we mentioned above, TLS offers better security than SSL, with TLS 1.2 offering the best. TLS 1.2 offers support for authenticated ciphers, such as AES-GCM, and an improved pseudorandom function to rely on SHA256.

Windows Server 2012 and 2012 R2 offer both of these protocols by default, so there is nothing that needs to be done to enable them.

Windows Server 2008 R2 supports these protocols, but they must be turned on manually. Microsoft’s KB 235030 explains a more detailed way to enable these protocols. The steps are this:

1. Create a registry key
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.1
2. Under the new TLS 1.1 key, create a Client subkey and Server subkey.
3. Create a 32-bit DWORD in both the Client and Server subkey called “Enabled” and set its value to 1.
4. Create a 32-bit DWORD in both the Client and Server subkey called “DisabledByDefault” and set its value to 0.
5. Repeat this process for TLS 1.2 by substituting “TLS 1.1” with “TLS 1.2” in the first step.
6. Reboot the server.

Unfortunately, for Windows Server 2008 and older, TLS 1.1 and 1.2 are not available at all. In this case, we recommend upgrading the operating system. Another option is to use a reverse proxy that does support TLS 1.1 and 1.2, either hardware or software, to offload the SSL responsibility from the server to the reverse proxy.

Consider Disabling SSL 3.0

SSL 3.0 is, for the most part, considered secure enough for use in production. However, it is on its way out due to a reliance on the weak MD5 hashing algorithm, among other factors. TLS 1.0 is the next step beyond SSL 3.0. All modern browsers support at least TLS 1.0, except, notably, Internet Explorer 6 on Windows XP, which does not support TLS at all.

Perform an audit to determine if SSL 3.0 is needed for a server where Secret Server resides. If SSL 3.0 isn’t needed, disable it on the server-side in the same fashion that SSL 2.0 is disabled.

Wrap up

Our takeaways are:

1. There is no practical reason for SSL 2.0 to be enabled anymore. Disabling it ensures unsecure clients don’t attempt to use it.
2. SSL 3.0, while still considered acceptable, should at least be examined to determine if it is necessary, and removed if unnecessary.
3. Enabling TLS 1.1 and 1.2 offers more robust security than SSL.
4. Windows Server 2012 and 2012 R2 already come configured with SSL 2.0 disabled and TLS 1.1 and 1.2 enabled out of the box.

What’s next?

A key component to SSL is the cryptographic algorithms underneath the covers. These algorithms make up the cipher suite. The cipher suites accepted during the negotiation step above have a big impact on security. This can be improved by disabling weaker cipher suites and setting up preference for the more secure suites. Check back next week for more details!