Database Reference
In-Depth Information
During simulation, as you view the model hierarchy and add remediation steps,
you will find yourself asking the above questions mentioned earlier for various
access points. You can continue to apply different access points to the model, in
essence redrawing the model with the newly applied access point while leaving
the remediation steps you have added. The model is a means to an end . It is used to
simply view the security model hierarchy in various ways to help analyze who has
access to what, and how.
Access paths are visually represented in the model. When a child is removed from
a parent, access paths that are no longer accessible will be grayed out. Keep in mind
that there may be many paths to get to an access point. The access paths are only
gray if all ways of accessing the access point are eliminated with the remediation
steps. Be sure to also consider what is seen on the screen may not be a complete
picture of the access security hierarchy. Look for the arrows on the right and left
of each level that allow you to scroll through to see additional access points in the
hierarchy. Also keep in mind if you have filtered your model, not all access points
may be displayed on the screen.
In some cases the links that show as gray can be misleading. For instance, if not
all of the access points are displayed on the screen (you must scroll to them), it is
possible that access points off the screen would be remediated and therefore cause
their children to be remediated, and would still show links as accessible (not gray).
In order to ensure links are appropriately grayed, consider filtering results in
the model to show specific users and roles. In the end, the model is just a visual
representation of the hierarchy. The statistics will show the accurate results based on
the remediation steps.
Implement corrective actions : Remediation will involve making changes in
the system that is being analyzed. For instance, in Oracle E-Business Suite, a
menu structure or responsibility may need to be changed. These changes will
generally first need to happen in a development instance, then most likely in
a test instance, and finally in a production instance. It is important you have a
change-tracking process to ensure the changes are made from system to system.
Make changes in the underlying system : The act of remediation is to make
actual changes in the underlying system in which incidents exist. Options
for remediation may be different depending on the business system. Some
common changes that may need to be made in the business system include
inactivating users, revoking role assignments, and changing menu structures.
 
Search WWH ::




Custom Search