With Access Manager 4.3, you will get an out-of-box Audit Server, default Reports, and Analytics Dashboard. This new capability can be achieved by installing a new appliance. If you already have an auditing infrastructure, you can forward raw events to this new appliance and use “Analytics Dashboard”.
Analytics Dashboard provides an intuitive visual view of real-time and historic access patterns. With this you can gain intelligent insights into typical access patterns and make decisions. You can tweak Access Policies, consolidate resources, capacity planning, and spot security risks.
With Analytics Dashboard, you can gain insights on Users, endpoint characteristics, Applications Accessed, trend of Authentications over a time period, security and Risk-Based Authentication patterns.
Typical Use Cases:
Here are some of the use cases you can achieve with the Analytics Dashboard.
Balance “Step-Up” authentications for users (in Risk-Based Authentication)
The NAM Administrator has a big task of configuring Risk-Based Policies (RBA). He has to balance security with user experience. He has to configure policies in such a way that the NAM system asks for additional authentication claims only to potential malicious users and allow legitimate users an easy pass. Usually, he has to configure “Step-up” authentication for additional claims. With Analytics Dashboard, especially, “Post authentication Risk” pie chart, he can get how many of the users are classified as “High” and subjected to “Step-up” authentications. For example, if more than 80% are classified for “Step-up”, he can plan to tweak the Risk policies so that high risk authentications are minimized and target only to malicious users.
Watch typical Authentication patterns and then configure policies.
The NAM Administrator is not sure what policies to configure for RBA. He decides to watch for typical user behaviors for a few weeks and based on that data, he will come up with best policies to allow legitimate users and deny other users. He enables RBA and assigns a default action of "Allow". After a few weeks, he schedules an "Analysis" job for those weeks. He looks at the most used geo locations, most used browsers, and most used end point devices. He samples that set and verifies that indeed those are legitimate users. He configures those users with low risk score. The rest of the users will have high scores with step up. In this way, he'll be confident that he is not giving the legitimate users a lot of troubles. He continues to monitor the dashboard and promptly reviews the high classified users and mitigate them if they are found to be genuine. (Risk policy for time of day, day of week is not there today in RBA)
Outliers. If some authentications or access patterns are not in align with the rest of general trend, the NAM Administrator would like to know if that is a breach or just an exception for that day or incident.
With the dashboard showing the outliers of usual trend, the Administrator can focus on those outliers leaving out the majority of legitimate users thus reducing the administrator efforts. He can drill down on the outlier and infer vital clues about that. Outliers could be "time of day" logins, "day of week" logins, frequency of login.
Verifying Access Rights
The IT Admin wanted to know if an application is accessed according to the policies defined by the Enterprise. In this release, this cannot be achieved through the Analytics Dashboard, but through a query in “Reporting Console” of the Analytics Server. For example, if an application “Office 365” was ever used, you can issue a query "((sev:[0 TO 5]) NOT st:"I" NOT st:"A" NOT st:"P") AND (dp:"Office365")". And to know whether “Office 365” was used by user “Bob”, append "AND (sun:Bob)" to the above query. In subsequent release, you can get this information just by clicking on the “Application” chart or using the filter.
Usage Patterns Analysis
You can use this analysis either for security purpose, IT resources consolidation, or better support investment for your enterprise.
Is that normal Access Pattern or not
Business owner Bob looks at the yearly trend or weekly trend of Applications access through Authentication data. He notices on a particular day or month, an unusually low count. Were there any critical services down during that time or other explainable reasons like holiday?
Usage of invested Applications
Bob looks at the most used Applications. He gets an idea how much of investment made for the cloud applications are indeed used by how many.
Better resource planning and support
Bob, now who owns a consumer facing business, looks at the past year trend. He notices there is a huge increase of access during festival seasons and he remembers there were many issues reported about difficulty of accessing the application X. The same festival is a few months away. He proactively plans to upscale the application, and also increase the Access Manager license.
Insight on end user and device characteristics
The IT development head is in the process of developing a new application. He wants know the typical browser and client device that he can invest in testing the application against to maximize the result and minimizing the resources. Fortunately, Access Manager already gives that data to him as all applications get authenticated through Access Manager. For example, if 90% of requests are going to be from IE on Windows, the development team should focus maximum effort on that platform and minimal testing on other platforms.
Usage of Applications
The IT head looks at the most used applications that are authenticated through Access Manager. He can decide which applications he can increase the investment in terms of support, enhancement, license, etc.
The IT Manager looks at the number of users who used Applications through Access Manager. Should we purchase additional licenses?
Make Development Decisions
An Application development Manager approaches IT head asking "We are planning to develop a mobile application for our consumers. Are our consumers using iPhone the most, or any Android variety?". IT head says "Let me pull the dashboard. Ah.. here you see many are using iOS, they'll be pleased if you release an iPhone App first".
User Behaviour Analysis
User Carolin reports that often she is denied authentication or asked to step-up. She remembers the date and time it happened. Admin Alice brings up the dashboard and enters the user "Carolin" in the filter field. She analyses the risk level distribution pie chart for her. She confirms that this user is classified "High" most of the time. Why? She looks at the geo map of orgin of the requests. Did it not match with policy Alice has configured? She also then looks at end point characteristics graphs (browser and device). Does it align with the Risk policy configured? She can then mitigate the problem. If there are no clues, she can look at the login trend of the user, note down the authentication time, and use Reporting Console's query interface to go to that time and analyse what really happened and also look at the Access Manager logs.
Potential Suspicious Activity
The IT Admin notices there is an unexplained spike in successful authentication unusual to the trend on day of week, time of day, or week of year. Every week, usually people login at 9 AM during the weekend. But today there is another spike at 2. Is it normal, or any suspected attack?
Admin Alice notices there is unusual activity from a country. She clicks on the region to narrow down and track the users and other activities from that region.
Alice looks at weekly trends of authentication for the past few weeks. She notices there was hardly any activity on weekends. But, on one weekend, there is more than usual activity. She calls up others and verifies that indeed something explains that. Otherwise, have security experts track if any malware or information theft happened.
Future Additions not available at the moment
Frequency and volume of Failed authentication attempts. This could indicate a potential malicious activity.
Failed authentications are high but risk score is not high, time to review the risk-based policies
if there are sufficiently huge failed 2nd factor authentications, first layer of security is not good or users have a very simple first level password. If the 2nd factor is a result of risk policy, find the parameters which pushed these users into 2nd factor and lower them without compromising on the security.