Security Testing Guideline

Introduction

This guideline outlines the planning and execution of security and robustness testing as part of development or maintenance projects. It applies to all products, both Safety certified and non-Safety products, that interact with physical users or other systems, not just those with Ethernet ports.

Intended for

This document targets release owner as well as cybersecurity personnel responsible for our products.

Release Owner together with Cyber Security Engineer will define the test scope for the release based on the tests listed below. Early planning is needed for estimates of resources and cost. Specifics about the tests and who will perform the tests should be described in the Test Strategy and Plan.
Tester, e.g. persons from the test team or developers, who will be involved in creating test cases, selecting test tools and perform testing.

Test plan & strategy

Planning for the security testing includes:

• analyzing possible vulnerabilities (including life-cycle issues) in the OSS or commercial components that the product/system is composed of (software composition analysis)
• identifying security-related issues associated with the software implementation (static code analysis and code review)
• creating test cases to validate that the product security functions meet the security requirements
• creating test cases to validate the effectiveness of any mitigation found during internal threat analysis (and risk assessment), performance tests, scalability, boundary/edge condition, robustness and malformed input testing (see both pre-DSAC and DSAC).
• to validate the effectiveness of any security control identified during the analysis of possible attack surfaces of the product/system (including hardening settings).
• defining regression testing including. tools, considering the security criticality analysis

Note that it is recommended that all security issues be handled before functional testing. All security test cases are recommended to be properly identified by using appropriate tags or a proper type (e.g. provided by a Configuration Management infrastructure) to ensure their traceability. They should be reviewed with security experts (e.g. cyber security engineers) since both the product architecture and software design might change in any release, along with security controls and used technologies. Extra attention should be given by the test team to system/product security critical components: changes in such components may require a deeper review and additional regression tests. Further, it is paramount that any security measure provided by the system does not adversely affect the essential functions.

Independence of testers

All types of test categories listed in the sections below are required for PAPCP releases. There are certain requirements according to IEC-62443-4-1 on who should perform specific tests. Different tests are best executed by different roles, however there are certain requirements on who can perform specific tests.
See the table below.

• None – no independence required. Developer can perform the testing.
• Independent person – the person who performs the testing cannot be one of the developers of the product.
• Independent department – the person who performs the testing cannot report to the same first line manager as any developers of the product.

Test Type	Level of independence - SVV-5	Reference to IEC 62443-4-1
Security Requirements Testing	Independent department	SVV-1 – Security requirements testing
Threat Mitigation Testing	Independent department	SVV-2 - Threat mitigation testing
Vulnerability Scanning	Independent person	SVV-3.1 – Vulnerability testing
Abuse Case Testing	Independent person	SVV-3.2a - Abuse Case Testing
Attack Surface Analysis	Independent person	SVV-3.2b – Vulnerability testing
Information Disclosure Testing	Independent person	SVV-3.2c – Vulnerability testing
Software Composition Analysis	None	SVV-3.2d – Vulnerability testing
Penetration Testing	Independent department or organization	SVV-4 – Penetration testing
Web Application Testing	None	-
Static Code Analysis	None	SI1 – Security implementation review

Objectives of security testing

• Identify Vulnerabilities:
  Conduct comprehensive assessments to discover potential security weaknesses in applications, systems, and networks. By proactively identifying these vulnerabilities, the organization can address them before they are exploited by malicious actors, thereby reducing the risk of security breaches.

• Ensure Compliance:
  Verify that the organization adheres to relevant regulatory requirements and industry standards, such as the Cyber Resilience Act (CRA), IEC62443, and ISO 27001. Regular compliance checks help maintain legal and regulatory standing and demonstrate commitment to security best practices.

• Enhance Security Posture:
  Provide actionable insights through detailed security assessments that highlight areas for improvement. This helps in continuously strengthening the organization’s overall security framework and reducing the likelihood of successful cyber attacks.

• Validate Security Controls:
  Test the effectiveness of existing security controls to ensure they are functioning as intended. By regularly validating these controls, the organization can identify any gaps or weaknesses and make necessary adjustments to maintain a strong security posture.

Security testing process

Scope definition and planning

• Security as a Key Component:
  Security is an important part of project planning. Review the items in the chapters below and plan for the activities to be performed as early as possible.

• Identify Critical Components:
  Determine which components, such as applications, databases, and network components, """"critical to the product and should be prioritized for testing.""""

• Engage Stakeholders:
  Involve stakeholders (internal and external) to ensure input on regulatory and compliance requirements. Start testing as soon as possible after implementation. Automate as many of the tests as possible.

• Resource Allocation:
  Identify and allocate the necessary resources, including personnel, tools, and budget, to ensure the testing process can be conducted effectively.

• DSAC Test:
  Ensure time slot with DSAC at an early point. See DSAC section further down this page.

Preparation for and execution of tests

• Hardening Before Testing:
  System hardening must be considered as a preparation before testing. System/product hardening is about reducing the attack surface for a system/product. It is an important ingredient in a defense-in-depth strategy.
  If the hardening settings are just recommended and not done by default for all installations, testing shall be made both with and without these. Components that are not needed shall preferably be removed. If this is not possible, they should be disabled and if this is not possible you want to prevent them from being exposed. An example of the latter is to use a firewall function to block access of a service that for some reason cannot be disabled. This is relevant for both OS features and product components. While general testing in most cases should be done to ensure proper functions both with and without hardening, good test coverage should be prioritized during security specific testing, e.g. during vulnerability scanning.

• Up-to-date 3rd party components:
  Mandatory hardening shall normally be performed before all testing, according to updated 3rd party SW in DFN. Tools like Black Duck and Dependency Track play a crucial role by continuously monitoring vulnerabilities in third-party software.

  • https://abb-is-000650.nmea.abb.com/pcp2/docs/Guides/3rd-party-and-OSS/How-to-Handle-3rd-Party-Software-EoL/

  • https://abb-is-000650.nmea.abb.com/pcp2/docs/Guides/3rd-party-and-OSS/How-to-Handle-Vulnerabilities-in-3rd-Party-Software/

• Maintain Clear Documentation:
  Keep detailed records of all testing procedures, configurations, and findings to ensure transparency and reproducibility.

• Report and Escalate Critical Vulnerabilities:
  Immediately report any vulnerabilities the ADO and to the relevant stakeholders to enable swift remediation actions. Ensure that the communication process is clear and efficient to minimize risks.

• Reporting:
  Compile a detailed report that includes descriptions of identified vulnerabilities, risk ratings, and suggested remediation strategies, and keep trace of findings by creating security bugs/tasks in Azure DevOps. The report should be clear and accessible to all relevant stakeholders.

Regression testing

Description:
All security functions must be tested to ensure that code changes in subsequent versions do not invalidate the function. Either the test cases can be selected for the released based on thorough impact analysis of the change that was made, specifically if they are in a security critical component. Another option is that certain test cases (preferably automatic) are tagged and listed as a set of standard security regression tests that should always be executed if changes have been made, as to avoid the risk of missing something in the impact analysis.

After a change or update of a 3rd party SW component the regression testing depends on the type of 3rd party software. 3rd party software included in the build or installation package should be handled in the same way as changes in our own code. Changes to 3rd-party software that the product depends but not an integrated part of the product are not tested by R&D, but by the MSRT/SPT team.
Pre-DSAC should be designed to cover regression tests.

Purpose:
Regression testing involves re-testing applications after modifications to ensure that new changes have not introduced new vulnerabilities or impacted existing functionality.
This type of testing is crucial for maintaining the integrity of the application. It ensures that updates, patches, or new features do not compromise the security of the application. One reason for regression testing is the change/update of a 3rd party SW component.

Tools:
See the list from DAST above, regression testing can be performed using both manual methods and automated testing frameworks, ensuring comprehensive coverage and efficiency.

Test categories

Below you find descriptions of the different test categories. Tools with links to detailed descriptions of the tools are also listed.
Mandatory tools: all tools listed here should be used.
Not mandatory: the tools listed here can be used in addition to mandatory tools or if there are no mandatory tools listed.

Security requirement testing – IEC 62443-4-1 requirement SVV-1

Security requirements are handled as any other requirement and tested accordingly by different levels of the organization.

Threat mitigation testing - IEC 62443-4-1 requirement SVV-2

Description:
Threat Mitigation Testing evaluates the effectiveness of security controls and mitigation strategies against known threats and attack vectors e.g. as describes as in the threat model.
This type of testing helps in validating the organization's threat management practices, ensuring that the implemented security measures are functioning correctly and effectively mitigating the identified threats by attempting to thwart each mitigation. It's recommended that the threat model includes reference from the threat mitigations to the threat mitigation tests.

Purpose:
The main objectives of Threat Mitigation Testing are to ensure the effectiveness of security controls against known threats, validate the proper implementation of mitigation strategies, identify gaps or weaknesses in current security measures, and provide actionable insights for improving overall security posture.

Tools: Mandatory: The team should design tests capable to verify the threat mitigations. This should include deciding on what tools that are sufficient to prove that the mitigations work as intended (including attempts to thwart the mitigations). Examples may be Achilles and ZAP, but could also be Burp, ... Manual inspection can also be used, but automation is of course preferred. Test documentation should describe how a selected tool proves that the mitigation works. Not mandatory: Tools that verify the practically same things as the mandatory tools, but in a different way.

Vulnerability testing - IEC 62443-4-1 requirement SVV-3.1

Description:
Vulnerability testing uses automated tools to identify known vulnerabilities in the system, providing a baseline assessment of the system’s security state.

Purpose:
The goal is to provide a comprehensive view of the system’s security hygiene, identifying areas that need improvement and helping prioritize remediation efforts. Penetration testing by 3rd party specialist is mandatory for products that should be compliant with IEC 62443-4-2 of security level 2 or higher.

Tools: Mandatory: Achilles Testing Platform, Nessus Professional, OWASP ZAP Not Mandatory: Burp Suite Professional, Nikto, Dirb, WFuzz, Claroty OPC_UA Exploitation Framework, Blackbox OPC-UA Fuzzing, AFL - American Fuzzy Lop, Peach Fuzzer, OPC UA Network Fuzzer, Honggfuzz

Abuse case testing - IEC 62443-4-1 requirement SVV-3.2.a

Description:
Abuse case testing involves evaluating how applications might be misused or exploited by malicious actors to uncover potential security weaknesses. It's an extension of use case modeling but focuses on negative scenarios that could lead to vulnerabilities. Description: Abuse case testing models interactions between an attacker and the system, identifying how the system could be harmed. It extends traditional use cases to include malicious actions and their potential impact.

Purpose:
The primary goal is to identify security vulnerabilities that could be exploited. By thinking from an attacker’s perspective, organizations can better understand potential threats.

Fuzzing

Description:
Fuzzing is a dynamic testing technique used to identify vulnerabilities and unexpected behavior in software by inputting random, malformed, or semi-random data into the system. Fuzzing should be performed on all interfaces that parse input data.

Purpose:
The primary objective of fuzzing is to uncover security weaknesses such as crashes, memory leaks, or other anomalies that could be exploited by attackers. By subjecting the software to a diverse range of inputs, fuzzing enhances the robustness and reliability of applications.

Tools: Not Mandatory: Claroty OPC_UA Exploitation Framework, Blackbox-OPC-UA Fuzzing, AFL - American Fuzzy Lop, Peach Fuzzer, OPC UA Network Fuzzer, Honggfuzz, Rex-fuzz, SPIKE

Robustness testing

Description: Robustness testing is a software testing approach designed to verify that an application can gracefully handle erroneous inputs and stressful environmental conditions.

Purpose: The purpose of robustness testing is to ensure that software can handle erroneous inputs and stressful conditions gracefully, maintaining its functionality, reliability, and security even when faced with unexpected or adverse situations..

Tools: Mandatory: Achilles Testing Platform Not Mandatory: NetDisturb Standard Edition

File fuzzing

Description:
File fuzzing involves the examination of applications that process file inputs. It generates and feeds corrupted or unexpected file contents to the application to test how it handles such inputs.

Purpose:
The goal is to uncover vulnerabilities related to file parsing, such as buffer overflows, infinite loops, or improper error handling.

Tools: Not Mandatory: AFL - American Fuzzy Lop, Peach Fuzzer, Honggfuzz

Protocol fuzzing

Description:
Protocol fuzzing targets the communication protocols used by networked applications. It sends malformed or unexpected messages to the application to evaluate its response to unusual or malicious network traffic. Another variant of fuzz testing is protocol fuzzing. For PAPCP, protocol fuzzing is mandatory for Ethernet-enabled embedded devices using the Achilles Satellite unit. This involves modifying communication messages for different protocols.

Purpose:
The aim is to identify vulnerabilities in protocol implementations that could lead to denial-of-service (DoS) attacks, information leakage, or remote code execution. Protocol fuzzing is part of DSAC testing and should be included in pre-DSAC testing where tools are available. DSAC can perform fuzzing of proprietary or other protocols not natively known by tools, using a “traffic capture fuzzer”. This should be requested for all products with proprietary Ethernet-based protocols. It is essential for applications that rely on complex protocols such as HTTP, FTP, and custom network protocols. Achilles Satellite Unit has fuzzers for most known Ethernet-based SCADA protocols such as ModbusTCP, MMS, EthernetI/P, FF-HSE, and OPC UA, as well as common IT protocols like FTP, HTTP, SNMP, and Telnet. To fuzz other protocols, such as vendor-specific protocols, plugins can be built for Netdisturb or WinPCAP.

Tools: Recommendation to use at least 2 of these tools.

Mandatory: Achilles Testing Platform
Not Mandatory: OPC UA Network Fuzzer, SPIKE, Peach Fuzzer

Regular expression fuzzing

Description:
Regular expression fuzzing focuses on testing the regular expressions used within an application to ensure they handle all possible input cases correctly.

Purpose:
The objective is to detect vulnerabilities that can arise from poorly constructed regular expressions, such as catastrophic backtracking or denial-of-service conditions caused by maliciously crafted inputs. It ensures that regex patterns are secure and efficient.

Tools: Not Mandatory: Rex-Fuzz

Flooding

Description: Flooding is a type of Denial of Service (DoS) or Distributed Denial of Service (DDoS) attack where an attacker sends an overwhelming volume of traffic or connection requests to a target system, server, or network.

Purpose: To overwhelm and exhaust a target’s resources, making its services unavailable to legitimate users.

Tools: Not Mandatory: Achilles Testing Platform

Attack surface analysis - IEC 62443-4-1 requirement SVV-3.2.b

Overview A process shall be employed for analyzing the security architecture of the system to identify all points that an attacker could exploit and is a complement to the Threat Model (see Attack Surface Analysis in PCP R&D Processes).

Description:
Attack surface analysis involves examining the security architecture of a product to identify interfaces and surfaces that could be vulnerable to attacks. This analysis helps in determining whether the planned security measures are sufficient to protect against potential threats targeting these surfaces. See the guide Attack Surface Analysis for more information.

Purpose:
The goal is to identify and mitigate vulnerabilities by analyzing the product's interfaces and communication paths, ensuring that all possible attack vectors are considered and secured.

Manual and tool-based analysis

Manual analysis:
Network attack surfaces can be analyzed manually, especially based on an existing threat model. This theoretical and manual analysis of the product's high-level design and architecture can detect issues such as insufficient access control for shared memory areas.

Tool-based analysis:
At a later stage, tools should be used to verify and analyze the attack surfaces in the implemented product, providing a more thorough and automated assessment.

Tools: Mandatory: NMAP, Nessus Professional Not Mandatory: Windows Resource Monitor, Microsoft Attack Surface analyzer 2.0

Information disclosure testing - IEC 62443-4-1 requirement SVV-3.2.c

Description:
This type of testing aims to identify unintentional information leakage through error messages, logs, or other outputs that could provide useful information to attackers.

Purpose:
The goal is to prevent attackers from gaining insights that could aid in further attacks. Information disclosure can reveal sensitive details about the application’s environment, configuration, or internal logic.

Tools:
Information disclosure testing is often conducted manually, complemented by DAST tools to automate the detection process.

Not Mandatory: TruffleHog

SCA - IEC 62443-4-1 requirement SVV-3.2.d

Description:
Software composition analysis (SCA) analyzes the open-source components and libraries used within an application to identify known vulnerabilities. See How-to Perform Binary Composition Analysis for more information.

Purpose:
The purpose of SCA is to ensure that third-party components do not introduce security risks. It helps in managing the risks associated with open-source software by identifying and addressing vulnerabilities.

Tools: Mandatory: Black Duck Hub Not Mandatory: Black Duck Binary Analysis

Penetration testing – IEC 62443-4-1 requirement SVV-4

Description:
Penetration testing simulates a real-world attack to assess the effectiveness of existing security measures. It involves actively trying to exploit vulnerabilities to understand the potential impact on the system.

Purpose:
The primary goal of penetration testing is to evaluate the overall security posture of the application and uncover critical vulnerabilities that could be exploited by attackers. This type of testing helps in understanding how well the application can withstand real attacks and provides insights into potential weaknesses.

Approach: There are different approaches to penetration testing, including:

• Black-box Testing: The tester has no prior knowledge of the system, simulating an external attack.
• White-box Testing: The tester has full knowledge of the system, including source code and architecture, simulating an internal attack.
• Grey-box Testing: The tester has partial knowledge of the system, combining elements of both black-box and white-box testing.

Web application security testing

Description:
Web application security testing, a specialized subset of penetration testing, focuses on assessing the security of web applications. This type of testing specifically targets vulnerabilities unique to web environments, identifying potential security issues that could compromise the application.

Purpose:
The goal is to identify and mitigate vulnerabilities such as cross-site scripting (XSS), cross-site request forgery (CSRF), and SQL injection. Web application security testing ensures that the web application is secure against common web-based attacks.

Tools:
Mandatory: Nessus Professional, OWASP ZAP Not Mandatory: Burp Suite Professional, Metasploit, Invicti

Static code analysis - IEC 62443-4-1 requirement SL-1

Description: This type of analysis examines the source code for potential vulnerabilities and coding errors without executing the code. It helps in identifying issues that could lead to security breaches or functional problems.
See Static Code Analysis for more information.

Purpose: Static code analysis helps developers catch and fix issues early in the development process, reducing the likelihood of vulnerabilities making it into the production environment.

Tools: Not Mandatory: SonarQube, Klocwork

Run-time Verification

Description:
Run-time verification monitors the application during its operation to ensure it behaves securely and correctly.

Purpose:
The goal is to detect and respond to security issues that occur during the application’s operation, providing real-time insights into potential vulnerabilities. Run-time verification as a method of finding security flaws is optional for PAPCP.

Tools: Not Mandatory: Microsoft Application Verifier (AppVerifier)

DSAC

The Device Security Assurance Center (DSAC) is an independent organization within ABB that performs Security Testing for ABB products before the release.

Note: all types of tests documented above shall be considered ‘pre-DSAC’ tests and they shall normally be performed before DSAC testing. The aim is to handle and reduce any risk due to both vulnerabilities and 3rd-party components obsolescence (‘security and operational risks’) before DSAC. It shall not be allowed to send any product for DSAC testing before all issues identified by the above tests are fixed.

All products are required to be tested at DSAC in Bangalore. All issues found during these tests are classified as either High, Medium or Low. This is a security severity that does not correspond directly to product severity. Issues reported with severity High in these tests are to be corrected before G5 of the product project and a plan should be made for the correction of Medium severity issues (preferably within the project).

• DSAC Portal
  Information about DSAC as well as access to documents can be found on DSAC Portal.

• Prepare for test
  Remember to plan ahead by reading the details about the process of Shipping Your Product to DSAC and how to register your test application. The tested product shall be configured as closely as possible to one at a customer site. Enable all protocols and services a user would use under normal conditions.
  Try to put a reasonable workload on the device. Try to recreate the conditions the device would be in if targeted for an attack on site.

Many of our products require some other dependent products to be installed for them to function. Eg: licensing and 800xA Base is required for all 800xA Products. Consider combining multiple products in a single test application since DSAC has a limit of 25 test applications in a monthly test cycle.

• Test tools
  DSAC has a number of dedicated test tools. A complete list of the test tools are available here.

• Reporting and Issue Classification
  The result of the DSAC test is documented in a test report which is reviewed by participants from both DSAC and the responsible development organization. It is important for product owners to review and agree on the classification of the issues found, as well as the future course of action. The issues listed in the final report should be reported as bugs in the local PRC system with Severity according to chapter 5.1. and with a reference to the DSAC ID and a reference to the error report (e.g. PRC number) should be included in the final revision of the test report for future tracing.

• Severity Classification of security vulnerabilities Issues found at DSAC are classified into one of three security severity levels. The severity is defined as the worst status of all available monitors. When these issues are reported in the PRC system for the actual product the severity of the issue need to be translated into one of the product severity levels defined by the used defect handling system. The recommended Severity translation from DSAC to product severity could look like this example, based on BU CT R&D Organizations.

Security Severity (DSAC report)	Product Severity
High	Critical
Medium	High
Low	Medium or Low, decided by product owner

Deviation from this translation can be done if both product manager and Head of Cyber Security for the BU agree.

• Correction of security issues

All high severity issues found during robustness testing shall be fixed before releasing the product (i.e., passing G5 for products developed following the Gate Model). All high severity faults reported and agreed by product team need to be fixed and verified by DSAC before product release. Medium severity issues need to be fixed in the immediate next release. There is no deadline to fix low severity findings.

An issue may be "reclassified". This is relevant if the product team has a strong argument why the severity set by DSAC is not justified. If the head of cyber security agrees to go for reclassification, the product team can request a reclasification form from DSAC. In this the team describes why the severity of the finding is something else than what DSAC initially set. A reclassification can be accepted if the PAPCP head of cyber security, the PA head of cyber security and the DSAC manager all agree to this.

If, after evaluation of a DSAC Medium severity case (Product Severity “High”) it is determined that it is very problematic to correct in the on-going project, a decision can be made by the CCB including at least one cyber security engineer, to defer the correction to the next project, with the expectation that the case, being known in the beginning of a project, will be part of the scope and corrected in that project.

Tool categories descriptions

Static application security testing (SAST)

Overview

• Description:
  SAST involves analyzing the source code or binaries of an application without executing it. This type of testing is performed early in the development cycle, usually during the coding or integration phases.

• Purpose:
  The primary goal of SAST is to identify security flaws such as buffer overflows, SQL injection, cross-site scripting (XSS), and other coding vulnerabilities that can be exploited.

Advantages

• Early Detection:
  Identifies vulnerabilities early in the development process.

• Comprehensive Coverage:
  Analyzes the entire codebase for potential issues.

• Preventative Measure:
  Helps prevent security breaches by addressing vulnerabilities before deployment.

Tools: SAST tools that we use are listed below. These tools provide detailed reports on potential vulnerabilities and offer guidance on how to remediate them. You can read more about these tools further down this page.

Static Code Analysis	Mandatory	Cost	Scanning type	Properties
SonarQube	Yes	Commercial	Automated	Code review & Code quality
KlocWork	Yes	Commercial	Automated	Code review & Code quality
Clang-Tidy	No??	Free	Automated	Code review & Code quality

Software Composition Analysis	Mandatory	Cost	Scanning type	Properties
Black Duck Hub	Yes	Commercial	Automated	Visability into software supply chain
Black Duck Binary Analysis	No	Commercial	Automated	Analyzes executables, libraries, firmware

Dynamic application security testing (DAST)

Overview

• Description:
  DAST tests the application while it is running. Unlike SAST, which examines static code, DAST interacts with the application to find vulnerabilities that are present in the live environment.

• Purpose:
  The goal of DAST is to simulate an attacker’s behavior to uncover runtime vulnerabilities such as broken authentication, insecure communication, and server misconfigurations. This type of testing helps identify issues that might not be evident through static analysis.

Advantages

• Runtime Analysis:
  Identifies vulnerabilities that can only be found when the application is running.

• Realistic Testing:
  Simulates actual attack scenarios to provide a realistic assessment of the application’s security posture.

• Comprehensive Coverage:
  Tests all aspects of the application, including its configuration, deployment, and runtime behavior.

Tools: Common DAST tools for Pre-DSAC testing listed below, some of which can automate the testing process and provide insights into how the application behaves under attack.

DAST tools	Mandatory	Cost	Scanning type	Properties
Achilles Testing Platform	Yes	Commercial	Automated	Robustness, Flooding & Fuzzing tests
Nessus Pro	Yes	Commercial	Automated	Vulnerability scanner
Burp-Suite Pro	No	Commercial	Automated/Manual	Vulnerability scanner for web application
Owas ZAP	Yes	Free	Automated/Manual	Vulnerability scanner for web application
NetDisturb Standard Edition	No	Free	Manual	Network traffic analyzer for anomalies
NMAP	Yes	Free	Automated	Network discovery and scanning
WireShark	No	Free	Manual	Capture and analysis network packets
Lynis	No	Free	Automated/Manual	System auditing
WFuzz	No	Free	Automated	Fuzzing of web applications
Nikto	No	Free	Automated	Web server scanning
Dirb	No	Free	Automated	Directory and file discovery

Tools descriptions

• Achilles Testing Platform
  • Description: Designed specifically for testing industrial control systems (ICS), Achilles Testing Platform simulates various threat scenarios to evaluate the resilience and security of ICS components.
  • Purpose: Achilles performs comprehensive security testing, including protocol fuzzing, flooding, vulnerability scanning, and robustness testing, ensuring that ICS devices can withstand various cyber threats.

• AFL (American Fuzzy Lop)
  • Description: AFL is a coverage-guided fuzzer that is highly effective at finding bugs by generating and mutating inputs to test software.
  • Purpose: AFL uncovers vulnerabilities in file formats and parsing routines, such as buffer overflows and memory corruption issues.

• Blackbox OPC-UA Fuzzing
  • Description: This black box fuzzing solution targets the OPC-UA protocol and is based on the mutational fuzzing engine Boofuzz.
  • Purpose: Blackbox OPC_UA Fuzzing automates the fuzzing process, collects crash information, and supports multiple target implementations.

• Black Duck Binary Analysis
  • Description: Black Duck Binary Analysis is designed to detect open source and third-party dependencies in compiled binaries, executables, libraries, containers, and firmware. It ensures that final packaging does not introduce new vulnerabilities.
  • Purpose: Black Duck Binary Analysis scans compiled binaries to identify open source and third-party components, even if they have been modified. The tool detects exposed sensitive information such as email addresses, authorization tokens, and passwords in binaries. It identifies vulnerabilities in the detected components, providing actionable insights. Using static and string analysis techniques, it accurately identifies components and provides comprehensive reports on the identified components, vulnerabilities, and remediation steps.

• Black Duck Hub
  • Description: Black Duck Hub is a comprehensive Software Composition Analysis tool designed to help organizations manage the security, quality, and license compliance risks associated with open source and third-party code.
  • Purpose: Black Duck Hub identifies and tracks open source components in your codebase. It detects vulnerabilities in open source and third-party dependencies, providing detailed reports and remediation guidance. The tool ensures compliance with open source licenses to avoid legal issues, offering a centralized dashboard for monitoring and managing risks across your projects. Additionally, it integrates with development and DevOps tools for seamless workflow integration.

• Burp Suite Professional
  • Description: Burp Suite is a comprehensive tool for web application security testing. It includes features for scanning web applications and identifying vulnerabilities such as SQL injection, XSS, and more.
  • Purpose: Burp Suite offers manual and automated testing options, allowing security professionals to thoroughly analyze and secure web applications. It also integrates with other security tools for enhanced testing capabilities.

• Clang-Tidy
  • Description: Clang-Tidy is a C++ linter and static analysis tool that detects and fixes common programming errors, style violations, and potential bugs. It is part of the Clang/LLVM ecosystem and provides an extensible framework for code analysis.
  • Purpose: Clang-Tidy is used to improve code quality and maintainability by enforcing coding standards, identifying security flaws, and suggesting optimizations. It is particularly useful for large-scale projects where consistent code practices are crucial.

• Claroty OPC-UA Exploitation Framework
  • Description: This advanced framework is designed for vulnerability research and exploitation of OPC-UA implementations.
  • Purpose: Claroty OPC_UA Exploitation Framework helps identify and disclose vulnerabilities in OPC-UA implementations, including denial-of-service (DoS) attacks, information leakage, and remote code execution.

• Dirb
  • Description: Dirb is an open-source web content scanner that uses dictionary-based attacks to search for existing (and possibly hidden) web objects. It examines web servers to uncover directories and files that may be overlooked by other scanners.
  • Purpose: The main purpose of Dirb is to detect hidden paths and web objects that could be exploited by attackers. It helps security professionals identify directories and files that are not properly protected, ensuring that all potential attack surfaces are secured.

• Honggfuzz
  • Description: Honggfuzz is a security-oriented fuzzer with a rich set of features for thorough testing.
  • Purpose: Honggfuzz is used to detect memory corruption, buffer overflow, and other vulnerabilities in file processing routines.

• Invicti
  • Description: Invicti is a web application security scanner that helps organizations identify and fix vulnerabilities in their web applications and APIs. It combines dynamic application security testing (DAST) and interactive application security testing (IAST) to provide comprehensive security assessments.
  • Purpose: Invicti is used for automated security testing, vulnerability detection, and compliance reporting. It enables businesses to secure their web applications efficiently by detecting security flaws, prioritizing risks, and integrating security into their development workflows.

• Klocwork
  • Description: Klocwork is a static code analysis tool that helps developers detect and fix security vulnerabilities, compliance issues, and coding errors early in the development lifecycle. It supports a wide range of programming languages and integrates with various development environments.
  • Purpose: Klocwork performs real-time analysis as code is written, providing instant feedback to developers. It identifies critical security vulnerabilities, compliance issues, and code defects, offering detailed remediation guidance. The tool also supports complex codebases and large-scale projects, ensuring that security and quality are maintained throughout the development process. Klocwork's integration with CI/CD pipelines enhances the efficiency of the development workflow, promoting a secure and high-quality codebase.

• Lynis
  • Description: Lynis is an open-source security auditing tool for Unix-based systems. It performs a wide range of security checks, including vulnerability assessments, configuration audits, and compliance testing.
  • Purpose: Lynis helps identify security issues, configuration errors, and compliance gaps. It provides detailed reports and actionable recommendations for improving system security.

• Metasploit
  • Description: Metasploit is an open-source penetration testing framework developed by Rapid7. It provides security professionals with tools to simulate cyberattacks, identify vulnerabilities, and test defenses against potential threats.
  • Purpose: Metasploit is widely used for ethical hacking, security assessments, and exploit development. It helps security teams detect weaknesses in systems, improve cybersecurity measures, and train professionals in penetration testing techniques.

• Microsoft Application Verifier (AppVerifier)
  • Description: AppVerifier is a runtime verification tool designed to help developers find subtle programming errors, security issues, and limited user account privilege problems in unmanaged code. It monitors application actions while the application runs, subjects the application to various stresses and tests, and generates a report about potential errors in application execution or design.
  • Purpose: AppVerifier ensures the reliability and security of applications by detecting errors that might be difficult to identify during standard application testing. It helps developers identify and fix issues early in the development process, reducing the cost and effort required to address them later.

• Microsoft Attack Surface analyzer 2.0
  • Description: Microsoft Attack Surface Analyzer is an open-source security tool developed by Microsoft that analyzes the attack surface of a target system. It takes snapshots of the system's state before and after the installation of software or system misconfigurations and reports on potential security vulnerabilities introduced during these changes.
  • Purpose: The primary purpose of Attack Surface Analyzer is to help developers, DevOps engineers, and IT security auditors evaluate the changes in the system's attack surface caused by software installations or system misconfigurations. It allows users to identify and assess potential security risks introduced by new software or changes to the system configuration.

• Nessus Professional
  • Description: Nessus is a vulnerability scanner that identifies vulnerabilities, misconfigurations, and security gaps in an IT infrastructure. It provides detailed reports and remediation guidance.
  • Purpose: Nessus is used to perform comprehensive network security assessments, identifying vulnerabilities that could be exploited by attackers.

• NetDisturb Standard Edition
  • Description: NetDisturb is an IP network emulator software that generates user-defined impairments such as latency, delay, jitter, bandwidth limitation, packet loss, duplication, and modification of packet content. It operates as a bridge between two Ethernet segments and supports bi-directional packet transfer on Ethernet, Fast Ethernet, and Gigabit network interface cards.
  • Purpose: The primary purpose of NetDisturb is to disturb flows over IP networks to study the behavior of applications, devices, or services in a "disturbed" network environment. It is used for development assistance, performance and acceptance tests, configuration and control of IP equipment, and testing applications.

• Nikto
  • Description: Nikto is an open-source web server scanner written in Perl. It performs comprehensive tests to identify potentially dangerous files, outdated server software, server configuration issues, and installed web servers.
  • Purpose: The primary purpose of Nikto is to identify potentially dangerous files, outdated server versions, and server misconfigurations that could be exploited by attackers. By providing detailed scan results, Nikto helps administrators enhance the security posture of their web servers.

• Nmap
  • Description: Nmap (Network Mapper) is a powerful open-source tool used for network discovery and security auditing. It can identify open ports, running services, and potential vulnerabilities in networked devices.
  • Purpose: Nmap is used to analyze network attack surfaces, providing insights into the network configuration and potential entry points for attackers.

• OPC UA Network Fuzzer
  • Description: Fuzzing the OPC UA (Open Platform Communications Unified Architecture) protocol. It sends a large number of random or targeted network requests to identify vulnerabilities in network protocol implementations by monitoring responses for unexpected behavior or crashes.
  • Purpose: The primary purpose of running the OPC UA Network Fuzzer is to identify and fix potential vulnerabilities in OPC UA implementations, ensuring the security and reliability of industrial communication systems.

• OWASP ZAP
  • Description: OWASP ZAP (Zed Attack Proxy) is an open-source web application security testing tool designed to find vulnerabilities in web applications during development and testing phases.
  • Purpose: OWASP ZAP helps developers, testers, and security professionals identify and fix security vulnerabilities such as SQL injection, cross-site scripting (XSS), broken authentication, and insecure direct object references (IDOR) in web applications, ensuring they are secure before deployment.

• Peach Fuzzer
  • Description: Peach Fuzzer is a robust tool that allows for the creation of custom fuzzing templates to test various file formats and protocols.
  • Purpose: Peach Fuzzer is used to identify vulnerabilities in file parsing and handling, ensuring robustness against malformed inputs.

• Rex-fuzz
  • Description: Rex-fuzz is a fuzzing tool designed to test software by bombarding it with invalid, random, or malformed inputs.
  • Purpose: Rex-fuzz uncovers crashes, vulnerabilities, or unexpected behavior in software applications.

• SonarQube
  • Description: SonarQube is an open-source platform for continuous inspection of code quality. It performs automatic reviews with static analysis of code to detect bugs, code smells, and security vulnerabilities.
  • Purpose: SonarQube integrates seamlessly with DevOps pipelines to provide continuous feedback and insights on code quality. It supports multiple programming languages, making it versatile for various development environments. The platform includes detailed dashboards and reports that help developers identify and fix issues early in the development process. SonarQube's rule-based engine provides recommendations for best practices, helping improve overall code quality and maintainability.

• SPIKE
  • Description: SPIKE is a protocol fuzzer creation kit that provides an API for creating fuzzers for network-based protocols using C++.
  • Purpose: SPIKE finds exploitable bugs in network protocols by constructing fuzzed messages called "SPIKES" and sending them to network services.

• TruffleHog
  • Description: TruffleHog is an open-source tool that scans through Git repositories (and other sources) to identify sensitive information, such as API keys, passwords, and private encryption keys, which might have been accidentally committed.
  • Purpose: TruffleHog helps uncover sensitive credentials that have been inadvertently included in the codebase. Integrating TruffleHog into CI/CD pipelines ensures continuous monitoring and protection against leaked credentials. It also assists organizations in maintaining compliance with security standards and best practices.

• Wfuzz
  • Description: WFuzz is an open-source web application fuzzer designed to allows any input to be injected in any field of an HTTP request, allowing to perform complex web security attacks in different web application components such as: parameters, authentication, forms, directories/files, headers, etc.
  • Purpose: WFuzz helps penetration testers and security professionals discover and exploit web application vulnerabilities, ensuring that these applications are secure before deployment.

• Windows Resource Monitor
  • Description: Windows Resource Monitor is a built-in tool that provides real-time information about system resources, including CPU, memory, disk, and network usage.
  • Purpose: It can be used to show TCP connections and listening ports, helping to identify open network connections that could be potential attack surfaces.

• Wireshark
  • Description: Wireshark is a network packet analyzer that captures and inspects network traffic in real time. It provides detailed insights into network protocols, packet structures, and communication flows, making it an essential tool for network analysis.
  • Purpose: Wireshark is widely used for network troubleshooting, security analysis, and protocol development. It helps network administrators diagnose issues, security engineers detect vulnerabilities, and developers debug network applications.