Backgroound Image

Month: June 2016

Cisco ISR Project – Internet failover config network config (12 of ?)

Posted on by Dan Kelcher

Each office will have their own internet connection, but in the event that connection fails the desire is to have branches backhaul internet access over the MPLS to the data center.  Since there is the possibility that the internet failure is located somewhere other than between the branch ISR and the ISP device there needs to be a method to verify connectivity.  Enter the IP SLA commands.

The following commands will set this up.  First, the actual IP SLA command.  The SLA is created, a request type, target, and source is specified, the VRF is specified, then threshold and frequency are set.  The threshold is how many milliseconds pass before marking the link is down.  The frequency is how often the requests are sent. 

ip sla 11

 icmp-echo 8.8.8.8 source-interface GigabitEthernet0/0/1

 vrf IWAN-SECONDARY

 threshold 2500

 frequency 15

ip sla 12

 icmp-echo 8.8.4.4 source-interface GigabitEthernet0/0/1

 vrf IWAN-SECONDARY

 threshold 2500

 frequency 15

ip sla 13

 icmp-echo 4.2.2.2 source-interface GigabitEthernet0/0/1

 vrf IWAN-SECONDARY

 threshold 2500

 frequency 15

ip sla 14

 icmp-echo 198.41.0.4 source-interface GigabitEthernet0/0/1

 vrf IWAN-SECONDARY

 threshold 2500

 frequency 15

ip sla 15

 icmp-echo 198.41.0.4 source-interface GigabitEthernet0/0/1

 vrf IWAN-SECONDARY

 threshold 2500

 frequency 15

As you can see, there are five listed.  Two are Google DNS servers, one is a Level3 DNS server, and the last two are root DNS servers.  I chose five because I thought it was enough to confirm an actual internet outage, but not so many as to bog the system down with requests.

The next step is to schedule the SLA commands to run.  The commands are pretty self-explanatory.  Run forever, start now.

ip sla schedule 11 life forever start-time now

ip sla schedule 12 life forever start-time now

ip sla schedule 13 life forever start-time now

ip sla schedule 14 life forever start-time now

ip sla schedule 15 life forever start-time now

Now the important part comes in.  Just because we are running these commands doesn’t mean much.  We want to track the reachability.  The following commands do just that.

track 11 ip sla 11 reachability

track 12 ip sla 12 reachability

track 13 ip sla 13 reachability

track 14 ip sla 14 reachability

track 15 ip sla 15 reachability

Next is creating a list of these SLAs.  Then setting a threshold.  In this command if half the sites are down the group is marked as down.  

track 10 list threshold percentage

 object 11

 object 12

 object 13

 object 14

 object 15

threshold percentage down 49 up 50

The last step is to actually put this into use.  The route from the default VRF needs to be removed and replaced with the same command, but with the track command added.

no ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0/1 ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0/1 Next_Hop_IP track 10

Now, if the tests to the external sites fail the default route is removed.  Then, a default route can be learned through EIGRP to route back through the data center to get out to the internet.

Here are a couple commands for troubleshooting:

show ip route track-table

show ip sla summary

The other side to this is configuring the data center router to advertise the default route.  First, create an ACL to define the default route.

ip access-list standard DEFAULT-ONLY

 permit 0.0.0.0

Then create a route map that includes the previously created ACL.

route-map STATIC-IN permit 10

 description Redistribute local default route

 match ip address DEFAULT-ONLY

Finally, add the route map to the EIGRP redistribution

router eigrp IWAN-EIGRP

 address-family ipv4 unicast autonomous-system 400

 topology base

 redistribute static route-map STATIC-IN

 exit-af-topology

exit-address-family

 If all went according to plan then a failure in the branch internet service should remove the default route, and then EIGRP should propagate the new default route.

Security control mapping – CIS CSC Top 20, NIST CSF, and NIST 800-53

Posted on by Dan Kelcher

I am working on a security project with a colleague, and instead of tackling one of the bigger standards we decided to create a road map and work towards it.  Essentially, the goal is to align with NIST 800-53.  That framework is way too complex for an environment with essentially a non-existent security policy.  Instead, we will tackle the CIS Critical Security Controls (SANS Top 20, CSC, or whatever else you want to call it) first, then the NIST CyberSecurity Framework (CSF), and then tackle the NIST 800-53.

The CSC is designed with the idea that it focuses on the most critical controls, so it is the best starting point.  By layering NIST CSF we add more controls, but they are less critical.  Finally, NIST 800-53 is where we would hit a level of maturity.  The nice thing with all of these is that the frameworks do build on each other.  Controls in CSC can be mapped to the CSF and 800-53, and the controls in CSF can be mapped to 800-53.  This means that work done on one control isn’t wasted.  The issue that we had was actually understanding what that meant for the overall project.  How much mapping was actually happening?

Before getting into the answer to that question we’ll look at the controls discussed.

The CSC framework has 20 controls, NIST CSF has 98 controls, and NIST 800-53 has 256 controls.

Here are links to info about each control:

CSC Poster This shows all the controls, a bit of detail on each, the background of the CSC, and has the mapping info for other controls.

To actually get the CSC controls you have to sign up here.  There’s some good info there, which includes a file with the mapping info in Excel format, the controls in Excel, a PDF with more detail on each control, and a PDF on testing and validating an environment based on the CSC framework.

The NIST CSF info can be found here, and here’s the Excel file with the controls.  The Excel file also contains the mapping info.

Then there’s the NIST 800-53, which can be found here.

Now, a quick note: This info is based off CSC v.6, NIST CSF (I believe it’s 1.0, but I can’t find version info) and NIST 800-53 Rev. 4.

With the mapping of controls I only wanted to find unique controls that were mapped.  There are often times where multiple controls map to a single control.  I counted the first, and excluded the subsequent.  This means that controls later in the list are likely to have fewer mappings listed as they are not mapping to unique controls.  Also, just because a control is mapped does not mean it is complete.  It’s more like it is started, and will likely need to be revised when looking at the higher frameworks.

On to the fun-

If you complete the CSC then it would map to 67 of the 98 CSF Controls (68.37%)

If you complete the CSC then it would map to 114 of the 256 800-53 Controls (44.53%)

If you complete the CSF then it would map to 155 of the 256 800-53 Controls (60.55%)

If you complete the CSC, then do the CSF it would map to 193 of the 256 800-53 Controls (75.39%)

As you can see, there’s definately a benefit to working through the controls in this order.

Now, like a good student, I am going to show my work.  The attached Excel file is a list of all the mapping info.  I compiled information from the above sources to make this.  The layout is the same as I had previously used.  The first four tabs list the details of the controls that are mapped, as well as the controls that are missed.  Then there are three “Summary” tabs with the specific control data removed.

Download the mapping file.