Skip navigation
All Places > Products > RSA Identity Governance & Lifecycle > Blog
1 2 3 Previous Next

RSA Identity Governance & Lifecycle

87 posts

Our 7.1.1 release continues to build on many of areas of improvement we have made across the 7.x releases including enhancing the user experience, delivering analytics to make informed decisions, and reducing the complexity of Identity Governance and Administration.

As we look at our recent releases we have provided innovations such as the new user access review making it easier to understand if access is appropriate, quick start deployments, and analytics that make your processes easier to manage, while enhancing some of the screens in the product to be simpler and easier to use.

So, what about 7.1.1?

Segregation of Duties, made simple

Management of Segregation of Duties (SoD) rules and processes can be hard; when you try and scale it to hundreds or thousands of applications it can feel impossible. To meet the every increasing risk and compliance requirements of many organizations SOD management at this scale is being demanded by audit and the business. To achieve this businesses are defining SoD matrix, a set of access classifications that cannot be held in combination. These organizations are then classifying their access and in this way are able to have simple dynamic SoD detection based on access classification.

To help our customers, RSA has provided a SOD solution including a recommended practice and two new product capabilities in this area.

New SoD Remediator Experience

Working with our customer design partners, RSA has significantly enhanced the remediator experience to reduce the level of effort needed to make decisions when a violation occurs. The experience provides more analytics and data while also allowing bulk actions and reassignments to take place when needed.

SoD Recommended Practice

This recommended practice talks you through our solution for implementing SoD detection, including building the classifications matrix and implementing it within our platform.

Advanced SoD Analysis rules

The new advanced rule process allows for a third data element to be considered when detecting SoD violations. This is needed when using a classification model to detect true violations and remove false positives. For example, you could say that having front office access together with back office access is a violation, but if they have that access in two different applications or countries, it might not be. The advanced rule capabilities allow you to make these correlations .

Continued evolution of the New Reviewer Experience

After RSA released the new Access Reviews experience in 7.1, we wanted to continue to enhance reviews based on the feedback from our customers. In 7.1.1 we have added several changes based on your input. 

Custom Views/Classifications

Give your reviewers more insight into the access they review, build your own custom views of data to highlight areas of risk or provide importance context to reviewers such as critical or privileged entitlements.

Review Calendars

Give your reviewers the time to complete their review successfully, take into account weekends and holidays when setting the amount of time they have to complete a review. All review types now allow you to specify the calendar they use when setting the timing of the review.

Pending Revoke, Automatically Marked Revoke

Reviewers are always frustrated when things don’t make sense. In 7.1 when we added categories into the review we provided a category called “Pending Revoke”. This means the items in this category are already in the process of being removed. Then reviewers asked “Why do we have to mark them as revoke again?” The default now is that everything in this category is immediately marked as revoked in the review.

Diagnostics & Heuristics

Collecting and testing key performance indicators

How successful am I being? How many applications have I onboarded? How many requests have I processed? What are the trends on my system? Is the way I configured the system the best way?

These are the types of questions we want to answer with this feature, which collects over 130+ data points daily to give you a better understanding of the successes and trends in your system.

These are things like the number of users, application, entitlement, orphan accounts, or time it takes to collect the data, approve a request, or complete a review. You can also provide the data to RSA, where we can give you with deeper insights looking at best practice and your status against other similar customers.

Trending Dashboards

7.1.1 provides a number of new trending dashboards allowing you to visualize the trends in key areas such as reviews, requests, rules, and roles. Customers can create their own as well, leveraging a new public view against the diagnostics and heuristics data.

So, as you can see, there are some great innovations in this release and these are just some of the highlights. Check out the release notes for full details and look out for the RSA Identity Governance and Lifecycle quarterly webinar series here where we will give more insights into what’s coming in the future!

Sean Miller

New Feature: Web Services

Posted by Sean Miller Employee Mar 19, 2019

In the recent RSA Identity Governance and Lifecycle 7.1.1 Service Pack Release we have added some new web services.  In previous releases you could use the findApprovals, getApprovalDetails, and performApproval web services to interact with approvals.  In this release the following web services have been introduced to interact with any type of work item including approvals:

 

  • getWorkItemsForUser
  • getWorkItemDetails
  • performWorkItem

 

The getWorkItemsForUser web service returns high level details for the work items including the work item IDs.  The getWorkItemDetails takes a work item ID and returns more details including what actions can be taken.  The actions that are returned are based on the transitions modeled in the workflow.  The performWorkItem web service is used to complete the work item using the provided action and comment.

The approval-specific web services will be deprecated in a future release.  Any implementations based on this should be updated to use the more generic work item web services.

      

 

Lastly, the new web service findReviews has be introduced in this release.  This allows you to search for reviews by name or other search criteria.  The web service returns details about the reviews based on the requested columns.  In particular, the review ID is returned which is needed for other calls like getReviewStatus, refreshReview, setReviewState, and updateUnreviewedItems.

As part of the RSA Identity Governance and Lifecycle 7.1.1 Service Pack release we are excited to introduce advanced Segregation of Duty (SOD) violation analysis capabilities that make it even easier for global organizations to identify and remediate where this risky access truly exists in their organization.

To scale at the enterprise level, across thousands of applications and hundreds of millions of entitlements, Segregation of Duty policy analysis needs not only examine if access on one side of the equation is in violation with access that is on the other side (for example, the ability to submit a check request and the ability to approve a check) but also inspect deeper and across business processes to determine if there is a false positive violation present or there is truly a violation and inappropriate access.

In this example, a user should not have the ability to submit a check and approve a check in the payroll expense system and accounting system. However, they may have the ability to approve a check request in the contractor management and vendor management systems. If organizations look at just the ability to submit and approve checks as violations, false-positives would be detected. This will lead to an overhead to cleanup before violations are sent to business users or policy managers or even having to create thousands of rules – which is unmanageable!

With this new and advanced SOD detection and correlation analysis, organizations can create a few number of rules that look across the enterprise and evaluate if the access is truly a violation. This is an advanced analysis that can look across the entire global set of applications and entitlements and determine not only if there is access that is truly in violation (based on a common business interface / application relationship), but also to reduce and virtually eliminate the number of false positives that can be typically be presented when just looking at two sides of the equation.

This analysis is performed at the business application level and determining if entitlements across both sides are in violation based on a “correlation” between the applications. That correlation is where the applications are considered part of the same business process, such as if they interface with each other. Following the example, instead of creating hundreds of rules to look for a submit and approve toxic access combinations, organizations can create a single rule that looks for these access types, using a correlation to identify where access should be considered a violation and access that is found on one side (but no correlating access on the other), is not a violation.

Otherwise without the correlation of the business applications the potential for several false positive violations surface. This creates a burden on the team to clean up before sending out violation to address or if not cleaned up before, creates a mess of information that is inaccurate and creating the potential for appropriate access to be inadvertently removed.

Organizations can effectively analyze across their enterprise applications where risky access exists and truly represents a SOD policy violation; therefore, reducing risk by quickly getting access violations in-front of the right people for review and remediation. In concert with this advanced analysis, a simplified and streamlined new policy violation review and remediation user experience has also been added.   

 For additional information on this update – please check out this additional context:

  • New SOD Policy Analysis Capabilities:

Have you ever wanted to be able to review and remediation multiple access violations at once? Have you ever wanted to be able to see how widespread access violations were across a grouping of users, business units, or applications? Have you ever wanted a streamlined, intuitive, and single screen to review and remediate access violations in your organization?

 

As part of the RSA Identity Governance and Lifecycle 7.1.1 release we have introduced a new streamlined, intuitive, and simple policy remediation experience that allows you to address the above questions. This new remediation experience follows the streamlined experience of the Risk Based Reviewer Experience; which, based on customer feedback, delivers a very successful and intuitive user review experience that has reduced risk in their organizations.

 

Some notable highlights for this new remediation experience

  • Several existing user access review capabilities are now available for the remediation review, such as review instructions, due date, multi-step operations, display views, guidance panel and more.
  • Improved details about the violating access in the accordion drop down, including any other policy where the violation is also in existence.
  • Policy Violation review assignments leverage the same business level assignment capabilities as user access reviews.
  • Violation Remediation Reviews can be linked to one to many User Access and Segregation of Duty Rules, making it simple for organizations to have a focused initiative to address access violations.
  • Violation Remediation Reviews can be monitored to ensure that assigned reviewers are addressing open violations.

 

For additional information on this update – please check out this additional context:

  • New Violation Remediation Experience: 

The log artifact is a new feature in RSA Identity Governance and Lifecycle Version 7.1.1 that will aide in the gathering of log information in the event that a support ticket is created.  It is an administrator-only feature that can gather the most widely used log files when troubleshooting problems in the application, thereby reducing the time to identify the root cause of an issue.  It is designed to work on a node-by-node basis and will work for different architectures such as Hard Appliance, Software Bundle with remote database, and Clusters, along with the different application servers we support.  The page can be found under the Admin > Diagnostics menu.

 

 

 

 

It is located on the Log Artifact tab.

 

The following is a description of the different areas of the page:

 

  1. Node Name - This tells the user which machine the user is current logged into.  This is important because the utility will gather all the log files that are local to that node.  If you are in a clustered environment and need logs from all the nodes in the cluster you will have to log into each one individually and gather from each node.  The information after the ‘:’ is the node type for the machine.  There are two types Systems Operation Node (SON) and General.  Log files should be collected from all nodes if this is a cluster.  At a minimum they should be collected from the SON.
  2. Date Range - This can limit the amount of information that is extracted from the log files.  For instance if the problem is two days old you would want to limit the log file from the last few days.  The default of 30 days will typically be sufficient.
  3. Create File Password (Optional) - This will allow you to password protect the zip file.
  4. Generate Zip File - This button is what will start the gathering of all the logs and then zipping of them into a single file.
  5. Current Status - After initiating the gathering process, this area of the page will display the status of what is being gathered.  It is not refreshed automatically so to see any new status you will need to refresh the page manually.  Once it is complete it will display the file that is available from this node.
  6. Download - This button will be enabled once the gathering/zipping process is complete.  It will allow you to download the most recent process.

 

 

 

When in progress the Current Status will contain the current step.

 

 

Once completed the zip file will be available for download

 

Upon completion of the process the status section will show the pertinent information about what was chosen for this invocation.  As detailed in the picture we will store the zipped file on the server and it will stay there until the next invocation of the process.  To store the file locally just press the Download button.

 

 

Limitations/Restrictions:

  1. When gathering log files for nodes in a cluster the Administrator must log into each node and run the process.  We only gather the local files to the server.
  2. Warning messages from the tool does not indicate a problem with the feature.  Not all environments/configurations will contain the same log files.  The Warning messages are primarily for Engineering.
  3. The gathering of the logs for a remote AFX server is still a manual process.
  4. The gathering of logs for a remote database is also a manual process.  We will display a Warning message with this configuration as the database logs will not be local.
  5. Some log files may reside in different directories depending on a customer’s configuration.  We will make a best attempt to find them with some well-known locations.  If we can’t find them we will display a Warning message to that effect.
  6. The process does not gather an AWR.
  7. The process does not maintain previous ZIP files.  At the start of a new generation the previous file will be removed, this will reduce the chance of running out of disk space.

 

See the following video which demonstrates the use of the feature.

 

RSA Identity and Governance Release 7.1 introduced a new interface for user access reviews, to provide a better user experience and improve efficiency in performing reviews with help of analytics-based prioritization and identification of high risk access and violations.

 

To continue enhancing the enriched user experience, the Display Views feature for the new user interface (for user access and rule remediation reviews) is introduced in Identity Governance and Lifecycle Service Pack Release v 7.1.1.

With the introduction of Display Views, you now have ability to organize review items in multiple ways to meet your requirements.

 

RSA IGL v7.1.1 Display Views

 

Here are some of the capabilities added to support Display Views in version 7.1.1.

 

Select multiple display views in review definition

The system now supports using display views in the legacy as well as the new user interface (for user access and rule remediation reviews). When more than one display views are selected in the review definition, the resulting review in the new user interface lists the display views in the left panel above Guidance and Analysis.

 

Custom display views

You can now define custom display views that can be used for the legacy user interface as well as the new user interface. The process to create custom display views is same as that for the legacy user interface. When custom display view definitions are used with new user interface:

  • Only the first six selected columns (from the custom view definition) are visible to the user in the new user interface.
  • The new user interface ignores the "grouping" configuration of the custom display view definition.

 

For additional information, follow the online help pages.

 

Here is a video on display views.

This blog describes what all diagnostics data is collected in RSA Identity Governance and Lifecycle V7.1.1 and how it can be useful to customers.

 

         The diagnostic data collection in RSA Identity Governance and Lifecycle is turned on by default and collects system information daily. The frequency of data collection is configurable (see Admin > Diagnostics in the product help). Customers should review the schedule for diagnostic gathering to ensure it does not conflict or delay nightly collections. With this feature enabled, statistical information is gathered about the product components like reviews, rules, access request, AFX, roles, reports, as well as information related to the deployed environment and the applications that are configured.

 

         Trends related to the change in the application configurations can be assessed by looking at the application parameters like the number of accounts, users, orphan accounts, users with multiple accounts, roles, entitlements over time. Assessment of sudden increase in data volume or spikes can be tied to symptoms like application slowness and performance degradations. Admins can use the historical data to explain such anomalous behavior or trace and tighten rouge jobs that could be the cause.

 

         Deployment related information can similarly be used to get the big picture of the type of Database configured (remote/local), number of “Remote Agents” deployed, number of AFX servers, number of nodes in cluster. This information can be used to compare any deviations from the recommended configuration by RSA and corrective actions can be taken.

 

         AFX related information like the number of connectors, daily status, number of active running connectors, and count of fulfillment request sent in a day, including failures. These can be used to understand the trend and make necessary changes including tuning of the end points to adjust the overall performance.

 

         Health of collectors can be learned from the trend in time taken for collections to complete, frequency of collection, and number of collection failures. This information will help in tuning the collection schedule and avoid redundant collections.

 

Out of the box Reports/Charts in 7.1.1 are provided for the following components:

Weekly and Monthly views are available for customers to include in their dashboards to get their statistics.

  • Reviews: Parameters like the number of review definitions defined, size of reviews, number of revokes are collected. Administrators can take stock of these statistics and take corrective actions like increasing/decreasing the number of reviewers, adjust the size of reviews, take actions based on the number of revokes (e.g. some rule may be granting more access than needed resulting in more revokes during reviews).
  • Rules: Parameters like number of rule sets, active/inactive/deleted rules, rule processing time, number of violations/exceptions caught, number of change/violations triggered by reviews each day, exception access granted in a day are monitored. Based on the chart summary admins can tune rules to improve processing, delete/modify rules as needed, can investigate exception access grants.
  • Access Request Forms: Parameters like the number of access request forms that exist, number of workflows defined, number of requests/approvals/fulfillments made per day, and approvals rejected per day are noted. Approval and fulfillment trends will help in measuring and ensuring conformance to SLAs.
  • Roles: Parameters such as the number of roles, number of roles with membership rules, roles with entitlement rules, average entitlements per role, number of users per role, number of app roles per role are captured. These statistics can hint on the complexity, hierarchy and gaps in implementation and association of roles within the system.

 

         The public view PV_TELEMETRY_DATA is also provided so customers can develop their own reports and charts against the diagnostic information gathered.

 

Diagnostics data use for troubleshooting:

         The complete set of data collected can be downloaded from the UI as a zip file containing a set of JSON files, which can be shared with RSA while reporting issues on the product. This data will be used by RSA to diagnose the reported issues and troubleshoot /fix them. Also the data will help RSA understand how customers are using the product and if the scale of objects defined is different from other customers. This will improve the time to resolve issues while reducing the number of meetings with customers. The likelihood of root causing a problem at first level of support (CS) would increase as the data is more intuitive.

 

See V7.1.1 Diagnostics overview video in the attachments.

Im very excited and happy to share our first edition of the RSA IGL newseltter!

 

Our goal is to help share more informatoin about whats happening and key things for you to be aware of. 

This is a monthly release, so you can expect the next newseltter at the start of April.

RSA CHARGE 2019 CALL FOR SPEAKERS OPEN FOR SUBMISSIONS

It's official - time to get your creative juices flowing as the RSA Charge 2019 'Call for Speakers' (C4S) is now open and awaiting your submissions!

 

As you are aware, the RSA Charge events represent all RSA products and an increasing number of customers across solutions attend this one-of-a-kind event each year. The RSA 2019 Charge promises to be the biggest event in our history of RSA Charge and RSA Summit conferences. 

 

The RSA Charge event is successful in no small part because of the stellar customer submissions we receive each year. We invite you to submit your presentation brief(s) for consideration. (That's right, you may submit more than one submission brief!)

 

This year for the first time the '8' Tracks for RSA Charge 2019 are identical across all products and represent all RSA solutions. We are pleased to present them to you:

 

Transforming Your Cyber Risk Strategy - Cyber-attacks are at the top of the list of risks for many companies today.  Tell us how you are approaching reducing this risk utilizing RSA products.

 

Beyond the Checkbox: Modernizing Your Compliance Program - The regulatory landscape is always shifting.  How are you keeping up and what steps are you taking towards a sustainable, agile compliance program?

 

Aligning Third Party Risk for the Digital Transformation - Inherited risk from your business partners is a top of mind issue.  Third party risk must be attacked from multiple angles.  Share your strategy.

 

Managing Operational Risk for Impact - Enterprise risk, operational risk, all things risk management.  Share your experience and strategy on how you identify, assess and treat risk across your business operations.

 

View from Above: Securing the Cloud - From security visibility to managing organizational mandates, what is your risk and security strategy to answer the "go to cloud" call.

 

Under the RSA Hood: Managing Risk in the Dynamic Workforce - The workforce has become a dynamic variable for many organizations - from remote users to BYOD to contractors and seasonal workers.  How are you addressing this shift?

 

Business Resiliency for the 'Always On' Enterprise - The world expects connectivity.  When the lights are off, the business suffers.  Tell us how you are ensuring your business is 'always on' - business continuity, recovery, crisis management and the resilient infrastructure.

 

Performance Optimization: RSA Product Learning Lab - Share your technical insights of how you use RSA products to meet your business objectives.  Extra points for cool 'insider' tips and tricks.

 

We know you have great stories to share with your peers, best practices, teachings, and how-to's. We hope you consider submitting a brief and thank you in advance for your consideration. More information can be found on the RSA Charge 2019 website (scroll to bottom of page) including the RSA Charge 2019 Call for Speakers Submission Form. Submission should be sent to: rsa.events@rsa.com.

 

Call for Speakers 'closes' April 19. 

 

For larger enterprises, creating a clustered environment for RSA Identity Governance and Lifecycle helps to scale the product. The RSA Identity Governance and Lifecycle 7.1 Configuring WildFly Clustering document (RSA Identity Governance and Lifecycle 7.1: Configuring Wildfly Clustering ) describes how to configure a cluster using multicast/UDP for communication between the nodes of the cluster. 

 

RSA Identity Governance and Lifecycle 7.1 now allows communication between the nodes in a cluster to use TCP, rather than multicast/UDP, because TCP is highly reliable and key to a more stable cluster. The new document,

 

Configure WildFly Cluster to Use TCP (RSA Identity Governance and Lifecycle 7.1 Configure WildFly Cluster to Use TCP ), describes how to change current UDP/multicast clusters to use TCP-based communication.

RSA recommends that clusters use TCP rather than multicast/UDP because of some of the key differences between UDP and TCP:

 

1. TCP is connection-oriented, unlike UDP, which is a connectionless protocol.
2. TCP is highly reliable for transferring data because it uses the acknowledgment of sent information and automatically resends any lost packets. UDP does not request retransmission if the packet is lost.
3. While TCP is slower compared to UDP, this is because TCP establishes the connection before transmitting data, and ensures the proper delivery of packets. 
4. The header size of UDP is 8 bytes, while the header size of TCP is more than 16 bytes.  Releases higher than 7.1 deprecate the UDP/Multicast setup in favor of TCP protocol.

Jamie Pryer

Reporting on Reports....

Posted by Jamie Pryer Employee Dec 6, 2018

A common question we get asked... "How many reports are there within RSA IGL"

The answer: LOADS!

 

Within RSA IGL we have a LOAD of out the box (OTB) reports included and shipped as standard.

All these reports can be found in the UI, by going to “Reports/Tabular” then “Create Report” button at the top.

From here you can find a lot of OTB reports by using the “type” and “Template” dropdowns.

For example, if you wanted a report on all your orphan accounts, you would select “Account” and then “Orphaned Accounts” - thats it! really simple

 

If you want a simple way to see all the reports you have in the system overall, you can execute the following query, either within something like SQL Developer or create a new a report within the UI itself

 

Main Query:

Select * from V_LIST_REPORTS;

This table tells you all the reports you have in your enviroment, both OTB and any you have also created as well.

 

Steps to create this in the UI are as follows

Note: this takes <5minutes to complete

  1. Log in as an admin user or as a user who can create reports
  2. Go to “Reports/Tabular”
  3. Click “Create Report” button
  4. Give you report a title and some details so you know what its for in future.


  5. Click the “Query” tab at the top
  6. Add the following SQL query:
    (select *  from avuser.V_LIST_REPORTS)
    Note: makes sure you wrap you the SQL in parenthesis “(“ and “)”
  7. Click the “Columns” tab
  8. Select only the following columns in the right-hand pane called “Displayed Columns” – everything else should be moved to the right.
    • Name
    • Report Description
    • Report Title
    • Last Modified Date
  9.    Click on “preview” button at the bottom to check its worked.

    These are more nice to have changes, that might make the report look a bit better, in my opinion
  10. Go to the “Grouping and Sorting” tab
  11. Select “Report Type” under Grouping, so that we can see the groups of reports we have created



  12. Click the “style” button at the bottom of the row

  13. Select “slate”

  14. Click "OK" to save and exit your report

 

Thats it, all done!

Sean Miller

Security Context

Posted by Sean Miller Employee Nov 21, 2018

This is for advanced users.  While security contexts can help control who can do what in the product, it can adversely affect performance if you have a lot of rules or the scope filters are very heavy to evaluate.  These rules must be evaluated on every user login.

Custom security context files can be used to define your own security rules and/or overload security rules provided in the shipping product.  The key to identifying if you are adding new privileges or modifying existing ones is based on matching the secure object type, name, and action.  If those match an existing entry, then you are overloading an existing privilege.

 

Custom Security Context

To customize the security context, you should:

  1. Do NOT modify the default file inside the aveksa.ear
    Modifying the security context file inside the aveksa.ear is not supported and you will lose your changes on upgrades, moving to other systems, or within a cluster.  By following the steps below you will keep your changes, they will be included in upgrades, and all nodes involved will see the changes.
  2. Take a copy of it to your PC (to use for reference later) so you have the header format and you can see existing entries.
  3. Create a new SecurityContext.csv file with the Header and a line for each privilege you want to add or modify or delete.
  4. Save and upload the custom security file to the UI under Admin > User Interface > Files > Security.

New Privilege

A new privilege is defined when it has a unique secure object type, name, and action.  The product has an internal fixed list of security object types and actions it supports so adding your own won't have an effect (only introduce unique names).

 

If the following privilege is defined, then I might introduce a similar privilege with a different name.  This has the effect of adding to the existing security privileges for the secure object and action:

 

SECURE_OBJECT_TYPE,NAME,ACTION,IMPLICIT_HAS_QUERY,IMPLICIT_BS_CHANGE,IMPLICIT_BU_CHANGE,SCOPE_TABLE,SCOPE_FILTER

Application,Business Owner,Manage,,scope,,t_applications,business_owner=${id} and resource_type='A' and is_deleted='FALSE'

Application,Custom Business Owner,Manage,,scope,,t_applications,cas1=${id} and resource_type='A' and is_deleted='FALSE'

 

In the example above, we defined a new privilege that is going to look in the custom attribute CAS1 to determine if the logged in user should have the Application:Manage privilege.  I named this new privilege 'Custom Business Owner'.

 

To use the new privilege, upload the custom security context file using the 'Custom Security Context' section above.

 

Modifying Default Privilege

To modify an existing privilege, following the steps in the 'Custom Security Context' section above. Find the line of the existing privilege. In this example:

 

Change Request,Affected,View,scope,,,t_av_change_requests,scope.id in (selectchange_requests_id from t_av_change_request_details where affected_user_id=${id})

 

Modify the scope filter for the privilege and upload the custom security context file on the UI under Admin > User Interface > Files > Security.

 

Disabling Default Privileges

Should you want to disable an existing privilege, then you should follow the exact same steps as in the modifying default privilege, but provide a scope filter that is never true (For example: 1=0).

 

SECURE_OBJECT_TYPE,NAME,ACTION,IMPLICIT_HAS_QUERY,IMPLICIT_BS_CHANGE,IMPLICIT_BU_CHANGE,SCOPE_TABLE,SCOPE_FILTER

Change Request,Affected,View,scope,,,t_av_change_requests,1=0

 

Many people have incorrectly tried to modify the default security context file instead removing the physical entry all together.

This posting is based on functionality as of 7.1.0 P04 and 7.0.2 P10

Please see the attached case study for how RSA IGL has helped a leading automotive company to reduce data retention and acces risk

Please find attached details of how RSA IGL has heped Dell technologies to reduce audit effforts by 50%, enhance their compliance posture and improve overall user experience!

Please see the attached for a great case study around how RSA IGL has helped a leading food manufacture to cut excessive privilages and reduce business risk.