I am giving a great big shout out to a new community podcast. The Network Collective is only five session in, AND it is a great podcast. I’m looking forward to catching many future episodes.
Episode 1 – Top 10 Ways To Break Your Network Continue reading
I have often wondered why the “security as an enabler” model is as unique as unicorns in the wild. I think the logic works in a vacuum and it would be great if it held true. However when humans and politics (layer 8 stuff) come into the mix, it seems that the cybersecurity team tend to be viewed as the naysayers that block progress. Quite honestly, the “security as an enabler” mantra only seems to work for those organizations that are directly profiting from the sale of cybersecurity. Those that understand the role cybersecurity plays in a typical organization realize that this is unfortunate.
With this thought in mind, I was reading through an article about the traits of CEO’s and found points that I think contribute to these challenges for information security:
- Bias toward action
- Forward Thinking
By no means am I criticizing CEO’s for these traits—they are primary contributors to keeping a given business relevant in its industry. I’m just using these to help explain the fallacy of the existence of a “security as an enabler” mindset within a typical organization. Continue reading
Cybersecurity professionals know that security cannot be a bolt on process or technology. Likewise, I also believe that that the thought of including the security team rarely goes far enough. To be effective, security should be ingrained and it should be pervasive. With a this commitment, there is at least one primary question that every organization should be asking in regards to Cybersecurity. That question is simply “Why?”
Not only should this question be asked organizationally, it should also be asked by individuals that are assuming security related roles within an organization. Some would think that the answer is simple or obvious. In many cases it is, but the complete answer WILL differ from organization to organization and differ based on the type of organization. What is important is that the organization itself agree upon the answer to this question.
Relevant answers to the Why question might be any or all of the following: Continue reading
Cybersecurity, as defined by Merriam-Webster, is “measures taken to protect a computer or computer system (as on the Internet) against unauthorized access or attack.”
The true importance of cybersecurity can only be understood if our dependence on “computer systems” is understood. It is difficult to imagine a day using nothing that is actively dependent on technology. We depend on connected systems to purchase groceries, perform medical procedures, manage the delivery of utilities and facilitate communications. These systems facilitate safe travel and alert us of impending dangers. It is conceivable that a cyberattack could take the power grid offline making it difficult or impossible to fill a car with fuel, purchase groceries, receive healthcare and even gain access to the typical procedures to restore the grid itself.
In our world today, unless we are primitive camping, we are using products of computer systems continually. To state it differently, our lives would change drastically if these systems became under widespread compromise. Considering Maslow’s hierarchy of needs, most individuals in a civilized society depend on computer systems for most of the elements defined in the critical first two layers. Since we have built this dependence, we must also protect these systems that we depend on.
As many PacketU readers know, I have held the role as a vendor SE for a couple of years. In this role, a primary function is to correctly position our products into customer environments. What I’ve come to realize is that many of our conversations actually start incorrectly. I think we need to change that. I will be sharing, as well as structuring, my own thoughts with an upcoming series of posts on security.
I firmly believe that products are only tools and we need to back up to better understand the problems we are trying to solve. One analogy I use on a regular basis when talking about autonomous vehicles is that “no one needs a car [they only need the transportation].” So if technology can provide autonomous cars, transportation can become a service instead of a depreciating asset in our garage. Continue reading
Sometimes the best way to learn to do something useful with a scripting language is with a starting point and a real world use case. While I don’t consider myself a Python expert, I can usually figure out how to put things together and get a task accomplished. For this article I challenged myself to create a simple script that performs the following:
- Open a file for a list of devices and credentials
- Log in to each device in the file using the credentials found
- Remove the current NTP server (184.108.40.206)
- Add a new NTP server (220.127.116.11)
- Save the configuration
Okay, so its not meant to be an API. I get that. I’ve been watching a rather good video about executing interactive commands with Parimiko and two thoughts came to my mind.
- Very powerful/flexible way to do tasks across many devices
- This could be a LOT easier if we simply had the RESTful API’s we want everywhere
In any case, I think the video below is a worthwhile watch if you’re struggle to leverage Python and SSH to make a modification across a large number of devices. Continue reading
This is the fifth and final article in a series that focused on Segmenting Layer 3 Networks with VRFs. In the third article, we discussed creating a shared services VRF and using it within the otherwise segmented network. In that article I alluded to the fact that we would later cover a way to securely allow traffic to flow between security zones. That is the intent of this article.
In this article, I am going to attach two sub interfaces between asav-1 and Main. One will attach into data and the other into pci. We will apply a simple policy that denies all traffic from data to pci, but allows telnet from pci to data (bad security example, but easy to demonstrate). Continue reading
As we’ve progressed through the Segmenting Layer 3 Networks with VRFs series, we have continued to build out a network that looks more like what we would see within an enterprise environment. This post takes it one step further and leverages the DMVPN (dynamic multipoint VPN) functionality to extend the network securely over the public Internet. In the examples here, we actually go one step beyond a typical DMVPN and map VRFs to tunnels using the tunnel key. This allows the pci and data VRFs to maintain isolation across the VPN.
One more thing that we will do that isn’t related to the core requirement of segmenting pci from data is leveraging a F-VRF (or front side vrf) on the DMVPN routers to isolate the Internet facing interfaces that connect them to the public cloud. This is my preferred method for DMVPN deployment if I’m not doing split tunnelling (i.e. I am back-hauling all traffic to a central location).
As a prerequisite, I will go ahead and build out the Internet router and the interface on Main that connects to DMVPN-hub. Continue reading
For those following the VRF Series, we currently have a topology built that consists of a segmented Layer 3 first hop network and remotely networked by carrying the isolation from the BrWan router to Main. This article covers, shared services, the next step in our journey to understanding VRFs for Segmented Layer 3 Networks.
The configuration focus is solely on the router Main. The shared services VRF that will be created could serve as a place to connect something that all other VRFs must have access to. Organizations should evaluate their requirements closely before deploying this configuration.
An organization that requires stateful inspection between two areas may choose to connect two or more VRFs together using an L4 or Next Generation Firewall (we will cover this in Article 5). The security ramification of having a shared services VRF, as described in this article, is that devices connected in this area could be used as a proxy into other areas. Therefore, careful planning and proper device level security is important prior to deploying this type of architecture.
The technologies covered here include:
- IGP w/ Route Redistribution (EIGRP)
- BGP w/ Route Redistribution
- VRFs with Route Targets/Route Distinguisher vlaues
In the last article, we took an initial look at L3 segmentation with VRFs. In that case, we created a basic first hop configuration that had isolated pci and data segments. In reality, most networks are far larger and more complex. This article continues down that same path by building proper layer 3 links and IGP adjacency with a Headquarter (Main) location. The starting point from a configuration standpoint is where we left off in Article 1 of this series.
Specifically in this article, we will configure subinterfaces to connect BrWan to Main for each VRF. We will also create a loopback on Main in each VRF to act as a test point that should be reachable from each host. From a routing protocol perspective, we will leverage EIGRP in Named Mode. This mode is a requirement because it is the method that allows the address family command to identify VRFs. Continue reading
Network engineers are well aware of the Layer 2 isolation properties of VLANs. Their use is so pervasive that they are second nature to most. This article is the first in a series that outlines specifically how VRFs can be used to provide the same type of end to end isolation for Layer 3 that VLANs provide for Layer 2.
In this example, we will work with a subset of the overall topology that I previously shared. Specifically, we are going to configure a router that I’ll call BrWan, a Layer 2 switch, and 3
routers that I’m using to emulate connected hosts (data-x/pci-x).
BrWan will contain the technology configuration that is the primary focus of the article. The other components are configured somewhat generically and using technologies that most are very familiar with.
At the end of this exercise, the requirement is that anything related to “data” can only reach other parts of the “data” network. Similar requirements exist for “pci”. There will be no ACLs used to prevent communication between pci and data, but the isolation requirement is strict. These concepts will be carried forward throughout the series. Later examples will provide a mechanism for some traffic between these zones and to access shared areas of the network. Continue reading