Software Environment

DEPLOYMENT: Software Environment (SE)

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

Software Environment Level 1

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

The organization monitors the input to the software that it runs in order to spot attacks. For web code, a web application firewall (WAF) can do this job, while other kinds of software likely require other approaches. The SSG might be responsible for the care and feeding of the monitoring system, but incident response isn’t part of this activity. For web applications, WAFs that write log files can be useful if someone periodically reviews the logs and takes action. Other 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: 111] Ensure host and network security basics are in place.

The organization provides a solid foundation for its software by ensuring that host and network security basics are in place across its data centers and networks. Evolving network perimeters, increased connectivity and data sharing, and increasing interdependence on vendors (e.g., content delivery, load balancing, and content inspection services) add a degree of difficulty even to getting the basics right. Doing software security before getting host and network security in place is like putting on shoes before putting on socks.

Software Environment Level 2

[SE2.2: 36] Publish installation guides.

The SSDL requires the creation of an installation guide or a clearly described configuration (such as for a container) to help deployment teams and operators install and configure software securely. If special steps are required to ensure a deployment is secure, these steps can either be outlined in the guide or explicitly noted in deployment automation; the guide should include a discussion of COTS and vendor components as well. In some cases, installation guides are distributed to customers who buy the software. All deployment automation should be understandable by humans, not just machines. Increasingly, this means infrastructure scripting (e.g., Terraform, Helm, Ansible, and Chef) becomes the installation guide.

[SE2.4: 27] Use code signing.

The organization uses code signing for software published across trust boundaries, which is particularly useful for protecting the integrity of software that leaves the organization’s control, such as shrink-wrapped applications or thick clients. In cloud environments, leveraging code signing might be important when packaging and distributing mobile applications, containers, and machine images through vendor registries or in-house hosted registries. The fact that some mobile platforms require the application code itself to be signed doesn’t indicate institutional use of code signing.

Software Environment Level 3

[SE3.2: 13] 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). This is particularly important for widely distributed mobile applications. For some software, obfuscation techniques could be applied as part of the production build and release process. In other cases, the protections could be applied at the software-defined network or software orchestration layer when applications are being dynamically regenerated post-deployment. On some platforms, employing Data Execution Prevention (DEP), Safe Structured Error Handling (SafeSEH), and Address Space Layout Randomization (ASLR) can be a good start at making exploit development more difficult.

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

The organization monitors production software to look for misbehavior or signs of attack. This activity goes beyond host and network monitoring to look for software-specific problems, such as indications of malicious behavior. Intrusion detection and anomaly detection systems at the application level 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. In any case, the signs that an application isn’t behaving as expected will be specific to the software 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.4: 14] Use application containers.

The organization uses application containers to support its software security goals, which likely include ease of deployment, a tighter coupling of applications with their dependencies, immutability, integrity (see [SE2.4 Use code signing]), and some isolation benefits without the overhead of deploying a full OS on a virtual machine. Containers provide a convenient place for security controls to be applied and updated consistently. While containers can be useful in development and test environments, production use provides the real benefit.

[SE3.5: 5] Use orchestration for containers and virtualized environments.

The organization uses automation to scale service, container, and virtual machine deployments in a disciplined way. Orchestration processes take advantage of built-in and add-on security controls to ensure 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 become part of your production environment, which in turn requires security patching and configuration; in other words, if you use Kubernetes, make sure you patch Kubernetes.

[SE3.6: 3] Enhance application inventory with operations bill of materials.

A list of applications and their locations in production environments is essential information for any well-run enterprise (see [CMVM2.3 Develop an operations inventory of applications]). In addition, a manifest detailing the components, dependencies, configurations, external services, and so on for all production software helps the organization to 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—whether they’re in private data centers, in clouds, or sold as box products—allows for timely response when unfortunate events occur. Done properly, institutional use of container security solutions can make inventory efforts much simpler.

[SE3.7: 9] Ensure cloud security basics.

Organizations should already be ensuring that their host and network security basics are in place, but they must also ensure that basic requirements are met in cloud environments. Of course, cloud-based virtual 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 implement cloud-based security features and controls (some of which can be built in, for example, to cloud provider administration consoles) that are 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.