Planning Resource Protection with Access Policies

[#1]

As a well-informed security professional, you’ve recognized the need for continuous combat against the increasingly perilous threat landscape, populated by increasingly skilled and persistent intruders.

As a security professional, you’ve recognized the need for continuous combat against the increasingly perilous threat landscape, populated by increasingly skilled and persistent intruders.

Many password alternatives are available to help deter infiltration. However, this abundance of options then creates the challenge of choosing among them when creating access policies for your sensitive digital resources. How do you begin to choose an appropriate set of authentication factors and policies to fit all your target resources, across all your user populations?

Let’s walk through RSA Security’s recommended approach to the challenge.

• Step 1: Set Business Goals

• Step 2: Determine Scope

• Step 3: Know Your Users

• Step 4: Select Resources to Protect

• Step 5: Select Authentication Methods

• Step 6: Define Access Policies

​Step 1: Set Business Goals

Develop a set of business goals and priorities to help guide you as you make tradeoffs between cost, convenience, protection strength and implementation complexity across various authentication methods and polices. Consider these questions:

• Do you need the strongest possible security, to guard against any infiltration? Or can you correlate authentication strength to business risk?

• How important is user convenience? How many choices should your users have when authenticating?

• What are your resource constraints for managing policies and authentication methods?

• Do you want to show quick success by starting with “low hanging fruit” targets? Or start with protecting the most sensitive digital assets, even if they are more complex to implement?

​Step 2: Determine Scope

While you need to have a comprehensive implementation scope in mind, to best ensure initial success, don't try to do too much at once.

Start with a limited, small set of targets, or a specific location or department and learn from the implementation before expanding. For example, you might select a perimeter or SaaS/cloud application, a high exposure area having the greatest likelihood of breach. Then focus on privileged access to sensitive applications as a next step. As you expand, consider the sensitivity of the target, the vulnerability to compromise and the scope of user access privileges to the targets.

​Step 3: Know Your Users

Consider your users' technical sophistication and access patterns. For example:

• Are your users internal or external to your organization?

• How technically sophisticated are they? It might be reasonable to require IT employees to navigate a strong MFA process, but not reasonable for non-technical users.

• Will your users to always have a mobile device for authentication? Will they always carry a hardware security token? If a user cannot authenticate using the preferred approach, what might be a “good enough” temporary backup method?

• Where are users typically located? Office? Remote? What works in the office might not work on-the-go.

• How often do users need to access your applications? Frequent authentication can seem like a barrier to getting work done, even if your users appreciate the need for security.

Consider the user experience when you devise access policies. One size does not fit all. Users who find it difficult to authenticate might find ways to circumvent your security protections.

​Step 4: Select Resources to Protect

Users tend to expect that low-risk applications support an easy, convenient authentication approach. However, sensitive mission-critical business applications usually warrant strong authentication policies.

1. List the resources you want to protect: network entry points, system logins, applications, databases, and so on.

2. Determine the sensitivity of these resources and assess the negative business impact if they were misused.

3. Next, divide resources into three access groups: low, medium and high sensitivity. Assess the business impact of rogue access to the application and data, considering factors such as:

   • Reputational damage – can access to an application damage the company’s reputation if leaked?

   • Financial damage – what would be the business impact of compromised customer base information, sales data, intellectual property, or any data that would have financial impact?

   • Compliance – what are the compliance penalties for leaked customer or employee records (HR system, CRM, and so on).

   • Operational damage – If an unauthorized user can access the AWS admin account, or the HR manager’s user account in the HR system, the rogue access to application capabilities can be devastating to the organization.

Ensure that your most sensitive digital assets are protected by the strongest authentication its users can tolerate. But for less sensitive resources, simple and convenient single sign on from the corporate intranet is likely sufficient.

​Step 5: Select Authentication Methods

RSA SecurID Access offers a broad array of authentication methods that can be applied to your list of resources. Each has advantages and disadvantages and provides varying levels of security protection. Some of those tradeoffs, as they apply to RSA SecurID Access, are listed in the table. For detailed information on each method, see Authentication Methods for Cloud Authentication Service Users.

Method	Advantages	Considerations	Comments
SMS Tokencode	Measure of strength when combined with password. Easy to use and relatively convenient (for example, consumer finance).	Requires access to preregistered mobile phone. Signaling system hacks have been demonstrated. NIST guidelines caution careful use.	Better than passwords alone.
Voice Tokencode	Voice-delivered one-time-password to an out-of-band phone. Useful where only landline is available (for example, in a lab).	Requires preregistered mobile or landline number. Risk is similar to SMS.	Tokencode is entered online, similar to SMS Tokencode.
Email One-Time Password (On-Demand Authentication in Authentication Manager)	Stronger than password alone, no phone required. Tokencode is delivered by email.	Requires online connection and preregistered email address. Email can be compromised or delayed. For agent-protected resources only.	Not widely used due to security concerns. Used for B2C when other notification methods not possible.
Mobile tokencode (RSA SecurID Authenticate app)	Stronger than any of the above methods, especially when used with PIN. Versatile – wide variety of B2E access uses.	Requires a smart phone and RSA SecurID Authenticate app installed. Cannot be used when device is lost or stolen.	Similar user experience as SMS, except uses stronger preregistered mobile app. Strengthened by PIN use.
RSA SecurID hardware token	Strongest security, especially with PIN. Can be used offline (no network).	Requires user to always carry the hardware token. Complex to administer. Cannot be used when device is lost or stolen. Has specific hardware cost.	RSA SecurID is considered “Gold Standard.”
RSA SecurID Software Token	Strong, two-factor authentication. Token resides on user's mobile phone.	Requires a smart phone and RSA SecurID Software Token app installed. Cannot be used when device is lost or stolen.
FIDO (U2F)	Strong, encrypted. Vendor neutral. Can be used offline.	Requires user to always carry the hardware token. Has specific, but relatively low, hardware cost.	Evolving standards, recognized by National Institute for Standards and Technology (NIST). Tokens are readily purchasable online.
Approve (mobile push notification)	Easy to use. Used for some B2C financial apps, B2E general employee use.	Requires preregistered smart phone and specific application installed.	Can also Approve from connected wearable (AppleWatch)
Device Biometrics	Relatively easy to use. Generally strong. Prevalent for mobile authentication, some government.	Requires mobile device with biometric authentication.	Maturing quickly. Laptop support available.
Identity Confidence (contextual risk-based analytics)	Reduces the need for other methods. Usually combined with any of the above, to simplify authentication and improve user convenience while still providing risk-based authentication security.	You must evaluate how strong the assessment will be, and map to your needs.	Uses machine learning algorithms, combining several contextual factors, to assess user risk based on anomaly detection. Gives confidence score. While not strictly an authentication method in the traditional sense (it can be considered more as a policy setting), it can be used with, or instead of, other factors to strengthen the verification process, so is included in this list, as well as discussed separately later.

To get you started, RSA SecurID Access prepopulates a few authentication methods in categories of Low, Medium and High assurance levels as described in Assurance Levels. Each level indicates the relative strength and security of the authentication methods within that level. You can change and add methods to match your needs.

​Step 6: Define Access Policies

After you have collected your user population information, your list of resources to be protected, and set of selected authentication methods, you can create access policies and apply them to your target resources.

Access policies usually comprise the following pieces:

• What (which resource or application)

• Who (user population characteristics including directory group membership)

• Context (circumstances of the access attempt)

• How (which factor(s) to require). So access policy creation is the coalescence of all the previous analysis steps.

For details on how access policies work and how to add them, see  Access Policies and Add, Clone, or Delete an Access Policy.

Once created, apply your policies to your target resources. The sensitivity of the resource to be protected should be matched to the strength of the authentication method.

Access Policy Planning Considerations

When devising a policy for an application’s multiple user populations, you need to consider privilege level. Employees with read-only access to the corporate organization chart do not need as strong a policy as the database administrator who can change, delete or export sensitive employee personal information.

Also consider whether you want a policy to allow “fail open” or “fail closed” access. If the user authentication context does not match any available policy, or meets some criteria but not others, “when in doubt”, do you want to risk letting the user in (“open”) because the impact of blocking legitimate access is high (for example, an administrator needs urgent access to fix a failed application or a potential customer could turn away) or be cautious (“closed”) and reject the authentication attempt, because the target resource is too sensitive to risk compromise?

For example, a policy that applies to the group HRManagers who use the Workday application might be:

Condition	Result
If a user's access location is in the United States	Additional authentication is not required.
Else, if a user is not in the United States or location cannot be determined	Require High assurance level methods (where High assurance level might require a device biometric authentication).

You need to assign a policy to each application, so you might require Low Assurance for a travel application, but High Assurance for access to the Cloud Administration Console by its privileged users.

Try to create the minimum number of policies you need to enforce the desired level of access security. Proliferation of too many detailed policies raises the risk of conflicting policies which could lead to user lockout.

​Preconfigured Access Policies

RSA SecurID Access provides preconfigured access policies that you can use immediately without performing any configuration. You can clone these policies and edit the cloned versions to customize as needed. For more information, see Preconfigured Access Policies

Note:  Depending on when your account was created in the Cloud Administration Console, you may or may not see these preconfigured policies in the Cloud Administration Console.

​Enrich Access Policies with Context Intelligence

You can help balance user convenience with security strength by applying intelligence to access context factors. Dynamically assessing the circumstances of the access attempt with access analytics can help achieve this balance.

RSA SecurID Access can collect information about a user’s access context and calculate an Identity Confidence level based on those circumstances. It evaluates the individual user, total population, and known risky authentication patterns to determine the Identity Confidence score.

That confidence score can be used as input to the access policy to dynamically determine the strength of authentication required. For example, if CFO Joe Smith is logging in with his recognized laptop at headquarters location, single factor password authentication may be sufficient to allow him to access the Accounts Payable application. However, if a user is attempting to sign in as John Jones, the IT database administrator for financial applications, and is trying to backup the Accounts Payable database using an unrecognized tablet that is located in Russia, far from John’s usual Cleveland location, then additional authentication for identity verification is more strongly warranted.

Risk assessment is based on different attribute sets, depending on license type. Using risk-based Identity Confidence, the number of additional authentications is reduced – enforced only when risk posture dictates it’s warranted. In this sense, it’s almost like having another authentication factor at your disposal to verify access attempts, which is why it was included at the end of the Authentication Methods table previously. This makes it easier for users to authenticate to your applications/resources.

For more information about Identity Confidence and other condition attributes, see Condition Attributes for Access Policies.

Previous Topic:User Session and Single Sign-On

Next Topic:Access Policies

You are here

Table of Contents > Access Policies > Planning Access Policies > Planning Resource Protection with Multifactor Authentication