S1: So for around ten years now, I've been trying to
S1: figure out where all this AI stuff is going, and
S1: I want to talk about what I figured out so
S1: far and what brought me to this conclusion. And I'm
S1: going to do that by sort of taking you through
S1: how I drunk stumbled my way along to this idea.
S1: So background wise, I'm a security person going back to 1999,
S1: spent my whole career doing that offensive security Pentesting web
S1: Appsec threat modeling Vuln management. But I would say my
S1: overall container is essentially security assessment. And going back like
S1: 15 years, when I do a security assessment for a customer,
S1: I do it in an unconventional way. And this is
S1: how I still do it today. I start with like
S1: the CEO and the CEO and like the head of
S1: legal and basically all the top people who like, run
S1: the company, uh, from the very top level. And I
S1: asked them essentially, what is the business? How do they
S1: think about the business? What fundamentally do they do? If
S1: they had to strip everything away? Like what would that
S1: be like? What is the core of it? Right. And
S1: I started getting into like what data comes in, what
S1: comes out, what are their primary outputs. And then I
S1: moved on to the next level of like senior management.
S1: Then I moved through management. Then I talked to the
S1: people on the actual ground who are like actually doing things.
S1: And I start to hear discrepancies. I start to see overlaps,
S1: I start to find all the patterns and I adjust
S1: my questions accordingly. So I basically moved through the whole
S1: structure in that way and try to figure out exactly
S1: what that company is doing and how they're doing it.
S1: So as I keep gathering more and more of this information,
S1: I start filling in like this elaborate diagram for the company.
S1: All their information flows, all their vendors where they're storing data.
S1: And I start to notice things right. And ultimately I'm
S1: figuring out like, what is this company actually look like?
S1: And what's really fun is to have people come in
S1: and so they modify the screen. They say, oh, that
S1: actually doesn't exist anymore. Oh, you forgot this piece. And
S1: invariably after, like the first day, people come in and
S1: they start taking pictures. I'm like, what are you taking
S1: a picture for? And they're like, this is the best
S1: view of the company. I've never seen a clearer understanding
S1: of what we actually do than this diagram here. Like
S1: all the other ones are incomplete, so that's always fun
S1: to see. So after a week or two of this,
S1: I then do the technical assessment, and then I start
S1: asking more and more questions to figure out, hey, so
S1: isn't this a problem? They're like, oh yeah, that actually
S1: is a problem. But the key idea is taking all
S1: this content from all these interviews, including from the highest
S1: level and the lowest level, and getting all that into
S1: a single context so I can start asking questions. So
S1: speaking of security, if you have a company or any
S1: digital assets that you're responsible for protecting, I recommend you
S1: check out one of my favorite companies ever going back, like,
S1: I don't know, 10 or 15 years, which is Project Discovery.
S1: So I've been using their open source security tools like
S1: Sub finder, DNS, HTTP nuclei, and a bunch of other
S1: tools from them for like ten years now. And they
S1: just recently released a cloud solution that takes what I
S1: was doing, like chaining all these commands together on the
S1: command line. And it does it automatically for you. So
S1: you come over here, you put in a domain that
S1: you want to start with. We'll go with like Tesla
S1: because they have an open security program. And you start
S1: that and you start collecting tons of stuff on whatever
S1: target you put in there. So in the background, it's
S1: doing a whole bunch of discovery stuff on the target.
S1: It's finding domains, sub domains, making sure those domains are valid.
S1: It's finding the web applications. It's taking screenshots of those
S1: like login pages. It's finding open ports. It's even getting
S1: the tech stack for every service that you find. So
S1: here are the type of results that you get from
S1: the discovery. And from here you can actually launch a
S1: full scan using nuclei and other tools. Okay. From here
S1: we can actually go into remediation and start actually fixing
S1: these things. So basically they started all these years ago
S1: as Pentester and bug bounty and command line focused, and
S1: now they brought all that functionality together into a full
S1: vulnerability management platform. So definitely go check them out. It's
S1: cloud CIO and thanks to Project Discovery for sponsoring today's video.
S1: So separate from that in a completely different thread on
S1: the consumer side, in 2013, I started to get a
S1: picture of where I thought all this AI tech was going.
S1: At the time I called it IoT, so I wrote
S1: this book in 2016. It's kind of a crappy book.
S1: I don't recommend you read it. Honestly. There's a blog
S1: version of it online on my site, which you should
S1: go check out. It's much better. Typography is much better
S1: as well, so definitely go check it out there. But
S1: the ideas are pretty decent. So the basic concept first
S1: idea is you have digital assistants that know everything about
S1: you and they advocate for you. Then the second piece
S1: is everything gets an API, including people and objects and businesses,
S1: and our digital assistants will also have that. And your
S1: Da basically uses those services to interact with the world
S1: on your behalf and then your Da. The third piece
S1: is augmented reality. It will use all those different services,
S1: all the data from those different APIs, to present to
S1: you inside of your glasses or your lenses or whatever.
S1: It is, the proper context for whatever you're doing, right?
S1: And finally, the last piece is once you have a
S1: company or a business or an individual or family or
S1: whatever with sort of information about them presented at as APIs,
S1: you could then take your AI, whatever the smartest AI
S1: you have with the largest context, and sort of look
S1: down at that entity that you're trying to manage, and
S1: you could give it goals. You could say, I am
S1: trying to achieve this in my family, in my business,
S1: for my county, for my city, for my country. And
S1: then your. I can sort of help you manage that.
S1: So those are the concepts from the book. Then in 2018,
S1: I got a job at Apple doing information security stuff.
S1: But the team I came in with was actually a
S1: machine learning team. So I had to refresh my horrible math,
S1: and I went and did the full Andrew Ng machine
S1: Learning course, which was on YouTube at the time, and
S1: I ended up spending multiple years there at Apple building
S1: out a security product, which they still use today. Pretty
S1: happy about that. But, um, lots of practical experience of
S1: using the ML stuff in the context of security. Um,
S1: so really happy to have come in for that team
S1: at Apple. Then in early 21, I left to go
S1: build Appsec and Vulnerability Management at Robinhood with Caleb Sima.
S1: And there I did a talk at Blackhat about building
S1: vulnerability management based on company context and specifically asset management,
S1: which turned out to be another sort of brick in
S1: this path towards context. So after doing that, I decided
S1: it was time to build things on my own and
S1: do consulting stuff independently. So I went independent with unsupervised
S1: learning in like August of 22. And that was just
S1: a few months before ChatGPT came out. So obviously I
S1: go absolutely insane when I see ChatGPT and I start
S1: calling everyone I know. All my friends got that call,
S1: my mom got that call, everyone got this call multiple times.
S1: I was freaking out, basically saying drop everything, go do AI.
S1: And the first place that my head went with all
S1: this was thinking about the context that I would gather
S1: in these security assessments and thinking about how I could
S1: use this for security, obviously, because that's my background. But
S1: I pretty quickly realized that this was bigger than just security.
S1: It's actually more about the context first. So in March
S1: of 23, I wrote this post called Sspca, which says
S1: everything is about state policy questions and actions. Basically, you
S1: have the current context for the company or the program
S1: or the department, whatever it is you're trying to manage,
S1: you have that current context. Then you have the policy,
S1: which is what you're trying to accomplish. Then you have
S1: the questions that you continuously want the answers to, and
S1: then you have actions or what you know, what we
S1: as people or I could take what we could do
S1: to make that policy happen, make the desired state come true.
S1: So with this, I start feeling like, okay, now I'm
S1: starting to lock this thing in and make it more solid.
S1: So that got decent traction, but I wanted to actually
S1: demonstrate this. So I started working immediately on something more
S1: practical as like a demo. So I did a talk
S1: at Black Hat. I think the following year maybe, and
S1: I put together this fake company called alma. And I
S1: gave it tons of context for, like, everything about the company.
S1: So its mission, how they differentiate from competitors, all their
S1: different products, their goals, where they do business, the risk
S1: register security team and its members and all their skill sets. Right.
S1: The projects that they're working on, the list of applications
S1: are it stack the dev teams, how they push code
S1: like everything about this company. I put it into this file.
S1: So now I can ask questions just like I do
S1: in security assessments. And I was doing this using an
S1: agent back in 23 to basically call this thing. And
S1: the agent would look up all this different tools or whatever,
S1: look at the context. And I could do planning for this.
S1: I could do threat modeling, actually output reports. I could
S1: write emails to auditors, I could respond to one off
S1: security questionnaire questions because, you know, you have a problem
S1: of like you have this database of security answers, but
S1: the question always comes in different. This solves that. So
S1: here's an example of a CISO making a statement about
S1: no more connections to a particular resource. And we're asking
S1: the question should this connection be allowed. And the AI
S1: responds back that, no, this connection should not be allowed,
S1: because the CISO said a minute ago that no more
S1: connections to that particular resource. So you could do really
S1: cool stuff when you have context. And throughout 23, 24
S1: and now into 25, I've been building more and more
S1: stuff that circulates around this central theme of context plus AI.
S1: So later in 23, I built this thing called threshold.
S1: It's an app that takes over 3000 sources on the internet,
S1: tells me how good the context is independent of the source.
S1: And it basically uses context about me It so it
S1: knows what I like. And it's using that as the
S1: level of quality of the ideas, right? The novelty of
S1: the ideas, the number of ideas and having them being
S1: shaped in a particular direction. Right. And I could slide
S1: this lever and it only shows me content that exceeds
S1: a certain threshold of quality. Currently about to launch another
S1: product called Same Page, which is an enterprise product that
S1: helps companies manage pretty much anything based on their company context. Um,
S1: doing a lot of stuff with security programs here. Another
S1: thing I've had for like nine years now, or maybe longer,
S1: is my attack service monitoring system called Helios. And it
S1: started off as basically pure automations, right? This is like
S1: directory stuff, Linux stuff, using a bunch of tools, mostly
S1: from project Discovery and a bunch of custom tooling and
S1: Python and Bash and stuff. So it was very kind
S1: of like a dumb system, very effective. Very fast. Very good.
S1: But what I've done now is I'm turning this into
S1: a complete AI model, and I'm rewriting it to be
S1: context central. So everything goes into a particular location and
S1: I start operating on it from there. So once again,
S1: it's actions running against context. And the last one I'll
S1: mention is like a daily brief for myself. So basically
S1: looks at all these different sources that I have for
S1: like open source intelligence, national security, like really smart people
S1: who could, like, tell what's in the back of a
S1: truck looking at a satellite photo based on the fact
S1: of like the tire treads that are in the grass.
S1: So I follow, you know, hundreds of people like that,
S1: and I know they have good signal. So what I
S1: do is I bring that all together, I do analysis
S1: on it using a bunch of AI, and then it
S1: gives me like the President's Daily Brief. So now I
S1: could say, oh, it looks like this might be happening, um,
S1: which I can start thinking about. I could talk about whatever.
S1: So all these separate areas are kind of loosely revolving
S1: around this concept of context. And I so I feel
S1: like or have felt like for a long time that
S1: this is congealing. It's coalescing into this single theme. Right.
S1: But a couple of weeks ago I'm like, this is
S1: not quite it. This is not quite it. I'm close,
S1: but not not quite there. And I think I have
S1: a much simpler way of describing this now. And that's
S1: what I'm calling this unified entity context. And of course,
S1: that won't be the real name that gets used because
S1: Gartner will name it something and that'll be the new name.
S1: No big deal. If we look at security specifically and
S1: we look at some use cases, we find some really
S1: interesting patterns. So for like a SOC analyst you got
S1: tons of different logs, you got threat Intel reports, you
S1: got identity stuff, endpoint data, all these different sources for
S1: incident response. You've got the same stuff you have to
S1: look at, but it's more focused around, like the narrative,
S1: determining the scope, the timeline, stuff like that. With Pentesting,
S1: you're also gathering tons of data and then trying to
S1: put the pieces together and figure out like what to
S1: go after. Same with Red team, but you're even more
S1: focused on a larger scope, more interested in like the
S1: context of everything and the impact that you can generate.
S1: And with vulnerability management, we need to understand the organization
S1: really well. Otherwise, it's really hard to do remediation, which
S1: is kind of the whole point, program management. You got
S1: to have project management, budgeting strategy, time management, all those
S1: things combined. GRC you have to know what we need
S1: to be compliant with and why. And we have to
S1: know what our gaps are in terms of like the
S1: risk register vulnerabilities, stuff like that. So the common issue
S1: with most of these, really all of these is that
S1: you have to be able to see multiple parts of
S1: the organization all at once in context at the same time,
S1: and then connect those pieces together. This is why security
S1: analysts and incident responders and red teamers are so valuable.
S1: It's not the single task in the problem that's hard.
S1: It's integrating all the different sources to be able to
S1: actually do that task. And I'm going to go a
S1: little deeper into vulnerability management to illustrate this point. Since
S1: I've lived in that hellscape for so long. What is
S1: it that's actually hard about vulnerability management? Is it that
S1: we don't have enough vulnerabilities? Is it that our dashboards
S1: aren't pretty enough? That is not the problem. The problem
S1: is when you have a given vulnerability, what application is
S1: it part of? What engineering team is responsible for that application?
S1: What repo do they work from? What DevOps workflows do
S1: they use? Like how do they actually push code? How
S1: do they fix things day to day? What is the
S1: best way to get a really good fix to the
S1: right person that doesn't annoy them, which causes their manager
S1: to call over security and say stop bothering me. You
S1: might think this is easy to find that person, but
S1: keep in mind things are changing constantly. Reorgs team changes.
S1: Tools are changing like the whole company is constantly in motion.
S1: So here's the question how much of our inability to
S1: do a great job at vulnerability management for the last
S1: 15 years is a security problem, and how much of
S1: it is actually an organizational knowledge problem? And now ask
S1: that for other areas of security. Even crazier, it's not
S1: just security. The software and services industries in general are
S1: all based on asking specific questions to a specific set
S1: of data and giving you an output in like a
S1: kind of a specific type of UI, right? You have
S1: HR data, right? You ask HR questions to the HR
S1: data and they put that in an HR interface. Right.
S1: Same with project management. Right. You have project management data.
S1: You ask those questions. You put it into some sort
S1: of PM UI. Do we really think that these things
S1: are going to need their own separate databases and their
S1: own separate APIs, their own separate tools, their own separate UIs?
S1: I don't think so. I think that all goes away.
S1: And what we end up with is this thing which
S1: I'm calling unified entity context. So if you're an individual,
S1: your history, your belief system, your aspirations, your favorite books
S1: and music, past traumas, salary, high blood pressure, your friends,
S1: your job, your career, family goals, upbringing, medical history. Your agenda,
S1: your calendar, right, your financial goals for that particular day,
S1: like what you're trying to do for this particular year,
S1: getting ready for, you know, a half marathon, whatever it is.
S1: But then, just like with the security program, you can
S1: ask all sorts of questions. Why is my relationship with
S1: my mother in law not working? What can I do
S1: to improve my health? Right. Different questions you can ask.
S1: If you're a company. It's back to the same thing
S1: that we collected with the Alma context goals. The state
S1: of all IT systems. What are my Kubernetes pods doing?
S1: What are all my EC2 instances doing? What's going on GCP?
S1: I want all slack messages, current projects, team members, the
S1: state of HR. How many people are we hiring? How
S1: many people just left? Why did they leave? Desired IRR
S1: for the company. All products that we have, our current
S1: marketing campaigns, all of our competitors, marketing campaigns for their products.
S1: This becomes the baseline for everything. Once you have that,
S1: then you have the smartest AI you have with the
S1: largest context. Look down at the entire thing and soak
S1: it in all at once. Let's think about this from
S1: the attacker defender perspective, because this is another way that
S1: I came at this and I came up with this
S1: thing called Acad, which is AI capabilities for attackers and defenders.
S1: And the basic idea was figure out what the attackers
S1: want to do to us, and let's just make a
S1: list of those so we can defend against them. So
S1: the number one question I get asked is essentially where
S1: do I spend money for cybersecurity. And this Acad thing
S1: is basically a way to answer that is you give
S1: the answer of, well, you think about what they're about
S1: to do to you and you make sure you can
S1: respond to it. So that turned into this project where
S1: I'm gathering tons of these attacker capabilities, and I'm building
S1: a corresponding set of defender capabilities. And we're trying to
S1: figure out like, how do these play off of each other?
S1: So basically the attacker capabilities will be gathering a whole
S1: bunch of data, right? The idea is that when you
S1: run these attacker capabilities or when they run them against you,
S1: they're going to put them into their own version of
S1: your context. They're going to have a target unified entity
S1: context for you, for you as the target, which is
S1: you as a company. Right. And I thought it would
S1: look like this. I thought the most important thing was
S1: actually these capabilities are like the most important. And I'm like, well,
S1: we obviously want to maintain that inside of a state bucket, right.
S1: The unified entity context. So I thought that was that.
S1: But after thinking about it a lot more, I think
S1: it's actually this the accuracy and the freshness of the
S1: target context is actually the most important thing because the
S1: ability to attack and pivot and hinge off of all
S1: this different stuff and, you know, go a different route,
S1: be dynamic, do attacker things and defender things. It all
S1: hinges off the quality of this context. So where this
S1: all takes us is that the top priority of attackers
S1: will be having better USC models of your organization than
S1: you do. So it'll be a competition between your attacker
S1: and you, between who has the most accurate and up
S1: to date context for your company. And this is absolutely insane,
S1: because the very next step is realizing that we have
S1: this entire thing completely backwards. Instead of cybersecurity or finance
S1: or whatever, being at the center, like in this diagram
S1: with context and I being like, oh, how do you
S1: add AI to cybersecurity? Oh, we should gather more context,
S1: you know, so we could do cybersecurity better. Nope. It's
S1: actually the opposite. The context of the entity is everything.
S1: It becomes primary along with the AI that operates. Looking
S1: down at that context, software verticals kind of go away.
S1: Software and service verticals just become use cases. They become
S1: modules on top of unified context. And here's a completely
S1: crazy question to think about. And this is currently like
S1: blowing my mind. It has not stopped freaking me out
S1: since I started thinking about this. What if all of
S1: our decisions are only hard because we actually lack context?
S1: What if the fog of war Is the thing that
S1: makes things difficult. Think about a junior analyst being asked
S1: if some connection is malicious or not, and they've got
S1: like 27 different sources they can pull from all these
S1: different repositories Google Docs, slack or whatever, and you're just like,
S1: have at it. Good luck. I need to know if
S1: this is dangerous or not. This is going to be really,
S1: really hard for a junior analyst, you know, with 1
S1: or 2 years experience, even three years experience. But now
S1: imagine a principal analyst comes along to assist the junior analyst,
S1: and they build them this elaborate timeline of everything that happened.
S1: They take all the logs, they study them for 27 hours,
S1: and they build this giant, complex visual map. Then this happened,
S1: then this, this log in CrowdStrike that maps to this
S1: log in Palo Alto, blah, blah, blah. Connect all the dots. Oh,
S1: this is when the attacker did this. This is when
S1: the attacker did this. That's when this happened. So it
S1: looks like this person is actually the same person as
S1: that person. And you could see it clearly. Now can
S1: the junior analyst answer this question. Yes they can. They
S1: could probably just be like, what are you talking about?
S1: Oh that's obvious. I mean, yeah, look, obviously it's malicious
S1: because you see the story right here. It's a narrative.
S1: It's a story because of the context. Now watch this.
S1: Maybe that doesn't even require a junior SOC analyst to
S1: answer that. That could be an intern. That could be
S1: somebody still in college who's barely learned any security at all.
S1: And you're like, hey, so you're vaguely aware that there's
S1: a security like concept and like, bad things are bad.
S1: They're like, yeah, I guess it's like, well, what if
S1: I showed you this diagram here and all these are
S1: different logs that happened? Do you think that connection right
S1: there is actually malicious? They're like yeah, obviously. So maybe
S1: the problem isn't the difficulty of the task, but the
S1: difficulty of filling in the context that paints the picture.
S1: I think this is absolutely true. And it's why I
S1: think unified entity context actually ends up being the most
S1: important thing for the management of anything. An ice cream
S1: truck business, the local city council group, right? A gardening collective, right.
S1: A city government, a state, a country, a federation of planets. Basically,
S1: I can use its understanding of the entity of the
S1: thing that you care about to lower the difficulty of
S1: most decisions because it can take snapshots of the current
S1: state that's relevant to the decision that needs to be made,
S1: and put it in context, in a timeline, in a
S1: narrative that makes it obvious what you should do right.
S1: If you think about the fog of war for like
S1: a genius general. Oh, where's the enemy attacking? We don't know, sir. Okay.
S1: How many troops do we have? We're not sure. We're
S1: cut off from, uh, communication lines. How many troops do
S1: the enemy have? We're not exactly sure. Somewhere between 10,000
S1: and 100,000. Okay, cool. That requires genius of that, general.
S1: That requires genius because they're operating in so much uncertainty.
S1: When you bring that uncertainty down, you could pull a
S1: private into that room and be like, okay, we know
S1: the exact current state of everyone. What should we do?
S1: And the private walks in is like, shouldn't we just
S1: blow up that truck? Since that's the most important thing
S1: and it has all the special plans in it, and
S1: it has the special device in it. Should we just
S1: blow that up? And everyone's like, yeah, exactly. That's exactly
S1: what we should do. It requires genius. If you don't
S1: have the information, it does not require genius if you do.
S1: So the natural question is what does this mean if
S1: this is correct? Well, if you're building a company, I
S1: think you need to be thinking very carefully about how
S1: to get access to unique data for your customers. You
S1: might have the best phone management scanner, but if your
S1: competitor partners with someone who provides unique data, or they
S1: have unique data themselves for some other reason and they
S1: have access to the customer's team structure, their GitHub repos,
S1: their HR, you know, workday, they know employees coming, they
S1: know all the org changes. They know all the dev pipelines.
S1: They know which application corresponds to which dev team and
S1: which developer. You are going to lose. It doesn't matter
S1: how good your scanner is, if they know more about
S1: the customer than you do, you're going to lose. So basically,
S1: avoid getting beat by someone who knows more about the
S1: customer's organization than you do. If you're in VC or
S1: you're really any kind of investor, I'd be looking at
S1: companies that are thinking deeper into this context and are
S1: thinking about USC early, how to make it themselves if
S1: they have to, how to partner with someone who's making
S1: it up. I don't think you should look for people
S1: who are trying to build the actual USC, because I
S1: think that is so big, it's going to be most
S1: likely the giant players that are doing it. But I
S1: would say avoid betting on companies that ignore this deep
S1: context threat and are probably going to lose as a result.
S1: And if you're a defender and you're trying to figure out,
S1: like what I do, I build. To improve my cybersecurity program,
S1: you should start building your own unique context for your company.
S1: Your attackers are going to have a version of context
S1: for your company. They are going to have a unique
S1: world model of you, and your version of that unique
S1: world model needs to be better than theirs. And finally,
S1: if you're just trying to figure out where things are going,
S1: just imagine this whole AI state management, unified entity context
S1: thing as a lens that you could use or not
S1: use to interpret new AI developments. Basically, one way of
S1: interpreting the news about AI that hopefully makes some sense.
S1: Thanks for your time and I'll see you in the
S1: next one.