Firepower Firewall Updates: Snort 3.0 and Network Security

Today, April 17th, welcome everybody to the show, the latest episode of Security in 45. Today as you can see from the invite, we’ll be talking about the latest and greatest innovations in Cisco firewalls, specifically what we know as Firepower or Secure Firewall, but particularly the new stuff, which is going to be like version 7.x and above. If you missed the previous episode on Cisco firewalls, which Andres, I think that was our opening session, session one. That was our first one.

Okay. Definitely go back after the show and watch that. That was a real good introduction there about what Cisco firewalls are and how they evolved from Cisco ASAs today. Yeah.

And still very excited, it was my Mike, to be here. We have two legends that if you tuned in before 12th, probably you heard some of us chatting about multiple things, but yeah, we have Josh Parabog and Seth Richardson. Both of these guys have worked with the tag team. They have crazy backgrounds.

Probably you’ve talked to them and if you’ve been working on firewall for the longest time, I think I’ve talked to Mike, I’ve talked to so many other people that I work with now. So super exciting to be here and guys, if you don’t mind, Josh and Seth, if you don’t mind introducing yourself, that would be awesome. Hello world. As Andres said, my name is Joshua Scarborough.

I’ve been at Cisco coming up for about 10 years now. I’ve been in the security architect role that I have now for about four years. I support Department of Defense. I support the United States Army and I support special operations programs within them.

So I’ve been doing this role for about four years now. Prior to that, as Andres said, I was in TAC where I handled anything CAP case related. So if it was high severity, I would have my hands on it. And as you might have heard prior to this, I was in the United States Navy where I worked on F-18 Super Hornets.

I was primarily responsible for making sure ejection seats went off correctly when the lanyard was pulled. And I’ve never wanted any of my, let’s just say, constituents to be able to pull that lever, but I did the work regardless. Nice. Yeah, so Seth Richardson and I have been at Cisco for about 10 years, almost divided my time up in half between TAC and my current role as a customer success specialist.

And now my main goal and focus is adoption. So if you get a firewall, for example, I’m here to help you to get the most out of it. Prior to Cisco, wow, a lot of different things. So IT worked probably since 2005 when I got into that.

And prior to that, not many people know, but I was trying to make a career short track racing and eventually in bigger leagues than that, but had to grow up at some point. Do we know? Do we have to grow up? We don’t.

That’s the thing. Yeah. Seth, that’s pretty cool about the racing. I did not know that.

Yeah. And Josh, I knew US Navy, but that must have been pretty crazy testing the ejection system. Did you ever have to get in there and get ejected? No.

So you don’t want to do that, right? So if you, if anybody knows, if you sit in ejection seat and you are in a very critical precarious moment where you have to pull that lever, you actually go up about 2,500 feet in less than a quarter of a second. It compresses your spine a third of an inch. So there are some pilots you’ve actually had to eject and they come out a third of an inch shorter.

You don’t ever really want anyone to do that. Like that’s like, that’s the very last line of defense of someone’s life right there. Right. So I had one pilot.

Yes, you did eject and he was very, he was safe. I got out just fine. But it’s kind of like that real just heart thumping moment. You’re like, Oh my gosh, did I, what I do correctly, you know, save someone’s life.

But yeah, it’s wild. So it’s not something you test, right? You just do the work and you’re like, I did this work correctly. And I know I did it.

I paid for myself, right? That’s it. That’s awesome. Very cool.

Andres, after a good start, pretty interesting guests we’ve got here. I’m super excited to kick this off. And Josh, let’s get right into the nitty gritty. And again, not any type of introduction stuff, but some of the more advanced features of our firewalls.

Can you tell me about kind of what I consider the heart of next generation firewall, which would be the IPS. Oh, yeah. Some of us on the call have heard of snort. What is snort?

What version are we on today? Yeah. So fun introduction. If you go to Google and type in world’s best open source IPS snort comes up.

So that’s fun. snort we acquired back in 2013 when we acquired source fire snort is our intrusion prevention system and like all good movie trilogies, we’ve just recently upgraded to the third and the third is always the best film in the series. Right. Joking aside, no snort 3.0 has just happened in firepower 7.0, one of the latest upgrade paths for firepower.

So essentially what the intrusion prevention system does is if there is some kind of known exploit, maybe just say an Apache server that somebody knows how to take advantage of, maybe it’s a specific script, somebody has a targeted attack, the intrusion prevention system is there to stop those packets into the firewall. So it kind of adds a further layer between layer two and layer three and it’s doing deep packet inspection to be able to determine, you know, hey, this is a known exploit, someone’s attacking me. Some of the notable changes though from snort two to snort three and the biggest one is multi-threaded architecture. So firepower has already had the ability to run multiple snort processes.

What they’ve done is they’ve opened them up and made them multi-threaded. So each process can now investigate hundreds of packets at any given time and we have hundreds of different versions of snort running at any given time as well. So that increases the throughput by quite a bit. If you’re upgrading from, you know, 6.x to 7.x and you go to snort three, roughly is about a 20 to 25, even 40% throughput increase on specific devices.

Another one, if there’s any snorties out there, if anybody’s written any custom snort rules, we have made it much easier to write custom snort rules. It’s much easier human syntax, much easier to define regex out there and we’ve also added a lot of different libraries like multi-scan regex to help promote those rules and make more specific rules faster. That is snort in a quick instance and the increases from snort two to snort three. I think it’s interesting about this, the performance increase due to a software based upgrade.

Usually when I upgrade something, software is going to slow it down a little bit if anything due to the larger size, but that’s pretty cool. Oh, I did forget to mention one thing also. If anybody’s familiar with snort two and looking to go up to snort three, we’ve added ways to categorize and organize these snort rules so the user interface looks much cleaner. One of the more important ones I like to talk about is MITRE.

Now we have a specific framework of intrusion rules dedicated to the techniques and tactics and procedures that MITRE puts out. If there’s any incident response teams out there or any SOCs out there looking at snort three, you have the ability to map snort rules to what MITRE says that this technique is. You can cross examine and then follow that packet through your network as well. Interesting.

When I log into my FMC and I’m looking at an IPS policy and I’ll see a snort two bond and a snort three bond, if I’m a customer, what does that mean for me? Am I using snort three or do I need to? Yeah, so you’ll actually make that distinguish on the FMC. So it’ll say, hey, this specific sensor is using a snort three policy or a snort two policy.

Because we’re not telling you that you have to use snort three, you have the ability to have both a snort two and a snort three profile on the FMC. But the sensors themselves, the actual firewalls, they will only have one snort policy. So you distinguish which one goes to them. And the reason why you have two there, of course, is there’s going to be a lot of customers out there that have custom snort two rules and they need to convert to snort three.

So it’s just giving them the option to be able to say, hey, these are my snort two rules. Let’s see what they look like in snort three. Okay. So, excellent.

The other thing that I’d like to point out is that what you mentioned, Josh, it looks a lot cleaner than it used to before. Yeah. And more readable. There’s a very common theme across Firepower for every upgrade that we try to do and every patch that gets put out.

And that is having the most effective security policy you have while maintaining the simplest way to deploy it, understand it, and make sure somebody who logs into these devices can say, hey, these are my rules. These are my intrusion rules. And this is my routing pieces. So it’s trying to be as simple as possible while maintaining maximum efficacy.

There’s a lot of syllables at once. Sorry. That’s awesome. That’s good.

Seth, anything to add to that? Yeah. Just on the interface itself, you know, when you log into – I think it’s your IPS rule you’re looking at. I hear feedback.

Is that – anybody else hear that? I don’t. Sorry. Yeah.

When you open your IPS rule, as you mentioned, there’s two options, snort two, snort three. One thing you’ll notice quickly is that snort three loads significantly faster when you load the snort three version of your policy. But once you’re inside the policy as well, just visually, you’ll see some differences there. It’s pretty much the same as far as the way it works as snort two, kind of like getting a – you know, upgrading from the family van to a sports car.

Pretty much the features and functionality are about the same, but there’s some improvements. One thing you’ll notice is the groupings, right? So when you look at your rules now in snort three on the left-hand side, you’re going to see various groupings of rule sets. So for example, you might have browser rules.

And let’s say that you configured your IPS policy. Let’s say that your base policy was balance, security, and connectivity. But maybe for whatever reason, there’s a specific group of rules that you have, and you want to increase that. So I’m going to use browser as an example, and let’s pick on Chrome.

So you can take the Chrome rule, and you can edit that in the group, and you can change the level of the rule base for those rules specifically to be pulled from, say for example, security over connectivity instead of balance. So even though your base policy is balanced, you can adjust those rules in the groupings by category to be different. So that’s one significant difference there between two and three. That’s cool.

And for everybody listening in, what the recommended by Cisco is the balanced rule, correct? Correct. Balance, security, and connectivity. Okay.

So we want to know when you’re spinning that up. Especially when you’re making your first policy, you can make a balanced one, or you could just create an audit policy just to see what would have blocked. But if you’re using an IPS nine times out of 10, people want to see something be blocked. But always take…

Your mileage may vary with every single policy. These policies are updated very often by Talos. But they are designed for threats that are out in the network, out in the world right now. So all of those rules will be turned on or turned off depending on what’s happening in the world.

Firepower does a good job actually with Firepower recommendations to say, hey, you have these operating systems within your network, these users, these devices, and they will actually tell you which rules to turn on and which rules have no use for you. There’s no reason to have 400 Apache rules if you have no Apache servers within your network. So Firepower does a really great job through Firepower recommendations to help you tune those firewalls after you create the base policy. That’s good and good information.

And one thing, if I could just throw an additional item on there too, and I see this often, right, in helping customers to tune their firewalls is you can use the Firepower recommendation, but oftentimes there’s a lack of awareness of where we get that information from. So you have a network discovery policy that’s within your FMC, and there you want to make sure that you are discovering hosts, right? By default, you’re only discovering applications, and typically you’ll be discovering all networks. So you want to make sure you adjust that.

So you are discovering only the hosts or subnets that you’re trying to protect, but you want to make sure as the discovery part it includes hosts as well as applications. That way we’ve got data to pull from to be able to make those recommendations. More good information. And just the first question, Mike, that’s awesome.

All right. So I’m going to do pretty much like a segue, and then we come back to more of that piece that we’re talking about firewalls. But in the segue it’s going to be on the FMC, the cloud-delivered FMC. So I said this question is for you if you can just briefly touch on what is cloud FMC, and just whatever you have to share about cloud FMC.

Be nice. Yeah, sure. I’ll try to hit the highlights. So cloud FMC is just pretty much think of your traditional FMC, except it’s in the cloud.

So when you think about that, what are some key differences? Well one of those is you no longer have hardware to maintain. So there’s no rack space, no utility overhead, those type of things. When it comes to patching, uptime, all these things, these are things that, you know, especially in certain organizations if you’ve got a lot of irons in the fire, patching and updates can be something that gets overlooked and can actually be critical down the road.

So with the cloud-delivered FMC, then, or cloud FMC, then Cisco takes care of that. You don’t have to worry about that responsibility. That’s something that we take care of. When it comes to your day-to-day, the navigation, you’ll notice that the response time is really quick.

So when you’re navigating around the FMC and the dashboard, you’ll see that things happen pretty quickly in there. Some other items you can think about with logging, there’s a few options. So you could log to an offsite SIM, perhaps to an on-prem FMC, or you could also integrate with security analytics and logging as well. So those are some of the features there.

And if I missed anything, maybe Josh can jump in there and throw some more details in there. The number one reason why I see cloud FMC outside of uptime upgrades, patches, just kind of being automated and done for you in the background. The Firepower Management Center itself is a centralized management plan. What I mean by that is you can have an FMC on West Coast and manage firewalls on the East Coast.

But those firewalls would have to traverse and go across to the West Coast, and you’d have to have cross and boundaries, and you’d have to have specific configurations. You’ll have to make sure that that specific sensor on the East Coast can talk to the FMC. Primarily, what I see cloud FMC for is true centralized management. You can have just your singular FMC sitting in the cloud that we manage for you.

And any firewall that you deploy across the world or continental United States, wherever you may be, you can do something like low touch provisioning and say, hey, this is my serial number. And as long as that sensor has internet connectivity, it’ll automatically register over to that FMC. And you can get right to chugging along, making your policies, making those intrusion policies. But true, true centralized management.

You have one policy for your firewalls, and that goes across the world. Anybody listening in that’s like, I’m currently using the on-prem FMC. That sounds pretty great. We have a team that’ll do that migration.

I’d call that with you, with slash for you. And that’s a no cost migration service that Cisco offers. So very cool. All right.

Big one for me of the new stuff is, and this goes back to the tap days, encrypted analytics and all this pain about decrypting all this SSL traffic and cert exchanges. And now I broke something. I don’t know. Last I checked or heard, it was like 80% of the world’s or 80% of enterprise networking traffic is encrypted.

This is a problem, but it’s also a good thing because it adds privacy. How do, can you tell us about, I won’t give it away, but the new engine that Cisco Firepower has? Yeah, I mean, the power’s in the name, right? Encrypted analytics engine, our encrypted visibility engine rather.

But we do call it encrypted analytics. And a lot of stats numbers out there are, I don’t know where the source comes from, but what I’ll tell you is you can go to a hundred websites, Google anything you want. And if you don’t see the lock that comes up on your URI bar, guarantee you’re more than most likely going to consider not going to it. So yeah, a lot of traffic is encrypted.

TLS 1.3 being the newest version of that has added some problem scenarios. In the past, we typically would see that the TLS handshake, the SIN, SINAC, and then ACK come through, it wouldn’t be encrypted. So we could pull out SIRTS and things like that. So what does that mean for us, right?

We now have a harder time decrypting anything TLS 1.3 related. And I say we, but the world, the world has a harder time decrypting it. So we have come out with the encrypted visibility engine and this allows you to do what is called packet fingerprinting on applications and files within your network without decrypting anything. So you don’t have to spend overhead or time or compute thinking about, Hey, I need to have this specific SSL slash TLS rule and I only need it to be this website and I want it to be man in the middle.

I need to be aware of this. So you simply can just go to your access control policy, turn on encrypted visibility engine, and what we’ll do is we’ll start fingerprinting specific packets for the application. While the certificate is still encrypted in the TLS handshake, we can still get some information out of it. Packet size, the cipher suite, and then the preference that they have for those ciphers, how many packets they’ve exchanged within that session, and then also source and destination gives us a lot of clues onto what is within that packet and who is communicating to and what the application would be.

And that was a lot of words basically says, Hey, we can still help you block malicious applications, malicious files, and give you a confidence score base of that without ever decrypting anything. And that goes to TLS 1.3 as well. So like you said, a lot of traffic is encrypted. What we want is to be able to give you the ability to have a safe, secure firewall without having massive overhead of doing TLS decryption.

That’s super cool. And, you know, I set this up on my own FMC and yeah, you just click a button, you just do a slide bar to enable the the Eve engine. And now I can actually enforce my policies even when they’re encrypted, I still know which applications are flowing. And then mentioned the malware perspective, I can still block malware and I don’t need to do all that decryption.

Because we used to have to price firewalls based on where you’re going to be doing SSL decryption. I mean, I’ll tell you in the past, that’s that’s been a big pain point. A lot of customers, a lot of users will say, Hey, I have a one gig uplink. And you know, you can average how much encrypted traffic you may have.

But honestly, if somebody really wanted to decrypt, they would likely decrypt probably about 60 to 70% of traffic. Now there’s some rules out there. Don’t decrypt medical, don’t decrypt payroll, don’t decrypt criminal justice, things like that. And we have great guidance on how to create, you know, a proper decryption policy.

But there are just there are things that you don’t want to decrypt. But what we can do is is say, you know, hey, if you are if you are looking for a firewall that blocks malware and blocks malicious applications, you don’t have to have this massive, massive firewall to get one gig of decryption. We can be very surgical with how we create a decryption policy. So you say you I want to decrypt this one server or a group of users, things like that.

And then you’re not going to have this massive, you know, 60 50% hit on your firewalls just for decryption. And then you can rely and allow to supplement with encrypted visibility analytics and, you know, other features to help you pull out that traffic with never decrypting it. Yeah, just the amount of visibility we get with with this is really good, actually makes a huge difference. And of course, on the resources.

Actually, I should thank you, Andres. I should say everything that we do with encrypted visibility analytics, right, it’s not definitive. So you won’t see something else. This is a guaranteed this application.

What we do is we give you confidence score and we say, hey, we’re 90% confident that this is this application. And we base it off of the packet fingerprinting that I had mentioned before. But basically, you have the choice to say, I only want to block it if you’re 90% sure or you know, your confidence score is very high. And that’s because it is encrypted.

We’ll never be definitive of what that application 100% is. We just build these algorithms for you to say, hey, this application exhibits all of these examples that we have detected. And you know, we’re 99% sure. So yeah, it’s never going to be 100% all of the time.

It is packet fingerprinting. And we do make very educated guesses based off of that. If you’re on if you’re listening to this and you’re on 6.x, all you got to do is a software upgrade software upgrade to version seven, go to your go to your access policy, the little more tab and then the advanced settings and you’ll see encrypted visibility engine. And you also see that TLS identity discovery that Josh mentioned as well.

Cool. So Eve actually was introduced in 7.1 experimentally and then fully added as a feature in 7.2 and then 7.4 added the ability to do malware on like payloads. Awesome. That’s good information.

All right. So I’m going to go to the next question. I know we talked a lot about all these features with Eve, with Cloud FMC, with Snort, but we introduced recently SD-WAN capabilities. So Seth, if you don’t mind going over some of those capabilities, it would be nice for everybody to listen to.

Sure. So when you think about SD-WAN, perhaps, you know, what comes to mind would be visibility, control, redundancy, availability, and a central point of management. So if you take all those same features, that functionality, you just apply that to Cisco secure firewall, then you have those those features there on the firewall side. So speaking of that feature specifically that you would see with SD-WAN in the firewall would be policy based routing.

So you can also route policy based for applications, ECMP support for load balancing across multiple ISPs. You have application based load balancing as well using policy based routing and also multiple ISP configuration with optimal path selection, which is based on application based interface monitoring. So that’s just some of the features. One use case that you might think of where you could combine most of those would be the routing application traffic from the branch to the internet using direct internet access or DIA.

We use a lot of acronyms. So I’m trying to instead of using the acronym, let me tell you what it is. So if you think back, for example, like in 2020, a lot of people, a lot of the workforce was sent home to work remotely and you had a bit of a scramble that took place, right? We’re trying to figure out what are we going to do with all this data that’s coming back with this VPN tunnels back to our head end.

And one of the ways that we use to address that was with split tunneling. That might have been one of the recommendations that you remember from that time. So there might be some types of traffic that you don’t need to send back across the tunnel to the hub site, right? You can just send that out your local ISP connection.

So if you think about that, when it comes to direct internet access, it’s really kind of the same thing. But what we’re doing is we’re just applying this to your site to site, right? So it’s from your hub to your or your branch to your hub connection. So if you’re over here at the branch, there might be some traffic you don’t want to send back across the tunnel, right?

And cause latency or bandwidth issues. So let’s say, for example, you’re at the branch location and maybe you use YouTube as, you know, for whatever reason, maybe it’s educational or whatever, you trust that. And you also have Webex. Well, you can have each of those applications to not go across the tunnel, but to go out the local ISP connection.

And then you can also combine that as well with your policy based routing. So let’s say if you had multiple interfaces, egress interfaces on your firewall, you could have Webex go out one interface, you could have YouTube go out the other. And then you could additionally include the equal cost multipath. So let’s say that maybe you have an application that is really sensitive to latency, right?

It could be some voice, it might be video, it could be Webex, whatever that is. Then you could have monitoring, path monitoring also applied so that we would know which interface, which egress interface is under the most load, which one is under the least load, and we could direct that traffic automatically out that interface. So really, if you think about all the things you love about SD-WAN, just apply it to the firewall. Well said.

I think it comes down to use cases when I meet with customers. Cool, I heard you guys can do SD-WAN now on Firepower. I’m like, yes, but let’s talk about your use cases. What does SD-WAN mean to you?

But yeah, great examples of that equal cost multipath. I’ve got, hey, maybe two VPN tunnels that I want to dynamically and automatically, without human interaction, failover between them or utilize both paths at a layer seven. Great stuff there, Seth. Again, another reason to get on that version seven because this is something that just gets included.

Josh, version TLS of 1.3, you touched on that a little bit earlier and about how the part of that handshake is now encrypted, and it made it difficult for us to know what users are talking to in terms of application. I know you touched on it a little bit earlier, but if you could just clarify that a little bit more because it’s really interesting knowing because people listening in are going to have to be dealing with that and are going to get questions from their management about, I heard about TLS 1.3. How are we going to be able to enforce our policies since the handshake is now encrypted? Like I said, you go on the website, you go to Google, you search for any websites that you want, and I guarantee you’re looking for that lock.

You can see if you go to the lock, you can see what TLS version it is. Maybe not everybody’s using TLS 1.3 right now, but that is going to, if not already, is the standard of how these new websites are being programmed. It’s what people are wanting to use. The biggest difference that I mentioned from 1.2 to 1.3 is the handshake is fully encrypted, so you can’t just pull a certificate out anymore and then base the domain score, the domain that you’re looking for, reputation off of that anymore.

With TLS Server Identity Discovery and our ability to do TLS description, decryption, we do server identity. It’s the same concept as the encrypted visibility engine, whereas instead of looking at packet fingerprinting, we’re essentially doing source destination and packet fingerprinting on that original handshake. We’re helping you determine, hey, this is the source, the destination, this is where they’re going, and this is the server that they’re trying to reach out to, and we’ll profile the server. For all intents and purposes, hijack that connection, and we will see what kind of website or domain that they’re connecting to, what servers they’re connecting to, and we’ll take that responsibility on the firewall.

That’s where TLS Server Identity comes into play. It’s not full decryption. It’s more of an intercept, TLS intercept. I was just going to say, similar to Eve and the fact that we’re identifying, but we’re not actually decrypting any payloads.

Correct. It’s 100% what that is. It’s just two pieces to the same concept. Eve is the packet itself.

It’s the offending packet. It’s the, hey, this is the stream, and TLS Server Identity is, this is the TLS handshake. It’s encrypted. It’s specifically going to be for TLS 1.3 where it’s encrypted, but if it’s TLS 1.2 and that handshake is not encrypted, much easier to pull that certificate out.

But yeah, TLS Server Identity Discovery is basically TLS intercept where we have the ability to pull through, see that certificate, and then make distinguished access control hits based off that certificate or that URL. Did you ask about TLS decryption, like how we do it? No, no, that was exactly. I was just wanting to know about how do you identify applications in TLS 1.3 traffic, and you answered that.

Yeah. We’re going to encrypt just that portion of that handshake only. We don’t need to decrypt the whole payload. You know what?

I don’t even know if I want to say we decrypt it. It’s more of like an intercept. We provide the connection to the server from the firewall where then we start to communicate with them and we pull out as much information as we can glean, and then we’ll either scramble like a TCP packet and then just drop the whole thing, or we’ll say, hey, this is malicious, and then just won’t allow that connection to ever happen. Great.

Guys, in the chat, there’s some really good Q&A coming in from the audience. If we don’t get to it live on the call, we will absolutely send. If anybody asks a question, we’ll have the answer and we’ll reply all to everybody on here. Real quick, Josh, I wonder if you could touch on this live one from Isaac.

Isaac asked, is there an impact to the firewall on enabling Eve? Any before and after check to see the benefits of enabling Eve? Probably got about 15 seconds to answer that if you could. Okay.

So enabling Eve, there’s, I would say, minimal impact, right? You’ll always be aware. If you’re already over an 80% CPU threshold, maybe just be aware of the changes that you’re making. But Eve is actually pretty minimal because it’s simply just a predefined algorithm that we have cached that says, hey, this packet is exhibiting these links, these sequence, these cypers, and it prefers these cypers.

And we can just kind of assign that to a specific application that we have in our database. And yes, there is, on the FMC, there’s actually unified events. You can see something that’s marked as an Eve. Why are my words failing me?

It’s marked as like an Eve detection. And it’ll tell you, hey, we have given you this confidence score because it has exhibited these specific features. And it’ll give you everything that we’ve determined it to be. But yeah, there’s a totally before and after on your…

If you go to the FMC analysis and unified events, and if you turn Eve on, you’ll start to see some Eve hits on your connection events. That’s a great call out because you can edit those columns in that analysis, unified events. If you edit those columns and you search for just the word encrypted and you’ll see like encrypted engine visibility, confidence score, process name. That’s a great call out there.

Since you answered that one so quick, I’ll throw this out either to set through Josh, another live question. Going back to the IPS, why should we not… Seth, you talked about like the balance. We talked about the balance IPS setting being the recommended.

Great question, yours. Why would I not just turn on the maximum detection policy? Isn’t that the most secure of all the policies? Oh, okay.

Can I answer this one, please? Yeah, go for it. Okay. That’s a valid question though.

It is, yeah. The operating word is detection. There’s two forms of intrusion prevention or intrusion rules. There’s intrusion detection and intrusion prevention.

Detection being the operating word is it is a full audit policy. It’ll basically say, hey, this is an exploit. We see it. It happened.

But because you’re in detection mode, we let it through. If you are looking for auditing purposes and you’re looking for IDS, then yeah, you can do maximum detection. If your firewall is like in a span or if it’s like somewhere off on its own where it’s just doing secondhand pack analysis, detection is great. But if you’re putting a firewall in line and word has come down, it’s like, hey, we need an IPS desperately because we’re getting these attacks, start off with balanced security and connectivity and then monitor it from there and make quick subtle changes as you start to determine what’s within your firewall and as you start to determine the connections that you see.

But maximum detection is purely auditing. Very cool. Yeah. And it was really actually a good question.

It’s a logical question. It makes sense. But just as Josh explained, the reason for my response, like, oh, boy, is like he mentioned, if it’s in line, you’re really going to be just stopping traffic. It happens all the time.

Yeah. I wish I could have the words changed on that. But I’ve seen it fairly often. If your idea, though, is maximum security, there are four types of policies.

So there’s maximum detection, there’s balanced security over connection and then prioritized connectivity. And then I think there is one that’s like maximum or max security or prioritized security. I forgot the exact names. I probably should have researched that.

Sorry. But there is a one that’s kind of like the mirror of maximum detection where it will also have like 50,000 rules turned on immediately and all set to block. But there is a mirror for it. Excellent.

Thanks. I just wanted to get those live ones in the rest of those. We’ll send out the answers to those. Thank you, guys.

Yeah. Yeah. And I love that, you know, you were excited to answer those. I love the firewall.

Passion. Another thing, too, like just if I can just for a moment, you know, we’re talking about IPS. And I know earlier we talked about making adjustment to rules and so forth. However, if you’re say go to policies and then intrusion policy, you’re not going to see anything out of the box there.

The only options you have for IPS is if you go to your access control policy rule and you go to inspection, you have your system provided. So if you do want to make changes, you have to create a new policy. And then you can use as a base one of those other policies. So I probably should have mentioned that earlier.

That’s good. That’s good. All right, guys. So I’m going to go.

We have three more questions prepared and I know we’re running short on time, but I’m going to make this one real quick for you, Seth, about cloud deployment options. What can you share with us? Can we deploy firepower in Azure, AWS, GCP, film and growing overdose? Yeah.

So, you know, I think usually you’ve got either cloud native, non-native. So you think of maybe there’s various terms, right? There’s cloud native, there’s cloud, cloud ready, cloud deployed, various terms for this. But maybe if you think about your ASAV, your firepower threat defense virtual, you can run these in an Azure environment, AWS.

So yes, we do have appliances, virtual appliances that run in those environments. Typically, you know, when you think about those devices, you’re doing most of the configuration, right? You are configuring the devices themselves like normal. But even though you’re running on another, say, a cloud provider’s infrastructure, there’s still going to be some items that you’ll have to manually configure.

Even when it comes to scaling, you can scale up pretty rapidly, but it’s still going to require you to do some configuration typically within that environment. And then you have, for example, cloud native. So you have, it’s very similar to the cloud, cloud ready, for example, I’ll use that term. It’s very similar to that.

And especially when you think of Cisco secure firewall cloud native, you have all these functionalities, but you also have increased agility and availability and a really simple management with cloud SaaS manager or API. So you know, when you think about a day, things are changing rapidly. And that seems to be the only norm is that things change and it’s happening quickly. And so this can cause problems for organizations that are they’re scrambling to keep up with all of the changes.

So with Cisco secure firewall cloud native, that’s a long word, but trying to be precise with it. We can help you to roll with those changes in your organization to take advantage, for example, of Kubernetes orchestration. So as your user demand or your activity increases, then it will automatically scale up to meet that demand. In addition, we can provide always on security.

So we’re able to monitor container health and have the ability to automatically heal, replace or even create new containers as needed. And then, you know, we mentioned earlier the back in 2020, you know, a lot of people were having to be sent home and you had this this massive remote workforce. And you think about all the VPNs that were needed. So with the Cisco secure cloud native firewall, you can quickly spin up those remote access VPNs as needed.

So as things happen and change rapidly, we’re able to help you to adapt and change rapidly as well. So you can probably sum it up in three words, efficiency, automation and speed. That was awesome. That was awesome.

So for the sake of time, Josh, I want to ask you maybe in just like a minute, just briefly touch on hardware innovations. We’ve talked a lot about software, but hardware innovations at the end of it. Could you tell me about maybe like a secret knob to turn on for users listening in? So maybe just a minute.

So hardware innovations in like a secret setting that you would recommend people turn on? Yeah. So let me say, look, I know everybody’s probably heard, you know, Cisco is going software subscription where, you know, but hardware is still hardware is everywhere. If it’s cloud, if it’s your personal cloud, private cloud doesn’t matter.

Hardware is everywhere. So Cisco has always been heavily invested in hardware. And what I want everyone to do, if you’re interested in, go look at some data sheets. The first firewall we ever created on the Firepower side was the 2100.

It’s been out for almost 10 years now versus the two newest ones that we have. The Firepower 1100 series and the Firepower 3100 series. The 1100s are either a small form unit or a one rack unit device. Those devices actually out power the 2100s by a lot and vice versa.

The 3100s overpower the highest versions of the 2100s. We have made drastic improvement. I’m talking like 200% improvement on our new form factor firewalls. Virtually every firewall we sell is one rack unit.

So we don’t have any of these like huge line cards anymore. These ASR 7200s, it’s taller than me and I’m six foot two. We have made drastic, drastic improvements on the hardware and especially with the forms of ASICs. The fact that we have a very strong partnership with NVIDIA and one of the things I want to say is just look out for Cisco and NVIDIA announcements.

If you know what data processing units are, look out. Be ready for some news. And the secret thing I’ll tell you about, if anybody’s deployed Firepower or is looking into Firepower, spend some time on the objects page. Look at your variables.

Virtually every single thing within Firepower is a variable. Not many people are making static IP to IP with a specific URL. Everyone is using some form of variables within their rules. They want things to be dynamic and they don’t want to have to make hundreds of thousands of rules, each one static.

And I say that by default, your home net variable is set up to zeros. So you’re going to search every single network, whether it’s inbound or outbound, and it may not even apply to you. Make your home net variable unique to your network, your IP scheme, and it’s going to increase the throughput of your firewall tremendously. That’s sender, what F and C go to objects and then?

Objects and variables. Objects and variables. Great. Okay.

Thank you, Josh. Any, just real quick, any things people should turn on, your little secrets of FMC? I probably had a dozen floating in my head and now you’ve asked me and I can’t really think of anything. But maybe, you know, one I see often, and it’s really simple, is if you look at the access control list, so when you go to access control policy and you’re looking at your rule set, right in the middle you’ve got the search bar and then right beside that is this little tick box and it allows you to show rule conflicts.

So just by selecting that, I see so many firewalls where the rules maybe are out of order. You’ve got a rule you expect traffic to hit and it’s being preempted by a rule above in that list. So secret knob, it’s not really a secret, but it doesn’t jump out at you and it can be just a quick visual to help you reorganize your rule set or see where something’s out of order there. Awesome.

That’s great. That’s great. All right, Andres, you want to kick off the next part of this? And what we just got about two minutes left in the show.

So Andres, let’s kick off the part everyone’s been waiting for and then we’ll close this out. Let’s do it. Let’s do it. So this is our not joke session and we’re going to make it like, I don’t know, a game and we’re going to ask you one question each and then you give us your answer and whoever wins it’s not a hot potato, I guess.

But all right, I’m going to go with the first question. That one goes for you, Josh. And this one is, what’s a secret agents favorite thing to wear? Firepower?

Pretty good. Secret agents would wear. I assume the answer is no for that one. Secret agent would wear something like firepower.

That’s cool. Like a firepower cape. Yeah, whatever you know. That could be the answer.

Yeah. So the answer will be spyware. Oh, of course. Of course it’s spyware.

Seth, I didn’t know the answer either. Seth, what do you call a computer mouse that swears a lot? Those cuss words all the time. I have no idea.

He would be a cursor. My favorite part always. Guys, Josh, any super quick closing remarks? 30 seconds.

Thanks for having me. It’s a pleasure to be here. I love the firewall, guys. I’ll answer your question.

You send them to me. I’ll answer them to the best of my ability. And I wasn’t kidding. Cisco has announced a couple of partnerships with Nvidia and data processing units are on the rise.

So if TLS decryption is your thing, look out. Very great. Seth, closing remarks? Yeah, I appreciate you having me on here.

It’s been fun. Good to see everybody again. If you have a firewall and you want to get more out of it, definitely get with the account team. That’s pretty much what I do is try to help you get the most out of your firewalls and be happy to work with you.

Look forward to it. I think we failed to mention the firepower migration tool and team. If anybody has an ASA and they want to migrate from ASA to firepower, we have a tool that is designed to help you do that. And I think Seth, is it your team that actually helps people go through and take care of that tool?

Yeah, so we’re part of the process, right? We help you learn to use the tool. And there’s also I think there’s another team that’s involved, at least maybe I forget the timeframe, but they can actually help you with some of the migration. But for sure, I can help you get prepared for that as well.

Yeah, if you’re hearing this and you’re like, it is time to upgrade away from our ASAs or from the on-prem FMC and the cloud FMC, just reach out to your Cisco account team. We’ll put you on the, that’s a zero cost to you service. So definitely take advantage of that. Great stuff, guys.

Thank you. My takeaways for this, Andres, snort 3.0, IPS that’s always on actually makes my firewall faster and more secure. Cloud FMC Seth, I love not having to manage FMC myself in terms of manage the deployment of it. I like logging in to a cloud-based, Josh, you talked about firewalls geographically dispersed and this actually being really centralized because it’s in the cloud.

Decrypted analytics is a big one for me. I don’t like the idea of just not being able to enforce my policies or detect malware just because something is encrypted. And I like doing that at line rate speed without actually doing SSL decryption. Seth, you touched on the SD-WAN capabilities.

Very cool stuff here. I do a software upgrade to version seven. Awesome. All of a sudden I can utilize all these paths I have at layer seven.

I don’t need to manually do that. I don’t need to manually be ready to get a call to start failing things over to a backup path. Right. Thank you for that, Mike.

And my takeaways are going to be on the TLS server discovery. You just mentioned something about Eve along the same lines, just more visibility, more understanding of the traffic that is going through without sacrificing resources. That’s great. Cloud deployment options, I think Seth, you covered a lot of that.

And we have multiple products that we can use and we can offer services on that site. I don’t remember seeing something about Cloud FMC, how fast it is to get it started. Super fast. There’s actually a website.

We’re going to publish it on the community site. And it’s very easy. It gets provisioned super quick. The last thing that I want to mention is the advanced configuration, the nuggets that we heard today from Josh and Seth.

And this is something that you may want to look into the conflict resolution inside of the policies for FMC. The network discovery as well. I know you mentioned that, Seth, and make sure you turned on Eve into your policies. So that’s all I had.

That’s awesome. Guys, Josh and Seth, it’s been fun. And thanks for all the good you do in the world, keeping everyone secure. I mean that.

The firewalls are such a fundamental part of the changing landscape, but they’re still so fundamental. If you’d like to learn more about what we talked about today, you can reach out again to your Cisco account team. Myself, Andres, Josh offered himself up. Seth, that’s much appreciated.

Andres, next call, May 24th, what is it? Identity management, I believe. Identity management. It’s going to be exciting.

It’s going to be really interesting. Great conversation today, guys. Stay secure. We will see you next month, everybody.

Thank you. Stay safe.