Plenty of tools exist for ticketing and tracking during an incident response. This report outlines the main requirements for incident ticketing/tracking tools and walks you through the decision-making process.
Why You Need a Ticketing/Tracking Tool
IR and incident handling can sometimes be a simple thing. A user reports a strange email, suspecting the email to be a phishing attack, right after an awareness training session due to a newfound paranoia. You investigate, mark it as a false positive and close
the incident. For this use case, using a simple spreadsheet to track your incidents will suffice.
But let’s look at another use case where an advanced persistent threat (APT) uses multiple attack vectors and several social engineering attacks, including data exfiltration, installing remote access Trojans, domain controller compromise and encrypting
several servers and critical workstations with ransomware. Email and IP telephony are down, the IR team is gradually growing as the investigation slowly uncovers the sophistication level of this case, and you are calling in a third-party forensics
team to help you get back control of your own infrastructure.
Such an endeavor requires managing multiple pieces of information that can be very complex and sometimes unstructured. During the investigation, the IR team gathers and analyzes evidence from all affected assets and can produce many pages of data as a
result. To ensure the completeness and consistency of the investigation, automated computer software can help track the incident across all the IR stages.
When laying out the requirements for the system, you should consider an incident response tool’s ability to:
- Follow your IR policies and procedures.
- Enable collaboration during the investigation.
- Search previous cases for the tactics, techniques and procedures (TTPs) of the attacker.
- Connect to threat intelligence databases.
- Secure itself and increase its resiliency to attacks. This is very important. The last thing you need during IR is to find out the tools supporting you in these stressful times are rendered unusable due to an attack.
Ticketing/Tracking System Requirements
Your chosen InfoSec ticketing system should, but are not limited to, support the following:
- Tracking, from receipt of incident notification all the way to its resolution.
- Automatic incident processing. The tool should guide the incident responder through all stages of IR, according to your internal IR plan, procedure or playbook. It should also be able to process the incident automatically from trusted information
sources.
- Prioritization, according to your internal guidelines for prioritizing incidents. There might be hundreds or more of daily incident reports, so prioritizing can be a critical point in the whole IR process. Incidents should be prioritized based on
impact on business functions or confidentiality, integrity or availability (CIA) of information, as well as recoverability.
- Secure storage, for all evidence gathered during the investigation as well as outcomes (reports) of the investigation of an incident.
- Search. The tool should support searching in current opened incidents, related incidents as well as historical searching. Data should be immediately indexed and ready for search.
- Visualization. The tool should provide a graphical front end to build dashboard views.
- Incident updates. The tool should support updating incidents by providing additional data or modifying existing data.
- Investigation management. The progress of the incident investigation should follow a logical sequence, performing a series of repeatable steps. This should ensure the right steps are performed in the required order, as well as the completeness of
an investigation.
IR Tool Security Requirements
IR tools are often the target of adversaries. If they get access to them, they will find out what you know about them and what steps are you taking to mitigate their attack. Your incident tracking tools should contain safeguards necessary to prevent unauthorized
modification of information during its processing, storage and transmission. The resiliency of the incident ticketing system must be ensured by implementing the following security practices:
- Secure development. The incident tracking tool should be developed using secure development practices (SDLC) that are thoroughly documented and auditable.
- Vulnerability scanning. The incident tracking tool should be periodically scanned against vulnerabilities using automated testing with manual verification of vulnerabilities by an independent testing party. All vulnerabilities with a score higher
than “low” should be remedied.
- Separate network. The IR capability must have its own physically (preferred) or logically separated network.
- Access control. There should be controls in place to prevent unauthorized access to information during data processing and storage, and access should only be provided after successful identification and authentication. Passwords should be stored as
salted hashes with industry-standard cryptographic strength.
- Multifactor authentication (MFA). This provides an added layer of security.
- Encryption. All communications must be encrypted using widely accepted protocols and key sizes.
- Anonymization. The system should support information anonymization for sharing purposes. It should also enable users to choose what information to anonymize.
- Audit trail. The system should provide an audit trail for activities of incident handlers/investigators to link them to the activities they performed. It should encompass, for example:
- Adding a record, removal of a record, modification of a record, etc.
- Technical events, like exceptions, faults and normal events.
- The modification or deletion of audit trails should not be allowed at the application level. The system should also support:
- Logging of administrators or other superuser accounts.
- Real-time sending of logs to a remote syslog server.
- Time synchronization for timestamping of any key events, including logs/audit trail.
IR Tools to Consider
RTIR
RTIR is an open-source web-based application that can be used in any environment and with any device. It helps manage the whole lifecycle of incidents and allows for customizations and integration with external tools for analysis.
RTIR can correlate key data from incident reports (from people as well as automated tools) to find patterns and link multiple incident reports with a common root cause incident. It is managed by Best Practical, a commercial entity, and is licensed under
the GNU General Public License.
OTRS
OTRS is a commercial ticketing and process management system that allows for automated workflows that are custom designed for security. It can integrate with third-party tools for detection, analysis and monitoring, and it also allows for automated processes
and notifications for quick response. It supports automated security alert processing to inform you immediately about a security breach, and it provides instructions for dealing with it. With OTRS, all incidents and resolution steps are documented,
and comprehensive reports can be produced.
TheHive Project
TheHive is an open-source security incident platform that is integrated with MISP and contains automation of some analytical operations using Cortex, which was built by TheHive and contains several analyzers like VirusTotal, PhishTank, Shodan and many
others. Cortex manages these autonomous tools right inside TheHive and allows for their automation. TheHive supports all six stages of IR, and lets you break down individual cases by tools or by processes in your playbook. It supports logging and
tracking of your incident process, along with the ability to upload indicators of compromise (IoCs) to your case. After adding your IoCs, you can run Cortex and the tools in it to enrich your data using many analyzers and responders.
The best choice for you depends on your budget, security maturity level and the depth of your intended investigations. RTIR and OTRS offer solid incident tracking systems with paid support (as of this writing). On the other hand, TheHive offers high scalability,
customizations and embedded analyzers for quick and automated analysis.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in connection with such information, opinions, or advice.