Release Notes
Abstract
Resilient Release Notes (v29.0)
Content
Downloadable version at bottom of this article
Incident Response Platform
Release Notes v29
Release Date: November 2017
Based on a knowledge base of incident response best practices, industry standard frameworks, and regulatory requirements, the Resilient Incident Response Platform helps make incident response efficient and compliant.
FEATURES AND ENHANCEMENTS
The V29 release of the Resilient Incident Response Platform introduces a number of new features and enhancements. All changes and bug fixes from the previous V28.0 to 28.3 releases are included.
The following lists the new features and enhancements:
- Red Hat Linux. The V29 Resilient platform VMware image is based on Red Hat Enterprise Linux (RHEL). Current on-premises customers running the Debian version of the appliance can upgrade to a Debian version of V29 or migrate to the RHEL based platform. Migration tools and documentation are provided. New installations of the V29 Debian based platform are not supported.
- Role based access control. Administrators can create their own roles by assigning specific sets of permissions. The existing Administrator and Master Administrator roles remain, but an administrator can edit or remove them. Please read the Resilient Incident Response Platform Master Administrator Guide before changing the Master Administrator role since it may impact any integrations. If a user is not assigned a role, the default permissions allow the user to be assigned incidents, and to manage incidents when a member or owner. Roles are included in import and export.
- Workflow enhancements:
- Playbook designers can assign workflows to notes, milestones, tasks, attachments, artifacts and data tables. Previously, workflows could only be assigned to incidents.
- Playbook designers can add an existing script to the workflow.
- Playbook designers can use timer events, which allow a workflow to proceed down an alternative path when either a user task is not completed or a message destination does not receive an acknowledgment within a specified time.
- Incident users can view active workflows, as well as suspend, resume and terminate workflows as necessary.
- Script enhancements. Within a script, a user can reference the user or group that caused a rule to run. The user can also access user and group information.
- Notification enhancements:
- Notifications can be sent to email addresses which are not registered as Resilient users.
- The system “defangs” URLs in all fields sent via notification emails to prevent users from inadvertently clicking a malicious link. On-premises customers can exclude legitimate URLs as described in the Resilient Incident Response Platform Master Administrator Guide. SaaS customers can contact Resilient Support.
- Search. Search has been improved by providing the ability to filter search results using object-specific fields. It also provides user specific search history.
- Concurrent editing improvements. Multiple users editing the same incident receive conflict errors only if both users have modified the same fields. If the edits do not conflict, both users’ edits are saved. If there are conflicts, the second user to perform the save is provided with a dialog listing the conflicts and given options as to how to resolve them.
- Navigation enhancements:
- The incident name is added to the browser tab to improve the multi-tab user experience.
- Added the ability to sort, filter and view different columns in the artifacts table for each incident.
- Users can filter the incident list using additional logic for fields.
- When customizing layouts, users can search for fields by API name.
- Other enhancements:
- Administrators can configure user session timeouts on the Organization Settings page.
- Additional identifying information is passed to message destinations to allow an action processor to identify which workflow sent the message.
- Rules support object creation and deletion conditions.
- For API users, the Resilient platform responds with a success code, not an error code, when loading an empty data table.
- Privacy regulation updates. The following regulators were updated in version 29 to incorporate regulatory changes or clarifications:
- Alaska
- Arizona
- California
- District of Columbia
- Florida
- Louisiana
- Montana
- Montana Insurance
- Nebraska
- North Dakota
- Oregon
- Rhode Island
- Vermont
- Washington
- Wisconsin Insurance
CORRECTED ISSUES
Tracking Code | Issue |
DE2011 | Missing "Content-Security-Policy" header. |
DE2116 | List Incidents: Incidents with long, single-line descriptions make the List Incidents table look too wide. |
DE2596 | Inclusive Gateway with no valid outgoing sequence flows causes an Internal Server Error. |
DE2645 | For on-premises customers only. Search is not re-indexed upon a resSystemRestore command. |
DE2731 | Enabled filter doesn't work on the Phases and Tasks page. |
DE2821 | Any connection error causes the custom threat service to be turned off. |
DE2928 | To prevent the Information Leakage-Cross Frame Spoofing issue with older browsers, the Resilient platform prohibits older versions of browsers from connecting. |
DE2929 | Authorization-Auto-complete allowed. |
DE2977 | Unable to allow LDAP users to create incidents. |
DE3033 | Custom Actions Notification message is misleading. |
DE3077 | Last login time is not displayed in User Details page for SAML users. |
DE3142 | Repeated incident listing. Duplicate incidents are listed under certain filter conditions. |
DE3150 | Large number of artifacts freezes the web page. |
DE3175 | Blank list incidents page. |
DE3203 | The Owner field becomes mandatory in the New Incident Wizard when creating an incident. |
DE3281 | The "automatic_tasks" endpoint returns invalid JSON response with extra bracket causing the workflow to display improperly. |
KNOWN ISSUES
Tracking Code | Issue |
DE2946 | Incident History Detail reports can cause the system to run out of memory and become unresponsive. This issue is most likely to occur on systems with thousands of incidents or many custom fields, and systems that have incidents with a very large number of updates. There is no known workaround. |
DE3255 | Resilient version 28 doesn't start correctly if a user stops the scripting service. This would possibly manifest after a failed upgrade from 28 to 29. If the application does not show the Resilient logon page after a failed upgrade, try these steps: sudo service resilient stop sudo service resilient-scripting start sudo service resilient start |
DE3294 | If a user finds a deactivated task in the results of a search, accessing that task results in an error, which is displayed in the console. |
DE3305 | The function 'contains' in an incident owner filter is not working on the global search page. Alternatively, use the "has one of" or "equals" conditions to achieve a similar result. |
DE3324 | Search results may be incorrect once the maximum fields limit is reached. A workaround for on-premises customers only includes increasing the limit, forcing a re-index then restarting the service. The following example shows how to increase the limit to 5000 (default is 2500). sudo resutil configset -key elastic_search.max_fields -ivalue 5000 sudo resutil configset -key elastic_server.init_schema -bvalue true sudo service resilient restart |
Was this topic helpful?
Document Information
Modified date:
19 April 2021
UID
ibm11162324