Overview

The increasing number of sensors, actuators, and devices attached to remote and mobile assets greatly complicates security due to the increased attack surfaces. Protecting the networks and devices is paramount to ensuring the safety and continuity of business. The Cisco Remote and Mobile Assets (RaMA) architecture has been developed with this in mind and has been validated in our labs and with the Cisco internal security audit team to help ensure it provides the safest environment for our customers across three attack vectors:

• Management plane security
• Data plane security
• Gateway and hardware security

Requirements

The Cisco RaMA architecture aligns with the Cisco SAFE security model and methods to simplify end-to-end security depending on the audience needs. Ranging from business flows and their respective threats to the corresponding security capabilities, architectures, and designs, SAFE provides guidance that is holistic and understandable.

Note: More information on the Cisco SAFE security reference architecture is available at: https://www.cisco.com/go/safe

By aligning with the SAFE Places in the Network (PINs) of Threat Defense, Segmentation, Secure Services, and Management, the RaMA architecture provide the ability to segment data and management, encrypt traffic, and provide secure remote access to connected devices.

Figure 1: Key to SAFE

The Key to SAFE organizes the complexity of holistic security into PINs and Secure Domains.

These SAFE requirements optimize protection from potential vulnerabilities by requiring a security centric IoT design that helps ensure that every element of the platform is secure, starting from the authentication of edge devices. In addition to secure device access, multiple secure connectivity options are required to ensure protection of enterprise data. Each layer of the IoT architecture must be secured to ensure security of both the management plane and the data plane.

Management Plane Security

• Use of an encrypted IP Security (IPSec) tunnel to provision and manage the edge gateways
• Certificate-based authentication during the gateway claiming process
• Multi-tenant Gateway Cloud Management (IoT Operations Dashboard) with support for:
  
  • Single sign-on and two-factor authentication
    
  • Role-based access control
    
  • Logging and auditing

Data Plane Security

The Data Plane refers to all customer/user data from the gateway or devices behind it that are not related to the management of the gateway itself. Feature highlights include:

• Secure connectivity from the edge gateways up to the enterprise headend using FlexVPN to establish encrypted tunnels using IPSec and Internet Key Exchange Protocol version 2 (IKEv2).
• Support for Secure Equipment Access (SEA) to enable secure remote access to devices behind the gateway via a secure connection through IoT-OD.
• WPA2-protected Wi-Fi with Pre Shared Keys (PSK) or RADIUS-based authentication.
• No user data goes to the management cloud. When a site-to-site VPN is deployed, all user data can be routed through the enterprise. Cisco recommends routing all traffic through the customer VPN headend if secure traffic is important.
• Support for industry-specific security requirements such as the Payment Card Industry Data Security Standard (PCI DSS) allowing organizations and sellers to safely and securely accept, store, process, and transmit cardholder data during credit card transaction to prevent fraud and data breaches.
• Integrated Cloud-based Cisco Umbrella for DNS-Layer security.
• Push button Zone-Based Firewall featuring Cisco’s latest firewall models providing simple, secure, and flexible firewall solutions.
• Integrated Cisco Stealthwatch support in edge Gateways through built in NetFlow support providing comprehensive visibility and network traffic security analytics solution. It provides advanced threat detection, accelerated threat response, and simplified network segmentation using multilayer machine learning and entity modeling.

Gateway and Device Security

At the gateway level, soft and physical security is provided for the gateway and the connected devices. Feature highlights include:

• Use of 802.1x to authenticate wireless or wired Ethernet clients.
• Cisco Trustworthy Technologies, including image signing, secure boot, and chain of trust.
• Physical gateway security using Trust Anchor module (TAm)—This proprietary, tamper-resistant chip features nonvolatile secure storage, Secure Unique Device Identifier, and crypto services.

Architecture

RaMA Base Security Architecture

Figure 2 illustrates key security aspects of the RaMA architecture today. It highlights key data and management plane security as well as software and hardware-based gateway security features.

Figure 2: RaMA Base Security Architecture

RaMA Enhanced Security Features

Figure 3 builds upon existing security infrastructure with enhanced security features that incorporate Cisco's Cloud-Based security product Umbrella and a host of additional products and services that Cisco offers today to speed up deployment and continually monitor the network for intrusions.

Figure 3: RaMA Enhanced Security Features

Key features for RaMa:

1. Cisco Umbrella DNS Integration
2. Cisco IOS Zone Firewall deployments
3. Cisco NetFlow with Stealthwatch
4. Cisco FlexVPN for Enterprise Network Access and AnyConnect for Remote Device Access

Design

Securing the Cisco IoT Operations Dashboard Management Plane

Encrypted IPSec Tunnel

All provisioning and management of the edge gateways occurs over encrypted IPSec tunnels to ensure secure communication between IoT Operations Dashboard and the gateways.

Certificate-based Authentication

The registration and claim process between IoT Operations Dashboard and the gateways is secured using a certificated-based authentication process. This helps prevents spoofing of the gateway and guards against man-in-the-middle attacks where an external server claims to be acting on behalf of a legitimate IoT Operations Dashboard server.

Web UI with Single Sign-on and Two-Factor Authentication

User names and passwords are no longer a safe security method for online accounts. Data breaches occur daily and hackers are always inventing new ways to take over accounts. The IoT Operations Dashboard platform supports both enterprise Single Sign-On (SSO) and two-factor authentication on its Web-UI to provide an extra layer of security. Users can point their logins to their SSO server if needed and also rely on two layers of security to protect the account in the form of two-factor authentication (2FA).

Secure Remote Device Connectivity

Cisco's IoT-OD allows users to securely access equipment behind the managed gateway based on tightly defined access methods (SSH, HTTPS, etc) and user permissions.

Role-Based Access Control (RBAC)

Cisco IoT Operations Dashboard provides several levels of access to the Web-UI. Depending on the user’s role (administrator, operator, or monitor), various features are either available or restricted.

Figure 4: User Roles

Logging and Auditing

Keeping a record of all actions performed through Cisco IoT-OD, as well as events related to gateway status, helps in a post mortem analysis after a security incident. Similarly, alerts can be configured to be sent immediately when a specified operation or event is observed, allowing the proper individuals to respond accordingly.

Figure 5: Audit Trail

Securing the Data Plane

Introduction to IPSec VPNs

VPNs are designed to securely and inexpensively extend the reach of corporate networks. Several options have been built on top of IPSec, a framework that addresses the task of ensuring the confidentiality, integrity, and authentication (CIA) of origin and secure key distribution for VPNs. Using a VPN secures the data plane and isolates it from the management and configuration of the gateway, which provides segmentation between management and data flow. All data that flows through the gateway flows through a customer-managed headend at the company data center or directly to the internet.

Some of the notable strengths of IPSec are its independence from the transport layer (UDP, TCP, or raw IP) and the simple replacement of one or more of its components (such as hash functions and cryptographic algorithms), so it can withstand brute force attacks while keeping current with the evolution of hardware.

The Cisco IOS software offers multiple VPN options including Classic IPSec, IPSec/GRE, Virtual Tunnel Interface (VTI), EasyVPN, and Dynamic Multipoint VPN (DMVPN). Each of these technologies were developed to solve specific problems:

• Crypto Maps are the initial/legacy solution devised before IPSec was an RFC. Although the services available are very basic, they help with interoperability.
• VTI brings a logical interface to IPSec deployments without the need for Generic Routing Encapsulation (GRE).
• EasyVPN allows branch routers (or other types of VPN appliances) to behave as hardware clients that are centrally configured by a VPN concentrator.
• DMVPN provides the capability to dynamically establish tunnels between spokes in a hub-and-spoke scenario.

Table 1: VPN Options

The Cisco RaMA solution uses IPSec-based FlexVPNs rather than SSL-based VPNs. Since it is application agnostic, IPSec can support several legacy protocols and traditional client/server applications with minimal effort. This is not the case with SSL VPNs, which have been built around web-based applications. As a result, SSL VPN-based options like OpenVPN could severely limit the security and network options for remote and mobile assets by requiring always-on connectivity to the headquarters.

Introduction to FlexVPN

FlexVPN is a framework for configuring IPSec VPNs on Cisco IOS devices. It was created to simplify the deployment of VPN solutions of all types, such as hub-and-spoke, spoke-to-spoke, site-to-site, and remote access implemented through EasyVPN, DMVPN, and Crypto Maps.

FlexVPN is Cisco’s implementation of the IKEv2 standard featuring a unified paradigm and CLI that combines site to site, remote access, hub and spoke topologies, and partial meshes (spoke to spoke direct). FlexVPN offers a simple but modular framework that extensively uses the tunnel interface paradigm while remaining compatible with legacy VPN implementations using crypto maps.

• FlexVPN requires the use of IKEv2, which is a more secure option than the original implementation (IKEv1).
• By design, IKEv2 is not backward compatible with IKEv1 since it provides increased security. IKEv2 requires reconfiguration of all IPSec VPNs.

Benefits of Using FlexVPN

• Built on IKEv2—IKEv2 is more secure than IKEv1 because it supports the latest Suite B cryptographic algorithms. IKEv2 has built-in support for Dead Peer Detection (DPD) and NAT-Traversal. It is also resistant to DoS attacks.
• Ease of configuration—It is easy to configure using IKEv2 built-in, smart defaults, so there is no need to define policies, transform sets, etc.
• Cost effective—The FlexVPN hub-and-spoke design does not require NHRP (unlike DMVPN), which reduces WAN bandwidth utilization and costs due to reduced control plane traffic.
• Support for hardware encryption:
  • IKEv2 stability—It automatically resumes normal operation after a temporary interruption of a connection, such as after a power outage or when entering a real-world tunnel.
  • IKEv2 route advertisement—Another cost benefit is IKEv2’s ability to advertise routes during tunnel negotiation, which helps reduce chatty control messaging that can consume data plans.
• Centralized policy control—VPN dynamic policies such as split-tunnel policy, encryption network policy, Virtual Route Forwarding (VRF) selection, and Domain Name System (DNS) server (for remote access) can be fully integrated with the authentication, authorization, and accounting (AAA)/RADIUS server and applied on a per-peer basis.
• Support for high-availability and scalability—In this solution architecture, we propose using IKEv2 Load Balancing, which relies on HSRP between the hubs to allow for scaling to greater than 10,000 sessions. All HSRP members are part of a cluster, with one of the hubs active while others are in standby mode. The active hub sends IKE redirect messages to hubs with lower utilization.
• Support for multi-cast traffic—GRE encapsulation allows multicast applications, including dynamic routing protocols, to traverse the tunnel without needing NHRP on the headend router (HER).
• IPv4 and IPv6 support—It is backward compatible as well as future proofed for IoT IP addressing requirements.
• Flexible AAA options—Authentication and Authorization may be performed by means of a local database or using RADIUS (more convenient for service provider environments, which typically require multi-tenancy).
• Dynamic tunnel configuration—This has been simplified so that theoretically only a single interface template would be required on the hub site to allow all types of incoming VPN connections.
• A private APN is not needed when using multiple carriers. It allows the same communications to the gateway no matter which carrier is used, which is desirable when coverage areas for certain locations are poor and you need to use multiple carriers to obtain reliable communications.

FlexVPN supports hardware encryption, which is offered by most Cisco products to optimize VPN performance. This provides exponentially better throughput than software encryption.

Private versus Public Access Point Names

Public Access Point Names (APNs) are the default internet connectivity for cellular gateways. Some customers purchase Private APNs from their cellular carriers. A Private APN can either be a dedicated APN for a customer or a “virtual one”, meaning that all traffic coming over the radio network is examined to identify the device cellular ID, enabling this traffic to be routed to the Private APN and subsequently into the enterprise network. In most cases, the data traverses the public internet to get to the network, which always introduces the possibility of security violations.

Because private APNs involve a manual intervention to configure the APN using the WebUI or CLI, Cisco recommends the use of FlexVPNs for Private APNs since this provides end-to-end encryption to ensure that no man-in-the-middle can view enterprise network traffic. If your RaMA applications or devices leverage application-level encryption or do not need access to the enterprise network for security or management, then Public or Private APN without FlexVPN may be an acceptable solution.

PCI Compliance

The Payment Card Industry Data Security Standard (PCI DSS) is an information security standard for organizations that handle branded credit cards from the major card companies.

The PCI Standard is mandated by the card brands and administered by the Payment Card Industry Security Standards Council. The standard was created to increase controls around card holder data to reduce credit card fraud.

The PCI DSS is organized into six logically related groups called “control objectives”.

Table 2: PCI DSS Control Objectives

Cisco Umbrella Integration

Cisco Umbrella is a cloud-native platform that delivers secure, reliable, and fast internet experience. Umbrella unifies firewall, secure web gateway, DNS-layer security, cloud access security broker (CASB), and threat intelligence solutions into a single platform to help businesses secure their network. As organizations directly connect IoT Gateways to the internet, Umbrella makes it easy to extend protection to roaming users and branch offices. It protects devices behind the gateway from malicious sites and provides content filtering to users behind the gateway. Umbrella leverages insights from Cisco Talos, one of the world's largest commercial threat intelligence teams, to uncover and block a broad spectrum of malicious domains, IPs, URLs, and files that are being used in attacks.

Cisco IR1100 and IR1800 gateways integrate the Umbrella agent directly in the software allowing for seamless Umbrella protection to all devices connected to it, wired or wireless. There are three modes to deploy Umbrella protection on the IR1100:

• **Without Direct Cloud Access (DCA)**—This is essentially sending all DNS traffic to Umbrella without applying any filtering or group policies.
• **With Direct Cloud Access (DCA)**—Umbrella agent in IR1101 will forward certain DNS traffic to enterprise, and all other DNS traffic to umbrella, thus keeping Enterprise traffic within the enterprise and sending all other to the internet.
• Enhanced DNS (EDNS) and DNSCrypt—EDNS feature is enabled to apply Umbrella policies by groups and subnets. It sends device identifier information with DNS requests enabling Umbrella to identify the user and enforce provisioned policies. Also, with encryption enabled through DNSCrypt, all DNS traffic is secure and private.

Figure 6: Umbrella Topology

Note: Refer to Sample Security Configurations for further configuration details.

Once a gateway is configured to use Umbrella for all DNS needs, all additional configurations and restrictions are on the Umbrella Cloud Applications UI. A user can perform any of Umbrella security functions as shown in Figure 7.

Figure 7: Umbrella Security Functions

Gateway Zone-Based Firewall

Zone-Based Policy Firewall (ZFW) is a new configuration model for the Cisco IOS Firewall feature set. This new configuration model offers intuitive policies for multiple-interface routers, increased granularity of firewall policy application, and a default deny-all policy that prohibits traffic between firewall security zones until an explicit policy is applied to allow desirable traffic. In Configuring ZFW, Interfaces are assigned to zones, and inspection policy is applied to traffic moving between the zones.

However, the feature is also backward compatible to nearly all classic Cisco IOS Firewall features implemented in prior releases.

The Cisco IR1100 gateway incorporates a ZFW which, for ease of use, is configurable using a template from the Cloud Management platform. The software also supports per-class session/connection and throughput limits, as well as application inspection and control for many popular applications. Those limits make the feature ideal to control LTE bandwidth usage and avoid congestion among downstream connected devices.

In a typical configuration as shown in Figure 8, there could be three zones for an IoT gateway and private, DMZ, and public internet zones. Each zone would have its own policy and then interfaces are assigned to a zone. Interfaces that share a zone would have unrestricted connectivity while traffic that crosses zones would be subject to the policies of each zone.

Figure 8: Basic Security Zone Topology

Note: Refer to Sample Security Configurations for further configuration details.

Cisco StealthWatch Integration

Cisco StealthWatch deployment requires three components:

• End devices capturing and forwarding NetFlows passing through the gateway
• A Flow Collector (FC) aggregating those flows from edge devices
• A StealthWatch Management Console (SMC) to configure and manage the flow collectors and display the data on user friendly dashboards.

Both Flow Collectors and the Management Console are on-prem applications and therefore installed in the customer data center Figure 9.

Figure 9: StealthWatch Components and Sample SMC Dashboard

The recommendations for FC and SMC deployment is to deploy in the data center one 4210 Series Flow Collector/Database (see https://www.cisco.com/c/dam/en/us/td/docs/security/stealthwatch/m5/hw/SW_FC_4210_Spec_Sheet_DV_1_1.pdf) capable of collecting up to 200,000 flows per second on UCS M5SX. Refer to the Hardware Installation Guide for deployment. Second, deploy in the data center one 2210 Stealth Watch Management Console (SMC) (see https://www.cisco.com/c/dam/en/us/td/docs/security/stealthwatch/m5/hw/SW_SMC_2210_Spec_Sheet_DV_1_1.pdf) on UCS M5SX.

Once the SMC is deployed, activate the following management applications:

• Host Classifier application:
  • This application provides Dynamic discovery and classification of core assets within your network.
• Visibility Assessment application:
  • Provides key metrics which help identify critical assets, validate policies, and audit and demonstrate compliance
  • Key metrics related to the network such as internal and external traffic, number of hosts, amount of encrypted traffic, etc.
  • Monitor traffic to high-risk countries

IoT Gateway and Device Security

The Cisco RaMA solution allows greater flexibility for end user devices connected to the Cisco Industrial Router (IR). Since the gateways support secure connectivity with technologies such as FlexVPN and WPA2 with IEEE 802.1x authentication, security policies can be enforced on the gateway instead of relying on the edge devices (such as laptops, phones, tablets, and video cameras), allowing users to connect and authenticate as if connected to an enterprise network.

End Devices Connectivity Best Practices

• While the solution is generally edge-device agnostic, Cisco suggests that wireless devices connect using IEEE 802.11n (or better) and wired devices connect over FastEthernet or Gigabit Ethernet.
• Using WPA2 with PSK or 802.1x authentication for wireless devices ensures that an end device is what it claims to be. This greatly enhances security by allowing 802.1x to accept or reject users who want full access to a network.
• Leveraging network-based VPNs increases the range of edge device options and simplifies security management. Software-based VPN clients on each edge device can be cumbersome to manage and require computing overhead to encrypt and decrypt data, resulting in a diminished user experience.

IEEE 802.1X Authentication for Wireless Clients

Any typical TCP/IP network that uses DHCP is defenseless against individuals who can find an unsecured network drop. The DHCP server could grant an IP address to unauthorized end devices, which would enable an attacker to launch a variety of attacks such as breaking into specific servers, eavesdropping on network packets, or unleashing a worm or a Denial of Service (DoS) attack. IEEE 802.1x provides a solution for such problems. By authenticating user access at the network edge, network administrators can ensure that unauthorized access is prevented, and all user authentication can take place on a centralized authentication server like a RADIUS server deployed at the enterprise headquarters.

Cisco ISE or alternatives like FreeRADIUS and Open RADIUS can be used to authenticate 802.1x clients for access to the network. For further information on Cisco ISE, refer to: https://www.cisco.com/c/en/us/products/security/identity-services-engine/index.html

Hardware Encryption

Cisco IRs offer hardware-accelerated encryption to support a full range of security services such as hardware cryptography to significantly increase IPSec VPN performance. This allows the use of Cisco’s Next Generation Encryption (NGE), which evolves traditional encryption technology to meet today’s increasing security needs while improving scalability and efficiency. Figure 10 lists the technologies that are included in NGE.

Figure 10: Hardware Encryption Features on Cisco Industrial Router Platforms

Note: MACsec is not supported on IR1800 routers.  For more information about Cisco Next Generation Encryption, refer to: https://www.cisco.com/c/en/us/about/security-center/next-generation-cryptography.html

ACT2—Hardware Root of Trust

The ACT2 chip is a security device containing product identity information and assertion functionality to support product identity for anti-counterfeit, secure storage, and other security functions. Key capabilities include:

• Anti-theft and anti-tamper chip designed only for Cisco products.
• Secure Unique Device Identifier (SUDI) and a certificate chain (x.509) that can be provisioned only at manufacturing. Linking the installed certificates and the ACT-2 chip provides the data needed for assertion and reconciliation by tracing the chip from creation to completion of the identity insertion process.
• Secure storage for certificates and objects used for encryption/decryption and other identities.
• Certifiable entropy for random number generation of one-time token/private key ensuring that no two gateways end up with the same set of private keys and SSH keys.

Image Signing and Secure Boot

Image signing ensures that, at every instance, the software stack, including the boot loader and OS stack, is authentic and has not been tampered with or manipulated. It provides software integrity against any back-door image modifications.

• The golden bootloader image is always in a permanent read-only boot flash that is encapsulated in epoxy and has the tamper evident label signed.
• Field-programmable gate array (FPGA) boot loader images are signed so that they can be validated by Cisco Secure Boot using burned-in certificates in ACT2.
• Protects system boot sequence against changing boot sequence, booting from alternate device, bypassing integrity check, and adding persistent code.
• Each step of software booting is authenticated by the previous stack to ensure end-to-end integrity.

Figure 11: Industrial IoT Anti-Counterfeit Protection Steps

Gateway Management Best Practices

• A major issue cited with IoT security is the use of hard-coded or default passwords, which can lead to security breaches. Even if passwords are changed, they are often not strong enough to prevent infiltration. Ensure that passwords within your IoT infrastructure are changed frequently and that the change is enforced on a recurring schedule. Enforce the use of strong passwords.
• Many IoT devices are “set and forgotten.” For example, they are deployed and left until their end-of-life with no security updates or patches. Ensure that all the necessary security patches and updates are applied to all elements within your network IoT fabric.
• Encrypt any sensitive data both in transit and at rest between IoT edge devices and backend systems using standard cryptographic algorithms. This helps maintain data integrity and prevent data sniffing by hackers.
• All encryption must be accompanied by an encryption key lifecycle manage process, since poor key management reduces overall security.
• Cisco recommends that all data be encrypted using FlexVPN and not split tunneled. This ensures that your data can leverage all corporate security policies and not be a “back door” into your remote or mobile asset. This is a best practice and is not required for all conditions.
• Cisco provides the ability to remotely update gateway and modem functions. Cisco highly recommends upgrading to the latest version to address any CVE or PSIRT advisories fixed in that release.

Sample Security Configurations

Note: While these configurations have not been fully validated end-to-end, the IR1101 Umbrella, Zone-Based Firewall, and StealthWatch with NetFlow configurations illustrate examples of what is possible on the IR1101 and IR1800 routers.

IR1101 Umbrella Configuration

The following is the most basic Umbrella configuration on IR1101 to connect the gateway to the Umbrella cloud instance, enable DNS encryption and apply the configuration to the WAN and LAN interfaces as needed.

! the cert below adds umbrella to the router and is provided by Umbrella. can be used as is in template.
crypto pki trustpool import terminal
-----BEGIN CERTIFICATE-----
MIIElDCCA3ygAwIBAgIQAf2j627KdciIQ4tyS8+8kTANBgkqhkiG9w0BAQsFADBh
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMSAwHgYDVQQDExdEaWdpQ2VydCBHbG9iYWwgUm9vdCBD
QTAeFw0xMzAzMDgxMjAwMDBaFw0yMzAzMDgxMjAwMDBaME0xCzAJBgNVBAYTAlVT
MRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxJzAlBgNVBAMTHkRpZ2lDZXJ0IFNIQTIg
U2VjdXJlIFNlcnZlciBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
ANyuWJBNwcQwFZA1W248ghX1LFy949v/cUP6ZCWA1O4Yok3wZtAKc24RmDYXZK83
nf36QYSvx6+M/hpzTc8zl5CilodTgyu5pnVILR1WN3vaMTIa16yrBvSqXUu3R0bd
KpPDkC55gIDvEwRqFDu1m5K+wgdlTvza/P96rtxcflUxDOg5B6TXvi/TC2rSsd9f
/ld0Uzs1gN2ujkSYs58O09rg1/RrKatEp0tYhG2SS4HD2nOLEpdIkARFdRrdNzGX
kujNVA075ME/OV4uuPNcfhCOhkEAjUVmR7ChZc6gqikJTvOX6+guqw9ypzAO+sf0
/RR3w6RbKFfCs/mC/bdFWJsCAwEAAaOCAVowggFWMBIGA1UdEwEB/wQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgGGMDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYY
aHR0cDovL29jc3AuZGlnaWNlcnQuY29tMHsGA1UdHwR0MHIwN6A1oDOGMWh0dHA6
Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEdsb2JhbFJvb3RDQS5jcmwwN6A1
oDOGMWh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEdsb2JhbFJvb3RD
QS5jcmwwPQYDVR0gBDYwNDAyBgRVHSAAMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v
d3d3LmRpZ2ljZXJ0LmNvbS9DUFMwHQYDVR0OBBYEFA+AYRyCMWHVLyjnjUY4tCzh
xtniMB8GA1UdIwQYMBaAFAPeUDVW0Uy7ZvCj4hsbw5eyPdFVMA0GCSqGSIb3DQEB
CwUAA4IBAQAjPt9L0jFCpbZ+QlwaRMxp0Wi0XUvgBCFsS+JtzLHgl4+mUwnNqipl
5TlPHoOlblyYoiQm5vuh7ZPHLgLGTUq/sELfeNqzqPlt/yGFUzZgTHbO7Djc1lGA
8MXW5dRNJ2Srm8c+cftIl7gzbckTB+6WohsYFfZcTEDts8Ls/3HB40f/1LkAtDdC
2iDJ6m6K7hQGrn2iWZiIqBtvLfTyyRRfJs8sjX7tN8Cp1Tm5gr8ZDOo0rwAhaPit
c+LJMto4JQtV05od8GiG7S5BNO98pVAdvzr508EIDObtHopYJeS4d60tbvVS3bR0
j6tJLp07kzQoH3jOlOrHvdPJbRzeXDLz
-----END CERTIFICATE-----
!
! Needed for IR to resolve api.opendns address. can be variable to be assigned by user or not.
ip name-server 1.1.1.1
!
! Create a pool for LAN with dns-server
ip dhcp pool lan
! network and router are variables to be chosen by user
network 192.168.10.0 255.255.255.0
default-router 192.168.10.1
! DNS server is variable and can be any global or enterprise server. MUST NOT be router itself.
dns-server 8.8.8.8
! domain name is variable and assigned by user as needed
domain-name cisco.com
!
parameter-map type regex dns_bypass
! following s regex for domains to bypass umbrella. should be variable.
pattern .*\.cisco\..*
!
parameter-map type umbrella global
! token for umbrella should be a variable. Token is generated from Umbrella site under Admin, API Keys,
! Create API for "Legacy Network Devices"
token <Umbrella Obtained Token>
local-domain dns_bypass
dnscrypt
udp-timeout 5
!
! wan interface needs to be the umbrella out cmd, can be wired or wireless.
interface GigabitEthernet0/0/0
umbrella out
!
! all internal interfaces need to have umbrella in cmd. tag can be variable or just chose fixed value interface Vlan 1
ip nbar protocol-discovery
umbrella in my_tag
! needed to disable the router as a dns server if already configured as it should not be.
no ip dns server

The following class-map and policy are used for Direct Cloud Access type deployments of Umbrella integration without or without Cloud Policy. In addition to those lines, the only other change is lan inbound interface where “Umbrella in” is applied.

class-map match-all umbrella-direct-access
match protocol dns in-app-hierarchy
match protocol attribute application-set saas-apps
!
policy-map type umbrella umbrella-direct-access
class umbrella-direct-access
direct-cloud-access
!
interface Vlan 1
ip nbar protocol-discovery
! DCA & NO Cloud Policy
umbrella in direct-cloud-access umbrella-direct-access
! DCA & Cloud Policy
umbrella in direct-cloud-access umbrella-direct-access lanTag

For additional documentation on Umbrella Configurations see:

• https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_umbrbran/configuration/xe-16-10/sec-data-umbrella-branch-xe-16-11-book/sec-data-umbrella-branch.html#id_58860
• https://www.cisco.com/c/en/us/support/docs/security/ios-firewall/98628-zone-design-guide.html

Zone-Based Firewall

The following is a typical Zone-Based Policy with three zones, INSIDE, OUTSIDE, and default. A policy map is allied to a service policy, and that is applied to the new zone-pair statement which determines direction the access restriction is applied.

ip access-list extended Web_acl
permit ip any any
class-map type inspect match-any Web_app
match protocol tcp
match protocol udp
match protocol ftp
match protocol icmp
class-map type inspect match-all Web
match class-map Web_app
match access-group name Web_acl
!
policy-map type inspect INSIDE-OUTSIDE-POLICY
class type inspect Web
inspect
class class-default
drop log
!
zone security INSIDE
description Zone for inside interfaces
zone security OUTSIDE
description Zone for outside interfaces
zone security default
!
zone-pair security INSIDE-OUTSIDE source INSIDE destination OUTSIDE
service-policy type inspect INSIDE-OUTSIDE-POLICY
!
interface X
zone-member security INSIDE
interface Y
zone-member security OUTSIDE

For additional documentation on zone-based firewalls see: https://www.cisco.com/c/en/us/support/docs/security/ios-firewall/98628-zone-design-guide.html

StealthWatch with NetFlow Configuration

For each NetFlow template, three components are needed. A flow record to define what is being recorded, a flow exporter to define where the data will be sent and using what transport method, and finally a flow monitor which joins a flow record and exporter together. Once those are created the flow monitor needs to be applied to an interface. Below is a sample configuration for the minimum required fields in a flow record for StealthWatch to be able to determine unique flows. If any additional fields are needed they can be added to the record with additional “collect” statements.

Default Template

flow record defaultStealthWatch
match ipv4 protocol
match ipv4 source address
match ipv4 destination address
match transport source-port
match transport destination-port
match interface input
match ipv4 tos
collect interface output
collect counter bytes long
collect counter packets
collect timestamp sys-uptime first
collect timestamp sys-uptime last
!
flow exporter export_Gi0_0_0_-63055531
destination 10.1.1.1
source GigabitEthernet0/0/0
transport udp 2055
template data timeout 60
!
flow monitor dsw_Gi0_0_0_-63055531
exporter export_Gi0_0_0_-63055531
cache timeout active 60
record defaultStealthWatch