Ash Patel: Just to reiterate, my name is Ash Patel. I'm a sales engineer here at WallArm, and I'm excited to tell you about Infrastructure Discovery today — our AWS-native asset inventory, change tracking, and security posture tool.
Before I jump in, just one thing to clarify: Infrastructure Discovery is a read-only tool. It does not require any write access, no agents — it will never modify anything on your backend.
The core issue we're meant to address is AWS sprawl. Large organizations can have hundreds to thousands of individual accounts, and no one really knows what's going on in any of them. People are given admin access, unlimited and without restrictions, to spin things up, read/write, store data, etc. Every one of those accounts presents its own security boundary — a boundary that admins and security practitioners have no real visibility into.
So this is the problem we're meant to address: the challenge of knowing what has changed in your AWS estate since last week or last month. Who created a resource, and when? Where is it — what region, what availability zone, what VPC, what can it connect to? And lastly, what do my auditors want to know about this? If I have an EC2 instance that can attach to an EBS volume with sensitive data on it, is that something they'd want to know about? Those are the types of things Infrastructure Discovery is meant to tell you.
Again, we don't change anything — we list, we describe, and we get. From that information we build a topological map and give you the ability to see a blast radius — this EC2 instance can connect to this S3 bucket, or this EBS volume, and has access to this part of the outside world.
Other capabilities include drift detection (old value, new value, what changed and by whom, via CloudTrail attribution), orphan resource tracking (people spin things up and forget about them — I'm probably as guilty as anybody, so now there's actually some accountability there), and Security Hub enrichment — taking findings in Security Hub and translating them into plain language with actionable insights: here's the security issue, here's the implication if it were exploited, and here are the prudent steps to address and mitigate it.
And the before-and-after picture: before Infrastructure Discovery, you were building things by hand. With it, a scan runs every 10 minutes, or on a configured schedule, so your inventory is always up to date. You get granular change tracking — old versus new, down to the resource level, with attribution for who made the change. Findings from Security Hub are placed into a graph, giving you a topological view of your entire estate. And there's inventory history — not just a moment-in-time snapshot, but a historical log with attribution, available on demand.
I know I breezed through those slides pretty quickly since I'd been through them before — let's jump into the demo. After you deploy Infrastructure Discovery, there are two ways to do it: you can put in a secret and a key, which is the easier path if you're just trialing it for a couple of weeks, or if you intend to run it in production, you'd probably deploy it as an IAM role. Once the account is configured, we instantly begin scanning and give you this topological map.
Here we can see all of my resources across the globe — from the US to APAC to EMEA. If we hover over these we get a high-level summary; if we drill down deeper, we get a more granular view of all the resources and assets that are running. You can segregate into various regions and availability zones, and the top critical assets are listed on the side. If we click on one, we get the high-level details, the appropriate CVEs, and the various connections being made to this resource. And lastly, the configuration — this is the resource as AWS sees it, and this is how we see it as well when we're monitoring it for any change or drift.
If we drill into the details — take the top one here, which looks like a vulnerable Python library — we give you complete context on what the vulnerability is and the remediation steps you should take. And lastly, a pictured blast radius: from this particular resource, where exactly could an attacker jump to, and what other information, resources, or sensitive data might they have access to?
That's things at a high level. If you want to drill down deeper into the actual asset inventory, the tabular view is a bit easier to sort through — say you wanted to see all your EC2 instances that have any particular vulnerabilities, you can drill into that view, click on one of the workers, and get a similar breakdown of that resource's associated security findings and blast radius.
We also help you prioritize your findings. Before I get to the findings, let's talk about where they come from: rules and policies. These are the built-in rules I referred to a moment ago — basic security hygiene, things you should be addressing, like not leaving SSH or RDP open to the world; you'd want to implement source IP rules to limit who can connect. We have a bunch out of the box, and you can also create your own using a standard CEL-based language, specifying the service, resource types, and applying your own severity level.
Once a rule is created, it's surfaced by a policy. A policy takes your rule — the custom ones we provide or the ones you create — and lets you tell us whether you want to surface a finding out of it. You can say, for this particular production VPC, I want every finding to be of critical severity, because those are of the utmost importance. That's how you control what we actually find, through rules and policies — and findings are organized based on that. A lot of what shows up here are CVEs related to EC2 instances running out-of-date libraries, so hopefully you're keeping things up to date.
To round things out — we looked at assets, rules, and policies, and the last piece is drift events: a complete view of the create, update, and delete activity in your AWS estate. Let's drill into one and see what was updated — here we can see a bootstrap script was modified at a certain time, but that alone doesn't tell us exactly what changed. Let's try one related to the subnet — here we can see this particular subnet was updated, and the available IP address count decreased by one (we probably changed that just to generate a drift event). But whether you changed an IP address or the number of VPCs in an account, any change you make is well documented and preserved in an immutable record, so your auditors always have a place to go back and see exactly who did what in your environment.
So, from a high level, that is the WallArm Infrastructure Discovery platform. At the top you get a summary view of your assets broken down by type, your number of findings by severity, and the number of drift events. Hopefully, after seeing this, you've realized you yourselves may have some gaps or deficiencies in inventorying your AWS estate — and you can go to the AWS Marketplace and deploy Infrastructure Discovery for free.
As Annette mentioned earlier, there are a couple of ways to deploy it: a free trial, which is the full-fledged product with no restrictions except time, and a free-tier version, which gives you unlimited time but is more limited in scope for what it can do.
So at this point, that concludes the demo. I'll now see if there are any questions posed in the Q&A.
Annette Reed: Alright, and if you haven't added questions to the Q&A, I believe we might allow you to come off mute, or you can raise your hand and we can bring you off mute if you want to ask a live question. And if you put something in the chat, we'll also review that and make sure we get to it as well.
Again, we'll make sure this recording is made available to you after the session today — you should see that within the next 24 hours, if not sooner. And for those who have registered — many of you have registered for the second demo, which will be on the 28th — that will also be a 30-minute session, going into more of the observation side of things with our AI Hypervisor. That's on the 28th; if you haven't registered, you can also register for that separately, though many of you registered for both at the same time. So we'll be seeing more of you on July 28th.
I'm not seeing any questions at this time, so we'll go ahead and wrap up our webinar. Any last comments, Ash, to leave the group?
Ash Patel: Again, just apologies for the brief technical issues at the beginning — I should have realized I wasn't presenting, so apologies for that, and it won't happen again on the AI Control Platform demo, which we hope everybody tunes in for as well.
Annette Reed: Alright. Thank you, everyone. Have a wonderful Tuesday.
Ash Patel: Bye, everyone. Thank you.
%201.svg){kind=small}
