Open Systems SASE

Network and security are one - without compromise. Our unified SASE service is fast, agile, and delivered from the cloud worldwide.

SASE: The Network of the Future is Here Today

SASE: The Network of the
Future is Here Today

Download eBook

Open Systems XDR

Outcomes. Not Alerts. Open Systems XDR predicts, detects, and responds to cyberthreats with AI that’s backed by real-world security experts 24x7.

3 Reasons to Choose MDR

3 Reasons to Choose MDR

Download Whitepaper

Why Open Systems

Our people, process, and technology work as one to deliver a unified platform, 24x7 operations, and expert advice when you need it most.

Call It

Call It "Sassy" - Gartner Calls
SASE Transformational

View Blog
SASE: The Network of the Future is Here Today

SASE: The Network of the
Future is Here Today

Download eBook

About Open Systems

Open Systems is the global leader in world-class cybersecurity and connectivity from the cloud.

Gartner Report: Voice of the Customer for WAN Edge Infrastructure

Gartner Report: Voice of the Customer for WAN Edge Infrastructure

View Report

Dr. Serge Droz | February 9, 2021

Houston, We Have a Problem: Why a Strong Incident Response Plan Must Go Beyond Alerts

“If you fail to plan, you are planning to fail.” – Benjamin Franklin

Recent Immersive Labs research found that nearly 40% of organizations are not confident their teams could handle a data breach. This is compounded by recent research from Sophos which indicates that 91% of breached enterprises were running up-to-date security stacks. The obvious conclusion is that breaches will occur despite even the most robust cyber defenses.

Given this reality, enterprises must have an incident response plan to ensure that breaches are quickly and comprehensively addressed to minimize their impact. I recently discussed the issue with the Security Experts Circle (SEC.OS), Open Systems’ forum of CISOs for CISOs, and together we identified the following key elements needed to create and operationalize a solid incident response plan built for 21st century threats.

Process

To develop a comprehensive process, you will need to rely on both real-world experience (yours and that of others) and established guidelines and best practices – FIRST.org is a great resource for this. Within the process there are four sub phases:

  • Detect: Using your technology or third party to detect an incident
  • Triage: Verifying if the alert you’ve received is real or not
  • Analyze: Ask questions to develop an overview and understand the context of an alert
  • Respond: Decide what measures to take against the attack

Many companies make the mistake of stopping here. But a very important part of your process is the post-mortem analysis so you can identify and rectify the weakness in your security posture. Failure to do this usually guarantees that you will face the same attack in the future.

(Source: FIRST, December 2020)

 

Step 1: Preparation

For the purpose of quick self-assessment, answer these questions:

  • Who is the incident lead?
  • Who communicates?
  • Who needs to be informed?
  • How do I contact them?
  • What is my out-of-band communication channel?
  • And yes, even: How will my response team be fed in the middle of a crisis?

If you have established a good incident response plan, these questions should be easy to answer. Once the plan is in place, your incident response team needs to practice for an emergency to ensure the plan works properly. Your incident response team, and if possibly management, should go through the steps of an incident in real time, enact the crisis and see how well the plan works.

In the case of a serious breach, all eyes – from the service desk to management to the board – will depend on your team. The effectiveness of your plan and your team will be closely analyzed, so practice in advance, otherwise you’ll be practicing during an actual crisis, which is never a good idea.

FIRST offers free breach workshops to help teams develop and refine their response plans.

Elements of Your Incident Response Plan

The effectiveness of your incident response plan depends on how comprehensively it addresses several critical factors, including:

Communication

Above all, communication remains an important part of every element of your incident response program. If done well, your communication will foster trust and confidence amongst customers, staff, press, and more. Providing clear, concise, timely, and accurate information via trained, knowledgeable spokespeople, will bolster both staff and customer confidence, keep your organization compliant, and help the media report accurately.

A key part of your communication plan also involves what is communicated to the incident response team. Around 50% of all incidents are discovered by third parties before the company realizes it has been breached, so you’ll need to ensure the response team is in the position to receive these reports to react in a timely manner.

Additionally, think of the different communications applications your company uses and make sure to orchestrate how you communicate with all stakeholders during a crisis. This can be particularly challenging given the pace at which information spreads in the age of social media. Consider:

  • Do you have telephone numbers printed out in case you cannot access your digital files?
  • Should you use your private mobile?
  • Do you need to purchase and test additional applications?
  • Are you prepared to address incoming questions on real-time communication platforms like Twitter or WhatsApp?

Leadership

Your incident response program lead doesn’t need to be a senior person, but someone who can project manage effectively and communicate with all stakeholders according to plan. Being the lead doesn’t mean handling each tactic required to implement the plan, e.g. – use a trained spokesperson to talk to the media.

Guidance

After disclosing the breach, give people guidance on what comes next – from your service desk to management, to customers and partners. You do not necessarily need to present a solution but be transparent and share what your next steps are to minimize the impact of the incident. Don’t downplay issues.

Out-of-band

Have a back-up communication system. Some companies use messaging platforms, such as Signal or Threema, as a back-up communication channel. Remember to test your back-up channel(s) regularly to make sure people have it properly configured and that you are positive that confidential messages will remain confidential.

Food

Bigger incidents take time. Think about how to keep people going. Hungry people will most likely not make good decisions, so make sure to take care of your incident response team by supplying them with healthy food and beverages.

Relationships

Know your friends: Establish a relationship with your vendors and suppliers but also with your customers. Talking to them for the first time after a breach is likely to be a challenge and having an established rapport will help. Moreover, make sure they hear about the breach from you – not the press. The loss of trust that comes with the lack of disclosure will likely cost your organization time, money, and reputation.

Compliance

Generally, you are required to inform regulators and customers. Depending on your industry and local/federal laws, additional regulators may need to be informed, and within a certain timeframe. Moreover, know beforehand what you are required to share and if there is any information that you must exclude.

Community

The FIRST community is ready to help you when your company has a crisis with members residing all over the world. Being a member of FIRST or having a security provider who is a FIRST member, like Open Systems, gives you an expertise advantage in connecting with its large member base to learn, network, and share information.

Step 2: Postmortem

Adding this crucial step to your plan will help you move from failure to progress. After dealing with the incident, you are in the prime position to implement changes to your program, based on what has gone wrong during the incident handling. Along the life cycle of your “Learn, Plan, Exercise” framework, use the momentum to debrief with your team and stakeholders and ask again a couple of basic but nevertheless important questions:

  • How did the breach occur?
  • What tool helped us detect the breach?
  • How could we be faster in detecting the incident next time?
  • How quickly and accurately were we able to communicate?
  • Do we need to adjust our process in order to improve efficiency?
  • How are we architecting to ensure this doesn't happen again?

Feed these results right back into your program. Apart from improving your incident response program, this step will help build trust with parties affected by an incident, namely end users, customers, and employees.

As you know, employees are one of the links attackers often use to find a way into your network. You want to foster security awareness amongst your employees, so that they feel safe to raise their hands if they observe strange behavior or receive fishy emails. After a breach, it should not be a company’s goal to find a culprit to blame your incident on. Accept that mistakes happen, learn from them as a team, and improve based on your new knowledge. Punishing employees for accidentally causing a breach will lead to further disclosure and compliance challenges.

Lastly: Some people will have worked overtime during an incident. Take the time to give thanks to them.

Conclusion

While it’s never too late to create an incident response plan, the journey doesn’t end by simply creating the plan. It’s an ongoing process needing constant review, improvement, and communication. Simply having an incident response plan and team in place does not guarantee success, particularly if the team has not tested the plan to verify it works properly. Practice, practice, and more practice will help you refine and optimize your program and ensure that team members fully understand their roles and responsibilities when a breach occurs.

Dr. Serge Droz is the Chair of FIRST (Forum of Incident Response and Security Teams).  He spoke at the Open Systems Security Experts Circle (SEC.OS) Roundtable in December 2020.