Get Started with the Whole of Branch Provisioning – Virtual and Physical

Earlier blogs have covered PnP use cases for simple deployments of a single switch.  This blog covers the design and automated deployment of a complete branch infrastructure. There will be no need to connect to the Command Line Interface (CLI) of any device.

Topology

In this example, Enterprise Network Compute Server (ENCS) is used to host the virtual network function(s).  This simple example has only a single function, an ISR router (ISRv).  This could easily be extended to include Cisco and third party virtual network functions.

The example shows automated provisioning of both virtual (ISRv) and physical (Catalyst 9300).  There are two connections between the ISRv and the 9300.  This could be simplified, but the two connection model provides all choices of connections between the ENCS running ISRv and the 9300 (L2, L3, PortChannel, ECMP etc).

Process

DNA Center provides the automation tools for this deployment. There are three main steps illustrated below:

1. Design phase. This is where IP address pools, site specific settings like credentials, DNS, AAA are defined.  In addition a network profile is defined, which include the “design” of the ENCS network functions and their internal network connectivity.  Finally, the network profile is mapped to one or more “sites.”  Site hierarchy is also defined in this phase.

2. Once the device is connected to the network, it uses PnP to discover the DNAC and will appear as an “unclaimed” device. The “claim” process simply assigns the device to a site.

3. Once the device is assigned to a site, it can be provisioned. This step places any device specifc settings (for example interfaces).  Most of this information has already been defined in the design, so cannot be changed.   The ISRv is also provisioned, but there is very little to change.  Once the WAN services are up, the Catalyst 9300 automatically uses PnP to obtain it’s configuration.

Example

This example assumes the design has been complete (just to show how simple it is).  I will come back to the design later on.

Claim Step

This example assumes a new ENCS device has been connected to the WAN, and it is able to discover DNA Center.  It will appear as an unclaimed device under the provisioning workflow.  Provision -> Unclaimed Devices

Next step is to select the nfvis device (nfvis is the default name for the device), and claim it.  All that is required is a site, in this example “Brisbane”.  Click Apply.

Click on the inventory tab, and you will soon see the device added to inventory, but in the “unprovisioned” state.

Provision Step

Now to provision the ENCS based on the network profile in the design phase.

Select the device, then go up to the “Actions” menu and select “provision”.  This will begin the provisioning workflow.

In the first step, there is little to do, unless you are provisioning multiple devices at once.  The main thing to remember is the “Next” button at the bottom of the screen to progress to the next step.

Step 2 (router WAN) is where the WAN interface for the ISRv is done.  Click on the small circle that links the ENCS to the WAN.  Then fill in details for the IP address, WAN interface on ENCS, and bandwidth.

Step 3 is the Integrated Switch configuration. ENCS has built in switch with up to eight ports.   In this example there are internal networks map to the two vlans.  In this example,  vlan 20 (service) is mapped to the service-net on ISRv and exposed on interface GigabitEthernet1/0 on the ENCS switch.  Similarly, vlan 10 mapps to mgmt-net and interface GigabitEthernet1/1 on the ENCS switch.

The final step is to review and deploy.

After a short period of time, the ENCS will be provisioned, which will create all of the internal networking and spin up the ISRv, and add it to the inventory.  You can check on the status of the provisioning by clicking on the hotlink on the far left of the ENCS entry.  Note also the ISRv is added, but not yet provisioned.

Provisioning ISRv

The same workflow is followed for configuring the ISRv. In this example a pre-defined configuration template will be applied.  The template was defined and applied during the design phase.  This is exactly the same workflow as with the ENCS.

Firstly, select the ISRv, goto actions and select provision.

Step 1 is just a preview.

Step 2 is the router WAN configuration.  Again there is nothing to configure here as WAN configuration was done in the ENCS workflow.

Step 3 is the Router LAN configuration.  In this deployment, the router has a layer three connection (routed, OSPF) to the downstream Cat 9300, so this is not really required.  In this case Gig3 appears in the dropdown menu as it has a “LAN” tag.  Just select DHCP and the single address pool.  These come from the ENCS configuration.

Due to the deployment model (the service network is going to be used to connect to the switch, rather than the LAN network), these settings do not really matter.  In other deployment models, they are.

Step 4 is the custom configuration template.  In this example, there are no device specific variables in the template.  If there were, they would be filled in here.

Final step is to review and deploy.

Once deployment starts, it can be monitored in the same way as ENCS.

The end result is the ISRv will be deployed, and due to the DHCP configuration on the device, the Catalyst  9300 will also use PnP to automatically provision based on a pre-defined rule.   There are now three devices in the inventory.  You will notice the ISRv is “Out of date” as I made some changes to the configuration template post-deployment.  The 9300 is not fully provisioned as it has a day 0 configuration.

I now have a fully deployed branch.

Details

This section shows the detailed configuration and how to define the network profile, along with ENCS/ISRv templates.  The templates augment the base configuration.

There are options where a single connection can be used to connect the 9300 and the ENCS.  In this scenario, there are limitations around topology (for example port channel will not auto-negotiate).  Using the management interface to PnP provision the switch, means any configuration can be applied to the front panel ports, without needing to establish connectivity first.

For example in the L3 connection, there is no default route provided to the 9300. It can only communicate to the outside world once OSPF is configured and comes up via the front panel ports.

In this case the service network and the management networks are being used and the LAN network is not required.  When other services such as firewall are used, the services network would link the router and the firewall and the LAN interface connect to the firewall.

The complete topology is configured via a network profile, and fully automated by DNA Center.

Design

IPAM

Three IP address pools are required for provisioning. They are:

◈ LAN for the LAN network.Typically this will be the connection to the end user devices.  As I am using a L3 link to the 9300 switch, the Lan networks will be terminated on the 9300, and this network is not being used.

◈ Service for the service network.In this example this will be a L3 connection to the 9300 switch.  In other topologies it will be used to link services such as Firewall into a chain.

◈ Management for the management network.Note, the management IP address is used to discover the ISRv router, so there needs to be reachability to it.

The current subnet masks are very generous, and would be optimized depending on the deployment scenario.

Templates

While most of the ENCS configuration is automated, extra configuration can be supplied in a template.  This allows capabilities that are not supported in the design workflow to be implemented. For example PortChannel on the switch ports. Currently, the switch vlan are used, but not defined via the design.  The ‘encs’ template contains these extra commands.

switch vlan 10

switch vlan 20

This template is used to configure the ISRv router. This is an extension to the base configuration, which includes everything to make the router discoverable by DNA Center. Although ospf is configured on the router, we need to change the networks that are advertised. DHCP scopes to allow PnP for the switch and the service interface for the 9300 switch are also defined.

router ospf 100

network 10.10.2.0 0.0.0.255 area 0

no network 192.168.200.0 0.0.0.255 area 0

network 192.168.200.0 0.0.1.255 area 200

   

ip dhcp excluded-address 192.168.200.129 192.168.200.180

!

ip dhcp pool PnP-mgmt

 network 192.168.200.128 255.255.255.128

 default-router 192.168.200.146

 option 43 ascii "5A1N;B2;K4;I10.10.10.181;J80"

   

ip dhcp excluded-address 192.168.200.1 192.168.200.60

!

ip dhcp pool PnP-service

 network 192.168.200.1 255.255.255.128

This is the configuration template for the 9300 switch. This template will be used in a PnP rule.

hostname $hostname

vtp mode off

enable password cisco

username cisco privilege 15 password 0 cisco123

interface Loopback0

ip address 1.1.1.1 255.255.255.255

ip routing  

router ospf 100

network 192.168.200.0 0.0.0.255 area 200

int vlan1

  no shut

  ip address dhcp

snmp-server community public RO

line vty 0 15

login local

Site Profile

To create a site profile, Design->Network Profiles -> Add Profile

Select the type as “Routing & NFV”.  The first step  will be to choose the type of device and the WAN connections.  Service Provider Profile is defined under Design -> Network Settings -> SP Profiles.

You will also need to configure the WAN connection from the device to the WAN cloud.

Finish by editing the  services.

Editing services is where you add the VNF (ISRv) and configure the internal networking.   Make sure you have uploaded an ISRv image into the image repository first, so you can chose the VNF profile for the ISRv.

Next step is to click on the service-net and the mgmt-net and add a vlan tag, as well as make it an access network.

In my case, service-net = vlan 20 and mgmt-net = vlan 10

Step two is to configure the connection between the ISR and the switch.  In this case it is L3.  The protocol is OSPF and the number is 100.

Third step is to configure the VLAN on the switch. In this case, both vlan 10 and 20 are used.

Finally, review the summary and save.

The only thing required to do is to add a site to the profile.

Validation

Once the desing and deployment is completed, the design can be verified by connecting to the 9300 router.  The OSPF peering has been established between the 9300 and the ISRv.

encs-9k#show ip ospf ne

Neighbor ID     Pri   State           Dead Time   Address         Interface

192.168.202.17    1   FULL/DR         00:00:36    192.168.200.16  Vlan1

The 9300 and ISR are connected over an L2 link with the peering point on an SVI – vlan 1. It is very simple to change g1/0/1 to a routed interface, or to run an etherchanel underneath, depending on requirements.

encs-9k#show ip int br | inc up

Vlan1                  192.168.200.3   YES DHCP   up                    up      

GigabitEthernet0/0     192.168.200.183 YES DHCP   up                    up      

GigabitEthernet1/0/1   unassigned      YES unset  up                    up      

Loopback0              1.1.1.1         YES TFTP   up                    up   

Continue reading

On-Box Python for Cisco Devices – the Why, What, and How

As a junior network engineer at a university I wrote a lot of management scripts in Perl.  I had scripts to do things such as check switchport configurations and upgrade switch code. Times have changed a lot since then. The university’s web server now runs in the cloud, rather than on my personal workstation, and Python has surpassed Perl as the scripting language du jour. Network automation with Python is now a major focus, making Python an extremely important tool.

Today I’m going to show you how to use Python scripts hosted on the box and integrated into IOS. This is far more powerful than my earlier-career scripts, and I have some simple examples for PCI compliance, Dynamic DNS ACL updates, and configuration validation.

As with many things in IT, we seem to be continually oscillating between “centralized” and “distributed.”  On-box hosting of Python scripts is an example of moving back toward distributed. My view on the argument is that it’s never about the extremes, but more about the balance—a bit like a pendulum constantly swinging as technology advances change what’s possible and practical.

Today, I want to demonstrate why Python scripts running on-box can be awesome.  I also want to explain how easy it is, based on the application hosting environment we’ve just released.  In addition, I’ll give some examples of how Python is even more powerful when combined with some of the existing IOS infrastructure such as Embedded Event Manager (EEM).

Why on-box Python?

There are three main advantages for Python scripts running on the device itself rather than externally.

◈ Scale: If I have a “sanity” script that I need to run regularly and it takes six seconds per device * 1000 devices, that would be 6,000 seconds, or one hour and 40 minutes.I could run them in parallel, but that still consumes resources on my management station, processing the data. It also potentially transports lots of data back to the management station, only to discard much of it.  An alternative is to distribute the work to the devices and get them to provide an update when they’re done.

◈ Security: Instead of having “utility” logins that connect into devices and export information for external processing, you can have the device process its data locally and just export the summary state. Data stays on the device, and less external connections are required.

◈ Autonomy: The biggest limitation of centralized processing is that it needs a network connection to the device. There is a set of use cases to modify device behaviour when it loses connectivity to other devices.  This can only be done on-box.

To illustrate the “what,” I’ve provided some sample scripts and use cases for the three points above. The code is published @  https://github.com/aradford123/on-box-python.git

To get started, we’re going to want to make sure Git is installed on your network device, run the following commands (after you’ve enabled guestshell; see section at the end for details).  The reason for using /flash/gs_script is that it’s a persistent directory and will be available on a switch stack switchover.

# install git

[guestshell@guestshell ~]$ sudo yum install git

# now install scripts into /flash/gs_script

[guestshell@guestshell ~]$ git clone https://github.com/aradford123/on-box-python.git /flash/gs_script

Example 1 – PCI compliance

Here’s an example of a use case that I think you’ll find interesting. One of our customers had a PCI requirement to ensure that any switch ports that were unused for more than seven days were disabled. (This was to prevent people from plugging in unauthorized devices.)

The script looks at all interfaces on the switch, and those that have been inactive (no traffic send/received) for more than seven days are shutdown. All interfaces that were shut down in a logged in a Cisco sparkroom. The interface description is updated with a message indicating the time/date it was shutdown by the PCI-check application.

To run the script, we’ll use the Embedded Event Manager.  EEM is a really powerful piece of IOS infrastructure that can be used to schedule the Python script to run.  The EEM cron job runs the Python script at 15 minutes past the hour, Monday to Friday.

event manager applet PCI-check

 event timer cron cron-entry "15 * * * 1-5"

 action 1.0 cli command "enable"

 action 1.1 cli command "guestshell run python bootflash:gs_script/src/pci-tool/pci_check.py --apply"

This script can now be run hourly (instead of weekly). It’s an example of scaling using on-box Python.

Example 2 – DNS ACL

Another customer had a requirement to keep an ACL updated with the latest DNS entries. For example, they wanted the ACL to reflect the real IP addresses of www.cisco.com and www.amazon.com.

This script automatically schedules its next execution based on the minimum Time To Live (TTL) of the DNS response. It ensures we don’t attempt to update more often than necessary.

The script logs entries that are added to the ACL via syslog, but that could be Cisco Spark or any other notification mechanism.

show logging

*Jul 12 11:44:11.174: %SYS-5-USERLOG_NOTICE: Message from tty4(user id: ): "Looking up cisco.com"

*Jul 12 11:44:11.253: %SYS-5-USERLOG_NOTICE: Message from tty4(user id: ): "Looking up amazon.com"

*Jul 12 11:44:11.341: %SYS-5-USERLOG_NOTICE: Message from tty4(user id: ): "adding IP: 72.163.4.161 to ACL: status: Success"

*Jul 12 11:44:11.351: %SYS-5-USERLOG_NOTICE: Message from tty4(user id: ): "adding IP: 54.239.25.208 to ACL: status: Success"

*Jul 12 11:44:11.360: %SYS-5-USERLOG_NOTICE: Message from tty4(user id: ): "adding IP: 54.239.17.6 to ACL: status: Success"

*Jul 12 11:44:11.370: %SYS-5-USERLOG_NOTICE: Message from tty4(user id: ): "adding IP: 54.239.26.128 to ACL: status: Success"

*Jul 12 11:44:11.379: %SYS-5-USERLOG_NOTICE: Message from tty4(user id: ): "adding IP: 54.239.17.7 to ACL: status: Success"

*Jul 12 11:44:11.389: %SYS-5-USERLOG_NOTICE: Message from tty4(user id: ): "adding IP: 54.239.25.200 to ACL: status: Success"

*Jul 12 11:44:11.398: %SYS-5-USERLOG_NOTICE: Message from tty4(user id: ): "adding IP: 54.239.25.192 to ACL: status: Success"

*Jul 12 11:44:17.605: %SYS-5-USERLOG_NOTICE: Message from tty5(user id: ): "reschedule in : 557 seconds: status: Success"

Here is the resulting ACL. Notice how the remarks are used to indicate the time the ACL changed. The last two entries were added at a later date.

9300#show run | sec canary

ip access-list extended canary_ip_in

remark Added 72.163.4.161 @Wed Jul 12 11:44:11 2017

permit ip any host 72.163.4.161

remark Added 54.239.25.208 @Wed Jul 12 11:44:11 2017

permit ip any host 54.239.25.208

remark Added 54.239.17.6 @Wed Jul 12 11:44:11 2017

permit ip any host 54.239.17.6

remark Added 54.239.26.128 @Wed Jul 12 11:44:11 2017

permit ip any host 54.239.26.128

remark Added 54.239.17.7 @Wed Jul 12 11:44:11 2017

permit ip any host 54.239.17.7

remark Added 54.239.25.200 @Thu Jul 13 16:34:37 2017

permit ip any host 54.239.25.200

remark Added 54.239.25.192 @Thu Jul 13 16:34:37 2017

permit ip any host 54.239.25.192

deny ip any any

This script uses a different type of EEM trigger, a countdown timer. The script self-updates the trigger based on the TTL of the DNS response. In the case below, it will fire in the next 557 seconds.

9300#show run | sec even

event manager applet DNS_update

 event timer countdown time 557

 action 1.0 cli command "enable"

 action 1.1 cli command "guestshell run python bootflash:gs_script/src/dns-update/DNS_update.py cisco.com amazon.com"

This is an example of security using on-box Python. No external access to the device is required.

Example 3 – Configuration change

This example uses an EEM event to look for a syslog message and execute a Python script. In this case, it looks for a configuration event, and fires the script.

This script will do two things:

◈ A sanity check. This example is a simple test to see if an IP address is reachable, but it could be more sophisticated. If the sanity check fails, then the configuration is rolled back.

◈ Log the changes to the configuration in a spark room.

This screenshow shows the configuration diff posted to a spark room.

Here’s an example of the sanity check:  I have a very simple sanitiy check that is looking for connectivity to 1.1.1.1.   While this example is trivial, the sanity check could be much more sophisticated (checking for OSPF neighours, number of connected hosts, etc.).

I shut down the loopback address 1.1.1.1, which is being checked by the sanity function.  The sanity function fails, triggering configuration rollback, and the current (working) configuration is restored.

9300(config)#int loopback 2

9300(config-if)#shut

9300(config-if)#exit

9300(config)#end

9300#

Jul 14 12:01:04.859: %SYS-5-CONFIG_I: Configured from console by vty0 (10.61.215.206)

Jul 14 12:01:15.648: %MLANG-3-LOG: config_check.py: Sanity 

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

Jul 14 12:01:15.690: Rollback:Acquired Configuration lock.

Jul 14 12:01:15.690: %SYS-5-CONFIG_R: Config Replace is Done 

Jul 14 12:01:16.579: %MLANG-3-LOG: config_check.py: 

Total number of passes: 1

Rollback Done

Jul 14 12:01:18.127: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback2, changed state to up

Jul 14 12:01:18.127: %LINK-3-UPDOWN: Interface Loopback2, changed state to up

There are lots of other options for this script, including checking into a git repository and more enhanced sanity checks.

This Python script uses EEM in a different way. The first line of the script embeds an EEM registration. If there is a syslog message with pattern “CONFIG_I” in it, the script will be executed. (NOTE: This is actually a Python script, and the normal Python code is after this.)

::cisco::eem::event_register_syslog pattern "CONFIG_I" maxrun 60

# this is an example of an EEM policy trigger

# based of Joe Clarke version

#https://github.com/CiscoDevNet/python_code_samples_network/blob/master/eem_configdiff_to_spark/sl_config_diff_to_spark.py

I then tell EEM to look for the registration in the config_check.py script.

event manager directory user policy flash:

event manager policy config_check.py

This is an example of autonomy; if the configuration is changed, a sanity check is run to make sure the device is still functioning (and connected) to the network. If the sanity check fails, the configuration is rolled back.

Upgrade sanity check

It’s pretty simple to extend the use case above to check the status of the device before downloading and installing new software. Once the new code is installed, it will re-run the sanity check and either remove the old version of code or roll back depending on the status of the sanity check.

This is another example of autonomy using on-box Python.

How does this really work?

Python runs in a guestshell on the device.  The guestshell is CentOS or Montevista shell running as an application on the device. In order to enable application hosting you need to use the application hosting framework IOX.  To enable IOX is quite easy:

9300# conf t

9300(config)#iox

You then need to enable guestshell. This will take a few seconds.

9300# guestshell enable

Management Interface will be selected if configured

Please wait for completion

On switches running 16.8.1 and later, you need to configure a management interface, as shown below. This was added to allow access to guest shell from ports other than the mangement interface (GigabitEthernet0/0).

9300# conf t

app-hosting appid guestshell

 app-vnic management guest-interface 0

end

9300# guestshell enable

Management Interface will be selected if configured

Please wait for completion

Once it has started, you can either run a command or get an interactive shell session.

9300#guestshell run echo "hello world"

hello world

9300#guestshell

[guestshell@guestshell ~]$ 

The very first thing you will do is update the DNS settings. You can use vi, or just a simple echo statement.

echo -e "nameserver 8.8.8.8\ndomain cisco.com" > /etc/resolv.conf

Now to install some Python modules. This is pretty simple. Just use pip install. I am using the “-E” option as my switch needs a proxy to get to the internet.

[guestshell@guestshell ~]$ sudo -E  pip install netaddr

Collecting netaddr

  Downloading netaddr-0.7.19-py2.py3-none-any.whl (1.6MB)

    100% |################################| 1.6MB 257kB/s 

Installing collected packages: netaddr

Successfully installed netaddr-0.7.19

DevOps

The next question you’re asking is how do I keep the scripts on the device updated? It would be a pain to have to copy/install new scripts all the time.

The solution is pretty simple. Store the scripts in a git repository (so you have full version control), then use an EEM script to “git pull” regularly to keep them updated.

Here’s a simple git update script:

[guestshell@guestshell ~]$ cat /flash/gs_script/utils/update_git.sh 

#!/bin/bash

(cd /flash/gs_script; git pull)

All that’s required is another EEM cron job to keep the device updated with the latest git repository.

event manager applet GIT-sync

 event timer cron cron-entry "0,30 * * * *"

 action 1.0 cli command "enable"

 action 1.1 cli command "guestshell run bootflash/gs_script/src/util/update_git/sh"

Continue reading

Five Proven Innovation Principles that Drive Business Success and Positive Social Impact

The innovation toolbox is broad and deep, with a growing array of methods, technologies, and tools for bringing a diverse group of innovators to the table. Though the fields of business and social change can seem very different, the things that make business innovation successful can also drive positive social impact. Think of design strategy, systems thinking, community engagement, and advanced technologies. By integrating these elements into regular operations, companies can reframe social responsibility as an integral part of their business model, rather than something that happens alongside.

As an innovation catalyst for Cisco and our customers, Cisco CHILL has identified several key principles that are essential for innovating across industries. We can use these same principles to take on some of the world’s thorniest social problems:

Collaboration

Multi-party innovation is key to solving big, global problems. As James Moore pointed out more than 25 years ago, business innovation requires ecosystems to attract capital, partners, and suppliers. Ecosystems built for social innovation create the same network effect. The more complex and global the challenges we tackle, the more we must grow a network across company, industry, and sector lines. The more intractable the problem, the more difficult it is it create a process to collaborate, but it is the only way to ensure a sustainable, inclusive future.

Technology

“We won’t experience 100 years of progress in the 21st century—it will be more like 20,000 years of progress (at today’s rate),” wrote Ray Kurzweil in 2001. Large, global data networks and the onslaught of new technologies are providing new tools to power social impact innovation. Imagine AI-enabled chatbots to coordinate aid distribution. Or an IoT-powered urban infrastructure that saves energy and lives. By applying new technologies to challenging problems, we can discover new ways to address complex challenges.

Stakeholder Engagement

In the Cisco CHILL innovation practice, we live by the principle of “massive inclusion”: everyone who might influence the success of a project is at the table. These are a project’s stakeholders. There are a lot of them and they don’t always agree! Leaders at the top of the organization must champion the company’s innovation agenda and involve stakeholders at every level from the very beginning of the design process (more on that below). This will help reduce friction internally and develop a culture of learning and trust. In the same way, a company’s agenda for community accountability and social responsibility must also be led from the highest levels so all employees and business functions can see how their work can affect real change.

Metrics

Founder of modern management Peter Drucker said, “What gets measured gets managed.” As with all business functions, determining the metrics for innovation success is important to achieving results. However, in both innovation and corporate social responsibility, the horizon can be long—it may be decades before we see impact. Innovators must carefully choose which indicators to track so we measure progress toward the end goal, not just activity for the sake of doing things.

Listening and Learning

Every step of the way, we must involve the people our initiatives will touch (often called “users” in the tech world). They too are stakeholders. It is crucial that the innovation process includes everyone and everything that a new technology or service will affect, positively or negatively.

At a CHILL Lab focused on healthcare, cancer patients and caregivers gave immediate feedback on prototypes and were the ultimate arbiters of success for all innovation concepts.

This expansive view must extend from people whose jobs or lives might be impacted, all the way to the global natural systems of air, water, climate, and environmental health. We can’t do this sitting behind a screen in an office: we must get out of the building to listen and learn, and leave ourselves open to wherever the conversation takes us. Co-innovation through prototypes is a great way to develop empathy and understand the needs of people affected by our solutions. At CHILL, we try out our ideas by building a quick prototype designed to test a specific assumption in a real and tangible way. Then we listen to feedback, adjust our approach, and try it again.

After spending the first ten years of my career in nonprofit organizations, I transitioned to enterprise innovation because I believe that to achieve a better world we need to embrace business transformation. The timing couldn’t be better. More and more, companies see the integrated connection between good business and being an accountable champion for a more just world. They see that having a profitable business doesn’t have to come at the cost of over-extracted resources, exploited populations, and pushing the long-term effects onto future generations. As Cisco CEO Chuck Robbins said recently during a Fortune Global Forum panel, “I think we’re going to move to a place where you’re not going to talk about CSR (corporate social responsibility) anymore; you’re just going to talk about what you do as a company.”

Today, more organizations like Cisco partner with innovative startups to take on broad social challenges. They champion the work of human service agencies in our communities and design products and regenerative processes to improve the quality of life for those with the least access. Together, we are taking steps toward a more sustainable, healthy, and equitable future for everyone.

Continue reading

Secure Access to Any Application With Duo Security

Over the past decade, several trends have broadly influenced the way businesses provide users access to applications and services. These trends include the wide adoption of:

◈ Mobile devices
◈ Cloud services (SaaS and IaaS)
◈ Accessing applications from anywhere

As businesses have transformed to a multi-cloud approach, users now have 24×7 access to business applications using any device, from any location. This approach has significantly increased productivity and business agility.

During this same time, business risk has increased as the volume of security incidents has skyrocketed. The result has been major impacts on brand reputation and increased costs in the management and remediation of security incidents. Meanwhile, attackers have developed more sophisticated methods of attack, although many older methods used today (like social engineering, phishing and stolen passwords) still prove effective.

Over the past five years, the Verizon Data Breach Investigations Report has shown credential theft as the most common factor of a breach. In the 2018 report, Verizon reported the number one action involved in a breach was the use of stolen credentials.

When we look back at the legacy solutions that were previously available to protect against credential theft, products such as RSA SecurID, Vasco and Safenet come to mind. These legacy solutions are known for introducing friction into the end user workflow. They’re seen as being overbearing for the end user, costly to manage, difficult to deploy and integrate with distributed multi-cloud environments. These are not attributes you want in a solution you’re trusting to secure access to critical applications and data.

When Duo Security started, our mission was – and still is – to democratize security by focusing on mitigating and reducing the risk of credential theft in a way that is easy and intuitive for the end user; easy for admins to deploy and manage – while easily protecting any application. We do this by verifying the trust of the user and the device at the time of access – the moment when a user attempts to access a business application. And we apply the same level of protection to all applications, whether they’re hosted in the cloud or on-premises.

It’s a three-prong, unified approach to secure access:

Verify User Trust

Duo verifies the trust of a user by sending a push notification to the user’s mobile device for one-tap approval and login, after the user completes primary authentication (username and password). For more sensitive applications, Duo can apply adaptive authentication controls and policies to establish a higher level of trust. This can include the user’s location, mobile biometrics such as TouchID and FaceID, as well as many other factors.

Verify Device Trust

Duo also verifies the trust of a user’s device by ensuring the device is up to date and adheres to an organization’s security policies before granting access. When a device is up to date, the risk of a device being compromised is significantly reduced. For higher risk applications, Duo allows for stronger controls, such as only allowing company-managed devices to gain access.

Secure Any Application

Duo extends the ability to verify the trust of the user and device to protect any application – in the cloud or on-premises – and supports the ability to apply these security controls to multi-cloud environments including SaaS, IaaS, VPN, Remote Access, Privileged Access, and other core business applications.

Duo’s ability to focus on the user experience while aligning with industry trends such as the broad adoption of mobile devices and cloud services puts Duo in a unique position to enable business agility by providing secure, frictionless access to any application, from anywhere, while significantly reducing the risk of a breach.

Continue reading

Layers of Security

Do you remember the movie “Die Hard”? Arguably the best Christmas movie ever. All kidding aside, this movie has a great correlation into Security best practices. Before we go into that, let’s recap. The bad guys in the movie were going to steal $640M in bearer bonds. In order to do so, they needed to break through several layers of security:

◈ Infiltrate Nakatomi Plaza and get rid of the guards
◈ Get the vault password from Mr. Takagi
◈ Have your computer guy hack through the vault locks
◈ Have the FBI cut power to the building, which in turn disables the last lock

So, how does this relate to Security? Layers. Lots and lots of layers. Utilizing a layered approach to security means that there are several hurdles that the bad guys need to overcome in order to get to your “bearer bonds” (your data, user information, etc.). The more challenging it is for someone to gain access to your resources, the less likely they are to spend their resources in getting them. While that is not always the case, if your security methodology is such that you can stop a large percentage of malicious activity early, you can focus on the more sophisticated attempts. Former Cisco CEO John Chambers said “There are two types of companies: those that have been hacked, and those who don’t know they have been hacked. “. If you take this to heart, it will help in laying out the strategy you need to best protect your people, applications, and data.

There is not one way to accomplish setting up these layers and they are certainly not linear as attacks can come from both inside and outside of your network. Let’s take a look at some of these layers that could be considered foundational to any security plan.

Starting at the Front Door

From a technology point of view, this makes me think of the firewall. Granted, in many ways this is obvious. Limit access to/from the Internet. This is a great place to start as this is like a lock on the front door of your home. With today’s Next-Gen Firewalls, one can look at applications, provide deeper packet inspection, and ultimately more granular control. As the infrastructures change, we are now deploying firewall technology within segments of the network and now even into the Cloud.

Who? What? Where? When?

Nakatomi Plaza had locks on their doors, guards, and security cameras. Managing Whether it’s physical or network security, managing access is critical. When we understand who is accessing the network (employee, contractor, guest, CEO), how they are accessing it (corporate laptop, phone, personal tablet), where they are accessing (HQ, Branch Office, VPN), and even the time of day, decisions can be made to allow or deny access. Taking it a step further, access control today with a solution like Identity Service Engine (ISE) can take all of this into consideration to allow/deny access to specific resources on the network. For example, if a user in the Engineering group is at HQ and trying to update a critical server using their corporate issued laptop, the engineer may be able to do so. That same engineer still at HQ but on a personal laptop or tablet may be denied access. Managing access to resources is one of the most important and challenging areas of security.

You’ve Got Mail

Email is still the number one threat vector when it comes to malware and breaches. The criminals are getting smarter and when they send out a phishing attack, SPAM, or malicious email, they look completely legitimate and it’s challenging to know what is real and what is not. Email security solutions can pour through all incoming and outgoing mail. These tools can verify the sender and receiver. They can look at the content and attachments. Based on policies and information from resources such as Talos, compromised emails may never even make it to the recipient. As long as email continues to be a primary source of communication, it will continue to be a primary way to be breached.

We’re Not in Kansas (or the office) Anymore

Almost 50% of the workforce is mobile today. People are working from homes, hotels, coffee shops, and planes now. There is also the need to access data from anywhere at any time. Keeping that data secure is not the job of the cloud provider but the owner of the data. Additionally, the users accessing the data from so many not-so-secure locations are of course always using their VPNs every time, right? Wrong! In a recent survey over 80% polled admitted to not using their VPN when connecting to public networks. So, now the bad guys are through another layer of security. We need to protect the cloud users, applications, and data. CASB (Cloud Access Security Broker) is a technology that does just that. Cloudlock can detect compromised accounts, monitor and flag anomalies, and provide visibility into those cloud applications, users, and data.

As work becomes a thing we do and less of a place we go, the risk of attack gets higher. I said earlier that the number one threat vector is email. Within those emails, many of the malware is launched from clicking on a link. That means DNS is yet another method that can be used by the bad guys. In fact, around 90% of malware is DNS based. Umbrella provides not only a better Internet access, but a secure Internet access. Regardless of where you go, Umbrella can protect you.

Having all of these layers to protect your “bearer bonds” doesn’t guarantee that nothing bad will happen. The bad guys have a lot of resources and time to get what they want. This methodology will hopefully help make it so difficult for them, that they don’t want to even try. People, applications, and data. It’s a lot to protect and a lost to lose. If you do it correctly though, you get to be the hero at the end.

Continue reading