anchor.diff:  
   ## <a id='isolation-segments'></a>Isolation Segments
   
  -Isolation segments provide dedicated pools of resources to which apps can be deployed to isolate workloads. Using isolation segments separates app resources as completely as if they were in different <%= vars.product_short %> deployments but avoids redundant management components and unneeded network complexity.
  -				
  -You can designate isolation segments for exclusive use by [orgs and spaces](./roles.html) within <%= vars.product_short %>. This guarantees that apps within the org or space use resources that are not also used by other orgs or spaces.
  +Isolation segments provide dedicated pools of resources to which apps can be deployed to isolate workloads. Using isolation segments separates app resources as completely as if they were in different <%= vars.app_runtime %> deployments but avoids redundant management components and unneeded network complexity.
  +
  +You can designate isolation segments for exclusive use by [orgs and spaces](./roles.html) within <%= vars.app_runtime %>. This guarantees that apps within the org or space use resources that are not also used by other orgs or spaces.
   
   Customers can use isolation segments for different reasons, including the following:
   
  -* To follow regulatory restrictions that require separation between different types of applications. For example, a health care company may not be able to host medical records and billing systems on the same machines.
  -* To dedicate specific hardware to different isolation segments. For example, to guarantee that high-priority apps run on a cluster of high-performance hosts.
  +* To follow regulatory restrictions that require separation between different types of apps. For example, a health care company might not be able to host medical records and billing systems on the same machines.
  +* To dedicate specific hardware to different isolation segments. For example, to ensure that high-priority apps run on a cluster of high-performance hosts.
   * To separate data on multiple clients, to strengthen a security story, or offer different hosting tiers.
  -						
  -In <%= vars.product_short %>, the Cloud Controller Database (CCDB) identifies isolation segments by name and GUID, for example `30dd879c-ee2f-11db-8314-0800200c9a66`. The isolation segment object has no internal structure beyond these two properties at the <%= vars.product_short %> level, but BOSH associates the name of the isolation segment with Diego cells, through their `placement_tag` property.
  +
  +In <%= vars.app_runtime %>, the Cloud Controller database (CCDB) identifies isolation segments by name and GUID, for example `30dd879c-ee2f-11db-8314-0800200c9a66`. The isolation segment object has no internal structure beyond these two properties at the <%= vars.app_runtime %> level, but BOSH associates the name of the isolation segment with Diego Cells, through their `placement_tag` property.
   
   This diagram shows how isolation segments keep apps running on different pools of cells, and how the cells communicate with each other and with the management components:
   
  
positive.code: ---
  
  <%# Reset page title based on product title %>
  <% current_page.data.title = vars.product_short + " Security" if vars.product_name != 'CF'  %>
  
  This topic provides an overview of <%= vars.app_runtime_full %> security. For an overview of container security, see the [Container Security](container-security.html) topic.
  
  <%= vars.product_short %> implements the following measures to mitigate against security threats:
  
  * Minimizes network surface area
  * Isolates customer applications and data in containers
  * Encrypts connections
  * Uses  role-based access controls, applying and enforcing roles and permissions to ensure that users can only view and affect the spaces for which they have been granted access
  * Ensures security of application bits in a multi-tenant environment
  
negative.code: 
  ## <a id='system-boundaries'></a>System Boundaries and Access ##
  
  As the image below shows, in a typical deployment of <%= vars.app_runtime %>, the components run on virtual machines (VMs) that exist within a VLAN. In this configuration, the only access points visible on a public network are a load balancer that maps to one or more <%= vars.app_runtime %> routers and, optionally, a NAT VM and a jumpbox. Because of the limited number of contact points with the public internet, the surface area for possible security vulnerabilities is minimized.
  
  <p class="note"><strong>Note</strong>: <%=vars.recommended_by%> recommends that you also install a NAT VM for outbound requests and a jumpbox to access the BOSH Director, though these access points are optional depending on your network configuration.</p>
  
    <%= image_tag("images/security/sysbound1.png") %>
  
  