Security testing

🌐 This document is available in both English and Ukrainian. Use the language toggle in the top right corner to switch between versions.

1. Introduction

The purpose of the security testing approach is to outline the strategy, objectives, and scope of security testing for the Registries Platform. It provides a thorough description of how security vulnerabilities are identified and addressed to ensure the protection of sensitive data and maintain the integrity of the application.

1.1. Scope of the Security Testing

The security testing focuses on identifying vulnerabilities within the Registries Platform web application and related infrastructure. It covers areas such as authentication, authorization, input validation, session management, data encryption, and secure configuration.

1.2. Objectives

The main objectives of security testing are:

  • Identify security vulnerabilities and weaknesses in the application.

  • Assess the effectiveness of existing security controls.

  • Address identified vulnerabilities and improve the overall security posture.

1.3. References

The Registries Platform is developed in accordance with the following security standards:

  • The software security posture management according to OWASP Software Assurance Maturity Model (SAMM).

  • The OWASP Application Security Verification Standard (ASVS) Project as a basis for testing the web application’s technical security controls and a source of requirements for secure development.

  • Center for Internet Security Software Supply Chain Security Guide (CIS SSCS) as a basis for supply chain security.

  • Comprehensive information protection system (CIS) as a legislative certification for information security controls, a set of technical measures that ensure information protection in an Information and Communication Technology (ICT) system.

2. Security Testing Approach

2.1. Security Testing Methodologies

The security testing follows a combination of manual and automated testing approaches. It includes vulnerability scanning, penetration testing, code reviews, GitOps security, cloud security posture management, and security best practices analysis.

Security testing methodologies are systematic approaches used to identify and assess security vulnerabilities and weaknesses in software applications, networks, or systems. They help ensure that security testing is conducted effectively and comprehensively. Here is the list of used security testing methodologies:

  • Penetration Testing (Pen Test): Penetration Testing, often referred to as "pen testing" or "ethical hacking," is a method of assessing the security of a computer system, network, application, or organization by simulating real-world cyberattacks. The primary objective of penetration testing is to identify vulnerabilities and weaknesses that malicious attackers could exploit to compromise the system or steal sensitive information.

  • Threat Modeling: Threat modeling involves identifying potential threats and risks to a system or application. It helps in understanding possible attack vectors and aids in making informed decisions about security measures. We are striving to adopt continuous threat modeling, which is an iterative and ongoing process of identifying and analyzing potential security threats and risks throughout the entire software development lifecycle.

  • Secure Software Development Lifecycle (SSDLC): SSDLC is a structured and systematic approach to software development that integrates security practices at every stage of the development process.

  • Secure Architecture Assessment: The architecture assessment approach ensures that the application and infrastructure architecture adequately meets all relevant security and compliance requirements and sufficiently mitigates the identified security threats.

2.2. Tools and Technologies Used

The following types, tools, and technologies are used during security testing:

Security testing type

Toolset

Static Application Security Testing (SAST)

Semgrep

Software Composition Analysis (SCA)

  • CycloneDx SBOM

  • OWASP Dependency Track

Secrets scanning

Detect Secrets

IaaC security

KICS

Container orchestration security

Kube bench

Container security

Trivy

Dynamic Application Security Testing (DAST)

OWASP ZAP

Security Cloud Posture Management

Qualys CloudView

2.3. Description of the Test Environment

Security testing is continuously conducted in a separate prod-like environment owned and managed by the security team.

3. Security Test Scenarios

Here is a set of specific test cases or situations designed to evaluate the security aspects of the Registries Platform:

Information Leak

Buffer Overflow

Cloud Metadata Attack

Code Injection

Command Injection

Cross-Site Scripting (Reflected)

Cross-Site Scripting (Persistent)

CRLF Injection

Directory Browsing

External Redirect

Format String Error

GET for POST

Heartbleed OpenSSL Vulnerability

Hidden File Finder

Log4Shell (CVE-2021-44228 and CVE-2021-45046)

Padding Oracle

Parameter Tampering

Path Traversal

Remote Code Execution - CVE-2012-1823

Remote File Include

Server Side Include

Server-Side Template Injection

Source Code Disclosure

Spring4Shell (CVE-2022-22965)

SQL Injection

User Agent Fuzzing

XPath Injection

XSLT Injection

XXE

ICMP checks

Port checks

Check SSL/TLS

Content Security Policy (CSP)

HSTS

Re-registration

Overwrite the existing user

Uniqueness of the username

Weak Password Policy

Email Confirmation

Disposable Email Addresses

Fuzz folder

Long password (200+)

Authentication Testing

JSON attack

Resistance to password-guessing

XSS to name or email

Failure to confirm password when changing email, password or 2FA

User account blocking mechanism

Rate limit

Check redirect on registration page after login

Broken Access Control

Test tokens for predictability

Disclosure of Tokens

Safe termination of the session

Session fixation

CSRF

Cookie scope

Decode Cookie (Base64, hex, URL, etc.)

Expiration of cookies

Reuse of cookie after closing the session

Log out and press the "return" function in the browser (Alt + left arrow)

Two instances are open, change or reset the 1st instance, update the 2nd instance

IDOR user profile

CSRF user profile

Email validate

IDOR parameters

Check the policies for different roles

Fuzzing all request parameters

Reflected XSS

HTTP header injection in GET & POST (X Forwarded Host)

RCE via Referer Header

SQL injection via User-Agent Header

Arbitrary redirection

Stored attacks

Script injection

XPath injection

XXE in any request, change content-type to text/xl

Stored XSS

HTTP Request Smuggling

Open redirect

SSRF in previously discovered open ports

4. Test Data

The testing process uses data that is inherently open. This data is publicly accessible and available at https://data.gov.ua/dataset. Real and pure data is not used during the testing process.

5. Test Execution Phases

5.1. Architecture review

During the architecture review of a new feature, we examine the correct provision of general security mechanisms such as authentication, authorization, user and rights management, secure communication, data protection, key management, and log management.

We verify that the solution architecture addresses all identified security and compliance requirements. All the application interfaces are analyzed against the list of security and compliance requirements. Additionally, the dataflow is amenable to analysis to ensure that the requirements are adequately addressed over different components.

The analysis types mentioned above are performed on both internal interfaces, e.g. between tiers, as well as external ones, e.g. those comprising the attack surface.

5.2. Threat modeling

We are striving to adopt the continuous threat modeling approach and build an iterative and ongoing process of identifying and assessing potential security threats and vulnerabilities throughout the entire software development lifecycle. Currently, the threat model is made for the entire application and almost all the changes are incrementally modeled to discover possible new threats.

5.3. Automated scanning

The development of the Registries Platform is performed following the Secure Software Development Life Cycle (SSDLC) approach. Automated security scanning plays a crucial role in SSDLC by helping to identify and mitigate security vulnerabilities and weaknesses in the software early in the development process. It is an essential component of the SSDLC, providing continuous security testing and feedback throughout the development lifecycle.

Plenty of security controls have been integrated into the CI/CD pipelines. All of them were integrated with the vulnerability management system to build security quality gates, which can break the pipeline according to the set criteria for a particular service or condition. There is also an exception mechanism in place to bypass this behavior if the risk of a particular vulnerability has been accepted or mitigated. These cases are explicitly approved first and all occurrences are logged together with a rationale.

All the services developed in-house automatically go through the list of security controls when a new change is introduced.

  • Static application security testing

  • Software composition analysis

  • Detection of sensitive information disclosure

  • Security of helm charts used for service deployment

  • Overall code quality checks

  • Container security

Once all the quality gates are passed successfully, the artifact is deployed in a separate security environment, where the dynamic testing happens. Dynamic Application Security Testing (DAST) is a type of security testing that involves assessing the security of an application while it is running or is in a dynamic state. The primary goal of DAST is to identify security vulnerabilities and weaknesses that may not be apparent in the application’s source code but could be exploited when the application is running.

There are six phases of Dynamic Application Security Testing for every change:

  • Environment configuration

  • Automated test data ingestion by application and dataflow recording by security framework to automatically reveal the dataflow and structure.

  • Authentication testing

  • Web application vulnerability scanning

  • REST API vulnerability scanning using updated contracts

  • Results are imported into the vulnerability management system for further analysis by a security engineer

This way, we utilize a thorough approach for proactively finding and fixing vulnerabilities to enhance the security posture of the Registries Platform and protect it against potential cyber threats.

5.4. Penetration testing

Penetration testing is performed annually by third-party vendors on a dedicated prod-like environment. The report is triaged, sorted, and consumed by the vulnerability management system to mitigate any found issues.

6. Vulnerability management

Vulnerability management is a proactive approach to gather, assess, prioritize, and remediate security vulnerabilities in an organization’s information systems, applications, and network infrastructure. The goal of vulnerability management is to reduce the organization’s exposure to potential cyber threats and attacks by addressing weaknesses before they can be exploited by malicious actors. This is a continuous and cyclical process.

We use OWASP DefectDojo to aggregate vulnerabilities all over the Platform development process. Every scan result from all development pipelines is consumed by DefectDojo for deduplication, grouping, false-positive analysis, and keeping the up-to-date status of discovered vulnerabilities.

The vulnerability management system is deeply integrated with the ticketing system, which enables us to lead the defect throughout the entire project task management process and transparently accompany it through the mitigation process.

Additionally, it contains the important and most complete history of all vulnerabilities discovered on the project. Using this information, we can easily track down any decision made like risk acceptance, etc.

This approach is also quite useful for high-level vulnerability analysis to spot patterns and quick wins and improve the general security posture.

Eventually, the vulnerability management system is a source of truth for our security engineers.

7. Reporting

We use the vulnerability management system’s reporting capabilities to generate reports of different immersion levels to get insight into the overall picture of the Registries Platform development and to adjust the security program.