Week 42, 2022

New features

Automatic session timeout when idle

Staying logged in when you are not using the app can be a security concern depending on your work environment.

In order to keep you and your sessions safe, we have implemented an automatic timeout if you do not use the interface.

When you remain inactive in the Oort application for 15 min, the idle timeout window will appear. You will be presented with the option to continue the session by clicking โ€œIโ€™m hereโ€ button, or to logout by clicking โ€œLogoutโ€ button. If you donโ€™t respond in 2 min the application will logout automatically.

Support for multiple ticketing services

Some of our customers use several ticketing services in parallel, and dispatch tickets to one or the other depending on the nature of the action, or the team it is going to be assigned to.

Oort now supports using Servicenow and Jira simultaneously. Once both integrations are set up, you can choose which ticketing service to use when opening a new ticket from the actions menu.


UX clarification: Oort audit logs are now labeled โ€œinfoโ€ instead of โ€œsuccessโ€

In order to reduce potential confusion, we have renamed Oort audit logs to โ€œInfoโ€, and turned the icon gray (Instead of a green one labeled โ€œsuccessโ€).

Tooltips for filters

Some of our filters (like checks names) are longer than the filters column width, so those names were truncated, limiting readability.

You can now see the full name of the check in a tooltip by hovering your mouse over the name.

Group names are clickable in changelogs

When performing an investigation, you might end up investigating some groups and recent changes made to them.

In order to make this task just a bit easier, the group names in the group changelogs are now clickable. Clicking on the group name will send you to the users list, filtered to only show you the members of said group. Bug fixes

  • For customers using Okta Log Streaming we set up specific event types (currently user.account.report_suspicious_activity_by_enduser and user.account.privilege.grant) that when spotted in the log stream trigger evaluation of checks automatically, which can send failed check notifications. This is by design to support near real-time alerting.

  • The bug was that if multiple Okta events in the same Log Stream batch matched the specific event types then we would trigger evaluation of checks automatically for each of the Okta events separately, causing a duplicate failed check notifications to be sent. This was fixed so we evaluate checks only once for all the events in the Log Stream batch.

Last updated