MOVEit Transfer Data Breach

A vulnerability in MOVEit, a managed file transfer (MFT) software, allowed attackers to access its database without authentication, enabling SQL execution to modify or delete entries and analyze its structure. The stored data was vulnerable to exfiltration by the hackers.

Tools as entry point to your system:

• Exposure of confidential data: MOVEit was supposed to allow data secure transfer even outside of the secure company network. Due to the CVE everyone could access data managed by MOVEit.

• Privacy Impact: High critical data e.g. driver’s licenses, permits and ID cards were accessed by the hackers.

• Weaponizing information: Critical data such as driver’s licenses and ID cards can be used for identity theft. If it is possible to upload compromised information, targeted misinformation could be spread. And in this way, critical processes can be targeted.

Do you analyze your Code properly?

Toyota Source Code Leak

Toyota disclosed a security breach in which a credential providing access to customer data was accidentally exposed in a public GitHub repository for nearly five years. The issue stemmed from a subcontractor uploading source code to a public repository which included a hardcoded access key to a server containing customer information. This exposed the data of 296,019 customers, potentially including identification numbers and email addresses.

Quick commit big impact:

• Development meets production: The mixture of development activities, productive servers and missing credential scanning made this incident possible.

• A mistake that happens all too easily: Hardcoding secrets is a major issue in software development. What might start as a quick test can lead to secrets being forgotten and uploaded, lingering in the project’s history.

• The Key to a well secured Vault: Credentials such as SSH-Keys are considered as very secure but once they become public an attacker can use them as easily as going through an open door.

Are your secrets stored safe and secure?

Ken Thompson Hack

The “Ken Thompson Hack” reveals a devastating reality: even your most trusted tools can be weaponized against you. This sophisticated attack doesn’t exploit just your software, it corrupts the entire building environment that creates the product itself.

The Hidden Threat:

• Invisible Backdoors: A compromised compiler silently embeds vulnerabilities, bypassing even the most rigorous source code reviews.

• Widespread Exposure: Every product built with the tampered toolchain becomes a potential target.

• Grave Consequences: From CVE exploitation to physical harm in safety-critical systems, the “fallout” is catastrophic.

How do you ensure your compiler delivers reliable results, every time?

XZ - Utils

XZ-Utils, a key component of OpenSSH for Linux server maintenance, was once targeted by a malicious actor. Thankfully, the obfuscated backdoor that the attacker had introduced was detected, reported, and fixed before it could be published for common usage.

The Risks are Real:

• Infiltration of Trusted Tools: Threat actors target open-source projects to introduce vulnerabilities.

• Undetectable Threats: Obfuscated backdoors can grant attackers total control without leaving any trace.

• High-Stakes Targets: Compromising essential tools such as OpenSSH could lead to an entire takeover of your system.

Would you have spotted the subtle 500ms delay that was the key sign of a backdoor exploit?

Stuxnet

In 2010, the Stuxnet attack showed how vulnerable critical systems can be. This cyberweapon infiltrated industrial tools, secretly altering their operations to cause physical damage to the nuclear gas centrifuges while showing “normal” condition to monitoring systems.

First digital strike against physical targets:

• Highly Critical Systems: The air gapped nuclear facility got compromised.

• Physical Impact: First documented failure of mechanical components due to a cyber attack.

• Consequences: The nuclear facility went down for a month, and no one saw it coming.

See Everything you need to know about Stuxnet - Tech Monitor for the details

Would you have noticed the changes?

Pillar 1: Develop Secure Software

Proactive software security requires designing systems with security as a fundamental principle, defining clear requirements, and ensuring that all stakeholders, including third-party vendors, comply with these standards.

Therefore, developers must be trained in secure coding practices to write resilient code aligned with these requirements.

Continuous code review and testing, integrated throughout the Software Development Life Cycle (SDLC), helps identifying vulnerabilities early, thus saving time and reducing costs.

Staying agile and vigilant is crucial, as developers must analyze vulnerabilities, learn from root causes, and adapt their processes to prevent future issues. Keeping pace with evolving best practices ensures that the development process remains robust and forward-thinking, ready to address emerging security challenges.

Validas contributes to this pillar by making your used tools & libraries secure (see Pillar 2 and 3).

Pillar 2: Use Secure Tools

Modern software development relies on tools, which enable teams to specify, design, implement, test and analyze code.

These tools facilitate crucial processes, beginning from planning and requirements definition over development and codebase management and testing against safety and security requirements ending in the deployment.

In order to ensure tool security, i.e. tools do not cause harms, the tool risks have to be analyzed, and managed in a proper way. Identified tool security risks should be reduced and the remaining tool risks should be handled, e.g. by following a tool security manual.

Tools can be classified (“Tool Security Classification”) according to their potential tool risks and the need to be reduced by “Tool Security Qualification”. We identify potential risks, and implement effective mitigation strategies that are critical steps to safeguard your software.

For more information see for example: Tool Readiness Check

Pillar 3: Use Secure Software Libraries

Third-party software libraries, including open-source components, are essential for development in general. Libraries provide functionality from an external source. Basically it introduces external code that is executed together with your own code in your product.

The integration of external code might introduce potential vulnerabilities that can directly impact the integrity of your product. By utilizing these libraries, you take responsibility for addressing any vulnerabilities (from the used libraries) that are now exposed within your software.

By conducting thorough analysis via Library Qualification, we identify potential risks, and implement effective mitigation strategies that are critical steps to safeguard your software.

Also, by using these methods proactively, you fortify your product’s security and reinforce the trust in its reliability and resilience.

For more information see for example:

• Qualification
• C++ Template Library Qualification Kit

The certified Validas Qualification Process (see link) covers the tool relevant parts of security standards like ISO/SAE 21434. Tools are essential for ensuring the integrity of critical systems.

For tool security, the tool risks have to be managed, i.e. analyzed (“classified”), reduced (“qualified”) and the remaining ones need to be handled. This has to be documented. Validas AG creates the following documents for you:

• STCR: Security Tool Classification Report (“analze”)

• STQP/STQR: Security Tool Qualification Plan/Report (“reduce”)

• STM: Security Tool Manual (“handle”)

Validas helps to reduce tool qualification costs by Tool Chain Classification and identifying critical tools for your use case without reducing the overall security. Qualify only the tools you really need to qualify!

The first risk analysis of your tool is free of charge! Contact us for a cost free tool risks analysis including:

• Description of the tool & use cases

• Inputs and outputs of the tool

• tool risks identification

• tool risk classification

• proposed risk reduction methods

Second step is to select and establish security risk reduction and handling methods. Our experts will guide you through this steps.

Finally we create the standard compliant tool security documents for you. We follow our certified qualification process and thereby guarantee success, i.e. no delays or extra costs due to failing security assessments for ISO/SAE 21434.

• STCR: Security Tool Classification Report

• STQP/STQR: Security Tool Qualification Plan and Report

• STM: Security Tool Manual

• PR/CR: Validas Certified Tool Management Process (PR) and compliance report (CR) with ISO/SAE 21434.

• Security Qualification Kit user guide (only for tool providers)