The use of geolocation is fairly obvious in monitoring networks with Firepower Management Center. What may be less obvious is that Continents and Countries can also be specified as the source or destination of connections in an Access Control Policy. Basically, this geographical information becomes one more match criteria that can be used to identify traffic for a block or allow action.
To get to this capability, open the Access Control Policy that is in use by the Firepower device. Within the policy, open or create an applicable rule. On the network tab (where you configure the source and destination addresses) a Geolocation tab can also be found. Clicking on this tab exposes Continents and Countries. These can be added as sources and/or destinations.
A few days ago I wrote an article demonstrating the Packet Tracer feature for troubleshooting Firepower Threat Defense. Another very cool tool for troubleshooting is the Capture w/Trace Feature. The power of this tool comes from both capturing a PCAP file (for Wireshark or your tool of choice) and a separate window pane that has a view of the device operation (very similar to the Packet Tracer output).
Similar to Packet Tracer, to initiate Capture w/Trace in the Firepower Management Console, choose ‘Devices‘ then ‘Device Management‘. Next, select the device that you want to perform the operation and select the icon that looks like a screwdriver and wrench.
Earlier this year, Cisco released Firepower 6.2.0. With that release came a feature called FlexConfig. Someone is digging around the UI might not initially understand the purpose or function of this configuration option. A really quick answer to this is that the user interface is incomplete when compared to the underlying feature capability found in Firepower Threat Defense.
A good way to better understand FlexConfig is to work through an example. Those with an ASA background will understand the modular policy framework (MFP). This feature exists in Firepower Threat Defense but its non-default configuration options are absent from the user interface. So if there is a need for a specific configuration, FlexConfig is the tool to complete this task. One use case might be the need to disable SIP inspection. In the ASA configuration, this would typically be as simple as the following.
no inspect sip
Since Firepower Management Console is GUI driven and is the UI for FTD, this is not an option. Ideally, there would be a complete menu system and API. Since this is not currently the case, FlexConfig is the tool that provides us an override of the defaults that aren’t exposed in the UI.
To disable SIP in FTD, we need to understand the way that this fits together. This is a series of parameters that feed the FlexConfig Object and is glued to the device by a Policy. At a high level, this is how things fit together:
Object FlexConfig/Text Object -> Object FlexConfig/FlexConfig Object
FlexConfig Object -> Flex Config Policy -> Device
Since that is enough to cause some level of confusion, let’s go through the exercise of disabling SIP in FTD (via the Firepower Management Console).
Before the modification, I am going to gather a baseline configuration directly from the device. This is possible by connecting directly to the device running FTD using this method to access the cli.
Note to reader: All Firepower content can be accessed by clicking here (or choosing Firepower from the menu at the top of the page).
According to the US Department of Homeland Security, “Our daily life, economic vitality, and national security depend on a stable, safe, and resilient cyberspace.” Digital infrastructure has infiltrated most aspects of our daily lives. When you start thinking about this in depth, it is easy to see how quickly things can turn s ugly.
Have you ever considered what would happen if our power grid was attacked? Beyond some of the domino effects the power grid itself has, think about the work to bring it back online. We are all accustomed to managing systems with other systems. A widespread power issue could create some very interesting chicken and egg problems.
Maybe some are smug enough to think they cannot be affected–with their resilient systems and diesel generators. Ever consider the likelihood of that fuel supply being available for the long term if there’s no utility power available at other places? The affected part of the world would be so challenged by such an event that everyone would be impacted, directly and indirectly. No power, no computers, no network and no ability to transact business in the ways that we are accustomed to. In other words, the possibility of impacting physiological layer of Maslow’s pyramid is real. Continue reading
In Information Technology, we commonly hear the mantra of “doing more with less.” That may sound great, and in some cases it can actually be beneficial. It obviously drives the requirement of streamlining performance and the simplification of processes. It can drive innovators to innovate and the attrition of unnecessary systems. The predominate reason for this philosophy is cost cutting.
My argument would generally be that IT should NOT simply be keeping the lights on, it should be adding value by creating competitive differentiators for the business. Being able to execute on that effectively SHOULD change the perspective of IT as it is viewed by the rest of the leadership team. One particular concern I have in regards to those businesses that continue aggressively down this path of cost cutting (or don’t proper initially fund) IT, is in regards to Cybersecurity.
In many cases smaller shops, or shops that don’t fully understand the risks, tend to place their technical team members into split roles. Maybe the view is that someone should be a part-time security person and a part-time network or system administrator. This introduces several concerns and I wanted to quickly share three that are top of mind.
Issue One — What do I do in my spare time?
While issue three (below) may be the primary concern for many, I actually think issue one is the most important. Even the very disciplined in joint roles are conflicted. In our world, there is no such thing as spare time. We prioritize what we do and what we are never going to have time to do.
Spare time may be better defined as when we don’t have a fire to put out. In that case, the person in the split role might look at the capacity planning for the network or perhaps the WAN link that is throwing a considerable amount of CRC errors. The security person might look at recently reported exploits and consider how they would’ve leveraged their tools to defend against them. Are there deficits that need to be filled? Continue reading
I love using VIRL to do quick self-check of a config, personal education, and learning the behavior of particular features. I also love using the iTerm2 Terminal Emulator on the Mac. Unfortunately, it isn’t obvious how to make the two play well together. I have had to re-educate myself on this over and over again as I get new computers, mess up my settings and do certain upgrades. I’m pretty sure I copied some of this configuration and the script that I will share from somewhere. So if this looks familiar, reach out to me and I will link back to the source.
This post meant to both share the config and caveats with others as well as to document the nuances for my future reference. In short, there is a standard configuration and a custom configuration for the terminal settings in VIRL’s VMMaestro. These are found in “VMMaestro -> Preferences.”
These settings control whether the built-in (VMMaestro’s client) is used or an external terminal client should be used. I much prefer an external client and iTerm2 is my current client of choice. To eliminate the need of manually launching and connecting, I have customized the Applescript code found below. This can be duplicated by opening the Applescript editor, copying the text and saving as virlterm.scpt. Continue reading
Those of us who work in technology see the need to take expensive, time consuming and/or mundane activities and convert them to streamlined automated processes. Ideally we improve these to the point that they improve accuracy, provide a better experience and can [mostly] be forgotten about. However, not every process fits all of the intended use cases. Maybe a more accurate statement might be that every process isn’t developed to fit every use case. For those of us who are outliers and find ourselves in those process deficiencies, these incomplete processes can create a lot of frustration.
A Little Background
I’ve been an Amazon Prime user for some period of time. I have also been free of a home mailbox for about 18 months and only used a PO Box to receive general mail. As a Prime customer, I regularly place orders with Amazon. Anyone else that has had the experience I’m about to share can probably finish my story. Continue reading
Posted in Uncategorized
I wanted to share a quick post on a feature that I have found incredibly useful on the ASA and has been extended to Firepower Threat Defense. The feature is called Packet Tracer and is an easy way to apply “packet walk” logic to a flow that would be initiated through the platform. Like most things FTD, the Firepower Management Console is the point of contact for initiating the process.
To initiate Packet Tracer in FTD, open the Firepower Management Console and choose ‘Devices‘ then ‘Device Management‘. Next, select the device that you want to perform the operation and select the icon that looks like a screwdriver and wrench.
There’s a lot of talk about network programmability and I recently had a simple use case that surfaced. The goal was locating a serial number in Cisco Devices. Basically, a script is required that will do the following.
- Process a list of IP Addresses and/or hostnames
- SSH into each device
- Determine if the device has a given SN
There are many ways this can be accomplished, but the method I am using utilizes SSH. This example requires the use of Paramiko to implement SSHv2. The script can match other items in the output of show version and can easily be modified to have multiple matches and return additional information. Continue reading
I think everyone that touches security has had multiple conversations about the hardened edge and soft center, commonly found in networks. This usually accompanies some discussion around the overlapping concepts of difference in depth, layered security and security ecosystems. It seems like many of the recent exploits have used a C2 connection for instructions. In those cases, assuming a perfect NGFW product and configuration actually existed that caught 100% of the malicious traffic, it would have the capability to impact those attacks.
However on June 27, Cisco Talos published an article about a ransomware variant known as Nyetya. As of today, Talos has been able to find no evidence of the more common initial infection vehicles. Both Cisco and Microsoft have cited the upgrade process for a tax accounting package as the initial point of infection.
Per Cisco Talos:
The identification of the initial vector is still under investigation. We have observed no use of email or Office documents as a delivery mechanism for this malware. We believe that infections are associated with software update systems for a Ukrainian tax accounting package called MeDoc. Talos is investigating this currently.
So what does this mean to the majority of the world that doesn’t use MeDoc? Can they be affected too? And if so, how could defenders prevent the rampant distribution into their environments?
Expanding on these questions: Continue reading
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