Secure Execution Container

Name (Title)	Secure Execution Container
Description	A container that is able to provide a safe environment where applications, jobs, or services can be run. Specifically, a Secure Execution Container should be capable of providing security enforcement and monitoring functions such that it can protect a running services from unauthorized external influence (originating outside of the container). Further it must also be capable of protecting the IT environment from the service in the event of an accidental or malicious change that causes the service to behave badly. The degree to which protection is afforded will vary based upon the actual implementation choices made, but as a rule, it is expected that the security configuration of the Secure Execution Container will be tuned based upon the services it supports. It will likely involve the integration of one or more technologies or products in support of its security objectives.
Alias	SEC
Intent	The intent is to construct a safe environment for the execution of services capable of: Protecting itself from unauthorized access or use by the services running within it. Protecting any service running within the container from unauthorized external influence. Protecting the IT environment and other services outside of the container (should a running service be mis-configured or compromised). Providing an audit trail of events occurring within the container for monitoring and analysis.
Motivation	Services running in an unsecured container are often susceptible to attacks from the outside that can damage the service or container. Likewise the environment beyond the container could be adversely affected by malicious code from within the container. It is thus imperative for a container that runs applications or services to protect itself from compromised or malicious external services and similarly to protect the outside environment should anything unexpected happen to services it is hosting. This pattern includes three logical boundary elements: Outside - This is beyond the boundary of the container and is where all requests to interact with the container's service originate. Inside - This is inside of the boundary where the container's service and all of its constituent parts are located. Boundary - This is a correct, verifiable, boundary "container" that cannot be bypassed and only exposes permitted interfaces to the outside while enforcing allowed policy on components running on the inside.
Applicability	The Secure Execution Container pattern can be used in most IT environments and with virtually any service. It is especially important for those environments seeking stronger security protections for the purposes of risk reduction and attack mitigation. By providing a controlled boundary through which services can be accessed, the Secure Execution Container is able to provide enhanced security protections for the service and the environment in which the service is hosted. This pattern is most useful when there are clear, well-defined interfaces for interacting with the service or when there is no direct need for service interaction (such as in the case of batch processing).
Structure
Participants	Service. A Service is the object that is installed and executed within the Secure Execution Container. It could be a composite application, a single service or a batch job. There are no restrictions on the type of service that can be used within an ISC although those with well-defined communication and processing interfaces are more suited to this type of environment. The actual service used will determine what security protections are needed in terms of the service itself. Secure Execution Container. The Secure Execution Container provides a security boundary around the Service. External clients can interact with the Service through published interfaces and the Service can also initiate messages to outside services through this interface. All communications and access methods are arbitrated by the Secure Execution Container's security boundary. Security Hardened Service Container. This is a operational quality of the Secure Execution Container. This element is used to depict the need to properly implement security hardening and configuration tuning of the container in which the Service is delivered. The actual steps taken to secure this container will vary based upon the implementation chosen. Service Container Security Functions. This is a functional element of the Secure Execution Container. This element is used to depict the need for security enforcement and monitoring functions that exist in the Secure Execution Container and are used to implement the protections described in the Intent section above. The actual security controls available and used will vary based upon the implementation chosen.
Collaboration	See the Participants section above to understand the relationships between the various elements of this pattern.
Consequences	The primary benefits of the Secure Execution Container pattern are related to the isolation of a service running inside a security boundary that helps to protect both the service and the environment within which it runs from unauthorized access and influence. Certainly, it is expected that all products used in the implementation of this pattern will be configured to use recommended security practices and as such it is expected that the overall attack surface of the SEC and its Service will be minimized. As the actual techniques used to implement the security configuration will vary by implementation, it is expected that specific products will be chosen based upon operational and security policy and requirements. While the notion of Secure Execution Containers is a general one that can accommodate most services, it must be noted that services with variable or ill-defined access methods or interfaces may not be suited for this particular pattern.
Implementation	Immutable Service Containers
Known uses	OpenSolaris and Solaris Zones, J2EE Containers, Java Sandbox
Related patterns	Immutable Service Containers, Immutable Service Container Dock
Author	Rafat Alvi, Glenn Brunette, Joel Weise
Reviewer	Ed Clay, Joel Weise

Secure Execution Container

Labels