Cisco Customer Success - Video

Multicloud Defense - AWS Visibility

Playback confirmation!

Do you want to resume playing from last left location?

Chapter 1 Thumbnail
00:05
Introduction and visibility overview in Multi-Cloud Defense
Chapter 2 Thumbnail
01:04
Enabling visibility: AWS region, VPC, and S3 setup
Chapter 3 Thumbnail
02:05
Verifying VPC flow logs and S3 bucket configuration
Chapter 4 Thumbnail
03:46
Route 53 DNS query logging and initial log ingestion
Chapter 5 Thumbnail
05:40
Investigate tab: VPC traffic analysis and log enrichment
Chapter 6 Thumbnail
09:44
DNS insights, Talos threat intel, and topology of malicious traffic
Chapter 7 Thumbnail
13:10
Recap and cleanup: removing AWS logging and closing

Transcript

Hey and welcome back. In today's video, we're gonna talk about how we can enable visibility within Cisco's multi cloud defense. Specifically within AWS, we can configure what's known as VPC flow logging and DNS quest.00:05Theory logging within our AWS accounts. This is a purely optional step. You don't have to do it, but it is a really nice way to centralize all of your flow logging into one platform. It's typically done through the setup menu. You can see step two here, again, it's completely optional. You don't have to do this to provide security within your CSP, but it is a nice add on.00:20So if I click enable visibility here, what's essentially gonna happen is it's going to start up a wizard where we can.00:40Again kick off orchestration on our SaaS controller that configures this within your cloud service provider. So we're gonna do this within AWS and I probably need to check what region, I can't quite remember what region we actually use. So let's.00:47Let's pivot over to AWS really quick. So this is my instance. All right, and let's double check my region, so east two. Okay, so we're gonna configure some VPC flow logging for the VPC that that test node is in. What's nice about this is I can scroll through.01:04Over here and look for East two or I could just type in East two and it'll automatically filter those out so go ahead and select that. And then the VPC is 2nd one, this testing inventory VPC. So what happens is we can see it's not enabled, if I select that and then point it at the S3 bucket that we created during the onboarding of our AWS account.01:24Okay.01:44This will essentially set up VPC flow log and DNS query logging and it'll dump those log records into that bucket. Right now we don't support Cloudtrail in terms of VPC flow logs or the DNS query logging, so S3 has to be our endpoint. And now we can see how quickly that was, right? So.01:45What I like to do at this point typically is pivot into AWS and showcase what actually happened from the AWS side, and we'll start by looking at the the actual VPC flow log parameters, so let me head into the vpcs, and if I select the VPC that I use.02:05Used during that that visibility wizard and take a look at the flow log section. We can see the record that it created. Again, it did a, a big old long kind of randomized name. We can see Valtics still the, the old startup name, and then a random string, destination type S3. So filter is both directions.02:24It looks like, yeah, the destination is that S3 bucket.02:44Which is nice. We can actually click on that and take a look at the bucket itself. And then so 1 min aggregation interval, it is active, and this is interesting, our custom log line format, so we do have a custom field is not the default fields for VPC flow logging, so that is definitely interesting if.02:48You're setting this up manually. And if we go over and take a look at the properties of our bucket here, you can get the ARN for the bucket that we're using, all the tags associated. You can see we do delete all objects after a day, so we we try to minimize the impact.03:08That we have in terms of your storage, and it doesn't look like, yeah, we're not doing any VPC, so NO NO flow logs have actually been sent to this bucket quite yet. Let me refresh that. Yeah, still, still nothing. The other object that we create is within the route 53 DNS query log.03:26Logging.03:46So let's let's head over there and it's hidden kind of by, by default, you have to click on the little three lines, expand this this sidebar menu. And then if you look at query logging, you can see the DNS query.03:46Logging that we have already set up within here. Again, pointed at the S3 bucket, so the same as the VPC flow logs. And if we dive into this, you'll see that currently it's just that one VPC. So this is where like if you're trying to clean up, you could actually just delete an individual VPC from this configuration if you, if you didn't want to do DNS que.04:07Query logging. And again, it's just part of the steps that the the controller automation takes when we're configuring visibility. Once we're actually pulling data in, everything's gonna be under this investigate tab under the traffic analysis section. So these these three kind of.04:26Sidebar menu items, the VPC fee net DNS and topology, which we'll, we'll go through as soon as some data starts trickling down into these. As we can see right now, nothing yet has hit. Let's check S3. Well, we are getting some, some VPC DNS query logs in here.04:42I would expect those to come in 1st. I don't see any flow logs quite yet. But once those come in, the controller again is gonna get notified through Cloudtrail that they're there and we'll go pull those logs out and process them. Okay, so I had to wait a little.05:00Little bit for the controller to process the flow logs that were already existing. And I do only have one test system out there actually like producing traffic, so we just delayed a little bit so that we could get some stuff in the logs that could be read into the controller. I will mention it is not, you know, perfectly real time, so there is a little bit of delay.05:19In between us pulling the flow logs out of the S3 bucket and actually being able to read them in the console. But now that we've had a little time elapse, let's actually go in.05:40And look through. So if I go to the investigate tab within multi cloud defense, you'll notice under traffic analysis, these sections, topology DNS and VPC are really where all of this visibility comes into play. Mind you, this is not traffic traversing our gateways. This is traffic that we are actually reading out of.05:49Of the cloud service providers. So VPC flow logs would be flowing into this VPC section. Notice the time bar at the top. This is, this is kind of nice because it allows you to look at, you know, specific subsets of time that maybe of interest to you. I personally like to just look sometimes at the last, you know, 15 min, but you can look at greater.06:09Subsets of traffic if you want to. You will notice that you can also limit it to specific accounts. You can look at malicious traffic versus all traffic, which is kind of nice.06:29And there is an advanced search option here where if you have like very specific queries you want to look into, you can look at things like, you know, specific parts of the TCP connection set, like whether it's TCP UDP, what port it's actually flowing on, protocol. So all of these are active parameters.06:39And we do allow you to kind of fill in the blanks as you go here. So it's, we, we, we, we try to make it as simple as possible. Now, all of these graphs are nice. I will admit to not using them all the time, but you do get some pretty interesting tra.06:57Kind of trends, traffic depictions within here so we can see like what's what traffic from a VPC vnet, you know, flow log capacity is coming in. If I had multiple vpcs and multiple instances, you'd really see where that kind of differentiates between the various vpcs and instances, how much traffic are being consumed, how many flo.07:12The logs were actually reading in.07:32Vpcs and V NETs by addresses, you look at top destinations, top ports being used. So again, we kind of break all of that down with some back end programming on the controller itself. So what I like about this is you can dive in, and again, think of this as a means by which we can centralize all of the flow.07:35Logs from various accounts, various CSPs all into one kind of consolidated system.07:54And if we look at the two tabs here, if I go to logs, you get really the details of each of these VPC flow logs that we're reading in here. What I like about this is not only can I click in and look through all of the different details.08:00Of a specific flow log, but because our controller's also reading in the metadata from the CSPs themselves, we actually do some flow log enrichment. And what do I mean by that? So a normal flow log is gonna be your typical, yeah, source destination, addresses, it's gonna be the port protocol being used, your typical like.08:16Five triple matching criteria, right? But we also come in and we do things like, you know, the, the, the bytes, but we will because we've learned that metadata, we'll actually start to put that metadata in. So VPC flow log instance data as well as all the tags. So this is nice because I could be looking at a flow log and not really know.08:36Know what that source or destination was, but because we're enriching it, I can see alright, this is the VPC flow log, instance.08:56Tags that are applied to that source or destination, and I'm looking at this and I can say, ok, the owner is, is J Lundon, the name is testing box. The environment's testing and the department is sales dupe. So again, now I have some metadata that's actually telling me a little bit more details than just the native flow log itself.09:04Good. So again, these are kind of nice just from being able to look at and maybe do a root cause analysis, look back through, and just try to decipher what's going on in your CSP environment. Very similarly, the DNS view is just looking at that D DNS query logging that we're doing in AWS. So I I showed you where that was.09:24Configured within AWS. This is gonna allow us to look at again just the same kind of logging, but just in a different light in terms of.09:44You know, where, where is our DNS traffic destined towards? What countries are we looking at? So, you know, United States in this case, news, computer and internet, search engines and portals and advertisements are kind of the top categories. You did get some pretty cool info, like especially in a.09:52More verbose environment. This again, I've just got a test machine out there doing some curls to some random websites, so we can see the fqdns that were actually resolved here. And then the final view, again, we can go into the more specific log parameters of all these as well, so we can look through, all the different DNS logging.10:11Who made the request, what was actually returned, what.10:30I also like to mention about this is because this is a SaaS controller, we're also bringing in malicious IP feeds from Talos. So what can we do with that information? The answer is simple, right? If we see you or an instance within your environment communicating to or being communicated to.10:33From a known malicious endpoint, we will actually flag that for you because we're kind of just in the background in the controller, we're kind of doing some of that black magic wizardry where we say, Oh, you know what, that IP or that destination IP or that source IP is actually a known malicious IP. We will flag that for you. So again, this is kind of the benefit of the visibility.10:54Is if I look at our topology view, it makes it very evident.11:14If you have, you know, a specific region that's, that's got malicious traffic, we will highlight that in red. So if I were to, let's look at views inbound and outbound, we kind of zoom out a little bit here. So it looks like East two is the only one that has some malicious traffic so we can kind of dive into that if I double click on that.11:18It will show me the vpcs within that region, so testing VPC looks like it's got a little bit of malicious traffic, so again we can double click into that. And this becomes very evident which nodes in that case. So in our public subnet, this testing box, again, the, the box that I set up for this purpose is communicating. So what I don't know is it, is it.11:38Inbound or outbound because.11:58Outbound's a problem, right? Outbound would mean the testing box was actually initiating connection to known malicious IPs. So if I deselect outbound, it looks like we definitely have some inbound traffic, so I'll re select outbound. Yeah, and it looks like so outbound we're fine. Outbound, we're only communicating to NO nodes in the United States, but inbound at.11:59And this is kind of a given, right? If if a box has a public, you know, in this case an elastic IP from Amazon.12:19Those are constantly being scanned from known malicious endpoints. So inbound, alright, yeah, that makes sense, but as long as we're not terminating those connections, I know in this case like my security group right now is locked down. But what's cool about this is if I actually had the infrastructure for multi cloud defense deployed, this would give me an easy way where I could.12:26Pivot directly in and start creating policy.12:46Maybe a malicious IP filter based off this specific node. So I might, you know, in reality I'd probably want to do this at a much higher level, maybe at a CSP level, but it does allow you to quickly, you know, pivot into creating policy based on that malicious traffic. So with that said, what we've done in this video.12:49Is we've actually went through and we've set up the visibility for AWS account that's been onboarded, specifically within the East two region within a VPC that we had set up for testing. Again, this is something you can do in one fowl swoop for every VPC or, you know, in, in the case of Azure like.13:10NSG, but we just really went in and selectively created that VPC flow log using our controller based automation. If I wanted to back any of this out after the fact, right now our controller does not allow you to delete that information. So if I wanted to actually clean this up.13:30From a provider's standpoint, I would simply go into my AWS console. I would empty this S3 bucket, right? So typically the the 1st part of of cleanup is actually emptying the S3 bucket itself, and.13:49That would clean up all the existing logs in there and and I might be a little bit backwards in this actually. We would go into the VPC, so I would go into my VPC here. I would look at the flow logs, I would delete.14:05The flow log, it's now deleted from there. I would go to route 503I would look at my query logging, and I would.14:24Delete that. So again, you could selectively delete it from just logging for those vpcs that we've identified, but I'm gonna go ahead and just for the sake of not having to pay Amazon any more money than I already do, I'm going to stop query logging and then I'm gonna delete.14:40The object itself. So this would essentially back out any of the changes that I made earlier. Of course, now if I wanted to go in and and empty that, that S3 bucket I could, but this would, you know, austically clean up everything that we just did within the configuring traffic visibility for AWS.14:57As always, if you found this video useful, keep a key eye on this channel as we will be releasing more and more content around the deployment and uses of multi cloud defense and how you can use it to protect your cloud infrastructure. Thank you for watching. We look forward to seeing you in the next video.15:20

About this Video

Author : Cisco Customer Success

Uploaded : May 28, 2026

SecurityMulticloud Defense
AI summary icon

AI summary

See how Cisco Multicloud Defense enables AWS visibility by orchestrating VPC Flow Logs and Route 53 DNS Query Logging to an S3 bucket via a wizard. Review optional setup, region and VPC selection, custom log format, storage controls, Investigate tab Traffic Analysis, enriched metadata, and Talos intelligence for malicious traffic detection.

  • Centralize AWS flow and DNS logs in one platform.
  • Accelerate investigations with enriched tags and advanced search.
  • Detect risky endpoints and pivot to policy creation.