Big news! The community will be moving to a new platform April 21. Read more.
Big news! The community will be moving to a new platform April 21. Read more.
Absent Member.
Absent Member.
431 views

"Access Rights Removed" Rule Fire

So we're seeing an "Access Rights Removed" correlation rule fire any time a user logs in to the console based on a "User Updated" event.

We've been ignoring it for the most part, but with the HIPAA 2.0 Compliance Insight Package it's showing this event as a possible HIPAA violation on the dashboards.

Has anyone else experienced this?

Labels (1)
0 Likes
4 Replies
Fleet Admiral
Fleet Admiral

Hai Samantha Rorabaugh,

Can U Give us Some more Details about this Rule...

Is it a Custom Rule or it is derived from ArcSight User Sessions Rule.Anything Like That....

0 Likes
Absent Member.
Absent Member.

It's not a custom rule exactly, it's built into the Compliance Insight Package rules for HIPAA 2.0.

Basically, one of us logs in to the console and the base event "User Updated" is logged. This causes the "Access Rights Removed" rule to fire. The conditions for this rule are as follows:

AND

     OR

          Category Behavior = /Authentication/Delete [ignore case]

          Category Behavior = /Authentication/Modify [ignore case]

     Matches Filter("/All Filters/ArcSight Solutions/HIPAA 2.0/My Filters/Limit Regulation")

     Name NOT Contains Password [ignore case]

     Attacker User Name NOT Contains $ // we added this

     Category Object StartsWith /Host [ignore case]

The base events fits this, as it has /Authentication/Modify as it's Category Behavior. I guess what I'm trying to figure out is why logging in to the console would fire as Authentication/Modify rather than something like /Authentication/Verify.

0 Likes
Fleet Admiral
Fleet Admiral

Dear Samantha Rorabaugh,

Based on Device Class Event ID, I just checked it

/Modify Category

Only any Changes which occurs/involves in Username,Password and Account Management triggered in modify Category.

Eg:

642    -     User Account Changed.

627    -     Change Password Attempt.

So those things were Default Categories set/Taken by ArcSight Itself it seems.

User logon,Successful logon,logon attempt,login Failure falls in /Verify Category.

User Logoff falls in /Access/Stop Category.

Sorry for the Delay in Reply coz i'm in Operator Level so I Couldn't able to check at the time u asked..

Reply if any other information u want.

Please Check out these link for any clarifications in Windows Device class event ID

http://www.ultimatewindowssecurity.com/securitylog/encyclopedia/default.aspx

0 Likes
Absent Member.
Absent Member.

Thanks for the info - this still doesn't help me figure out why ArcSight would classify a simple login event as Authentication/Modify. There is no change in the username or password, and so that leaves me with "Account Management", which is vague.

In fact, logging in to the console doesn't generate any event other than the Authentication/Modify event - there doesn't appear to be a way to login via the Console and only generate Authentication/Verify.

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.