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.

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.

Cygna Identity Feature

Organizations are moving some of their workloads to the cloud and embracing SaaS solutions like never before.  However, most organizations will still have key workloads on-prem for some time due to the cost, effort or regulatory / residency issues.  This all results in organizations having a multitude of systems and applications that do not share a single identity store. Since some of these systems are required to be separated due to regulatory or geopolitical reasons, a single admin or user may have numerous separate user accounts to manage or use these systems.

The 2.0 release of Cygna Auditor introduces a new feature called Cygna Identity to unify these accounts from an audit perspective. This feature provides the ability to group multiple user accounts from hybrid and multi cloud systems to a single searchable identity.  The Cygna Identity feature enables organizations to quickly see an individual’s activities across multiple accounts or to create groups of accounts that span across identity stores.

Configure Cygna Identity

The Cygna Identities feature is configured through a tile on the Tools screen.

Once opened, selecting the plus icon allows you to manually create a Cygna Identity and map the desired accounts to it.

• Display Name – Name used in the identity field to perform searches.
• Description – Additional information to describe the Cygna Identity.
• Search users – Interactive search field to find accounts to map to the identity being created.

Once saved individual mapped accounts can be toggled on or off or deleted to be removed from association with the identity.

Identity Search

The Identity name filter allows for quick searches and reports based on the defined identities.  When the filter is applied, it will return all the audit activities of the user accounts enabled for the specified identity greatly simplifying and speeding up the search and reporting process.

You can also customize the grid view and add the Identity name column to the view.

Schedule Identity Search

An identity search analyzes user accounts with audit activity from connected AD and AAD sources to automatically create identity mappings.  The job analyzes user accounts with similar UPNs.  Depending on configurations, UPNs may not be similar across AAD and AD even when using AD Connect for account synchronization so another method is also used, matching SIDs.

This task can be run one time or on a flexible recurring schedule.

Active Directory is dead, long live Active Directory

If you were to look at topics being covered at Microsoft’s conferences, announcements, or social media one could easily assume that Active Directory (AD) is dead.  It is correct that many organizations are embracing SaaS solutions and are going through digital transformations.  While all of this is true, we are still at the beginning of the process that will take a long time to get the majority of workloads and organizations to become cloud only.  You only need to look at mainframe usage and that Windows XP still comprises ~ 1.6% of PC operating systems to understand that organizations resist changes and computing paradigm shifts can take decades, and some things won’t change.

There is no question that the move to cloud is well underway and is accelerating.  This means that a hybrid and multi cloud systems are the reality for most and will be for some time with AD as the primary identity store.  Many organizations use AD Connect to sync their on-prem users to Azure Active Directory (AAD) for Office / Microsoft 365 (M365).  All of this means that you still need to keep track of what is happening in AD to make sure is stays secure.  Recent cyber attacks, namely the Solarwinds breach got bad actors into on-prem systems where they moved laterally, elevated permissions to eventually gained access to M365 resources.

Cygna Auditor has the flexibility to gather events with or without an agent from both trusted and untrusted forests while also allowing you to control where and how long the audit data is kept.  Monitoring AD changes alone will not be sufficient to maintain security and availability in a hybrid system.  You will also need to closely keep track of activities of your cloud connected systems.  Even though AD has been around for a long time, your auditing solution doesn’t need to be dated as well.  We are running a limited time campaign for you to Switch to Cygna Auditor.  Ask us to see what a modern hybrid auditing solution can do for your organization.

Cygna Auditor SIEM Event Forwarding

Cygna Auditor can now forward events to SIEM systems in a standard syslog format or in a structured view to Splunk. Cygna Auditor events are presented in plain language which greatly simplifies the understanding and consumption of the audit information.  This enables operational and security teams to work efficiently and make decisions and react quickly.

Structured View

The structured view for Splunk normalizes the audit data in the SIEM views by the Detail (expandable list of the modification), Item (object/attribute that was changed), Source (system or platform of modification), Success (if the action succeeded or failed), What (the object/attribute that was changed) When (timestamp), Where (the system where the change was applied), Who (account that made the change).

In the following example, the expandable Detail node provides the GPO setting that was modified with both the old and new values.

Native Windows Event in SIEM

The following is a native GPO change event imported into a SIEM from the Windows Event Logs.  There is a substantial amount of text to sift through to try to understand what has occurred.  Since the friendly name of the GPO is not shown you would either have to know the GUID or do a search to find out which GPO was modified.  This also does not show you what has changed.  You would need to have a previously exported GPO report prior to the change and manually compare the settings with the current version.  Needless to say, this would be a very time-consuming task.

Cygna Auditor provides SIEM systems a data translation layer service that converts non-human readable raw log data into plain language values as they occur.

Configure Splunk for Structured Cygna Events

To send Cygna structured events to Splunk you will need to configure an HTTP Event Collector.  For more information on this topic please select the following Splunk documentation link or see the following example configuration.

The first thing you need to ensure the HTTP event collector is enabled in Splunk UI through:

1. Settings -> Data Inputs
2. HTTP Event Collector
3. Global Settings

Make sure it is enabled and make note of the port #.

The second step is to create an Event Collector token:

1. Settings -> Add Data
2. Monitor
3. HTTP Event Collector

For the Source Type under Input Settings step, make sure you pick  Select and then in the Select Source Type dropdown pick Structured  _json

Once the configuration is saved you will see a token value that will be required to configure the connection to Splunk from the Cygna server.

Configure Cygna Server to Send Structured Events to Splunk

 Enable Remote Logging

From the Cygna Server UI:

1. Configuration -> System
2. Select Remote Logging tab in the System Configuration window
3. Change the type drop down to Splunk
4. Enter the URL for the Splunk HTTP Collector with port#
5. Enter the Splunk HTTP Event Collector Token Value
6. Ensure the message format is set to JSON
7. Save the configuration

Configure Which Events to Forward

Once both Cygna and Splunk have been configured to be able to send and receive events you can decide what events you want to send.  This is done through alert remote logging on the Cygna server.

Enable Event Forwarding

Cygna events can be forwarded to SIEM systems through the alerting feature in Cygna reports.  The alerts events can be sent via email notification or through remote logging to SIEM systems or both.

From the Cygna Server UI:

1. Reports
2. Alert settings

(a) For existing reports, select its menu icon (hamburger) and then Alerts and enable the toggle

(b) When creating a new report under the Manage alert settings tab choose Remote Logging and enable the toggle

Once the alert is saved any event matching the filtering criteria will be sent to the SIEM system defined in the Cygna Remote Logging configuration.

Cygna Labs Adds SIEM Event Forwarding and Identity Grouping Features to Cygna Auditor Version 2.0

Cygna Labs releases a new version of Cygna Auditor (v 2.0.380) that implements event forwarding to SIEM systems as well as an account mapping feature that allows for the grouping of an individual’s user accounts from multiple on-prem and cloud systems to a searchable identity.

SIEM Forwarding

The need for organizations to understand what is happening in their on-prem and cloud environments has become increasingly important to detect insider threats, breaches, and cyber-attacks. Auditing and alerting on suspicious activities are critical to aid in detection and to minimize the impact. The newest release of Cygna Auditor adds the ability to forward plain language events to SIEM systems in a standard syslog format or structured view. This simplifies the understanding and consumption of the audit information for operational and security teams to make decisions and react quickly. The structured view normalizes the audit data in the SIEM by the who (account that made the change), what (the object/attribute that was changed with before and after values), where (the system where the change was applied) and when (the time the change was made).  Essentially Cygna Auditor provides SIEM systems a data translation layer service that converts non-human readable raw log data into plain language values as they occur.

Cygna Identity

Many organizations have a multitude of systems and applications that do not share a single identity store. Some systems are required to be separate due to regulatory or geopolitical reasons and as such, a single admin or user may have numerous separate user accounts to use or manage these systems. The new 2.0 release of Cygna Auditor has a new feature called Cygna Identity to unify these accounts. This feature provides the ability to group multiple user accounts from hybrid and multi cloud systems to a single searchable identity. No other auditing solution currently provides a single view of the individual’s activities across these separate accounts.  The new Cygna Identity feature enables organizations to quickly see an individual’s activities across multiple accounts.

Additional 2.0 Features

• PBMS Connector AD Delegation and Scoping
  • Active Directory delegation and scoping will now also apply to AD audit data from the PBMS connector
• RSAT Extensions (Remote Server Administration Tools)
  • Integration into ADUC and GPMC consoles to be able to launch a Cygna audit trail or perform a rollback from these native administration tools through context sensitive menu options
• Daily Status Emails
  • Anonymized system status emails that can be sent to administrators, integrators or partners to inform on high level system function and performance

Stay tuned for additional blog posts that will go into greater detail on the SIEM forwarding and Cygna Identity features.

Delegation in Cygna Auditor

The Cygna Labs platform allows you to view and combine audit information from across your hybrid multi-cloud systems in a single web console. Depending on your organization’s administration model, regulatory compliance, or policies, you may need to limit user access and actions. Delegation should limit users to perform specific activities on only the information they are allowed to work with that is necessary to perform their jobs.

The Cygna Labs platform has implemented a role-based access control (RBAC) delegation model to control access and permissions to the base platform and product modules. Roles are defined by combining only the necessary sets of permissions needed to perform common tasks in organizational job functions. Groups and or users are then assigned to the roles allowing them to perform these tasks. There is also the ability to define scope for groups and or users assigned to the role to create a boundary for data and actions. This approach minimizes the need to create additional duplicate roles or reports that only differ in scope. The role defines the permissions for its members to perform the designated actions. The scope set to the user or group when assigning them to the role that defines where, or on what data, they can perform them on. If no scope is set on the users or groups assigned to the roles, they will be able to perform those actions against the complete dataset that is configured for the Cygna product module. Scope assignments are hierarchical (when applicable) and are inherited by all child items. Built-in reports will have fixed role permissions set out of the box but will also allow list and execute permissions to be set directly.

Common Permission Sets

• Full Control (all permissions)
• List (read)
• Create (write)
• Execute (open)

Role Based Access Control (RBAC)

Each module has the following basic RBAC roles defined with its own actions, data types and scope boundaries.  The delegation model accommodates for additional built-in roles to be added in the future and for user defined roles.  Built-in roles are not end user customizable.  However, custom roles can be created by owners from scratch or built-in roles can be cloned to speed up and simplify the configuration process.

• Owner of module – Allows you to manage everything, including access to resources
  • Permissions:
    • Full control for the module
  • Manages:
    • Access and scope
    • Module settings
    • Module data
• Contributor – Allows you to perform most actions except for core module configuration and granting access / scope to resources
  • Permissions:
    • List
    • Create
    • Execute
  • Actions on:
    • Module specific data
    • Module specific tasks
• Reader – Allows you to view everything, but not make any changes
  • Permissions:
    • List
    • Execute
  • Actions on:
    • Module specific data
    • Module specific tasks

Example Delegation Scenario

NA Auditors group is added to the Active Directory – Reader role with a scope defined to the North America OU.  EU Auditors group is added to the Active Directory – Reader role with a scope defined to EMEA OU.  User (A) is a member of the NA Auditors group.  They would be able to see the list of Active Directory reports.  If they run the All Active Directory Changes report they would see all AD changes but only for their scoped OU of North America.  User (B) is a member of the EU Auditors group.  They would be able to see the list of Active Directory reports.  If they run the All Active Directory Changes report they would see all AD changes but only for their scoped OU of EMEA.

Scenario Delegation Configuration

Delegation is available under the Configuration view. Select the Delegation tile to configure.

There are two tiles under Delegation, Roles and Role Assignment.

The Roles tile contains the built-in roles and allows you to add + a new role or select the hamburger icon ≡ to the right of an existing role to clone it.

To add a user or group to a role, select the Role Assignment tile under Delegation.  Once open, select the desired role for assignment from the Select a role drop-down list of available roles.  For the example scenario, select the Active Directory – Reader role.

To select the role assignment target type, select the Assign access to drop down list.  For the example scenario select Group.

The role assignment configuration options should currently look like the following.

To configure a scope for the role assignment, select the Add/Remove scope tab on the top before saving the role assignment.  The appropriate data source for the role is shown.  For the example scenario expand the desired Active Directory domain and select the North America OU and click on the Add scope button.

Once the scope has been added, click the Save button to finish the role assignment.  For the example scenario the same process would be followed for the second role assignment except the group selected would be the EU Auditors and the OU selected would be EMEA.  Now users that are members of those groups will be limited to audit data for their respective scoped OUs for both ADHOC searches and built-in reports.

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

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

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

• 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

Cloud Computing Demystified – Part 3

Cloud Computing (Part 3) – The Risks & Challenges

In the previous blog, Cloud Computing Demystified – Part 2 – The Benefits, we discussed the benefits of cloud computing, and there are many, but we also need to be aware of the challenges and risks associated with cloud computing.

If you didn’t read the previous blog, check it out at:  https://cygnalabs.com/en/blog/

Most of these challenges and risks can be addressed and mitigated through proper planning, and due diligence.

Again, just like in the previous two blogs, keep in mind, this is with a focus on the larger cloud providers, such as Amazon Web Services, Microsoft Azure, Google Cloud and so on, with smaller providers you will experience different risks & challenges to some extent.

So, let’s jump in and discuss these risks and challenges…

Risks of cloud computing

Before considering cloud computing technology, it is important to understand the risks involved when moving your business into the cloud. You should carry out a risk assessment before any control is handed over to a service provider.

Below are a few of the major points to be aware of:

Privacy agreement and service level agreement

You need to have suitable agreements in place with your service providers before services commence. This will protect you against certain risks and outline the responsibilities of each party in the form of a service level agreement (SLA). You should read the SLA and ensure that you understand what you are agreeing to before you sign. Make sure that you understand the responsibilities of the service provider, as well as your own obligations.

An SLA serves as both the blueprint and warranty for cloud computing and should act as a guide for handling potential problems, such as lawsuits.

It’s a tool for protecting the stability of the service and protecting the assets of the company and minimizing the expense should drastic actions be required.

Security and data protection

You must consider how your data will be stored and secured when outsourcing to a third party. This should be outlined in the agreement with your service provider and must address mitigations to governance and security risks. It must cover who has access to the data and the security measures in place to protect your data.

Location of data

Cloud computing service providers could be in a different country. Before committing, you should investigate where your data is being stored and which privacy and security laws will apply to the data.

Legislation and regulation

You will need to be aware of legislative and regulatory requirements when storing personal data. If the data is being stored outside of your country (e.g. if your business uses an overseas service provider), you will also need to be aware of the legislation and regulation requirements in that geographic location.

Biggest Challenges of cloud computing

Cloud computing makes accessing data and applications more reliable and efficient, with less administrative effort. It’s used to enable global access to mutual pools of resources such as services, apps, data, servers, and computer networks.

It’s the choice for many businesses and organizations, since it’s very scalable and in a lot of cases makes perfect financial sense for these companies. It also provides less of a need for worrying about business continuity planning, availability, upgrades and so on.

However, the on-demand and scalable nature of cloud computing services sometimes makes it difficult to define and project quantities and costs.

There are challenges involved in cloud computing, but if you’re aware of what they are, and address them, you will be able to reap the benefits.

Cost

Cloud computing itself is affordable but tuning the platform according to the company’s needs can be expensive.

Even if you host your data and systems off-site, there are internal labor costs, as you scale up to handle workload, there’s a complexity with managing large numbers of cloud instances, just like managing large number of servers.

Furthermore, the expense of transferring the data to public clouds can prove to be a problem for short-lived and small-scale projects. It can cost tens of thousands of dollars per year to move large volumes of data to public cloud services and to store that data for long periods of time.

Long-term data storage in the cloud can be a significant cost. You pay for it every month, and if you consider data growth over the next few years, the life cycle cost of data can be quite high when stored in the cloud.

Although companies can save some money on system maintenance, management, and acquisitions, they also must invest in additional bandwidth, and the absence of routine control in an infinitely scalable computing platform can increase costs.

Network bandwidth accounts for much of the cost of moving data, cloud providers might charge upload and download fees.

Also, cloud data backup is expensive, could be as much as three to four times what it would cost to keep data internally.

Lack of Cloud Specialists

Organizations are increasingly placing more workloads in the cloud while cloud technologies continue to rapidly advance. Due to these factors organizations are having a hard time keeping up with the tools. Also, the need for expertise continues to grow.

Small and medium-sized enterprises without cloud computing expertise lose more than $258 million annually, according to a Rackspace and London School of Economics and Political Science report. Around 65% of IT pros said the cloud skills gap is hurting innovation and creativity.

Organizations may find adding cloud specialists to their IT teams to be prohibitively costly. Luckily, many common tasks performed by these specialists can be automated.

Governance & Control

IT governance policies are critical to ensure that agreed upon policies and procedures are being followed when implementing new IT assets, to make sure they are properly controlled and maintained, supporting your organizations strategy and business goals.

In cloud-based environments, in some cases, IT departments do not always have full control over the provisioning, de-provisioning and operations of infrastructure.

This results in increased difficulties to provide the governance, compliance and risk management required.

To mitigate the various risks and uncertainties in transitioning to the cloud, IT must adapt its traditional IT governance and control processes to include the cloud.  To this effect the role of central IT teams in the cloud has been evolving over the last few years. Along with business units, central IT is increasingly playing a role in selecting, brokering, and governing cloud services. On top of this, third-party cloud computing/management providers are progressively providing governance support and best practices.

Password Security

Industrious password supervision plays a vital role in cloud security. However, the more people you have accessing your cloud account, the less secure it is. Anybody aware of your passwords will be able to access the information you store there.

Businesses should employ multi-factor authentication and make sure that passwords are protected and altered regularly, particularly when staff members leave. Access rights related to passwords and usernames should only be allocated to those who require them.

Security issues

If a company outsources the processing or storage of data that it is required to protect, then it is relying on a cloud service provider to maintain their compliance.

When you’re auditing a cloud service provider’s security and privacy laws, make sure to also confirm the third biggest issue is taken care of: compliance.

Your organization needs to be able to comply with regulations and standards, no matter where your data is stored.

Conclusion (Cloud Computing Part 1 -3)

In my humble opinion – Cloud computing is here to stay, the benefits are so many, and if you only do your due diligence, the benefits greatly exceed the concerns, with its flexibility, scalability, and ease of adoption.

There’s no longer a need for businesses to buy their own hardware, build and maintain their own data centers, having to deal with costly server maintenance, or worrying about business continuity planning and disaster recovery, all this while having the opportunity of the flexibility to scale up or down overnight.

For startups and small to medium sized businesses (SMEs), having the ability to quickly adopt to new circumstances such as growing business opportunities, or during slower business periods is especially beneficial.

File Server security (Part 3) – Securing your Windows File Servers

In the two previous parts of “File Server Security” (1-2), we looked at ways for you to physically secure your files servers, making it more difficult for perps to get physical access to your servers and the data, but if they still would, we would surely make them sweat a little bit before they could “enjoy” it.

We also looked at ways to minimize the attack surface by utilizing firewalls, avoiding internet connections, getting rid of unnecessary software, stopping services, malware protection and so on…

In this third and final part of “File Server Security”, we will put the final touch on our file server security recipe, for now…

Read more…