Week 7, 2024

We are back this week after an exciting time at Cisco Live. This week's release brings new checks, filters around failing integration checks, and more. Read on to learn more about the features and updates our engineering team has released this week.

Impossible Travel Check Explainability Improvements

In the previous release, we introduced enhancements to improve check explainability for β€˜Sign-in from Recently Created IDP,’ β€˜Activity from Untrustworthy ISP,’ and β€˜Registered Location Mismatch.’ In this release, we are extending the same improvements to our β€˜Impossible Travel’ check. Now, you will notice attributes that were previously presented as raw JSON are parsed, and some of these attributes are now filterable. Similar to our other checks, clicking on the filterable fields enables you to pivot to the respective filtered activity screen for further investigation.

All those explainability improvements ensure that performing a deep investigation is always fast and easy, to reduce your workload and time to resolution.

Inactive Guest User Check Improvements

A key aspect of evaluating guest accounts in your environment is understanding the extent of their access. In this release, we are enhancing visibility in the explainability drawer for the β€˜Inactive Guest User’ check to provide more clarity. In addition to β€˜Providing Failing Check’ attribute, we now populate β€˜Assigned Applications’ and β€˜Groups,’ invaluable for assessing the risk associated with the inactive guest account and making informed decisions about their presence in your environment.

New Check: Shared Mailbox Sign In Enabled

Shared Mailboxes serve various purposes within an organization. What may come as a surprise is that these mailboxes have sign-in capabilities enabled by default when created in Entra. The β€˜Shared Mailbox Sign-in Enabled’ check detects when a shared mailbox has interactive log-in enabled. This is crucial because shared mailboxes are often targeted by adversaries as they typically do not have Multi-Factor Authentication (MFA) configured, leaving them vulnerable.

If a user fails this check, it is important to ensure the mailbox is intended to have interactive logins enabled. If it is unexpected, it is best to adjust the settings to disable sign-ins for the shared mailbox.

New Check: Weak MFA Manually Activated and Utilized check

As we know adversaries often bypass security defenses by utilizing social engineering techniques to persuade service desk employees into changing or adding new targeted account Multi-Factor Authentication (MFA) methods, we’ve introduced the check β€˜Weak MFA Manually Activated and Utilized’ to alert when there is successful access from newly registered SMS factor.

By default, the evaluation period is 7 days, monitoring if the MFA method is used within this timeframe. You can easily adjust the period based on your policies via Check Settings.

For more detailed insight into changes to the users’ MFA method, you can find additional context in the explainability drawer when selecting a failing user. This information provides details such as the admin that added the factor, which applications were accessed with the new factor when the factor was enrolled, and more. Having access to this information is crucial for investigating whether the user initiated the request to change their MFA and if the phone number associated is recognized by them.

Failing Users Per Integration Filter

On event-based and some state-based checks, you will now see a new card called β€˜Failing Users Per Integrations’. As you can see in the β€˜Failing Users’ card above we show the number of users failing this check. The β€˜Failing Users Per Integrations’ card takes that a step further and gives you further visibility with a breakdown of the users failing by integration. This insight is helpful if you are focusing on a particular integration, and to better understand where to focus to improve your overall organization posture.

Selecting one of the integrations will direct you to the β€˜Users’ tab with the list of users that allows you to further drill down and investigate the users failing the respective check.

Bug Fixes and Minor Improvements

  • Sensitive apps widget. Bug fix around error thrown when clicking on the legend of the sensitive apps' widget.

  • Quarantine Remediation Sources. Bug fix around additional unsupported sources populating when selecting the β€˜Quarantine’ Remediation action. Action will now only show Okta as it is the only supported source.

Last updated