Windows incident-handling tools:
1. Archer Incident Management tracks incidents and ethics violations in real time, manages the investigation process, tracks incident resolution and monitors the incident status and impact. CSIRT functional need: Manage an incident’s tasks and activities.
2. D3 Incident Reporting and Case Management has two parts. The incident reporting side allows web based fully customizable incident forms, task and analysis reports. They can be customized to your company. CSIRT functional need: Reporting on incidents.
3. Application for Incident Response Teams (AIRT) gives the ability to upload files and attach them to specific incidents. You can receive e-mail and link it to incidents. The import que can receive network and contact information. CSIRT functional need: Communicating incident information.
4. Request Tracker for Incident Response (RTIR) triages incoming incident reports and links them to an ongoing incident or makes a new incident. You can launch investigations to work with other people such as law enforcement. CSIRT functional need: Tracking Incidents.
5. BMC Remedy Action Request System replaces manual systems with process automation which speeds everything up. Notifications, escalations and approvals. CSIRT functional need: Archiving Incidents.
I would recommend using Archer Incident Management because it can double as incident management and tracking incidents. This software does both having one tool that does many things is cost effective. AIRT is great for communicating an incident to everyone involved. When technicians or remote users are in the field it is good to be able to add new information too an incident file. E-mail is good way to communicate any new findings or to get files you may need to compare to other information.
In an enterprise security operations center (SOC) that is mature, analysts tend to spend the most time on the following types of activities:
Alert identification and correlation: Alerts come in to centralized collection platforms for analysis, often originating from firewalls, network and host intrusion detection and prevention tools, malware sandboxing, system and application logs and many more sources. Unfortunately, this initial identification phase requires sifting through an inordinate amount of noise and very often leads to follow-up activities that an analyst must perform.
False positive identification and suppression: For events and patterns we’ve seen before, tuning false positives may be somewhat more streamlined, but determining what is a false positive and what isn’t remains the albatross of event management and analysis.
Initial investigation and triage: Analysts need to investigate activities in the environment to validate legitimate incidents underway. This task is often limited by security and forensic analysts’ availability.
Ticket generation and updates: When an event warrants investigation, tickets need to be opened and assigned to a primary incident response team member who then updates the case as additional details are discovered and vetted.
Report generation: Tools create many reports automatically, while others are assembled after manual investigative steps.
There are several major factors to consider when considering these types of products:
1. Vendor maturity. Some of these products have been around for several years and have installations within large organizations. This factor is especially important for older IR tools, as they pose a much greater risk of disrupting production environments if not vetted by mature teams.
2. Integration partners. This is actually one of the most important considerations, as most of these tools fundamentally rely on the use of APIs to perform automation activities. The more associates an integration partner has in the areas of endpoint security, network security, antimalware, identity management, forensics and so on, the higher the likelihood that integration and ongoing management will go smoothly. Another key integration is with messaging and reporting tools, the most common being help desk ticketing and tracking software.
3. Security information and event management (SIEM) tool alignment. These tools are usually implemented with some sort of defensive motivation, and that often means automating detection, response and investigation tasks and processes. For most large clients, this means integrating with the SIEM tool because that is where all event management is taking place currently. How events are passed among the systems and reported should be considered when reviewing products.
4. Ease of use and implementation. Some of these tools have well-designed and intuitive GUIs. This is critical, as analysts shouldn’t spend an enormous amount of time fumbling through a clumsy interface to perform important actions or looking for information during an incident. Creating and monitoring run books and workflows should be fluid and simple, and team member collaboration should be straightforward. Reporting should also be simple, with a variety of reports available for both technical analysts and executive management.
Security teams are improving at continuous data collection and analytics. They’re starting to employ threat intelligence, too, although this is still an immature market and capability is hampered by a lack of maturity in commercial products as well as a shortage in available skills.
The majority of focus regarding incident response automation currently lies in phase 3, streamlining live response capabilities. These same phases were echoed in a 2015 RSA Conference presentation by James Carder and Jessica Hebenstreit, both formerly of Mayo Clinic, who provided tactical examples of security response automation, such as the following:
• Automated lookups of domain names never seen before (driven by proxy and domain name system logs).
• Automated searches for detected indicators of compromise.
• Automated forensic imaging of disk and memory from a suspect system driven by alerts triggered in network and host-based antimalware platforms and tools.
• Network access controls automatically blocking outbound command and control channels from a suspected system.
Fortunately, many products are emerging that offer help with many of these phases. Vendor products such as Swimlane, Invotas (now FireEye Security Orchestrator), CyberSponse, Phantom, Resilient Systems (now part of IBM), Hexadite and more are facilitating IR automation and security orchestration by integrating with numerous other tools in the environment.