anchor.diff:  
   ### <a id='deleting-groups'></a>Delete ASGs ##
   
  -<p class='note'><strong>Note</strong>: You can only delete unbound ASGs. To unbind ASGs, see <a href="#unbinding-groups">Unbind ASGs</a> below.</p>
  +<p class='note'><strong>Note</strong>: You can only delete unbound ASGs. To unbind ASGs, see <a href="#unbinding-groups">Unbind ASGs</a> above.</p>
   
   To delete an ASG, run the following command:
   
  
positive.code: 
  <strong><%= modified_date %></strong>
  
  _This page assumes you are using [cf CLI](https://github.com/cloudfoundry/cli) v6.4 or higher._
  
  ## <a id='introduction'></a>Introduction ##
  
  This topic describes how to use and administer Application Security Groups (ASG). 
  
  ASGs are a collection of egress rules that specify the protocols, ports, and IP address ranges where app and task containers send traffic. Because ASGs define *allow* rules, their order of evaluation is unimportant when multiple application security groups apply to the same space, org, or deployment. Containers use these rules to filter and log outbound network traffic. ASGs apply to both buildpack-based and Docker-based containers in both the app and task lifecycle phases.
  
  When apps begin staging, they need traffic rules permissive enough to allow them to pull resources from the network. After an app is running, the traffic rules can be more restrictive and secure. To distinguish between these two security requirements, administrators can define one ASG for app and task staging, and another for app and task runtime. 
  
  To provide granular control when securing a deployment, an administrator can also assign ASGs to apply across a deployment, or to specific spaces or orgs within a deployment.
  
  ASGs can be complicated to configure correctly, especially when the specific IP addresses listed in a group change. To simplify securing a deployment while still permitting apps reach external services, operators can deploy the services into a subnet that is separate from their Cloud Foundry deployment. Then the operators can create ASGs for the apps that whitelist those service subnets, while denying access to any virtual machine (VMs) hosting other apps.
  
  For examples of typical ASGs, see the <a href="#typical-groups">Typical Application Security Groups</a> section of this topic.
  
  ## <a id='default-asg'></a>Default ASGs ##
  
  <% if vars.product_name == 'CF' %>
  <%= partial 'default_asg_oss' %>
  
negative.code: |`cf security-groups`                |All ASGs
  |`cf staging-security-groups`        |All ASGs applied to the platform-wide staging ASG set
  |`cf running-security-groups`        |All ASGs applied to the platform-wide running ASG set
  |`cf security-group SECURITY-GROUP`         |All rules in the ASG named `SECURITY-GROUP`, for example, <code>cf security-group dns</code>
  
  ###<a id='asg-individual'></a>Create ASGs
  
  To create an ASG, perform the following steps: 
  
  1. Create a rules file: a JSON-formatted single array containing objects that describe the rules. 
     See the following example, which allows ICMP traffic of code `1` and type `0` to all destinations,  and TCP traffic to `10.0.11.0/24` on ports `80` and `443`. Also see [The Structure and Attributes of ASGs](#creating-groups).
  
      <pre>
      [
  