Feature - Automated Account Reviews (end of April)

[eramba]

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

[eramba]

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:

[david.schroth]

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.

[eramba]

Hi David,

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

@david.schroth

I don’t see an obvious way to display the permissions that each account has.

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…!

@david.schroth

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 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.

[eramba]

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.

[david.schroth]

@eramba

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…!

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.

[eramba]

@david.schroth

f 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.

There is a description field !

[david.schroth]

@eramba

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…

[eramba]

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.

[JGLA]

Completely agree that this added detail is required to make this a useful feature for any kind of audit assurance.

[eramba]

I’ll have a testing environment tomorrow, i will try to shoot a video (yes, yet another) showing the general functionality.

[eramba]

A video i made while testing on dev branch:

Url: https://drive.google.com/file/d/1tZQEoBxQZMDA_0QVC9T4M5Dpyh9g4NTe/view

[rene.beauregard]

Looking forward to this new feature.

[eramba]

glad to see that, the video quality is awful ! i honestly did not realise it was that bad.

[njaehnert]

With Enterprise Update 53, the blog post stated this would come out in Beta at end of April.

I just ran the e1.0.6.057 update, but do not see this feature yet under Security Operations. Is it available to beta yet?

Thanks!

-Noah

[eramba]

Hello Noah,

We got delayed , we are hoping to put a release out next week it might include this feature as “beta” !

Regards!

[njaehnert]

Thanks Esteban! Looking forward to the release, even if it’s just beta.

[eramba]

we are nearly there, today we made a detailed testing and we did not see anything wrong … so next week this is out.

[nluebbers]

Just a comment on this feature but unless I missed something it looks like it requires we setup some process to do an AD dump to create the data to be fed into this. It would be much nicer for those of us integrated into AD already if we could just point to an AD group and have it query that group for the user list?

[eramba]

Hello,

Bare in mind it can work with anything, not just AD!

Yes it requires you to pull accounts from whatever system you are aiming to review accounts, is really easy to code such scripts we have made examples for linux, mysql, AD, etc.

kisero/account_reviews_scripts/blob/master/ldap_get_list_of_group_members.php

the one i mention above works with LDAP and pulls accounts and their last logon. We’ll keep adding more as time permits, we can also work for your specific needs but that needs to be billed separately.

I hope that helps!