Red Hat Security Advisory 2023-7345-01 - An update is now available for Red Hat OpenShift GitOps 1.9. Issues addressed include a denial of service vulnerability.

The following advisory data is extracted from:

https://access.redhat.com/security/data/csaf/v2/advisories/2023/rhsa-2023_7345.json

Red Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.

- Packet Storm Staff

====================================================================  
Red Hat Security Advisory

Synopsis:           Important: Red Hat OpenShift GitOps v1.9.3 security update  
Advisory ID:        RHSA-2023:7345-01  
Product:            Red Hat OpenShift GitOps  
Advisory URL:       https://access.redhat.com/errata/RHSA-2023:7345  
Issue date:         2023-11-20  
Revision:           01  
CVE Names:          CVE-2023-39325  
====================================================================

Summary: 

An update is now available for Red Hat OpenShift GitOps 1.9.

Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.

Description:

An update is now available for Red Hat OpenShift GitOps 1.9.

Security Fix(es):

* golang: net/http, x/net/http2: rapid stream resets can cause excessive work (Rapid Reset Attack) (CVE-2023-39325)

* HTTP/2: Multiple HTTP/2 enabled web servers are vulnerable to a DDoS attack (Rapid Reset Attack) (CVE-2023-44487)

A Red Hat Security Bulletin which addresses further details about the Rapid Reset flaw is available in the References section.

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

Solution:

https://access.redhat.com/articles/11258

CVEs:

CVE-2023-39325

References:

https://access.redhat.com/security/updates/classification/#important  
https://access.redhat.com/security/vulnerabilities/RHSB-2023-003  
https://docs.openshift.com/gitops/1.9/understanding_openshift_gitops/about-redhat-openshift-gitops.html  
https://bugzilla.redhat.com/show_bug.cgi?id=2242803  
https://bugzilla.redhat.com/show_bug.cgi?id=2243296

Red Hat Security Advisory 2023-7345-01

Red Hat Security Advisory 2023-7344-01 - An update for openshift-gitops-kam is now available for Red Hat OpenShift GitOps 1.9. Issues addressed include a denial of service vulnerability.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2023/rhsa-2023_7344.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Important: openshift-gitops-kam security updateAdvisory ID:        RHSA-2023:7344-01Product:            Red Hat OpenShift GitOpsAdvisory URL:       https://access.redhat.com/errata/RHSA-2023:7344Issue date:         2023-11-20Revision:           01CVE Names:          CVE-2023-39325====================================================================Summary: An update for openshift-gitops-kam is now available for Red Hat OpenShift GitOps 1.9.Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.Description:An update for openshift-gitops-kam is now available for Red Hat OpenShift GitOps 1.9.Security Fix(es):* golang: net/http, x/net/http2: rapid stream resets can cause excessive work (Rapid Reset Attack) (CVE-2023-39325)* HTTP/2: Multiple HTTP/2 enabled web servers are vulnerable to a DDoS attack (Rapid Reset Attack) (CVE-2023-44487)A Red Hat Security Bulletin which addresses further details about the Rapid Reset flaw is available in the References section.For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2023-39325References:https://access.redhat.com/security/updates/classification/#importanthttps://access.redhat.com/security/vulnerabilities/RHSB-2023-003https://bugzilla.redhat.com/show_bug.cgi?id=2242803https://bugzilla.redhat.com/show_bug.cgi?id=2243296

Red Hat Security Advisory 2023-7344-01

Threat actors are targeting the education, government and business services sectors with a remote access trojan called NetSupport RAT.
"The delivery mechanisms for the NetSupport RAT encompass fraudulent updates, drive-by downloads, utilization of malware loaders (such as GHOSTPULSE), and various forms of phishing campaigns," VMware Carbon Black researchers said in a report shared with The

Malware / Network Security

Threat actors are targeting the education, government and business services sectors with a remote access trojan called **NetSupport RAT**.

"The delivery mechanisms for the NetSupport RAT encompass fraudulent updates, drive-by downloads, utilization of malware loaders (such as GHOSTPULSE), and various forms of phishing campaigns," VMware Carbon Black researchers said in a report shared with The Hacker News.

The cybersecurity firm said it detected no less than 15 new infections related to NetSupport RAT in the last few weeks.

While NetSupport Manager started off as a legitimate remote administration tool for technical assistance and support, malicious actors have misappropriated the tool to their own advantage, using it as a beachhead for subsequent attacks.

NetSupport RAT is typically downloaded onto a victim's computer via deceptive websites and fake browser updates.

In August 2022, Sucuri detailed a campaign in which compromised WordPress sites were being used to display fraudulent Cloudflare DDoS protection pages that led to the distribution of NetSupport RAT.

The use of bogus web browser updates is a tactic often associated with the deployment of a JavaScript-based downloader malware known as SocGholish (aka FakeUpdates), which has also been observed propagating a loader malware codenamed BLISTER.

The Javascript payload subsequently invokes PowerShell to connect to a remote server and retrieve a ZIP archive file containing NetSupport RAT that, upon installation, beacons out to a command-and-control (C2) server.

"Once installed on a victim's device, NetSupport is able to monitor behavior, transfer files, manipulate computer settings, and move to other devices within the network," the researchers said.

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

NetSupport RAT Infections on the Rise - Targeting Government and Business Sectors

By Deeba Ahmed
Czech Republic Police Expose 'Fake Bankers' Gang in $8.7 Million Vishing Operation.
This is a post from HackRead.com Read the original post: Multimillion-Dollar Vishing Scam Busted: Czech-Ukrainian Gang Arrested

Europol Warns of Growing Vishing Trend as Criminals Exploit Phone Calls for Massive Financial Gains

Ukrainian and Czech police under the supervision of Europol have dismantled a criminal gang that stole millions of dollars from bank customers in Czechia through vishing scams. According to Europol’s press release, the police also arrested ten suspects (aged 18-29) in connection with the multimillion-dollar fraud ring.

A joint investigation was initiated by Europol that led to the arrest of four individuals in Czechia and six in Ukraine in April 2023. Those arrested from Ukraine were later extradited to Czechia.

During the crackdown, investigators seized SIM cards, mobile phones, and computer equipment from the suspects’ vehicles, call centers, residences, and offices located in Czechia (Domazlice, Rokycany, and Plzen) and Ukraine (Dnipropetrovsk). Some of the suspects had a history of drug offences, violent crimes, and document forgery.

The criminal organization, based in Ukraine, conducted vishing attacks against Czech victims. They operated from call centers in Ukraine and called bank customers using spoofed phone numbers, posing as bank security officers. This scamming method is called vishing (created by combining voice and phishing).

The targets were told that their bank account was hacked and lured into revealing their banking data, such as credit card numbers, login credentials, and other details. Scammers also made phone calls pretending to be a police official to confirm the hacking.

After gaining trust, the scammers persuaded their victims to transfer funds from their “compromised” bank accounts to “safe” bank accounts, which the scammers owned. Through these scams, the fraudsters made approximately $8.7 million (€8 million) from victims in Czechia alone.

The Czech Republic police uncovered this scam. In November 2021, they contacted Eurojust to launch an investigation. Europol then formed a joint investigation team in June 2022, comprising Europol’s European Cybercrime Centre (EC3) officials and the Czech and Ukrainian investigators. The agency organized five meetings to facilitate judicial cooperation between the authorities.

The police called the gang’s activities one of the **“most extensive series of frauds committed through fake bankers.”** Currently, Europol is conducting analytical work and providing digital forensic support for the confiscated equipment.

Image via Czech Republic police

Vishing fraud has become more widespread and popular lately. It usually involves someone pretending to be from a reputable organization, institution, or government agency and deceiving people into disclosing confidential, personal data.

The severity of vishing scams is highlighted by the September 2023 incident when the notorious ALPHV (BlackCat) ransomware gang exploited vishing to deceive an MGM Resorts employee, enabling them to breach the company’s security and compromise its network.

To protect yourself from such scams, always be cautious of unsolicited phone calls, note the caller’s phone number, and tell them you will call back and quickly verify their identity by calling the organization.

Don’t believe any caller if they have basic information about you because it could be taken from social media. Lastly, keep your credit/ debit card PIN or online banking password private because bank representatives would never ask for this information.

****_RELATED ARTICLES_****

1.  **Police Dismantle SIM Swapping Gang in Spain**
2.  **48 DDoS-hiring Services Busted by FBI in Major Sweep**
3.  **Cisco Breach – Employee’s Google Account was Hacked**
4.  **The Types of Phishing Attacks and How to Dodge All of Them**
5.  **SpyNote Spyware Using SMS Phishing Against Banking Customers**

Multimillion-Dollar Vishing Scam Busted: Czech-Ukrainian Gang Arrested

Red Hat Security Advisory 2023-7335-01 - An update is now available for Red Hat Process Automation Manager including images for Red Hat OpenShift Container Platform. Issues addressed include a denial of service vulnerability.

The following advisory data is extracted from:

https://access.redhat.com/security/data/csaf/v2/advisories/2023/rhsa-2023_7335.json

Red Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.

- Packet Storm Staff

====================================================================  
Red Hat Security Advisory

Synopsis:           Important: Updated Red Hat Process Automation Manager 7.13.4 SP2 Images  
Advisory ID:        RHSA-2023:7335-01  
Product:            Red Hat OpenShift Enterprise  
Advisory URL:       https://access.redhat.com/errata/RHSA-2023:7335  
Issue date:         2023-11-16  
Revision:           01  
CVE Names:          CVE-2023-44487  
====================================================================

Summary: 

An update is now available for Red Hat Process Automation Manager including images for Red Hat OpenShift Container Platform.

Description:

Red Hat Process Automation Manager is an open source business process management suite that combines process management and decision service management and enables business and IT users to create, manage, validate, and deploy process applications and decision services.

This release includes security fixes.

Security Fix(es):

* netty-codec-http2: HTTP/2: Multiple HTTP/2 enabled web servers are vulnerable to a DDoS attack (Rapid Reset Attack) (CVE-2023-44487)

* undertow: HTTP/2: Multiple HTTP/2 enabled web servers are vulnerable to a DDoS attack (Rapid Reset Attack) (CVE-2023-44487)

* Quarkus: HTTP/2: Multiple HTTP/2 enabled web servers are vulnerable to a DDoS attack (Rapid Reset Attack) (CVE-2023-44487)

* EAP XP: HTTP/2: Multiple HTTP/2 enabled web servers are vulnerable to a DDoS attack (Rapid Reset Attack) (CVE-2023-44487)

* EAP: HTTP/2: Multiple HTTP/2 enabled web servers are vulnerable to a DDoS attack (Rapid Reset Attack) (CVE-2023-44487)

* businessautomation-operator: HTTP/2: Multiple HTTP/2 enabled web servers are vulnerable to a DDoS attack (Rapid Reset Attack) (CVE-2023-44487)

A Red Hat Security Bulletin which addresses further details about this flaw is available in the References section.

For more details about the security issues, including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE pages listed in the References section.

Solution:

https://access.redhat.com/articles/11258

CVEs:

CVE-2023-44487

References:

https://access.redhat.com/security/updates/classification/#important  
https://bugzilla.redhat.com/show_bug.cgi?id=2242803

Red Hat Security Advisory 2023-7335-01

Red Hat Security Advisory 2023-7334-01 - An update for rh-varnish6-varnish is now available for Red Hat Software Collections. Issues addressed include a denial of service vulnerability.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2023/rhsa-2023_7334.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Important: rh-varnish6-varnish security updateAdvisory ID:        RHSA-2023:7334-01Product:            Red Hat Software CollectionsAdvisory URL:       https://access.redhat.com/errata/RHSA-2023:7334Issue date:         2023-11-16Revision:           01CVE Names:          CVE-2023-44487====================================================================Summary: An update for rh-varnish6-varnish is now available for Red Hat Software Collections.Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.Description:Varnish Cache is a high-performance HTTP accelerator. It stores web pages in memory so web servers don't have to create the same web page over and over again, giving the website a significant speed up.Security Fix(es):* HTTP/2: Multiple HTTP/2 enabled web servers are vulnerable to a DDoS attack (Rapid Reset Attack) (CVE-2023-44487)For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2023-44487References:https://access.redhat.com/security/updates/classification/#importanthttps://access.redhat.com/security/vulnerabilities/RHSB-2023-003https://bugzilla.redhat.com/show_bug.cgi?id=2242803

Red Hat Security Advisory 2023-7334-01

Cisco Talos has recently observed an increase in activity conducted by 8Base, a ransomware group that uses a variant of the Phobos ransomware and other publicly available tools to facilitate their operations.

A deep dive into Phobos ransomware, recently deployed by 8Base group

By Deeba Ahmed
The Ddostf Botnet was initially identified in 2016.
This is a post from HackRead.com Read the original post: Ddostf Botnet Resurfaces in DDoS Attacks Against MySQL and Docker Hosts

Researchers claim that the Chinese Ddostf botnet is specifically designed for launching DDoS attacks and that the threat actors are operating a DDoS-for-hire service.

AhnLab Security Emergency Response Center (ASEC) researchers have shared alarming **details** of a new campaign targeting MySQL servers and Docker hosts with DDoS malware.

AhnLab noted that attacks targeting MySQL servers on Windows systems have increased sharply, and vulnerable servers are infected with the Chinese botnet Ddostf, **discovered** in 2016.

Researchers claim that this malware is specifically designed for launching DDoS attacks and that the threat actor is operating a **DDoS-for-hire service**.

According to the AESC blog post, threat actors scan for exploitable MySQL servers. After compromising the servers, threat actors install the Ddostf DDoS botnet to launch distributed denial-of-service (DDoS) attacks against other servers.

**MySQL servers** are a common target in such campaigns because of their widespread use in Windows and Linux environments. Although MS-SQL is a preferred database service for Windows users, MySQL servers are also commonly used on Windows, which makes the systems running them a prime target for cybercriminals.

Based on data from AhnLab’s Smart Defense (ASD) logs, most malware targeting vulnerable MySQL servers were **Gh0st RAT** variants, but instances of **AsyncRAT** were also observed and recently, there’s been an uptick in the use of the Ddostf botnet.

Ddostf is a powerful malware that copies itself with a random name in the %SystemRoot% directory and registers as a service before decrypting the encrypted C2 server URL string to connect to the attackers’ server. It can collect system data and transfer it to the C2 server. Then it waits for specific commands (e.g., SYN, UDP, and HTTP GET/POST floods) to launch the **DDoS attacks**.

The botnet is unique because it can connect to a new address from the C2 server and execute commands there for a limited time. This helps the Ddostf botnet operator to infect multiple systems and sell DDoS attacks as a service. Ddostf can target Linux and Windows systems because of supports both ELF and PE formats and can achieve persistence. 

Attackers first scan for publicly accessible systems using port 3306/TCP and after accessing the server (those with known vulnerabilities or weak credentials), they use brute-force or dictionary attacks on the system.

If the system has signs of poor credential management, attackers can gain access to administrator account credentials. If the system runs an **unpatched version with vulnerabilities**, attackers can exploit them to execute commands without needing these processes. Unlike MS-SQL, which entails direct OS command execution methods, MySQL relies on UDFs (User-Defined Functions) that can allow threat actors to execute commands.

They can also install malicious UDF DLLS on infected MySQL servers and execute commands. Like CLR Stored Procedure WebShell work, these DLLs can provide threat actors complete control of the infected system. In the case of the Ddostf DDoS bot, attackers use the UDF malware as a tool to install it on poorly managed MySQL servers.

Database servers get frequently targeted because of poorly managed account credentials. Administrators must use strong passwords apart from applying the latest patches to protect their servers. Firewalls can be used to restrict access to external actors, and a DDoS mitigation service can help protect against **large-scale attacks**.

****_RELATED ARTICLES_****

1.  **Who Killed the Mozi IoT Zombie Botnet – India or China?**
2.  **Chinese APT Posing as Cloud Services to Spy on Cambodia**
3.  **Dark.IoT & Custom Botnets Exploit Zyxel Flaw in DDoS Attacks**
4.  **How Chinese Hackers Stole Signing Key to Breach Outlook Accounts**
5.  **Chinese Scammers Exploit Cloned Websites in Vast Gambling Network**

Ddostf Botnet Resurfaces in DDoS Attacks Against MySQL and Docker Hosts

Red Hat Security Advisory 2023-7288-01 - An update for Openshift Jenkins is now available for Red Hat Product OCP Tools 4.14. Issues addressed include bypass, code execution, cross site scripting, and denial of service vulnerabilities.

The following advisory data is extracted from:

https://access.redhat.com/security/data/csaf/v2/advisories/2023/rhsa-2023_7288.json

Red Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.

- Packet Storm Staff

====================================================================  
Red Hat Security Advisory

Synopsis:           Important: Red Hat Product OCP Tools 4.14 Openshift Jenkins security update  
Advisory ID:        RHSA-2023:7288-01  
Product:            OpenShift Developer Tools and Services  
Advisory URL:       https://access.redhat.com/errata/RHSA-2023:7288  
Issue date:         2023-11-16  
Revision:           01  
CVE Names:          CVE-2022-25857  
====================================================================

Summary: 

An update for Openshift Jenkins is now available for Red Hat Product OCP Tools 4.14. 

Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.

Description:

Jenkins is a continuous integration server that monitors executions of repeated jobs, such as building a software project or jobs run by cron.

Security Fix(es):

* golang: net/http, x/net/http2: rapid stream resets can cause excessive work (Rapid Reset Attack) (CVE-2023-39325)

* HTTP/2: Multiple HTTP/2 enabled web servers are vulnerable to a DDoS attack (Rapid Reset Attack) (CVE-2023-44487)

A Red Hat Security Bulletin which addresses further details about the Rapid Reset flaw is available in the References section.

* snakeyaml: Denial of Service due to missing nested depth limitation for collections (CVE-2022-25857)

* maven-shared-utils: Command injection via Commandline class (CVE-2022-29599)

* apache-commons-text: variable interpolation RCE (CVE-2022-42889)

* jenkins-2-plugins/script-security: Sandbox bypass vulnerability in Script Security Plugin (CVE-2023-24422)

* jenkins-2-plugins/JUnit: Stored XSS vulnerability in JUnit Plugin (CVE-2023-25761)

* jenkins-2-plugins/pipeline-build-step: Stored XSS vulnerability in Pipeline: Build Step Plugin (CVE-2023-25762)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

Solution:

https://access.redhat.com/articles/11258

CVEs:

CVE-2022-25857

References:

https://access.redhat.com/security/updates/classification/#important  
https://access.redhat.com/security/vulnerabilities/RHSB-2023-003  
https://bugzilla.redhat.com/show_bug.cgi?id=2066479  
https://bugzilla.redhat.com/show_bug.cgi?id=2126789  
https://bugzilla.redhat.com/show_bug.cgi?id=2135435  
https://bugzilla.redhat.com/show_bug.cgi?id=2164278  
https://bugzilla.redhat.com/show_bug.cgi?id=2170039  
https://bugzilla.redhat.com/show_bug.cgi?id=2170041  
https://bugzilla.redhat.com/show_bug.cgi?id=2242803  
https://bugzilla.redhat.com/show_bug.cgi?id=2243296

Red Hat Security Advisory 2023-7288-01

Avoiding some of these common mistakes ensures your organization’s plan will be updated faster and is more thorough, so you are ready to act when, not if, an incident happens.

Thursday, November 16, 2023 08:00

Cisco Talos recently covered the basics of NIS2, a new set of requirements for cybersecurity and security incident disclosures set to take effect next year in the European Union.

As part of these new guidelines, organizations with operations in the EU must have up-to-date “incident handling” procedures and “policies on risk analysis and information system security”

To comply, Talos IR recommends creating or updating your organization’s incident response (IR) plan, along with the Information Security Policy, Business Continuity and Crisis Management Plan. The IR plan is a crucial document for each organization’s cybersecurity practice and should be among the first documents to be updated to comply with NIS2.

Below, we’ll outline seven common pitfalls that organizations make when creating or updating an incident response plan. Avoiding some of these common mistakes ensures your organization’s plan will be updated faster and is more thorough, so you are ready to act when, not if, an incident happens.

**Part II: Pitfalls to avoid when creating an incident response plan**

**Failing to define a document hierarchy**

A common mistake when starting to work on a new or updated IR plan is to look at the plan in isolation, without consideration for all the cybersecurity documents that exist in your organization.

The term “document hierarchy" might sound complicated and foreign, but it describes exactly this simple concept: All documents within an organization should have a specific scope, purpose and intended audience — A bit like LEGO blocks that build upon each other.

Document B can deepen the information presented in Document A by providing more details on a specific part of the process without the need to repeat what was already presented in Document A. Having a clear overview on how the individual documents fit within the overall document hierarchy helps avoid duplication of information, thus keeping documents only as long as they really need to be. A shorter document with a clear focus is more likely to be read and effectively used by its intended audience.

In the context of cybersecurity, Talos IR recommends a document hierarchy consisting of the following building blocks:

The incident response plan focuses on the incident handling process. It is a second- or third-level document that builds on the higher-level information in the security policy or the security principal statement. In the plan, which has a narrower audience than the previous two documents, one can find details on the formation and operations of the incident response team, actions and available resources in each phase of the incident response process, escalation procedures and communication flows. The information in the incident response plan is applicable to all cybersecurity incidents and serves as a basis for the development of the next level of documentation, which is more procedural and scenario-based.

By failing to define and adhere to a clear document hierarchy you run the risk of overloading the IR plan with specific checklist type of information, which would be more fitting for a playbook. Playbooks usually build upon the incident response plan to provide step-by-step guidance for responding to a specific incident type, such as ransomware, suspicious emails, and unusual network traffic. Another risk is the plan is too broad, borrowing content from the policy and listing general cyber hygiene advice and end-user training topics. This makes it hard for the responders, who are the main audience of the plan, to find the vital information for their needs.

**Being too general**

An Incident Response Plan should at the very least answer the “Who, What, When and How?” of a cybersecurity incident.

If you break it down:

*   **Who** – What are the roles that are part of the IR process, what skillsets or capabilities are required for the members of the role (technical and in terms of crisis management and coordination), and what other supporting roles are involved during the different IR phases.
*   **What** – What activities are performed at each stage of the incident response process? Remember, an IRP is not a playbook, so you do not need to describe the details of, for example, investigating suspicious executable files on a host. Instead, the plan should have a description of the general triage process, available data sources within the organization and possible playbooks to follow once the incident has been narrowed down.
*   **When** – Time is precious during an incident, so it is good to have an order of actions that is pre-determined to take place whenever an incident occurs. For example, based on the priority classification of the incident (which is something that should also be in the plan) an escalation process might be started. Would a high-priority event occurring on the weekend necessitate calling immediately the manager immediately? Is such an escalation point available outside of normal working hours? Each action should also have a role owner identified.
*   **How** – An incident response plan should contain high-level information about the tools that would typically be used during an incident for the technical response (including data capturing, detection capabilities and analysis tools) and the incident communication (e.g., what alternative infrastructure can be used if the network is suspected to be compromised). Yet, the plan should offer only an overview of the capabilities of the tools, the toolkit at the team’s disposal, rather than procedural details on using them. The latter should be added to the organization’s playbooks.

**Being too specific**

An IRP is not a playbook. The information in the plan is the foundation that doesn’t need to be repeated in the other playbooks. For example, ensure that the plan does not include procedural information that is only applicable to one type of attack, such as ransomware or distributed denial-of-service (DDoS), because this will water down the scope of the document.

**Writing in isolation**

In all fairness, few technical personnel are truly enthusiastic about writing process documentation. This makes it even more important to ensure that whoever works on the IR plan is supported by the broader team.

One of the most successful ways to create a meaningful IR plan is to involve the company stakeholders, such as the primary business application owners, so they can have an understanding and make sure their needs and expectations are being met with the plan.

The initial plan draft should be reviewed by at least two team members who have process knowledge and will be responsible for the IR process implementation. Then, the next level of review should be done by teams outside of the core IR team, such as Networking and Storage Management, which play a key role during recovery. Supporting non-technical teams such as legal, communications and HR, should be provided with a final draft for review. The input of the latter is just as valuable as the technical ones, because some regulations, such as NIS2, will require incident notification within 24 hours. For example, it would be up to the legal team to confirm if, and who will be available on the weekend to contact law enforcement for an incident that started on a Friday afternoon and by Sunday needs to be reported.

**Not testing the IR plan**

We all know that testing processes are essential, but not all processes are created equal. How often do you test your backup recovery procedure? And how often do you test your incident response process?

An Incident Response Plan typically contains several sub-process descriptions, such as an escalation process, triage process, alternative communication channels activation process, etc. The plan is only as good as its use during a real incident, and the best way to identify any gaps in any of those sub-processes is to put them to a test.

How can you test the IR Plan? Start by breaking it down into key processes which are part of the overall incident handling. Then rank those processes according to their criticality for the overall response and their level of effort to test. Start with the sub-processes on top and work your way down.  

For example, look at the recovery action, “the incident lead contacts the backup management team to get the status of the backups.” Here are some of the questions that you might need to check:

*   How does the incident commander contact the backup management team? Is that communication channel available offline if the company’s communications tools are down or compromised?
*   Will the backup management team be available at this time of the day? What if the incident happens on the weekend or during a public holiday?
*   Where will the backup management team find the latest test date of the backups? Does the backup management team have a procedure to follow during the verification of the backup’s integrity? How quickly such an overview be created?
*   If backups have been isolated, could they be checked for integrity?
*   In case of a suspicion of compromise, does the backup management team have a list of all accounts that have access to the backups?
*   How will the incident commander keep track of all information sent to them during the incident and make them available to the larger team?

To test the tools, people and processes involved in this situation, Talos IR recommends conducting tabletop exercises at least once a year.  A tabletop is a dry run through a scenario customized to your organization, the attack being only on paper without environmental impact, to see how responsible teams will react. It might seem harmless but if done properly, the tabletop can empower teams to see their IR plan with new eyes, discovering both the power of a well-written document with up-to-date information and the areas that need improvement.

**Letting it get stale**

An IRP should be renewed and updated at least once a year, and additionally, whenever you have major software or hardware changes in your environment. Changes in the organization's legal structure, such as mergers and acquisitions, also necessitate a review. At the conclusion of any major incidents, it is also recommended to review the IR Plan and adjust based on the incident. Regular reviews also help ensure that in case of personnel changes — e.g., members rotating outside the team or the organization, or IT landscape changes — the plan is still effective.

**Being too IT-focused**

An IR plan should be created in consultation with other non-technical teams, starting with legal, compliance, HR and communications. Specific examples of when you will need to work closely with those teams are cases when the personal data of employees has been affected, when you have regulatory requirements to notify authorities about an incident, or when you need to publish a public statement about a major incident.

Another team that is often overlooked but should be part of the IR plan development is the service desk team. Are agents able to route a cybersecurity incident properly and get it quickly escalated to the IR team? Have they been trained to recognize, even with fewer affected users, high-confidence signs of common attacks such as ransomware, wipers and social engineering?

If you remain too focused on the technical aspects of handling an incident, you run the risk of creating an incomplete document. Supporting teams should be part of the development process, the distribution list of the final document, and the testing and training exercises. Raising a child takes a village, and so does protecting an organization.

Talos IR can support customers in preparing to meet the requirements of NIS2. The following services address one or more of the requirements of the directive:

*   **Preparing:** IR Plan, IR Playbooks, IR Readiness Assessment, Log Architecture Assessment
*   **Simulating:** Purple Team
*   **Training:** Tabletop , Cyber Range
*   **Hunting:** Compromise Assessment, Threat Hunting
*   **Core:** Emergency Response, Intel on Demand

The implementation of technical and procedural measures, which would support you in achieving compliance with NIS2, is a process that might require creating new processes and updating your technology stack. Time flies when you are having fun so we recommend that you start by reviewing the requirements you will need to comply with and putting together an actionable plan for how to achieve this in the course of the upcoming year.

Tag

#ddos