Tag Archives: security

The Hidden Dangers of Bidirectional Characters

Discover the hidden dangers of bidirectional control characters! We dive deep into how these essential text-rendering tools can be exploited to manipulate digital environments. Learn about their security risks, from filename spoofing to deceptive URLs, and uncover the crucial strategies to safeguard against these subtle yet potent threats. Understand how to protect your systems in a multilingual world. Join to ensure your digital security is not left to chance!

Key Bidirectional Control Characters

Bidirectional control characters (often abbreviated as bidi control characters) are special characters used in text encoding to manage the direction of text flow. This is crucial for languages read right-to-left (RTL), like Arabic and Hebrew, when mixed with left-to-right (LTR) languages like English. These characters help to ensure that the text is displayed in the correct order, regardless of the directionality of its parts.

Here are some of the common bidi control characters defined in the Unicode standard:

Left-to-Right Mark (LRM) – U+200E: 

They are used to set the direction of the text from left to right. It is particularly useful when embedding a small piece of LTR text within a larger segment of RTL text.

Right-to-Left Mark (RLM) – U+200F: 

This setting sets the direction of the text to right-to-left. It is used when embedding a small RTL text within a larger segment of LTR text.

Left-to-Right Embedding (LRE) – U+202A: 

They are used to start a segment of LTR text within an RTL environment. This embedding level pushes onto the directional status stack.

Right-to-Left Embedding (RLE) – U+202B: 

They are used to start a segment of RTL text within an LTR environment.

Pop Directional Formatting (PDF) – U+202C: 

They are used to end a segment of embedded text, popping the last direction from the stack and returning to the previous directional context.

Left-to-Right Override (LRO) – U+202D: 

It forces the text within its scope to be treated as left-to-right text, regardless of its directionality. This is useful for reordering sequences of characters.

Right-to-Left Override (RLO) – U+202E: 

Forces the text within its scope to be treated as right-to-left text, even if it is typically LTR. This can be used to display text backwards, which might be used for effect or in specific contexts.

Uses and Applications

Bidirectional control characters are essential for the following:

Multilingual Documents: Ensuring coherent text flow when documents contain multiple languages with different reading directions.

User Interfaces: Proper text rendering in software that supports multiple languages.

Data Files: Manage data display in multiple languages with different directionalities.

Some Demos

Bidirectional control characters can pose security risks. They can be used to obscure the true intent of a code or text, leading to what is known as a “bidirectional text attack.” For instance, filenames could appear to end with a harmless extension like “.txt” when they end with a dangerous one like “.exe” reversed by bidi characters. As a result, users might need to be more informed about the nature of the files they interact with.

Security-aware text editors and systems often have measures to detect and appropriately display or alert users about the presence of bidirectional control characters to mitigate potential security risks.

Here’s a simple Java demo that illustrates how bidirectional control characters can be used to create misleading filenames. This can demonstrate the potential danger, particularly in environments where filenames are manipulated or displayed based on user input.

Java Demo – Right-to-Left Override (RLO) Attack 

This demo will:

Create a seemingly harmless text file named “txt.exe” using bidirectional control characters. The file will output the actual and displayed names to show the discrepancy.

Explanation

Creation of Names: The deceptive file name is created using the right-to-left override character (`U+202E`). This causes the part of the filename after the bidi character to be interpreted as right-to-left, making “exe.txt” look like “txt.exe” in some file systems and interfaces.

File Creation: The program attempts to create files with standard and deceptive names.

Output Differences: When printed, the deceptive name will show the filename reversed after the bidi character, potentially misleading users about the file type and intent.

To see the effect:

– Compile and run the Java program.

– Check the output and the file system to observe how the filenames are displayed.

Java Demo – Right-to-Left Mark (RLM) Attack

Let’s examine a Java example that demonstrates how a Right-to-Left Mark (RLM) can be critical in ensuring the correct display and handling of mixed-direction text. This example will simulate a simple scenario where Arabic and English text are combined, highlighting how the RLM character helps maintain the intended order of words.

This Java example will:

1. Combine English and Arabic text in a single string.

2. Use the Right-to-Left Mark (RLM) to manage the display order correctly.

3. Print out the results to illustrate the effect of using RLM.

Explanation

Arabic and English Text: Arabic is inherently right-to-left, whereas English is left-to-right.

Concatenation without RLM: Depending on the environment, simply concatenating Arabic and English text might not always display correctly, as the directionality of the English text can disrupt the flow of the Arabic.

Concatenation with RLM: By inserting a Right-to-Left Mark after the Arabic text but before the English text, the English part is correctly treated as part of the right-to-left sequence. This ensures the English text is read in its natural order but positioned correctly within the overall RTL context.

When you run this program, especially in a console or environment that supports bidirectional text:

The “Without RLM” output may show the English text misplaced or improperly aligned relative to the Arabic text.

The “With RLM” output should show the English text correctly placed and maintain the natural reading order of both languages.

This example underscores the importance of RLM in software and user interfaces dealing with multilingual data. It ensures that text is presented in a way that respects the reading order of different languages. Proper handling of bidirectional text is crucial in applications ranging from document editors to web content management systems.

But why is this a security issue?

Bidirectional control characters like the Right-to-Left Mark (RLM) are a security concern primarily due to their ability to obscure the true intent of text and data. This ability can be exploited in various ways to mislead users or automated systems about the content or function of data, leading to potential security vulnerabilities. Here are some specific scenarios where this becomes critical:

File Name Spoofing

One of the most common security issues related to bidirectional control characters is file name spoofing. Attackers can use bidi characters to reverse the order of characters in a file’s extension in file names, making a malicious executable file appear as a harmless type, such as a text file. For instance, the file named `doc.exe` might be displayed as `exe.cod` in systems that do not handle bidi characters properly, tricking users into thinking it’s merely a document.

Phishing Attacks

In phishing emails or misleading links, bidi characters can be used to reverse parts of a URL to mimic a trusted domain, leading users to malicious sites. For example, what appears to be `example.com` in reversed parts could be a link to an entirely different and dangerous site, exploiting the user’s trust in familiar-looking URLs.

Code Obfuscation

Developers or malicious coders might use bidi characters to obscure code logic or comments in software, making it difficult for security analysts or automated tools to assess the code’s behaviour accurately. This can hide malicious functions or bypass security audits.

Misleading Data and Database Entries

Bidi characters can be used to reverse strings in database entries, potentially leading to incorrect or misleading data processing. This could be exploited to bypass filters and validation checks or to intentionally corrupt data integrity.

User Interface Deception

In applications with user interfaces that display user input data, bidi characters can create a misleading representation of that data. This could need to be clarified for users or lead them to make incorrect decisions based on incorrectly displayed information.

Addressing the Security Risks

Addressing the security risks associated with bidirectional control characters (bidi characters) requires a multifaceted approach that includes technical safeguards and user education. Here are more detailed strategies that organizations and software developers can employ to mitigate these risks:

Input Validation and Sanitization

Strict Validation Rules: Implement strict validation rules that check for the presence of bidi characters in sensitive contexts such as file names, URLs, and input forms. This validation should identify and flag or reject unexpected or unauthorized use of these characters.

Character Filtering: For applications not requiring bidi characters, remove them from inputs during the data entry or ingestion process. For applications where such characters are necessary, ensure they are used correctly and safely.

Encoding Techniques: Use encoding techniques to handle potentially dangerous characters safely. For example, HTML entities can encode bidi characters in web applications, preventing them from being processed as active components of the code.

Secure Default Configurations

Display Controls: Configure systems and applications to visually distinguish or neutralize bidi characters, particularly in environments where their use is rare or unexpected. This could involve displaying their unicode point instead of the character or providing visual indicators of text direction changes.

Limit Usage Contexts: Restrict the contexts in which bidi characters can be used, especially in identifiers like usernames, filenames, and URLs, unless there is a specific need for them.

User and Administrator Education

Awareness Training: Conduct regular training sessions for users and administrators about potentially misusing bidi characters and other Unicode anomalies. Include real-world examples of how these features can be exploited.

Best Practices for Content Creation: Educate content creators on the correct and safe use of bidi characters, emphasizing the security aspects of text directionality in content that will be widely distributed or used in sensitive environments.

Enhanced Monitoring and Logging

Anomaly Detection: Use advanced monitoring tools to detect unusual bidi character usage patterns in system logs, network traffic, or transaction data. This can help identify potential attacks or breaches early.

Audit Trails: Maintain robust audit trails, including detailed logging of input validation failures and other security-related events. This can help with forensic analysis and understanding attack vectors after a security incident.

Security Policies and Procedures

Clear Policies: Develop and enforce clear security policies regarding handling bidi characters. This includes guidelines for developers handling text input and output and policies for content managers reviewing and approving content.

Incident Response: Include the misuse of bidi characters as a potential vector in your organization’s incident response plan. Prepare specific procedures to respond to incidents involving deceptive text or file manipulations.

Technological Solutions

Development Frameworks and Libraries: Utilize frameworks and libraries that inherently handle bidi characters safely and transparently. Ensure that these tools are up-to-date and configured correctly.

User Interface Design: Design user interfaces that inherently mitigate the risks posed by bidi characters, such as displaying full file extensions and using text elements that visually separate user input from system text.

Implementing these strategies requires a coordinated effort between software developers, security professionals, system administrators, and end-users. Organizations can significantly reduce the risks of bidi characters and other related security threats by adopting comprehensive measures.

Conclusion:

In conclusion, while often overlooked, the security risks associated with bidirectional control characters are significant and can have profound implications for individuals and organizations. These characters can be exploited in various deceptive ways, from file name spoofing and phishing attacks to code obfuscation and misleading data presentations. To effectively mitigate these risks, a comprehensive and multi-layered approach is necessary.

This approach should include stringent input validation and sanitization processes to filter out or safely handle bidi characters where they are not needed and to ensure they are used appropriately where they are necessary. Secure default configurations that visually indicate the presence and effect of bidi characters can help prevent their misuse, while robust monitoring and logging can aid in detecting and responding to potential security threats.

Education also plays a crucial role. Users and administrators need to be aware of how bidi characters can be used maliciously, and developers need to be informed about best practices for handling such characters in their code. Security policies must be clear and enforced, with specific guidelines on handling bidi characters effectively and safely.

Finally, employing technological solutions that can handle these characters appropriately and designing user interfaces that mitigate their risks will further strengthen an organization’s defence against the security vulnerabilities introduced by bidirectional control characters. By addressing these issues proactively, we can safeguard the integrity of digital environments and protect sensitive information from being compromised.

Audio Steganography In More Detail

Audio steganography is a technique for hiding information within an audio file so that only the intended recipient knows of the hidden data’s existence. This method belongs to the broader field of steganography, which itself is a subset of security systems and comes from the Greek words “steganos,” meaning covered, and “graphein,” meaning writing.

The primary objective of audio steganography is to conceal the presence of secret data by embedding it into an audio signal without noticeable degradation of the signal. Unlike cryptography, which secures the contents of a message through encryption, steganography focuses on concealing the fact that there is a hidden message.

Methods of Audio Steganography

There are various techniques used to embed data within audio files, including:

Least Significant Bit (LSB) Insertion: 

This is one of the simplest methods where bits of the hidden data are inserted into the least significant bits of the audio file. Because these modifications are slight, they are generally imperceptible to the human ear.

Phase Coding: 

Phase coding is a sophisticated technique used in audio steganography to embed information within an audio file by manipulating the phase of the sound signal. This method leverages the fact that the human auditory system is far less sensitive to phase changes than it is to changes in amplitude or frequency. As such, phase coding can be a very effective way to hide information without noticeable changes to the sound quality as perceived by human listeners.

How Phase Coding Works

Phase coding is typically applied to the phase spectrum of a sound signal. The process involves several steps:

Signal Decomposition: The original audio signal is divided into segments using a Fast Fourier Transform (FFT) transform. This decomposition converts the time-domain signal into the frequency domain, where each component has an amplitude and a phase.

Phase Manipulation: The phase of the audio file’s initial segment (or a reference segment) is adjusted to embed the secret data. The phases of subsequent segments are then altered to ensure a smooth transition between segments, maintaining the perceptual integrity of the audio signal. This is crucial to prevent artefacts that could be detectable by the human ear.

Data Embedding: The binary data to be hidden is typically encoded in the phase changes between successive segments. A simple method might involve using the presence or absence of a phase shift as a binary one or zero respectively.

Signal Reconstruction: After the phase modification, the segments are transformed back to the time domain, recombining them to produce the final audio signal with the hidden data embedded.

Advantages of Phase Coding

Subtlety: Since human ears are not particularly sensitive to phase variations, especially in complex sounds with many overlapping frequencies, this method can hide data effectively without audible distortion.

Robustness to Compression: Phase coding can be relatively robust against lossy compression, especially compared to methods like LSB insertion, which such processes can disrupt.

Challenges and Considerations

Complexity: Implementing phase coding requires careful handling to maintain the coherence of the phase between segments. Poor implementation can result in noticeable audio artifacts.

Data Capacity: While phase coding is discreet, it typically offers lower data capacity compared to other steganographic techniques. This is because excessive manipulation of phase information can lead to perceptible sound quality degradation or inconsistencies.

Dependency on Sound Content: The effectiveness of phase coding can depend heavily on the type of audio being used. Complex signals with many frequency components (like music) offer more opportunities for phase manipulation without detection than more straightforward signals (like speech).

In summary, phase coding is a powerful but complex technique in audio steganography, offering a high level of discretion for embedding data within audio files. Its successful application requires careful handling to balance data capacity, sound quality, and robustness against signal processing.

Spread Spectrum: 

In this method, the secret message is spread across the frequency spectrum of the audio file. This spreading makes the message less susceptible to intentional or unintentional modifications.

This technique is based on spread spectrum communication technology principles, initially developed for military use to ensure secure and robust communication over radio waves.

How Spread Spectrum Works

In the context of audio steganography, spread spectrum involves embedding a secret message into an audio signal by slightly altering its frequency components. The process typically follows these steps:

Data Preparation: The data to be hidden is first prepared, often by encoding it in a binary format. This binary data is then spread out over a larger bandwidth than it would normally occupy, which helps in disguising its presence.

Signal Spreading: The spread data is combined with a pseudo-noise code (PN code) or a similar key that only the sender and intended recipient know. The PN code has properties similar to noise but with a known structure, making it possible to detect and decode the data without being detected by unintended listeners.

Modulation: The combined data and PN code modulate the host audio signal, typically using techniques like Direct Sequence Spread Spectrum (DSSS) or Frequency Hopping Spread Spectrum (FHSS). In DSSS, the signal is spread across a wide range of frequencies based on the PN code. In FHSS, the signal frequency hops rapidly in a pattern defined by the PN code.

Integration into Audio Signal: The modulated signal is then subtly integrated into the audio file. This integration is done so that the modifications to the audio are imperceptible to the human ear but can be detected and decoded by analyzing the audio spectrum with the correct key.

Advantages of Spread Spectrum

Robustness: Spread spectrum techniques are highly resistant to interference and noise. Because the data is spread across a wide band of frequencies, it remains intact even if parts of the signal are disrupted or lost.

Security: The use of a PN code makes the hidden data difficult to detect and decode without the correct key, providing an additional layer of security.

Low Detectability: The hidden data’s wide distribution across the frequency spectrum and low amplitude make it difficult to detect through casual listening or even with spectral analysis without prior knowledge.

Challenges and Considerations

Complexity: Implementing spread spectrum in audio steganography requires sophisticated signal processing techniques and careful tuning to ensure that the hidden data does not affect the quality of the audio.

Bandwidth Requirements: The method requires more bandwidth to spread the data, which can be a limitation in environments where bandwidth is constrained.

Dependency on Audio Content: Like other steganographic methods, the effectiveness and capacity of the spread spectrum can depend on the nature of the audio content. Complex audio signals with a wide dynamic range and rich frequency content are better for hiding data.

Echo Hiding: 

This involves introducing an echo into the discrete signal. Parameters like the amplitude, decay rate, and offset of the echo can be manipulated to embed data. This method capitalizes on the auditory characteristics of human perception, specifically how humans perceive echoes, to hide data effectively without noticeably altering the quality of the audio.

How Echo Hiding Works

Echo hiding works by manipulating the properties of echo—such as delay, decay, and amplitude—to encode data. The basic steps involved in echo hiding are:

Echo Creation: Echoes are artificially created and superimposed onto the original audio signal. The parameters of these echoes—such as the delay (time between the original sound and its echo) and the decay rate (how quickly the echo fades away)—are crucial.

Data Embedding: Binary data is encoded into the audio signal by varying the parameters of the echoes. For instance, a short delay might represent a binary ‘0’ while a longer delay might represent a binary ‘1’. The amplitude of the echo can also be used to encode data, with different levels of loudness representing different data bits.

Parameter Control: To remain imperceptible, the echoes must be subtle. The echo delay is typically kept within the range of 1 to 3 milliseconds, as delays shorter than 1 millisecond are generally not perceived as echoes, and those longer than 3 milliseconds can begin to be perceived as discrete repeats rather than reverberation or natural echo.

Signal Synthesis: After encoding the data, the modified signal (original plus echo) is synthesized back into a coherent audio stream. This new audio stream contains the hidden information encoded within the echo parameters but should sound nearly identical to the original to an unsuspecting listener.

Advantages of Echo Hiding

Imperceptibility: Since the echoes are subtle and use natural auditory phenomena, the modifications are typically imperceptible to casual listeners.

Robustness: Echo properties can be robust against certain types of signal processing, such as compression and transmission over noisy channels because the characteristics of the echo (especially if embedded in a robust part of the audio spectrum) can remain detectable even if the quality of the audio is somewhat degraded.

Compatibility: Echo hiding does not require significant alteration of the frequency content of the audio signal, which helps preserve the original quality and characteristics of the audio.

Challenges and Considerations

Detection and Removal: While robust against some forms of manipulation, sophisticated audio analysis tools designed to identify and modify echo characteristics can detect and potentially remove echoes.

Capacity Limitations: Compared to other steganographic methods, echo hiding generally hides a limited amount of data. Overloading the signal with too many echoes can make it more detectable and degrade the audio quality.

Dependency on Content: The effectiveness of echo hiding can depend on the nature of the audio content. Audio signals with lots of natural variation and existing reverberation may mask the steganographic echoes better than very dry, sparse, or highly dynamic signals.

Frequency Masking:

Frequency masking is an audio steganography technique that exploits the limitations of human auditory perception to hide information within an audio file. It leverages a phenomenon known as “auditory masking,” where certain sounds become inaudible in the presence of other, louder sounds at similar frequencies. This technique is particularly subtle because it embeds data in a way that is naturally concealed by the characteristics of the audio itself.

How Frequency Masking Works

The basic concept of frequency masking involves embedding hidden data into parts of the audio spectrum where the presence of louder, dominant sounds will mask it. The process typically involves the following steps:

Analysis of Audio Spectrum: The first step is to analyze the frequency spectrum of the host audio signal to identify potential masking opportunities. This involves finding frequency ranges where louder sounds are likely to mask quieter ones.

Data Preparation: The data intended for hiding is prepared, usually encoded into a binary format. This data needs to be modulated or otherwise processed to fit within the selected masked frequencies.

Embedding Data: The prepared data is then embedded into the quieter parts of the audio spectrum, specifically within the critical bands of frequency where masking is most effective. Critical bands are frequency ranges in which the human ear processes sound as a single auditory event.

Signal Synthesis: After embedding the data, the audio signal is reconstructed to include the hidden data. This process must be handled delicately to ensure that the modifications do not become perceptible, maintaining the quality and integrity of the original audio.

Advantages of Frequency Masking

Imperceptibility: Because the hidden data is placed in regions where louder sounds naturally mask it, it is very difficult to detect without specific, sophisticated analysis tools.

Robustness to Compression: Frequency masking can be relatively robust against some forms of audio compression, particularly if the embedded data is strategically placed in less compressible parts of the spectrum.

Utilization of Auditory Phenomena: This method uses a natural auditory phenomenon, making it a very organic form of steganography.

Challenges and Considerations

Complex Signal Analysis Required: Effective use of frequency masking requires detailed analysis of the audio signal’s spectral properties, which can be complex and computationally intensive.

Limited Data Capacity: The amount of data that can be hidden is generally limited to the available masked regions, which may not be extensive depending on the audio content.

Dependency on Audio Content: The success of frequency masking heavily depends on the nature of the audio file. Audio tracks with dense and varied spectral content provide more opportunities for masking than simpler, cleaner tracks.

Applications

Audio steganography has various applications across multiple fields. Some of these include:

Secure Communications: These are used by organizations and individuals to communicate sensitive information discreetly.

Watermarking: Audio files can be watermarked to assert ownership, much like watermarking images or videos.

Covert Operations: Used by law enforcement and military for operations requiring secure and stealthy communication methods.

Challenges

Despite its advantages, audio steganography faces several challenges:

Robustness:

The steganographic information must remain intact even if the audio file undergoes compression, format conversion, or other types of digital processing.

Imperceptibility:

The alterations made to embed the data should not be detectable by normal hearing, as this would compromise the steganographic integrity.

Capacity:

The amount of data that can be hidden is generally limited by the size of the host file and the technique used, which could be restrictive for larger data needs.

Conclusion

Audio steganography offers a unique way to conceal information within audio files, making it a valuable tool for security and privacy in digital communications. Its effectiveness lies in its ability to hide information in plain sight, providing an added layer of security through obscurity. However, its success and reliability depend heavily on the choice of technique and the nature of the application. As technology evolves, so do steganography methods, which are continuously improving to meet the demands of modern security needs.

Beyond the Visible: Exploring the Depths of Steganography

Steganography is the practice of concealing a message, file, image, or video within another message, file, image, or video. Unlike cryptography, which focuses on making a message unreadable to unauthorised parties, steganography aims to hide the message’s existence. The word “steganography” is derived from the Greek words “steganos,” meaning “covered,” and “graphein,” meaning “to write.”

An example from history

One notable historical example of steganography involves using invisible ink during the American Revolutionary War. The British and American forces employed various forms of steganography to conceal messages and strategic information.

In particular, the Culper Spy Ring, a clandestine network of American spies operating during the Revolutionary War, extensively used invisible ink to communicate covertly. One member of the ring, invisible ink expert James Jay, developed a secret method for creating invisible ink using simple household ingredients such as lemon juice or milk.

The Culper Spy Ring would write messages with this invisible ink between the lines of innocent-looking letters or on the blank spaces of documents. To reveal the hidden messages, the recipient would apply heat or special chemicals, causing the invisible ink to darken and become visible.

This use of steganography allowed the Culper Spy Ring to transmit crucial intelligence about British troop movements, plans, and other sensitive information without detection by British authorities. The effective use of invisible ink by the Culper Spy Ring played a significant role in aiding the American cause during the Revolutionary War and exemplifies the historical importance of steganography in espionage and covert operations.

Example of using Steganography in Cybersecurity

A modern example of steganography in cybersecurity involves concealing malicious code within seemingly innocuous digital files to bypass security measures and deliver malware to targeted systems. Cybercriminals often employ this technique to evade detection by traditional antivirus software and intrusion detection systems.

For instance, attackers may embed malicious payloads, such as Trojans or ransomware, within images, audio files, or documents using steganography techniques. The carrier files appear unchanged to the naked eye or standard file analysis tools, making it difficult for security solutions to detect hidden malware.

Once the steganographically encoded file reaches the target system, the attacker can extract and execute the concealed payload, thereby compromising the system and initiating malicious activities.

To combat this threat, cybersecurity professionals utilise advanced threat detection technologies capable of analysing files for signs of steganographic manipulation. These tools employ various techniques, such as statistical analysis, anomaly detection, and signature-based detection, to identify suspicious patterns or deviations from expected file structures.

Additionally, cybersecurity awareness training programs educate users about the risks associated with opening files from untrusted sources and emphasise the importance of maintaining up-to-date security software to mitigate the threat of steganography-based attacks.

All Code Examples are on GitHub: https://github.com/svenruppert/Steganography

How to do it practically in Java 

Steganography techniques can involve various methods, such as:

The source code you will find on GitHub under the following URL:

https://github.com/svenruppert/Steganography

Text Steganography: 

Embedding secret messages within text documents by altering spacing, font styles, or using invisible characters.

Here’s a simple example of text steganography in Java using a basic technique called whitespace steganography. In this example, we’ll hide a secret message within a text document by manipulating the whitespace between words.

This code demonstrates a basic form of text steganography where a secret message is hidden within the whitespace of a text document. Note that this method needs to be revised and may not be suitable for high-security applications. Advanced techniques can involve more sophisticated manipulation of text or embedding data within specific patterns.

Image Steganography: 

Data is concealed within digital images by modifying the least significant bits of pixel values or by embedding data within specific regions of the image where slight alterations are less noticeable.

Certainly! Here’s a simple example of image steganography in Java using LSB (Least Significant Bit) embedding. In this example, we’ll hide a secret message within the least significant bits of an image’s pixels.

This code hides a secret message within the least significant bit of each pixel in the image. The original image is saved as a new steganographic image when the message is hidden. Later, the hidden message is extracted by reading the steganographic image’s pixels and retrieving the least significant bit of the red component of each pixel. Finally, the binary message is converted back into a readable string. Replace “input_image.png” with the path to your input image.

Audio Steganography: 

Hiding information within audio files by modifying the least significant bits of audio samples or by exploiting imperceptible frequencies.

Here’s a basic example of audio steganography in Java using LSB (Least Significant Bit) embedding. In this example, we’ll hide a secret message within the least significant bits of the audio samples.

This code hides a secret message within the input audio file’s least significant bit of each audio sample. The modified audio data is then saved as a new steganographic audio file. Later, the hidden message is extracted by reading the least significant bit of each audio sample in the steganographic audio file. Replace filename and path with the path to your input audio file.

Video Steganography: 

Concealing data within video files by manipulating frames or embedding data in specific segments.

Below is a basic example of video steganography in Java using LSB (Least Significant Bit) embedding. In this example, we’ll hide a secret message within the least significant bits of the blue pixel values of video frames.

File Steganography: 

Embedding files within other files, such as hiding a document within another document.

File steganography with PDF files involves hiding one PDF file within another PDF file. In this example, we’ll hide the contents of one PDF file within the metadata of another PDF file. Specifically, we’ll utilise the “Keywords” metadata field of PDFs to embed the content of a secret PDF file.

Here’s the Java code to achieve this using the Apache PDFBox library:

In this code:

1. The “hidePDF” function loads the source PDF document, converts the content of the secret PDF file to a Base64 encoded string, and embeds it into the “Keywords” metadata field of the source PDF file.

2. The “extractPDF” function loads the steganographic PDF document, extracts the Base64 encoded content from the “Keywords” metadata field, decodes it, and writes it to an output PDF file.

Make sure to replace every path to files with the appropriate file paths in your system. Additionally, you’ll need to include the Apache PDFBox library in your project to use its functionalities.

Conclusion:

As explored in this paper, steganography is a fascinating field with a rich history and diverse applications. By concealing information from ordinary data, steganography provides a powerful means of covert communication and data protection. Steganography continues to evolve alongside technological advancements, from ancient techniques of hiding messages in wax tablets to modern digital methods embedded within multimedia files.

While steganography offers numerous benefits in fields like digital watermarking, copyright protection, and secure communication, it also presents challenges and ethical considerations. Due to its subtle nature, detecting steganographic content remains a significant challenge, requiring advanced algorithms and tools for effective analysis.

As technology continues to advance, the importance of understanding steganography becomes increasingly critical. It underscores the need for robust security measures balanced with respect for privacy rights. By delving into the principles and techniques of steganography, researchers and practitioners can develop more effective strategies for exploiting and defending against covert communication methods.

In conclusion, steganography represents a dynamic and intriguing aspect of information security, with implications spanning various domains. By embracing its complexities and exploring its potential applications, we can navigate the intricate landscape of digital communication with greater insight and resilience.

Introduction to the Linux Foundation’s SLSA project

Supply Chain Security is a hot topic these days. And more and more, we as developers are dealing with this daily. But what does this mean for us, and how is this influencing our job? I want to give an overview of common attacks against the Software Supply Chain from the developer’s view and will introduce the Open Source project SLSA from the Linux Foundation. 

a) Who is the project SLSA

Various experts from the security field started this project to share their knowledge, leading to the mentioned project. There is no company or governmental organisation behind this project. It is a pure Open Source project under the umbrella of the Linux Foundation. 

b) What is the goal of this project?

The SLSA project is open-source and will not provide its own source code. It is, therefore, not a classic open-source project to publish a specific solution. Instead, it is a documentation project to process knowledge about supply chain security in software development and make it freely accessible. The structure contains examples of where the events or attacks mentioned have been successfully taken and which countermeasures should be taken. We’ll look at the security levels provided a little later. The aim here is to allow the reader to prepare for these threats with specific steps slowly. 

After all, based on your options and the current environment, you have to decide which next steps and measures make sense to implement. 

c) What is the current status of the project?

The project is currently (beginning of 2022) still in the alpha phase. There is a lot of documentation, but some places still provide references to future content. So it’s always worth taking a look inside. Since this is an open-source project, you can, of course, also contribute yourself. Here you have the opportunity to make your expertise available to others. 

SLSA security levels?

a) Why do we need these security levels?

When you look around the SLSA project website for the first time, the description of the security levels quickly catches your eye. But what are these levels all about? With these levels, you want to achieve two things. First, it should help to enable a self-assessment. This first consideration serves to classify the own existing environment and to identify the primary weak points. The second goal of this level is to help you plan the following purposes that should be implemented to increase your protection significantly. These recommendations are based on evaluating many projects and environments and on the security experts’ knowledge. This enables you to use the available means and opportunities to increase your security. 

b) Level 0

The first level mentioned is marked with the number zero. This is the state in which no action has yet been taken. The documentation that describes the entire build process must be available and up-to-date to reach this level. This enables an initial analysis of the environment to be secured. It can also be seen as a way of taking stock.

c) Level 1

The level with the number one requires first actions on the environment. The point here is to list all the components used to create a binary file. Not only are the dependencies used listed, but all other metadata is recorded if possible. There is the term SBOM, Software Bills Of Materials in the industry. However, the term can be broadened considerably here. Within JFrog Artifactory, there is “build info”, which means a superset of SBOM. All sorts of metadata are recorded here, such as the operating system and version of the build machine, environment variables and their contents, etc. I have created my video for this.    

In this video, I’ll go over the details of SBOM and Build Info.

Within the SLSA project, the term SBOM or Build Info is not explicitly mentioned. Instead, the requirement is described more generally, and it is also clearly pointed out that this level does not yet help against the compromise itself. It is only the basis for the follow-up and the comprehensive risk assessment. Based on this level, one can start with vulnerability management.

d) Level 2

Level two describes code versioning software in combination with a hosted build service. With this combination, you want to trust the build service and thus trust the origin of the generated files. Here you must take a critical look at where and who will offer these services. The fundamental consideration is based on the assumption that a specialized provider has a better grip on the issue of security within the build infrastructure than you can guarantee yourself. However, the manipulation of protection of the build service can be increased in various ways.

e) Level 3

With level three, auditors are now included in the considerations. Here, trained security specialists are used to check the existing build environment for possible vulnerabilities. As part of an accreditation process, the auditors determine whether specific standards are met to ensure the verifiability of the source and the integrity of the provenance (origin). This level offers better protection than all previous levels to ward off well-known threats. Preventing cross-build contamination is an example.

f) Level 4

In the SLSA project, level four is the highest currently achieved. To reach this level, the following conditions are set. The first requirement describes the necessity that two people constantly carry out all changes. This does not only refer to the changes made to the source code. The term is broader here and also includes all changes to the system and the configurations. This ensures that no intentional or unintentional compromise can occur at any point. Such a process has prevented most bugs, vulnerabilities and compromise attempts.

The second requirement relates to the technical environment. It is assumed here that it is a hermetic and reproducible creation process. However, a distinction should be made between the requirement for hermetic builds and reproducible builds. The former guarantees that all required dependencies are known and checked for vulnerabilities. Here, of course, it plays a role from which sources these dependencies were obtained. On the other hand, reproducible builds help detect changes and conduct subsequent analyses. However, the reproducibility of a build is not a mandatory part of the fourth level.

g) Limitations

Even if many supply chain threads are addressed with the SLSA project, there are some limitations that I would like to list here.

1) The list of all dependencies in a project can simply become too large to be able to fully record and evaluate them. That can depend on different things. The point that shows this most clearly is based on the possibility of some dependency management systems not only specifying explicit dependency versions. In some scenarios, you can also define a version range. This now results in an exponential increase in all possible version combinations.

2) The number of all components to be backed up can exceed the available capacities. The teams then have to decide which elements are subjected to safety analysis.

3) The SLSA security levels are not transitive. This means that this component itself consists of components that have a lower security level. So here, you have to pay very close attention to the details.

4) Even if automation is the solution in many areas, there may be areas where this will not be possible. Again, this refers in many areas to closed-source projects. Here, some analyzes are simply not feasible. It must then be decided how this dependency will be classified on a case-by-case basis.

What are the requirements? 

All the requirements mentioned here are a little more detailed in reality. An overview of the requirements was provided to guide what exactly is meant by each point. Here, you can see which condition belongs to which level and how this is understood. Then the details are discussed, such as what difference it makes if you only use a building service or if you also use the “Build as Code” strategy. All the details are too extensive here, so I refer to the section on the project’s website.  

Supply Chain Threads

a) Overview 

To better understand the project and its limitations, you should look at the individual types of attacks on a typical software development environment. A distinction is generally made between source, image and dependency threads. The SLSA project also delimits precisely what it includes and what it does not.

The following overview comes directly from the project and will be further developed if necessary. At this point, one must not forget that this project is only in the alpha phase (early 2022). However, these types of attacks mentioned are timeless and apply to almost every development environment.

Let’s get to the source threads. This type of attack aims to compromise the source code itself. 

b.1) Bypass Code Review

The attack called “Bypass Code Review” describes a scenario in which an attempt is made to bypass the control mechanisms and directly add compromised source code to the project. Here public paths are taken to reach the destination. Such attacks were carried out on the Linux kernel, for example, via the mailing list. The best and probably simplest way to thwart such attacks is to have all source code changes checked independently by at least two people. However, at this point, one must also find ways to prevent mutual “covering up”.

b.2) Compromised Source Control System

If importing compromised source code does not work, you can try to attack the CVS itself. Attempts are being made here to make changes to the source code on the server, bypassing the official channels. A prominent example is a successful attack on the source code of PHP. The self-managed system was attacked, and the changes were imported directly as a commit. Only securing the system helps against this type of attack. To manage such a system yourself, you must have the necessary resources and knowledge. In this case, it is often easier and cheaper to use a managed system with Github.

Next, we come to the build threads.

b.3) Modified Source Code after Source Control

The source code cannot only be changed where it is stored. When a Build process is started, the source code is fetched from the specified source. The source text on the build page can also be modified before the translation process starts. One attack in which this approach was used is the “Webmin” project. Here, additional and modified source texts were injected into the translation process. The agents responsible for carrying out the individual build steps must be secured to prevent this attack. Here, too, one has to weigh up how much of this work is carried out by oneself since how safe such an environment depends primarily on one’s own abilities. 

b.4) Compromised Build Platform

Since the built environment is part of the value chain, this part must also be secured classically. Here, too, it is again the case that one’s own abilities in ​​safety must be assessed. A well-known representative of this type of attack is the Solarwinds Hack. Here, the build route was modified to compromise the newly created binary with each run. 

b.5) ​​Using Bad Dependencies – Dependency Thread

At this point, I would like to insert the dependency threads briefly. Dependencies are specifically modified and then offered. The security of the repositories plays a central role here. I’ll come back to that in a moment. However, this attack pattern refers to external locations where dependencies are fetched to process them. Particular attention should be paid to assessing the integrity of caches and mirrors of known official bodies. Often the “official” mirror servers of publicly accessible repositories do not have the same financial resources as the original. This causes attacks to be placed there.

You may be offered modified versions of known commonly used dependencies when you dock at such a place.

b.6) Bypassed CI/CD

Let’s get back to the build threads. Sometimes it is easier to bypass the CI/CD environment at an appropriate point. Here, the topics within a development path are selected where a transfer between the build server and the associated repositories is not sufficiently secured. The attack involves offering a recipient such as a repository a modified binary to make it look like it is from the CI environment. Malicious code is injected parallel to its own build infrastructure. 

b.7) Compromised package repo

A component repository is also part of the infrastructure and can fall victim to an attack. As with all other elements, protection is necessary here. Attackers try to gain access to the repositories to replace the binaries of known and frequently used dependencies with modified versions. Depending on your ability to harden such a system against attacks, you have to decide whether an externally managed alternative will increase the security standard of your value chain.

b.8) Using a bad package

We come to the last attack variant mentioned here. In this scenario, known dependencies are taken as a template and then their own modified versions are offered in a public repository. Here, an attempt is made to give the own variant a name close to the original name and depicts typical spelling errors. This dependency can still be resolved if a misspelling of the original name is used in a version definition. Only in this case a modified version of it will be loaded.

The only way to protect yourself against this attack is to carefully check how each individual dependency has been defined in your own projects. 

Project Persia Overview

We have seen which general types of attacks on a classic software development environment are possible. These are always generic attack patterns that can be used independently of the current products. Others also saw this as an idea to develop a general strategy to counter this. The language here is from the open-source project Persia, which is currently (early 2022) in the alpha phase. We are close to officially accepting it as an incubator in the CD Foundation. The project website is https://pyrsia.io.

The basic idea of ​​this project is that there will be a network of trust for open-source projects. A P2P network consisting of build and distribution nodes should exist where the sources are fetched, built and offered decentrally. In addition to the classic advantages such as reliability and better utilisation of the network resources of a P2P network, increased security should also be achieved with the binaries themselves. The types of attacks on source code management software are excluded. But all subsequent attack patterns can be repelled in this way. 

Unfortunately, it is not possible to fully describe the project. But at this point, I would like to draw attention to my video about this project. (https://pyrsia.io/) 

Cheers Sven

The Power of #JFrog Build Info (Build Metadata)

Intro

This article will take a detailed look at what the term build-info is all about and why it will help us protect against attacks such as the Solarwinds Hack. 

What is the concept behind the term – build-info?

Let’s start at the very beginning and clarify the basic principle behind the term build-info. The term build-info has been coined for many years by the company JFrog, among others. This is a particular type of repository.

This repository stores the information that describes the context that led to the creation of a binary file. With this information, you can now achieve a wide variety of things.

What components does build-info consist of?

The content of a build-info is not strictly defined. Instead, the approach that applies is that the more, the better. Of course, you have to proceed with caution here too. All possible parameters are collected. In addition to the date and time, the system on which the process was run, which operating system was used in which patch level, to active environment variables, compiler switches and library versions.

The challenge is actually that it is not known which information will later be helpful and expedient. For this reason, more rather than less should be saved.

Why do we actually need a build-info?

The task of a build-info is to enable the observation, or rather, the analysis of a past situation. There can be a variety of reasons for this. For example, it can be used to improve quality, or it can be the basis for reconstructing a cyber attack that has taken place. And with that, we come straight to the event that got everything rolling in the recent past.

Trigger – SolarWinds Hack

One of the others will have heard or read something about it. We are talking about one of the most significant cyberattacks that have ever taken place. It’s the SolarWinds Hack. Here it was not the final target that was attacked directly, but a point in the supply chain. SolarWinds is a software company that provides a product for managing network infrastructure. With just over 300,000 customers worldwide, this software’s automatic update process has been the target of the attack. It was not the update process itself that was compromised, but the creation of the binaries that will be distributed with this update process. The attack took place on the company’s CI route to immediately infect the newly created binaries with each build. Here the CI route was manipulated so that another component was added to the binary to be generated. This component can be thought of as a kind of initial charge. As soon as this has been ignited or activated, further components are dynamically reloaded. As a result, each infection had different forms. These files were then offered to all customers by means of an automatic update. Thus, over 15,000 systems were infiltrated within a short time.

Reaction – Executive Order of Cybersecurity

Since there were many well-known US companies, US organizations and US government institutions among the victims, the question arose of how to counter such a threat from the US state in the future. The US government has decided that one begins with the complete cataloguing of all software components in use, including all their constituent parts. This obligation to provide evidence was formulated in the “Executive Order of Cybersecurity”. However, when I first heard about an executive order, I wasn’t sure what that actually meant.

What is an executive order?

An executive order is a decree of the US President that regulates or changes internal affairs within the state apparatus. You can think of it as a US president like a managing director of a company who can influence his company’s internal processes and procedures. In doing so, no applicable law can be circumvented or changed. With such an executive order, no law can be changed, stopped or restricted. But it can change the internal processes of the US authorities very drastically. And that’s exactly what happened with this Executive Order of Cybersecurity, which has directly impacted the US economy. Every company that works directly or indirectly for the state must meet these requirements to continue doing business with the US authorities.

What is the key message of the Executive Order?

The Executive Order of Cybersecurity contains a little more text, the content of which I would like to shorten here and reproduce without guaranteeing legal correctness.

This arrangement aims to record the software operated by or for the US authorities in its entirety. This means that all components of the software used must be documented. This can be thought of as follows; If you want to bake a cake, you need a list of ingredients. However, listing these would not meet the requirements, as knowledge of all elements down to the last link is required. In our example, an ingredient that consists of more than one component would have to provide a list of all existing parts. This is how you get all the components used that are needed for the cake. If we now transfer this to the software, it is necessary to record all direct and indirect dependencies. The list of all components is then called – SBOM (Software Bills Of Material) 

And what does that mean for me?

Now I am not directly working for an organ of the US government. But it will still reach me sooner or later. Because through the indirection, all possible economic sectors worldwide will be affected. It can also affect me in the private sector. If I have an open-source project that is used indirectly in this environment, it can only continue if I prepare the project accordingly. Long story short; It will come our way in whatever way it will happen.

What are the general requirements for a build-info?

Let’s get back to the build-info. A build-info is a superset of an SBOM (Software Bills Of Material). So the dependencies are catalogued, and additional information from the runtime environment in which the binary is generated is recorded. However, there are also some requirements for such build-info. By this, I mean properties that must be present in order to be able to deal with this information in a meaningful way.

Accessibility:

The information that is collected must be quickly and easily accessible and therefore usable. A central storage location such as Artifactory is suitable here, as all binaries and dependencies are also stored here. You also have all the meta-information of a respective binary file at this location.

Immutability:

When information is collected, it makes sense to store it in such a way that it can no longer be changed. This promotes the acceptance of the data situation and gives particular security when evaluating a case.

Combinability:

The static data are also suitable for enriching them with current secondary data. In this case, I am talking about the vulnerabilities that can be found in the dependencies used. In contrast to the static information, this image has to be constantly updated. In practical use, this means that the data must be stored in a machine-readable manner in order to enable the connection of other data sources. In the case of Artifactory, it is the data from JFrog Xray that is displayed here.

How can a build-info be generated?

It would be best if you had the following things.

First, the JFrog CLI generates the build-info and second, it is possible to save this information permanently. You can do this very quickly with the Build-Info Repositories from Artifactory. But one step at a time.

The process for generating a build-info is as follows.

In the following example, we assume that we are going to build a Java project with maven. Here you have to get involved in the build process. You can do that quite easily with the JFrog CLI tools. These represent a wrapper for the build process used in each case. In our example, it is maven. To install the JFrog CLI Tools, you can go on the website https://jfrog.com/getcli/ choose the installer that is suitable for it. After installing and configuring the JFrog CLI Tools, you can start the build via the CLI on the command line. After a successful build, you can find the build-info as a JSON file in the target directory. This file can be viewed with a text editor to get a feel for the wealth of information that is stored here. This file is regenerated with each build. This means that there is a 1: 1 relationship between the build cycle and the binaries generated in the process. Using the CLI, you can then transfer this information to the Artifactory build repository and evaluate it there using a graphical user interface.

How can I link vulnerability scans to the build-info?

If you are now within Artifactory (https://bit.ly/SvenYouTube ), look at the build-information; you also get the current information regarding the known vulnerabilities. This is an example of how the build-information can be enriched with further system information.

Since there is not enough space at this point to clarify the generation and evaluation, I refer to a demo project in which I have stored the steps in the README, including detailed explanations of the individual practical steps.

If you want, you can also register for one of my free DevSecOps workshops. You are also welcome to speak to me directly if you’re going to do this in a free community or company event.

The URL for the demo project is: 

https://github.com/Java-Workshops/JFrog-FreeTier-JVM

Have fun trying it out.

Cheers, Sven! 

SolarWinds hack and the Executive Order from Mr Biden — And now?

In the past two years, we have had to learn a lot about cybersecurity. The new attack vectors are becoming more and more sophisticated and are directed more and more against the value chain in general. But what does that mean for us? What can be done about it, and what reactions have the state already taken?

Let’s start with the story that got all of this rolling and made sure that the general attention was drawn to the vulnerabilities of the available IT infrastructure. We’re talking about the SolarWinds Hack. What happened here, and what is more critical; What are the lessons learned from this incident?

It is essential to know that the SolarWinds company produces software that is used to manage network infrastructure. With the name “Orion Platform, ” this software should help manage and administer the network components efficiently. If you look at the product description on the SolarWinds website, you can read that the software can monitor, analyse, and manage the network infrastructure. And that’s exactly what the customers did. The company itself has around 300,000 customers worldwide, including individual companies and government organisations and corporations from a wide variety of areas. To always stay up to date, the software platform includes an automatic update mechanism. And that was exactly what the attackers were after. They saw in the SolarWinds company a multiplier for their own activities. But how can you go about this? The attackers obtained the necessary software tools by breaking into the FireEye company and infiltrating the SolarWinds network. The goal was the software development department in which the binaries of the Orion platform are created. Here, the CI routes have been manipulated to include compromised binaries in every build of the software. As a result, the company produced these binaries and put them into circulation through the automatic update process. In this way, around 18,000 targets could be infiltrated and compromised within a short time.

What does that mean for us now?

There are two angles here. The first is from the consumer’s point of view. However, for your own production, it must be ensured that no compromised binaries are used. That means that all, and here I mean all binaries used, must be checked. These are the dependencies of the application and the tools used in the production process. This includes the tools such as the CI server used, e.g. Jenkins, or the operating system components of the infrastructure and Docker images.

The second perspective represents the point of view that one has as a software distributor. This means anyone who distributes binaries in any form. This includes customers in the classic sense and other departments that may be considered consumers of the binaries created. The associated loss of trust can cause a company severe financial damage.

What can we do to protect ourselves?

If you look at the different approaches to arm yourself against these threats, you can see two fundamental differences.

DAST – Dynamic Application Security Testing

An application can be subjected to a black box test. This is called DAST, Dynamic Application Security Testing. Here you go the way a hacker would do it. The application is attacked via the available interaction points. Attack vectors based on the most common vulnerabilities are usually used here. SQL injection can be cited as an example. These attack patterns are initially independent of the technology used and represent typical security holes in web applications.

This approach has advantages as well as disadvantages. A serious disadvantage is that the tests cannot be started until the application has been developed. This means that the measures to eliminate weak points found are more costly than is the case with other approaches. On the other hand, a significant advantage of this approach is that the dynamic context can also be checked when testing the production system. Examples include weak configurations, open ports, and more.

SAST – Static Application Security Testing

The counterpart to the dynamic tests is the static tests. These tests analyse the individual components of the infrastructure involved. This includes not only the applications created but also the components involved in operating and creating the application.

A disadvantage of the SAST method is that it can only search for known security vulnerabilities. However, this point is put into perspective in that the number of known security gaps increases steadily. Still, it is also assumed that the number of known security gaps exceeds the number of unknown security gaps. Another advantage of the SAST method is that it checks the licenses used. This area also contributes to the security of the company, albeit in a legal sense.

So what has the most significant effect when you start with the topic of security?

When looking at the different approaches, it becomes clear that the proportion of directly or indirectly used binaries makes up the most significant amount in a technology stack. This means that you should also start securing precisely these parts. Unfortunately, there is only one way to ensure with SAST that it is really 100% checked directly. All other methods do not achieve this coverage, or if they do, then only in sporadic exceptional cases.

However, it should be noted that one understands the interdependencies. This is the only way to identify and extract the possible attack vector. Here it is of essential importance that not only the binaries themselves are examined, but also the associated meta-information is evaluated. Within software development, there are two points for these analyses where such an analysis fits very well. The first point that most people will think of is the CI segment. Here the CI server can carry out the analysis during the execution of a build pipeline and all the checks and also take over the reporting. If the violations are too massive, the build is cancelled. The second position, which is ideally suited for such an analysis, is directly in the IDE. Here it can already be determined during the definition whether the license used is permitted. The known vulnerabilities can also be extracted and thus provide enough information to decide whether this version of this dependency may be used.

Lesson Learned – what we learned from the SolarWinds Hack.

We learned the following things from SolarWinds. First, the attacks are no longer aimed at the final targets themselves but against the suppliers. Here one tries to reach multipliers who massively increase the effectiveness of this attack. Likewise, you no longer only have to protect yourself against your use of compromised binaries. The newly added component means that the self-generated binaries must also be secured. Nobody wants to become a distributor of infected software. It follows that all parts involved must be subjected to permanent checks.

Reactions – The Executive Order from Mr Biden

One or the other has undoubtedly noticed that the US President gave this Executive Order of Cybersecurity. But what exactly does that mean, and who can even do something like that under what conditions?

In the United States, the president – the “executive branch” of the US government – can issue what is known as an executive order. Much like a CEO in a company, the executive branch has the power to make some unilateral decisions that affect the behaviour of the US government. These orders must be limited to government conduct and policies and not to general laws or statutes that encroach on the rights of any individual or state. If the executive transgresses in this area, the US Supreme Court or other legal remedies can appeal and revoke all measures. Only the president – due to his status as head of state – can issue an executive order. No other officer is allowed to do this.

Significantly, executive orders are mostly limited to how the US government operates internally. For example, an executive order might not simply resolve to raise taxes in a state or issue far-reaching commercial guidelines. However, executive orders are legally binding on the behaviour of the US government if they do not violate fundamental rights or make something unconstitutional. Because of this, these commands can be found to change the policy from the president to the president as, like a CEO, they set some of the government’s agendas. In this case, the Executive Ordinance refers to how the US government monitors and regulates its software usage and sets out requirements for how that software must be documented to be sold to the government. It doesn’t dictate trading on a broad scale.

Since the US government can define its way of working, it was decided that the SBOM requirements (in preparation) will be the only way to approve software purchases – to get an idea of ​​the volume, you have to know it is one amount in the tens of billions per year. This means that any company that wants to sell to US government agencies, likely state and local agencies, and anyone who works with resellers who sell to the government and more, must meet all of these new standards.

When the European Union agreed on comprehensive data protection and data security laws with the GDPR, the effect was felt worldwide and quickly. In a globally networked economy, decisions by the world’s largest GDP producers can set standards for other areas. With the GDPR, companies in the US and elsewhere had to immediately revise and update software and processes to continue doing business in the EU. It became a worldwide rule so as not to lose EU treaties. Likewise, the US cybersecurity order is believed to be reversing, with U.S.-based global corporations influencing global software security behaviour.

Wow – what now?

What does that mean for me as a software developer? Well, the effects at this point are not as severe as you might want to imagine. In the end, it is said that a complete list of all contained dependencies must be created. This means the direct and indirect dependencies. To obtain such a dependency graph, one can, for example, use the tools that already do this. It means the tools that can generate a complete dependency graph, for example. For this, you need a logical point through which all dependencies are fetched. A tool such as Artifactory is best, as this is where the knowledge of all dependency managers used comes together. Devices such as the vulnerability scanner JFrog Xray can then access this information, scan for known vulnerabilities and licenses used, and extract the entire dependency graph. This information can thus be generated as build information by the CI route (e.g. JFrog Pipelines) and stored in a build repository within Artifactory.

Conclusion

We have seen that the new qualities of attacks on software systems, in general, will lead to advanced countermeasures. What is meant here is a complete analysis of all artefacts involved and produced. The tools required for this must combine the information into aggregated impact graphs across technology boundaries. One point within software development that is ideal for this is the logical point via which all binaries are fed into the system. However, the components alone are insufficient since all indirect elements can only be reached and checked by understanding the associated meta-information.

The tools used for this can then also be used to create the SBOMs.

In my opinion, it is only a matter of time before we also have to meet this requirement if we do not want to suffer economic disadvantages from the Executive Order of Cybersecurity.

If you want to find out more about the topic or test the tools briefly mentioned here, don’t hesitate to contact me.

In addition to further information, we at JFrog offer free workshops to prepare for these challenges in a purely practical manner.

And if you want to know more immediately, you are welcome to go to my YouTube channel. There I have other videos on this topic.

It would be nice to leave a subscription on my YouTube channel as a small thank you. https://www.youtube.com/channel/UCNkQKejDX-pQM9-lKZRpEwA

Cheers Sven

What is the difference between SAST, DAST, IAST and RASP?

Intro:

In this post, we’re going to look at the differences between the various cybersecurity defence techniques. Here you can identify four main groups, which we will go through briefly one after another to illustrate the advantages and disadvantages.

SAST – Static Application Security Testing

SAST describes the process in which the components of an application are subjected to a static analysis. This approach not only searches for security gaps but also determines the licenses for the individual elements. In the following, however, I will only deal with the consideration of vulnerabilities in this post.

The term static comes from the fact that only the static context is used for this evaluation. All dynamic or context-related assessments are not possible with this method. SAST can be used to analyze the entire tech stack of an application if access to these components is possible, which is also one of the advantages of SAST compared to other analysis methods. The only exception is the IAST procedure, which we will come back to later.

What exactly happens now with the SAST procedure? SAST is available in two forms. The first that I would like to mention relates to checking your source code. Here the attempt is made to determine whether there are patterns that make a later vulnerability easier or even possible in the first place. For example, it searches for calls to critical libraries or identifies unsafe handling of resources. However, one honestly has to admit at this point that, first of all, your source code will be by far the smallest part of the overall application in the vast majority of projects. Second, the analysis methods in this area are still at a very early stage of development.

When using SAST, it makes a lot more sense to deal with all the other components first. Therefore, all binary files of the entire application environment are meant here. This also includes all elements that play a role in the development, such as the CI server and the other tools used.

DAST – Dynamic Application Security Testing

The DAST analysis method does precisely the opposite in comparison to the SAST method. Here the application is viewed as a black box. As soon as an executable version of the application is available, it is attacked through automatically executed cyber attacks. In most cases, the general attack patterns are based on the Most Common Vulnerabilities defined by the OSWAP. Defining your attack vectors is either not provided for in the tools I know or requires very detailed knowledge in this area. For developers who do not use these tools daily and intensively, their use is limited to the predefined attack vectors. It is a good thing with this procedure that unknown security gaps can also be identified, as long as they are based on the Most Common Vulnerabilities. Some manufacturers extend this approach with AI or ML techniques. This approach using AI and ML techniques is still in a very early stage of development, and the currently available potential cannot be foreseen.

Unfortunately, the method can only be used sensibly against the production environment, as this is the only way to identify all gaps based on configuration deficiencies. Therefore, in contrast to the SAST process, it makes no sense to use it within the CI route.

IAST – Interactive Application Security Testing

IAST uses software tools to evaluate application performance and identify vulnerabilities. IAST takes an “agent-like” approach; H. Agents and sensors run to continuously analyze application functions during automated tests, manual tests, or a mixture of both.

The process and feedback occur in real-time in the IDE, Continuous Integration (CI) environment or quality assurance or during production. The sensors have access to:

  • All source code
  • Data and control flow
  • System configuration data
  • Web components
  • Backend connection data

The main difference between IAST, SAST, and DAST is that it runs inside the application.

Access to all static components as well as the runtime information enables a very comprehensive picture.

It is a combination of static and dynamic analysis. However, the part of the dynamic analysis is not a pure black-box test as it is implemented at DAST.

Some reasons for using IAST:

Potential problems are identified earlier, so IAST minimizes the cost of eliminating potential costs and delays.

This is due to a “shift left” approach, meaning it is carried out in the early stages of the project life cycle.

Similar to SAST, the IAST analysis provides complete lines of data-rich code so that security teams can immediately lookout for a specific bug.

With the wealth of information that the tool has access to, the source of vulnerabilities can be precisely identified.

Unlike other dynamic software tests, IAST can be easily integrated into Continuous Integration and Deployment (CI / CD) pipelines.

The evaluations take place in real-time in the production environment.

On the other hand:

IAST tools can slow down the operation of the application.

This is based on the fact that the agents change the bytecode themselves. This leads to a lower performance of the overall system.

The change itself can, of course, also lead to problems in the production environment.

The use of agents naturally also represents a potential source of danger since these agents can also be compromised.

– See Solarwinds Hack

RASP – Runtime Application Self Protection

RASP is the approach to secure the application from within.

The backup takes place at runtime and generally consists of looking for suspicious commands when they are executed.

What does that mean now?

With the RASP approach, you can examine the entire application context on the production machine and real-time.

Here all commands that are processed are examined for possible attack patterns.

Therefore, this procedure aims to identify existing security gaps and attack patterns and those that are not yet known.

Here it goes very clearly into the use of AI and ML techniques.

RASP tools can usually be used in two operating modes.

The first operating mode (monitoring) is limited to observing and reporting possible attacks.

The second operating mode (protection) then includes implementing defensive measures in real-time and directly on the production environment.

RASP aims to fill the gap left by application security testing and network perimeter controls.

The two approaches (SAST and DAST) do not have sufficient visibility into real-time data and event flows to prevent vulnerabilities from sliding through the verification process or block new threats that were overlooked during development.

RASP is similar to Interactive Application Security Testing (IAST); the main difference is that IAST focuses on identifying vulnerabilities in the applications, and RASPs focus on protecting against cybersecurity attacks that can exploit these vulnerabilities or other attack vectors.

The RASP technology has the following advantages:

First, RASP complements SAST and DAST with an additional layer of protection after the application is started (usually in production).

It can be easily applied with faster development cycles.

Unexpected entries are checked and checked.

It enables you to react quickly to an attack by providing comprehensive analysis and information about the possible vulnerabilities.

However, RASP tools have certain disadvantages:

By sitting on the application server, RASP tools can adversely affect application performance.

In addition, the technology (RASP) may not be compliant with regulations or internal guidelines,

which allows the installation of other software or

the automatic blocking of services is permitted.

The use of this technology can also lead to the people involved believing themselves to be false security.

The application must also be switched offline until the vulnerability is eliminated.

RASP is not a substitute for application security testing because it cannot provide comprehensive protection.

While RASP and IAST have similar methods and uses, RASP does not perform extensive scans but instead runs as part of the application to examine traffic and activity. Both report attacks as soon as they occur; with IAST, this happens at the time of the test, while with RASP, it takes place at runtime in production.

Conclusion

All approaches result in a wide range of options for arming yourself against known and unknown security gaps. Here it is essential to reconcile your own needs and those of the company for the future direction.

Conclusion RASP:

We have seen that with RASP, there is an approach in which the application can protect itself against attacks at runtime. The permanent monitoring of your activities and the data transferred to the application enable an analysis based on the runtime environment. Here you can choose between pure monitoring or alerting and active self-protection. However, software components are added to the runtime environment with RASP approaches to manipulate the system independently. This has an impact on performance. With this approach, RASP concentrates on the detection and defence of current cyber attacks. So it analyzes the data and user behaviour in order to identify suspicious activities.

Conclusion IAST:

The IAST approach combines the SAST and DAST approach and is already used within the SDLC, i.e. within the development itself. This means that the IAST tools are already further “to the left” compared to the RASP tools. Another difference to the RASP tools is that IAST consists of static, dynamic and manual tests. Here it also becomes clear that IAST is more in the development phase. The combination of dynamic, static and manual tests promises a comprehensive security solution. However, one should not underestimate the complexity of the manual and dynamic security tests at this point.

Conclusion DAST:

The DAST approach focuses on how a hacker would approach the system. The overall system is understood like a black box, and the attacks occur without knowing the technologies used. The point here is to harden the production system against the Most Common Vulnerabilities. However, one must not forget at this point that this technology can only be used at the end of the production cycle.

Conclusion SAST:

If you have access to all system components, the SAST approach can be used very effectively against known security gaps and license problems. This procedure is the only guarantee that the entire tech stack can be subjected to direct control. The focus of the SAST approach is on static semantics and, in turn, is completely blind to security holes in the dynamic context. A huge advantage is that this approach can be used with the first line of source code.

My personal opinion:

My personal opinion on these different approaches is as follows:

If you start with DevSecOps or security in IT in general, the SAST approach makes the most sense. This is where the greatest potential threat can be eliminated with minimal effort. It is also a process that can be used in all steps of the production line. Only when all components in the system are secured against known security gaps do the following methods show their highest potential. After introducing SAST, I would raise the IAST approach and, finally, the RASP approach. This also ensures that the respective teams can grow with the task and that there are no obstacles or delays in production.

Cheers Sven