Morgan Holm

We put you in control of your data – Purging

Cygna solutions are designed to put you in control of your data.  There are other new related features coming soon that will be covered in additional blog articles such as database segmentation and archiving.

Change auditing can generate a lot of data which can make it difficult to find, analyze and retain the events.  Cygna Auditor is designed to overcome these issues in several different ways.

Some activities generate multiple events in the native event logs making it difficult to correlate and figure out what has happened.  Cygna Auditor reduces the volume compared to native logging by combining the data in a single easy to consume plain language event.

Another way to reduce the volume of events is to simply not capture unwanted events in the first place with auditing exclusions.  This feature is described in detail in the Auditing Exclusions section of the Auditing Policies – Cygna Auditor for Active Directory blog article.

Many organizations may prefer a more conservative approach of capturing and then purging events later.  This is a way to control database growth and number of events being retained while providing a configurable window of time to review activities.

Configure Purge Settings

Auditing Purge Rules

The auditing purge rules have flexible configuration options, so you can apply different rules to suit your needs.  For example, you could choose to have a rule that keeps Active Directory (AD) audit events for one year and another rule that keeps VMWare data for 90 days.  Keep in mind that no events or data are set to be purged by default.  Purging rules are designed to be flexible because organizations may have specific internal retention policies or be subject to regulatory compliance mandates based on locale, industry, type of events and data being gathered among other possible requirements.

The purge settings can be found by clicking the Data Purging tile in the vertical configuration tab of the product portal.  The purge configuration section has two tabs, one each for auditing and data purging rules.

 

 

Many organizations have straight forward requirements that are based on how long events and data should be retained.  For an example scenario, I will step through the configuration process for an auditing purge rule of AD data. These type of retention rules are simple to configure as there are built-in template rules by source and time.  You can easily customize these to suit your organization’s needs by clicking on the pencil icon (on the far right) to open the Edit purge rule window.  Once opened, the Rule details tab has fields for the name, description, and a toggle to enable the rule as well as a preview pane of events that would be purged if the rule was enabled and scheduled.  The Add/Remove filters tab is where the event purging criteria is defined.

 

The When filter is mandatory for purging rules to expunge events that are older than x number of days.  The built-in AD purge rule is set to purge AD events older than 365 days.  Adjust the number of days to your organization’s requirements.  You can return to the Rules details tab to see a preview of the events that would be deleted once the rule and purging are enabled.  If the results and rule are to your liking, then save the rule by selecting the save icon in the top right hand of the screen.  You can enable the rule from the same tab or from the Purge configuration page in the Auditing purge rules tab.  Enabling a rule will not start the purging process on its own.  The top level Enable purging toggle must be set to enabled for purging to happen.  Before enabling purging, we recommend that you set your desired schedule for the purge to happen by selecting the clock icon in the top right hand of the Purge configuration page.  The purge schedule has the following options:

Frequency

  • Daily
  • Weekly
  • Bi-Weekly
  • Monthly

Start Date

  • Immediate
  • Specified Time – Calendar picker with date and time options

End Date

  • Immediate

Specified Time – Calendar picker with date and time options

Once set, click on the Apply changes button.  See the following example below.

 

You can also create your own auditing purge rules by clicking on the plus icon in the top right-hand corner of the page or amend existing rules to fit your needs.  For example, you could amend the AD purge rule defined above to not delete events from administrative accounts using the Cygna Identity feature.  The Cygna Identity feature allows you to group multiple users accounts back to a single identity even if they are from different systems that do not share the same identity provider.  See the Cygna Identity Feature blog article for more information on that feature.  In this example, the NA-Admins identity is comprised of the administrative accounts from all domains and untrusted forests.  The condition is set to “is not” so that those events made by any account defined in the identity will not be purged but all other AD events will.  Since these events remain, you could have an additional rule that purges these events from the NA-Admins identity in for example, 2,555 days (7 years).

 

 

Data Purge Rules

The data purge rules apply to the data collected by the Cygna recovery modules.  When enabled they will remove backup data that is older than configured number of days.

 

Best Practices and Considerations

 There are a few considerations and best practices that you should consider before enabling purging.

  1. Data retention, regulatory compliance, laws, and policies that your organization is subject to.
  2. We recommend that a DBA or someone with the SQL knowledge / authority take a full backup of the Cygna Auditor database before purging is enabled.
  3. The purging schedule should start at a time when the Cygna Auditor database is the least busy such as overnight when there should be minimal activity and not when the SQL server is actively backing up.
  4. Initial purge time frame.  If you have been running Cygna Auditor for some time or there is a significant volume of events that you want to purge, this could put a heavy load on SQL.  We would recommend the following approach.  Configure the purge rule to remove a smaller subset of events initially to not put too heavy of a load on the SQL server.  For example, if you only want to retain a year’s worth of data but the solution has been running for 2 years without any purging.  We would recommend that the rule initially be set for events older than 639 days and after the rule has run, change the rule to 548 days.  There are many factors that impact the load on SQL such as the number of events to be purged.  You can set the same filters as the purging rule in the Auditing tab to see how many events would be purged.  The performance and resource availability of the SQL server itself would also greatly impact the purge execution.
Morgan Holm

Auditing Policies – Cygna Auditor for Active Directory

Cygna Auditor for Active Directory auditing policies have two main purposes, to protect objects from being changed or to exclude specified activities from being captured.  These auditing policies are applicable at the domain level in Active Directory (AD) when using agent-based auditing.  Once a policy is configured via the wizard, the agents in that domain will automatically pick up the configuration within a two-minute period and start enforcing the policies.  If no policies or exclusions are configured with agent-based auditing, no objects will be protected, and all events will be captured.

Protection

With Cygna Auditor for Active Directory configured with agent-based auditing you can see all changes to AD.  It is also possible to configure an alert so that you can be notified when a specific change occurs to verify it is valid and does not pose a security risk.  Even though you can follow what is happening in near real time you are still in a reactionary mode.  Protection is designed to prevent unwanted changes to critical objects from even happening in the first place.  With protection there are only specific actions and objects that rules may apply to.  These restrictions are required to not impact the necessary modifications needed by AD to function properly.  Actions on supported objects that can have protection rules are:

  • Deletes
  • Modify events for GPOs
  • Modify or other events for group, contact, printQueue, volume, organizationalUnit, and container object types

A common use is to implement protection auditing policies to prevent changes to critical AD objects such as Enterprise Admins or Domain Admins groups.  Membership in either of these groups gives privileged access to AD and therefore many other systems that leverage AD as their identity provider.  This makes them the target of bad actors looking to elevate privileges to accomplish their nefarious goals.

The place to configure a protection audit policy can be found on the Configuration tab / Active Directory tile / Auditing Policies tile.  Existing policies can also be edited from the manage domain (gear icon) Domain Auditing Policies tab for each domain listed under the Domains tile as well. To launch the wizard to create a new audit policy, select the plus icon in the upper right-hand corner of the Auditing Policies page.

General Page

The General page of the wizard allows you to set the following:

  • enable / disable the policy
  • specify the domain the policy will apply to from the drop-down list
  • name the policy
  • description field

The following example is a protection policy for the Enterprise Admins group.

 

Who Page

The Who page allows you to specify which user accounts the policy does or does not apply to.  If you leave the Who drop-down set as Apply rules to all user accounts, then the policy applies to all.  To select specific users, change the drop-down to Apply rules to the selected user accounts.  If you specify to include one or more users, then the policy only applies to them, and all other users will be inherently exempt.  If you specify to exclude one or more users, then the policy will apply to everyone except them.

For the Enterprise Admin group membership protection example, you can choose to protect that group from membership changes no matter which user is attempting to make the modification (even if they have the native AD permissions to do so) by leaving this setting as Apply rules to all user accounts.  If you want to prevent everyone except a particular user, for example Frank Whitten, you would change the drop-down to Apply rules to the selected user accounts and then add that account and set it as exclude.  That policy would then prevent all users, except Frank from being able to modify group membership on the Enterprise Admins group.  Note that Frank would still require the appropriate native AD permissions to make the change.  The search active directory field allows you to find the desired accounts to include or exclude if so desired.

What Page

The What page of the wizard allows you to define what actions, object classes and attributes the policy will apply to.

  • What (actions)
    • Create, Modify, Remove, Move, Rename and Restore check boxes
  • Object type
    • Match all or only specified object classes
  • Attribute
    • Match all or only specified attributes

For the Enterprise Admins group membership protection example, all actions except create are defined for the member attribute of the group object class.

Where Page

The Where page allows you to specify which objects you want the policy to apply to.  The policy can be set to Apply rule to all objects or to Apply rule to selected objects.  If you change the drop-down to Apply rule to selected objects, then you have two different ways to locate and select the objects.  The Search Active Directory selection provides an auto complete text field that will start returning selectable results in a list below after the first three characters are entered.  This allows for quick selection of one or a few objects or containers. The other option is to select the Browse Active Directory drop-down that allows to see the hierarchical view of containers for the domain. If you specify to include one or more objects, then the policy only applies to them, and all other objects will be inherently exempt.  If you specify to exclude one or more objects, then the policy will apply to all objects except the ones set as exclude.  If a container is selected, then you can choose how the rule will be inherited.  The rule can apply only to the container object itself, child objects or both the container and child objects.

For the Enterprise Admins group membership protection example, select the Apply rule to selected objects and search for and select the Enterprise Admins group.  Since we only want the rule to apply to that group and no others, select the include drop-down.  There is no option for inheritance as this object is not a container.

Actions Page

The Actions page defines what the policy will do when an event that matches the criteria specified on the Who, What, and Where pages is encountered.

In the Auditing section, the Enabled auditing toggle is used to set if audit events that match the criteria of the policy will be captured by the agent writing to the database.  Keep in mind that the default behavior is to capture all audit events so this would be used to turn off auditing, this is covered in more detail in the next section.

The Protection Enforcement section is where the protection policy settings are set as follows:

  • Enable protection
    • If enabled, this will prevent the change form occurring usually returning an Object not found error to the user attempting to make the modification
  • Write a Protection Policy Event to the Microsoft Event Log
    • If enabled, whenever an event matches a protection policy, an event will be written to the Microsoft event log on the domain controller where the change was attempted. This can then be utilized by systems management or security solutions that monitor event logs to trigger an organization’s internal process.
  • Write a Protection Policy Event to Cygna Auditor for AD audit log
    • If enabled this will write a prevention event to the Cygna Auditor for AD log

Once the policy is configured as desired save it and it will take effect in around two minutes.

Auditing Exclusions

The default behavior of Cygna Auditor for AD when using the agent based collection method is that every AD change gets captured regardless of how native auditing is configured.  Some organizations may not want to capture some specific events to minimize the volume of events being captured or simply do not have an interest in capturing certain kinds of events.  If an audit exclusion policy is configured the events do not get written to the SQL database.

If database size or volume of events are an issue, another approach organizations can utilize is the purge feature which would capture the events and then deleted them on a scheduled basis.  This would provide a configurable window of time to review events and if the database is backed up a potential to restore and examine the events if warranted. The purge feature will be covered in more detail another blog.

A common use of this feature is the ability to exclude changes made by a service account for an application such as an identity management solution.  Many of these solutions already track all their own activities and could also make a significant number of changes when syncing with Active Directory.  The policy is configured through the same wizard as the protection policy shown above by selecting the Configuration tab / Active Directory tile / Auditing Policies tile.

General Page

In the General page of the wizard provide an appropriate name and description for the policy.

Who Page

For the Who page, change the scope to Apply rules to the selected user accounts.  For this example, the IDM Service account is selected and set to include so that the rule only applies to events made by that service account.

What Page

For this particular use case on the What page check all the actions (Create, Modify, Remove, Move, Rename, Restore) as we want this audit exclusion to apply to all actions, object types and attributes that are being modified by the IDM service account.

Where Page

In the Where page we want the exclusion to apply to whole domain, so no configuration is required.

Actions Page

For the Actions page we want to turn the toggle off for Enabled auditing as we do not want events captured for the IDM service account.

Save the policy and it will take effect in around two minutes.

Once an audit policy has been completed it will appear on the Auditing Policies page.

 

Morgan Holm

Configure PBMS as a Data Source in Cygna Auditor

Since Cygna Labs took over the BeyondTrust Auditor Suite (PowerBroker Management Suite) at the beginning of this year we have taken on support, maintenance, and enhancements for the products. We are uniquely positioned to do this because we are the same group of industry veterans who also developed the Blackbird Management Suite, which was acquired by BeyondTrust in 2012.
Our main goal is to provide a smooth transition for those customers over to the Cygna organization and products. To that end we have recently released an updated version of Cygna Auditor that integrates PowerBroker Management Suite (PBMS) as data source in the Cygna Auditor global reporting feature. This provides the ability to view and filter PBMS data combined with many other sources such as Office / Microsoft 365 in a simple yet powerful web-based console.
The process to setup this configuration is straightforward.

 

Select PowerBroker Management Suite Tile

  • From the Cygna Auditor Configuration page Select the PowerBroker Management Suite tile.

 

Configure PowerBroker Management Suite

 

 

Configure PBMS Connection Properties

  • Enter the database server name and instance (if not default) for the existing PBMS database
  • Select the SQL authentication type and enter an account and password that has access to the PBMS database
  • Select the name of the PBMS database under Initial Catalog
  • Typically there is no need to adjust timeout or retry setting values
  • Push the Verify connection string button to confirm the settings are correct and if so, then select the Save button

 

PowerBroker Management Suite Database Connection Settings

 

PBMS Dashboard Elements

  • Once connected, a PBMS tile will be added under Events by Source and there will be a Top PBMS AD Users chart

 

PowerBroker Management Suite Dashboard Elements

 

PBMS Events

  • PBMS audit events now appear in the interactive audit views and can be saved in reports
  • You can specify the audit sources of interest

 

PowerBroker Management Suite Event Source

 

 

  • The PBMS audit events appear among audit events from other sources including Microsoft 365
  • The displayed events can be focused to only return the desired audit data across specified sources greatly simplifying your auditing efforts

 

PowerBroker Management Suite Events in Cygna Auditor Global Reporting

 

Arno Therburg

The threat from within – Who supervises the supervisor?

All organizations constantly worry about external attackers, but truth to be told is that most threats these days come from malicious insiders. This is something that most organizations are not prepared to handle.

That insider could be your trusted colleague sitting across the desk from you, and that person may or may not even know he or she is a threat.

Read more…

Arno Therburg

The IT Audit – Ready or Not – Here I come…

Monday morning 8:15, you start feeling that weird sense of guilt and nervousness, you feel the beads of sweat forming on your forehead, 15 minutes left before the auditor arrives…

You ask yourself – “How long could this possibly take? What are they looking for? What if I can’t provide the answers to all their questions? Should I look for a plane ticket to a faraway country where they don’t have an extradition treaty?”

Read more…