Benefits of Pentest for the post-incident patient

Eva Belyaeva, Security Vision

Introduction

How can you help to get the SOC team excited and get them to fight against a real, rather than fictitious, attacker? What is most often associated with some negligence in relation to the postincident process and how does it affect the investigation process as a whole?

On what will the preparation phase of the investigation and the investigation itself most depend? Today we will look at the relationship of pentest for the company and Lessons Learned processes.

Some outsourced-SOCs have commented that some sort of incentive or training is needed for the Blue Team to ensure that analysts are prepared for unexpected and rare incidents. Because turnover is familiar, relevant to almost everyone, and automated and scripted into playbooks whenever possible.

Problems usually arise when either part of the infrastructure has not been worked out (it and attacks on it remain unfamiliar) or when the team, even having learnt on typical cases of a certain direction, fails to face the real task. The reason for the latter is often that the results of the exercise were not properly used further.

What is the purpose of working on mistakes - to change something around or to change your approach to work?

Typical operation of a commercial SOC

If you imagine a spherical SOC in a vacuum, anyone would say standard incident handling services, standard incidents and playbooks. If you have ever built a SOC for someone (or made one for yourself), you may have caught the moment when the implementation team looks at both standards and developments on the topic in order to adapt some classic cases to the customer's realities with minimal effort. Non-standardisation started when vendor specialists had already left and the real attacks had just started.

Recently, this picture has changed somewhat - now there is a full-fledged audit, and best practices have become wider, now they can include not so popular earlier anti-fraud, a separate area is a separate line of ACS, and so on.

One thing is constant - according to some experts at the same SOC Forum, red team and blue team somehow find nothing or find some degenerate or too simple cases. Either they should have been protected against them ten years ago, or such a scenario can't occur to anyone in principle.

The outlook of both teams is confined to their own developments and does not expand further. But why?

There are several ways to bring new expertise to the team - exercises, roundtables, and pentests. You may have something else in use - for example, you regularly read dfir reports or monitor attacker reports.

But what's the next step when all these necessary activities have been done? How do you not go back to square one? There is a whole phase in the investigation for this - the post-incident phase - and it's one that you need to be able to work intelligently in.

What is Lessons Learned and why is it done?

How does a post-incident go? After the results of specific situations are analysed, work is done on the infrastructure and response plans, and plans are formed to improve the response and investigation process itself. The outcome of this stage is the optimisation of current processes and improved training of analysts, a more systematic approach to further ‘work on errors’.

This process includes the following steps:

- Identifying issues and strengths, collecting comments and recommendations

- Documenting all findings

- Analysing and preparing documentation

- Formation of a knowledge base

- Further utilisation of the data collected

The goals of the postincident are most often as follows:

- To learn from mistakes - not to repeat actions that did not yield positive results

- Understand problems both in infrastructure and organisational problems

- To emphasise the success of current actions - not to forget what has been done well

- Retain knowledge in documentation - the very existence of a knowledge base of frequent problems and workarounds helps to establish processes

- Reducing the risk of future problems - it is likely that some of the risk will be mitigated by changing the approach

- Improved productivity - speed of response and getting up to speed on tasks

Where does the content come from?

The ultimate goal of a SOC is always to improve security, not to periodically close metrics and hammer out a pentest every now and then. The company and its systems must be secure and constantly monitored, and people must be prepared for any attack scenario.

Postincident is exactly what brings security spiralling towards target security. There are several levels of maturity for the postincident process:

Depending on how often and over how many incidents Lessons Learned are conducted, the bottom line of refinements for SOC processes changes. In particular, the GIAC Certified Incident Handler certification mentions that even if any issues are identified post-incident, they are rarely passed on to the preparation phase in the next process cycle. Also, people may neglect to make changes to the documentation before direct work, even if some results were obtained.

In other words, a process that runs somewhere parallel to the daily activities of analytics is unpredictable and its results are difficult to use. Often, the SOC may neglect this phase altogether, because after one incident is over, it is necessary to move on to the next, and the next, and there is no time to work through their possible mistakes.

Attitude towards the process

- Perception of the process as a necessity

- Make it as easy as possible for the user to complete forms

- Regularly checking and revising data

- Using the accumulated data in the work

There are whole methodologies on how to work with optimisation in Lessons Learned, as an example let's look at one of them.

Three phases of LL work and analysis

In this incident results workflow, the actions taken during the post-incident are captured and incidents are tagged; these results are further categorised based on incident type, criticality and other metrics. The output provides a picture of which incidents were followed up after closure, which measures had a positive and which had a negative effect. The need to change the measures in each group of incidents is also recorded: the need to refine the playbook, add new steps to it, the need for additional training of analysts.

The results of such processing are conclusions - what we need to stop or start doing, whether changes are needed at all. At the output we collect a full-fledged database of developments with the context of solved and unsolved problems.

Where can we get the context from? That is, the set of incidents that would effectively test existing playbooks and analyst readiness.

Conducting a pentest that the SOC may not be aware of

The unpredictability of a pentest without blue team involvement provides a broader perspective for the SOC analytics team as a result. If you don't try to hedge and compensate for something in the moment, you will see the real picture of the security level, exclude the possibility of prior agreement and redistribution of forces, for example, on web defence, if the attack is planned in this direction.

The primary target of the pentest, if independent researchers are to be believed, is errors in business logic. Business logic vulnerabilities can include errors in processes, rules and workflows that can be exploited by attackers for unauthorised access, data manipulation or disruption.

Why a classic planned pentest is not enough

- ‘Infrastructure builders’ make generally the same mistakes over time that lead to typical vulnerabilities and risks. These can be identified without a pentest.

- Auto-validation within the product will not give full coverage as non-standard cases are not considered.

- A good pentest has no such thing as out of scope, even if the customer does not belong to a certain area, e.g. banks or telecoms, it is still worth trying scenarios from these areas too.

- Pentest and IS often have different objectives of checking products, network, security. The defence team is interested in proving the results of their good work with a real-life example, and less often in finding their weaknesses.

What should be considered a measure of success?

Increased readiness for rare cases after a pentest is one of the bonuses of independent research. The result can also be a test of not only the analysts' skills but also their defences - it may be time to replace them.

In fact, getting the result of a pentest to confirm that the customer is not protected in the best way is in some way even good - it is better than with a real attacker. An unexpected pentest without agreements that impartially checks everything it can find will provide both a shake-up for analysts and a new context for the post-incident.

It is the Lessons Learned phase of the post-inspection process that is worth spending valuable time on, transferring the newly highlighted risks into documentation and embedding in the preparation phase.

The bottom line

In the constant race for performance within the SOC, it is not uncommon to scrutinise issues that are not relevant to the company. In addition to taking the post-incident phase with due seriousness, regular adjustments in the focus of the SOC team are also required, and pentesting can help with this.

Regular penetration testing will provide the Situation Centre with new, live cases and help train the current team of analysts on the infrastructure of the customer they are protecting.