Thread:

It was @JohnLaTwC who famously said:

“Attackers think in graphs. Defenders think in lists. As long as this is true, attackers win.”

If you’ve seen more than one of my talks, you might think I’m contractually obligated to include this quote in every talk I do.
This quote means a lot to me. A LOT. Graph theory, to me, almost seems like it was invented solely for the information security field. Its purpose and reach is obviously waaaaaaay further than our field, but…
… we have BARELY scratched the surface of what’s possible with applied graph theory in information security. The core feature of #BloodHound is finding the shortest path between two nodes. The algorithm this is based on was first published in 1959.
If you think about it this way, infosec is actually playing catch-up with graph theory, and mathematics as a whole. In playing catch-up, there are fundamental concepts like falsifiability that so far have not really existed in our field yet.
More immediately, there are practical concepts we can apply to infosec very soon that I believe will pay huge dividends.
The most obvious is the graph concept of “reachability” - how many nodes can reach this node, or vice versa, and in how many steps?
Don’t be turned off by this 3 dollar word, “reachability”. Think about it in a more practical sense - how many computers can be compromised if this one particular computer is comprised? That’s what reachability means.
Graph theory enables this kind of measurement. And just like shortest path, there is existing literature and math to help us figure out how to calculate these things in polynomial time.
So what does that mean, practically? Remember the OMIGOD vuln? This bug let you get a root shell on an Azure-hosted Linux box. This bug has an associated CVE. The “impact” of that CVE is limited to the host.
Now: think about reachability again. Think about it in the context of OMIGOD. Think about it in the context of every Azure subscription hosting a Linux VM. The context of every tenant trusted by each sub. The context of each tenant that trusts each of those tenants. Etc.
The real impact of OMIGOD reaches far beyond the individual host. The real impact of EVERY bug reaches far beyond the affected host. That impact is measured as reachability.
Imagine the difference between a vanilla vulnerability management system and a modern attack path management system. The vulnerability management system tells you impact to the host. The attack path management system tells you the impact to the entire environment.
Now: imagine knowing the potential impact of such a bug before it’s even discovered. Imagine eliminating that impact before those bugs are discovered. Imagine *not giving a fuck* about CVEs anymore. That’s what graph theory and mathematics will deliver over the next 10 years.

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Andy Robbins

Andy Robbins Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @_wald0

25 Nov
There are worlds of untapped security research opportunities in Azure - growing, dynamic, and multiplying worlds. The next few years will produce amazing research. Get a head start with the following resources:
The world-class writings of @inversecos: inversecos.com/?m=1
Read 7 tweets
12 Sep
At a high level, what security-related strategies and policies should Microsoft employ over the next ten years? Here are my ideas, but I want to know what you think as well: 🧵
Number one: take radical ownership over customer security outcomes. Microsoft is already doing this with the introduction of built-in safety rails in Azure. But there’s much more opportunity here:
Historically, Microsoft has made all the tools available to admins to secure their networks: Windows firewall, device guard, application guard, etc. A well-resourced, well-financed admin can make an AD domain *amazingly secure*. But most do not.
Read 16 tweets
7 Sep
Three of the most common issues #BloodHoundEnterprise finds, their impacts, and how you can use FOSS #BloodHound to find and fix these issues yourself, today: 🧵
Issue #1: Domain Controller object ownership. This issue is *extremely* common and *extremely* dangerous when looking at attack path possibilities this opens up. This is also *extremely* easy to fix.
In FOSS #BloodHound, run this query using the "raw query" bar at the bottom:

MATCH (g:Group)
WHERE g.objectid ENDS WITH '-516'
MATCH p = (n:Base)-[:Owns]->(c:Computer)-[:MemberOf*1..]->(g)
RETURN p
Read 17 tweets
11 Aug
(1/6) One of the most powerful and valuable aspects of a red team assessment is its ability to cut straight through any pre-existing notions of a network's security posture. 🧵
(2/6) The facts of a devastating attack path, well-executed, cut through egos, politics, ineffective operational momentum, and spell it out very plainly for everyone to see: the red team got in, took control of everything, and you couldn't stop them.
(3/6) Getting your teeth kicked in like that hurts, but professional red teams know how to turn that pain into value for the customer, and help them see it as an opportunity to improve.
Read 6 tweets
20 Jun
It's time to stop ignoring prevention. A thread:
Point #1: Red teamers know how year after year the same tools and methodologies can be used to take over almost any organization running Active Directory. Sometimes even the same exact attack path steps find their way into reports year after year.
We shouldn't be satisfied with doing the same attacks against our clients for years (even decades) and collecting paychecks - what exactly is the point of all this tailchasing if things aren't getting better?
Read 11 tweets
13 May
(1/n) The other day, @JulioUrena asked a great question in the BloodHound Slack:

"How can I determine which Group Policies apply to members of a certain group?"

We can use #BloodHound to answer this question, but I want to explain the moving pieces here as well
(2/n) Group Policy can't be applied directly to security groups, except when using SID filtering and linking the Group Policy correctly. SID filtering on GPOs is not very common, so #BloodHound doesn't currently model that.

We can still use #BloodHound to figure this out though
(3/n) Take for example this security group -- real data so labels are hidden (left CTRL in BloodHound GUI). This group has 7 users in it, but because it has a group added to it...
Read 8 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Thank you for your support!

Follow Us on Twitter!

:(