Which Team Is Responsible for Debriefing After a Cyber Attack?

So, the company you work at had just figured out that a cyber attack had just occurred. You’ve probably heard about the attack from your team lead – and now you’re figuring out what to do to contain the damage and fix the underlying issues. Before you go about fixing them, though, you might wonder – which team in the company will be responsible for doing the debriefing after a cyber attack?

For the sake of simplicity, let’s assume the company is rather small (< 100 people) and the underlying structure within the company is something along those lines:

• Management team
• Software engineering team
• Security team
• Marketing team

Some companies might also have a support team, or a team of database administrators as well – the goals of these two teams would be to provide support for underlying issues within the product and (or) build out features or manage the underlying databases to ensure they’re not causing problems. Either way, in many cases, everything would look like so:

1. Someone from the security or software engineering teams becomes aware of a possible attack on the infrastructure of the company.
2. The person that has become aware of the cyber attack informs his or her colleagues within the team.
3. The issue is escalated to management and the management team of the company is briefed about what has just occurred.
4. The management team gives directions on what to do.

After these initial steps have been completed, the first person in line to respond to such attacks or to be briefed would probably be the CSO or CISO – he would need accurate information in regards to the “scene” of the incident in order to evaluate it.

Once that’s done and the parts of the application where an incident is likely to have occurred are identified, everything is likely to be forwarded to the security team.

Once the security team would possess this information, the security engineers would likely work together with software engineers on one main goal: working on the part of the application where an incident is likely to have occurred in order to make sure that the flaw that has been exploited doesn’t take place ever again. In many (not all, but let’s assume) cases the attack would be the direct result of a SQL injection vulnerability in the application being exploited – as such, the software engineering team would immediately look at any and all queries that are sent to the database and try their best to refine them such that the input provided by the user doesn’t ever reach the database without being sanitized.

Once done, the software engineers would likely report back to the security engineers that would be responsible for the initial debriefing of the incident to management (after all, the approval of all of the decisions within the company is up to management as well.)

Debriefing After a Cyber Attack

Once the security engineers would possess information about the attack, they would go on and provide their initial debriefing to management. Here’s what the debriefing would likely contain:

• A brief explanation of the incident that is likely to have occurred.
• Preliminary reasoning as to why the cyber attack was successful/unsuccessful.
• If there’s sufficient information to believe that the cyber attack was mounted successfully, a brief explanation of the procedures used to contain the incident.
• A brief list of temporary preventative measures that have been taken (e.g. restricting access to parts of a website, etc.)
• A summary of the incident.

Once the aforementioned information is in the hands of management, it would be up to them to decide what to do and how to act next. The management would likely elevate this issue to the CEO of the company and tell him what’s happened – the CEO, on the other hand, would likely talk to the CISO and the security engineers as well, and then present a briefing of what has occurred in the meeting of the team (some teams meet daily, some weekly, some bi-weekly… it all depends on the company.) The briefing would likely not be long – the CEO would have a point to make that would be something along the lines of “the company cannot afford a data breach – we need to step up our game in the security space” and tell the software engineers in the company to write code according to the security standards outlined by OWASP or other vendors.

Depending on the size of the company, after the meeting, the security engineers would also likely have a word with the CEO or their team lead and would probably be encouraged to look for solutions in the security space that can keep them all safe from cyber attacks both now and in the future and to present them all to the team in the upcoming meeting.

Data Breach Search Engines

One of such solutions would very likely be data breach search engines such as the one provided by BreachDirectory – the security engineering team lead would likely be interested in the API functionalities provided by the data breach search engines since the data breach search engine itself would only let people search for one or a couple of accounts at a time.

Data breach search engine APIs are not all built equal too, though – some might allow people to run bulk searches by providing a text file with a list of accounts (see below), some might not, and some might not even search through all of the data breaches in the system at once.

The security team would need to compare their needs with the problems solved by the data breach search engine API capabilities and decide for themselves. In order to evaluate the capabilities posed by data breach search engine API solutions, the people in the team would likely turn to the documentation of the API. In BreachDirectory, the documentation looks like the following:

The security engineers would need to weigh all „for“ and „against“ options when choosing what security solution to employ, and once they‘ve chosen the API, they would most likely forward some information to software engineers that would then assist in implementing the data breach API into the company infrastructure.

As a result of the data breach API implementation, the company would have access to tens of billions of rows of breached data and the ability to scan through all of the data at once – such a piece of functionality would be very easy to implement into any application or website, then utilized for OSINT purposes or to inform customers once their account information is likely to be at risk.

The success of data breach search engines, though, would be directly dependent on the actions initially performed by security and software engineers within the company – if they‘ve chosen correctly, there shouldn‘t be many issues!

Summary

The teams that would most likely be responsible for the initial debriefing after a cyber attack would be software engineers and security engineers that would forward information to the management team. The management team, on their behalf, would consult the CEO on what has been done and discuss the preventative measures that need to be taken – the CEO would likely forward the information to the CISO or back to the security engineers themselves and let them decide what security solution they need to employ to further the security of the company.

Many of the security engineers would elect to use data breach search engines and their API capabilities due to their powerful nature to scan through tens of billions of rows of data quickly and with ease, and then make the data breach API a part of the company for years to come therefore protecting it from threats of the present, and of the future alike. If you‘ve enjoyed reading this blog, make sure to explore more stories on our blog by visiting this link, share this blog with your friends if you‘ve found it to be interesting, and until next time!