Application hardening policies

Application hardening policies are a group of software quality policies used by the Spectra Assure platform to help you improve the overall software package security.

These policies are used during software package analysis to check your compiled code and inform you if any of the built-in validation rules are violated. Specifically, application hardening policies focus on detecting missing vulnerability mitigations in your software to prevent attackers from exploiting any security gaps.

In this context, application hardening gaps cover security issues detected in Windows and Linux binaries, like missing vulnerability protections, insecure coding practices, outdated toolchains, inadequate prevention methods, and missing fortified functions. Application hardening policies alert you if your Windows and Linux software has not been developed according to secure coding practices or if it is not employing common risk mitigation strategies. Advanced users of Spectra Assure can adjust how each policy violation is treated and add their own exceptions to policy configuration files.

In the Spectra Assure SAFE report, these policy violations can be found in the Application Hardening issue category and cause risk in the SAFE Assessment Hardening category.

Software developers will benefit the most from the guidance provided by these policies. When Spectra Assure products detect an application hardening gap in a software package, its exact location is highlighted in the analysis report. Development teams can then apply the remediation advice for each particular policy to resolve detected issues.

Policies in this category

Windows application hardening policies cover the following:

• inefficiently implemented or missing vulnerability mitigations
• insecure compilation and memory management practices
• inadequate toolchain configuration

Linux application hardening policies cover the following:

• inefficiently implemented or missing vulnerability mitigations
• missing fortified functions
• inadequate binary planting prevention

Windows application hardening policies

Show/hide all Windows application hardening policies

• SQ14101 - Detected Windows executable files packed with runtime packers that reduce or nullify the effects of vulnerability mitigation protections.
• SQ14102 - Detected Windows executable files that do not implement the DEP vulnerability mitigation protection.
• SQ14103 - Detected Windows executable files that try to implement DEP but declare all sections as executable thus nullifying the vulnerability mitigation protection.
• SQ14104 - Detected Windows executable files that convert process heap to RWE thus nullifying the DEP vulnerability mitigation protection.
• SQ14105 - Detected Windows executable files that do not implement the ASLR vulnerability mitigation protection.
• SQ14106 - Detected Windows executable files that do not implement the high entropy ASLR vulnerability mitigation protection.
• SQ14107 - Detected Windows executable files that try to implement ASLR but do not have relocations to support that vulnerability mitigation protection.
• SQ14108 - Detected Windows executable files that rely on the ineffective ASLR vulnerability mitigation enforcement option.
• SQ14109 - Detected Windows executable files that trigger ASLR compatibility mode and reduce its effectiveness.
• SQ14110 - Detected Windows executable files that negate ASLR by forcing predicable relocation to first granularity base.
• SQ14111 - Detected Windows executable files that are not large address aware while trying to use high entropy ASLR.
• SQ14112 - Detected Windows executable files with bound imports that will be ignored due to enabled ASLR vulnerability mitigation protection.
• SQ14113 - Detected Windows executable files that do not implement protection from integer based memory allocation overflow attacks.
• SQ14114 - Detected Windows executable files that do not implement the buffer overrun vulnerability mitigation protection.
• SQ14115 - Detected Windows executable files that try to implement buffer overrun vulnerability mitigation without the appropriate security cookie.
• SQ14116 - Detected Windows executable files that might ineffectively generate the security cookie value.
• SQ14117 - Detected Windows executable files that might not cover the entire application with buffer overrun vulnerability mitigation.
• SQ14118 - Detected Windows executable files that might not cover all statically linked libraries with buffer overrun vulnerability mitigation.
• SQ14119 - Detected Windows executable files that do not implement the safe exception handling vulnerability mitigation protection.
• SQ14120 - Detected Windows executable files that do not implement language specific guarded exception handling.
• SQ14121 - Detected Windows executable files that might not cover all statically linked libraries with safe exception handling vulnerability mitigation.
• SQ14122 - Detected Windows executable files that do not implement CFG vulnerability mitigation protection.
• SQ14123 - Detected Windows executable files that might ineffectively implement CFG vulnerability mitigation protection.
• SQ14124 - Detected Windows executable files that might not cover all statically linked libraries with CFG vulnerability mitigation protection.
• SQ14125 - Detected Windows shared library files that do not suppress exports which reduces CFG vulnerability mitigation protection effectiveness.
• SQ14126 - Detected Windows executable files that do not implement XFG vulnerability mitigation protection.
• SQ14127 - Detected Windows executable files that do not implement long jump control flow vulnerability mitigation protection.
• SQ14128 - Detected Windows executable files that do not implement delayed import function hijacking mitigation protection.
• SQ14129 - Detected Windows executable files that do not implement static cast vulnerability mitigation protection.
• SQ14130 - Detected Windows executable files that might not cover all statically linked libraries with static cast vulnerability mitigation protection.
• SQ14131 - Detected Windows executable files that do not implement retpoline vulnerability mitigation protection.
• SQ14132 - Detected Windows executable files that do not implement Intel CET vulnerability mitigation protection.
• SQ14133 - Detected Windows executable files that implement relaxed Intel CET vulnerability mitigation protection.
• SQ14134 - Detected Windows executable files that implement now deprecated RFG vulnerability mitigation protection.
• SQ14135 - Detected Windows executable files that implement now deprecated MPX vulnerability mitigation protection.
• SQ14136 - Detected Windows executable files that are not built with file reproducibility.
• SQ14137 - Detected Windows executable files that enforce image integrity while missing a digital signature.
• SQ14138 - Detected Windows executable files that were compiled without following the recommended SDL process.
• SQ14139 - Detected Windows executable files compiled without following the SDL best practices while using banned memory functions.
• SQ14140 - Detected Windows executable files compiled without following the SDL best practices while using banned string functions.
• SQ14141 - Detected Windows executable files that might have SDL process enforcement coverage gaps.
• SQ14142 - Detected Windows executable files with sections that map header information to their own address space, which may lead to misuse of header information.
• SQ14143 - Detected Windows executable files that have a BSS region with executable attributes.
• SQ14144 - Detected Windows executable files that utilize the outdated and unsafe shared section model for inter process communication.
• SQ14145 - Detected Windows executable files that convert read-only access to writable or executable as a side-effect of their alignment and memory layout.
• SQ14146 - Detected Windows executable files that have no sections causing the headers to gain RWE attributes allowing any code to change them in memory.
• SQ14147 - Detected Windows executable files with the entry point residing in a writable section making it possible to change code while executing.
• SQ14148 - Detected Windows driver files with the entry point residing in a writable section making it possible to change code while executing.
• SQ14149 - Detected Windows executable files with the entry point residing in headers causing data and code to overlap.
• SQ14150 - Detected Windows executable files that implicitly modify headers during loading with function code or relocations.
• SQ14151 - Detected Windows executable files that load dynamic libraries from network or remote server location.
• SQ14152 - Detected Windows executable files that do not require dependency isolation.
• SQ14153 - Detected Windows executable files that opt out of dependency isolation while including a manifest that specifies how dependency loading should be performed.
• SQ14154 - Detected Windows executable files with different data tables overlapping with each other or with file headers.
• SQ14155 - Detected Windows executable files with exported symbols susceptible to pointer hijacking.
• SQ14156 - Detected Windows executable files with imported functions susceptible to pointer hijacking.
• SQ14157 - Detected Windows executable files with delay import functions susceptible to pointer hijacking.
• SQ14158 - Detected Windows executable files with TLS callbacks susceptible to pointer hijacking.
• SQ14159 - Detected Windows executable files with exception handlers susceptible to pointer hijacking.
• SQ14160 - Detected Windows executable files that embed PDB files whose integrity is verified with an insecure hashing algorithm.
• SQ14161 - Detected Windows executable files that are not using a cryptographically secure GUID for their PDB identifier.
• SQ14162 - Detected Windows executable files with security mitigation tables susceptible to pointer hijacking.

Linux application hardening policies

Show/hide all Linux application hardening policies

• SQ18101 - Detected Linux executable files that declare the stack as executable, making non-executable memory mitigations less effective.
• SQ18102 - Detected Linux executable files that declare some writable segments as executable, making non-executable memory mitigations less effective.
• SQ18103 - Detected Linux executable files that might set writable and executable permissions to the code segment, making non-executable memory mitigations less effective.
• SQ18104 - Detected Linux executable files compiled without any kind of buffer overrun protection.
• SQ18105 - Detected Linux executable files compiled without any kind of buffer overrun protection while using banned string functions.
• SQ18106 - Detected Linux executable files compiled without any kind of buffer overrun protection while using banned memory functions.
• SQ18107 - Detected Linux executable files compiled without any kind of buffer overrun protection while using banned input functions.
• SQ18108 - Detected Linux executable files without any fortified functions.
• SQ18109 - Detected Linux executable files that use a deprecated method to store the security cookie, making the buffer overrun vulnerability mitigation protection less effective.
• SQ18110 - Detected Linux executable files that might ineffectively generate the security cookie value, making the buffer overrun vulnerability mitigation protection less effective.
• SQ18111 - Detected Linux executable files that do not implement the ASLR vulnerability mitigation protection.
• SQ18112 - Detected Linux executable files that were compiled without any dynamic symbol hijacking protections.
• SQ18113 - Detected Linux executable files that were compiled without the recommended dynamic symbol hijacking protections.
• SQ18114 - Detected Linux executable files that may be susceptible to binary planting.
• SQ18115 - Detected Linux executable files that may be susceptible to binary planting while using known global or user-writable directories.

Security challenges and practices

Risk (or threat) mitigation is a collection of remedial actions, tools, and techniques used to identify and block potential threats or malicious activities found in your system, as well as lessen the impact of a cyber attack or data leak. Attackers can take advantage of any gaps in your software to access your sensitive information and cause some serious damage to your organization's resources and systems. Therefore, it is essential to detect and mitigate all potential vulnerabilities before your software reaches production.

With the threat landscape evolving rapidly and unpredictably, there is an increased need for risk mitigation strategies. Keeping security measures up to date is becoming a significant challenge for organizations. Thus, it is crucial to be adequately prepared to promptly resolve any security misconfigurations in your software and prevent them from being exploited. This is where application hardening comes in handy.

Application hardening refers to system protection methods that attempt to increase the natural immunity of operating systems or software applications by reducing their attack surface. Some techniques used to achieve this include Address Space Layout Randomization (ASLR), Data Execution Prevention (DEP), stack canaries, and more.

• ASLR is a technique that works on the principle of randomization. Whenever a program is run, its libraries, stack, base, and heap are placed in unpredictable positions across the address space of a process, making their location more difficult to guess. It needs to be enabled together with DEP to be truly effective.
• DEP is a security feature that prevents damage from security attacks attempting to run malicious code from system memory locations reserved only for data structures and variables. It needs to be enabled together with ASLR to be truly effective.
• Stack canaries are a buffer overflow protection technique where a random value (the stack canary) is placed on the stack every time a function is called and is expected to stay unmodified the whole time the function is running. If the value changes, it is a strong indication of potential compromise.

In addition to employing various application hardening strategies, you can increase your software security if you use a memory-safe language whenever possible. However, this does not eliminate the need for vulnerability mitigations, which give your code another layer of protection. To avoid potential security gaps, a key step in your software development lifecycle is implementing relevant secure coding practices. Well-defined, realistic coding standards need to be established and applied consistently to promptly and efficiently catch bugs introduced in development, especially as your projects grow more complex and larger in scale. Clean code, reliable third-party components, secure code reviews, up-to-date toolchains, as well as proper error handling are all practical ways to ensure your software and your organization are kept safe.

Recommended for you

• Secure development and deployment guidance (External resource - National Cyber Security Centre)
• NSA Releases Guidance on How to Protect Against Software Memory Safety Issues (External resource - National Security Agency/Central Security Service)