This is part 2 of a two part post on Incident Response Plan for Cyber Attacks. The other post left off at listing the responsibilities that are often assigned to IRT members. Below the list continues:
- The applications used to research the incident
- How to get training on the investigative tools
- Preparing a written report on the event
- How to approach the impacted parties
- The process involved with changing security practices
- The types of equipment that are part of the electronic security defensive effort
- Regular maintenance to ensure systems are patched
- The applications used for accessing the sensitive or confidential property
- The names of the individuals responsible for systems harboring sensitive data
- How systems are monitored for potential insurgencies
- What to do with infected systems (e.g. stop using them but, don’t turn them off)
- What is the contingency plan for a critical system that becomes infected?
- How to report potential gaps in the corporate security effort
- It’s also important to list the regulatory compliance organizations the company falls under. Some industries have electronic security guidelines that must be followed. All of which should be broken out and added to the above list. For example, the company may be required to note specific details that were potentially stolen (e.g. first and last names, social security numbers, credit card numbers, expiration dates, email addresses, medical health information, etc.
- Example Incidents Benefiting from an IRT
- What is important is having a documented process for addressing electronic security thefts and breaches. The above information can be applied to many types of security breaches. In all cases, a member of the IRT should be involved to determine any next steps. Examples of incidents the list can apply to includes:
- DoS and DDoS attacks
- Suspected unauthorized exfiltration of sensitive corporate information
- Excessive port scans
- A firewall breach
- A virus outbreak
- An employee or 3rd party that obtains unauthorized access to a restricted resource
- Stolen or loss equipment that could have been storing sensitive data
Whatever the incident, the incident response procedure outline explains the process for working through the event. Gathering evidence using the in house forensic investigation solution should be documented.
Documentation should be tested and possibly even rehearsed like a fire drill.
Why Incident Response Teams Fail
I think it is important to summarize this post with some reasons why an Incident Response Plan or why a member with an Incident Response Team can fail.
- Commitment: Lack of commitment from the management. Is management getting the right people involved. Are they budgeting to support the Incident Response Plan?
- Process: Lack of detail in the procedure process. Has the Incident Response Team done due diligence and properly documented the follow up and investigative process. Schedule regular fire drill to ensure they have.
- Tools: Poor tools to support the process. Has the IRT evaluated and purchased the right NetFlow and IPFIX collection solution for a forensic threat investigation? What about syslog and event log collection? How long is the data archived? Is it correlated? Can you customize what to alarm on? Create a list of questions that are important to protect your company’s assets and verify.
- Empowerment: Is the IRT suffering from a lack of empowerment to do its job and avoid politics? Can a member of the IRT walk over to any employee without management permission and ask them to use another computer while they investigate the traffic from the suspected system? Can they get changes made on the firewalls without a bunch of red tape?
- Training: Is the Incident Response Team budgeting for yearly training to stay up to date on how to navigate the forensic network investigation solutions they have invested in or are they pointing fingers and putting in requisitions to purchase another solution every 6 months? And are they being properly tested on how to use it?
Download the white paper on Flow based approaches in network management and find out why more people are using flow data for forensic threat investigation.