Software Environment

The Software Environment practice concerns itself with OS and platform patching, web application firewalls, installation and configuration documentation, application monitoring, change management, and ultimately code signing.

Software Environment Level 1

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

The organization monitors the input to software 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 could be responsible for the care and feeding of the system. Incident response is not part of this activity. Defanged WAFs that write log files can be useful if somebody reviews the logs periodically. On the other hand, a WAF that’s unmonitored makes no noise when an application falls in the woods.

[SE1.2: 91] 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. It is common for operations security teams to be responsible for duties such as patching operating systems, maintaining firewalls, and properly configuring cloud services. Doing software security before network security is like putting on your pants before putting on your underwear.

Software Environment Level 2

[SE2.2: 33] Publish installation guides.

The SSDL requires the creation of an installation guide or a clearly described configuration, such as 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. 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: 29] 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: 15] 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 looking for misbehavior and 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: 4] 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. Containers used in development or test environments without reference to security do not count.