Sorry, not available in this language yet

Software Environment

The Software Environment practice deals with OS and platform patching (including in the cloud), WAFs, installation and configuration documentation, containerization, orchestration, application monitoring, change management, and code signing.

Software Environment Level 1

[SE1.1: 87] Use application input monitoring.

The organization monitors input to the software that it runs in order to spot attacks. Monitoring systems that write log files are useful only if humans or bots periodically review the logs and take action. For web applications, a WAF can do this monitoring, while other kinds of software likely require other approaches, such as runtime instrumentation. Software and technology stacks such as mobile and IoT likely require their own input monitoring solutions. Serverless and containerized software can require interaction with vendor software to get the appropriate logs and monitoring data. Cloud deployments and platform-as-a-service usage can add another level of difficulty to the monitoring, collection, and aggregation approach.

[SE1.2: 115] Ensure host and network security basics are in place.

The organization provides a solid foundation for its software by ensuring that host (whether bare metal or virtual machine) and network security basics are in place across its data centers and networks, and that these basics remain in place during new releases. Host and network security basics must account for evolving network perimeters, increased connectivity and data sharing, software-defined networking, and increasing dependence on vendors (e.g., content delivery, load balancing, and content inspection services). Doing software security before getting host and network security in place is like putting on shoes before putting on socks.

[SE1.3: 79] Implement cloud security controls.

Organizations ensure that cloud security controls are in place and working for both public and private clouds. Industry best practices are a good starting point for local policy and standards to drive controls and configurations. Of course, cloud-based assets often have public-facing services that create an attack surface (e.g., cloud-based storage) that is different from the one in a private data center, so these assets require customized security configuration and administration. In the increasingly software-defined world, the SSG has to help everyone explicitly configure cloud-specific security features and controls (e.g., through cloud provider administration consoles) comparable to those built with cables and physical hardware in private data centers. Detailed knowledge about cloud provider shared responsibility security models is always necessary to ensure that the right cloud security controls remain in place.

Software Environment Level 2

[SE2.2: 57] Define secure deployment parameters and configurations.

Create deployment automation or installation guides (e.g., standard operating procedures) to help teams and customers install and configure software securely. Deployment automation usually includes a clearly described configuration for software artifacts and the infrastructure-as-code (e.g., Terraform, CloudFormation, ARM templates, Helm Charts) necessary to deploy them, including details on COTS, open source, vendor, and cloud services components. All deployment automation should be understandable by humans, not just by machines, especially when distributed to customers who buy the software.

[SE2.4: 39] Protect code integrity.

Use code protection mechanisms (e.g., code signing) that allow the organization to attest to the provenance, integrity, and authorization of important code. While legacy and mobile platforms accomplished this with point-in-time code signing and permissions activity, protecting modern containerized software demands actions in various lifecycle phases. Organizations can use build systems to verify sources and manifests of dependencies, creating their own cryptographic attestation of both. Packaging and deployment systems can sign and verify binary packages, including code, configuration, metadata, code identity, and authorization to release material. In some cases, organizations allow only code from their own registries to execute in certain environments. With many DevOps practices greatly increasing the number of people who can touch the code, organizations should also use permissions and peer review to govern code commits within source code management to help protect integrity.

 

[SE2.5: 52] Use application containers to support security goals.

The organization uses application containers to support its software security goals. Simply deploying containers isn’t sufficient to gain security benefits, while their planned use could support a tighter coupling of applications with their dependencies, immutability, integrity (see [SE2.4]), and some isolation benefits without the overhead of deploying a full operating system on a virtual machine. Containers are a convenient place for security controls to be applied and updated consistently (see [SFD3.2]), and while they are useful in development and test environments, their use in production provides the needed security benefits.

 

[SE2.7: 42] Use orchestration for containers and virtualized environments.

The organization uses automation to scale service, container, and virtualized environments in a disciplined way. Orchestration processes take advantage of built-in and add-on security features (see [SFD2.1]), such as hardening against drift, secrets management, RBAC, and rollbacks, to ensure that each deployed workload meets predetermined security requirements. Setting security behaviors in aggregate allows for rapid change when the need arises. Orchestration platforms are themselves software that becomes part of your production environment, which in turn requires hardening and security patching and configuration—in other words, if you use Kubernetes, make sure you patch Kubernetes.

Software Environment Level 3

[SE3.2: 19] Use code protection.

To protect intellectual property and make exploit development harder, the organization erects barriers to reverse engineering its software (e.g., anti-tamper, debug protection, anti-piracy features, runtime integrity). For some software, obfuscation techniques could be applied as part of the production build and release process. In other cases, these protections could be applied at the software-defined network or software orchestration layer when applications are being dynamically regenerated post-deployment. Code protection is particularly important for widely distributed code, such as mobile applications and JavaScript distributed to browsers. On some platforms, employing Data Execution Prevention (DEP), Safe Structured Handling (SafeSEH), and Address Space Layout Randomization (ASLR) can be a good start at making exploit development more difficult, but be aware that yesterday’s protection mechanisms might not hold up to today’s attacks.

[SE3.3: 11] Use application behavior monitoring and diagnostics.

The organization monitors production software to look for misbehavior or signs of attack. Go beyond host and network monitoring to look for software-specific problems, such as indications of malicious behavior, fraud, and related issues. Application-level intrusion detection and anomaly detection systems might focus on an application’s interaction with the operating system (through system calls) or with the kinds of data that an application consumes, originates, and manipulates. Signs that an application isn’t behaving as expected will be specific to the software business logic and its environment, so one-size-fits-all solutions probably won’t generate satisfactory results. In some types of environments (e.g., PaaS), some of this data and the associated predictive analytics might come from a vendor.


[SE3.6: 18] Create bills of materials for deployed software.

Create a BOM detailing the components, dependencies, and other metadata for important production software. Use this BOM to help the organization tighten its security posture, that is, to react with agility as attackers and attacks evolve, compliance requirements change, and the number of items to patch grows quite large. Knowing where all the components live in running software—and whether they’re in private data centers, in clouds, or sold as box products (see [CMVM2.3])—allows for timely response when unfortunate events occur.

 

[SE3.8: 0] Perform application composition analysis on code repositories.

Use composition analysis results to augment software asset inventory information with data on all components comprising important applications. Beyond open source (see [SR2.4]), inventory information (see [SM3.1]) includes component and dependency information for internally developed (first-party), commissioned code (second-party), and external (third-party) software, whether that software exists as source code or binary. One common way of documenting this information is to build BOMs. Doing this manually is probably not an option—keeping up with software changes likely requires toolchain integration rather than carrying this out as a point- in-time activity. This information is extremely useful in supply chain security efforts (see [SM3.5]).