Configuring Cisco Secure Access Secure Internet Access

What it is

Secure Internet Access protects users and sites that go to the internet and to cloud applications, using policy enforced in the Cisco cloud.

Traffic from your users is steered to the Cisco Secure Access service. There the service checks it with DNS layer security, a secure web gateway, a cloud delivered firewall and other tools. You decide what is allowed through policy rules.

How it works

The setup has three stages: connect the traffic, define who and what, and write the policy.

Stage 1: connect traffic to the service

Secure Access can protect traffic only if it arrives there. Choose the method that fits each user group and site.

For a branch, a tunnel is built from the branch device to the service, and the branch network traffic goes through it. A PAC file is a small script that tells the browser which requests go to the proxy and which go direct.

function FindProxyForURL(url, host) {
    if (isInNet(host, "10.0.0.0", "255.0.0.0")) {
        return "DIRECT";
    }
    return "PROXY PROXY_HOST_NAME:PORT";
}

This sample sends internal addresses direct and everything else to the proxy. The real proxy name comes from your service settings.

Stage 2: identities

Policy needs to know who the traffic belongs to. Identities can come from several sources.

• Users and groups: usually synchronised from a directory such as Active Directory or an identity provider.
• Devices: roaming computers that run the client.
• Networks and tunnels: a site, identified by its egress address or by its tunnel.

Identity based rules follow the user between office and home. Network based rules are for sites that have no user level information.

Stage 3: internet access policy

An internet access policy is an ordered list of rules. Each rule has the same main parts.

Rules are evaluated from the top, and the first match decides. Specific rules go above general rules, and the final rule decides what happens to everything that is left.

Destinations can be content categories, such as social media or gambling, or custom lists of domains and URLs. Application controls let you allow an application but restrict certain actions in it.

Security profiles and inspection

A security profile, together with other rule settings, chooses the inspection to run on permitted traffic. The exact options depend on your licence and the current product release.

• Malware and file inspection: scans downloads with anti-malware engines and reputation.
• Intrusion prevention: looks for exploit patterns in the traffic.
• Content and application controls: filter by category and by application behaviour.

A rule can use the isolate action to open a risky site in a remote browser, so no active code reaches the device.

TLS decryption

Most web traffic is encrypted, so inspection of content needs decryption. The service acts as a proxy, so it ends the user's TLS session, inspects the clear text, and creates a new session to the site. Devices must trust the certificate authority that signs these certificates, so you deploy that root certificate to them.

Some traffic should not be decrypted, such as banking and health sites, and sites that pin their certificates. A do not decrypt list handles these exceptions.

Testing and monitoring

After you build policy, test it from a connected device and check the activity reports. The reports show the identity, the destination, the rule that matched and the action taken. Use them to find rules that are too broad or too tight.