brief Flashcards
Intro: Hello! thanks…
for allowing me to help kick off what should be a fascinating day of deeply technical talks. Im humbled to be included with the other bright minds that will be sharing this venue, and I want to apologize in advance for mucking up what should be a fascinating groups of technologists with my government flavors.
Intro: by way of introductions…
I’m Josh Finney, and i’m from CISA. This is pronounced, for the record, as “CISA” not “Seesaw” or “SY-SA”, or any of the other hilarious versions we hear every year. We’re an agency that still has a “new car smell” as congress surged us into being under the department of homeland security umbrella in 2020.
Intro: I presently lead
CISA’s incident response teams and our proactive threat hunting cohort. This means that whenever things go bump in the cyber night, my team of exceptionally bright analysts are tasked with figuring out who it was that bumped, what systems got bumped, and in some cases……how do we evict the bumpers.
Intro: if that explanation…
makes any sense to you, then you’re doing better than friends and family of mine who I attempt to describe the very important work of CISA’s Threat Hunting team to.
Intro: Folks may be familiar
with the tendrils of CISA’s Threat Hunting team at work, whether it’s in our public advisory work that we help author for identifying specific activity or for securing cloud environments. Our collaboration with industry around our SCUBA project represents the new frontier for collaboration with the government, and I couldn’t be happier.
Intro: Folks may ALSO be familiar
with the some of our open sourced tooling, such as Untitled Goose Tool, which is an incident responders companon for hunting in Microsoft M365 SaaS environments.
Intro: we continue to partner
with our friends at the NSA, FBI, Cybercom, and across the USG to disrupt threats as early and as often as we can. That means active hunts across the federal civilian executive branch of government, in 16 critical infrastructure sectors, and in partnership with State and Local governments.
Intro: I know its popular
to say that “i’m from the government, and i’m here to help” but I swear we mean it, every time. There’s nothing that makes us happier than finding that final puzzle in an investigation and helping our stakeholders when they’re having the worst day of their life, in the midst of a cyber event.
Core Challenge: Over the last few
years, we continue to encounter identity related compromises in our partners.
Core Challenge: it’s worth providing some context
CISA is engaged with partners of a LOT of different sizes and maturity levels. We’ve worked with everyone from the threat hunters at Department of state, who are some of the best we know, all the way out to remote water and electrical municipal suppliers who’s network defenders sometimes double as the guy who does the daily lunch runs.
Core Challenge: We have a much broader
sphere of obligation than a lot of our friends in the incident response and threat hunting industries, and we also face an extremely challenging landscape of threasts.
Core Challenge: identity is a very different
conversation relative to the system owners complexity. It’s especially interesting when we add fun variables like physical control systems or embedded processors in places like Manufacturing or transportation.
Transitive Identity: i’m going to read the language we used in our guidance
to stakeholders experiencing a major identity compromise from the Solarwinds/M365 event. ““This [is an activity] that can be conducted, for example, using a transitive mapping of all potentially compromised credentials to the systems that those credentials accessed.”
Transitive Identity: To say that this language
didn’t resonate with our partners could be considered a massive understatement. I think the response, collectively, was a lottttt of raised eyebrows and requests for explanations.
Transitive identity: I think what we meant to say
in laymans terms, was “once an attacker has definitively gotten access to privileged credentials, what DID they, or COULD they, have done with them? What came next?” This is relatively simple stuff, but sometimes the simplest ideas are the most difficult to articulate.
Transitive identity: i think in the future
it shouldn’t take a PHD to dissect an attackers opportunity space, for what they can reach and what the context of their access is.
threat trends: We’ve heard from partners
that they’d like to transition from the term “assume breach” because it’s overly pessimistic. If anyone here can help me come up with a more positive spin on that term…..please let me know what it is. In the meantime, We’re going to continue to workshop ideas while only whispering “assume breach”
threat trends: CISA continues to work
with partners at OMB and in industry on Zero Trust methodologies and breach prevention techniques, but its worth noting that sophisticated threats (like the one on the screen) continue to prey on similar identity based attacks with small iterations, year over year…..because they’re effective.
Threat trends : these threats here share one thing
in common; they’re preying on normal traffic and identity structures to make evasion easier and detection much more challenging. The recently released blog post from Microsoft detailing the Storm 558 threat also illustrate how much of that responsibility is shared amongst customers and cloud service providers in the detection space.
Threat Trends: I know the feedback we’ve gotten
from our friends in industry about CISA continuing to talk about Solarwinds elicits some eyerolls. “This again?” I can relate to that, but also think that when the collective has mitigated the threat activity and neutralized those TTPs, we’ll stop talking about it.
Threat trends: threat actors are still
using the same TTPs, and if that isn’t clear, i’d encourage everyone to read MSFT’s blog on FoggyWeb and Magicweb. These blog posts perfectly illustrate some examples of threat actors pivoting their techniques just a little bit to evade atomic detections, while maintaining a consistent approach to attacking the identity plane.
Threat trends: fortunately, most of the briefs I see
at major conferences assure me that the AI/ML revolution will solve this problem for us, so i’m looking forward to packing up my antacids, as they’ll no longer be needed. Eventually. But this isn’t an AI/ML discussion!
Red teaming: you know who doesn’t struggle with this mindset?
Offensive security professionals. Red teamers, penetration testers, exploit developers.
Red teaming: Also, if you didn’t believwe
that we’d see the famous Jack Lambert quote represented here in a talk about graphing…..surprise! we’ve made it. For those unfamiliar with this quote, Jack says ““Defenders think in lists. Attackers think in graphs.. As long as this is true, attackers win.”
Red teaming: what does this mean?
He goes on to say “Your network is a directed graph of credentials. Hacking is graph traversal. See the graph or all you’ll see is exfil.”
Red teaming: attackers in industry continue to
to use tools like Bloodhound and Redeye, CISA’s C2 graphing app that you can find on our Github page, to create graphs of transitive identity space; they can model privilege escalation and C2 channels.
Red teaming: for decades
Attackers have been able to construct an approach that is part of their core philosophy within an offensive security fabric. Once they’ve established a user context and what the boundaries are for that access, they can expand that access until they reach their objectives. It’s second nature…..intuitive for those in the community.
Red Teaming: from an attackers perspective
an service identity is every bit as useful as an interactive identity. This can be profound.
How to transition: What must we do?
We must understand the difference here and evolve. We must grapple with network defenders understanding how directory services, API calls, managed identity providers, and every other new technology leads to a new node in the identity graph for their enterprise.
How to transition: we’re currently doing this…
from surveying lists, performing find functions, and centering on hashes and IoC’s. This leads to defenders thinking in linear, boxed fashion, not in a hub/spoke model. One of the things I find most interesting for responders is what happens when the whiteboards come out while working a case; when multiple folks start drawing correlations between nodes, the magic begins!
How to transition: unfortunately, our stakeholders tell us
that as a whole, the reality of defenders thinking in graphs is not on the immediate horizon.
Pelican Project: I want to discuss
How we’re trying to tackle some of these concepts for our incident response teams, with a project called Pelican. I’ll explain the name later.
Pelican project: our first step
in this process was to look at how others were tackling visualizing and graphing large data sets. We found great examples out there; our first example was in Lyft’s Cartography project on their github, which lead us down the rabbit hole of looking at capabilities like Neo4J.
Pelican Project: we also looked at…
projects that had nothing to do with cyber. We found great insight in projects meant to map transitions in the financial sector, and social media interactions. There’s great energy in the industry space for this problem set; most of the major CSPs, for example, have great data lake services that allow us to manage the core data elements
Pelican project: So, what did we learn?
We learned that graphs are powerful! They have a very low barrier to entry, and they let us take structured and unstructured information to visualize it.
Pelican project; it works well with
large data sets, and allows us to apply high efficiency algorithms to the models.
Pelican project: graphs dramatically reduce
comoplexity, and can translate deeply nuanced technical information to a broad audience. This is the more useful modern equivalent of SOC watch standers throwing pie charts with IP addresses on the wall when VIPs were visiting; instant light bulbs for the audience!
Pelican project: vendors and open source technologies
are built to neck down and reduce the voliume of data so that defenders can focus on “what’s important” in a meaningful sample size.
Pelican: <press> So, why did we name it</press>
Pelican? At some point, we started naming everything after bird stuff? We had a Goose, a Sparrow, a Hawk, and now a Pelican. At some point, you just commit to the bit whether you like it or not!
Pelican: in reality
Pelican was chosen as a totem because it’s a bird that will continue to ingest more even after it’s past it’s capacity to take it in. This is a great analogy for our big data analysis capability, and also a great euphamism for me and my uncles at Thanksgiving, as we continue to go for another plate.
Pelican: In this video
you can see the “travel” for identities. This application lso has a timelining capacity, so it can zoom in and out on specific timeframes. This is meant to represent every interactive and non-interactive identity identity in a broad enterprise environment, and everything that’s accessed.
Pelican case study: So, what happens when you plumb
in these data sets? Well, let me tell you the a story.
Pelican case study: we had an AWS
AWS development environment. We used this environment to test our tooling and to emulate specific types of threats, and we decided to use THAT environment as a test bed for the Pelican graphing analytic.
Pelican case study What we saw
Is what appeared to be a sophisticated threat actor in our environment. Oh noooooooooooooo. We saw thousands of API calls with commensurate data exfil activity, on a regular basis. This rightfully raised a lot of alarms and lead to some frantic emails with our staff. This activity turned out to be, you guessed it: me, being an idiot.
Pelican case study: I had totally forgotten
That in the early days of testing, we had established an API based ingestion project in our environment, meant to both check the state of AWS services but to also ingest key logs like CloudTrail. So the great mystery of the APT actor in the environent was….Josh. This case was handled extremely efficiently. This is a very funny story to relay now, but I can’t understate how terrifying it was up front.
Future state: so what does the future hold?
We’re eager to move from what we know and can visualize into a semi-supervised graph learning state; we want to move to a place where the knowns and unknowns begin to label themselves, over time.
Future state: our next use case
Now that we’ve got some core Cloud identity information ingested into the tool, is to draw the cross CSP correlation between MSFT and AWS identity structures.
Future state: simply put
we’re eager to move to a state where incident responders can focus on the weird and the unique. That they can focus on bespoke oddities, and away from detections around atomic indicators.
Future state: this is one method
That CISA is exploring to try to tackle this particular program, but i’m eager to spend the next few days listening and learning how the brilliant folks here are also tackling similar challenges. We’re collectively better than the sum of our parts.
Future state: thanks
for your time, and i’m looking forward to meeting as many of you all as I can in the coming days!
