Skip navigation
All Places > Products > RSA SecurID Access > Blog > 2017 > August

If you’re looking for the latest news, trends and innovations in identity, you’ll find it all at RSA Charge 2017 October 17-19 in Dallas. I hope you will join me this year along with the RSA identity team for three action-packed days of content and connections, with hands-on labs, RSA product previews, plenty of networking opportunities and more. It’s all part of RSA’s can’t-miss annual user conference, Charge, the premier event on RSA® Business-Driven Security™ solutions, where an elite community of customers, partners and industry experts dedicated to tackling the most pressing issues across cybersecurity and business risk management unite.


Top 3 Reasons to Attend

By joining us for RSA Charge 2017, you’ll be able to:

  • Learn how you can reimagine your identity strategy with identity and access assurance, next-gen authentication solutions (including mobile push authentication, biometrics, FIDO tokens, smart phone authentication methods and more), and the latest in identity governance and lifecycle management technology
  • Go hands-on in labs learning recommended practices for RSA® Identity Governance and Lifecycle and preview the latest RSA SecurID® Access product features
  • Gain insights from your peers at top companies sharing how they solved real-life identity challenges and what they learned in the process

The Future of Identity Starts Here

RSA Charge 2017 is your opportunity to gather with RSA’s identity experts and executives to hear about RSA’s vision and strategy around identity. Keynotes by cybersecurity visionary and TED speaker Marc Goodman, RSA President Rohit Guy, and other RSA execs set the tone each day, followed by morning-to-night sessions exploring the shift from identity management to identity assurance, the move to multi-factor authentication and the evolution of identity-related risks and risk management. You’ll also hear first-hand from customers sharing stories of how they’re reinventing their identity strategies to address emerging challenges in authentication and identity governance.

Getting Down to Brass Tacks

Come to share your input into the overall identity customer experience, and leave with plenty of practical knowledge for improving your identity practice. We’ll guide you through detailed roadmaps of RSA Identity Governance & Lifecycle and RSA SecurID Access, and give you a sneak peek at the latest releases. We’ll also share some practical tips for specific identity projects like upgrades and quick starts. And we’ll show you how RSA Identity Governance & Lifecycle integrates with RSA Archer, RSA Authentication Manager and other key business applications to give you new ways to manage identity risk and to help you lower your risk of an audit failure (or worse, a data breach) while improving your overall compliance efforts, including those for GDPR.

Register Today for Special Pricing on Your Attendee Pass

Don’t miss your chance for an up-close look at what’s happening in identity today from RSA experts and customers, and other security industry leaders, at RSA Charge 2017. Register by September 15 for serious discount pricing. I look forward to seeing you there!

About RSA Charge 2017

RSA Charge 2017, the premier event on RSA® Business-Driven Security™ solutions, unites an elite community of customers, partners and industry experts dedicated to tackling the most pressing issues across cybersecurity and business risk management. Through a powerful combination of keynote speeches, break-out sessions and hands-on demos, you’ll discover how to implement a Business-Driven Security strategy to help your organization thrive in an increasingly uncertain, high-risk world. Join us October 17 – 19 at the Hilton Anatole in Dallas, Texas. Register now!

This RSA SecurID Suite Navigator Tool is part of an ongoing campaign by the RSA SecurID Customer Enablement group to make it easier for RSA SecurID Suite customers like you to find relevant product training and documentation. The RSA SecurID Suite Navigator Tool allows you to filter content based on your role within your organization: Administrator, System Administrator, and Business User. You can also filter content by your knowledge level of the RSA SecurID Suite, from Basic to Intermediate to Advanced.


The RSA SecurID Suite Navigator includes content from the entire RSA SecurId Suite: RSA Authentication Manager, RSA Identity Governance and Lifecycle, and RSA SecurID Access. This navigator tool pulls content from different RSA business units and includes RSA University training content, Knowledge-based articles, as well as a vast collection of user documentation. The RSA SecurID Suite Navigator will be updated frequently to ensure you are receiving the most up-to-date content available. There is a dedicated team of RSA professionals across different business units to help you take charge and power your way to success with the RSA SecurID Suite.


In our continued efforts to provide the best content available, we rely on your feedback. If you cannot find what you are looking for in the Navigator, please complete the form we have provided on the main Navigator page.


You can find the SecurID Suite Navigator Tool on the main RSA SecurID product page or by navigating to the following URL:

We work with many customers who struggle to figure out the best way to provision credentials. Credentials are the “keys to the kingdom” and it is critical that customers find an adequately secure provisioning process. When provisioning credentials, extreme vigilance must be maintained. None of us want to consider some unauthorized party getting access to the resources the credentials are intended to protect.


Provisioning Challenges

There are a number of challenges to securely provisioning tokens.

  • How can I communicate with the end user in a secure manner?
  • How can I vet the identity of the recipient?
  • How can I be sure that only the intended recipient was able to access the credentials?
  • How can I provision what may be a large number of credentials efficiently?

This comes down to a common thread throughout all security-related procedures: finding the right balance between convenience and security.


When credential provisioning is involved, it is also important to consider the frequency. Provisioning is not something that should occur on a regular basis, so I find that most customers lean more toward security than convenience. Focus on convenience for the day-to-day authentication mechanisms, not the provisioning process.


I used to work for a company that had what I considered to be a very secure password (or password reset) provisioning process. If you forgot your password and called the help desk, they asked you your location and then directed you to walk to the nearest guard station. At the guard station, the help desk called the guard and asked them to check your photo identification badge to verify your identity. After the guard had verified your identity, they handed you the phone and the IT help desk provided a temporary password that had to be changed at your next logon.


This was clearly a very secure process involving a “trusted third party” (i.e. the guard) and a previously issued credential (the user’s security badge), but it was not what I would consider to be very convenient. Passwords could not be reset if you were off-site, and outside of normal working hours you might have a long walk to the nearest manned guard station. On the other hand, forgetting your password or needing a new password was something that should not occur on a regular basis.


Securely provisioning credentials requires customers to avail themselves of every protection available. This follows another core security tenant: leverage defense-in-depth wherever possible. Unlike a physical credential (i.e. a key), electronic credentials offer the administrator a number of additional defenses. Electronic credentials can be enabled only once we have verified they’ve been received by the intended recipient. Some credentials may also involve a personal identification number (PIN) as an additional defense. If possible, administrators should provide a temporary PIN (changed at first use) along with the credential. Others may have a password that can be used as an additional level of protection for the credential while in transit. All of these mechanisms improve the security of the credential while in transit.


Case in point: RSA SecurID Software Tokens and Compressed Token Format

RSA SecurID software tokens can be provisioned using a Compressed Token Format (CTF) code. This is a credential provisioning format that contains the token initialization values (i.e., seed, serial number, start date) in a convenient code that can be emailed to the end user and is easily imported into a device. These values are typically encrypted with a password and another value called the binding ID. While extremely convenient, care must be taken to leverage all available CTF protection mechanisms depending on the potential exposure of the data during the provisioning process.


The binding ID is a value generated during the installation of the software token and is provided to the administrator by the end user. The software token attempts to make this as convenient as possible by providing a link that generates an email containing the binding ID. The administrator uses this value to generate a CTF code that, in conjunction with a password, can be used to initialize a software token. Note that this creates a “two-factor authentication” mechanism for the CTF (which we all know is better than a single factor).


Software tokens may also be provisioned through mechanisms that greatly limit the exposure of the CTF value. For example, the CTF can be provided to the software token as a graphical “QR Code” displayed from a secure self-service web portal. Since accessing this portal would have already required the end user to have performed some form of authentication, adding an additional password may be unnecessary and inconvenient. On the other hand, if the administrator was sending the CTF code via unencrypted email, an additional password (provided to the end user through some other, secure mechanism) would be critical to the security of the provisioning process.


Since the binding ID also contributes to security, it would also be important to have procedures that keep this value and the CTF code separate. An administrator that received a binding ID via email should use care to not simply reply to the same email (as this leaves the binding ID in the email response). During this sensitive process, we want to make it as inconvenient as possible for any bad actors that may be attempting to steal credentials. Replying to a “Binding ID” email with a CTF code would create a neat package of data that, if obtained by a malicious party, would provide them with many pieces of the puzzle. Intercepting just a CTF code without the corresponding binding ID would leave the bad actor looking for this and other data. Optimally, the binding ID would have been provided to the administrator through some other channel, such as a phone call.


This begs the question: “How does the binding ID contribute to the security of the solution?” While it is a factor that is used to protect the CTF code, the binding ID also helps the administrator prevent a legitimate user from installing the software token on more than one device (which poses a separate security risk). If we assume the bad guy has somehow gained access to the user’s binding ID, it provides little protection from someone, using a rooted or jail-broken device who attempts to use an ill-gotten CTF code to clone the token. In this scenario, the CTF password is critical and would help prevent the bad actor from creating a copy of the token. Thank goodness for defense-in-depth! Since the administrator was very security-conscious, the token was also left disabled until the administrator could confirm it was received by the recipient, and a temporary PIN was set (which was separately provided to the end user through a secure channel). These additional steps add significantly to the security of the provisioning process. Even if a bad actor was able to obtain and use the CTF code, they would not know the temporary PIN associated with the credential and the intrusion would be quickly discovered.


Threat Modeling for Provisioning

Security administrators should be creating and maintaining an internal threat model specific to their credential provisioning practices and procedures. I like to start by focusing on the most valuable assets and look at how those might be compromised. The other critical activity is to identify a number of threat model assumptions. These are very helpful to simplify and create a “boundary” for the model. The goal of threat modeling will be to develop a level of confidence that the procedures in place will be sufficient to stop a simple and undetectable attack. This exercise will also identify points at which provisioning data may leave your control, which could lead you to consider additional layers of security that could be added to further complicate and prevent unauthorized access. In the CTF example above, data being sent by unencrypted email was a clear point at which some control of the provisioning information was lost.


In general, this process leads to a long sequence of “what if?” questions, which in turn lead to security mechanisms that are rooted in the model’s assumptions. Some examples:

  • How do end users prove their identities to the administrator?
  • Who is authorized to provision credentials and how is that process controlled?
  • How will the credential be transmitted to the end user and what protects it during this process?
  • If this is a software-based authenticator:
    • How to I control devices (i.e. phone, laptop, tablet) the end user can use as an authenticator?
    • How can I be sure the end user has the correct software?
  • If a credential is compromised during the provisioning process, what could the adversary do with the credential and what could they access?

And perhaps one of the most important questions: are the assumptions on which I am basing my threat model correct?


Once the model is complete, it should help you make any necessary changes to the provisioning process to close any identified security gaps. Every threat model should result in a plan-of-action with changes to enhance your security posture.

Keys to the Kingdom

Bottom line, when provisioning credentials, you are intending to provide the keys to your kingdom (or a small part of it) to a trusted associate. Make sure that they are the only person who can actually get those keys by following these steps:

  • Develop a credential provisioning threat model while carefully examining your security assumptions. This model should form the basis of your credential provisioning procedures.
  • Consider additional steps to add “defense-in-depth” to the provisioning process. I recommend that our customers make use of every available protection, especially in the sensitive credential provision process.
  • Review and audit the actual procedures for adherence to the security plan. Security procedures are only effective if they are being followed.
  • As the security landscape is constantly changing, revise and update the threat model and procedures on a regular basis.

Following these steps should help you find a credential provisioning process that is reasonably convenient but maintains adequate security for your enterprise.




For more information, please take a look at the RSA Authentication Manager Software Tokens Best Practices Guide (DOC-35128).

The case for multi-factor authentication (MFA) is clear. The harder you make it for cyber attackers to get to your data, the lower your risk of a breach—and MFA definitely makes it harder, by requiring people who request access to authenticate their identity in more than one way. The downside is that if you don’t choose wisely, MFA can also make things harder for people within your organization to deploy it, use it and manage it. And given that most of us tend to take the path of least resistance, you want to be sure to seek out a solution that makes MFA easy for everyone except attackers. Read the full article on RSA's Speaking of Security blog to learn more...

Filter Blog

By date: By tag: