anchor.diff:  
   <strong><%= modified_date %></strong>
   
  -<%=vars.pcf_rec%> protects customers from security threats by applying security
  -controls and by isolating customer applications and data.
  +<%=vars.pcf_rec%> protects customers from security threats by minimizing network surface area, applying security controls, isolating customer applications and data in containers, and encrypting connections. 
  +
   
   Cloud Foundry:
   
  
positive.code: * Cloud Foundry runs the app inside a secure container. For more information, see the [Application Isolation with Containers](#containers) section.
  
  * Cloud Foundry operators can configure network traffic rules to control inbound communication to and outbound communication from an app. For more information, see the [Network Traffic Rules](#network-traffic) section.
  
  ## <a id='containers'></a>Application Isolation with Containers ##
  
  Each application deployed to Cloud Foundry runs within its own self-contained environment, a Linux [Warden container](./architecture/warden.html). Cloud Foundry operators can configure whether contained applications can directly interact with other applications or other Cloud Foundry system components.
  
  Applications are typically allowed to invoke other applications in Cloud Foundry by leaving the system and re-entering through the load balancer positioned in front of the Cloud Foundry routers. The Warden containers isolate processes, memory, and the file system. Each Warden container also provides a dedicated virtual network interface that establishes IP filtering rules for the app, which are derived from network traffic rules. This restrictive operating environment is designed for security and stability.
  
  Isolation is achieved by namespacing kernel resources that would otherwise be shared. The intended level of isolation is set such that multiple containers present on the same host cannot detect each other. This means that each container is given its own Process ID (PID), namespace, network namespace, and mount namespace.
  
  Resource control is managed using Linux Control Groups ([cgroups](https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt)). Each container is placed in its own cgroup, which requires the container to use a fair share of CPU compared to the relative CPU share of other containers. This placement also determines the maximum amount of memory the container may use.
  
  <p class="note">
  	<strong>Note</strong>: BOSH does not support a RedHat Enterprise Linux OS stemcell. This is due to an inherent security issue with the way RedHat handles user namespacing and container isolation.
  </p>
  
  ### <a id='networking'></a>Networking ###
  
  The [DEA](./architecture/execution-agent.html) for each Warden container assigns the container a dedicated virtual network interface. This interface is one side of a virtual ethernet pair created on the host VM. The other side of the virtual ethernet pair is only visible on the host from the root namespace. The pair is configured to use IPs in a small and static subnet. Traffic to and from the container is forwarded using NAT. Operators can configure global and container-specific <%=vars.net_traffic_rules%> that become Linux iptable rules to filter and log outbound network traffic.
  
  ### <a id='filesystem'></a>Filesystem ###
  
  Every container includes a private root filesystem. For Linux containers, this filesystem is created by stacking a read-only base filesystem and a container-specific read-write filesystem, commonly known as an overlay filesystem. The read-only filesystem contains the minimal set of Linux packages and Warden-specific modifications common to all containers. Containers can share the same read-only base filesystem because all writes are applied to the read-write filesystem. The read-write filesystem is unique to each container and is created by formatting a large sparse file of a fixed size. This fixed size prevents the read-write filesystem from overflowing into unallocated space.
  
  ## <a id='logging'></a>Security Event Logging and Auditing ##
  
  
negative.code: ### <a id='protocols'></a>Protocols ###
  
  All traffic from the public internet to the Cloud Controller and UAA happens over HTTPS. Inside the boundary of the system, components communicate over a publish-subscribe (pub-sub) message bus, [NATS](http://nats.io/), and also HTTP.
  
  ### <a id='bosh'></a>BOSH ###
  
  