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: 58] 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 the job; other kinds of software likely require other approaches. The SSG might be responsible for the care and feeding of the system, but incident response is not part of this activity. Defanged WAFs that write log files can be useful if someone periodically reviews the logs. A WAF that’s unmonitored makes no noise when an application falls in the woods.

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

The organization provides a solid foundation for software by ensuring that host and network security basics are in place. Operations security teams are usually responsible for patching operating systems, maintaining firewalls, and properly configuring cloud services, but doing software security before network security is like putting on pants before putting on underwear.  

Software Environment Level 2

[SE2.2: 39] 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 the software securely. If special steps are required to ensure a deployment is secure, the steps are either outlined in the installation guide or explicitly noted in deployment automation. The guide should include a discussion of COTS components, too. In some cases, installation guides are distributed to customers who buy the software. Make sure that all deployment automation can be understood by smart humans and not just a machine. Evolving DevOps and integrated team structures do not eliminate the need for human-readable guidance. Of course, secure by default is always the best way to go.

[SE2.4: 31] Use code signing.

The organization uses code signing for software published across trust boundaries. Code signing is particularly useful for protecting the integrity of software that leaves the organization’s control, such as shrink-wrapped applications or thick clients. The fact that some mobile platforms require application code to be signed does not indicate institutional use of code signing.

Software Environment Level 3

[SE3.2: 17] Use code protection.

To protect intellectual property and make exploit development harder, the organization erects barriers to reverse engineering. This is particularly important for widely distributed mobile applications. Obfuscation techniques could be applied as part of the production build and release process. Employing platform-specific controls such as Data Execution Prevention (DEP), Safe Structured Error Handling (SafeSEH), and Address Space Layout Randomization (ASLR) can make exploit development more difficult.

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

The organization monitors the behavior of 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 may 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.

[SE3.4: 11] Use application containers.

The organization uses application containers to support its software security goals. The primary drivers for using containers include ease of deployment, a tighter coupling of applications with their dependencies, and isolation 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. The ones used in development or test environments without reference to security do not count.

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

The organization uses automation to scale 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 container and virtual machine meets predetermined security requirements. Setting security behaviors in aggregate allows for rapid change when the need arises. Of course, orchestration platforms are themselves software that, in turn, requires security patching and configuration. If you use Kubernetes, make sure you patch Kubernetes.

[SE3.6: 0] 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 allows organizations to secure all the things. 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 all the components 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.

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

Of course, you already do [SE1.2 Ensure host and network security basics are in place], right? Someone must ensure that basic requirements are met in cloud deployments as well. In the increasingly software-defined world, you must explicitly implement security features and controls (some of which may be built in) at least as good as those built with cables and physical hardware. Nothing is as automatic as it seems.