You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Okay, so we are going to do our series of tutorials on building Alice, our
software architect. And so as a part of that we're going to do a bunch of
engineering log videos, just the same as we do the weekly sync stuff. So this is
going to be not like the weekly sync where we do, you know, it's more of like an
office hours. This is more of, you know, whoever's working on something will
stream what they're working on so that there's, you know, basically like you can
understand their thought process and we'll have, you know, basically as detailed
as it gets logs of how we built this thing. So that's the plan. This is going to
be the first video. So we're going to do this tutorial series. Basically we're
going to do, so 12 chapters in 12 months. And yeah, and by the end of it, what
we're hoping to do is have this AI driven software architect and her name will
be Alice, like Alice in Adventures in Wonderland. And that's in the public
domain so we can riff all over that. And it's great. I love it. So we're going
to build this tutorial series. We're going to build this AI. You know, hopefully
she can help us maintain our projects, right? Just doing more of what we always
do. So writing more test cases and in effect, you know, our test cases are just
going to be this AI driven pile of CI jobs, right? We will, for instance, you
know, we've been talking about the second party plugins and that third party
plugins for a while. So basically as we, we are finally splitting that stuff
out. And as we do it, we're going to need help, sort of. Because we're going to
end up with this situation where we've got this like poly repo setup and we
don't have access to all the repos and so there's different maintainers. And
these are the third party people and then we have our second party people, which
is our org. And you know, the whole thing is going to be chaos, right? And so,
well, you know, kind of look up Alice in Wonderland, it says it's this genre of
like nonsense literature. It's like chaos. There's chaos everywhere. So as we
know, so is software development and so is life in general and so is everything,
right? So, Alice is going to help us make sense of that chaos. She is going to
rely on data flows and machine learning models and hopefully some web3 stuff,
which we'll cover in our first, you know, few videos of context here. We're
going to lay some groundwork with that. So, essentially, if you're familiar with
like KVM nested virtualization, then this is going to be a familiar concept to
you. But we're going to sort of do the simplest approach to this first. The
simplest approach and something that we can sort of like massively parallelize.
Just so if we get more compute, you know, then we can use more compute. So
great. Okay. So and what are we going to build? Okay. So what's the first thing?
Our first target is to have Alice have an understanding of an individual code
base. So once we do that, we're basically going to do an extension of should I.
So there's a bunch of should I tutorials up there. Ties in with the building
operations and stuff. The way this sort of went is, you know, the initial
project rolled out. We did this automated classification demo.
As people with the word “security” in our titles, we come across a lot of
questionable decisions. It’s our job to scrutinize the dubious and guide the
less paranoid. Wide eyed developers in a dependency wonderland can easily
find themselves smoking opiumssl with a caterpillar from stackoverflow who
assured them it’s twice as performant than openssl. Nevermind the fact that it
was written by @madhatter in 2012 and never touched since. In our infinite
wisdom we set them back on the right track. But how wise are we really? Could
a robot do just a good a job at guiding them through the looking glass?
Hello everybody. We're going to get started. I'd like to introduce you to John
Andersen. John is on the open source security team at Intel. He's from Portland.
Went to PSU for computer engineering with a focus on embedded systems and did
his honors college thesis on machine learning. He's been working at Intel as an
intern, then an employee for the past five years. Security research, embedded
systems, machine learning, and data flow programming are his current interests.
Let's welcome John. Thanks guys. Thanks for showing up. So I'm going to talk to
you a little bit today about Intel's dependency review process and how we
automated some of it using machine learning. So who am I? I'm John. As was said,
I'm an open source security guy at Intel. So I've been playing around a lot the
past few years with Linux, containers, concurrency, web apps, and Python and
machine learning a little bit more recently. So while I was at PSU doing my
undergraduate honors thesis, I did it on machine learning. And at the same time,
I was interning at Intel, and so I got the chance to work on this project where
I got to apply some of the stuff I was learning about machine learning to a real
application. So at Intel, we have a dependency review process that is part of
the release process for any given piece of software. And so the software at
Intel goes through this whole security process, right? And before you can
release, you have to make sure that none of your dependencies end up on this ban
list because a lot of software out there can be pretty bad, especially if you're
just Googling for something and you find it on GitHub and it says it does AES
and it's half the size of OpenSSL. And if you went to Matt's talk yesterday, you
might know why that is a bad thing, and you should not use that. So we have this
review form. It has a bunch of...you can't really see it, and this is not the
exact same one that is the internal one. This is one that went through legal
review. So it's got a bunch of little A through F answers for each category,
looking at things like maintenance and security testing and testing in general.
And so what we were doing is we as the open source security team were put in
charge of reviewing all packages for anybody's dependencies for all of Intel.
And so Intel writes a lot of software, and so we were reviewing thousands of
dependencies of open source software. And so we thought, well, it would be great
if we could automate this because we have other jobs like real things to do. And
we don't want to be sitting there looking at open source packages all day. It's
pretty mind-numbing. So we took this dataset of the form answers, and John
Whiteman and I took the same approach at this the first step around. And so we
grabbed this dataset, we got the URLs to all these Git repos, and we have the
review forms, right? And then we have the classification. So this should be a
pretty straightforward problem, right? We should be able to take this form and
then map it to the classification, train a machine learning model on it, and it
should tell us, yes, this is good, or no, this is bad, based on our trained
classifications. But we ran into a problem pretty much right off the bat. And
that was that reviewers weren't consistently filling out these forms. And, yeah,
big surprise, right? So we're charged with doing this mind-numbing task that
takes a lot of time, and we're really excited to go click every single dropdown.
So part of the reason for this was that first, right off the bat, you could
usually tell, or not usually, but you could sometimes tell whether something was
good or bad right away, right? So signs like, you know, has this thing written
in 2005 and never touched since, does it implement some crypto in a very
non-standard way that one guy wrote and no one else has looked at, is it a
parser? And so all of these things are early warning signs that we might just go
bad, right? You cannot use this thing. You may not ship with this software.
There are also signs of things being good, right? You know, this is system D.
Well, we may not like system D, but you can use it. We know that people are
maintaining it. So this was a failure. We only got around 60% accuracy. So we
had to go back to the drawing board and think about, well, what is our approach,
right? So if we don't have the data in the form, then we're going to have to
generate a new data set, right? And so we're going to, instead of using that
form data, we're going to generate some answers that are sort of like that form
data, right? We don't know what they're going to be yet, but we know that
there's some data that when you put it through a model, you will get something
that tells you this is good or this is bad at a high percentage accuracy.
Because after reviewing all these packages, we know that there were some things
that we could put into numbers. We just didn't quite know what they were, right?
It must be possible. So we took this iterative approach where we're going to
generate this data set, train the model. If the model gives low accuracy, that
means we have the wrong data set, right? So go back and grab some different
features. So we came up with this plug-in based system, right, where we're going
to scrape these different pieces of data that we're using as the features for
the model. And that way we can quickly swap in and out these features as we find
out that this one doesn't matter or this one does matter. And it will allow us
to, the idea is that we can swap out these features very quickly and so that we
can then find which ones matter, which ones don't. And ideally we have a
simplistic framework to do this because if I just want to count the number of
authors, that should be as simple as get log, grep authors, sort unique, right?
So that's very easy. But the problem comes into play when you start doing these,
you start running multiple of these at once and they're all running Git. And
well, Git apparently actually does some weird lock files on repos, so you can't
actually run Git concurrently. So if you want to scrape all of these repos and
iterate on this, right, then you need this regeneration process for this data
set to be fast, right? Because I can't sit here and spend two days regenerating
my data set and then go back and find out that no, that wasn't the right set of
features. That's going to be a huge waste of my time. So we needed to come up
with something that gave us a little more flexibility around like how do we
write these data scraping plugins without needing to know too much about the
other things that are scraping data as well. So we came up with this framework
that's basically like this, it's like a directed graph of operations that get
run concurrently while the execution framework deals with locking. So we define
the data types and we say, you know, this data type needs to be locked before
it's used in an operation or it doesn't need to be locked. So the Git repo, for
example, is a data type that needs to be locked. Once I've parsed some of that
data, I can throw that data back into this network of running operations and I
can now run things concurrently or if it's just random data, we can run it in
parallel, right? We don't want to be running things that are CPU bound
concurrently. And then that releases the resource lock for the other operations
that actually do need to be working on the locked resource, like other things
that need to go actively scrape the Git log or whatever it is. So this is the
directed graph showing how we would do a calculation of the number of lines of
comments to the number of lines of code ratio, which was a rough estimation for
how well documented is this code. And so what you can see here is we take the
URL of the Git repo, we clone it, and then we're going to go find what the
default branch is unless it was provided. So, you know, we want to detect if the
default branch is master or maybe it's like, you know, 5.3 point something. And
then we're going to combine that. The other thing that was happening here is
that we were doing this on a quarterly basis, so we're doing time series
information because as you can imagine, the maintenance of Git repos and the
other properties of them are all varying over time, right? So somebody may start
out doing co-verity or somebody may not start out having their thing in public
co-verity and then they put it in public co-verity, right? So quarter by
quarter, these data points change. So we have a set of operations that goes and
takes a quarter start date and goes back, you know, X number of quarters and
then generates what are the commits associated with those dates for those
various quarters. And since this is all running concurrently, part of also what
happens here is all the possible permutations of every input set for any given
function, which is also known as an operation, gets run. So as soon as you
generate all of those quarter dates, it's going to go and dispatch all of these
operations to run concurrently and it's going to go say, okay, go grab with that
default branch that you did and that quarter date. I want you to go and for
each, then it's going to say for each of these quarter ranges, I'm going to go
scrape that or I'm going to go check out that repo and then run this clock or
basically we ran clock and then we did this division to find the ratio. Right.
So this is how this execution environment works. And we are, we can, the nice
thing about this is it runs everything concurrently, manages the locking and it
does this permutations of inputs so you get every unique permutation gets run.
So when we went to go, we go to plug this back, come back to like the main
framework here, right? We've got this system for doing plugins on the data set
generation and we also came up with a system for doing plugins on the neural,
the models, the machine learning models, as well as a system for doing plugins
on the data sources. Right. So now we can iterate, we can iteratively swap out
the data generation pieces and then we can swap out the model, the model portion
so we can go and say, you know, am I using scikit, which is what we started with
because scikit will tell you what are the feature importances of each of the
pieces of data you're putting into it. So it might say, hey, you know, you gave
me this ratio of how many comments per poll or how are there a lot of comments
on every poll request or you know, what is the diversity of authorship? Like how
is, is each line of code committed by a different person? And so if you throw
that through the random forest classifier, it has this nice property being like
this classical machine learning algorithm where it can tell you that which
pieces of feature data were important in getting a good accuracy on the
prediction. So that helped us throw out these things, right? But then once we
got to a reasonable amount of accuracy, around 80%, I think it was like 82%, we
said, okay, well, we want to go switch this to a better machine learning model,
something that hasn't been around for many, many years. So let's try doing some
neural networks through TensorFlow. And so since we've got this plugin
framework, we basically say generate the data. Now instead of doing through the
scikit model, do through the TensorFlow model, it's just a command line flag to
say scikit to TensorFlow. And then now we're training using TensorFlow and we
get 90% accuracy. So that's pretty good enough right there. So we're just going
to go and start using this 90% accuracy to drop the ban hammer on things as
people submit them so they don't have to wait for this four to six week
turnaround to hear that they need to go change all their code because they used
about dependency. So, and then, like I was saying, we also swapped in and out
the data sources. So when we went to go take this into the production
environment, the production environment had this wacky MySQL setup. So we, you
know, we created this custom data source that knows how to interact with all
these various MySQL tables, which is, you know, probably the case if you're
going to integrate with an existing application, like you don't know what the
database is going to be like. Or well, you do know what the database is going to
be like, and it's probably going to be custom logic, right? So you're going to
go need to figure out how to integrate it with that custom logic. So you write a
plugin. So this is what it looked like once it got integrated, it's pulling and
pushing, pushing the data from that production database. And it, you know, you
put in the URL, it runs the data set generation, and then it runs the prediction
through the trained model. And it says, yes, I think this is a good thing or no,
I think this is a bad thing. So what's behind all this? Well, we've got this
wonderfully named library called Dataflow Facilitator for Machine Learning. And
that legal gave me this name. So it's long and it's generic and descriptive. So
what does this thing do, right? It provides the abstractions around sources and
around data set generation and around models. And we've got a few baked in for
you. But you also, it's the plugin based system does not require that you write
a plugin that gets contributed back into the main source code of the repo.
Right. So people can publish plugins and then just like have them on PyPy or
have them in their Git repos and you can install them from people's random
source and it will work as a part of the existing ecosystem. So we've got
sources for CSV files, JSONs, MySQL, and we've also got some models for
TensorFlow and Scikit to do a few things there. We provide a consistent API
across the command line interface, the library, the HTTP API, and then by
extension, the JavaScript API that works with the HTTP API. This is just like a
bunch of console log from doing all the same things we were doing in Python.
We're now doing from JavaScript hitting the HTTP API. So then you have access to
all these plugins, you know, you install somebody's random plugin. And since it
all fits in the framework, it knows how to extrapolate all the data you need to
go configure that model or whatever and display it to you through this other
API. So what else have we done with this thing? Well, we wrote this meta static
analysis tool for Python called Should I. And if you're familiar with Python or
basically any package manager, you usually type, you know, pip install or
apt-get install blank. Right. So we created this thing that goes and it
downloads the PyPy package that you were about to install and it runs some
static analysis tools on it. And right now there's only two static analysis
tools that it runs, but there can be lots more because we have this system where
we're using these operations and the amount of code that it takes to add a new
plugin to analyze the source code is basically like, I think it's like 20 lines
if it's auto formatted with this thing that makes it really long. So we take the
package name, we go grab the JSON information from the PyPy API. This is the
data flow for that. Right. And so then we extract the URL, we extract the
version, we download the package contents and we're running Bandit, which is
like a tool that does source code analysis to look for things like SQL
injections and stuff in your Python code. And then we also run this other tool
called Safety, which goes and checks for like open CVDs or known vulnerabilities
and packages. And so all of this runs concurrently. And then when you're
scheduling out to sub processes, because it's back to an async IO, the nice
thing that will happen here is that when you call it to a sub process, it
automatically gets run in parallel. So you're getting concurrency and some
parallelism for free. And also, if you're doing CPU bound tasks, it's really
easy to just say, hey, you know, schedule this in a thread and the orchestrator
will go do that for you. So we've also got this concept where you can take these
data flows, right, since we've abstracted to this level, we can take these data
flows and we can deploy them in different kinds of environments. Right. We could
deploy this as a command line application like we did, where we say, you know,
should I install this thing? It goes, runs them and gives you the results. Or we
could deploy this behind like an HTTP API. You know, coincidentally, the same
one that does all the machine learning models and stuff. So basically, we export
to YAML files and or JSON files or, you know, whatever config format you want.
Like there's a serializer and deserializer plugin, because if you haven't
noticed yet, I like plugins. And so you can export these data flows and then you
could say like, you know, run it. This is the specific data flow for the HTTP
API. And you can overlay other things on top of that to extend it and say, you
know, I so I had this base set of operations for this data flow. But now I want
to create this new data flow. Right. So I want to take these should I operations
that we wrote. Right. And one of them was download the package contents and run
the banded operation. And but now instead, I'm going to take the package
contents. And then in parallel, I'm going concurrently, I'm going to link that
into those existing get operations that we had. Right. And I didn't have to
write any code. All I had to do was modify the YAML file. And now if you can see
at the bottom here in this demo, it's giving you the lines of code or lines of
comments, a line of code ratio. And basically, we have like a very small YAML
file that gets in this overrides situation. And then you can like overlay
different operations to create new data flows by chaining together these
operations and saying how they should be connected. So this is the graph that
shows you how we took that package contents. And now we are using it in or we're
using those other get repo operations to, you know, same code. All we had to do
is tweak some YAML files. And now it's all running concurrently together. So
where do we go from here? You can check out the machine learning integration
usage example, which is basically very, very, very similar to the code that had
to be written to integrate this within Intel's environment. And you can also
check out should I, which is this meta static analysis tool. And hopefully you
guys can go contribute because it should be very easy to write little
operations. And you if you want to contribute, we have weekly meetings at 9 a.m.
PST or PDT narrate now. And we've also got a getter mailing list and the meeting
links are on this website. And I just updated all the documentation and rolled
releases this morning. So hopefully it all works. Any questions? Yes.
The open architecture aka Alice is a proxy for domain specific representations
of architecture. The metadata to help us understand each domain specific
representation of architecture is called the manifest metadata, right? We just
talked about that. And then the term manifest is used to describe the domain
specific representation of architecture, right? So just because that's a bit of
a mouthful. And then each node in the architecture graph is therefore manifest.
And then the top level document aka Alice, aka the open architecture itself,
must therefore be also a manifest because it's effectively its own thing, right?
So everything is basically just a manifest.
Alright, hello entities of the internet! I just wanted to give a brief progress
update from the month of May. Because it's the end of the first week of June
basically, which is also the last week of May. So, let's see. Where are we and
where are we going? Let's do a recap. I think we could walk through the
engineering log videos and just talk a little bit about where we've been and
where we're going. So, you'll recall that just to set the stage, remember we're
building Alice. That's what this is about. So, Alice is going to be our
developer assistant, our cross-project, cross-repo developer assistant. Who
allows us... who... yeah, basically, the point being we can apply overlays to be
cross-project, cross-organization, or granular on the level of granularity
around applying policy to build or run time for any given codebase. And
remember, we're not so much focusing on codebases anymore because we don't
really care what language anything is written in. We care about the architecture
because Alice will... I mean, code is code, right? So, we can just write some
serialization code for the underlying whatever language it needs to be in. It's
just bindings. So, let me try this again. So, recap month of May. So, we're
building Alice. We suspect that the DID and peer DID format gives us everything
that we need to... it provides us with a primitive, a storage, a serialization
primitive, right, that allows us to then serialize and deserialize from
arbitrary representations into this common representation, right? And so, why is
this... you know, why are we playing around with this stuff, right? Why are we
investigating this? Well, this primitive... the properties of the primitive are
identifier, right, document with schema, and then links to other documents,
right? So, that maps very well to our concept of the manifest, which we wrote
the shim layer for, and we've been talking about... I don't know how long we've
been talking about the manifest. It's been about a year, at least. Well, let's
see when was... okay, so this was December. But yeah, I think... December we
were talking about the manifest. But yeah, oh, we've been... I mean, we've been
doing the second party stuff. So, the second party stuff was even before the...
oh, yeah, so we've been doing the second party stuff for a while. So, basically
what we were doing is we were like, okay, well, we need to split out the
plugins, right? You know, this isn't all over the map update. The moral of the
story is we're building Alice. So far, so good. Don't have a lot of finished
products yet, but we did a lot of conceptual ground laying. We've done some
thinking in this thread. You know, many of us have conversed on the topic. We
know we're playing with ideas. We're feeling this thing out. And, you know,
we've explored our general Web3 landscape because that seems like a good way to
go. Because then the Web3 landscape would provide... the community seems to be
enthused about providing Web2 to Web3 proxies, right? So, if you just speak...
if we just speak Web3, they'll show up and do the Web2 to Web3 for us, it sounds
like, right? That sounds like that's the deal. And obviously will help. So, you
know, it's a community effort. So, then beyond that, right? So, that's our
serialization format. But beyond that, right, we're going to leverage that
serialization... we're going to leverage that serialization format, propose it
as an option, right? For the general methodology, which is to describe the
overall architecture of an arbitrary application, right? And why do we want to
do that? Well, we want to do it because we want to analyze. And if we can
analyze, then Alice can analyze. And if Alice can analyze, then she can put
together alternate programs, right? So, and she can potentially understand
intent, right? And so, next week on Saturday at 2.30 p.m. Oh, right now. So, a
week and a day from today, John Weigman and I will be presenting on living
threat models. So, John will take us on a deep dive of the situation around, you
know, threat models and, you know, how our threat models are currently dead
threat models, right? And how we might bring our threat models to life. And then
I'll touch on a bit, you know, about how Alice can help bring those to life,
right? And we'll be bringing Alice to life along the way. So, that's out of
order. OK. What else? Oh, yeah. We potentially discovered time travel in a way.
I mean, to be honest. OK. Anyway, so. Yeah. And then we also, you know, figured
out how to integrate the system context. Well, we got clarity. So, we got
clarity on what is the system context, right? The system context is the upstream
overlay in the orchestrator. And so, remember, our overlays are our ways of
essentially doing like programmatic forks of upstream with dynamic policy based
on context. So, that was fun. And then we also got into, oh, yeah, we also
explored potential architectures for distributed CI CD leveraging attestation of
build artifacts and source code via hardware security modules, aka TPMs. And how
that might pair with a DID based architecture and a pure DID based architecture.
Let's see. So, oh, look, there's this video. And then we did a lot of frantic
work on the system context. So, you know, most of this month was spent planning.
That was the intent. Obviously, you know, we hope to get a lot of work done as
well, but it ended up being mostly planning. Which is fine. That was what it was
supposed to be. But, yeah, so I think we can expect, so for next week and for
June, we can expect that we'll continue work with the system context, right?
We'll continue to flush out overlays and upstream in their application and the
granularity thereof, as well as getting a start on, you know, generating
something more than just raw feature data. And, you know, some maybe some living
threat models, right? So that can describe a code base and that Alice can
generate for us. I really would love to serialize to pure DIDs. Hopefully now
that we have the system context and we can if we can figure out how to get the
system context chain happening, then hopefully we can jump in a deserialization
very quickly. We were going to do data flow as class as the mechanism by which
we implemented the input networks for serialization and deserialization, as well
as communication of, you know, with arbitrary chains. I think we're ready to go
on that now. We just need to iron out, there's a little bit of ironing out and
it needs to be done on the deployment environment, but I think we got the
default deployment environment, so we can always just throw a data flow in there
without specific operations. So I think we're pretty much ready to roll on that.
Let's see. So, yeah, so we should go try, once we get, should I think we should
just go do that? That should be one of the first things we do. Let's go do that.
Let's, let's, okay, so where's the code before I get ahead of myself? This
always happens. So, okay, where were we? Yeah, we were trying to tie together
the CLI. I think if I don't stop trying to tie together the CLI next week,
someone tell me to stop doing that because I'm getting a little bit too in the
weeds and I'm trying not to, but, you know, it can be easy to convince yourself
sometimes that it's a good idea. So, yeah, other than that, you know, I think, I
think, you know, hopefully we see some serialization and deserialization and
communication with different chains and then hoping to see, hoping to see, well,
we started with that, so I don't want to, you know, I hope to see that. Yeah,
hoping, definitely going to see some, a living threat model of some kind get
generated. And what else are we looking at for June here? Oh, we're going to
look at the, yeah, I want to look at that TPM stuff and that key architecture
off the DID. So, so we're going to have to, we're going to have to, we're going
to have to serialize and deserialize, so we'll fix the system context. Okay, so
just to recap, where are we going? Oh, oh, that's right. So for next week and
for, yeah, so for next week we'll publish the open architecture set of ADRs,
which will workshop into a RFC probably by late July, August timeframe. I'd like
to see us RFC that. And which will cover, you know, the methodology of which
serialization to DIDs and pure DIDs is one serialization mechanism. But
generally the methodology will be focused on manifests, right? And this idea of,
you know, what are our touch points? What's the schema? And then what are the
side effects in an asynchronous nature? And so one of those could be basically
immediate return value, essentially. Or, you know, error conditions that derive
from that, which would be asynchronous. So, yeah, so open architecture ADRs next
week, living thread models next week. And then probably pure DID. So more
getting into system context a little more the week after, hopefully connecting a
few more, connecting some system context links. And then, you know, towards the
end of June, we might get into serialization and deserialization, even though I
want to do that immediately now. So I'd really like to see us trade the flows on
top of TBdex. So that will require serialization, deserialization. So if anybody
wants to jump on that TBdex trading, you know, please reach out if you haven't
already. Or reach out again if because I haven't heard. And we'll try to get
that organized. So then, you know, following the RFC, we'll try to parallelize
workstreams. So it would be really great if we could get this all done within
the next year or two. Just because, you know, why wait? So, you know, reach out
if you want to get involved and hopefully there'll be some, you know, better
commenting ability than the thread. But for now, you know, we've just got the
thread. So I'm hoping to dump this. You know, you all have seen me try to go
through and dump this several times now. So, you know, there's always something
else. So I'm definitely, it will be dumped by next week. But if you want to
comment before then, you know, please throw any thoughts or comments in the
thread. Everything is valuable. You know, we really need to flush everything
out. So great. All right. Well, thanks, everyone. And I'll see you on the
Internet or in reality.
The cornerstone of security for every application starts with a threat model. Without it, how does one know what to protect and from whom? Remarkably, most applications do not have threat models, take a look at the open-source community. And, even if a threat model is created, it tends to be neglected as the project matures since any new code checked in by the development team can potentially change the threat landscape. One could say that the existing threat model is as good as dead if such a gap exists.
Our talk is about creating a Living Threat Model (LTM) where the same best practices used in the continuous integration of source code can aptly apply to the model itself. LTMs are machine readable text files that coexist in the Git repository and, like, source code, can be updated, scanned, peer reviewed and approved by the community in a transparent way. Wouldn’t it be nice to see a threat model included in every open-source project?
We need to consider automation too to make this work in the CI/CD pipeline. We use the open-source Data Flow Facilitator for Machine Learning (DFFML) framework to establish a bidirectional data bridge between the LTM and source code. When a new pull request is created, an audit-like scan is initiated to check to see if the LTM needs to be updated. For example, if a scan detects that new cryptography has been added to the code, but the existing LTM doesn’t know about it, then a warning is triggered. Project teams can triage the issue to determine whether it is a false positive or not, just like source code scans.
We have been working on this effort for a few years and feel we are on the right track to make open-source applications more secure in a way that developers can understand.
And our next speakers are John Whiteman and John Andersen. They're going to talk
about living threat models are better than dead threat models. I totally agree.
John Whiteman is a security researcher for Intel and a part-time adjunct
instructor for the University of Portland. I'm also an Intel alumni there, John,
myself, and it's good to see you again. He also teaches the UC Berkeley's
Extension Cybersecurity Bootcamp. That's actually quite awesome. John holds a
Master's of Science in Computer Science from Georgia Institute of Technology. He
possesses multiple security certifications, including CISSP and CCSB. He has
over 20 years of experience in high tech with over half of it focused on
security. That's kind of like mine as well, half on security, half not on
building things. He can also hear John host the OWASP-Dx security podcast
online. And John grows Wasabi during his off hours. I'd like to get some of
that, John, when we meet in Portland eventually. He's driven by passion for
exploration and understanding. He's currently analyzing software development
methodologies and technologies to identify and proliferate best practices across
organizations so as to optimize asset allocation and alignment with desperate
organizational strategic principles. He's excited to explore the application of
these techniques on human and AI agents. His mission is to help foster an
environment which maintains agent freedom, privacy, and security. We also have
another fantastic John joining us, John Andersen. He is driven by passion for
exploration and understanding. He's currently, well, I think that part that I
read was for John Andersen. So I'm going to stop here and I'm going to pass it
over to you gentlemen and looking forward to your presentation. Awesome. And I'm
going to stop sharing. Can you see my screen? Absolutely. Perfect. Yeah. And by
the way, because there are two Johns, we just have the John squared thing, the
intelligent questions, like the hard to answer one that goes to John Andersen.
So we'll know the context of it. And anything like, you know, trivia for TikTok
or something that's on my side. So anything like that. So John gets the hard
questions. Sounds good. Voted. All right. Well, thank you so much. This is my
favorite day actually of the year, the favorite time because in Portland here,
we finally got back and the Rose Festival is back in progress again. And it is a
little rainy, but cool. And just a perfect day. And both of us are really, we
really appreciate you coming in and taking some time and listening to us. We
really are excited about this, but yeah, as our, as the title goes, living
threat models are better than dead threat models. The opinions expressed here
are our own and not necessarily our employer, which we have to say. And about
this presentation, we're going to assume that you already know something about
threat models. And it's not about any particular threat model methodology. We
have the old school stride, pasta, vast trike, and our favorite dread. By the
way, if anybody wants to collaborate and create a cartoon for this, we're
totally into this and be funny. And we're agnostic to threat modeling tools,
although we will be presenting a couple of tools in a couple of different
contexts, particularly about some of the nice things that they have, but the
limitations as well. What we're really trying to do here, our primary focus is
the collection and definition of data for threat modeling use. So John, can you
talk just a little bit more if you want beyond what was said? Hey, yeah, sorry.
Yeah. So I'm John I'm at Intel also with John. And right now I'm focuses on
inner source. And so, you know, analyzing software development methodology is
proliferating best practices playing around with those concepts, you know,
hopefully feeding best practices to developers internal and external, and then
also exploring that on AI agents, thinking about, you know, how can we get AI to
follow our best practices and living threat models are, you know, a part of
that. Cool. Thank you, John. And it was already said to not only micro SABI. And
by the way, the word micro, all that means is that I started out with like five
wasabi plants and I have one left that's living. So micro sounds good, but it's
actually a result of a failure as a wasabi grower and also make kombucha, but
that's an old person thing. I'm not going to get into why we do that now,
something about John squared and what kind of led up to this presentation back
in 2016, we both worked as security researchers for Intel's open source
technology center. Unfortunately that's not around anymore, but at that time our
work, we didn't really work together. We were on the same team, but we're doing
different activities. Now I left Intel 2016 for a few years and I went to Oregon
health and science university. And there I worked on a project called SAS and
the bad human project. And this is where I was using machine learning to predict
risks across hundreds of web apps at a time where they didn't really have any
expensive SAS tools. And this was risk prediction from say source code from web
applications. And I presented that information to besides in 2018, John, a year
later did something called down the dependency rabbit hole. John, you want to
describe a little bit about that work that you did? Yeah. And with that project,
what we did was we looked at open source dependencies. So if you're familiar
with like the open SSF identifying security threats or metrics, working groups,
similar sort of concept, you know, analyzing open source projects, trying to
understand whether, you know, there's something secure and robust enough from a,
from a general health and, and their predictive life cycle health standpoint,
rather than just, you know, do they have CVS or something like that? One of the
things we discovered, so I went back to Intel and we started meeting because we
felt like the work wasn't really done. We felt like we had some answers, but
then all, and sooner than later, we found fundamentally we were trying to solve
the same set of problems. Number one was to find ways to dynamically assess
risks associated with these projects to collect a bunch of data from various get
repos and other sources three we need. And this is a big bulk of what we're
going to be talking about today. And that is defined an open source threat
modeling language for integrate these systems into CI CD frameworks, five
promote and socialize our efforts for adoption. That's why we're here today.
Hopefully you get people on board. And then finally, if we solve all these
things, we made the world a much more secure place. We would go in and retire.
And when I first created the slide, I showed it to John and John just kind of
said, you know, there's a lot of words on this slide. What we can do, let's just
go straight to six and retire. So we're done with our presentation. Thank you
all have a good day. Anyway, not for that. So when apps evolve, so does the risk
and so should the threat model, at least that is what you would think. Typical
threat model workflows are like this. The team, the project team will create an
architecture design. They'll go then and do some threat modeling. And usually
it's a manual process and manuals good. We think manual processes are good. And
this would be the bulk of the threat model early on in the project. Then they'll
go off and save that threat model to store it somewhere. And usually at the same
time, they're committing code. They're doing manual code reviews. If they're
doing good, secure quality assurance. Also static code scanning, SAS tools,
dynamic testing like gas, fuzzing. If you're not fuzzing, you should be ashamed
of yourself. Everybody should be fuzzing. And then through this whole process,
they're finding and fixing vulnerabilities. It's evolutionary things get checked
in. There's a release every now and then. And yeah, maybe an escape too. You
might get a CVE back, but if your project is right, that's transparency. You're
finding and fixing and getting patches back to your customers, the end users as
soon as possible. Now one of the problems with this flow is we have, we call
this Hadrian's wall, but we couldn't find a good image for Hadrian to go this
high up. But what's happening is on the left-hand side of this is your threat
model is not really evolving as it is on the right-hand side. And so what we
call this is the tombstone threat model process or TTMP. Now it's a bit of a
hyperbole to say that a threat model is dead if you don't use it or update it
after a while, or your threat model expires. In fact, your threat model is
probably going to be pretty much intact as long as it doesn't fundamentally
change the environment and all that. So we like to use best used before or best
before. And a great analogy would be something like this. It's late at night,
it's Saturday, your refrigerator is empty, you're covered to bear, but then
you're under the sink and you see behind the drain, this package of top ramen,
and you're looking at it and it's saying, hey, best before was like two years
ago, and you got to make that critical decision. And that decision is, are you
going to eat it or not? And with top ramen, it's probably not a, it's going to
live longer than the universe. We know that. But with milk, I don't even think
they use best before. I think they use an expiration. So if anything, when you
walk away from this presentation today and somebody asks you that John squared
meeting or presentation, what did you learn from there? What we've learned is
that threat models are ramen and not milk. And I think we should be, John, I
think we should create swag for this. I just thought of that. Okay. All threat
models should be machine readable. Absolutely. That's things that we found right
off the bat. So what we normally see for typical threat model storage is you got
your threat model, teams might be doing it in something like PowerPoint or Word.
They may be doing their diagramming in Visio or something like that, and they
save it off to something. Now, these can be pretty big files. Sometimes teams
would then do, you know, convert it or export it to PDF. And those are much
smaller in most cases, but they're read only and they're not really parsable.
I've seen teams go and do threat modeling and take a picture, say of a
whiteboard and they use that diagramming they had on the whiteboard as their
threat model, nothing wrong with that. Or they've actually used a tool like a
paint, Microsoft paint or GIMP, you know, hopefully they didn't save it as a
BMP, but that's also part of what they're using for a diagramming piece. Other
teams now I see more often are doing something like DrawIO or some related ones.
And what happens is when all of these applications save, like you save that
application to data, we call this application specific languages or ASL. We'll
use the DrawIO as an example. Now most people, if you've used it before, are
aware that there's an online version, but if you didn't know, there's also a
Visual Studio Code version. It's a plugin. And what's really cool about this is
if you're already in Visual Studio, you're probably in the same place where
you're doing your coding and everything else. You're under your repo
directories. And so when you install this plugin, it comes, if you see on the
left hand side here, they call them stencils or templates, whatever, but you got
these pre-made objects and out of the box, DrawIO comes with threat modeling.
And you see here, all these nice little things that you can easily drag over to
your canvas and you can quickly start to diagram. Now this threat model that I
have here is going to be the one that we're going to be using throughout the
rest of this presentation. But it's very simple. We have three major components.
We have a client application, could be a browser, it's out of scope and it's
communicating to web server. That's in scope for us. It's talking across the
network. It's doing the right thing. It's using HTTPS, TLS for encryption and
authenticity. And then on the other side, we have a customer database. And
again, we're talking to it across the network. This could be behind the DMZ,
could be off in the cloud somewhere, but we're trying to do our best. And these
lines in blue, these dashed lines in blue, this is going to be our trust
boundaries. So we can easily diagram with these ready-made pieces. We have other
areas if we wanted to add style and all that, but again, we're really trying to
threat model, but not spend our time to make it look pretty. Now if we go and
save this, there's various ways. You can export it as an image. You can do all
that, but they also have what they call a dot DrawIO file. And all that is, is
this machine readable XML. And XML is what we call a general purpose language.
We love, we love GPLs. Other examples are JSON, YAML. And if you take a look
here, there's a lot of data here, but you can, if you just take a little time,
you can tell that there are some areas that are, you know, first of all, this is
a very small footprint, but there are areas where you start seeing things like
mixed data and the content. And so we don't necessarily care about page width.
That's not going to be a vulnerability of page width is greater than 850 pixels,
but we do care about these other areas like the database and some other
components from there. Threat modeling tools are dangerously shiny objects. This
is the biggest mistake I think people make, and we did it too. And this was
about, I say the second year where we started talking about this. We said, Hey,
you know, that's great with Draw.io and PowerPoint and all of that. Why don't we
just build a tool that does everything, not just complimentary. So it could have
diagramming, could have your APIs, reports, templates, stencils. We even talked
about gamification and even something like putting on like a virtual reality
headset, grabbing pieces in the air and putting things together. Right. But when
we realized quickly is that this whole thing starting with the tool, that's so
1990s. And it's always a big mistake. What we found is that most threat model
specific tools today, they're not CICD friendly. And it's not because they don't
have the features to automate, but it's because of a lack of a common open
threat model language. And what we mean by that is when you say that ASL data,
app one, app two, this could be something like JIRA. This could be some other
tool out there. The teams would have to build some custom tools to talk to these
other components to integrate into their CICD environment. And that's a tough
call, especially if this is just a single purpose language and other people
don't use it. And I think that's one reason why we're seeing these challenges.
And also it's hard enough to get teams to do security in the first place. One
thing we noticed out there too, there's not a lot of threat modeling tools. If
you look, there might be maybe a dozen or so. There's a bunch of others that
have false starts, but there aren't that many. And I grabbed five for this table
here to illustrate a few things. We all maybe know KIRIS, which is cool because
it also includes things like social engineering as threats where a lot of tools
kind of miss that. But Microsoft Threat Modeling tool, that's gone through a few
iterations. Our favorite OWASP Threat Dragon, Thragile, if you haven't heard
that, look that up now, and Threat Modeler. And they can come in all types in
terms of licensing. Many are open source, which we like for what we're trying to
do. Microsoft is free, but it's proprietary and Threat Modeler is proprietary.
I'm not sure if they have a community version, but you're going to pay money for
the good stuff. When we talk about data and we're coming back to the data,
there's really two major formats that we care about. There's the ASL stuff that
we talked about. Again, that's the application specific one. And most of these
application have these export formats too. And if the export formats are not
really parsable like KIRIS again, ODF, RTF, DOC files are pretty tough to manage
when you're parsing. Even the Microsoft tool does have HTML, which is a domain
specific language, but maybe not the best. And OWASP has PDF, but the ASL format
is JSON. The thing I want to talk about Thragile though is for both the ASL
format and the export format, at least it supports a GPL, a general purpose
language, YAML on the ASL format and JSON on one of the export formats. And
we'll illustrate why this is so crucial for what we want to do. Here's an
example of the Microsoft, the latest tool. They again went through a few
versions. The latest version has support around Azure and it's a great tool and
it's GUI based. You start it up, you have a nice canvas here. You can put your
objects in here similar to what we saw for Draw.io. But the nice thing about
this, it includes all of these attributes for the given type of object. And in
this case, this is processed. So when you're thinking about threads, a process
might be, is it running elevated? It doesn't have input surfaces and things like
that. So this is what is really great about this tool. Now, when we go off and
save it, again, it's GUI driven. So you have to start it up and do all your
things. But when you save it, the ASL part comes with this.TMZ file. Get this to
memory, right? This is what I call ponderously parsable. It is XML, but it's got
a mix of HTML. I see hieroglyphics in there. I don't know, Sanskrit in there.
Everything is in there. If you want to parse and figure that out, go for it. But
the actual export file is HTML. And I don't have anything really bad against
HTML, but these things are a bit dynamic, right? Based on the structures that
come with it. So we'll have about the threads, maybe a summary. And down here,
it will have that diagram that we created in the canvas, but this is embedded as
the binary inside of it. So what happens is, because this is not really CI CD
friendly, what you need to do is open the app. You have to export that report to
HTML. Then you got to go and extract this diagram, use something like
BeautifulSoup, but there you go. Now, I was going through the MSDN format
thinking, well, I must have the old version because I'm sure they did something
better here. This is back all the way from 2017, where somebody was saying that,
hey, wouldn't it be really cool if we could take this diagram and map it to the
actual things back here, like what we're talking about today. Come on Microsoft,
get with the program. And we feel that they kind of dropped the ball here
because it's not really, again, CI CD friendly. By the way, we have our own
favorite threat modeling tool. This tool is not in the list or the table that I
showed before, but this is John and I's favorite tool. It's the Etch A Sketch.
And we were talking about if somebody comes in for a job interview and they're a
security person and you give them a scenario where they have to do some
diagramming here for the threat model, we give them that scenario and we tell
them, okay, you got 10 minutes to do it. And we give them an Etch A Sketch. And
if they run away, we would hire that person. If they stayed and finish it, then
we'd be very scared of that person. Anyway, sorry about that. Application
specific data, we just talked about a machine readable, very specialized mixed
content, not portable, heavyweight, right? General purpose languages, machine
readable, generalized, JSON, XML, YAML. We love it because they're widely known,
they're accepted, they're easily recognized. You don't even have to know how to
create the parser or use parsers for them. In fact, that's the nice thing about
them is the parsers are already created. You never want to write your own
parser, right? Michael Leibovitz of the old days, parsers are hard, great
presentation. What we want to talk about next though is domain specific
languages, DSLs. Again, machine readable. Notice this is the common thread.
They're specialized and they're idiomatic to the domain, very compact and
lightweight. So some that you already know, HTML, SQL, HTML, you think of web
pages, SQL you think about relational databases, right? And that idiomatic piece
that I'm talking about, that's what gives us SQL injection errors, right?
There's specific things about it. I want to talk about two other languages.
These are diagramming languages, modeling language, mermaid and plant new ML.
And you may have seen these already in action and may not have been aware what
they were. So now if we talk about mermaid, just with a few lines of code, the
mermaid syntax here if you've never seen this before, if I click on this, it's
wonderful. You get this wonderful diagram, all of this information contained
with just a few lines of code. We're not talking about an image. We can parse
this, but the challenge here is this language you would have to figure out how
to parse it. It's very specialized. Let's take a look at another, the competitor
plant new ML. UML by the way is a modeling language. It's domain specific, but
it's based on UML. And the same thing with just a few lines of code, we can come
in here and define an equivalent threat model with this, at least with the
diagrams. Now, obviously we'd have to put more information in here, but we like
the fact that, oh, now we have some syntax. Now we have some structure, but it's
not quite what we want yet. But at least we have something here that we don't
necessarily need a full blown tool to do things with. So what is our goal? Why
am I talking about languages up to this point anyway? Well, as I mentioned way
in the beginning, we want to define a threat model language, a threat modeling
language, an open language. And open means we want to do it as an open
architecture with heavy community involvement. Now when I first, this is yet
another slide I was working with John, I'm like old school. I mean, my threat
models go back, you know, pre-Civil War days, you know, and I'm thinking like we
got to get the standards team in. We got to get the ISO people in, we got to get
the IEEE people in. And John was really quiet. He didn't really see anything.
And then he came, John, tell me why this is a better way of an open architecture
versus the way I was describing. Yeah. So yeah, and John and I, we played around
with this standard architecture and came to, standards are hard, you know,
standards require that everybody agree on the whole standard, right? So instead
what we're suggesting is, okay, let's agree on a few things and then we can all
have, you know, sort of interoperable architectures as within this realm of the
open architecture. And eventually, you know, maybe we, ideally we converge on
some standard, right? But we can't, let's not start there, you know, let's not
start climbing up the standard mountain without flushing this out as a community
first, right? So the goal is to say, Hey, here's a couple pieces of metadata,
right? Which we think your, which we think the, the open architecture should
include. If you decide that you want to do something slightly differently,
that's fine. We're all still going to be able to interoperate as long as we
include these several pieces of metadata. Yeah, perfect. And we didn't want to
pay, you know, if you want to download the standards, you have to pay for it.
The people that are really doing the work is what we want the people here.
Again, we're thinking of a CI CDI CD supported system. That's where we're
looking at with the troops on the ground. So what this diagram represents here
is this gray area is that standard considered that the paper that has the
grammars, all of the dependencies, the academic paper, if you will. And then
what we want to do is create this domain specific threat modeling language from
that. And then we want to use it and represent it as a GPL, do it in GPL. So
again, it would be something like JSON, XML, or YAML. We want to avoid that
specialized syntax. Like we, like we saw for mermaid and plant new ML, because
that's just going to be a big turnoff. If we can represent this as a GPL
language, and we're going to show you example in a second, how important that is
as, as a, as a first impression of anything for adoption from there, we believe
that once this is defined, they will build it. So do you remember when we talked
about going, building those tools first and doing all these wonderful things
again, that's so 1990s, if we have this language already defined, then people
will say, Oh, I'm going to invest my time. I'm going to go ahead and build a
threat modeling tool, but my tool is going to be cooler than the other people,
but it's going to be based on that same language that everyone else is using.
It's going to be IDE plugins, GitHub rendering. As you know, GitHub does mermaid
and plant new ML and code syntax and all of that, or even editors for it. So
Thrajile is one of our examples. I just learned about this about a month ago, a
coworker, my rich Hogan, who was talking about this and also these domain
specific languages and why I got really interested in it. So some credit to him.
The idea is that if you take a look here, this is a threat model. It's
represented as a YAML file that Thrajile understands. Now, if you don't
understand anything about the, maybe the structures, but you know something
about threat modeling, you can look in here and you can say, Oh, well, I know
threat models have security requirements. I know a threat model should have
something about assets, maybe some metadata on here. This is the oldest threat
model, the battle of Hastings in 1066. And there was some overlaps or overlooked
by Errol. And anyway, you know what happened after that. So in addition, if you
look at a full file, there's assets, there's flows, there's trust boundaries and
there's customizable things. That's key too. And you have these tags where you
can build things that might make sense to your business and nobody else. Right.
Stores nicely as re in the repos as a text file and it's the ICD friendly. It's
a Thrajile. That's the command tools name it's written in Golang. It would
ingest this YAML file generates these wonderful fla reports off the fly and you
can do audits. And we're going to talk about why audits are important and why we
need to be doing this. So Thrajile is a great one. Highly recommend you take a
look at it for the open source. By the way, we have a GitHub repo. We'll send
you all the link and all of that for it, where all the slides, but all this
stuff that we're working on, some of these demos, that information's in there as
well. Now scan threat models like you scan code. Well, if we have this wonderful
threat modeling language, this open architect language, we can do some of the
following, which we really can't do right now. Number one, we could do things
with the threat model file itself. We can write a linter for it. We can look in
the file and we can do things like, oh, it's missing assets. Why does your
threat model have no assets or some labels are missing? Maybe we see things like
duplicate names, or we can even look for the age of the threat model and that
best use before date. We can do that as well. And these are quality checks that
we call it, but we can also do scans against that same threat model file for
vulnerability checks like a SAS scanner. In this case, we might be looking for a
lack of or incorrect mitigations. Maybe you have a network connection. It says
HTTP, but you're not using TLS. That is a vulnerability, or you have nothing on
there at all. The other thing, which we'll talk about later, and this is the
core, what I believe is for this whole presentation, is with this threat model,
you can now start to model or monitor for these check-ins. If you remember that
evolutionary thing that I was talking about between the existing threat model
and the source code. So for example, as people are checking things in, all of a
sudden your source code starts containing network libraries or crypto or
something of that nature. But your existing threat model says nothing about
networks. It says nothing about cryptos. That can raise an alert and say, hey,
you might want to go back and take a look at your threat model. It looks like
we're getting some stuff in here that you haven't considered before. It could be
a false positive, it could be real, who knows. Now because we don't have that
language yet, we can use something existing and we want to use our beloved OWASP
threat dragon to make a point. And again, this is open source threat model too.
Hopefully here in OWASP we know about it. Goodwood, Gatson, Redding and all
those folks. Gatson is one of our own from the Pacific Northwest. I believe he's
still up in Vancouver, Washington state. So it's great to have that identity as
well. There's two flavors of threat dragon. One is a standalone tool and the
other one is a web app. The web app is pretty cool because what you can do is
configure it to point to your repo and it'll automatically do the commits into
it. And so all of this threat modeling is integrated into your repo. And of
course that's what we've been talking about. Really nice. Now, as we saw in that
table before, there's really two flavors. The ASL is exporting as JSON and then
the actual exports themselves are PDF. In this case, we're going to reverse it.
Normally we want to look at what the exports are, but the threat dragon's ASL,
the JSON representation is actually pretty nice and easy to parse. So this is
the same threat model that I was showing. And if we saved it off in threat
dragon, this is the actual ASL data that we get. And just at a glance, it's
pretty easy to figure out where stuff is. Again, we get this mix of presentation
data and some other trackers, but as you would go down and we have this up
there, you can see that where the client app and all the data and some of the
metadata that's associated with it, we would just want to go off and to parse
some of this stuff out to create some things. And that's what we're going to do.
For this demo, I've created three threat models with threat dragon. And they're
all based starting with the same thing here with our web server. The first one
is good and I saved it as good.json. Now when you're in threat dragon, when you
click on any of these components, you would get this little box that comes up
and it'll ask you some questions like, you know, give it a label. Is it
encrypted? Is it over a public network? And so that's about what we get and
maybe that's good enough. So we label it. Yeah, it's over a public network, but
we're doing the right thing. We're encrypting it accordingly. And that's good.
We click on the backend network connection again, same thing, but in this case,
it's not over a public network, but we're doing the right thing again. We're
labeling that's a quality thing and encrypting that's a mitigation against such
a vulnerability. And then finally the customer database stores credentials.
Okay. Is it encrypted? Yeah. At least this is what we're trying to do. Of
course, there's many other things that we can do, but for the sake of this demo,
these are the three things that we think have a, you know, a complete threat
model for this example. So this is a good threat model. A bad threat model is
where there are some problems. It could be a vulnerability problem. It could be
a quality problem. Now, John and I got really excited about this because this is
like about a year ago, a year and a half ago, I think that maybe it's longer
now. I don't know. And everything's like melting together, but do you remember
like the intentionally vulnerable web application or the intentionally
vulnerable C program that you use for AFL fuzzing and all of that? We got real
excited for training because we want people to learn how to threat model. We
could create a project that has intentionally vulnerable threat models, and we
can teach students to say, what's wrong with this threat model? And we can do it
in such a way that, well, we'll show you how you can recognize that and grade it
if you want. So in this case, again, I'm looking at these three attributes. I'm
calling this protocol now HTTP. I'm taking the TLS out. It's not encrypted. It's
over a public network. Very bad idea. In the backend side, we are encrypting and
we've left that, but we're leaving. We left out the label. So the label is more
of a quality issue, even though this is not a real vulnerability. And then the
backend, yeah, we're still storing credentials, but we're not encrypting. So we
essentially have two vulnerabilities with the encryption part, the TLS, and then
the non encrypted database. And then we have one quality issue for the protocol.
And we call this bad doc JSON. Now there has to be an ugly. I said, well, I'm
kind of stuck. What is an ugly threat model? What the heck is that? And I wish
we're all in person, because then I would ask you to raise your hands and stuff.
What is an ugly threat model? In short, it's no threat model. Shame on you. Your
grandkids will come to you. They're going to ask you grandma, grandpa, why, you
know, what are you proud of? What are you ashamed of in case you tell them I'm
proud of you the most? And what are you ashamed of the most? You say, because I
never threat model. And they'll just never look at you the same way. So this is
what we call it. And this ugly.json is an empty file. All right. Now, what I
did, because you saw how that syntax was, very simple application specific
language. I wrote a little parser. And if you take all of these things out, all
I'm doing is just extracting the info I want, ignoring the presentation data.
You can write this in maybe a few dozen lines of code or not. In fact, I wrote
this probably in about 30 minutes. That's how easy it was. And that's the beauty
of having a JSON structure. You know, you understand JSON, you understand the
structures. It doesn't take very long. I then created another one called
Auditor, which uses parser, consumes that threat dragon file, and then it goes
and looks for some specific issues. Again, the three that we mentioned here
would be a labeling issue or it's the HTTP, not HTTPS and stuff. You would
probably do these rules in some text-based file and then consume it accordingly.
But just for the sake of this presentation, you can see the power here with just
a few lines of code on each side, where now we can parse this threat model and
we can start doing things like auditing the threat model. So let me show you the
screen here. And what's happening here is I'm going through all three cases. The
first one, the good, is that empty or that good file. So here's good. We get
nothing back, which means it's good. The exit status, bad. The bad one, we get
there are three issues. And then the ugly, it just crashes my program. It's like
perfect for that anyway. So that's what we do. And you see this thing is
repeating. Now imagine this in your continuous build environment, right? Every
time you get this commit, you're going to run these things and then you're going
to set some rules there. And if you are getting something that's a non-zero
coming back, then you take whatever appropriate action or maybe there are known
issues and you look at the file. But the sky's the limit because we're all on
some standard defined open language that we can use for this. So this is this
example and the scripts are there if you want to take a look at it. Now we say,
put the threat model in the CI CD workflow. One way you can do it, and there's
multiple ways of doing it. Now we can say, instead of that threat model sitting
over there as a PowerPoint slide, we now have this defined language, machine
readable, lightweight. We can create an individual branch called threat model.
Again, this is one approach. And this threat model is keeping track of the
versions of the threat model. So like this initial check-in, this is the stuff
that we've done manually. That's all the hard work that goes in and we set it up
as we move along. Now the branch one, we might get some hot fix and this null
operator means that there's really no code inside it that has changed anything.
So we don't need to update our threat model and we can go ahead and merge
accordingly. But let's say we get some significant code changes that affect the
threat model. Maybe we're adding cloud components and all of that. And with
that, we're going to have to update our threat model here. Now this is the
point, like what we're saying is something significant like that would probably
require some manual intervention. Or if it's something small, we'll show you in
a little bit, we can actually catch that and update accordingly. Another thing
that could happen is we could get something like a zero day vulnerability. We
find out about it, but there's no code or anything. We can almost treat the
threat modeling branch as private. It's not being merged in. So we are aware of
this. And now we're waiting, maybe it's going to be branch three or something
that will come along and it's going to say, oh, we got to put an implement. We
have to implement this, but before we make it public, we're aware of that and
we're going to update the threat model accordingly. That's one way of doing it.
Another way where I think John and I kind of agree that maybe this other way is,
again, we're going to do that initial check-in where the threat model is done
manually, but then the threat model itself is really just part of the code. It's
part of the regular check-ins at the same branch. So just like the code, you're
going to do your SAS scans. You might be scanning for third-party
vulnerabilities along with your custom code. And you're also going to be
scanning your threat model because now you have those scanners for those. And
again, the caveat here is that, you know, you're going to want to check, it
might not be fully automated, but at least if you have the tools in place to
look for things like these deltas along with some human interactions, it could
be a pull request, for example, that might be just the pull, the threat model,
those are the things that are kind of natural anyway when we're doing it like
this. This is kind of a typical scenario. Now threats.md is the new readme MD.
And what do I mean by that? Well, everybody hopefully knows what a readme MD is.
It's a simple markdown file, but it has a special purpose in GitHub, right? So
it resides at the root of the repo directory. You can always find it there. And
we understand that's usually the place you start when you want to find out
something about the repository. Now inside it, this readme file, we were kind of
alluding to this earlier, but you know the triple back tick stuff, right? And
then you put something in there. The markdown parser understands it, doesn't
understand what's going on inside it, but it assumes you do, and maybe your
parser will understand it. So there's this foundation readme parser, and then
the special purpose could be domain specific stuff. In fact, Mermaid is a great
example of it. Plan UML as well on GitHub is when you look at the markdown file,
you got your triple back tick here. We got a Mermaid label here that indicates
whatever the parser is on top of that says, oh, this is, I got to pay attention
to this because this is Mermaid. It goes in and renders, of course, something
simple like that. And I think that's the coolest thing in the world. And that's
so easy to do with the readme file because it gives us the best of both worlds.
Now, I want to talk about something called overlays, and John and I kind of made
this name up, but there's a super, there's something super powerful about it.
And the best way I can explain it is start with something called citations.cfm.
Now, citation.cfm is not called an overlay, but it's something that's supported
by GitHub. If you create this file, and this is the format, it's a domain
specific format, but if you want people, and I think you should, if you got
good, if you don't know about citations and, but you have a really good repo out
there and you want people to cite it the right way, create this file. And
citations, again, we're talking about academic papers or books that may go out
and use your repo as for some something, right? You want them to cite it
correctly. This is the way to go. And as you would expect, who are the authors,
the title, version, maybe, orchid names, you have all of those, the date
released, and of course the URL. Now what happens is when you save this as
citation.cfm, it's just like, just like the readme file, you do this at the top,
you'll immediately notice over on the about on your GitHub site, this thing
appears, cite this repository. And when you click on this, all of a sudden you
start getting a couple of different flavors of citations, which is really cool.
There's APA, which is great for scientific stuff. You get bit text as well. I'd
love to see something like IEEE or Chicago style or something. People can go and
build this tool and add it accordingly. And when you pick this, you get the
format that you're looking for. If it's APA, you get this bit text is great
because it's kind of used for a lot of other things as well. And this is all it
is. Now you say, well, what's the big deal about that? Well, if we do it for
something like we create this file called threats.md, readme file, and it's just
doing some stuff here, and then we have our backticks here, we call it threat
model threats, whatever we want to call it. We have some dummy, we have our
language, we haven't defined it yet, but I'm just giving this an example. It's
going to understand now again, the readme is not going to understand it, but
somebody's going to go off and say, oh, I understand this specific language is
open and I'm going to go ahead and create some backend thing that GitHub is
going to support and it's going to render it accordingly. So if we save it as
threats.md, we then get this automatic thing that comes up again, all the
machinery's back in GitHub called threat models or threats and mitigations. And
when we click on that, we can go as far as, remember those methodologies and
those characters at the beginning of our presentation? We can have it
represented as stride. Somebody can write the stride version and it's writing on
top of our specific dsl-kml or pasta, and they can click on it and get the
language. Extremely powerful. And this is what we're saying for the potential
behind all of this. So finally we have to feed the threat model to keep it
alive. So I've been talking about languages up to this point, but what I haven't
been really talking about is how do we keep it alive? Well, we need to define
this language first, but now we need the tools to determine what's new. What are
the things that are, we're going to check for example, the deltas, what is the
data that we're going to do to extract from all this information? And John's
going to take over here. He's going to do a dffml demo and describe exactly what
this scenario is for us. John? All right. So let me bring up this. All right. So
here's what we're going to be doing. I'll show you all what we're going to be
doing and then we'll do it and then we'll talk about it again. So John and I
talked about the threats.md file and the, you know, the threat model, the threat
dragon threat model, right? And this idea of this open architecture based off of
a general purpose description like JSON, right? Or YAML or whatever, right? The
point is we have this structure and we're going to have a schema involved,
right? So we're going to be doing a little demo here where so when I said I'm
excited to try this on human and AI agents, we have a project which is spun out
of the dffml project to build sort of this AI software developer. Her name is
Alice. And so Alice is going to be helping us generate our threats.md file
today. So what we're going to do is first thing we're going to do is generate
just the thread model and it's just going to have, you know, the threat dragon
threat model in it, the diagram there and then as well as the general, just this
open architecture description of the, you know, of the, of the, of the threat
model, right? So we're doing a conversion. So let's do here. So let me remove
the file, right? So whoops. Okay. So there it is. Okay. Nevermind. Let me go to
my browser. So this is the file that gets generated here. All right. So, okay.
So I don't have the mermaid for you today, but what we do have is, and I'll
paste this into the body of a GitHub issue. So this is what it looks like,
right? So we're, we're, you know, I'm just previewing in a GitHub issue right
now in the body of an issue and, you know, so we have our threat model, our
diagram from a threat dragon, and then we have our, our open architecture spec,
right? And so this is actually, this is actually the open architecture for the
the tool itself right now. So, and you can see basically you've got effectively,
we have this directed graph of, of data and it's a little verbose right now
where, you know, where it's in progress but the main point is you have your sort
of definitions of your data types and your assets, which correspond to, you
know, the elements that we'd see up here. And then we have our connections
between them. Right. And so that's getting into, you know, what, how do we link
these things together? Okay. So then in the future, we'll have also the mermaid
diagram, which will be synthesized from there. Right. And so the concept is,
okay, you take your, your source of truth material, right? So in this case, it's
your, your, your threat dragon threat model, any maybe supplementary data you
may have, right? That's written text, and then we're going to combine it all
together using Alice and dump it into this threats, empty, right? And when we do
that this helps ensure that our threat model or our threats MD file is always up
to date, right? Because we generate that with our CI and we pull from, you know,
whatever, whatever authoritative sources of truth we have. Right. So then let's
see. Oh, I had a checklist of things I was supposed to talk about and I was not
doing that. So where is my manifest? Oh, this is, where's the manifest. I can't
get to that tab. Oh, here it is. All right. So what, you know, what, what is
this open architecture? Well at a high level and so we also have, have also been
referring to Alice as the open architecture. She's an entity which is based off
of this implement off of the architecture itself at a high level. And then so we
use the same, same terminology to refer to both. So with the open architecture
effectively what we have is like a, you can think of it almost like a reverse
proxy for domain specific formats of architecture or representations for of
architecture. And since domain specific representation of architecture is such a
mouthful we basically have been referring to that as, as what is effectively a
manifest. And so when we talked about earlier, you know, what are these
properties of, of a manifest that allow us to interoperate, right? Well, we
looked at the world and we said, okay, so what are some successful formats? What
do they do? And how would we, you know, if we treat the world of data as like
streams of data and we may not see file names, we may just see these blobs
coming through. What are the things that we need to see in these blobs of data
to know what they are, right? To know what an individual element within an
architecture is so that we can appropriately apply threats and mitigations as,
and, and the auditing, which John showed in this cross language way, right? So
you, we, we figure out what is the domain specific representation of argument
for, of architecture, AKA the manifest for our source of truth, right? And that
source of truth, you know, that we could have multiple sources of truth for
different parts of our application and we're forming them together, right? We're
bringing it all together to do this open architecture representation. And so the
nodes in that graph are effectively a manifest. And then the top level node of
the graph, the graph itself is also effectively a manifest, right? Because the
same it's, it's, it's, it's, you know, you can represent any domain specific
format within, within this is the goal, right? So, and we need this to be a
community effort to figure that out, right? So what are some of the things that
are involved in a manifest, right? Well we looked around and we said, JSON
Schema did a lot of good, you know, they, they learned, they learned some, they,
they, they have built a lot for the community, right? We stand on the shoulders
of giants. And so we know that documents should have schemas because a schema
will allow us to understand, well, what is this thing? When I hit a new node in
the graph, it'll let us say, okay, well, what should I expect this node to
contain? And if I know what I can expect the node to contain, right, I can do my
input validation. And then when my tool consumes from the graph, then it, it,
you know, I, I can have a tool that understands the various different formats in
the schemas that are applicable to each format. And then basically, well,
there's this concept of sort of the shim that says, all right, well, given this
format for this domain specific representation of architecture, let's jump into
this auditor, right? Or this visualization, right? And then we output that all
to the threats MD and that way it stays alive, right? It's not stale. It's
always coming from the source of truth. So so effectively the main thing that
we, there was three properties, which we said, these are good things, the
manifest metadata, right? Which a manifest should have, which would allow us to
effectively validate any blob of data, right? And, and say, we understand this
thing as if it's, it's part of the open architecture. It's it's part of this
proxy format, right? And that is the format name, the format version and the
schema for that. Right? So we'll combine all those things with little, little
shorthand, we'll put them all in the URL, right? And basically the file name
gives us all three of those. And then when we resolve the URL, we get the
schema, right? And so if we have this information, then we can write our parsers
off of it, right? Or our auditors, right? And then, so we talked a little bit
about the concept of overlays. So the default flow that we just ran, right? To
generate the, okay, I've got a lot of stuff on my screen here. Can you all see
the top bar? You can't see the top bar, right? All right. I'm going to assume
you can't, you know what, I'll hit enter a few times in case you can. So this
command, which we just ran, right? To generate the threat model. This just, just
you know, source of truth in and then good, good threats out. But what we would
like to do is run that auditor that John showed, right? So and here's the
auditor again, right? And so we want to run this as along with generation of the
threat model, of the threats MD, since we're thinking CI CD, we want to make
sure that this source, that that threat model conforms to like the code that
we're seeing, right? Or in this case, you know, we just want to check, check
just a few basic checks on the threat model itself to make sure it's complete,
right? And so we can start to combine this by adding overlays. So what we did
here is we basically just, we made a little overlay. All it is, is with the
underlying framework that we're using, DFMO, basically all of this is typed,
right? Because if you think about these manifests in the schema, you got to have
some types. So we're going to go ahead and just throw a little type hinting on
there and then create this overlay, which is basically saying, all right, we
have this audit operation, right? And so what we're going to do is we're going
to export the audit operation to this open architecture format, right? So once
again, I can't really see here, but I'm hoping that you can, right? So we export
the open architecture to this format. And then what we're going to do is run the
same generation with the overlay, right? So now what it's going to do is it's
going to check for, it's going to run that auditor internally, right? Along
with, let me make sure we're running the overlay, right? So it's going to run
the auditor there and we should see, you know, oops, wait, where are we? It's
the wrong command. The command is running over here. All right. We're going to
run it over here. All right. So this is the same command, different, different
terminal with the right context. And we end up, you know, with once again, the
threat model, oh, wait, wrong file. So model good threats, right? So here's the
file again, right? And this time we've run through the auditor before we
generated it, right? And that way, if the auditor failed, it wouldn't spit out
good threats MD and we'd fail the CI job. All right. Let's see. And then let's
see. So there's a few things that we want to, you know, we'd like to ask the
community to help us with, right? We'd like everybody to, you know, think about
this concept of the open architecture and how you might build tools around this,
and then also collaborate with us and comment into the thread, which we'll link
here. And we're going to have this as a pull request soon. Right now it's just a
discussion thread on GitHub. So we'd like people's feedback and to play with the
tools that we showed, you know, with the auditor and with Alice and try to
figure out, you know, how, how is this stuff working for you? You know, does,
are you having success with it? Are you seeing places where we could extend? Do
we need to modify the concept of what metadata is required, right? For us to be
interoperable? Is there some more pieces of information that, that would be
required beyond the schema, the format name and the version, right? And then
we're also looking to, you know, create this as a, along with commenting on this
thread, we're looking to make this into a whole, a working group, right? And so
within that working group, we'll try to figure out how does this, how does this
all, you know, that, that can be our forum for discussion. There was some work,
adjacent work. I think maybe I saw it in the mailing list the other day, the
SPDX abstract syntax tree stuff. It sounds like, look from what I saw, it might
be vaguely related, but we need to pull in everybody who might be working on
this type of thing. And, and, you know, think together about how this works. And
some, some future stuff that we wanted to do is combine scan data, right? So
your static analysis data to understand, are all these the components that are
really in your application, right? So using something like CVE bend tool, we
could augment, right? We output to the open architecture from CVE bend tool, and
then we augment the, the auditor to ensure that if you saw a database in your
scan results, that it better show up in your threat model. Right. So, yeah, I'll
turn it back over to John, but just a call for engagement here. Awesome. Thank
you, John. So wrapping up here, there was a question we did an interview with
Adam Shostak, like it was like one of the most exciting OAuth podcasts we did a
while back. And I think it was like 2018. That's how long ago it was. But there
was a question in there about, can we fully automate threat modeling? Can we,
could we just take the humans out of it? And he responded back with a question
and he said, can you fully automate programming? And then I said, I don't think
so. Not now. But here's something to think about. I just did a look. Yeah. I did
a Google. There's 128 million repos on GitHub right now. And we know every one
of them are quality repos with threat models. No, just joking. But if you took
10% of that or something less, and let's just pretend people decide to threat
model and let's pretend that people are making it publicly available. Right. I
think some teams are, but we just never see it. But let's say they're using this
20 years from now, 10 years from now, it's optimistic. Then you have this huge
corpus of data that you can then start creating your machine learning models
from there. And I think then that's the big picture that maybe then not only
that you have these commits where GitHub is already looking for things, but you
could also have a threat model check and it could come back and give you a
pretty good risk score or whatever you want to call it from that. So there's a
lot more involved here. Again, if we're all speaking the same language and that
language of course is this language and the tools that, and again, the people
are going to build the tools accordingly. So yeah, we do appreciate it. If
there's any questions, please feel free as, as John said, we're looking for
input and we're going to keep moving forward with this. Something's got to
happen. Something has to happen to make these more secure. So we appreciate your
time. Thank you. Thank you. Thank you again, gentlemen. Thank you, John and
John. We really appreciated that talk. I'm actually looking forward to
potentially grabbing the slide deck from you if that's possible. And I'm going
to put the sponsor. Are there any questions before we switch over? Let me take a
look at the chat. Have we taken all the questions? Yeah, it looks like it.
We've taken the discussions thread, which we were working in, which was the
Alice thread here, 1369. And so this was the original, you know, this was used,
this used to be the the improved data flow docs discussion, which you can see
got migrated, got migrated from an issue. I don't know where that information
is now. Yeah, I converted from issue, but the information's gone. But there is
an issue where this used to live for the even older version of this. So this
started, you know, we're going to improve the data flow docs and on the way we
realized, you know, hey, wait, the next step to everything is to build Alice.
So we did, you know, a lot of trying to suss out the architecture. What is this
thing? You know, what does our mental model look like? And a lot of that work
is captured within the thread here and is not yet exported to what we've done
for June. And what we've done for June is at the bottom of thread. So here's
the second party pull request. So this all started when we went and we said,
okay, we need to split out the plugins and to facilitate the second party set
up so you can have second and third party plugins. And we arrived on this
concept of the manifest, the plugins.json. And then eventually this is
ballooned into, basically, we're going to write this helper who's going to be
Alice, who's going to help us on each of the plugins in the ecosystem. So this
is what this PR now covers. So this covers a lot of different code and then a
lot of just the discussion stuff that was exported. So the pieces of this that
are of interest and to be contributed to. So please pull request the Alice
branch or please comment directly in here. And so these are sort of the pieces
of interest and there's a lot of other code in there that I'm going to clean up
that are some functionality related to stuff that's just been sitting around in
the same branch that need to get cleaned up. So then, okay, so what do we got?
So yeah, so we have the tutorial itself, right? So this is where we're going to
map the existing work streams that we've identified here. As far as chapters
that we've already started in-flight, we're going to try to map this over the
next one to two years. So reach out, get involved if you want to propose a
chapter, propose a tutorial, and then we'll figure out where we can fit it into
the roadmap with other mentors and maintainers to work with you on that. So
then, let's see. So yeah, so we can just jump right into these. The preface is,
I think, let's see, the preface is the one that kind of has a high level sketch
of a few of the chapters that don't have content yet. So I would say let's add
to the, you know, either add the chapters directly or add right to the, you can
either add it either add in either place, right? We'll try to make sure that
it's de-duplicated. So just make sure, you know, you give us enough information
that somebody can build off something, right? Or we'll evolve it. We just, you
know, all brainstorming is good right now. So we need to sort of flush this
out. So okay, let's see. So the Architect Canals Volume Zero, this is the one
where we're, you know, figuring out what is the architecture, how do we
implement the architecture, what are the base plugins, you know, what are some
of this general ecosystem stuff that we have to be aware of, and you know, how
do we work together to define the open architecture as our ecosystem grows,
right? So and you know, primarily looking at things like Web5 and CI-CD
frameworks and KCP to facilitate interaction for execution, and then formats
like SBOM, the SPDX SBOM 3.0 spec, and the 2.3 spec, and all that good stuff in
VEX. And then we're also looking at, there's some work going on with
CVE-BendTool, and they have this triage mechanism. So expanding that triage
mechanism out into sort of this generic policy mechanism, and then there's some
stuff in the thread about dynamic analysis and sort of this adaptive
sandboxing. And so if we can all collaborate, you know, to define a spec there
or to work towards a spec, you know, and perhaps building on this next piece,
which is the manifest ADR, to figure out what does that manifest look like for
that policy. And then at that point, we can start, you know, we'll start, like,
we'll take the CVE-BendTool existing triage mechanism and we'll evolve that
into this policy parser, and everybody can have their own and do different
stuff off of it. But generally, you know, we'll have this policy piece, which
will say, you know, hey, how do we accept CVEs, you know, like, or like, how do
we deal with upgrades of CVEs, you know, what ones just pass through if the
tests pass, you know, like, what's sort of our general pattern of, like, how do
we deal with incoming events? If Alice is maintaining a repo, what's the policy
around how she deals with incoming events? Right, that's sort of how we can
think of that. And then, of course, you know, Alice is the fulfillment of the
software supply chain on demand, right, in a context-aware fashion. So the SBOM
stuff is going to be very critical in figuring out, you know, what is the
existing stuff that we need to fulfill in terms of delivery if that asset is
requested. So let's see. And we're looking, of course, so we're looking at
analysis of existing artifacts, right, via things like CVE vent tool. And then
we're also looking at the definition of the plugins that we're creating and
producing SBOMs for that stuff as well, right, and making that all the same
thing, which is the open architecture. So your SBOM is your, basically your
SBOM, you take your open architecture, you overlay your SBOM, you get a running
application, right. So it, we, yeah. And then, you know, here's shows some
stuff that we're going to do where we're going to get into, you know, threat
modeling and debug and really build this entity Alice off of this Coach Alice
first set of tutorials as the base where we really get deep into how do we be
software developers, right, and what is the thought process that we go through
and model that thought process in Alice's code and in her overlays. So then
we'll get more into, so Alice and the artist strategy. This is going to be more
into the visualizations and how we sort of see the world in the same way. How
do we get to this place where we're all looking at the same picture, including
Alice, right? And so how do we explore visualizations and, you know, just
methods of interaction and communication so that we can basically viewing art
as a mode of communication and as a mode of learning, right, when we're looking
at sort of the machine sense or successful communication as being learning. And
we're going to sort of, yeah, just get into, you know, how do we, how do we use
art to learn? And then we'll flip that in volume three and say, well, how do
you use art, you know, for nefarious purposes, right? And how do you paint a
certain picture with the data that you're distributing on the network or
perhaps the entities who you reward to compute specific data, which then goes
onto the network, right, to sort of corrupt these oracles in your hybrid
on-chain off-chain contract situations. And so that is, you know, that this is,
you know, Alice and the Art of Strategy or, you know, on mind control. And
we'll focus on, you know, effective strategies for controlling one's own mind.
And then through creating this network of agents and detection of the network
of agents of who controls one's own mind, we can develop, adapt, like we can,
we'll develop adaptive policies to modify our threat model to these more
strategic threats that we faced in this hostile open network environment. So in
volume four, then we're going to go into, okay, so now we have, so we have, all
right, so what have we got here at this point? We've got our plans, volume
zero. This is what we're running. This is like our running thing where we sort
of just keep going, keep adding more stuff. It's, if it's high level
architecture stuff. So it's sort of a volume sort of knot. And then it's sort
of a set of tutorials. It's sort of just like our context around the whole
thing Vue does, almost like an ADR and implementation. So, and so when we move,
so this is, yeah, so this is how we've built our architecting Alice. Coach
Alice, this is Alice, the overlays of the software engineer, the software
architect. And then Alice and the art of strategy, you know, the communication
overlays, Alice and strategy of art, you know, these, what become effectively
our security in this new environment, in this new threat landscape. And then
once we have that, now we're like, okay, so we've got our functionality, Coach
Alice. We've got our communication with the outside world, volume two, Alice
and the art of strategy. How does she produce art? How does she interpret art?
How do we interact with her in that way? Volume three, then we have Alice in
the strategy of art. So she's seeing these communications as she's interacting
with the outside world. She knows how to do her job and she knows how to sort
of like respond and adapt in this dynamic way, which is pursuant to her, which
is always in pursuit of her strategic principles. She wakes up every day at the
TIC and she, you know, does her best to align her activities to those strategic
principles between the TIC and the TOC. And then she resets because she's
ephemeral and she goes again, right? So for each job. So in this volume, Alice
and the Health of the Ecosystem, you know, Alice will be out there and she will
be contributing to open source projects, right? And so she will be building up
our open source projects because we don't want to let her out on the whole, you
know, wide world yet. So this is our DFFML ecosystem and of course anybody else
who wants to participate in our little tutorial here. So in that case, we're
basically just going to monitor, I don't know, we need to flush this one out
more. So, but this is basically like, hey, this is right before number five,
which is then, okay, now Alice, here you go, you're going out into the world,
you know, we think you're pretty much, you're almost there. And then at that
point, you know, this is pretty far out, right? This is probably like, we're
looking at like, these are probably a year each, right? So we're probably
looking five years out now. So I don't know, this would, you know, feel free to
propose stuff. And this is, you know, what does she look like in the real
world? What kind of stuff do we have to deal with there? We want to make sure
to get anything and everything. This is, you know, ethical considerations.
We're thinking about, like, we're teaching a real human, right? Don't think of
her as a machine. Think of her as a human. Like, what, how do you be a software
engineer, a software architect in the world, right? And then how do we, you
know, debug your mind like a machine and then make you rolling, which is volume
six, right? And then we basically go in and we say, okay, you've been out in
the world for a year now. How do we fine tune you, right? So volume five is
more of like, okay, like, hey, this is a different environment, you know, it's
not a sandbox anymore, right? Our ecosystem is our sandbox. Volume five is, you
know, okay, no more sandbox. And then volume six is, okay, let's, we were in
firefighting mode for a year. Let's assume this is how these things go. And so
then we come in at volume six and we start to say, okay, now we recognize,
okay, we've taken care of the firefighting mode stuff. Now let's fine tune. And
then finally, once we've fine tuned, then she'll be rolling. And we'll all be
rolling through whatever the other side of this is. And she'll tell us what
that is. So, yeah, so please, pull request and review the Alice branch. And
please feel free to comment in the PR or reach out directly. But yeah, so this
is where we're at for June, basically. So what to expect? Well, we'll be
marching towards RFC v2, probably sometime around the end of December. We'd
like to see, you know, the rest of the ADRs that are involved in this. Let's
see. So, you know, the system context. We'd like to see the rest of Coach Alice
and probably some of Alice in the Arts strategy get fleshed out, just so that
we know what our next one to two years looks like. And then at that point, and
there's a Gantt chart, if you feel like updating the Gantt chart with any of
your plans, you can just update it directly, just make sure that you update
both. And then it'll already be on the Gantt chart. So, great, I think that's
where we're at. So the CI does not work right now. So the demo code that we've
been working on, that does work. So if you want to work on Alice, then it works
right. But the next thing that I'll be doing is I'll be trying to get the
overlay stuff working, and then the first tutorial for the overlay, so we can
get people writing overlays. So yeah, great. All right. Well, thanks, everyone.
We're building Alice, an Open Artificial General Intelligence, we invite you
to join us.
Today is Alice's unbirthday. I'm going tell you a little bit about Alice and
the Open Architecture and give a brief status update on where we're at and how
you can get involved.
Who is Alice?
Alice will be our developer helper and one day a developer herself. She
helps us understand and preform various parts of the software development
lifecycle.
We currently extend her by writing simple Python functions which can be
distributed or combined in a decentralized way.
She is built around a programming language agnostic format known as the Open
Architecture.
Eventually we will be able to extend any part of her in any language, or
have parts be driven by machine learning models.
What is the Open Architecture?
It's the methodology that we use to interpret any domain specific
description of architecture.
We are developing the open architecture so that we can do a one hop on
analysis when looking at any piece of software from a security or other
angle.
Having this generic method to describe any system architecture allows us to
knit them together and assess their risk and threat model from a holistic
viewpoint.
Why work on the Open Architecture?
We want this to be a machine and human interpretable format so that we can
facilitate the validation of the reality of the code as it exists in it's
static form, what it does when you execute it, and what we intend it to do.
Intent in our case is measured by conference to and completeness of the
threat model, and therefore also the associated open architecture
description.
The entity analysis Trinity
The entity analysis Trinity helps us conceptualize our process. The points
on our Trinity are Intent, Dynamic Analysis, and Static Analysis.
By measuring and forming understanding in these areas we will be able to
triangulate the strategic plans and principles involved in the execution of
the software as well as it's development lifecycle.
We use the Trinity to represent the soul of the software.
What happens when we work on Alice?
We build up Alice's understanding of software engineering as we automate the
collection of data which represents our understanding of it.
We also teach her how to automate parts of the development process, making
contributions and other arbitrary things.
Over time we'll build up a corpus of training data from which we'll build
machine learning models.
We will eventually introduce feedback loops where these models make
decisions about development / contribution actions to be taken when given a
codebase.
We want to make sure that when Alice is deciding what code to write and
contribute, that she is following our organizationally applicable policies.
As outlined maybe in part via our threat model.
Who is working on Alice?
The DFFML community and anyone and everyone who would like to join us.
Our objective is to build Alice with transparency, freedom, privacy,
security, and egalitarianism as critical factors in her strategic
principles.
How does one get involved?
You can get involved by engaging with the DFFML community via the following
links
Every time we contribute new functionality to Alice we write a tutorial on
how that functionality can be extended and customized.
We would love if you joined us in teaching Alice something about software
development, or anything, and teaching others in the process.
It's as easy writing a single function and explaining your thought
process.
The link on the left will take you to the code and tutorials.
We are also looking for folks who would like to contribute from by
brainstorming and thinking about AI and especially AI ethics.
The link on the right will take you a document we are collaboratively
editing and contributing to.
Now for a status update. (Progress to date)
Alice can make contributions, we've laid the foundations for the automation
of the software development process.
Our next step is to help her understand what she's looking at, what is the
code, how can she use the source Luke?
Plans
As such our top priorities right now are
Ensuring the contribution process to what exists (alice please contribute) is rock solid.
Building out and making alice shouldi contribute accessible and ready
for contribution.
Engaging with those that are collecting metrics
(https://metrics.openssf.org) and ensuring our work on metric collection
bears fruit.
Following our engagement on the metric collection front we will preform
analysis to determine how to best target further alice please contribute
efforts and align the two with a documented process on how we select high
value targets so that others can pick up and run with extending.
Participating organizations in parallel begin automated outreach via Alice
please contribute
Later we'll get into more details on the dynamic analysis portion of the
Trinity, where we'll work, over time, across many program executions of the
code we are working on, to understand how it's execution maps to the work
that we're doing via our understanding of what we've done (please contribute) and what we we're doing it on (alice shouldi contribute).
Okay, so we're still trying to build our hybrid Wolfie and Fedora distro with
the SSI service built in. And we're also gonna put the Curie stuff in there
because that sounds interesting. So there's links to that in the logs. Okay,
let's get this going. I think we're gonna be able to remove the Pixy stuff from
this. I think we're gonna be able to move directly into the EFI. Then just set
the init script to be a little thing that'll mount the proc and stuff instead
of doing the RCH root. Just go in and install the bootloader and then run QEMU
with no reboot. Also with the kernel with the EFI to the Linux kernel which
we'll copy out here. We need to copy that out. So that's what we're getting
here. We do copy, copy out. And we're in the DigitalOcean VM again. Okay, I
spun back up and I posted this thing. So copy out kernel for use for first time
bootloader. So this will be our, we can take this and this will be our image
now. Right now we can just spin VM images off Docker files. I've been wanting
to do this for years, but I can never, I never have time. So now I'm finally, I
don't know. I'm gonna, I'm just, I'm sick of it. We need it. We need it. We
need it. Okay. So it's just, it's silly that we don't have this. So copy out
kernel for use. Maybe somebody else has this, but I don't know. I want it to be
very specifically to be two scripts, right? One Docker file, basically three
scripts. One build, right? That's the pipeline. And then the Docker file, which
defines the OS and then the boot with the VM, right? And ideally we can just
get rid of this freaking bootloader installation problem eventually, but a
single pass bootloader installation, I think is an acceptable one. Now this
does require a VM, right? Because we need the loopback to mount on, which is a
restriction for this creation process. But you could potentially use user space
Linux. I'm not sure, but I think that might be an option. If you had to run it
within a container or something, you didn't have access to any sort of
virtualization, but I'm not sure. So eventually we'll get there. Okay, because
we needed to run in any environment. Okay, so yeah, and I just added another
partition. So this is the main thing that we saw. The difference between this
and last is now the Fedora partition is basically a 5GB root and then we have a
15GB root and I updated it from 20 to 30. So we have 10GB of swap or we have
our 500 and we have our 160MB FAT32. It's GPT. It's FAT32, 160MB for the EFI
boot partition. And then it's 10GB of swap. It's 5GB for the Fedora root,
right? Because that's basically just our systemd. And then the rest is Wulfy,
right? For 15GB. And that's the final line. So that's part 4, part partition 4.
So then and so what we did is we flipped. We had Wulfy as the root and then
Fedora as a CH root. But then we flipped it around and you'll see the Docker
files flipped now. So but that was so we still haven't booted into it yet.
Because we're trying to put Wulfy within the Wulfy root because previously we
didn't have a separate bind mount. Okay, and then it just worked out easier.
But now we're trying to do it from from the we're trying to copy them. So we're
going into some issues with move command and then okay, so. And then I don't
know what we could do. What just... success. All right. Okay, so then we'll
have a VM. All right. Wait, what's that? V1 do boot. Okay. Okay. All right.
Okay. Okay. Right. Okay. Well, that's basically the same thing. It's just it's
a copy over because we're copying from the local with an SCP. And this is that
digital ocean. Okay, so it's creating the image it's copying off the so it
started the Docker because I can't I can't figure out how to just export a
Docker container from from where it is. I know that I know there's a way and I
know I should but I don't know what it is. So I just start the container and I
copy it up. Right? So now it's unhappy with us. So. So why are you not happy
with this? So then we copied out and then I wanted to copy because we're the
find mounts. So you can't just copy right into the find mount. But then why are
you trying to RMRF right there? What did you RMRF immediately? Give it to
something. Listen. That should be a problem. Yeah. Okay. Um, also, why would
you do that? Would you do that? Why would you have that? Oh, no, that's
stating. Okay, yeah, do that at the end. Okay. Um, yeah, do that at the end,
please. All right, that's my bad. Let's try that again. Or let's. Okay. So. So
we remove the image, we recopy over the script and we run the script again. The
problem was here. This. Right. Should have been that. So. So now. Just check.
You're not happy. Okay. Done. Yeah, this is where I was. Okay. Do always
before. It's do. Do I can never remember. I just think. I just sit here and I
just. Mess with semi-colon after the do and the done until works every single
time. Yeah. Mine is it done doing it in one after time? But you get that just
to go update. I didn't want to not make a video and so long. So.
[00:00:00.000 --> 00:00:03.700] [MUSIC]
[00:00:03.700 --> 00:00:06.280] A threat model never expires like milk.
[00:00:06.280 --> 00:00:07.600] John Smiley.
[00:00:07.600 --> 00:00:10.800] It never expires like milk, but it's more like top ramen,
[00:00:10.800 --> 00:00:14.400] where you can maybe eat that top ramen two years later.
[00:00:14.400 --> 00:00:18.000] It's probably still best by use date.
[00:00:18.000 --> 00:00:19.240] [MUSIC]
[00:00:19.240 --> 00:00:22.360] Hi, welcome to the OpenIt Intel podcast.
[00:00:22.360 --> 00:00:24.080] I'm your host, Katherine Druckman,
[00:00:24.080 --> 00:00:26.280] an open source evangelist here at Intel.
[00:00:26.280 --> 00:00:29.480] Today, my guests are John Andersen and John Whiteman,
[00:00:29.480 --> 00:00:31.960] also known as John Squared around here.
[00:00:31.960 --> 00:00:35.440] We're going to dive into threat modeling to lay the groundwork for
[00:00:35.440 --> 00:00:38.320] a series of episodes covering open source security.
[00:00:38.320 --> 00:00:40.800] I hope you enjoy and please visit us again for
[00:00:40.800 --> 00:00:43.360] more important open source conversations.
[00:00:43.360 --> 00:00:49.000] [MUSIC]
[00:00:49.000 --> 00:00:50.880] Hey, I'm talking to John Andersen,
[00:00:50.880 --> 00:00:53.360] a DevOps architect and John Whiteman,
[00:00:53.360 --> 00:00:56.080] a security researcher both here at Intel.
[00:00:56.080 --> 00:00:59.320] Thank you for joining me to talk open source security.
[00:00:59.320 --> 00:01:00.800] >> Thank you, Katherine.
[00:01:00.800 --> 00:01:02.720] >> Yeah, thanks for having us.
[00:01:02.720 --> 00:01:06.240] >> I'm really excited about this conversation because I think
[00:01:06.240 --> 00:01:08.600] everyone especially developers should have
[00:01:08.600 --> 00:01:10.600] a basic understanding of threat modeling.
[00:01:10.600 --> 00:01:12.640] So I think this is going to be really fun.
[00:01:12.640 --> 00:01:18.720] First, I'm curious, what draws both of you to security work and security research?
[00:01:18.720 --> 00:01:24.040] >> Well, I would say I'm unable to not be drawn to it.
[00:01:24.040 --> 00:01:28.640] Once you get into this mindset,
[00:01:28.640 --> 00:01:33.360] you start seeing things and well, you want to fix things.
[00:01:33.360 --> 00:01:39.280] So as your threat model will tell you what you should be worried about.
[00:01:39.280 --> 00:01:44.760] >> Yeah, I think a lot of us are the accidental tourists.
[00:01:44.760 --> 00:01:48.440] We've been working on something before we started in security,
[00:01:48.440 --> 00:01:52.880] and all of a sudden there's this need for security and suddenly we're drawn into that.
[00:01:52.880 --> 00:01:54.400] Then once you're in security,
[00:01:54.400 --> 00:01:56.800] you could never get out of it to self-doubt.
[00:01:56.800 --> 00:01:58.200] >> Yep, you're stuck.
[00:01:58.200 --> 00:02:03.200] >> Yeah, now your brain thinks this way and everything is a potential threat.
[00:02:03.200 --> 00:02:03.720] >> Yeah.
[00:02:03.720 --> 00:02:05.000] >> To be mitigated.
[00:02:05.000 --> 00:02:07.560] >> Or it's goped appropriately.
[00:02:07.560 --> 00:02:10.960] >> This is a familiar answer to me.
[00:02:10.960 --> 00:02:13.360] So yeah, none of that surprises me.
[00:02:13.360 --> 00:02:18.440] I think threat modeling should really be the beginning of any security conversation.
[00:02:18.440 --> 00:02:20.080] So just to lay the groundwork,
[00:02:20.080 --> 00:02:24.320] what are the basics that any developer should know about threat modeling?
[00:02:24.320 --> 00:02:26.080] What is threat modeling?
[00:02:26.080 --> 00:02:31.520] >> So threat modeling, imagine maybe I use the analogy like a house,
[00:02:31.520 --> 00:02:34.680] and you own this house, you have your family,
[00:02:34.680 --> 00:02:38.160] and of course your family is what you want to protect, right?
[00:02:38.160 --> 00:02:40.640] And there may be assets inside the house as well.
[00:02:40.640 --> 00:02:44.320] So you might live in a neighborhood that is dangerous,
[00:02:44.320 --> 00:02:47.360] you might live in a safe neighborhood or something in between.
[00:02:47.360 --> 00:02:49.760] But either way, you still look at things like,
[00:02:49.760 --> 00:02:53.040] well, if I have a door, I should put a lock on it, right?
[00:02:53.040 --> 00:02:55.760] If I have windows and I leave the house,
[00:02:55.760 --> 00:02:58.440] I should maybe close them, right?
[00:02:58.440 --> 00:02:59.280] And all of these things.
[00:02:59.280 --> 00:03:02.080] So you start putting all these things in place,
[00:03:02.080 --> 00:03:06.120] and it might be, again, a neighborhood that is a bit more sketchy,
[00:03:06.120 --> 00:03:08.920] and you might say, well, maybe I should put up some security cameras
[00:03:08.920 --> 00:03:13.080] because the return on investment is there because my car got busted in,
[00:03:13.080 --> 00:03:15.000] you know, a couple of weeks ago.
[00:03:15.000 --> 00:03:18.440] Now, taking that analogy and then putting it into a project,
[00:03:18.440 --> 00:03:20.480] and not saying that your project is in a bad neighborhood,
[00:03:20.480 --> 00:03:24.440] but if you have your project, you are going to look at,
[00:03:24.440 --> 00:03:27.040] again, what is it that you're trying to protect, right?
[00:03:27.040 --> 00:03:31.760] And you're going to look at some of the mitigations that would protect them.
[00:03:31.760 --> 00:03:35.600] And some of them might not have a good return on investment.
[00:03:35.600 --> 00:03:40.480] There might be something that is more expensive than what it is that you're trying to protect.
[00:03:40.480 --> 00:03:44.320] So from threat modeling side, it's what your assets are,
[00:03:44.320 --> 00:03:47.200] who your attackers or your adversaries are,
[00:03:47.200 --> 00:03:49.760] and what are you going to do to try to protect them?
[00:03:49.760 --> 00:03:54.800] And usually try to set these objectives up front as you're building your threat model.
[00:03:54.800 --> 00:03:57.280] So the basic questions, what are you trying to protect?
[00:03:57.280 --> 00:03:59.120] Who are you trying to protect it from?
[00:03:59.120 --> 00:04:02.720] You know, what's the damage if you fail, basically, right?
[00:04:02.720 --> 00:04:04.480] Exactly, exactly.
[00:04:04.480 --> 00:04:07.120] Yep. And in the end, it could be your environment.
[00:04:07.120 --> 00:04:11.200] You may have that same house, but it depends where that house is located.
[00:04:11.200 --> 00:04:12.800] All of those things matter.
[00:04:12.800 --> 00:04:17.280] If you're going out and building something, you're creating something for a customer,
[00:04:18.000 --> 00:04:22.400] the things that you have to worry about is protecting assets that might be important to the
[00:04:22.400 --> 00:04:28.480] customer. And probably the most common thing we hear about today is like data and privacy.
[00:04:28.480 --> 00:04:32.560] So we try to identify in a project what the assets are.
[00:04:32.560 --> 00:04:36.000] And again, it could be information, your health information.
[00:04:36.000 --> 00:04:38.240] And we look for ways of protecting that.
[00:04:38.240 --> 00:04:41.360] So there could be different types of adversaries out there.
[00:04:41.360 --> 00:04:45.760] They could be nation states, they could be script kitties or whatever.
[00:04:45.760 --> 00:04:49.440] But you put these things in place to protect those assets, to of course,
[00:04:49.440 --> 00:04:52.480] protect you, your reputation, and your customers.
[00:04:52.480 --> 00:04:54.880] And fundamentally, that's what threat modeling is.
[00:04:54.880 --> 00:05:01.360] So I'm wondering, how does threat modeling differ when you're considering open source software
[00:05:01.360 --> 00:05:04.000] versus proprietary software? Does it differ?
[00:05:04.000 --> 00:05:09.520] I think it would largely depend on, you know, what angle you're looking at it from,
[00:05:09.520 --> 00:05:14.160] right? So if you're looking at it as, as you know, a vendor providing proprietary software,
[00:05:14.160 --> 00:05:20.000] you might have a different threat model than, you know, an open source project or community,
[00:05:20.000 --> 00:05:22.080] or, you know, set of open source projects, right?
[00:05:22.080 --> 00:05:27.440] So you might, you know, while we don't endorse security by obscurity, you might have a few trade
[00:05:27.440 --> 00:05:31.840] secrets that you might want to keep a secret. And so, you know, from that perspective,
[00:05:31.840 --> 00:05:38.320] you would be, you know, looking at a different, you know, level of confidentiality that you want
[00:05:38.320 --> 00:05:40.960] to ensure there, you know, for different actors, right?
[00:05:40.960 --> 00:05:45.040] Your customer is actually somebody you're trying to protect yourself against, you know,
[00:05:45.040 --> 00:05:51.120] maybe if you're a video game, right? So from that aspect, you know, you have a, you end up with
[00:05:51.120 --> 00:05:56.320] different threat actors, right? And that's all highly dependent on your situation, right?
[00:05:56.320 --> 00:05:59.760] So, you know, educational software, not protecting against the customer,
[00:05:59.760 --> 00:06:02.720] video games got to protect against the customer.
[00:06:02.720 --> 00:06:05.120] Open source software, basically everyone's a threat.
[00:06:05.120 --> 00:06:10.320] So, and everything's a threat because you have no idea how your software is going to be used.
[00:06:10.880 --> 00:06:14.240] Whereas with third-party software, right, you're selling something for a purpose.
[00:06:14.240 --> 00:06:16.880] You got a pretty good idea of why somebody's paying for that.
[00:06:16.880 --> 00:06:20.320] Whereas with open source software, you're putting it out there and you really don't know
[00:06:20.320 --> 00:06:24.080] what people are going to use it for, which can be a challenge when you're, for example,
[00:06:24.080 --> 00:06:26.240] releasing reference implementations as a company.
[00:06:26.240 --> 00:06:32.720] And I also wonder just kind of as a follow-up to that, open source is ubiquitous at this point.
[00:06:32.720 --> 00:06:36.320] I mean, open source is everywhere. I think a lot of people maybe who aren't involved in open source
[00:06:36.320 --> 00:06:40.640] don't realize just that, I mean, is there much software that doesn't use open source?
[00:06:40.640 --> 00:06:46.160] There's really not anymore. So, I wonder, you know, I wonder how that distinction is still
[00:06:46.160 --> 00:06:49.280] important, you know, as it relates to threat, threat assessment.
[00:06:49.280 --> 00:06:56.480] Well, I think one thing, John and I, we gave a presentation a while back earlier this year about
[00:06:56.480 --> 00:07:02.960] looking at threat modeling and even treating your threat model as, as source code, particularly
[00:07:02.960 --> 00:07:08.720] an open source model where everyone in that project, they become part of the threat model
[00:07:08.720 --> 00:07:13.280] development piece, right? And you treat, you know, your threat model like you treat with source code.
[00:07:13.280 --> 00:07:19.040] You look and identify them, you try to be open about it. And I think that's one huge difference,
[00:07:19.040 --> 00:07:25.680] say, as opposed to proprietary, where there may be things that, of course, the audience is much
[00:07:25.680 --> 00:07:30.800] more restricted and there's probably certain considerations. Again, maybe the proprietary software
[00:07:30.800 --> 00:07:35.920] itself is restricted and not given to a whole bunch of people, like John said, that we don't
[00:07:35.920 --> 00:07:40.560] know who's going to see it. So, there is the differences from there. But again, I think the
[00:07:40.560 --> 00:07:45.840] approach from open source software should be open source and open as well. The threat model.
[00:07:45.840 --> 00:07:51.360] I love it. I agree. Oh, just also sort of on that, you know, there's this flip side,
[00:07:51.360 --> 00:07:55.120] there's the providing side, right? And then there's also the consuming side. And of course,
[00:07:55.120 --> 00:08:00.000] with the recent supply chain, you know, focus, supply chain security focus, we've seen a lot,
[00:08:00.000 --> 00:08:05.840] you know, this shift to really think about, well, how do the things that I'm including in my project,
[00:08:05.840 --> 00:08:10.800] you know, affect the security posture of it, right? And so from that perspective, when you're choosing,
[00:08:10.800 --> 00:08:15.360] you know, when you're sourcing your components, you know, you're almost making sort of a life
[00:08:15.360 --> 00:08:21.200] cycle decision there, you know, on like that XKCD of the maintainer in Nebraska, right? That is a
[00:08:21.200 --> 00:08:25.600] choice that does factor into your health of your project and your health of your project as its
[00:08:25.600 --> 00:08:31.520] maintenance status can affect the security status of it long term. Yeah, I like that. And that's
[00:08:31.520 --> 00:08:37.600] definitely for those listening, I think that's a conversation we're going to continue to explore
[00:08:37.600 --> 00:08:43.840] in future episodes. So I hope people will come back for that. So, so what makes a good threat
[00:08:43.840 --> 00:08:52.000] model? And beyond that is a threat model ever complete. Yeah, good threat model, I think starts
[00:08:52.000 --> 00:08:57.440] with the basics. I mentioned previously with the assets identifying what those assets are
[00:08:57.440 --> 00:09:02.480] and what you're trying to protect. And then you want to get into things like trust boundaries.
[00:09:02.480 --> 00:09:08.240] So if your threat model is on a network or on maybe in the cloud, for example, there are
[00:09:08.240 --> 00:09:13.440] considerations to do and there are different levels of trust that you have to think about.
[00:09:13.440 --> 00:09:18.640] And then the flow between the trust boundaries, right? If it's as simple as a web application,
[00:09:18.640 --> 00:09:24.160] and you have a browser, you know, there's of course this big, this big span, it's called the network,
[00:09:24.160 --> 00:09:29.760] right? untrusted network that you need to cover. And also think about who your adversaries are.
[00:09:29.760 --> 00:09:36.160] In some cases, it could be advanced attackers, you know, state agents, state actors, for example,
[00:09:36.160 --> 00:09:42.560] or it could be some more simple things or even even accidental things in a vertain types of
[00:09:42.560 --> 00:09:48.000] attacks that may occur. But you want to put all of these components in and you want to make sure that
[00:09:48.000 --> 00:09:53.520] you identify the potential attacks that they have, particularly on a capabilities basis.
[00:09:53.520 --> 00:09:58.320] And then you consider things like mitigations against them. And this is where the whole risk
[00:09:58.320 --> 00:10:03.760] management thing comes into play, where mitigations could be something. Another part might be
[00:10:03.760 --> 00:10:11.440] transference of that. You may not have that ownership or it could even be acceptance. Maybe
[00:10:11.440 --> 00:10:16.960] the risk is low or the complexity is very high or the damage is minimized. So you get into all
[00:10:16.960 --> 00:10:22.480] of those aspects as well. But John, do you think that the threat model is ever done? We have a
[00:10:22.480 --> 00:10:28.160] complete-- No, and that's because the fall under that is because your scope might change, right?
[00:10:28.160 --> 00:10:32.640] And your scope might change in various different areas. And you might be scoping things in or out,
[00:10:32.640 --> 00:10:38.880] right? Depending on your deployment. And that is, you know, fundamentally, it's tied to how do you
[00:10:38.880 --> 00:10:44.960] envision your project or how will your project actually be used, right? And it's highly dependent
[00:10:44.960 --> 00:10:49.280] on scope there. If your project is alive, your threat model should be too.
[00:10:49.280 --> 00:10:55.920] How much of threat modeling is about a methodology versus just a mindset? All right,
[00:10:55.920 --> 00:10:59.280] when you think about how you approach your threat modeling process.
[00:10:59.280 --> 00:11:04.960] I think it's a combination of both. Some teams will come in and they've never done threat
[00:11:04.960 --> 00:11:10.000] modeling. So they're not sure what happens. But I see this process that takes place. As you go
[00:11:10.000 --> 00:11:14.080] through the threat modeling, they learn about these things. And it's great touch points,
[00:11:14.080 --> 00:11:19.040] particularly as a security person interacting with teams. I've seen a transformation when there is
[00:11:19.040 --> 00:11:24.240] no mindset, meaning there hasn't been any thought about threat modeling to the end of the process
[00:11:24.240 --> 00:11:29.600] where you have a nice complete threat model at that time where the team finally gets it and they
[00:11:29.600 --> 00:11:35.920] say, "Oh, I see what you're talking about." And it sort of continues on after that. And you can
[00:11:35.920 --> 00:11:41.600] apply more trust into teams to do it for future releases as we asked that question before.
[00:11:41.600 --> 00:11:47.520] The threat model is really never complete if you're adding new features or there's new kinds of
[00:11:47.520 --> 00:11:53.280] attacks out there that we're not aware of or just simply things that we forgot about or missed.
[00:11:53.280 --> 00:11:57.120] That is an evolutionary process just as the mindset is too.
[00:11:57.120 --> 00:12:04.240] So I'm wondering, and this is kind of a slightly tangential question, but just for fun, but
[00:12:04.240 --> 00:12:10.240] do you incorporate storytelling or creativity into the process when you're thinking about this?
[00:12:11.360 --> 00:12:17.680] I mean, I think that as you look at the different attackers and their various capabilities and
[00:12:17.680 --> 00:12:24.960] motivations, those almost tell the story in themselves. So nation state attacker,
[00:12:24.960 --> 00:12:34.080] your story there might be, "Hey, I'm a major, I'm Lockheed Martin." Well, then my story might be
[00:12:34.080 --> 00:12:39.040] defend against World War III. There's your story. That's your very high level.
[00:12:40.320 --> 00:12:47.360] But it might also just be, some of these are more complex, especially if you start looking at
[00:12:47.360 --> 00:12:56.720] physical access. When physical access exists and you're defending against maybe an abusive
[00:12:56.720 --> 00:13:02.160] partner situation or something. I know there's a lot of physical devices and social networking
[00:13:02.160 --> 00:13:07.920] and things that have to deal with that. That is a sad story, but a very much more complex story.
[00:13:08.640 --> 00:13:14.320] And if you don't dive into that, you're not going to see the various angles that you need to defend
[00:13:14.320 --> 00:13:22.560] against. Taking a little bit of a different turn, I believe that greater diversity on your
[00:13:22.560 --> 00:13:27.600] security team, the better, because the greater the variation among life experience, the more
[00:13:27.600 --> 00:13:33.200] coverage you get when thinking through a problem from different perspectives, how would you encourage
[00:13:33.200 --> 00:13:38.320] people new to the security field to break in? Are there any particular qualities you think that
[00:13:38.320 --> 00:13:42.720] are particularly valuable or might give a person a greater aptitude for this type of work?
[00:13:42.720 --> 00:13:49.680] At least for me, I've seen people, again, a lot of people that come into security, especially,
[00:13:49.680 --> 00:13:55.760] well, today there's a lot of college curriculum around that, right? There's cybersecurity studies,
[00:13:55.760 --> 00:14:02.560] et cetera. But a lot of folks still come from sort of a non-pathway to security. It's just that
[00:14:02.560 --> 00:14:08.880] they're in that situation where they need a security expert. And yeah, I think there's a natural
[00:14:08.880 --> 00:14:19.200] curiosity around it. There's also an added caring for your product to make sure it's secure, because
[00:14:19.200 --> 00:14:26.080] again, what we're trying to do is protect the customer and protect the reputation of who we're
[00:14:26.080 --> 00:14:31.440] working for, right? For that. And I think there's also, most security people, at least I know,
[00:14:31.440 --> 00:14:39.440] tend to like to work hard to keep learning. And if this is what you want to do and become the
[00:14:39.440 --> 00:14:47.360] experts, I mean, it's in every field out there from medical to, for what semiconductors, everything.
[00:14:47.360 --> 00:14:53.440] There's some security aspect to it. So if you're interested in AI, or if you're interested in
[00:14:53.440 --> 00:15:00.640] protecting a hardware store, it's all there for you. And I think it's a natural curiosity that
[00:15:00.640 --> 00:15:06.960] comes with all of that. Yeah. And with curiosity, and thinking about how one might be able to get
[00:15:06.960 --> 00:15:13.600] started, one of the things that really everybody can do, but is a pretty easy thing that you can do
[00:15:13.600 --> 00:15:17.760] as you're writing your software, is when you pick a dependency, a lot of times dependencies
[00:15:17.760 --> 00:15:23.200] might have, if it's a well-established project, some particular security guarantees that you should
[00:15:23.200 --> 00:15:28.080] be aware of, right? Or a security section, right? So as you're going around and you're reviewing
[00:15:28.080 --> 00:15:33.280] your dependencies, or you're choosing a new dependency, you can take a look at what the project has
[00:15:33.280 --> 00:15:37.600] already written about what they think you should consider from the security perspective. And that
[00:15:37.600 --> 00:15:42.240] can kind of tease that curiosity and kind of get you thinking about, well, why did they write that,
[00:15:42.240 --> 00:15:46.880] right? You know, what do I need to be worried about here? What do I need to be mitigating within
[00:15:46.880 --> 00:15:52.080] my usage of that? It can kind of take you down that rabbit hole a little bit. Speaking of rabbit holes,
[00:15:52.720 --> 00:15:58.720] how does working in security bleed over into your private life? Do you find yourselves tempted to
[00:15:58.720 --> 00:16:04.160] just kind of risk assess every public place and every interaction? I like to encourage people to
[00:16:04.160 --> 00:16:08.800] use threat modeling concepts when evaluating their own online behaviors, for example, like when it
[00:16:08.800 --> 00:16:13.920] comes to privacy considerations. Are there any other areas of life where you like to apply this way
[00:16:13.920 --> 00:16:20.880] of thinking? I knew somebody who had started, John and I were on the same team a while back, who had
[00:16:20.880 --> 00:16:27.760] started on our team and never had security experience and was in multiple meetings that we have. And
[00:16:27.760 --> 00:16:34.720] one observation that you had in the beginning was, why are you also paranoid? Every time somebody
[00:16:34.720 --> 00:16:40.640] said something, why are you all like that? And I said, just wait. And about a year later,
[00:16:40.640 --> 00:16:50.800] this person was exactly like us. And I, again, it is, you know, trust and verify, but maybe even
[00:16:50.800 --> 00:16:54.960] worse, never trust and always verify. I think it's a secure. Yeah, there you go.
[00:16:54.960 --> 00:16:56.800] The fox-mullter approach.
[00:16:56.800 --> 00:17:04.400] Which is, you know, it's not to say that you need to be worried about everything, right? But it's
[00:17:04.400 --> 00:17:09.680] more of that, you know, being prepared and having the mindset allows you to not worry, right?
[00:17:09.680 --> 00:17:16.960] Knowing that you've explored these angles, you know, allows you to have a, you know, more sound
[00:17:17.520 --> 00:17:23.600] approach as you go about your software project or your life, right? And so yes, you can. I have
[00:17:23.600 --> 00:17:30.400] definitely assessed every place that I walk into, you know, all the time. But, you know, I think
[00:17:30.400 --> 00:17:34.800] that type of stuff becomes second nature. And it becomes second nature as you develop your software
[00:17:34.800 --> 00:17:39.360] to. And then, you know, you are more secure and you don't think about it, right? It's just really
[00:17:39.360 --> 00:17:42.880] about being critical, right? And having that critical mindset.
[00:17:43.680 --> 00:17:48.960] So truth, when you go into a restaurant, you pick the table based on like scoping out the exits
[00:17:48.960 --> 00:17:56.960] and stuff. No, John. John always depends. Depends, depends, you know, what the throw model is.
[00:17:56.960 --> 00:18:04.720] John only grabs the seat that faces the door. That's what I love it. I highly respect that
[00:18:04.720 --> 00:18:11.680] position. Yeah. You got to know what threat actors are coming in. That's awesome. Okay, cool.
[00:18:11.680 --> 00:18:16.880] So that getting back to the kind of technical aspects here, threat modeling. So I suppose it
[00:18:16.880 --> 00:18:21.760] should be obvious that threat modeling should be undertaken early in the design process. We're
[00:18:21.760 --> 00:18:27.440] talking about software. But could you elaborate a bit on how to incorporate it into the development
[00:18:27.440 --> 00:18:36.320] life cycle and also maybe at what stages do you revisit it? So, yeah, pretty much all, but,
[00:18:36.320 --> 00:18:40.640] you know, the sooner the better. So especially when they're in the park where they're creating
[00:18:40.640 --> 00:18:45.520] the architect, they're doing the design, the architects are putting the pieces together. That's a good
[00:18:45.520 --> 00:18:51.920] time to get somebody from security involved there. Because as with anything, if you can find
[00:18:51.920 --> 00:18:57.760] problems early on, it's going to save a lot of problems later on, particularly costs and time.
[00:18:57.760 --> 00:19:04.000] But yeah, through the whole process, the upfront work is always the most, where you have the people
[00:19:04.000 --> 00:19:09.680] come in, you get all these pieces together. But once you get the, once you get that initial
[00:19:09.680 --> 00:19:13.920] architect in there and the initial threat model that represents that architecture,
[00:19:13.920 --> 00:19:18.400] then it's a lot less maintenance. And you should keep, you know, keep added, particularly if there
[00:19:18.400 --> 00:19:22.640] are no new features, particularly if you're having new releases that are coming into place,
[00:19:22.640 --> 00:19:28.160] you want to make sure that your threat model is up to date. We had a joke last summer where
[00:19:28.160 --> 00:19:34.960] a threat model never expires like milk, John smiling, it never expires like milk, but it's
[00:19:34.960 --> 00:19:41.120] more like top ramen where you can maybe eat that top ramen two years later. It's probably still,
[00:19:41.120 --> 00:19:47.040] you know, best buy use date, things like that are, I think, important to realize that, you know,
[00:19:47.040 --> 00:19:52.240] unless nothing has totally changed and your project goes out of scope, that threat model
[00:19:52.240 --> 00:19:55.600] is still should be living. It shouldn't be dead. It should be kept alive.
[00:19:55.600 --> 00:19:57.920] Oh, I like the top ramen analogy.
[00:19:57.920 --> 00:20:02.400] Yeah, wait, did you reverse that analogy? Threat models are ramen not milk.
[00:20:02.400 --> 00:20:04.720] Oh, wait, no, never mind. Okay, great. Perfect.
[00:20:04.720 --> 00:20:12.800] When you okay, so you talk about it as an ongoing process. So how often do you need to
[00:20:12.800 --> 00:20:17.600] reevaluate? How do you find the right balance between too often and not often enough?
[00:20:17.600 --> 00:20:23.920] I think that it's yeah, I think threat model is just like the product. If you look at
[00:20:23.920 --> 00:20:28.320] the threat model, like you look at your project, the evolution of your project,
[00:20:28.320 --> 00:20:32.080] if you're getting new features in and you have a release that's coming out,
[00:20:32.080 --> 00:20:36.320] you probably want to take another look at the threat model to see if anything has changed,
[00:20:36.320 --> 00:20:40.720] even for things that might have been deprecated, maybe things that you've taken out,
[00:20:40.720 --> 00:20:45.520] you want to make sure those are updated. Just think of the worst case if, let's say,
[00:20:45.520 --> 00:20:50.400] something does happen to your project and it's breached. First thing you probably want to look
[00:20:50.400 --> 00:20:56.160] at is the threat model to find out where this happened and why it happened and to make those
[00:20:56.160 --> 00:21:02.960] changes accordingly. And as I mentioned too, you might have the exact same threat model and maybe
[00:21:02.960 --> 00:21:07.760] it was in some research department, right? But now that research is going to go public,
[00:21:07.760 --> 00:21:12.560] it's going to become a production product. That threat model, even though all the technologies
[00:21:12.560 --> 00:21:16.800] are the same, it's going to change because now you have a different audience, you have a different
[00:21:16.800 --> 00:21:22.480] attack surface from there as well. And then finally, as you know, as you read the news,
[00:21:22.480 --> 00:21:28.160] there's always new techniques, new things that people are discovering, particularly the adversary
[00:21:28.160 --> 00:21:34.080] side, which you may have not considered before as possible in your threat model. So those are
[00:21:34.080 --> 00:21:39.040] things that you want to be aware of too is saying, Oh, I didn't realize that somebody could do that.
[00:21:39.040 --> 00:21:43.520] Let's revisit the threat model updated and make sure we have the right mitigations in place.
[00:21:43.520 --> 00:21:49.760] How does threat modeling differ from similar ideas like risk assessment? Or does it?
[00:21:50.720 --> 00:21:54.800] John, you want to talk about risk? Yeah, you know, I mean, I think that threat modeling and
[00:21:54.800 --> 00:21:59.520] risk assessment really go hand in hand. I think that you can't accurately assess, at least me,
[00:21:59.520 --> 00:22:04.000] personally, I would say I don't think you can accurately assess your risk unless you have some
[00:22:04.000 --> 00:22:08.880] understanding of what your threat model is. Because you know, your risk is once again,
[00:22:08.880 --> 00:22:13.280] you know, it's heavily dependent on what you've scoped in, what you've scoped out, right? Who
[00:22:13.280 --> 00:22:19.040] you're protecting from, right? And in what scenarios, right? And as John said, you know, as new things,
[00:22:19.680 --> 00:22:24.800] you know, you might even need to also factor in the risk of like, okay, so say God forbid
[00:22:24.800 --> 00:22:30.880] somebody breaks RSA, right? You know, does that collapse everything catastrophically? Or is that,
[00:22:30.880 --> 00:22:37.760] you know, a single certificate fails, right? You know, you, it's, you know, once it's sort of
[00:22:37.760 --> 00:22:41.840] it's dependent, right? And they're definitely interrelated. Yeah, that kind of leads a little
[00:22:41.840 --> 00:22:47.120] bit into the next question. In software engineering, I think many people become hyper focused on
[00:22:47.120 --> 00:22:53.280] software in an almost atomic sense, focusing on features and functionality, specialized code,
[00:22:53.280 --> 00:22:58.560] whereas threat modeling requires, I think, a far more holistic approach to thinking,
[00:22:58.560 --> 00:23:03.360] how do you ensure you are sufficiently opening your mind and getting a broad enough view?
[00:23:03.360 --> 00:23:10.320] You got to get everybody involved in the project, I would say, you know, to give you your opinions
[00:23:10.320 --> 00:23:15.520] on how they think it could be used. But I think what you'll often find is that people are using
[00:23:15.520 --> 00:23:19.920] things in a lot different ways that you think that you're using, they're using them. So that
[00:23:19.920 --> 00:23:26.960] can be one approach. Yeah, and I think another one too is that even folks, we teach a class, right,
[00:23:26.960 --> 00:23:31.920] in threat modeling and all kinds of folks in there from what you would expect the architects,
[00:23:31.920 --> 00:23:38.960] the testers as well, that go through there. But we also had managers and program managers.
[00:23:38.960 --> 00:23:44.640] And what I liked about that is that threat modeling does take some time up front to get it done right.
[00:23:44.640 --> 00:23:51.360] And they learned it. They got that Eureka moment as to what it's about. And I found that some
[00:23:51.360 --> 00:23:56.400] of the best proponents later were like program managers saying, is the threat model up to date?
[00:23:56.400 --> 00:24:02.400] Has the team done their due diligence for the next release, which I think is great. So part of
[00:24:02.400 --> 00:24:07.760] that is, as John was saying, is to get all of the actors involved. It's not just a technical
[00:24:07.760 --> 00:24:13.600] sort of exercise. It's everything as far as the whole team and everyone should get involved to
[00:24:13.600 --> 00:24:18.000] understand what those threats are. Because another set of eyes, again, is going to add a different
[00:24:18.000 --> 00:24:23.200] perspective and possibly uncover things that we never considered. Picking up on something that
[00:24:23.200 --> 00:24:28.320] John said earlier about not really knowing necessarily how your software is going to be used.
[00:24:28.320 --> 00:24:35.040] So I think developers tend to focus on how software is supposed to work, how to achieve that goal,
[00:24:35.040 --> 00:24:40.080] and maybe spend less time thinking about how it might not work or be misused. How do you as
[00:24:40.080 --> 00:24:45.360] security specialists get developers to look at software and systems from that different perspective?
[00:24:45.360 --> 00:24:50.480] So some people really love breaking things. A lot of people that get into security,
[00:24:50.480 --> 00:24:56.960] they love breaking things. Now John and I are kind of odd security birds. So that makes us
[00:24:56.960 --> 00:25:05.440] odd birds within the odd birds. So that's how we got here. But we are interested in, of course,
[00:25:05.440 --> 00:25:11.280] how to build things securely and you must know how things break. So if you're a developer and
[00:25:11.280 --> 00:25:16.160] you're thinking about security, all of those things that you hated, all of those bugs,
[00:25:16.160 --> 00:25:21.680] well, a vulnerability is just an interesting bug. So if somebody, if you might get really jazzed
[00:25:21.680 --> 00:25:27.920] about a particular bug, that bug, I bet you there's somebody who might have a vulnerability
[00:25:27.920 --> 00:25:37.040] about that bug. So if you spent all day fighting a race condition, John cracked.
[00:25:37.040 --> 00:25:46.000] John's been attacked. I'm not cutting that out.
[00:25:53.040 --> 00:25:56.560] That was more, I would call that an insider threat. I think John.
[00:25:56.560 --> 00:26:04.160] I told you this was going to be a fun podcast. Yeah, for those who can't see it,
[00:26:04.160 --> 00:26:07.280] John's headset collab. It's all good. He's fine. He's fine.
[00:26:07.280 --> 00:26:07.680] We're off.
[00:26:07.680 --> 00:26:14.560] Okay. With so many places, the development lifecycle where things can go wrong,
[00:26:14.560 --> 00:26:22.320] how do you methodically identify them? Where is the low hanging fruit? I'm new to this.
[00:26:22.320 --> 00:26:23.600] Tell me where to look first.
[00:26:23.600 --> 00:26:30.880] Well, we have many, many, many very talented colleagues in our software community who have
[00:26:30.880 --> 00:26:37.760] written a lot of cool static and dynamic, et cetera analysis tools. And so the more the
[00:26:37.760 --> 00:26:42.960] merrier on the usage, right, obviously within reason and as applicable. But of course,
[00:26:42.960 --> 00:26:47.600] these can help us find some of these issues and those issues can help us say, hey, this is a
[00:26:47.600 --> 00:26:54.000] threat for this reason. Okay, static analysis. Yeah, I like it. Step one. So, okay, speaking of tools,
[00:26:54.000 --> 00:26:58.880] like static analysis and others, what is it? What's in your toolbox and your threat modeling toolbox?
[00:26:58.880 --> 00:27:03.840] What are the frameworks, methodologies? What do you value the most? What about modeling software
[00:27:03.840 --> 00:27:07.680] like threat tracking? Is that helpful to you? Would it be more helpful for people
[00:27:07.680 --> 00:27:13.200] newer to security engineering? That's actually a great question. And I think for John and I,
[00:27:13.200 --> 00:27:19.760] we go back many years on this same question. And I think people really get excited about the tools
[00:27:19.760 --> 00:27:25.280] first and say, let's go out and find a threat modeling tool and all of that. I really think it's
[00:27:25.280 --> 00:27:31.920] still organic. My favorite tool is a chalkboard or a whiteboard and a camera starting with that
[00:27:31.920 --> 00:27:37.600] first and just talking with the teams and putting out the threat model and then worry about the
[00:27:37.600 --> 00:27:42.480] tooling later because there's sometimes I think the tool itself sort of gets in the way, right?
[00:27:42.480 --> 00:27:46.720] It's like, well, how do I make this? How do I put this label in this flow line? And how can I make
[00:27:46.720 --> 00:27:52.640] my trust boundary a nice color than green or something of that nature? So for us, at least,
[00:27:52.640 --> 00:27:57.920] what we've learned over the past is that first just threat models, get together, start that
[00:27:57.920 --> 00:28:03.280] conversation, maybe do some initial training with the team, just tell them what threat modeling is
[00:28:03.280 --> 00:28:08.800] at a very high level. And then, yeah, the methodology is going to depend on, again, maybe where you're
[00:28:08.800 --> 00:28:13.200] working at. If you're working at, per se, I like, let's say, for example, I think Microsoft,
[00:28:13.200 --> 00:28:17.760] they're the ones that came out with dread and stride and I believe they still use that. So if
[00:28:17.760 --> 00:28:22.960] that's what they're using, that's what you do. And I do know some other government agencies are
[00:28:22.960 --> 00:28:28.000] using things, maybe like pasta, whatever depends on what it is. But the first thing is just to start
[00:28:28.000 --> 00:28:33.760] threat modeling to get those things out. And then later, if you're looking at some kind of tooling
[00:28:33.760 --> 00:28:40.080] or whatever, that should come, I would say last. Now, with that said, and we've always sort of
[00:28:40.080 --> 00:28:46.160] proponents on that is we'd love to see, and I think threat dragon was one great example coming out of
[00:28:46.160 --> 00:28:52.640] OOS, if you can actually represent your threat model in some sort of machine readable tech space
[00:28:52.640 --> 00:28:58.000] thing that you could put say, if it's an open source project with your repo, or any repo doesn't
[00:28:58.000 --> 00:29:03.040] matter, and then later on, people can draw that threat model up and update it with a nice tool.
[00:29:03.600 --> 00:29:09.120] That is that is ideal as well too. But again, it depends on your circumstance. As long as
[00:29:09.120 --> 00:29:13.040] your threat modeling in the beginning, that should be the first thing. And then the other
[00:29:13.040 --> 00:29:18.800] details should work out. Yeah. And what something I keep coming back to as I have had conversations
[00:29:18.800 --> 00:29:24.560] with people recently is, you know, most of the time, the first step is really just, you know,
[00:29:24.560 --> 00:29:28.480] tell me what you know, and don't tell me what you know, tell you what you know, right? You are
[00:29:28.480 --> 00:29:34.000] the expert in your project. If you can sort of just, you know, jot down some stuff, you know, just,
[00:29:34.000 --> 00:29:40.240] then you can kind of see where that takes you. And a lot of times like John and I in this talk,
[00:29:40.240 --> 00:29:45.920] John goes into the good, the bad, and the ugly threat model, right? And the auditor, and you know,
[00:29:45.920 --> 00:29:51.760] how we can look at these threat models in this example application. And what we see is that,
[00:29:51.760 --> 00:29:58.400] when you write down what's your application doing, sometimes the gaps become fairly obvious.
[00:29:58.400 --> 00:30:03.840] Right. Like maybe, hey, you know, I've got a HTTP client, an HTTP server. And I, when I wrote it
[00:30:03.840 --> 00:30:08.720] down and I described it to myself, I didn't put TLS on there, right? So now I've immediately
[00:30:08.720 --> 00:30:12.800] identified I have no encryption. And I'm really all I had to do was sort of ask myself some questions
[00:30:12.800 --> 00:30:18.800] about my application. I personally, I find the identifying threat agent stage to be the most
[00:30:18.800 --> 00:30:23.520] interesting. And also maybe the least straightforward, although I could be wrong and please, please,
[00:30:23.520 --> 00:30:29.360] weigh in if you feel differently. But how do you break down that task? And what resources or
[00:30:29.360 --> 00:30:35.600] methodologies are most helpful to identify? Yeah, that that a lot of it has to deal with what
[00:30:35.600 --> 00:30:41.280] the technologies are at hand. So for example, if you're using a network, well, there's probably
[00:30:41.280 --> 00:30:47.040] going to be some kind of network adversary, right, in that regard. But then you always have to think
[00:30:47.040 --> 00:30:51.920] about there's the insider threat, right? There might be somebody at the company that might,
[00:30:51.920 --> 00:30:55.920] you know, of course, those are probably the worst, right? Because they would have access and
[00:30:55.920 --> 00:31:02.160] more privileges. It might be, again, maybe you're working for a defense contractor. So you have
[00:31:02.160 --> 00:31:08.080] government agencies that might not be friendly, might be your attackers as well. And they may have
[00:31:08.080 --> 00:31:13.760] a lot more resources and a lot more time to be able to, you know, attack your system. I always
[00:31:13.760 --> 00:31:19.600] think that's the biggest challenge for anyone in this, this whole security process. You know,
[00:31:19.600 --> 00:31:24.000] if you're at a company, you only have a certain amount of time before you got to get that product
[00:31:24.000 --> 00:31:29.760] shipped, right? So you don't have a lot of time to get the security right. So part of that is as
[00:31:29.760 --> 00:31:35.760] you evolve, you build your skill sets up and you do it better and quicker. But these threat agents
[00:31:35.760 --> 00:31:41.040] out there, they, many of them do have all the time in the world and may have money and may be able
[00:31:41.040 --> 00:31:46.960] to break these systems where you might not have the just the right amount of time to do it. But
[00:31:46.960 --> 00:31:51.280] that's a whole, in a way, I think that's the interesting part of the challenge. And maybe
[00:31:51.280 --> 00:31:55.680] going back to your original question, why we do it, we kind of like that challenge. We say,
[00:31:55.680 --> 00:31:59.760] well, we're going to step the game up the next time. We're going to do it better the next time.
[00:31:59.760 --> 00:32:04.880] And I think that's another part of what we do, particularly in threat modeling, which makes it so
[00:32:04.880 --> 00:32:10.400] interesting. That was such a good answer. Thank you. I'm wondering if there's anything, if there's
[00:32:10.400 --> 00:32:15.280] any angle here that we haven't covered that you wanted to make sure to mention. Speaking of,
[00:32:15.280 --> 00:32:22.240] you know, different tooling that you can use, right, we have this project where we're looking at,
[00:32:22.240 --> 00:32:27.920] you know, defining, when you look at the threat model of an application, you're also looking at,
[00:32:27.920 --> 00:32:32.480] you know, the architecture, right, you know, what are the components in that. And so one of the
[00:32:32.480 --> 00:32:37.520] things that John and I realized when we went about, you know, the tooling saga in our threat model
[00:32:37.520 --> 00:32:41.600] journey is that there's a lot of different tools, right, and there's always going to be a different
[00:32:41.600 --> 00:32:47.840] tool that's better for something else, right. So we began to focus on kind of this approach of
[00:32:47.840 --> 00:32:52.080] more like, well, you know, what are the key components, right? And then how do we, you know,
[00:32:52.080 --> 00:32:58.240] expose those to the tools and source from the tools as appropriate, right, or, you know, as context
[00:32:58.240 --> 00:33:06.960] appropriate, right? So we, so we've come up with this concept, right, of this, we basically said,
[00:33:06.960 --> 00:33:12.320] we want to describe the architecture. We would like to do this in an open source way. So we took
[00:33:12.320 --> 00:33:16.000] the word open and we took the word architecture and we put them together and now we've got the
[00:33:16.000 --> 00:33:22.720] open architecture. And so the goal here is really to say, okay, well, what does the application look
[00:33:22.720 --> 00:33:29.200] like? And to speak of the angles, we've got this entity analysis trinity, which basically says,
[00:33:29.200 --> 00:33:35.920] you know, what, what are you trying to do? What is your threat model, right? And then what are you
[00:33:35.920 --> 00:33:41.520] actually doing? And what did you write down, right? What is your code? So what is your intent at the
[00:33:41.520 --> 00:33:46.640] top of the triangle, right? What is your static analysis say? And what is your sort of behavioral
[00:33:46.640 --> 00:33:53.920] or dynamic analysis say, right? And so the objective here overall is to, you know, apply your static
[00:33:53.920 --> 00:33:58.640] analysis methodologies, apply your dynamic analysis, right? You know, maybe that's telemetry from the
[00:33:58.640 --> 00:34:02.960] field or whatever, right, to tell you about, you know, what's happening in your software,
[00:34:02.960 --> 00:34:06.800] or, you know, what does it look like when it's tested under a live, you know, dynamic scanning
[00:34:06.800 --> 00:34:11.200] environment, right? And how does that relate to your threat model, right? And so we can do that
[00:34:11.200 --> 00:34:15.920] because we can identify the different components being tested by the different tools and map them
[00:34:15.920 --> 00:34:21.200] into this, you know, open description of architecture. So yeah.
[00:34:21.200 --> 00:34:29.920] I like it. So this, this sounds like we're leading into a conversation about your open source project
[00:34:29.920 --> 00:34:36.160] that maybe we have time to work out. Oh, it's exciting. Okay. So John Andersen, specifically,
[00:34:36.160 --> 00:34:40.480] this time. So I'm going to be a little cryptic here because I'm guessing you're going to unpack
[00:34:40.480 --> 00:34:46.880] this for for me and for the listeners. But tell me about Alice. Who is Alice? And how does Alice
[00:34:46.880 --> 00:34:55.360] approach threat modeling? So Alice is right now, she's basically a CLI utility. And the funny
[00:34:55.360 --> 00:35:02.880] thing about Alice is we're hoping that eventually Alice can be her own threat model. And so we
[00:35:02.880 --> 00:35:08.560] want to define her via this open architecture, and then we want to analyze her via the open
[00:35:08.560 --> 00:35:13.200] architecture. And then what do we want to be defining? It's the analysis of other software
[00:35:13.200 --> 00:35:18.160] projects, right? So it's sort of this very recursive thing. And at the end of the day,
[00:35:18.160 --> 00:35:22.480] really what we're trying to do is round out that Trinity, right? So we're trying to have her be
[00:35:22.480 --> 00:35:27.760] able to help us identify, you know, is our threat model complete? You know, can she help us kind of
[00:35:27.760 --> 00:35:32.640] gamify that process a little bit, for example, is there encryption on that connection? Or are you
[00:35:32.640 --> 00:35:37.680] running that static analysis tool? So maybe it's actually please go run that for me. Or hey,
[00:35:37.680 --> 00:35:43.440] do you have a GitHub action CI pipeline running that every time? Because you know, my static analysis
[00:35:43.440 --> 00:35:49.040] is doubly, are you doing it? And from the life cycle perspective, do you intend on continuing to do
[00:35:49.040 --> 00:35:54.560] it? Right? And you know, because of somebody using a project, you know, I would like to know not only
[00:35:54.560 --> 00:35:58.960] that their scan is clean, but that they intend on continuing to have clean scans for the scans
[00:35:58.960 --> 00:36:05.840] that I care about. Right? So so really, Alice, as she exists today, is really, you know, this this
[00:36:05.840 --> 00:36:12.640] base from which we're trying to build out these these, this sort of data analysis control loop,
[00:36:12.640 --> 00:36:17.520] right? And that that loop is really fundamentally about, you know, measurement, where are you at?
[00:36:18.400 --> 00:36:21.760] You know, an analysis, hey, what is that? What do you,
[00:36:21.760 --> 00:36:27.760] does that conform, you know, to what or what, sorry, not, I don't want to say conform.
[00:36:27.760 --> 00:36:34.480] Does that align to what you think it should be doing? You know, what, what is your threat model
[00:36:34.480 --> 00:36:38.320] say, right? What are you hoping your code does? And then what does it actually do, right? That
[00:36:38.320 --> 00:36:46.880] dynamic analysis. Is it, is it fair to call Alice an AI tool? Alice actually, so we call Alice an AI
[00:36:46.880 --> 00:36:53.040] tool, how our Alice uses no machine learning right now. She sits within a project, which is
[00:36:53.040 --> 00:36:58.640] fundamentally about machine learning. But as security people will tell you, machine learning is a very,
[00:36:58.640 --> 00:37:04.720] very dubious, dubious thing. So yes, the entire project is centered around machine learning.
[00:37:04.720 --> 00:37:10.080] No, the reference entity does not use any machine learning today. And the reason for that will
[00:37:10.080 --> 00:37:16.720] become apparent as we begin to delve deeper and deeper into the, you know, various, yeah, the
[00:37:16.720 --> 00:37:22.000] rabbit hole of things that can go, you know, wrong with different models and, and you know,
[00:37:22.000 --> 00:37:27.360] their usages, which we will probably see next year. You know, the CVEs abound, right?
[00:37:27.360 --> 00:37:34.480] But we'll see, we'll see. John, can't, can't you call Alice AI? I think it's the A.
[00:37:34.480 --> 00:37:40.240] I think you call anything. Well, it's the A and A. That's Alice Intelligence, right? Just call
[00:37:40.240 --> 00:37:45.200] Alice Intelligence. Alice Intelligence, or we were also going with the Alice initiative, right?
[00:37:45.200 --> 00:37:49.520] Well, that's even better. Yeah, because then it's just AI by default, even if it's not ML.
[00:37:49.520 --> 00:37:52.560] Just don't read the fine print. Yeah, just
[00:37:52.560 --> 00:38:01.440] Where can our listeners learn more about Alice? They can learn about Alice on the DFFML project,
[00:38:01.440 --> 00:38:07.360] which is something that you can Google and it will only return one result. Or you can go to
[00:38:07.360 --> 00:38:16.560] the https://bit.ly/aliceoa. Fabulous. Okay. I think we've covered so, so many things and thank you both
[00:38:16.560 --> 00:38:21.840] for, for, you know, all of these insights. I think this is tremendously helpful. But I kind of wanted
[00:38:21.840 --> 00:38:27.280] to wrap it up with a kind of a fun question. When are you happiest in your work? John,
[00:38:27.280 --> 00:38:33.920] are you happy? Well, I'm happy right now. You know, I love, you know, I really love talking to
[00:38:33.920 --> 00:38:40.000] people about security, right? Because security is only as good as you put it into practice.
[00:38:40.000 --> 00:38:46.800] You know, and making others sort of think about it like we talked about, you know,
[00:38:46.800 --> 00:38:52.640] that threat modeling mindset, that attacker mindset, that, you know, the more you think
[00:38:52.640 --> 00:38:56.480] that way, the more it becomes second nature, right? And the more that you end up putting it into
[00:38:56.480 --> 00:39:05.280] practice without thinking about it, right? So, I think that, you know, sort of having that critical
[00:39:05.280 --> 00:39:11.520] mind and having those conversations where you get to sort of attack problems from different angles
[00:39:11.520 --> 00:39:16.960] is really some of the most fun part about security. Yeah, I have the good John. And if I was to wear
[00:39:16.960 --> 00:39:22.080] a Fitbit and I don't, and somebody is going to do it like a side channel attack and they're looking
[00:39:22.080 --> 00:39:26.960] where my heart rate is up and my excitement and all of that, I'm probably doing some threat
[00:39:26.960 --> 00:39:32.000] modeling at that time with some team. So yeah, it's just when you're working in security,
[00:39:32.000 --> 00:39:36.640] particularly when when teams come up to you and they ask you, you know, how can we make our product
[00:39:36.640 --> 00:39:42.240] better? How can we make it more secure? To me, that's, that puts all the worth in my job. And I'm
[00:39:42.240 --> 00:39:48.720] extremely, I'm extremely grateful for having a job that I truly enjoy and working around
[00:39:48.720 --> 00:39:55.760] such expertise as I have. There's nothing better than this. You're here. Well, likewise, I get to
[00:39:55.760 --> 00:40:00.800] talk to people like y'all. So I think this has been, this has been really fun and informative,
[00:40:00.800 --> 00:40:08.000] which is as it should be. I hope everyone enjoyed it thus far and I suspect the answer is yes.
[00:40:08.000 --> 00:40:12.720] Well, thank you so much for having us on. This was a blast. Yeah, thanks, yeah.
[00:40:12.720 --> 00:40:22.720] [Music]
DSSE (Digital Signature over Software Artifacts) and COSE (CBOR Object Signing and Encryption) are both specifications that deal with securing the integrity of data, but they serve slightly different purposes and are used in different contexts.
DSSE (Digital Signature over Software Artifacts):
DSSE is a specification designed to enable the secure signing of a variety of software artifacts, such as binaries, container images, and software bill of materials (SBOMs).
It aims to provide a single, flexible, and secure signature format for these artifacts.
DSSE is often used in the context of software supply chain security.
It is not tied to a specific serialization format and can be used with JSON, Protobuf, or any other format of the user’s choice.
DSSE is designed to be agnostic of the key management system or public key infrastructure (PKI) being used.
COSE (CBOR Object Signing and Encryption):
COSE is a specification that provides a way to sign and encrypt data that is represented in CBOR (Concise Binary Object Representation) format.
It is an IETF standard designed to work efficiently with CBOR data structures and is commonly used in constrained environments or systems with limited resources (e.g., IoT devices).
COSE defines several types of cryptographic structures like signed, MACed, encrypted, and keyed messages for CBOR.
It is similar in goal to JOSE (JSON Object Signing and Encryption), but it is specifically optimized for smaller messages and lower processing overhead.
In summary, DSSE is more focused on securing software artifacts typically in the context of DevOps and software supply chain integrity, whereas COSE is broader in terms of its application and is particularly suitable for securing data in compact and resource-constrained environments where CBOR is used.
COSE (CBOR Object Signing and Encryption) and DICE (Device Identifier Composition Engine) are two distinct technologies that could potentially interoperate to enhance the security of IoT (Internet of Things) devices and ecosystems.
COSE provides the means to create and handle encrypted or signed information structures using CBOR formatting, which is efficient in size and processing requirements for constrained devices. Mainly, COSE offers a way to protect information transmitted between devices or between devices and services.
DICE aims to establish a device's identity and ensure the integrity of its firmware/software. It uses device-specific secrets to derive unique keys, which are then leveraged to validate the boot process of a device, starting from a known immutable code that progresses through layers of trust.
Here's how they might interoperate:
Attestation and Identity: DICE could provide unique identity and attestation capabilities for an IoT device. This unique identity or attestation report could then be signed by the device using COSE-formatted signatures to ensure it has not been tampered with when being sent from the device to other entities.
Secure Communication: After the device identity is established upon boot using DICE, subsequent communications from that device could employ COSE to sign or encrypt the data being exchanged. This ensures integrity and confidentiality of the messages and helps in preventing Man-In-The-Middle (MITM) attacks.
Software Updates: Software or firmware updates that need to be securely transmitted to the device could be signed using COSE, utilizing keys derived through the DICE process. The device can then verify the signature using its derived keys before the software update is installed.
Mutual Authentication: When an IoT device (authenticated and secure through DICE measurements) communicates with a cloud service or another IoT device, it can use COSE to mutually authenticate the entities involved in the communication, therefore ensuring that both ends are verified, and trusted.
By integrating COSE with DICE, you can create a layered security approach where DICE secures the device boot and onboarding process, and COSE secures the ongoing communication and data management. This interoperation helps in building a cohesive and robust security framework suitable for resource-constrained IoT environments.
The interoperation of IETF COSE, IETF SCITT, IETF RATS, and TCG DICE represents the collaboration of various standards and frameworks each aimed at enhancing security and trustworthiness in digital systems:
IETF COSE (CBOR Object Signing and Encryption): COSE specifies how to create and process messages that are signed, MACed, encrypted, or authenticated using CBOR data structures. It's designed for constrained environments where resources like bandwidth and processing power are limited.
IETF SCITT (Supply Chain Integrity, Transparency, and Trust): SCITT focuses on providing a framework for supply chain security, one where assertions about artifacts (such as software or hardware components) can be cryptographically signed to ensure their authenticity and integrity. SCITT uses transparency logs, much like what is seen in certificate transparency practices.
IETF RATS (Remote ATtestation ProcedureS): RATS elaborates on securely attesting a device's hardware and software state (its "trustworthiness") to a remote verifier. This typically involves the creation of attestation evidence by a trusted component within the device (attester), which is then appraised by a verifier.
TCG DICE (Device Identifier Composition Engine): DICE is a TCG standard that provides a device identity and device-attestation features. When a DICE-secured device starts up, it follows a measured boot process that creates a chain of trust using device-specific secret keys and cryptographic measurements of the software being loaded.
How they might interoperate:
COSE & DICE: COSE could be used to sign and encrypt the attestation information generated through the DICE process. The cryptographic keys used by DICE for attestation purposes could leverage COSE's structures for representing and managing cryptographic material.
COSE & SCITT: When signing statements about supply chain artifacts under SCITT, COSE would be the underlying mechanism used for creating these signed assertions, ensuring they are secured appropriately for different environments.
DICE & SCITT: DICE can provide robust device identity and attestation, which can be included in SCITT's transparent statements. The claims made by a device about its software and hardware configuration, once measured and signed using DICE, can be registered in a SCITT transparency service, providing a verifiable trace of the device's state within the supply chain.
DICE & RATS: DICE can generate attestation evidence as part of a device's boot process, which then can be assessed using the procedures defined by RATS. The evidence created by DICE can include DICE-generated certificates tying hardware identity to software measurements, thus instilling confidence in the device's trustworthiness.
RATS & SCITT: The attestations or evidence generated by RATS can be encapsulated within the signed statements managed by SCITT. This could be used, for example, to assert that a particular software artifact was compiled on a trustworthy build system or that a device's firmware is authentic and untampered with.
Combining Them All: Envision a device with DICE capabilities that boot up securely and generate attestation evidence. This evidence is then signed and/or encrypted using COSE formats before being communicated over the network. The signed attestations or claims can be wrapped into a SCITT Signed Statement and entered into a transparency log. The entire chain ensures that audit, verification, and transparency are maintained throughout the process. This integrates the secure identity and attestation of hardware and software (DICE), with remote verification and attestation information exchange (RATS), all wrapped in a secure cryptographic envelope (COSE) that becomes part of the supply chain's transparency record (SCITT).
This interoperability implies a more secure ecosystem where supply chains can benefit from transparent and verifiable claims backed up by device-specific, hardware-rooted trust.
Mermaid diagram that visualizes the interaction between IETF COSE, IETF SCITT, IETF RATS, and TCG DICE:
sequenceDiagram
participant Device with DICE
participant COSE
participant SCITT Transparency Service
participant RATS Verifier
Device with DICE->>+COSE: Create attestation evidence
COSE->>+SCITT Transparency Service: Sign evidence (SCITT Signed Statement)
SCITT Transparency Service-->>-Device with DICE: Log entry (Receipt)
Device with DICE->>+RATS Verifier: Send attestation (COSE-signed)
RATS Verifier-->>-Device with DICE: Validate attestation
Note over Device with DICE,SCITT Transparency Service: DICE provides device identity and attestation
Note over COSE,RATS Verifier: COSE secures the attestation data structure
Note over SCITT Transparency Service: SCITT logs and timestamps the signed evidence
Note over RATS Verifier: RATS Verifier appraises the attestation evidence
Here's a breakdown of the steps in the diagram:
The device with DICE (Device Identifier Composition Engine) starts by creating attestation evidence for its current state.
This attestation evidence is then handed over to COSE (CBOR Object Signing and Encryption), which wraps it in a secure, signed data structure.
The COSE-signed attestation evidence is then registered with a SCITT (Supply Chain Integrity, Transparency, and Trust) Transparency Service, which adds it to its immutable log and provides a receipt for the log entry back to the device.
Separately, the device with DICE sends the attestation evidence to a RATS (Remote ATtestation Procedures) Verifier.
The RATS Verifier appraises the attestation evidence to validate the trustworthiness of the device's state.
This flow ensures that the device's attestation captures the integrity of its state which is then cryptographically secured using COSE, logged for transparency using SCITT, and can be remotely verified through RATS. Each framework plays a role in guaranteeing the security and trustworthiness of the device within a broader ecosystem.
The development of AGI (Artificial General Intelligence) in an IoT (Internet of Things) environment involves a complex interaction of data flows, model training, and execution, all of which need to be accounted for securely and transparently. The integration of frameworks like COSE, SCITT, RATS, and DICE ensures that data used to train AGI models, which may be coming from various IoT devices, is legitimate, untampered, and traceable, while the models are securely deployed and utilized across devices.
Here's a high-level view of how these could apply to AGI development:
DICE provides a secure identity for each IoT device and a measured boot process that ensures device integrity.
RATS offers mechanisms for these devices to generate attestations asserting their secure state.
COSE enables the secure signing and encryption of both the attestation information from devices (RATS) and the data sent to the AGI models, as well as the models themselves when they are distributed to devices.
SCITT provides the framework to log statements about the integrity of the AGI models and the data used for training or prediction, ensuring a verifiable supply chain for all software artifacts.
Now, let's translate this into a mermaid diagram, focusing on chaining model usage and data ingestion within an IoT environment for AGI development:
sequenceDiagram
participant IoT Device with DICE
participant Data Source
participant COSE
participant AGI Model Training
participant SCITT Transparency Service
participant RATS Verifier
participant AGI Inference
IoT Device with DICE->>+RATS Verifier: Generate and send attestation
RATS Verifier-->>-IoT Device with DICE: Verify device integrity
Data Source->>+COSE: Secure data (encrypt/sign)
COSE->>+AGI Model Training: Send secure data for training
AGI Model Training->>+SCITT Transparency Service: Log model training artifact
SCITT Transparency Service-->>-AGI Model Training: Provide Receipt
AGI Model Training->>+COSE: Secure AGI Model (encrypt/sign)
COSE->>+AGI Inference: Deploy secure AGI Model
AGI Inference->>+SCITT Transparency Service: Log model usage statement
SCITT Transparency Service-->>-AGI Inference: Provide Receipt
AGI Inference->>IoT Device with DICE: Perform inference on device
Note over IoT Device with DICE,RATS Verifier: DICE provides secure device identity & boot
Note over Data Source,AGI Model Training: Data is encrypted and signed for training
Note over SCITT Transparency Service: SCITT logs integrity artifacts for data and models
Note over AGI Inference,IoT Device with DICE: Secure model execution on verified devices
In the context of chaining model usage and data ingestion:
Each IoT device with DICE generates and sends an attestation to a RATS Verifier, ensuring its secure state before participating in the AGI environment.
Data, possibly sourced from these IoT devices, is encrypted and signed using COSE to maintain confidentiality and integrity as it's sent off for AGI model training.
The AGI training process is logged by SCITT, creating an immutable record of the model training artifacts.
Once the AGI model is trained, it is again secured using COSE for encryption and signing before being deployed across the IoT environment.
Model usage, including inference tasks performed on IoT devices, is also logged via SCITT, achieving transparency and traceability in the AGI intelligence's decision-making process.
Through this diagram, we can see how the assurance of the data and AGI model integrity across the IoT environment is maintained, thereby building a foundation of trust in the AGI's developmental processes and outputs.
The integration of federation protocols like ActivityPub with SCITT instances can decentralize the AGI development process by allowing different SCITT instances to communicate and share transparency log entries in a secure and standardized way. ActivityPub is a decentralized social networking protocol that enables different servers to interact with each other as a federated network. Here's how ActivityPub can assist within the context of AGI development:
Inter-SCITT Communication: ActivityPub can facilitate interactions between different SCITT instances across organizations or administrative domains, enabling them to exchange transparency data about model training, data provenance, and usage logs.
Model Sharing: AGI models or updates can be distributed across a network of SCITT servers, which record the metadata and hashes of these models in their respective transparency logs. This approach allows for the verification of the origin and integrity of models across different entities.
Data Provenance: As data flows from IoT devices to be ingested into AGI systems, ActivityPub can enable the decentralized tracking of data sources, transformations, and lineage by sharing signed statements and receipts between SCITT instances, ensuring traceable and reproducible data pipelines.
Accountability and Auditability: Federating transparency logs enables better accountability and decentralizes the audit process. Different actors in the network can verify logs from multiple SCITT instances, ensuring that policies have been adhered to by various entities.
Now, let’s visualize this with a detailed mermaid diagram:
sequenceDiagram
participant IoT Device with DICE
participant Data Source
participant COSE
participant AGI Model Training
participant Local SCITT Instance
participant RATS Verifier
participant AGI Inference
participant Federated SCITT Instances
participant ActivityPub Protocol
IoT Device with DICE->>+RATS Verifier: Generate and send attestation
RATS Verifier-->>-IoT Device with DICE: Verify device integrity
Data Source->>+COSE: Secure data (encrypt/sign)
COSE->>+AGI Model Training: Send secure data for training
AGI Model Training->>+Local SCITT Instance: Log model training artifact
Local SCITT Instance-->>-AGI Model Training: Provide Receipt
AGI Model Training->>+COSE: Secure AGI Model (encrypt/sign)
COSE->>+AGI Inference: Deploy secure AGI Model
AGI Inference->>+Local SCITT Instance: Log model usage statement
Local SCITT Instance-->>-AGI Inference: Provide Receipt
Local SCITT Instance->>+ActivityPub Protocol: Publish model/data logs
ActivityPub Protocol->>+Federated SCITT Instances: Disseminate logs
Federated SCITT Instances-->>-Local SCITT Instance: Acknowledge and synchronize logs
AGI Inference->>IoT Device with DICE: Perform inference on device
Note over IoT Device with DICE,RATS Verifier: DICE provides secure device identity & boot
Note over Data Source,AGI Model Training: Data is encrypted and signed for training
Note over Local SCITT Instance: Local SCITT logs integrity artifacts
Note over Federated SCITT Instances: Federation allows decentralized log management
Note over AGI Inference,IoT Device with DICE: Secure model execution on verified devices
Note over ActivityPub Protocol: ActivityPub enables federated sharing and syncing of logs
By employing ActivityPub for federating SCITT instances, we ensure that not only the data used for training AGI but also the generated AGI models and their deployment to IoT devices can be audited across different servers and organizations in a scalable and decentralized manner. This level of traceability and transparency is highly beneficial for complex systems like AGI where understanding the data and decision-making processes is crucial.
Here's a flowchart to illustrate the decentralized AGI development process with different SCITT instances using ActivityPub. Here's a Mermaid flowchart that represents the same process:
flowchart TD
D[DICE IoT Device] -->|Generate & send attestation| RV[RATS Verifier]
RV -->|Verify device integrity|D
DS[Data Source] -->|Secure data encrypt/sign| C[COSE]
C -->|Send secure data for training| AMT[AGI Model Training]
AMT -->|Log model training artifact| LSI[Local SCITT Instance]
LSI -->|Provide Receipt| AMT
AMT -->|Secure AGI model encrypt/sign| C2[COSE]
C2 -->|Deploy secure AGI model| AI[AGI Inference]
AI -->|Log model usage statement| LSI
LSI --> |Publish model/data logs| APP[ActivityPub Protocol]
APP --> |Disseminate logs| FSI[Federated SCITT Instances]
FSI --> |Acknowledge and synchronize logs| LSI
AI --> |Perform inference on device| D
classDef default fill:#f9f,stroke:#333,stroke-width:2px;
classDef device fill:#bbf,stroke:#333,stroke-width:2px;
classDef action fill:#bfb,stroke:#333,stroke-width:2px;
class D,DS device;
class RV,LSI,FSI,APP action;
Explanation of the flow graph:
DICE IoT Device (D): Represents an IoT device with DICE capabilities that start by generating and sending an attestation to validate its integrity.
RATS Verifier (RV): Acts as the entity that verifies the integrity of the IoT device based on the attestation evidence received.
Data Source (DS): Marks the origin of the data that will be ingested by the AGI system, which is first secured by COSE.
COSE (C & C2): Two instances of COSE are shown. The first secures the data from the source, and the second secures the AGI model post-training.
AGI Model Training (AMT): Indicates the process where the AGI model is trained using the secured data.
Local SCITT Instance (LSI): The entity responsible for logging model training artifacts and providing receipts for them, as well as publishing these logs via ActivityPub.
AGI Inference (AI): Depicts the deployment of the secure AGI model to perform inference operations.
ActivityPub Protocol (APP): Symbolizes the protocol used to publish and disseminate logs from the Local SCITT Instance to other instances.
Federated SCITT Instances (FSI): Stands for other SCITT instances in the federation that acknowledge and synchronize logs with the local instance.
This flow graph visually represents how each component of the decentralized AGI development process interacts with the next, emphasizing the chain of trust from IoT device attestation to secured model deployment, underpinned by transparency and auditing mechanisms afforded by COSE, SCITT, and ActivityPub.
Labeled property graphs and content-addressable ontologies can be a powerful combination for defining and enforcing policies in a system. Here's how they might work together:
Labeled Property Graphs (LPGs): In LPGs, nodes and relationships (edges) contain labels that describe their types, and properties that hold values or attributes. These are especially effective for modeling complex, interconnected data and relationships, similar to what you would find in policy rules and conditions.
Content-Addressable Ontologies: An ontology is a formal representation of knowledge as a set of concepts within a domain and the relationships between those concepts. Content-addressable ontologies enable accessing and referencing these concepts through unique identifiers (the content addresses), which typically could be cryptographic hashes of the content.
Combining the two, you can build a policy framework that uses the LPG to represent the entities, actions, and relations that are involved in your policies, with the ontology providing a structured and semantically rich knowledge base that the graph can reference to apply policy logic.
Here's how they might interact in a system:
Ontology as a Knowledge Base: Use an ontology to define the concepts and relationships that are pertinent to your policies. This could include entities such as 'user', 'device', 'action', 'resource', and relationships like 'can acce
ss', 'owns', 'part of'.
LPG for Policy Representation: Use the LPG to map out instances of those concepts and their interrelations as they pertain to specific policy scenarios. For example, which users can access which resources under what conditions.
Content Addressing for Immutability and Integrity: For each defined concept and relationship, a content address can be generated. When your policy references a concept, it's not just a static label but a pointer to a particular state of that concept at the time of the policy's creation or enforcement.
Dynamic Policy Updates: As your ontology evolves (adding new rules or modifying existing ones), new content addresses are generated. Your policies in the LPG can dynamically reference these updated concepts providing a traceable his
tory of policy changes and ensuring current policies always apply the latest rules.
Semantic Reasoning and Inferences: With content-addressable ontologies, updated knowledge can be disseminated through the system without needing to update every link manually. Policies defined in the LPG can leverage semantic reason
ing to infer new facts or constraints from the ontology and apply them to policy decisions.
Integration with Other Systems: Since ontologies and LPGs are standards-based, they can be integrated with various systems, ensuring that your policies are consistent and interoperable across different domains and services.
Querying and Enforcement: Graph databases provide powerful querying capabilities that can traverse these complex relationships efficiently. Policies can be queried dynamically based on attribute values, relationships, or even inferred knowledge, with the content addressing providing the integrity check to ensure the policies haven't been tampered with.
This system can be extremely agile and robust, providing a rich semantic grounding for your policies, a flexible and dynamic framework for policy representation, and strong guarantees about policy integrity and provenance.
To facilitate AGIs maintaining context-aware roots of trust within their local SCITT instance using labeled property graphs (LPGs), content-addressable ontologies, and federation, we need a system that integrates these elements efficiently. Alice and Bob represent two AGIs, each with their threat model and strategic principles that define how they interact within the ecosystem.
Alice's and Bob's Threat Models:
Alice's AGI prioritizes privacy and confidentiality, considering threats from data exfiltration and unauthorized access.
Bob's AGI focuses on integrity and availability, worried about data tampering and service denial.
Alice's and Bob's Strategic Principles:
Alice's strategic principles involve strict access control, minimal data sharing, and encryption-first policies.
Bob's strategic principles ensure data resilience, regular integrity checks, and failover mechanisms.
Policy Engine via LPGs:
Alice and Bob can use LPGs as a dynamic policy engine that considers the current context, their threat model, and strategic principles to evaluate incoming events. Their policy engine would need to verify that events adhere to the strategic principles while mitigating the threat model's concerns.
Let’s visualize with a flowchart how labeled property graphs combine with content addressable ontologies to assist the AGIs in maintaining context-aware roots of trust:
flowchart LR
A[AGI Alice Instance] -.->|Federation event| LPG-A[LPG & Ontologies Policy Engine A]
LPG-A -. "Evaluate against \nAlice's threat model\nand strategic principles" .-> PA[Policy Actions A]
PA -- "Aligned with\nAlice's context" --> A
A -.->|Federation request| FS-A[Federated SCITT A]
FS-A -.->|Event| B[AGI Bob Instance]
B -.->|Federation event| LPG-B[LPG & Ontologies Policy Engine B]
LPG-B -. "Evaluate against \nBob's threat model\nand strategic principles" .-> PB[Policy Actions B]
PB -- "Aligned with\nBob's context" --> B
B -.->|Federation request| FS-B[Federated SCITT B]
FS-B -.->|Event| A
A & B -.->|Local roots of trust| SC[SCITT Instances]
SC -.->|Transparent Statements| A & B
And now a sequence diagram showing the interaction between the AGIs, the LPG & Ontology-based policy engines, and SCITT instances in response to a federated event:
sequenceDiagram
participant Alice as AGI Alice Instance
participant LPGPA as LPG & Ontologies Policy Engine A
participant SCITTA as Federated SCITT A
participant SCITTB as Federated SCITT B
participant LPGPB as LPG & Ontologies Policy Engine B
participant Bob as AGI Bob Instance
Alice->>LPGPA: Evaluate event against policy
LPGPA->>Alice: Event aligns with context
Alice->>SCITTA: Publish event to federation
SCITTA->>SCITTB: Relay event to Bob
SCITTB->>Bob: Receive federated event
Bob->>LPGPB: Evaluate event against policy
LPGPB->>Bob: Event aligns with context
Bob->>Alice: Acknowledge event
In this ecosystem, Alice and Bob's AGI instances use their respective policy engines, powered by LPGs and ontologies, to process events. The policy engines determine if an event aligns with their defined strategic principles and threat models.
Policy Engine Functionality:
Event Evaluation: Upon receiving a federation event, the AGI consults its policy engine. The policy engine uses the LPG structure to map the event's attributes and content-addressable ontologies to evaluate it against the AGI's threat model and strategic principles.
Decision Making: Depending on the outcome, the policy engine triggers appropriate policy actions. Events that align with the AGI's model are allowed, and inappropriate ones are rejected or flagged.
Federation and Trust: Valid events are then published to federated SCITT instances, extending the local context-aware roots of trust to the federation. For instance, Bob's acknowledgment of Alice's event is also fed into Alice's policy engine for verification.
That way, AGIs can maintain context-aware roots of trust tailored to their operational context, privacy needs, and strategic objectives, while participating in a trusted, federated ecosystem. LPGs serve as a flexible, adaptive policy engine that can accommodate evolving AGI requirements and threats.
In the following example, Alice and Bob, have AGI systems, they are hosting their version control software (VCS) servers. They wish to utilize webhook events related to their CI/CD workflows and repository activities to enhance collaboration and maintain integrity within their poly-repo environment. By leveraging re-broadcasted webhook events and creating SCITT statements, they can collaborate securely, tracking contributions across repositories and ensuring that each action taken is transparent, traceable, and aligns with their operational context.
Setup Webhooks on VCS Servers: > - Both Alice and Bob configure their self-hosted VCS servers to send webhook events for commits, pull request (PR) updates, issue comments, and PR reviews.
Local Policy Engine Evaluation:
Each VCS server processes the incoming webhook events through the local policy engine, which references an LPG to validate against the AGI's principles and threat model.
For example, only certain types of commits or comments may be permissible depending on the source, the content, and the current context.
Generating SCITT Statements:
Events that adhere to the policy are signed and wrapped as SCITT statements, which contain relevant metadata like event type, actor, repository affected, and a content hash for data integrity.
These statements are then logged locally in the SCITT instance attached to the AGI, providing a tamper-evident record.
Re-broadcasting Events via SCITT:
The SCITT instances communicate via federation protocols (possibly adapting ActivityPub for software development use cases) to re-broadcast the verified statements to other nodes.
The LPG and content-addressable ontologies ensure that the meaning and context of these events are preserved across AGIs.
Collaboration Synchronization:
Upon receiving a federated SCITT statement, the recipient AGI's VCS server processes and reconciles the statement with local data, potentially triggering CI/CD workflows or updating the poly-repo state as necessary.
Auditability and Provenance:
Each AGI's VCS server maintains a traceable history of software development activities federated across their systems, ensuring full auditability and clear provenance for actions taken.
Here's a flowchart that takes into account CI/CD workflows and repository exchanges:
flowchart TD
subgraph Alice
SCA[SCITT Instance Alice]
VCSA[VCS Server Alice] -- webhook event: CICD workflow execution --> SSA[SCITT Statement Alice]
SSA --> PA
PA -- Log event if Alice cares and trusts --> SCA
SCA -- Trigger collaborative actions --> VCSA
end
subgraph Bob
SCB[SCITT Instance Bob]
VCSB[VCS Server Bob] -- webhook event: CICD workflow execution --> SSB[SCITT Statement Bob]
SSB --> PB
PB -- Log event if Bob cares and trusts --> SCB
SCB -- Trigger collaborative actions --> VCSB
end
SCB -- Federation event send<br>Bob statement to Alice --> PA[Policy Engine Alice]
SCA -- Federation event send<br>Alice statement to Bob --> PB[Policy Engine Bob]
classDef agi fill:#ffffff,stroke:#333,stroke-width:2px;
classDef servers fill:#f9f,stroke:#333,stroke-width:2px;
classDef engines fill:#bbf,stroke:#333,stroke-width:2px;
classDef statements fill:#bfb,stroke:#333,stroke-width:2px;
classDef scitt fill:#ff9,stroke:#333,stroke-width:2px;
class Alice,Bob agi;
class VCSA,VCSB servers;
class PA,PB engines;
class SSA,SSB statements;
class SCA,SCB scitt;
sequenceDiagram
participant VCSA as VCS Server Alice
participant PA as Policy Engine Alice
participant SSA as SCITT Statement Alice
participant SCA as SCITT Instance Alice
participant SCB as SCITT Instance Bob
participant SSB as SCITT Statement Bob
participant PB as Policy Engine Bob
participant VCSB as VCS Server Bob
VCSA->>PA: Trigger webhook event (e.g., commit)
PA->>SSA: Validate event and create SCITT Statement
SSA->>SCA: Log event to Alice's SCITT Instance
SCA->>SCB: Federate event to Bob's SCITT Instance
SCB->>VCSB: Propagate federated event
VCSB->>PB: Evaluate federated event
PB->>SSB: Validate event and create SCITT Statement
SSB->>SCB: Log event to Bob's SCITT Instance
SCB->>SCA: Federate response event to Alice's SCITT Instance
SCA->>VCSA: Propagate federated response event
In this ecosystem, webhook events from Alice's and Bob's VCS servers initiate CI/CD workflows or repository updates that are validated and captured in SCITT as transparent statements which serve as records for each repo actions, ensuring the integrity of their collaborative efforts. Federation protocols enable sharing these statements across their SCITT instances, allowing the AGIs to maintain a coherent state across poly-repos and collaborate effectively while preserving their operational and system contexts. This setup not only enhances the security posture by ensuring actions are validated and authentic, but also fosters collaboration by maintaining a shared history of contributions across their poly-repo environment.
Alice and Bob represent two advanced software systems with self-hosted version control servers. They need to safely collaborate across multiple software projects while ensuring the actions taken on their codebases are transparent and traceable.
To achieve this, they utilize a combination of modern security and networking protocols—namely, a secure logging mechanism known as SCITT, which is like a ledger to record and verify noteworthy activities, like code updates or bug comments, in a way that cannot be repudiated. Additionally, they use something called webhooks, which are automated messages sent from their version control systems when specific actions occur, such as code being committed.
Alice and Bob each have their own rules and policies that govern how they operate—a sort of strategic playbook. These policies are enforced using what is known as a policy engine, which considers contextual information. Think of it as a highly sophisticated filter that decides what activity is relevant or allowed according to their set of rules.
When Alice's system gets a webhook event, like a code update, it processes this through its policy engine, and if it passes muster, it's recorded in its SCITT ledger as a statement of action, which is like stamping "approved" on a document. Once recorded, this information can be shared with Bob's system through a federated network—a network where both systems share and recognize each other's ledgers. Bob's system undergoes a similar process, and the mutual exchange of "approved" actions allows them to collaborate effectively in their software development efforts.
By using these technologies, Alice and Bob ensure that their collaboration is not only efficient but also adheres strictly to their security requirements and strategic goals. The transparency provided by the SCITT ledger ensures a high degree of accountability and trust in their joint operations.
Draft deck for status update:
Slide 1: Collaborative AGI Development with Trusted Poly-Repo Management
Summary of the seamless, secure collaboration protocol established between AGI instances, Alice and Bob, across multiple repository environments.
Slide 2: Summary
Introduction to the need for secure, transparent collaboration between advanced software systems.
Overview of SCITT as the transparency ledger for recording and sharing approved activities.
The role of policy engines in ensuring adherence to each AGI's operational policies.
Slide 3: Poly-Repo Collaboration Overview
The collaboration challenge in a multi-repository setup.
The necessity for a system that ensures integrity and trustworthiness.
The federated system that allows sharing trusted actions across different AGIs.
Slide 4: The Core Technologies
Explanation of technologies involved:
Webhooks: Automated notifications for events like commits or comments.
Policy Engine: Filters events based on a set of predefined rules.
SCITT (Supply Chain Integrity, Transparency, and Trust): Ledger to log events.
Federation Protocols: Enable AGIs to share SCITT log entries.
Slide 5: Mechanism of Event Processing
Detailed view of the event validation process:
Capture through webhooks.
Verification against strategic rules and threat models.
Logging of events in SCITT after validation.
Re-broadcast to federated instances for synced collaboration.
Slide 6: Federated Event Sharing
Flowchart detailing inter-AGI communication:
Verification of incoming federated events.
Reflecting changes across both AGIs for synchronized development.
Slide 7: Extending Webhook Events into SCITT Logs
The process of transforming webhook events into SCITT statements.
Presentation of flowcharts showing the validation and federation of events for collaboration.
Introduction to LPGs and ontologies for managing policies.
How they ensure context-aware decisions within each AGI system.
Slide 9: Integration with Version Control Systems (VCS)
Demonstrating how AGIs integrate event handling with their VCS.
Sequence diagrams illustrating the handling and federation of webhook events.
Slide 10: Combining Technologies for a Trustworthy Development Ecosystem
Summary diagram showing the complete interaction chain from webhook capture to SCITT federation.
The role each technology plays in securing and simplifying collaborative development efforts.
Slide 11: Conclusion & Next Steps
Recap of benefits provided by the poly-repo management system.
The strategic impact on AGI development and potential areas for implementation.
Final Notes for Presenter:
While delivering the presentation, start with the broad concerns and executive summary to capture the audience’s attention. Then delve into the specific technologies, illustrating how each component of the system functions and interacts to ensure a robust collaborative development environment. Emphasize the strategic value provided by these processes in promoting transparency and efficiency. Conclude by opening the floor to questions and discussions on potential implementation strategies.
Alice and Bob can use their secure and collaborative AGI-driven environments to bootstrap further infrastructure by leveraging the verified and transparent activities in their poly-repo setup. The infrastructure expansion can include further development environments, production systems, or even extended AGI networks. Here's a high-level overview of how they might achieve this:
Infrastructure as Code (IaC): Using the reliable history of changes and actions in their VCS, Alice and Bob can create IaC scripts that define and automate the deployment of new environments, ensuring consistency and adherence to established patterns.
Continuous Integration and Deployment (CI/CD): By incorporating the SCITT statements, they can trace every aspect of CI/CD workflows, assuring that each automated build or deployment follows expected protocols and originates from verified changes.
Dynamic Environment Creation: With verified CI/CD practices, new environments (development, staging, production) can be spun up dynamically, reflecting the current state of development as logged in the federated SCITT instances.
Resource Configuration Management: Leveraging the auditable SCITT statements, they can manage configuration changes across multiple platforms. This provides a foundation for synchronizing settings and updates in a decentralized manner while ensuring trust.
Security Policy Enforcement: Using the policy engines and the SCITT infrastructure, Alice and Bob can enforce security policies and compliance requirements as part of the bootstrapping process. These policies ensure that the newly created infrastructure adheres to the same security standards as existing systems.
Automated Verification and Consistency: Newly bootstrapped environments can automatically be checked against the SCITT statements and LPG-driven policies to ensure they align with the agreed-upon standards and operational context.
Collaborative Multi-AGI Operations: As new AGI instances might be part of the expanded infrastructure, these can be integrated into the existing federation, extending the network of trust and allowing for seamless collaboration across a broader AGI ecosystem.
Monitoring and Auditing: Continuous monitoring systems can be set up following the same principles, where anomalies or non-compliant changes trigger alerts and are logged as SCITT statements for audit purposes.
Detailed steps in the bootstrapping process might look like this:
Step 1: Evaluate current repository states and CI/CD pipelines using the local SCITT instance data.
Step 2: Define the necessary infrastructure setups and configurations as code.
Step 3: Run IaC scripts through the policy engine to ensure compliance and security.
Step 4: Execute IaC scripts to provision and configure the new infrastructure.
Step 5: Each action taken by the IaC tooling generates webhook events, which are processed into SCITT statements for an immutable record.
Step 6: Validate the health and policy adherence of the new infrastructure against SCITT statements.
Step 7: Integrate new environments into the AGIs' operational processes, such as monitoring and federated event handling.
By using SCITT as a backbone for trust and verification, the AGIs can ensure that the expansion of their infrastructure is not only swift and consistent but also maintains the integrity and security needed for reliable AGI development and operations.
SCITT can be integrated with Kubernetes to provide a high-integrity log of state changes and serve as a policy decision point for admission control. This integration ensures that all changes within the Kubernetes cluster are authorized, logged, and verifiable.
The integration could work as follows:
Admission Control: A Kubernetes admission controller is deployed that intercepts requests to the Kubernetes API server. Before any creation, update, or deletion of resources within the cluster, the admission controller sends the request details to the policy engine.
Policy Engine Evaluation: The policy engine, guided by SCITT statements and organizational policies, evaluates the request to ensure it complies with the predefined security standards and operational practices.
SCITT Logging: Upon successful policy evaluation, a SCITT statement is generated to log the change. The SCITT statement captures the what, who, when, and how of the requested change, offering complete traceability.
Approval and Logging: If the request passes the policy engine's evaluation, the admission controller allows it, and the action is logged in SCITT as an immutable record. If it's denied, the request is rejected, and the attempted change is also logged for audit purposes.
State Watcher: A Kubernetes watcher service tracks changes to cluster state and generates SCITT statements that log these changes. These statements serve as a tamper-evident timeline of cluster events.
State Change Validation: For requests that result in changes, follow-up checks validate that the state of the cluster reflects what was approved, ensuring no unauthorized modifications slipped through.
Here is a mermaid diagram visualizing this process:
sequenceDiagram
participant User as User/API Client
participant AC as Admission Controller
participant PE as Policy Engine
participant SL as SCITT Logger
participant KS as Kubernetes Server
participant KW as Kubernetes Watcher
User->>AC: Request to create/update/delete resource
AC->>PE: Evaluate request against policies
PE-->>AC: Approval/Rejection
AC-->>User: Admission decision
AC->>SL: Generate SCITT statement (if approved)
SL->>SL: Log SCITT statement
AC->>KS: Apply approved changes (if any)
KS->>KW: Notify of state changes
KW->>SL: Generate SCITT statements for state changes
SL->>SL: Log SCITT statement
In this sequence:
User/API Client sends a resource management request to Kubernetes.
Admission Controller captures the request and queries the Policy Engine.
Policy Engine approves or rejects based on current policies and logs the action as a SCITT Statement via the SCITT Logger.
Kubernetes Server applies the changes if approved.
Kubernetes Watcher monitors cluster state changes and logs them as SCITT statements.
SCITT Logger maintains a tamper-evident ledger of statements for auditing.
By integrating SCITT with Kubernetes, Alice and Bob can ensure that the cluster's state always reflects approved and validated states from their CI/CD workflows, maintaining security and consistency across their development operations. This integration also creates an audit trail for all changes, providing complete visibility into cluster events and enabling rapid response to potential policy violations.
https://github.com/intel/dffml/blob/alice/docs/tutorials/rolling_alice/0000_architecting_alice/0004_writing_the_wave.md
$ for file in $(cat transcript.txt); do echo "# ${file}" | tee "${file}.md"; time python -uc 'import sys, whisper; print(whisper.load_model("medium.en").transcribe(sys.argv[-1], language="en")["text"])' "${file}" | tee -a "${file}.md"; git add "${file}.md" && git commit -sm "${file}" && git push -fu origin main; done