 Here we are going to try and give a talk. So the title of this talk, Graphical Representations of Security Relationships, are they awesome or are they bullshit? You probably already formed a strong opinion by this point in my screw ups. So here we go. By the way, I like doing presentations just with plain HTML. I can't believe how many hacker cons I go to and people are using PowerPoint. I was in the speaker green room before we got started and EFF people were there getting ready for their panel, which is going on simultaneously. And one of them actually said, although she admitted this was not her original quote, she was citing it with fair usage in mind, she said power corrupts and PowerPoint corrupts absolutely. So the beginning is this. We have this problem of collecting huge amounts of information and that's not rare in the security scene, right? You run a Nessus scan, you see a ton of kilopages of output, you're running a SysLog server, you get a ton of stuff, and how many people attended Rafael Marty's talk on Afterglow? All right. That was a fantastic talk and he's smarter than I am, but I'm going to do some different things based on some of his work. So we have the problem of large collections of information and we have two issues here. One is let's say you look at a Nessus scan of a network and you get, you know, a lot of information. There's two problems. The first one is does any particular piece of information in that scan output make sense to you? That's hard to say. And then the second thing is do these two pieces of information go together? And that's hard to say too. One of the problems with vulnerability scanners in general, of course, is that they look at each system that they scan as just its world unto itself. They don't understand that they participate in a whole environment. They don't know what kinds of things are important about them and so forth. And so we're going to try to do, see what we can do about taking the information that they give us and making it more useful. So this is a picture of someone who believes that vulnerability scanners actually describe the security of their network. You can see he's got a seat reserved there on the bus. So we have seen recently some efforts to come up with solutions to these problems. We've seen a lot of security information management systems, things that do log aggregation, event roll-up, some kind of analysis of the patterns that they see. And that's all great. And then we also have seen in the non-product side of efforts to fix this problem or address this issue, we've seen two sort of parallel efforts. One is the increased emphasis on threat modeling and I'm not a big zealot about fancy methodologies and producing documentation just so. When I talk about threat modeling, what I really mean usually is just being organized and consistent about how we describe things and rate them and rank them so that we are internally able to make apples-to-apples comparisons, even though maybe nobody else in the world understands what we're talking about. So basically formal processes in place to make sure we're being thorough and we're being systematic about the way we describe risk. The second thing that we've seen getting a lot of attention lately are these operational frameworks. ITIL, COVID, ISO 17799 or 27001 if you like fancier numbers. Or the incident command system for incident handling, these are things that are trying to make responses to situations predictable and minimize risk through process. So those are two ways, basically they're saying, hey, we can't really predict what kind of information we're going to gather, but we know we're going to have the same plan no matter what information we gather. These are the steps we're going to follow. All right, so what's our goal here? So there's no shortage of information and in the aftermath of the 9-11 attacks a lot of intelligence agencies said that the problem was not that they didn't have data about what was going on, they couldn't go through all of it. So we're going to try to find ways to organize the information that we collect in a way that it actually supports decision making and just visualization is probably not enough. So we're going to make two observations here. The first thing is that security is not necessarily as hard as it sounds. When people talk about security it always seems really mysterious, but sometimes that's just this perception of complexity and maybe we can do some things to reduce that. The second thing is to note that the same set of data might contain multiple messages that are interesting to us. So for example, here's a little puzzle. If you saw this sequence of numbers, would you know what the next number is? Well what if you saw it organized like this? Same sequence of numbers, but you're pretty good at guessing what comes after the two now. So sometimes just the way we look at the information we see can be very helpful to us in terms of putting it in some sort of context for us. So now we're going to make the transition to the scary math portion of the presentation and we're going to talk briefly about graph theories. And so we're going to define what a graph is and I don't mean things like bar charts and stuff like that. I'm talking about mathematical graphs which are sets of two kinds of things. The first is what we call a vertex or a node, a thing on the graph. And then the edge is just a connection between any two vertices. And I'm going to, so you can have connections that are one way only. I'm only going to work with two way connections just to keep things simple. If you can go one direction, you can go the other direction on the graphs. So this is how we write it. A graph is a union of two things, a set of vertices and a set of edges. Fine, that's all very interesting. So here, let's look at one. Here we have a graph with five nodes on it. So their set of vertices is one, two, three, four, and five. And then we're going to define some edges as just basically the pairs of vertices that are connected. So you can see that there is an edge from one to two on that graph, right? And from one to four. So that's an example of a graph the way we describe it here. All right, so familiar graphs you might remember, right? Routing tables, spanning tree descriptions. Those are graphs that we're familiar with in the networking world. If you do software development, things like entity relationship diagrams, object relational diagrams, those are the sorts of things that you might encounter. Those are also represented mathematically as graphs. And then in regular life, you might think of subway or metromats. So the nodes are the subway stations and then the edges are the subway lines that you could take in between them. All right, swell. So now we're getting to the point where we can say what the title of the talk comes from. I did some work for an educational institution. And they wanted, one of the things that they wanted was a map of their network. And it was a large national network. It was confusing and they had lost track of it. So they wanted to know where it was and what was connected to what. And so I built a tool for doing this using these graphs, right? So we have two types of nodes. We have routers, which are one type of node. And then a net block, like 192.168.0.0 slash 8. So that would be a net block. So we got those two types of nodes. And then an edge is just a connection between a router and a net block, okay? So is directly connected to it. So if you did it on a Cisco router, show IP route, and this net block is connected directly, that would be an edge. Fine. So we have this little snippet of code courtesy of P monkey in the front row. P monkey stand up and say hi to the nice people. This is just a little, a little, a little, yeah, yeah, he's a sweetie. A little thing for just walking through routers, grabbing via SNMP their routing tables. And you can just run this on your network. And what we're gonna do is take the, the output of those things. And we're going to massage it a little bit. We're going to take every network that is directly connected, and we're going to put it into a file. The contents of which are the list of networks directly connected to the router. And the name of that file is just something that helps us identify the router, like 10.1.10.1 was a router. So we call it that. Super. So what do we get? Let's talk a little bit about graphs again. We can take the same graph that we saw earlier and represent it in a language called dot, which is just basically a language for describing the way a graph is. So you see we define our vertices, one, two, three, four, five, and our edges, one to two, two to three, two to four, three to five, and so forth. And then we can use something like graph vis to render that into the image that you see on the right there. Dot language is something that Afterglow works with, and so forth. And that's where I got the idea of doing things this way. And then this is the, so this is the command line that you use to generate that graph from the dot file on the left. Mine's super amazing. So this is the graph that we got for that network. And it's horribly disgusting in this format. And on my laptop, I have a tool that I can zoom in on it. So I'm gonna see if I can do that here. Note my one-handed Windows skills. No previews, please, just this. Let's see if we can see it a little larger. I have a magnifying glass over here. So let's just zoom in on a portion of the graph. And it's not liking me. But you can believe me, or not, that each of the red things, oh, pretty. All right, so the red objects are the net blocks. And the green objects are the routers. I colored the internet yellow so that we could see where the connections are. And this is kind of fun. And so I was very proud of this tool and I wanted to show it off. And so I sent it to a mailing list internal to my company about how swell Cisco networking technology is. And I sent it to that hoping that everyone would be very happy with me and praise me. And I got exactly two responses from the two engineers that I like and respect most of the company. And one of them said, this is awesome. I want to use this all the time. And the other one said, this is bullshit. It doesn't tell me anything. And so that's why we're calling the talk this. So now we come to the central question. Is this awesome or is it bullshit? So I think there are points to be made on either side. On the awesome side, this has very strong nerd appeal, right? We can all agree that there's a simple image here and it's summarizing a great deal of data. And that's kind of cool. And so you could, if you had a magnifying glass and a sufficient patience, you could find any piece of information that you were interested in there. This is a whole lot easier than drawing that whole mess out by Visio. And it's cheap too because the software is free and it's on your CD. You can just have it. However, on the opposing side, it looks just like a spirograph. It doesn't really convey any message. It doesn't support any conclusion, right? So the engineer who said bullshit said it's better to summarize data that's redundant or repetitive. You saw like 96 sites that looked exactly the same. They all had four netlocks hanging off of them. You probably all noticed that, right? And so graphs like this might actually distract from the information that you're trying to find and it might minimize the importance of problems. And that's not what we want when we're trying to make a point about security. All right. So let's talk a little bit about what my central theme here is. I'm really interested, I'm kind of obsessed with trust between systems. And so this is a quote from Halvar. And he's saying that almost all real hacking is done via transitive trust, which is you break into one system and having that degree of access gets you into another one. And he says my favorite quote, transitive trust and real hacking gets too little credit at security conferences. I'm on a personal mission to change that and have been for some years now. Another quote that I wanted to cite was from my colleague Sherd Lou over at the side of the room. She was participating in a discussion with Steve Christie from MITRE. He asked a question, what is the state of vulnerability research? And the very excellent point was made that really what we consider vulnerability research is generally not research the way formal academic research is. And there should be maybe some degree of emphasis on trying to make this a little bit more rigorous. And I like that point. I also am sick of the idea of just data for its own sake. And that's what's wrong with the spirograph graph, right? So this is an old essay from Bruce Schneier when he's trying to make the point that counterpain is cool. So 41% of the attacks we saw were unauthorized activity of some kind. Well, as opposed to this, you know, 59% of authorized attacks, I'm not sure. 21% were scanning. What does this information do for you? What do you make out of that? How does that help you live your life better? So I also cite a number of different sources. One is Dan Burrow's talk from DEF CON 9, which introduced me to the idea that you could actually do math on data that you collect. The second one is a research that I'm familiar with from the UW Madison near my hometown. And this is a person who does computation on graphs, trying to do computation on graphs that represent attack patterns. I'm not doing fancy model checking, which is this strange algebra on top of the graphs. I don't bother with scary stuff like that. Rafael Marty's talk at DEF CON 13 blew my mind, and that made me want to start drawing pictures. And then Keos Gelobitsky's talk at Lisa 05 on using automated tools to draw security conclusions, specifically computing attack surfaces. This is really interesting stuff. I recommend all of these pieces of research to you if you are having trouble sleeping and just want to know more about this stuff. So we have a number of tools previously released that we have incremental advances to. All of these are available from Fufas.net. The latest revision of OWNR is not up there yet. I'll put it up when I get back. Basically, this is just a net bios information gathering tool. It's sort of general purpose. And the nice thing about it is that it puts things out in comma-separated files or character-separated files so that you can quickly find things in them using grep and cut, which is my favorite. Everybody should have a favorite UNIX utility minus cut. We've made some improvements since it was shown then. It's actually thread safe, so we can do multi-threaded analysis. We've improved the Active Directory functionality and so forth. It's fun. Another tool is FGDump, written by Fizgig down in the front row. Fizgig, stand up and say hi to the nice people. This is a replacement for PWDump. It is way better. Fizgig also released PWDump 6, but it is superseded by FGDump. It is smart enough to do things like turn off antivirus and antispyware things that it encounters so you don't dust the machine that you're trying to dump passwords out of. It does a lot of nice stuff. So it was initially released to Turcon 7. There was a much better release around Christmas time, right? Yeah. So it's very nice. It's a sort of Swiss Army knife password dumping tool as it gets cached passwords and password history and stuff like that. Very fun. Another one is Medusa, written by Jomokun, who is not in the room. He's off seeing the EFF and I'm gravely insulted. It's just a good password grinder. It's a replacement for Hydra from THC, but it's designed specifically for giant multi-threading. It's very modular and you should get it and you'll love it. All right. So where are we? We're back to our matrix here, our graph here. So we've seen the dot representation of that graph. We've seen the visual representation of the graph. We can also have a mathematical one. So we're going to make ourselves a little matrix and the edge columns are just labels, right? One, two, three, four, and five. And one, two, three, four, and five down the sides. And what's interesting is the cells in there. Can I highlight this? Well, not really. Anyway, so rows like this. So for each cell, what we do is if there is a connection between node one and, say, node two, we're going to put a one in that cell. And if there isn't a connection between, say, node one and node three, we're going to put a zero in that cell. And when we say connection, we mean just direct connection. They're right next door to each other, okay? So what's called an adjacency matrix. It's a matrix of just ones and zeros. And the ones I draw always have ones down the diagonal. If that's just a style point, you can do it differently if you like. So if you're on one, you can get to one, in other words. Super. Okay, so we can represent the matrix that way, or the graph that way. We can also multiply matrices together. These are two notations for doing that. The top one is sort of more like you would write a program to do it. The bottom one is what's called Einstein notation. That's named after some guy. And so the original adjacency matrix shows paths of length one, right? If we square that matrix, if we multiply it by itself, we'll see where there are paths of length two. So any place that there is a non-zero entry in one of these rows, it means there's a path of length two between these two things. In other words, this is a totally connected matrix. There are no zero nodes in here at all. From any one node, you can get any place else. And you can see that just visually inspecting it, right? There's nobody that's isolated on there. All right, so a little bit more math, and we'll be home free. So you'll notice you'll remember from your algebra classes, right? The geometric series there. You have this polynomial one over one minus x. If you actually were to take a piece of paper and divide that out, you'd get one plus x plus x squared plus x cubed. And so on to infinity. You can do the same thing with matrices. The identity matrix, which is depicted down here, is just a matrix that's all zeros with ones down the diagonal. And we'll represent that as i. So i over i minus r matrix gives us the geometric series for matrices. So one plus m plus m squared plus m cubed m is our matrix. And what this allows us to do is compute something called closure or transitive closure on our graph. In other words, we can take an individual adjacency matrix and we can say, regardless of the length of the path, can you get here from there? And so if you have a zero in a row in that matrix, you can't get there. And if you have anything else, you can get there. So if we had a way of building matrices, we could quickly compute the set of nodes that are accessible on a network. So the set of non-zero elements. And that might be awesome. And not bullshit. We'll see. So here's how I've been going about it. I take a number of different tools, OWNR, together, user account information. Nessus gives me information about vulnerabilities on systems. FGDump grabs passwords for me. Medusa sees if those passwords work anyplace else that I haven't touched. And what we do is we build ourselves an adjacency matrix out of that. So an adjacency matrix is, oh, there's Dan. Great talk. So an adjacency matrix out of this. So what we're going to do is anytime we have passwords from a system and you have a user account and password that is repeated on another system. So system A has user patent. Oh, that's me. I outed myself, damn. User Fufus is on system A. And then user Fufus is also on system B. And the two passwords match. We're going to describe those two systems as adjacent. And this is Halver's idea of transitive trust. You hack one, you get to log into the other one for free. All right. So we're going to build an adjacency matrix out of that. And on your CD, you have a tool for doing that. And what I have been doing is then doing some cleanup. If you have multiple domain controllers on a network, you want to prune those out and reduce it to just one because they're the same anyway, et cetera. And we're going to convert that to dot language and we're going to draw a picture of it. And that's going to be cool. And everyone's going to think we're neat. So this is a school district measured this way. And again, we have the same problem that we did with our other graph. Let's get rid of this. And let's bring up this guy. So here we've got about 312 different systems which are represented by the blue ovals. Those are computers. And the orange rectangles represent connections between those computers. So if we keep zooming in, you'll see, come on, we just want to get to the point where it's legible. So what you'd see is IP addresses inside the blue kind of circles. And then inside the orange rectangles, you would see a username and a password hash that match between those two systems. And that's kind of neat because what we can see all of a sudden is that we've got 314 systems on this graph. 312 of them are connected by some kind of transit of trust. So in other words, if you hack one, you can basically romp all over the whole darn place. And what's sort of a couple of interesting points, one is, oh, wake up laptop. Well, you saw there was a big sort of soccer ball shaped circle of nodes surrounding one account which we're trying to get over to. That account happens to be named administrator. That's a password shared between, I don't know, a couple hundred systems. Let's just go back to the other view and you'll just believe me that this is true. Also, you'll see that down here there's a yellow octagon. If you have good enough eyes in this resolution, you might be able to see right there is a yellow octagon. That represents the domain controllers. And so basically there are, if you hack any one of these systems, you can get to all of them including the domain. And that's kind of significant for their security. They thought that all they had to do was keep the domain controllers secure, but it turns out that the project of keeping their network secure is equivalent to the project of keeping all 314 systems on it secure. If one falls, they all fall. So that was kind of fun, but that graph really only conveys one message which is you are owned. It does not help with anything else. And we want to see if we can't make it tell us more interesting things. So I call it, this is somewhat bullshit, even though it was fun to make. So here's a little intermission for you. What do you think of this graph? This is from Greg Hogland and Gary McGraw's book, Exploiting Software. And I just love the caption here. This graph is rendered in three dimensions. First off, no it's not, it's sitting right there on my screen. Each node location, each code location looks like a small room. I don't know what kind of rooms they live in, but we use the OpenGL package to illustrate all the code paths leading toward a vulnerable Sprint F call in a target program. So let us just assume, they don't label it or anything clever like that, but let's just assume that this is the vulnerable Sprint F call because everything seems to sort of be leading there. What are we to make of this graph? What on earth does it tell us? What is this room which is not connected to anything? So what do you say? Awesome? Yeah, maybe. This is what I think. And I have nothing against this field. It's a fine book, but that graph just blew me away. Okay, so let's see if we can start to make more sense here. The ISO 17799 standard is just a framework which claims to identify all of the stuff you ought to be doing if you are running your network well. It divides the project of running an organization up into 11 areas and then those areas are subdivided into what are called objectives, so you have about 140 objectives. So that's that standard. We're going to use another standard, too, which is NIST 800-26 because they are just totally into sexy titles over at NIST 800-26. Guide to self-assessment of networks. And they define a scale from 1 to 5 about how far along you are in terms of making progress towards security virtue. Have you written a policy? Have you actually written a procedure for how you're going to execute on that policy? Are you doing that procedure? Have you put things in there so that you're testing to see if the procedure works? And then when you find that it's failed, do you have a procedure for taking steps to learn from that problem and making progress? We've added a level zero, which means, holy cow, we never even thought of that yet. So we're going to take these two ideas and you see I've assigned color codes to them. NIST did not bother to color these things. What we're going to do is take those 11 areas and we're going to represent for an organization, we're going to say where are they on that NIST scale for each of the 140 objectives. And we're going to recognize the hierarchical organization of that standard. So we have the standard 11 areas and 140 objectives distributed among those 11 areas. And what we're going to do is color each of those objectives based on their NIST ranking. And then we're going to draw a picture of that. How do we do this for ourselves at home? Oh, yeah, another free tool that's on your CD. This is the kind of picture we get. So you can see the central, here's the standard. The color codes represent how we're doing. And what I do is for every area where there is something that's not ideal, for every objective that's not ideal, the area represented by it gets sort of a lowest common denominator. So we have one orange, this area turns orange. And this is a way of sort of visually representing how you're doing along with the ISO standard. It's a nice way to measure progress. I don't really care much about ISO certification, but this is a way of showing sort of what's holding you back in your organization and what things might be going better. All right, so that actually I claim represents something interesting. It helps you support a conclusion. It tells you where to focus your effort and so forth. Now the old plan was kind of cumbersome. It didn't provide much organization of our information. That's that school district graph I showed earlier. It didn't really support multiple views of the data. We know we might want to visualize things more than one way. So we have a new plan. We're going to decouple the description of the data from the analysis of the data. And I'll tell you what I mean in just a moment. I'm also, I used to run things through Afterglow to generate my .files. I'm ditching Afterglow, not because Afterglow is superior to my work in every way, but just because it's designed for a specific purpose and I want to be more granular with the way I manage .. So what we're going to do is harvest our raw data, the same as we used to except that the tools are fancier now. We're going to render those into adjacency files with this map adjacencies program, which is on your CD. And we're going to do this in two ways. We're going to represent an adjacency matrix and also adjacency lists, just two equivalent representations of the same information. Now we can write simple scripts that just process those lists. Where can I get to from this node? What user account is connected to the most things and stuff like that. We can start making more interesting pictures. So we have that radiating view like we just saw with the ISO standard. We can also rank things. This is, I'm going to see if we can't ditch that. Get ourselves one more picture. We can also draw things ranked as trees. This is a manufacturing company. Hopefully this one will zoom in a little faster than the others. Draw a box. Oh, draw a box. I don't know how to draw a box. All right, all you box masters out there are better than me. So anyway, what's interesting here is we see that this system up at the top, from there you can get to one system. From this one you're connected to just about everything. All of these are interconnected. That goes down to another stratum. And then what's interesting here is that the farthest away, what this shows us on this network, is the farthest away you can be is one, two, three, four hops. Within four hops you're every place on this network. And I think that's a sort of more interestingly organized presentation of the same kind of information we had before. It actually supports some kinds of decision making. What if we isolated this system, then everyone would be safe against attack from that? Or what is this one account that's shared between all of these? Maybe we could get rid of that. I think those are the sorts of things that will help us actually make progress. All right, now. The way I signed the rank for the top system, that's a great question. What I did was I picked the system that I was interested in, and I said that's the top system. But seriously, that's actually the point of this. I want to be able to interrogate this data in ways that are interesting to me. I want to be able to ask questions about it. I'm interested in that one top system, and I want to know about it. That's the glory of decoupling the rendering into adjacency files from the analysis of those adjacency files. I can write a thing that says, well, for any given host, what can I learn about it? And that's... So I don't know who asked that question, but that was a good question, and thank you. All right. So this is a familiar graph, which I stole from Counterpane. This is what's called an attack tree. And the goal... Basically, the goal here is, you know, I want to open a safe. So what are the different ways that could happen? I could pick the lock. I could learn the combination. Well, how might I learn the combination? I might find it written down. I might get it from somebody. How might I get it? Well, I might threaten them, or I might eavesdrop on them, et cetera. So this is a way of sort of modeling your adversaries' decision-making process. And what I'm hoping is that graphs like this can actually model, well, if this is the system we're interested in keeping safe, what are all the ways you could get to it? And that's a sort of interesting question, I think, to be able to ask and answer. All right. All right. So we can start asking things like, can we rank hosts in order of their security importance? So things that are directly connected to other things versus things that are connected indirectly. Can we... If we know where... what we're interested in protecting, can we say all of the different paths to it are transitive trust? Those are the sorts of questions I'm hoping we'll be able to answer with our new fangled tools. And then you have this idea of degrees of separation on the network, emphasizing the importance of one central system that's... or central account that's connected to all others. All right. So how does this line up in terms of what we actually are experiencing in the world? Here's the old window of vulnerability problem. Right? You have... you have to think about risk in terms of dollars per year, right? Annual rate of occurrence of security incidents versus, you know, the cost of a single security incident, single loss expectancy. And when you have a security solution, most products that people notice, security vendors never sell you a product. They sell you a solution. When they sell you this solution, what they're really focusing on usually is reducing the frequency of security incidents. So we buy a countermeasure that is supposed to make it impossible for certain things to happen to us. But so what's interesting about this graph, which is this is sort of trying to model the way the big internet worms of the early part of this decade happened, you'd have always some background noise of systems getting compromised. And then someone would figure out something was wrong with the system. They'd learn how to hack it. Stuff would start getting owned. Usually a patch would get introduced, but nobody paid attention to it. Then someone would automate the exploit and things would go through the roof. Then we'd start patching. And then most things would get patched over time. But it never all gets patched, right? If you run a web server and you look in your logs, you still see code red sweep through a couple times a year. Or a couple times a month, pardon me. And it never was zero to begin with. The people finding the ODes make sure there are always systems getting hacked and we don't know what's going on with them. That's alien technology that we don't know about. So what's interesting about this is we can start thinking in terms of not just the rate of occurrence of security incidents, but we can start minimizing the consequences of them by reducing connections between systems so that when one gets owned it doesn't cascade into a failure of our whole network. Because we can spot which are the strategic connections strategic trust connections between systems. Alright. So we're talking about minimizing the consequences of security incidents. We're not just reducing their occurrence. Isolating things better and with more more confidence than we could before because we can spot some of these relationships. Hopefully this is good also for spotting single points of failure in our defenses. The whole well, if one of these systems gets hacked they all are a problem. Hopefully this is good for spotting those things. And then hopefully it's also giving us clear understanding of the effects of the security decisions we make. Again, we're able to start thinking about defending against attacks we don't know about yet. We don't care how system X gets compromised. We just want to know that when it does what are the consequences to us. And we can also start combining this data with information from vulnerability scanners so we can take our Nessus output and color the hosts on those graphs differently depending on what vulnerabilities they have, things like that. So again, there's no shortage of security information is trying to make it easier to synthesize it together and to use it intelligently. And we've got plenty of work left for me to do. I need to start fixing bugs in the code that I've written. I need to re-implement the matrix multiplication stuff. I currently have been doing that in the language J which is very confusing. I don't know if any of you speak APL. J is a sort of next generation APL. I need to port that to Perl so that humans can read it. And I basically am going to just keep releasing scripts for doing certain kinds of pictures and that's going to be ways of slicing and dicing that information that we've gathered in more interesting ways. Alright, and we've got just libraries full of graph theory that we can take advantage of and maybe use people who have been proving theorems for centuries and these actually suddenly have applications to making security decisions. That transitive closure equation is a nice one for us. Alright, so some credits I use GraphViz, I worship Afterglow. There are two books that I would strongly recommend. The Graphs and Networks book is all you need to know about graph theory. The Algorithms book is a way of traversing those graphs. There's lots of good stuff in there. There are some tools that are not bundled on the CD, OWNR, Medusa, FGDump, those are available from FooFist.net, greets to my peoples. And everybody likes a prize so valuable prizes await people who solve the following problems. Right now Medusa does not run under SIG Win. If you get Medusa to run under SIG Win and explain to us how it was done, we will do something nice for you. Let me know. Also, I have been trying to use the LSA enumerate accounts with user write API call to enumerate users. The SDK used to say you could do that and I know that sounds like a crazy idea. Just enumerating accounts with an API called enumerate accounts. But it doesn't work. It doesn't work the way it's supposed to at least. It doesn't work the way the docs say. Now, I noticed about a week before I came here that Microsoft has revised the docs and it no longer says explicitly that you can do that. It hints that you can but they're being a little bit cagey about it. If anyone makes a program that actually in C or C++ that can enumerate all users on a system using that API call, let me know. That is the material that I came with. I note that I am actually five minutes, I believe, ahead of schedule. I would love to take questions. I apologize for the delays at the start and I also apologize that I couldn't show more interesting graphs porting from one computer to another. All of a sudden was an unexpected thing. Special thanks to this is FooFist of FooFist.com. It's amazing that there are two people in this program that we should meet at DEF CON is doubly amazing. But he loaned me his laptop and thank you, man. If there are questions I would love to entertain them. If not, I recognize it's DEF CON on a Sunday. Everybody is half asleep. Yes, sir. Let's let him and then you're next. Yes. Right. Okay. So the question is can we use these same principles at design time? I think the principles are very important. Usually when I get to look at a system it's already out there in the world. I haven't done that work. Certainly you could draw connectivity graphs of things that don't yet exist. I guess the utility that I've perceived in what I'm doing is the ability to spot connections and things that do exist. So at design time you're doing it basically it would be an on paper exercise. I think you could do that. Until it exists it's not really rigorous because even the best plan can be bungled in implementation and when you're talking at design time you're only talking about planning stuff. Yes, sir. So have you thought about taking your graph data and piping it into some really cool interactive graph exploration sort of tools? Yeah, exactly. I've played with LGL a little bit through look. Most of this I do for putting in documentation though and so two dimensional static representation has been my favorite. It's totally compatible with that. The dot language is very flexible and you can represent that in a variety of different things. I've been using graph vis but if you like fancy twinkles go for it. Yes, sir. Have you considered doing directed graphs where you can represent things like firewalls and stuff like that? Yes, so as I mentioned before all the graphs that I'm drawing are undirected which means every connection goes two ways. It is possible to think in terms of one way connections. What I'm focusing on right now is transitive trust relationships or implied trust relationships. Most of those are two ways so I haven't bothered with it but yeah in terms of the dot syntax all you do is instead of saying graph and so the facility exists it just hasn't been something that I've focused on yet. What about waiting the cost to go through and then trying to analyze that to see how hard is it to get to a particular node from say the internet? That is interesting stuff and I encourage you to collaborate with me on this research. One thing there that if we look back at this tree example one of the interesting things here the graphs that I'm looking at are what I would call highly cyclic graphs there are usually sort of loops that you can go through in multiple paths between things and one of the things that I'm interested in doing is implementing like an open shortest path first algorithm so that we can do things like wait what is the quickest way from point A to point B on the graph. I'm not doing that yet but that is something that I certainly intend on doing. Again those are all algorithms that exist maybe I'm not smart with math if you want to talk to me later I'd love to learn what that is. Can I draw a correlation matrix instead of an adjacency matrix? I assume I can. Yes smarter person says yes I don't know what it is though. Thank you very much. You've been very patient.