Feature - Automated Account Reviews (end of April)

I’m getting the permission error as well - looking forward to looking at the design document.

new link:

As a quick intro , we are thinking on the following types of reviews:

  • Snapshot: pull all accounts and check them all
  • Differential: pull all accounts, compare against the previous pull, show differences and ask for those differences to be reviewed. Pulls intervals can be 1 hour minimum (they rely on hourly cron) and that is not really good because in one hour you can add and delete the same account and eramba would not have a clue, still for many people is a huge step forward.
  • Exits: pull all accounts from a system and compare them against a list of current employees or employees that have left the organisation. If this is run every day you can monitor exits pretty much ok.

Thanks! I also have one other review idea/thought here. Would be good to have another option to review groups.

Especially if Eramba can pull from LDAP/Active Directory, would be nice to specify which groups to review, who the owner is, and allow them to attest that the correct people are in the group, or ask to have some removed if needed.

We used to do this manually/via script at a previous employer. We pulled any groups that provided administrative access to devices or systems, then sent them to the owner to validate.

(Note: This may already be the thought/intent behind the Snapshot and Differential reviews above. Just giving a thought/example as to how I’ve dealt with this in the past, and how Eramba might help).

Thanks!

-Noah

With this approach you can check any system no matter the connecting method, you will need:

1/ script to pull members from that group and store them in a text file, the following is an example that stores all members for a group in a txt file.

ldapsearch -D “CN=Joe Ramone,OU=People,DC=corp,DC=eramba,DC=org” -w “password” -p 389 -h ad.eramba.org -b “DC=corp,DC=eramba,DC=org” -s sub “(&(objectCategory=user)(memberOf=CN=Network_Team,OU=Groups,DC=corp,DC=eramba,DC=org))” sAMAccountName | grep sAMAccountName | sed s/"sAMAccountName: "// > eramba_v2/app/tmp/network_group_accounts.txt

You will add that script in your crontab to run every hour, day whatever you want.

2/ eramba will pick up that file automatically and perform any of the three reviews (snapshot, differential, exits)

On purpose we want to stay “out” of the method used to get accounts, im sure we’ll have a nice repo of scripts you and everyone else can use.

This looks like it will be very useful for a number of my clients and far more economical than using Aveksa or Sailpoint (both of which may be helpful to you in looking to get any more inspiration for requirements).

Based on the the training class I was in a couple weeks ago and the direction of the account reviews module, there may need to be some thought given to how to handle assets. On the training call, it was said that it was a bad idea to load every single system asset (i.e. all servers, databases, etc.) into Eramba as the asset functionality was designed more to be used for high level things, perhaps at the system, category or process level (same level as the risk assessments). However, when we start getting into doing account reviews, being able to establish relationships ala a CMDB would be very beneficial at the server level (assuming there’s intent to use this for infrastructure user reviews) but also bring it right back to where Eramba is not intended to be - at that every single system level. Of course, even without the relationship information, this is still a great feature for my smaller clients.

Will the Rest API be made to work with this feature? Specifically, can systems push their user lists in via it?

makes a ton and a half of sense - yes…i’ll keep this in mind! thx!

Catching up on this area of development and I wondered if the capture of account information would include some reference to the level or type of access. Just as Eramba has groups with different types of access, so do most systems needing account reviews. If we capture accounts and ask people to review them via Eramba, how will this review reflect the level or type of access for that review? Maybe someone changed roles, and while they still need access, maybe the level of access has changed. Would that be obvious in the review tool?

nice one JGLA - very good point indeed.

i’m running your request with an example, lets assume eramba as the target system to review. eramba has:

  • user accounts (authentication)
  • users assigned to groups (authorization)

to review both, authorization and authentication i believe you’ll need to configure in this feature two reviews:

  • list of user accounts (authentication)
  • list of users per group (authorization)

if someone is in group A and gets group A and B , that will show on any of the two basic reviews (snapshot or incremental).

Not sure if this clarifies the approach (simplistic of course as anything in eramba) we have taken.

I think the easiest way to put it is that eramba has no clue about what is being pulled from the fees and what is reviewed, you could well be reviewing a firewall configuration (or its changes) instead of a list of accounts with this same feature.

appreciate the thoughts and feedbacks! really do.

Good in concept. There may be cases where a user may have multiple authorizations. It may be important for this system to be flexible to handle various forms of authorizations, whether direct user authorizations, or via groups. Also, to be able to group or batch these together for approvers to avoid too many steps in the approval process.

I’ll have to look at the possible inputs we would be using to see if there are other considerations to share, but it sounds like the right path.

Guys, thanks so much for doing this. great feature. looking forward to using this. (Paul Jose)

HI Esteban,
with the Account review module, I understand that the module will be pulling information from a CSV file. is there plans to interface with Windows AD like you have done with the Accounts module?

Hey there Paul - hope you are enjoying sunny southern hemisphere !

you can pull anything as long as you have a script that does it for you and then sends the output to a CSV (from where eramba reads), we’ll for sure provide BASE (might need some customization) templates for:

  • ad
  • ubuntu linux
  • mysql
  • mariadb
  • github
  • amazon aws

hope that helps , marek starts coding next monday… i explained him the stuff yesterday and he understood it quite well … or at least that was my impression :slight_smile:

marek is moving forward pretty nicely, here i leave some screesnhots of the early user interface (which uses the current/old template but will be migrated to the new template once we get there)

the list of pending reviews for a user that logged on the portal:

the index of multiple account reviews:

exit account reviews portal:

the wizzard used to create account reviews:

1 Like

Looking at the screenshots, I don’t see an obvious way to display the permissions that each account has. I suspect the way that you would model it would be account review/pull per permission set rather than including all roles/permissions for a given application.

Using the Github example, let’s say Julo has admin rights and Rado has read only rights. How would the reviewer of the permissions know this? They would not be able to make a valid determination of access appropriateness without this information.

I realize Eramba would not be able to do too much with respect to roles/groups - it would have to be an field that the source system would need to append to its file that is being exported.

Hi David,

Sorry for the late response, i honestly missed your post!

This is perhaps because this feature is not about showing users what permissions users have but instead validating if their accounts should be there or not…!

I would create two account reviews, one for each type of right. a script pulls who has “admin” and writes it on a file, eramba takes that file and notifies whoever has to do reviews for “People with admin rights on Github”.

Another approach would be to pull all users and their rights in one shot and store the rights as “description” (when you review accounts, there are two fields: the account and a free description field) … then you can review all accounts in one shoot. since each review is stored you can later use filters to know who had what access.

Not sure if this will make a lot of sense without seeing the feature , perhaps at the end of the week i’ll have a video with a demo.

We are moving on with this feature, as we are testing we build template scripts to pull accounts from:

  • linux
  • mysql
  • aws
  • ldap (ad)

https://github.com/eramba/account_review_template_scripts

we are still fine-tuning them … it should be a basic template for potentially more elaborated scripts.

Isn’t the entire purpose of validating whether their accounts should be there or not performed as a control to limit access to individuals to just what they need in order to perform their job function? If you only review a list of accounts but do not know what permissions they have, then you are not able to determine whether their access is appropriately limited to the “need to know” level to perform their job.

If you take a payables system, for example, you’re often concerned about segregation of duties with respect to the 3 way match (PO Entry, Approve Invoice and Edit Vendor Master File, for example) - you generally do not want the same person to have more than one of those roles in a given system. If you simply review that people have accounts, you’re not addressing the risk of users with incompatible roles/functions.

If there was a description field that was applied at the account level (rather than review level), then this would easily address what I’m asking about. If there has to be a new Account Review performed for each role/permission set in an application, it will get unwieldy very quickly. The account level description field could then be populated via the scripts - i.e. for AD, the list of groups a user is in could be concatenated and put in that description.

There is a description field !

Then we should be good to go - in the screen shots I see “description” at the review level, not at the account level, so that’s what I was focusing on…

actually I’m not sure the original plan of relaying on the description field is enough, without having groups/roles per account as structured data we’ll miss at least these two functionalities:

  • differential reviews (those that compare accounts in between the current and previous pull) wont notice if a user changed permissions (groups or roles) as the comparison now is done only against the account name.
  • dealing with SOD reviews (a bit like you mentioned above) is a real pain (tons of spreadsheets and pivot tables) and although now it would be hard to include advanced comparisons, with the current filters we could at least respond to things like: “who is member of this group/role”, “show me accounts that are members of this and that role at the same time”

i’ll talk tomorrow to marek … he wont be happy when i tell him we need to add this … but hey, if we are going to do this lets try to do it well.

1 Like