Cybersecurity 411: Effective Incident Response

This is the fourth in a series of articles to inform multifamily professionals of the current cybersecurity threat-scape and recommend best practices for dealing with these issues. Read part one, two and three. 

Effective incident response

As we have seen earlier in our series, today, there is an assumption of breach. It is the new normal. The questions are: 1) how ready will you be and 2) how quickly can you detect and respond to contain the threat? An effective incident response program should help an organization be able to deal with ransomware, phishing, denial of service and other attacks. This can turn a $10 million incident into a $10 thousand incident.

First, an organization needs a formalized, written Incident Response (IR) plan that spells out who, what and how response will be carried out. Just as with all cybersecurity plans (e.g., business continuity and disaster recovery plans), an IR plan must be tested periodically to ensure its effectiveness and it should be updated with lessons learned after every invocation of the plan.

If we consider the security architecture of a typical multifamily IT enterprise, we can’t think of it as a castle with one controlled entrance but rather as a city with many routes leading in. Wireless communications, removable media (thumb drives, DVDs), e-mail, phones, cloud services and other sources allow holes through the security perimeter, leading to denial-of-service (DOS) attacks, web attacks, spam, phishing, improper resource usage, loss or theft. Being on the lookout for all of these is difficult.

The incident response program must provide visibility into the enterprise IT infrastructure both at the headquarters and property levels. We keep constant diligence for adverse events or “incidents” on the system – that is, things that have a negative consequence, such as:

• System crashes
• Packet floods
• Unauthorized use of system privileges
• Unauthorized access to sensitive data
• Users falling victim to phishing attacks
• Execution of malware that destroys data

Breach Sensors

The sensors that lead us to realize that an incident has taken place include the following: Intrusion Detection Systems (IDS), Security Information and Event Management (SIEM), antivirus software, file integrity checking software, third-party monitoring services, operating system and application logs, network logs and people both inside and outside the organization.

Note that just because a sensor picks up an indicator of attack does not mean an incident has occurred. Trained cybersecurity analysts must make their best judgment based on available information to determine whether to escalate the incident to the next level. This incident escalation is based on:

• Functional Impact. What impact does the incident have on our operations? How difficult will it be to maintain business continuity?
• Informational Impact. What impact does the incident have on our data? How valuable was the data, or what would the fallout be from its compromise?
• Recoverability Impact. How much time will it take to recover?

The Incident Response (IR) team that springs into action upon incident escalation must be named ahead of time. Each person on the team should have a defined role and be aware of what that role is and how to execute the role in the case of an escalated incident. The IR team typically includes the following: chief information officer (CIO), chief information security officer (CISO), information technology (IT) manager, IT cybersecurity engineers/analysts, human resources, public affairs, legal department, external legal counsel, and cyber breach insurance agent.

Communication Efforts

Who gets notified first in the case of an incident, and how they will be notified, should be carefully spelled out in the IR plan. Depending on whom you ask, you will get several differing opinions on whom that should be. For instance, attorneys will always advise to contact legal counsel first, because they can control liability from a legal standpoint. But IT managers would say they need to know first, so that they can contain the incident.

In addition, considering that communications in the enterprise could be compromised due to a breach, the IR Team should consider utilizing out-of-band communications (e.g., third-party email accounts, cell phones, in-person meetings).

The IR Team should establish clear protocols for communications with third parties, such as law enforcement, regulators, affected individuals and suppliers. Legal counsel needs to maintain control and oversight of determining what, if anything, should be communicated and when such communication should occur to these parties. You should consider having all communications go through legal counsel to maintain the privacy and attorney-client privilege of these communications.

In order to contain the incident, the IR plan should include a strategy to accomplish the following:

• Limit potential damage
• Preserve evidence
• Maintain service availability
• Determine time and resources needed to implement strategy
• Evaluate effectiveness of strategy
• Evaluate duration of solution

Containment

As to what actions should be taken for containment, this depends on the incident. In some cases, you may wish to shut down a system, disconnect it from the network, or disable functions.  However, in other cases, you may wish to maintain surveillance, perhaps through redirecting the attacker to a “honey pot” that allows you monitor activity or gather additional evidence.

Some data breach cases require a digital forensic investigation. This must be carefully handled, often under the supervision of a private investigator and include special techniques for evidence-handling. Such investigations require understanding the following:

• The focus of the investigation:
  • Computer/data as fruits of a crime
  • Computer/data as instrument of a crime
  • Computer/data as evidence of a crime
• How did the incident occur?
• What, if any, data or resources were exfiltrated or misused?
• How can we make sure this won’t happen again?

Once an incident is dealt with and contained, the last step an organization should take is to conduct a post-mortem review and add lessons learned into a repository that is referenced for continuous process improvement.

Read part one, two and three. 

Jeremy Rasmussen is chief technology officer & cybersecurity director of Abacode, a company based in Tampa, Fla., that provides all aspects of cybersecurity for growing organizations and employs global thought leaders and industry experts in ethical hacking, digital forensics and corporate governance.