CIS Controls Application Software Security Capability Group

Apply cloud configuration baselines that deactivate unused regions to reduce unmanaged cloud attack surface and help prevent adversaries from creating cloud instances in unused geographic service regions in order to evade detection.

Apply cloud service configuration templates that restrict or disable external data sharing and limit sharing to authorized users or domains to help prevent adversaries from exfiltrating data by transferring the data.

Use standard cloud hardening templates to block unauthorized subscription transfers in Azure and prevent use of the AWS LeaveOrganization API through Service Control Policies to help prevent adversaries from modifying hierarchical structures in infrastructure-as-a-service (IaaS) environments.

Apply hardened web server templates that implement policies on internal web servers, such HTTP Strict Transport Security, that enforce the use of HTTPS/network traffic encryption to prevent insecure connections.

Use standard hardening templates for continuous integration / continuous development (CI/CD) infrastructure that block unreviewed code execution, isolate untrusted builds, restrict secret access, and prohibit unsafe pipeline triggers to help prevent adversaries from manipulating CI/CD processes.

Apply controlled baseline configurations and change management for security-related forwarding mechanisms and firewall rules to help prevent disabling, degrading, or tampering with security tools or applications.

Use standard hardening templates for DNS servers to implement zone transfer policies that permit zone transfers only to validated servers to help prevent adversaries from gathering DNS information.

Apply standard, industry-recommended hardening templates that enforce information repository data retention, archival, and deletion settings to limit accessible data.

Apply standard, industry-recommended databases hardening templates that enforce information repository data retention, archival, and deletion settings to limit accessible data.

Apply standard, industry-recommended customer relationship management software hardening templates that enforce data retention, archival, and deletion settings to limit accessible data.

Use standard hardening templates for application infrastructure components to allowlist MIB objects and implement SNMP views, restricting access to configuration information.

Use standard hardening templates for application infrastructure components to allowlist MIB objects and implement SNMP views, restricting access to configuration information.

Use standard hardening templates to allowlist MIB objects, implement SNMP views, and disable Smart Install when it is not used, reducing exposure of network-device configuration data.

Using standard, industry-recommended hardening templates for cloud containers to enforce the use of container services in rootless mode can help mitigate the effects of adversaries creating or modifying system-level processes.

Selecting and maintaining trusted software components helps prevent integration of malicious or compromised libraries, packages, and software.

Selecting and maintaining trusted software components helps prevent integration of malicious or compromised libraries, packages, and software.

Selecting and maintaining trusted software components helps prevent integration of malicious or compromised libraries, packages, and software.

Application developers can use root-cause analysis to identify and remediate recurring authentication-validation weaknesses, such as missing replay protections, weak session controls, or flawed request validation. This reduces opportunities for adversaries to replay authentication messages, impersonate authorized parties, and conduct exploitation for credential access.

Application developers should exercise caution when selecting and integrating third-party libraries, using root-cause analysis of identified vulnerabilities to strengthen dependency-selection and management practices. This helps prevent supply-chain compromise through vulnerable or malicious software dependencies and development tools.

Application developers should exercise caution when selecting and integrating third-party libraries, using root-cause analysis of identified vulnerabilities to strengthen dependency-selection and management practices. This helps prevent supply chain compromise through vulnerable or malicious software dependencies and development tools.

Application developers can use root cause analysis to address code or build process practices that expose credentials to ensure that applications do not store sensitive data or credentials insecurely.

Use vetted platform and application security modules to validate component integrity; where applicable, include hash values in manifest files to help prevent malicious DLL side-loading.

Using vetted authentication modules or services that support token-binding protections that cryptographically bind a token to a secret can help prevent the token from being used without knowledge of the secret or possession of the device the token is tied to.

Validating authentication requests using vetted platform authentication and identity management services, rather than relying on custom authentication code, can help prevent adversaries from targeting credentialing and authentication mechanisms for exploitation.

Use vetted platform services and trusted application security modules that validate component integrity; where applicable, include hash values in manifest files to help prevent malicious library side-loading.

Using vetted authentication modules or services that support token-binding protections that cryptographically bind a token to a secret can help prevent the token from being used without knowledge of the secret or possession of the device the token is tied to.

Application developers should be cautious when selecting third-party libraries to integrate into their application. Additionally, where possible, developers should lock software dependencies to specific versions rather than pulling the latest version on build.

Application developers should be cautious when selecting third-party libraries to integrate into their application. Additionally, where possible, developers should lock software dependencies to specific versions rather than pulling the latest version on build.

Using a vetted SMS/messaging service that provides and is configured with anti-abuse controls such as CAPTCHA or equivalent bot protection can help prevent adversaries from leveraging messaging services for SMS pumping.

Apply secure design principles to ensure that applications do not store sensitive data or credentials insecurely (e.g. plaintext credentials in code, published credentials in repositories, or credentials in public cloud storage) to help prevent adversaries from obtaining valid accounts.

Apply secure design principles to implement token binding strategies, such as Azure AD token protection or OAuth Proof of Possession, to help prevent the token from being used by adversaries

Apply secure design principles to prevent exposure of sensitive information by ensuring credentials and API keys are not embedded in or published through public code repositories to help prevent adversaries from finding information online about victims that can be used during targeting.

Apply secure design principles to prevent exposure of sensitive information by ensuring credentials and API keys are not embedded in or published through public code repositories to help prevent adversaries from finding information online about victims that can be used during targeting.

Applying secure design principles by implementing CAPTCHA protection on forms that send SMS messages to help prevent adversaries from leveraging messaging services for SMS pumping.

Applying secure design principles through Apple developer guidance which enables hardened runtime protections for applications to help prevent adversaries from modifying property list files (plist files).

Applying secure design principles by enabling the Hardened Runtime capability and not including the com.apple.security.get-task-allow entitlement with the value set to any value of true can help prevent adversaries from providing malicious content to an XPC service daemon.

Applying secure design principles by enabling the Hardened Runtime capability and not including the com.apple.security.get-task-allow entitlement with the value set to any value of true can help prevent adversaries from abusing inter-process communication (IPC) mechanisms.

Applying secure design principles to include hash values in manifest files, where possible, can help prevent adversaries from side-loading malicious dynamic-link library (DLL) files.

Applying secure design principles to include hash values in manifest files, where possible, can help prevent adversaries from hijacking the way operating systems run programs and executing their own malicious payloads.

Applying secure design principles to limit custom or difficult-to-manage file and folder exclusions and use trusted, access-restricted installation paths can help prevent adversaries from hiding file-based artifacts in specific folders or filenames excluded from defensive capabilities.

Applying secure design principles by using the application bundle structure and its designated /Resources folder can help prevent adversaries from abusing resource forks to hide malicious code or executables.

Applying secure design principles to limit custom file and folder exclusions and installing applications only in trusted paths protected by restricted file and directory permissions can help prevent adversaries from hiding artifacts associated with their behaviors.

Applying secure design principles to validate authentication requests, including one-time passwords, timestamps or sequence numbers for messages sent, digital signatures, and random session keys, can help prevent adversaries from exploiting software vulnerabilities to attempt to collect credentials.

Apply secure design principles to implement token binding strategies, such as Azure AD token protection or OAuth Proof of Possession, to help prevent the token from being used by adversaries

Static and dynamic application security testing can identify exploitable application weaknesses such as injection flaws, unsafe input handling, authentication defects, and other code-level vulnerabilities before or during release, reducing opportunities to exploit public-facing applications.

Where code-level security checks scan application code, configuration, and repositories for hardcoded or otherwise insecurely stored credentials, exposed authentication material can be identified and removed before release, reducing opportunities for adversaries to obtain and abuse valid accounts.

Code-level security checks within the application lifecycle can identify vulnerable, malicious, or unexpected code and software components introduced through software supply-chain compromise. This relationship applies to software and development-chain compromise that can be detected through static, dynamic, dependency, integrity, or release-pipeline analysis.

Static analysis, dependency review, and build-pipeline security checks can identify vulnerable, unexpected, or suspicious third-party dependencies and development artifacts before they are incorporated into or released with enterprise software.

Automated or manual code review, static and dynamic testing, and release-pipeline integrity checks can identify unexpected or malicious modifications introduced into software before the compromised build or update is distributed.

Code-level and build-time security checks can identify unsafe executable or library search paths, missing integrity values, and other application-loading conditions that permit adversaries to hijack execution flow, allowing those weaknesses to be corrected before release.

Static and build-time checks can identify insecure DLL search behavior and verify expected library paths or manifest integrity information, reducing opportunities for malicious DLL side-loading or search-order hijacking in developed applications.

For applications that use inter-process communication, code-level security checks can verify hardened runtime settings, entitlements, and IPC-related security configuration so insecure development settings that permit unauthorized process interaction can be identified before release.

For macOS applications using XPC services, build and code-level checks can verify hardened runtime and entitlement settings and identify insecure configurations that could allow unauthorized interaction with or abuse of XPC services.

Static and dynamic security checks can verify secure implementation of token handling and token-binding or proof-of-possession controls, helping identify application designs that would allow stolen authentication material to be reused without the intended cryptographic or device-bound protections.

Code-level and dynamic security testing can identify insecure application access-token handling and verify token-binding or proof-of-possession protections, reducing the ability to reuse a stolen application token outside its intended security context.

Static and dynamic security testing can verify application controls that validate authentication requests, such as one-time values, timestamps, sequence numbers, digital signatures, or random session keys, helping identify weaknesses that could otherwise be exploited to obtain credential material.

Where development or release pipelines validate code signatures as part of code-level security checks, invalid, missing, or untrusted signatures can be identified before software is released, reducing opportunities to distribute or execute software that misrepresents its authenticity or provenance.

For macOS applications, code-level and build-pipeline checks can verify hardened runtime, signing, and expected application configuration settings, helping identify insecure development conditions that could make application behavior or configuration more susceptible to malicious plist modification.

Separating production and non-production environments with enforced network and administrative boundaries can restrict non-production systems and management paths from reaching production identity infrastructure, reducing opportunities to modify production accounts or authentication settings.

Separate production cloud environments, VPCs, and control-plane access paths can prevent non-production systems or administrators from reaching production identity interfaces used to add cloud credentials to existing accounts.

Network separation between production and non-production environments limits the infrastructure and traffic paths visible from either environment, reducing the scope in which an adversary can position for interception or manipulation of communications.

Separating production and non-production broadcast, name-resolution, and SMB communication paths can constrain poisoning activity and prevent non-production systems from directly relaying authentication to production services.

Production and non-production container or virtualization infrastructure can be placed behind separate gateways, firewalls, or control-plane boundaries so a compromised non-production system cannot directly reach production hosts used to build images.

Separating production and non-production container control planes and network paths can prevent a compromised non-production workload from directly querying production container APIs, dashboards, nodes, or resource inventories.

Enforced separation can restrict access from non-production systems and administrative paths to production account-management infrastructure, reducing the ability to create accounts in the production environment from a compromised non-production environment.

Production domain controllers and account-management services can be isolated from non-production networks so non-production systems cannot directly reach the services used to create or manage production domain accounts.

Separate production cloud environments and restricted control-plane connectivity can limit non-production access to production identity services used to create cloud accounts.

Production configuration-management interfaces and repositories can be placed on network or management segments that are not directly reachable from non-production systems, reducing unauthorized collection of production configuration data.

Separating production management traffic from non-production networks can restrict SNMP access to approved production management systems and prevent non-production hosts from directly querying production MIB data.

Production network-device management interfaces can be isolated from non-production environments so non-production systems cannot directly access SNMP, Smart Install, or other interfaces used to retrieve production device configurations.

Separating production from non-production systems reduces unauthorized cross-environment access to production data and business processes, limiting the ability of a compromise in development or test infrastructure to directly manipulate production information.

Enforced production boundaries can prevent non-production systems from directly reaching production applications and runtime services, reducing opportunities to alter data while it is being processed in the production environment.

Separate production and non-production container control planes can prevent compromised non-production systems from directly accessing production APIs or orchestrators used to deploy containers.

Separating sensitive production identity infrastructure from non-production networks can restrict the connectivity required for systems in non-production environments to enumerate production domains and trust relationships.

Firewalls and access controls between production and non-production environments can permit only required protocols and destinations, blocking unauthorized alternate-protocol transfers across the production boundary.

Production/non-production boundary controls can deny unapproved encrypted protocols, ports, and destinations, limiting exfiltration over symmetrically encrypted non-command-and-control channels across environments.

Production/non-production boundary controls can restrict unapproved encrypted protocols and destinations, limiting exfiltration over asymmetrically encrypted non-command-and-control channels across environments.

Production/non-production segmentation can block unnecessary plaintext protocols and destinations across the environment boundary, directly restricting unencrypted non-command-and-control exfiltration paths.

Production services can be placed on separate hosting or security zones from non-production systems so exploitation of an exposed application does not provide unrestricted network reachability into other production resources.

Separating production and non-production systems with controlled network paths reduces the remote services reachable across environments and limits exploitation-based movement from a compromised non-production system into production.

Production remote-access services can be exposed only through dedicated gateways, proxies, or approved access paths that are separate from non-production access, preventing direct remote connectivity from less-trusted environments into production.

Network segmentation between production and non-production systems limits host and service reachability, reducing the production systems that can be discovered from a compromised development or test environment.

Separating production and non-production network segments limits the traffic, broadcasts, and multicast communications visible from either environment, reducing opportunities to capture production traffic from non-production systems.

Production/non-production firewalls and gateways can restrict communication to approved interfaces and protocols, blocking unauthorized non-application-layer traffic across the environment boundary.

Boundary firewalls between production and non-production environments can allow only explicitly required ports, preventing arbitrary cross-environment communication over non-standard or unauthorized ports.

Restricting remote-service traffic between production and non-production security zones reduces the ability of an adversary in one environment to reach and hijack remote sessions in the other.

Blocking unnecessary RDP traffic between production and non-production environments prevents non-production systems from directly reaching production RDP sessions that could otherwise be hijacked.

Production/non-production segmentation can restrict RDP to explicitly approved administrative paths and block ordinary cross-environment RDP connectivity.

Firewall rules between production and non-production environments can restrict DCOM and RPC connectivity, reducing opportunities for remote DCOM execution across the environment boundary.

Production systems can use separate WinRM management paths and firewall rules that permit access only from approved administrative systems, preventing general non-production systems from reaching production WinRM services.

Separating production systems and supporting security or response infrastructure from non-production networks can reduce the ability of an adversary who compromises non-production systems to reach and stop critical production or defensive services.

Production deployment and management infrastructure can be isolated from non-production systems and reachable only through approved administrative paths, reducing the ability to abuse a compromised non-production deployment tool to execute software in production.

Separating production and non-production environments prevents a trusted integration or relationship available in a less-restricted non-production environment from automatically providing equivalent network reachability into production.

Production container APIs can be isolated behind separate gateways, firewalls, or control-plane networks so non-production workloads cannot directly access production container interfaces that may expose credentials or sensitive configuration.

Where non-production or general wireless access is separated from production network segments, enforced segmentation prevents systems that gain Wi-Fi connectivity from directly reaching sensitive production resources.