E The Discovery Process

This appendix shows the modeling process in which high-level requirements are translated into security policies.

It contains the following sections:

E.1 Discovery Process Overview

The high-level steps involved in security policy development are as follows:

  1. Determine what you are trying to accomplish (problem statement).

  2. Break the problem statement into:

    • Inputs: What data is available to evaluate?

    • Rules: What types of evaluations do I need to perform on the data?

    • Outcomes: What should happen based on the analysis?

  3. Translate the wording of the problem statement into a security policy by mapping the data, evaluations, and outcomes to an OAAM configuration.

  4. Configure entities, transactions, patterns, groups, policies, rules, actions and alerts based on the above preparation.

E.2 Example Scenario: Transaction Security

In this scenario, a Security Administrator must configure OAAM to notify the security team if there are more than 4 orders to a shipping address in a 24 hour period.

E.2.1 Problem Statement

Notify the security team to perform a manual review if there are more than 4 orders placed to any single shipping address in a 24 hour period regardless of the number of users.

E.2.2 Inputs Available

The following data is required to perform the stated evaluation described in the problem statement:

  • Date/time of each order

  • Shipping address for each order

  • Count of orders using each shipping address

E.2.3 Evaluation

It is recommended to form a logical statement to describe the risk evaluation required by your problem statement.

The logical statement for this scenario is:

"For a shipping address, if total # of orders > 4 in last 24 hours then review order."

E.2.4 Outcomes

The outcome required by the problem statement in this case is to generate a single Fraud Alert for the security team.

E.2.5 Translation

In the translation step, the problem statement that was broken down is mapped to the OAAM security policy components.

Table E-1 Problem Statement Mapping

Problem Statement Breakdown Oracle Adaptive Access Manager Security Policy Components

Notify the security team to perform a manual review

An alert with specific messaging

Shipping address

An address entity

Orders

A custom checkpoint for this transaction is needed

 

A policy scoped to the "order" checkpoint will contain any rules needed.

If there are more than 4 orders placed to any single shipping address in a 24 hour period

A rule configured using a generic transaction rule condition


E.2.6 Alert

The best practice is for every evaluation to have a separate alert message.

E.3 Example Scenario: Login Security

In this scenario, a Security Administrator wants users that login from a state they have used less than 5% of the time in the last month to answer a KBA challenge question before being allowed into the protected application.

E.3.1 Problem Statement

Profile users' login behaviors including the geographic locations they login from. Use their unique profile to determine how risky a login attempt is and challenge with a KBA question when required based on risk level. If the login is from a state the user have come from less than 5% of the time in the last month them with a KBA challenge before allowing them into the protected application.

E.3.2 Inputs Available

The following data is required to perform the stated evaluation described in the problem statement:

  • User

  • Time period

  • Geographic location

  • Percentage for total logins used for the comparison

  • Registration status

E.3.3 Evaluation

It is recommended to form a logical statement to describe the risk evaluation required by your problem statement.

The logical statement for this scenario is:

"For a user (logging in from state(s)), if % of logins < 5% of all his logins from this state in last month, then challenge user."

E.3.4 Outcome

The outcome required by the problem statement in this case is to challenge the user with a KBA question if the percentage of logins to a state is less than 5% of his total log ins to states in the last month.

E.3.5 Translation

In the translation step, the problem statement that was broken down is mapped to the OAAM security policy components.

Table E-2 Problem Statement Mapping

Problem Statement Breakdown Oracle Adaptive Access Manager Security Policy Components

if logins from a state

Pattern to track the user's logins from different states.

Multi-bucket pattern with user as actor and state as attribute and for each as the compare operator.

challenge user

An action group to KBA Challenge

with a KBA question

Is registered is an attributes and equals as the compare operator and yes as the compare value.

He has to have questions registered before the system can challenge him with a KBA question

percentage for state vs percentage of total

Condition: "Entity: Entity is member of pattern less than some percent times"

5%

Percentage basis specified in rule

last 1 month

Time period specified in rule

before allow to proceed to protected resource

Post-Authentication checkpoint policy

In best practices, KBA challenges occur in the Post-Authentication checkpoint.


E.3.6 Action

KBA challenge users logging in from a state that they do not log in from, specifically one that they use less than 5% of their total logins to states in a month