Has Your Law Firm Been Breached? Here is How To Respond

By: Scott Suhy

Chief Executive Officer at NetWatcher

Category: Cyber Security for Businesses, Law Firm Network Security

This blog post discusses the steps taken by the firm in response to a breach of security. Your firm (no matter the size) should have this contact matrix filled out, communicated and ready to go so you are ready to respond to a security breach.

Using the matrix filled out above, your firm should follow the following step-by-step list to ensure you taking the necessary actions for protecting your firm.

1. The person who discovers the incident will call the HELPDESK contact.
2. HELPDESK will record:
   1. What type of incident is this? E.g. virus, worm, intrusion, abuse, damage
   2. Is the equipment affected business-critical?
   3. What data or property is threatened and how critical is it?
   4. What is the impact on the business, should the attack succeed? Minimal, serious, or critical?
   5. Name of system being targeted, along with operating system, IP address, location, and any additional information about the origin of the attack.
   6. Is the incident real or perceived?
   7. Is the incident still in progress?
   8. Can the incident be quickly contained?
   9. Will the response alert the attacker and do we care?
   10. The name of the caller.
   11. Time of the call.
   12. Contact information about the caller.
   13. What equipment or persons were involved?
   14. How the incident was detected.
   15. When the event was first noticed that supported the idea that the incident occurred.
3. If the issue is or could be real (versus perceived) and the business impact is serious or critical,then HELPDESK will call the INCIDENT RESPONSE COORDINATOR. All security issues should be reported to the INCIDENT RESPONSE COORDINATOR once per day by HELPDESK for review.
   

   Note that you need to provide guidance to your HELPDESK on how to determine if an issue could be real and how to determine if it has business impact.

4. INCIDENT RESPONSE COORDINATOR contacts the INCIDENT RESPONSE TEAM, comprising the following people:
   1. PERSON RESPONSIBLE FOR FIRM’S TECHNICAL SECURITY
   2. PERSON RESPONSIBLE FOR FIRM’S NETWORK, SERVERS and ENDPOINTS
5. INCIDENT RESPONSE TEAM:
   1. Gathers and reviews server logs
   2. Gathers and reviews firewall logs
   3. Gathers and reviews intrusion detection logs
   4. Gathers and reviews SIEM logs
   5. Gathers and reviews endpoint logs
   6. Gathers and reviews email logs (if Phishing was involved)
   7. Gathers and reviews secure web gateway logs
   8. Begins to interview witnesses and the incident victim to determine how the incident was caused.
6. INCIDENT RESPONSE TEAM determines the nature of the attack (this might be different than the initial assessment suggests).
   1. Determine the attack point of origin.
   2. Determine the intent of the attack. Was the attack specifically directed at your organization to acquire specific information, or was it random?
   3. Identify the systems that have been compromised.
   4. Identify the files that have been accessed and determine the sensitivity of those files.
   5. Determine whether unauthorized hardware has been attached to the network or whether there are any signs of unauthorized access through the compromise of physical security controls.
   6. Examine key groups (domain administrators, administrators, and so on) for unauthorized entries.
   7. Search for security assessment or exploitation software. Cracking utilities are often found on compromised systems during evidence gathering.
   8. Look for unauthorized processes or applications currently running or set to run using the startup folders or registry entries.
   9. Search for gaps in, or the absence of, system logs.
   10. Review intrusion detection system logs for signs of intrusion; which systems might have been affected; methods of attack; time and length of attack; and overall extent of potential damage.
   11. Examine other log files for unusual connections; security audit failures; unusual security audit successes; failed logon attempts; attempts to log on to default accounts; activity during nonworking hours; file, directory, and share permission changes; and elevated or changed user permissions.
   12. Compare systems to previously conducted file/system integrity checks. This enables you to identify additions, deletions, modifications, and permission and control modifications to the file system and registry. You can save a lot of time when responding to incidents if you identify exactly what has been compromised and what areas need to be recovered.
   13. Search for sensitive data, such as credit card numbers and employee or customer data, that might have been moved or hidden for future retrieval or modifications. You might also have to check systems for non-business data, illegal copies of software, and e-mail or other records that might assist in an investigation. If there is a possibility of violating privacy or other laws by searching on a system for investigative purposes, you should contact your legal department before you proceed.
   14. Match the performance of suspected systems against their baseline performance levels. This of course presupposes that baselines have been created and properly updated.
7. INCIDENT RESPONSE TEAM categorizes issue into the highest applicable level of one of the following categories:
   1. Category 1 – A threat to public safety or life.
   2. Category 2 – A threat to sensitive data
   3. Category 3 – A threat to computer systems
   4. Category 4 – A disruption of services
8. If the issue is Category 1 or 2, INCIDENT RESPONSE COORDINATOR contacts CXO CONTACT and MANAGEMENT CONTACT and adds them to the INCIDENT RESPONSE TEAM.
9. If the issue is Category 3 or 4, INCIDENT RESPONSE COORDINATOR contacts MANAGEMENT CONTACT and adds them to the INCIDENT RESPONSE TEAM.
10. If the issue is Category 1 or 2, INCIDENT RESPONSE COORDINATOR contacts Forensics, Legal and Insurance contacts.
    

    Note that it is the judgement call of the INCIDENT RESPONSE TEAM if a Category 3 or 4 issue would require Legal and Insurance to be contacted.

    1. CYBER LAWFIRM CONTACT
    2. CYBER INSURANCE CONTACT
    3. CYBER FORENSICS CONTACT

    If the issue is Category 1 or 2, once Legal and Insurance have provided guidance, the INCIDENT RESPONSE TEAM should contact the FBI CONTACT and POLICE CONTACT.

11. INCIDENT RESPONSE TEAM does Evidence Preservation—make copies of logs, email, and other communication. Keep lists of witnesses. Keep evidence as long as necessary to complete prosecution and beyond in case of an appeal.
12. If the issue is Category 1 or 2, once FBI and POLICE have been contacted and have provided guidance,
    1. Segregate all hardware devices suspected of being compromised (if possible) from other business critical devices.
    2. Quarantine instead of deleting.
    3. Restrict Internet traffic to only business critical servers and ports.
    4. Disable remote access capability and wireless access points.
    5. Follow direction  of CYBER FORENSIC CONTACT, CYBER INSURANCE CONTACT and CYBER LAW FIRM CONTACT.
    6. Create and Execute Communications Plan.

    Note: Try to avoid letting attackers know that you are aware of their activities. This can be difficult, because some essential responses might alert attackers.

    Compare the cost of taking the compromised and related systems offline against the risk of continuing operations. In the vast majority of cases, you should immediately take the system off the network. However, you might have service agreements in place that require keeping systems available even with the possibility of further damage occurring. Under these circumstances, you can choose to keep a system online with limited connectivity in order to gather additional evidence during an ongoing attack.

    In some cases, the damage and scope of an incident might be so extensive that you might have to take action that invokes the penalty clauses specified in your service level agreements. In any case, it is very important that the actions you will take in the event of an incident are discussed in advance and outlined in this response plan so that immediate action can be taken when an attack occurs.

13. If the issue is a Category 3 or 4, team members will restore the affected system(s) to its uninfected state. They may do any or more of the following:
    1. Re-install the affected system(s) from scratch and restore data from backups if necessary. Preserve evidence before doing this.
    2. Make users change passwords if necessary.
    3. Ensure the systems are fully patched.
    4. Create and Execute Communications Plan.
14. INCIDENT RESPONSE TEAM assesses the damage to the organization and estimates both the damage cost and the cost of the containment efforts.
    1. Costs due to the loss of competitive edge from the release of proprietary or sensitive information
    2. Legal costs
    3. Labor costs to analyze the breaches, reinstall software, and recover data
    4. Costs relating to system downtime (e.g. lost employee productivity, lost sales, replacement of hardware, software, and other property)
    5. Costs relating to repairing and possibly updating damaged or ineffective physical security measures (e.g. locks, walls, cages)
    6. Other consequential damages such as loss of reputation or customer trust
15. INCIDENT RESPONSE TEAM recommends (documents) changes to prevent the occurrence from happening again. Upon management approval, the changes will be implemented.
16. INCIDENT RESPONSE TEAM reviews response and updates policies—plan and take preventative steps so the intrusion can’t happen again.
    1. Consider whether an additional policy could have prevented the intrusion.
    2. Consider whether a procedure or policy was not followed which allowed the intrusion, and then consider what could be changed to ensure that the procedure or policy is followed in the future.
    3. Was the incident response appropriate? How could it be improved?
    4. Was every appropriate party informed in a timely manner?
    5. Were the incident-response procedures detailed and did they cover the entire situation? How can they be improved?
    6. Have changes been made to prevent a re-infection? Have all systems been patched, systems locked down, passwords changed, anti-virus updated, email policies set, etc.?
    7. Have changes been made to prevent a new and similar infection?
    8. Should any security policies be updated?
    9. What lessons have been learned from this experience?
    10. Was the incident handled in a timely manner?