So this is hacking dot net applications at run time. I'm John McCoy and this is Daniel DeFries. So going after dot net at run time is using reflection to activate the functionality inside of a dot net program. This is legitimate inside of the dot net framework. It's functionality inherent. This is part of a run time language. If you go to something like Java or other run intermediate languages that have CLR, you'll find this basic same functionality. This allows us to reflectively look at objects and edit them at run time and we're going to exploit this to make a dot net application malleable to not only change the value and state of it but to literally change the logic flow. We're not going to be attacking code, we're going to be attacking the run time itself. So this presentation will be covering accessing running dot net programs, attacking the run time structure, the weak points to go after when you attack a program, and some tools that we're going to be releasing. So the tools that you'll be getting is dot net exploit. This is a framework and payload system with a management area as well as the standard deliver package or payloads. So it's easy to reuse and hopefully people want to develop for it. Metasploit payload that will work with the delivery system that will be arbitrary. And this will be a standard Metasploit delivered to SQL Server Management Studio. And we'll demo that towards the end, hopefully you'll like it. And we also found some really nice extras when we were doing this research. We're going to be leveraging an old Visual Studios exploit as well as showing some decompilation that will get around some of the protection that you might run up against when you're trying to decompile dot net applications. So the run time attack. It's going to go after the process space itself. This is your application. You can put more than one application in a process space. We're going to modify the run time objects of a process to carry out this attack. We're going to be editing the underlying structure of an application. The structure itself, not the code base. This will allow us to compromise the GUI, instantiate new features, access the code base, subvert logic, and evaluate the object structure. It's more for reconnaissance. When you get into someone else's application, assuming you do or don't have access to their source code, you want to go around and figure out how those objects lay in memory. What instance of an object do you want to attack? This is also useful when you're attacking a program live. So if you're not making it out of the box attack, you want to attack it on the fly. This is also useful. So what is it and what is it not? This is a memory-only attack. We're not going at it on disk. This is deployment independent. That means that whatever way that you are able to make it into your target's run time, this attack will be carried out the same. We have a few demonstration ways of getting into your target's application. And stability. We're not playing games with the heap. We're not messing with pointers. We're inside of the dotnet framework. So we have the stability that dotnet comes with. You don't have to worry about accidentally changing one thing that changes everything else in the program. And this is language agnostic. When you're attacking a dotnet program at run time, it's I-L. So you don't have to care about what language it was coded in, as well as you should be going up against protected programs, which will have obstification, so you shouldn't be able to convert it back into a language anyway, so it doesn't matter. So this is what we're attacking. A dotnet process. You have app domains, assemblies, modules, classes. This is kind of the structure. At the end, we have our instances. And this is what we're going after. So this is the classical view of a dotnet process. You have a process where you have your GUIs and your instances. Inside of that, you have app domains, assemblies, and eventually have your classes and values and functions. And this is our target. We're going to be going after instances at run time. We really don't care what class it came from. We will be utilizing what class it came from, but the structure of the application doesn't matter. The structure of the objects matters. And this is what a program kind of looks like at run time. You'll be going up against a lot of objects spinning around in memory. We have logical sections like the GUI and the core functionality. These objects are interrelated by pointers behind the scenes, but basically value references. And we have a button. It's interconnected by an event to a specific object. And this is our target. To go after the run time, to go after the instances, to go after the events and remold all this. And this will allow us to change the underlying structure of a dotnet application. So the specific task behind this attack, going to connect into your target application. Find objects and hunt for the references to the specific object you want to attack. Like if you're going after a timer or a SQL connection or a TCP connection, you have to hunt down your references in order to attack it. Going to move between objects. Depending on your connection method, you might need to hunt objects. Other connection methods will give you references for free. And finally, we're going to change objects. Using reflection, we'll look at the meta structure of an object, use its signature, and edit it at run time. Okay, so, down to the meat of it, how do you get into your target application? So you connect into your target's run time. You inject into it and spin up some dotnet. There's some projects we'll be demoing for this and is the favored method for injecting or for connecting to your target application. This is what we're going in with Metasploit. This is how you attack them on your system. Also, you can exploit the target's code base or the problems inside of the application. We're going to be demoing Visual Studios and exploiting that. Both of these get you into a target application, not necessarily where you want to go, but it gets you inside. There's infecting the target's code base on disk. This is an old hack. You find your entrance. You add yourself into a NOOP or something and you're in. That's kind of been done. This is on disk, so you're going to leave some forensics evidence behind as where with injecting your code into memory, you're not going to be worrying about leaving something on disk that can be recovered later. And finally, there's attacking the framework where you infect the framework itself. This was presented last DEFCON and has a little bit of research behind it and it's pretty strong. When you infect the framework, you don't have to worry about the target application seeing your code running inside of it. You can access core things like two string and when someone uses it, you attack them. So you can basically have an entrance into any application that uses the framework, which is all the .NET applications. So demoing how to connect into a target application will bring up Mandian's highlighter. Going to be injecting a 64-bit payload in there. If it's a 32-bit application, you inject a 32-bit payload in there. So we inject in and this spins up a payload that says, what do you want to load in? We'll select hack buttons, a nice little demo that goes in and it adds objects to the form itself. And it's pretty easy to go in and edit form since they're made to be fairly receptive to new objects. And we can click these buttons and they go through and add events programmatically to everything it finds on the form. In this case, it adds a right click event to everything on here. When you right click, it brings up an editing menu. And so you can edit pretty much anything as you normally would. This is pretty much the same concept as what Visual Studios does when you're editing it offline. And you can dig into pretty much any part of this and edit it however you want. And of course, you can do this programmatically to reskin any application. And there's some other ones. Like you can make them draggable and all that. Make them poppable. But this is just a demonstration of the injection. So that's injecting. Demonstrating the exploitation. As a quick exploit for Visual Studios, there's a way to run arbitrary code inside of Visual Studios when you open a project. So we open a project and now there's arbitrary code running. So we'll again say, hey, what payload do we want to load into this? And we'll load the lead. So this just programmatically goes through and changes everything into lead. So this is actually dot net form. It's live. It's actual objects. And we're going to lead it. Part of this system is a communication console with all of the payloads. So we have our delivery system. We have our lead. What application it's in, the PID, the user. And this will hopefully be extracted to run over the network. So you can arbitrarily communicate with payloads that have been deployed on someone else's system. So we'll go ahead and lead Visual Studios. We'll also bring up a data connection. So we lead it. It comes through. It iterates through every object that it finds that's of a control type and changes its text to lead. And this actually happens in code. So the plus side of this is it's completely programmatic and we don't have to worry about disturbing the underlying structure of the program. And also FYI, if you save this, it actually saves lead into your code base. And that's exploiting that. So that's the general connection types. There's also infecting the framework, which I'm not going to be demoing, but there's some code base that we're going to be releasing to do that. Like I said, it's pretty strong and pretty effective. So this is the overall structure of the application or the system. You have your payloads. They get packaged into a safe wrapper that gets injected into your target application. So you don't have to worry about threading or any other hiccups when you're running inside of another application.  So this is the basics for how we're getting in. We inject into our target application. We spin up some C++. This unpacks itself in memory and spins up C sharp. This can either be your hack or your payload delivery system.  So this is the basic idea of what you're up against when you inject into a target application. You basically end up in nowhere.  You can hope to get some statics or some entrances, APIs or some object reference. But on a whole, you're pretty much in the middle of nowhere. So how do you get from the middle of nowhere to your target application? There's nothing stopping you, but there's also no doors to use. So the favorite method that we're going after is accessing the GUI to turn that around into an object. You say, windows give me a handle to the window. And then you ask .net to turn that handle into an object. Once you have the windows formed that you want inside of your target application, you can iterate inside of that through all of the controls, access all of the events, the events being function pointers to your target objects. And once you've done this, you can iterate through the object structure using each object to gain more references until you've either reached your target object or you have exhausted the entire object structure. And that's how you get around into the object structure. At this point, once you have all of the references, it's pretty simple to implement your changes to your target application. So as a quick demo for mixing the GUI, we'll spin up Redgate's memory profiler, we'll inject into it. And a nice thing about this is basically any .net application is susceptible. Once you're in, there's nothing that can really stop you. There are a little bit of tricks that can be played inside, but I'll get to that later. So we're inside of our target application. We'll load up our hack buttons again, and we have a payload inside of our target. Utilizing our communication paradigm, we can say, we want to load another payload in there. And so instead of picking from one of the payloads, we'll actually load another .net application into it. And this is .net reactor, a code protection system, itself being protected by a good number of obstification, shells, everything that this protection system could throw at protecting other .net applications. So we're injecting one application into another, and at this point, they're essentially becoming one application. They're in the same app domain. They're not sharing logic flow, but they are one application now. And so now we can say, add yourself to that form, since these are all one application now. Ants memory profiler and reflector. And again, we can go through and lead everything, all that. And it leads everything that it finds in this object structure, and this one leads everything in that object structure, which is why they're separate. But at this point, we can do things like pop controls on and off. But we can also pop controls on and off of multiple applications. So we've now popped a button. And at this point, this button over here is still part of this logic flow. And its functionality here is maintained. We haven't broken it. When we put it over here, we kept all of the same links. So when this is clicked, it activates the same functionality. This is allowing us to intermix the GUIs and the core functionality of independent applications. Also notice that the style of this window matches the application we put it into and not its actual parent. This is due to where threads come from determines their style. And there's some fun games that you can play with this. So now that we can intermix GUIs, we can intermix logic. We can basically remold applications into new Frankenstein apps or mashups, whatever you want to call it. And this allows us to do more complex things when we get into other applications. We can bring tools with us that are other applications. And so that's being able to play with the GUI. So this is basically what we can attack. When we actually go after fundamentally changing a target application, we'll go after the events that are inside of the application. We'll go to a button and wrap the function that it goes to. So the games that I like to play is find this object that it goes to, wrap it, derive from it, inherit and intercept all of the functionality that they would be calling, and then put it back in place of its original. This allows you to intercept the event, arbitrarily do new functionality, and not have to worry about whether you're going to match the signature or anything else, because you're basically the original object structure. Also, this doesn't change the underlying object's code, so you don't have to worry about someone detecting that you're making changes to your target's code base, because this is just a wrapper in another module that's being loaded into it. So something fun that we've whipped up for you is an SQL modification. So we spin up SQL Server Management Studio and inject into it. SQL Server Management Studio is a 32-bit application. A lot of the .NET apps you'll be going up against will be an MSIL and targeted generically, but this is targeted at 32-bit, so you have to use a 32-bit injection system. So for the payload for this, we're going to be using a targeted attack. These are pretty much just generic attacks that can be deployed against any .NET application arbitrarily. This is more for R&D and showing you in code how to do these things. The SQL attacks, we'll start out with SQL Defender. It's loaded in. It goes after this form, adds a star to it to say, yeah, we're online. So now what this does is it adds a whole new security model to the login process to defeat brute forcing. What we've basically done is subverted that event for the connect button, as in the previous slide, and now that we own this connect button, when you click this, it now has your username password. And so what this is, is when you type in a username and password defined in the protection mechanism, it opens up an admin console. This lets you choose how many failed attempts you'll allow before you lock out the login process. You can change your username and password to get to this admin panel. Also, if someone does get locked out and they keep brute forcing into your server, if they finally do get in, it'll instead of logging them in, it'll change your password to a 40-character random. And this is also where you come in and say, I don't want to be locked out anymore. Let me in, let me try again. As well as some Twitter keys that say, hey, if someone is trying to hack my system, what account should I notify? So someone breaks into your physical and decides that they're going to try and brute force overnight. This will add an extra layer protection. This is just a demonstration of adding third party patches to a .NET application. The basic premise of this is you can pretty easily add third party solutions to existing applications without having to worry about compromising the overall structure of the program. You don't have to worry about some pointer when you're connecting to a database because we're affecting this one object. And these hack, these modifications are done in just a few lines. Instead of being hundreds and hundreds of lines, these most of the time are in between 50 and 100 lines. You're dealing with high level .NET instead of walking lines. Another targeted attack that whipped up is going after ants memory profiler again. So this one is loading up a payload that will go after the trialware. The trialware on ants memory profiler pretty much works off of this one window. As most good programmers do a whole bunch of logic and then return a value, that's all this window does.  And that's all this does. It says everything's fine, go on. And the nice thing about this is it's implemented in two lines. The code is literally dialogue result okay, close window. So reflection is the main tool we're using.  You can get constructors and all of that. So if you're a coder, this is the most interesting part and if you're not, here's a nice graphic for you. So when you come into reflection, you're going to have an object. You say get type for object. That'll get you a type. You say hey type. What kind of methods do you have? This will return you a method info object. You can then utilize this to activate that method info. You pass in a couple of parameters and you activate the method. You can ask for values and properties, properties being the getter and setter that wraps a value. And at runtime, getters and setters turn into functions. You can go around and get events. Events are a really nice part to attack, so I've spent a little bit of time focusing on that. Also, you can get constructors for your objects. You can basically dig around in an application and grab anything that you want. You can grab the inherited types. You can grab interfaces and basically think of it as developing at runtime. So here's a little bit of code for hacking an event. Events are normally completely secured against outside tampering, so you can be confident that if you've set something to your event that no one outside of you can change that. This gets around that. Basically, you say, give me a flag that says instance non-public and then you ask for the events. So this function takes in, say, a button. And you say, hey, get me the field of events in string. So you're actually using proper names at runtime. And you say, get me the instance non-public. And so it does. It just returns a private instance variable. You can say static, private. Anything you want will be returned.  And again, it returns it. And then, finally, it's a linked list inside of an event. And you say, get me your handler. And again, instance non-public, which is private. And it returns that value. And then you say set value on that. And you set the event to null. And that's all you have to do to access someone else's event and wipe it out. This is basically the same premise that you would use to reconnect the connect button or anything else. Or text boxes are pretty much anything. You can, once you can control someone's values, you control everything. So the basic premise of this attack is you inject into your target application. You drive deep into it. You gain access to the target objects. Once you've done this, you can access the objects. You access a button. You rip out the events out of the button and you change them. And then you pwn the application. And it's done. You're not worried about editing anything else outside of the object structure. At this point, you don't care about what the code is underlying this. So no matter what kind of protection mechanisms they may have implemented on the code at memory, they're all objects. And they're free to be messed with. This is what it used to look like. When you would go after an application, you might spin up IDA and step through it and try and change values this way. This is what .NET brings us. A lot faster development time. Instead of hundreds of hours and looking through thousands of lines, you're talking about 15 minutes and looking at 50 lines. Most protection mechanisms can be broken down to attacking one function or one value. And with the .NET attack, you can basically iterate through the object structure and find what you want in a matter of minutes or seconds, hopefully, with a little bit of practice. So as a quick public service announcement, we found a really old visual studios hack that's been around since 2006. Microsoft thinks this is a feature that it runs arbitrary code on your system. So basically, all you have to do to make an infected project is, let's see, let's spin up. So all you have to do to make an infected project for any version of visual studios, this is a feature that's core to the functionality of visual studios. They say it's not a threat because it requires multiple clicks. So this loads arbitrarily whatever code you want. They say it's a couple of clicks because when you load it up on a system that you didn't develop it on, it either comes up with this or hey, you didn't develop this code. So you come into the application, you look at the about box and that's it. So this happens because this image box is infected and it's the constructor of the image box.  It executes when they look at it. So the added scary thing is maybe you can make a scanner that would go through and look for the code base and you could look at it before you open it. It turns out that if you don't rebuild that whatever code was left in there, so we'll go to that same constructor, it's completely empty. Look at the about box and it's still there. So regardless of what the code says until you rebuild, it'll be utilizing old objects that could be infected and this is core to the functionality apparently. Microsoft has no plans in taking it out. So I decided that I would whip up a nice little infected app that instead of showing the user something pleasant, it would Twitter out the computer name and the IP address. So when people download and run this application, it decides to Twitter out and so I'll be putting out an application that says in the ULA, hey, when you use this I'm in a Twitter and hopefully Microsoft will get the message that this is not some feature. If you have arbitrary code execution on a programmers machine, you can basically hone whatever company they might work for. You can do something that specifically messes with the development cycle. You can go after the SVN that it has access to. Developers often run as admin, so you can leverage that into something pretty powerful and scary. So some of the other fun ones that we also have is data piggybacking. The basic premise of this is the same as the other ones. Once you're inside of another target application, you can send whatever you want. So SQL Server Management Studio. So you make it into someone else's machine through some exploit and you're unable to get back out to the net, but SQL Server has a valid communication portal and you leverage its credentials to get you back out to the net. So we inject into it. We select data piggybacking and again this management console allows us to talk directly to that payload. We can send emails, Twitters, UDPs, and so we can send a Twitter of whatever we want and it inside of the object structure leverages the credentials of SQL Server Management Studio to send Twitters. Or UDP packets or email. This is just a nice data exfiltration tool. So once you're inside of your target you can migrate around until you find an application that does have rights to get out. And so here's a Metasploit payload that we developed. All right. So I'm not much of a .NET programmer, but I do like Metasploit quite a bit. And I like getting Metasploit integrated with as much stuff as possible. So we thought it would be really cool if you could go from one machine to another remote machine using any arbitrary exploit that you had that you could get from Metasploit anyway you can find in and then do in-memory remote .NET code injection to the remote machine through that. So we set out to do that. So what we wrote was essentially just a C++ shim. That right now it's a interpreter extension but you can do it.  You don't actually have to write your own interpreter extension if you don't want to. And that will spin up .NET from within whatever process that you've migrated to.  So we just have a VM over here that's got SQL server management studio running on it and I should get a remote desktop to that. And so we've got a interpreter shell I just put something vulnerable on it. And then if you look at the process list and find SQL server management studio SMS it's 3088. So if you just migrate to 3088 use this is the boilerplate interpreter extension that they wrote. And I just wrote this command alive that spins up .NET and then whatever payload that you have. So you can write anything that has some C-sharp in it and avoid main and this will just execute it for you inside that C-sharp application. So we just the thing you saw before that attacks SQL server management studio that twitted your password. If we look at the login here, oh it would have worked if this was open. There. So let's try it again. Is it there? Yeah. So there's the asterisk on SQL server management studio. So now you don't have to do any of the work of figuring out how to get .NET running within a C-sharp process or anything like that. It's all there for you and you can just deliver metasploit payloads in .NET now. Which I thought was kind of cool. And it never touches disk because the metasploit people did all that great stuff with DLL injection and that's essentially underlying how this works as you DLL inject into some process and they're doing all the fancy reflective DLL injection stuff and then we leverage that and spin up .NET inside and it's pretty cool I think. And so like you said of course you can use any of these payloads and deploy them across the network or make your own void main. So now that you've successfully pwned, you can pretty much do anything you want. Anything in .NET can now be done. You can do anything from access the system's Windows API to write to disk. Leverage any of the credentials of your target application or migrate around to your target application until you find the credentials you want. Some of the non-evil uses of this are also quite applicable. If you want to write third-party patches for your application and you want to do it with a short development time this is great. You can edit the GUI, you can edit the logic and then you wrap your application with a loader that injects it every time it loads. Also there's defensive payloads like the SQL one that will stop brute forcing. So you can write independent protection systems that will work for you that no one else maybe knows about or you have one set of developers developing something to be injected and you can hold this back from your main development cycle. There's also bug hunting. You can inject into your target application and of course bug hunt. You can find the exact values of anything and get deep inside of it and find out the state. You can find out the connection and there's also flexible programs that can be built. This is nice because now you basically have an API that can work with any application. Instead of worrying about how do you connect to a target application you reach straight down inside of it and access any part of it you wish. This is specifically nice when you're maybe trying to figure out how an API works. You can reach inside of it and literally dig around inside of it until you understand it or even remold it to add a new API. So the things that can slow this attack there's a little bit of framework security but that's not any concern. Some people say they're trying to make defensive countermeasures but of course you can attack their countermeasures or since this is basically loaded at a specific instance in time you can wait till all of your authentication is done and the defensive countermeasures have all spun down and then inject into the application and get your work done and possibly unload from memory. A lot of the hacks that you can do are merely rewiring you don't actually have to add code to your target so you can get in rewire your target and then get out and so you won't be resident in memory anymore. Also bad programming design can make this really hard. When you find a program that has vestigial buttons and classes all over the place for no apparent reason you can get pretty lost and other bizarre development cycles but as a whole most programmers have a pretty clean design in high-end apps so you can get around pretty logically and I'm hoping that development cycle will spin up and we'll be developing a better way to walk around the objects and attack them that way. Was there one more? How do I get paid from this? We're going to make these hacks and give them away for free so this is all going out for free under the Creative Commons non-commercial so it's all going to be out there to play with. We get paid hopefully to build countermeasures against this. Basically we get paid by building countermeasures so if it company would like to get this they would be able to hire us as contractors to come in and protect their system from this or add additional protection. Sweet. So some of the people that really helped with this on coding the wheel James Devlin sorencer band they did some nice research and he did attacking the framework some really nice stuff thanks to some of my good friends that added to this and check out the book Managed Code Root Kits this is coming out in a couple of months and definitely something if you want to attack the framework and as I said this is all going out under the public use license and they'll be Q&A over in 106 and some of the additional payloads if you want to watch we can run over them okay we want to show Twitter real quick one last thing in case you didn't believe that it was actually doing it so when you log into your SQL server every time now it shows you your essay password in black hat so we have a couple of extra minutes so I'm gonna just spin up some injection and do a couple of fun demos that I've really enjoyed so we can basically at this point intermix applications of course and injecting into our target application allows us to edit the GUI and add some intermingling features so when we get into the target application we can ask code object the code behind it so when you're inside of it you say hey what's your code and it divulges its code so you can jump around to objects and say hey what are you running and instead of hunting through the object structure you're right there in code also going after SQL server we'll inject into that and spin up the communication console pretty much the same hacks leading I guess I lost a couple of payloads okay well thank you very much for coming to my talk hope you enjoyed it


So my beautiful people I am back with another out and ring video today I showcase to you guys how you can get well what's an extremely rare weapon I mean one enemy drops this I know yes there's many one enemy weapons in this game but this one is an enemy hiding in a dark corner in a place you probably won't go to you don't have to go there and I mean literally it's a one-time thing so hey and it's pretty cool too it's called the mantis blade and today I'll explain all how's it going guys my name is dpg and if you do enjoy the video leaving a like it helps out and if you like what you see you want to see more be sure to subscribe okay so there are many other weapons in the game there are many weapons you will easily miss and this is probably tougher to charge so I mean this drops from one enemy as far as I'm aware there's only one of these enemies in this game that I've seen anyway and this enemy is hiding literally in a dark corner you can easily miss or because at the time you will encounter this enemy it's kind of like yep I'm in a rush I need to get out of here I don't want I don't have time to stand here and fight just in case so yeah guys it's a it's a great weapon too like I said I'll showcase it to you now it actually is super unique in its heavy attack well firstly let's check out its stats it scales with strength and dexterity it requires 12 dexterity and 10 strength can apply an actual war to it it's just got that standard spinny slasher thing I hate seeing this on that weapon I'm not gonna lie I'm so used to weapons with unique skills but hey this one guys you can apply an actual war to it to make it even better and as you can see by its heavy attack it kind of like doubles up like a mantis claw pretty cool guys it really is pretty cool but hey do you're wielding these things I mean new game plus only unless you can get somebody to drop it for your dupit with you but new game plus only you're wielding this I think it would be absolutely amazing I really do but yeah guys okay so where's this comes from so it drops from an enemy all the way up here within where are we the galmyers hero grave now this is quite a trek to get to your first obviously need access to the grand lift of dektas dektas medallion guys search youtube for it um easy to get once you have access to this you can come you can actually make your way around here now I'm gonna run all the way around because this video will be 20 minutes long but the easiest path to is to easily just literally just just follow this just follow this guys just run around here run straight up through here just like so you'll come around here then guys and you'll come to this grace point now I'll lead from this grace point which you'll see on the screen now but you literally run forward come up a ladder and just follow the path I take and once you're in the heroes grave it may take a few attempts because it can be a bit hard there's a chariot in there there's lava there's all kinds of things I take a different route to probably a route many people will take I jump down on this second sequence of the chariot I jump down until like a little ledge and then just go back and actually land on top of where this enemy is you need to kill hey guys follow what I do see where I'm going on screen now and you shouldn't have no problem getting this thing like I said once you get to the heroes grave just take your time in there is a little dangerous that chariot is absolutely disgracefully powerful one hit guys and destroy you but yes go get this weapon guys I'm pretty sure you will love it and well I hope you enjoyed the video if you did leave me a like really helps out if you like what you see and want to see more out of the ring be sure to subscribe and hopefully might be you too for people I will see you on that next one


of Donegal. It was a pioneering survey that took place over 40 years ago. In fact, Donegal was the first county in Ireland to have a full survey of its archaeological sites and Caroline Carr from the museum now joins us in the studio. Caroline, it was groundbreaking stuff at the time to have such an extensive survey of archaeological sites done. How long did it take? It happened over two years, two years of surveying and then it took about another year to collate all the data and it was published in book form in 83. So this is the early 1980s. Right. And it came out in book form. And this, this is showing off the book. This book form here, yeah. This is our Bible, our archaeological survey of Country Donegal. It's an amazing, amazing book. It's extraordinary publication. How many people would have been involved? So Brian Lacey, Dr. Brian Lacey was the survey director and up to about 35 people involved from archaeologists to surveyors to all different occupations were involved in it. And it was, it came out a very funny way because you have to remember the 1980s. It was a time of, you know, huge unemployment in the country. Everybody was leaving. Yeah. And there was no work. And, you know, it was a hard time. And this, this came out of actually of a meeting after a cross-border meeting in about 1979 that there's a regional development committee in Donegal. And it was to do Dees Mackie and Dermot Walsh, a chance conversation. So the madness began then and they put in a proposal to the tripartite government set up a tripartite committee to try and alleviate some of the unemployment in Ireland. Trying to get jobs or create schemes or funds and things like that.  So they put in this proposal for project and it was actually, it was approved for funding and it was a pioneer. It had nothing of this type had been done in Ireland. Previously in County Down there was a smaller survey but nothing to this extent and nothing ever published like it is. After this, where there's similar surveys done in other countries? Yeah, it said it was a pioneer for the whole of Ireland. So there's some surveys being carried out in Ireland and I'm not sure all the counties in Ireland have been covered yet. Well, so it really was pioneering stuff and I'm just looking and it was, a lot of it was very basic stuff because I'm looking at the book here and there's some photographs, grand, but there's also a lot of writing detailing any number of the sites. And then there's some sketches, a lot of sketches. It's very detailed and it was very ground and they have to remember these were carried out with the most basic equipment and we have the minutes and the records of the survey and the survey teams and like they're trying to beg, borrow and steal like range and rods or they had one camera and you have to remember they photographed over nearly 4,000 sites. One camera. One camera. And like they had they had just about luckily rain gear and range and road and they had a couple of vans hired from the council as well. So it was really, really a pain. Literally, there were pioneers on the ground and you have to remember there was no modern IT equipment, no modern surveying equipment, so it was pretty hands-on. So you, before this exhibition, you've been chatting to some of the scientists who were involved. Some, yeah, some of the archaeologists like Claire Cotter called in there the last day and she was pleasantly surprised to see herself on the panel and out and about where sheeps can quote with no buttons. She said they didn't even have, you know, they didn't, some of them didn't have boots or wellies. You know, that's how basic, yeah, they weren't given any equipment. But some of the fantastic stories saying like, you know, remember this archaeological survey, so you're going up hills and downdales and infields and every nook and cranny around the county looking for archaeological sites and surveying. So you're meeting everybody and you need to get permission if you want to land and like she's, you know, many characters she met, but also describe, you know, the unbelievable poverty they came across and the loneliness of older people living on their own and may have never talked to anybody that weak apart from the postman. And then other stories then of them being chased because people were assuming that they were involved with the uranium mining as well, which is a hot topic at the time, and because they were surveying along the border and coming across, you know, being told the site that literally they were going to maybe survey that morning, there was an arm stump found in it. So and then coming across army patrols and coming across because they were in the middle of fields with range and rods and equipment and people didn't know who they were and you wouldn't really come across too many archaeologists now in everyday life anyway. But still wouldn't. No still wouldn't. Okay so a strange activity in sort of strange times, but you know at the heart of it all it's a very detailed survey and it's always compiled here in book form which adds weight to it all if you like, but it's a very detailed survey of every type of archaeological sites. People don't realize how well unfortunately since the book has been published yes more sites are continues to be discovered because not everything can be documented and catalogued and then unfortunately some of the sites have gone. So in our exhibition as well we received funding to the Heritage Institute funding from the Heritage Council we hold the original field notes and we hold also the original plans and drawings your lovely surveyors drawings you're talking about all of the sites and also photographs of practically nearly all the sites and they have never been seen by anybody apart from or maybe they've never been seen until they returned into slide form over 40 years ago. Would you say some of them are gone? What's happened to them? Been destroyed or maybe erosion or different reasons. The vast majority of them wouldn't be protected. No they would be protected but you have to remember the when this time we hadn't the all the National Monuments Act weren't in at the time but all the sites that are in now they're all protected and things and even though a site maybe you say for example a standing stone say it's not visible above the ground that means that doesn't mean it's not protected. It's still if done the RMP map there's a socket in the ground it's still protected even though it's not visible it's still there or like Ringford so you have to check and the easiest way to check now is on archaeology.ai and you go into the heritage environment view and you see the most up-to-date listings of archaeological sites in your area and just type in your townland and you'll be surprised what you might see. Yeah and and stuff that you might be passing every day or areas you might be passing every day and you just wouldn't realize that there's something of great significance there. You may not know and then and the problem is not problem with these but some a lot of these sites not all of these sites are in public care and public accessibility they're on private land so you may never see them or you may never get access them but it's it was such an important thing and the detail of you know what they are and maybe some of the research has been updated and the dates have been changed but it's an extraordinary thing to detail on it. And now a lot of this has been digitalized I'm assuming. Well the book hasn't been digitalized yet now we're working on that but the the lovely photographs or slides we have there's a beautiful site of rock art beautiful rock art and it's got its twin twin brother over here and it's it's long the road you know barn is big between you know Terman and Kilmer Cranon it's down below the road and it's most beautiful rock art and then you have the pure freezing cold surveyors out near Petticoat stand and I feel what their high-tech wet gear on them and they're one ranging rod. It looks like it's not the best of days. I know the date first this was about the 30th of December so they're out in all weathers and then we see the state of the county then we know this would be full standing stone it's falling down at that state but you can see the the dump car and the batten car yeah and now you know it's a great snapshot of our county site just over 40 years ago and you can see the difference in sites and you can see you know a lot of sites maybe you know have improved and their condition has improved or has been stabilized or and or some cases sometimes are gone. So the exhibition is really the story behind the survey as opposed to focus on the survey itself is it? It's a mix we do so we have printed and we've created some from the images but it's telling the story of how this amazing survey and the people who worked on it under these conditions and how it was created and we've all as I said we got funding from the Stewardship Fund to digitize all the plans and drawings and slides and there's over about um gosh 8,000 there's probably five or six five over 5,000 of them so they're due to go up on these are on the years when the Donegal County Council gets a new website updated we'll we'll put them up online so they'll be available digitally and they're the most amazing resource for anybody researching the local area or professionals or for planning and things like that because these are sites the images of the sites people have never seen before they're in my office and for the last 20 something years or for 40 years prior or 20 years prior to that and they've never been viewed by anybody it must be fascinating for you to to chat to some of the archaeologists involved and just listen to their stories first hand yes and some of them are the leading archaeologists in the country you know that worked on it um oh yeah in some of the partially some of the stories you couldn't tell I can't tell you I can't but no it was um they're busy were pioneers they were sent out nobody else had done this type of surveying work nobody else worked on on on a county they may have surveyed a local area or local site but not an entire county and the county was divided up into five areas so there's archaeologists based in local areas and they became in you know part of the community as well they've been there for months at a time oh yeah they've been there there for you know a year maybe or more there you go and uh there would be integration into the local community and it's amazing what they I'm sure it was tough for them but it would have been fascinating at the same time well they're a lot of them are all young and just out of college um as well so it was a great a great time and a lot of them maybe like how it didn't realize how far away Donegal was you know and um and there are more corners that they were going to be sent to oh and it is literally the remotest corners of Donegal they got to view these amazing sites are coming across them like but we're always encouraging people to report them any new sites or anything we can help you with the archaeology ring us in the museum we'd love to help you okay the exhibition is open now is it it is it's on and it's free always free yes museum's always free down at the museum down on the high road yeah that's it come in and see us yes Karen thanks man thank you so much


Hello everybody and welcome again to yet another OpenShift Commons briefing and this time I'm really pleased to have Aqua with us. They are brand new members to the OpenShift Commons And as I always like to do is make new members introduce themselves and what they do in the ecosystem of OpenShift and Kubernetes and these guys and folks were at the KubeCon event in Berlin and I was pretty impressed with their offering and then they joined up to the Commons and so I was even more happy to have them as part of our community. So today Tevi, Stevie, Corrine is going to do the presentation. We also have one other person, Apesh Patel, who's in online as well with us and we're going to let them introduce themselves and give a presentation for about 30 minutes or so and we'll have some Q&A afterwards. So Sevi, take it away. All right. Hi everybody. Really excited to be to be presenting here to the community. You know, we've been in the Docker community for a while now as a company and I could actually jump right in a little bit about Aqua. So Aqua has been was founded about two years ago. Our mission statement is to make the use of containers be as secure as possible and actually provide organizations with the expertise and the tools that they need in order to not have security as a something that would prevent containers from rolling out. So not having security as a barrier for containers. Our product, what we sell and what we support has been around for a year, has been used in multiple environments, both big and small and and I'm happy to share some of the product details with you today. We're also very much engaged in the community.  We are a private partner for OpenShift. You can find that information on the partner section in OpenShift. We do a lot of meetups. We do a lot of conferences and we have a lot of engagement with companies and also with individuals that want to advance the cause of containers and make sure that they are done securely in an environment. A little bit about myself. So I actually come from the security side. I've been in security for over 20 years now and my focus is compliance, security processes, procedures and in the last two and a half years or so I've been concentrating on securing DevOps specifically containers and doing a lot of advocacy for container security. And with me is Upesh Patel who is doing our community outreach and business development for Aqua and he was the one that was able to get us certified and on board on the community and make sure that we have the right relationships with the entire ecosystem. So what I'd like to do is jump a little bit into what we're doing today and that is talk about security for containers and it's a pretty big subject. Security for containers touches a lot of things. The way that containers touch a lot of things. It's a new paradigm in IT and it turns things a little bit on their head. The security that we've had so far around application development, the operations of application deployment and the networks really didn't have a lot of interface points and I show up, I show a few of the interface points firewalls and web application firewalls specifically are interfacing between the needs of the application, the needs of the network. The way that code is assessed and analyzed throughout the environment is interfacing within development and operations and of course there's the networking and operations for server config and patches and containers where it sits in the middle of it. There's a lot of capabilities in containers. They shorten the development life cycles and they do provide an opportunity to roll the same software in multiple places and the flexibility to move to the cloud in a very robust way. But for security that's the fact that it really sits at the heart of very different sometimes very disparate security practices requires attention and it has been a barrier to adoption because it does turn the security processes from being very much late in the security process, in the development process into something that needs to be thought in advance and there's needs to be a lot of collaboration between development ops and security. So this is where we sit today. Containers are changing a lot of the security process and IT process in general and we need to make sure that we follow up with them. The platform security and where OpenShift comes in is to provide the best secure platform for running containers from an operational point of view. So by controlling who can access the nodes, by controlling authorization around what application spaces can be started around what the different uses can do, the administrative rights around making sure that container resources are done properly, that the server is hardened upfront, that there is elements of intrusion detections and process separation is actually just a partial list of all the security benefits that OpenShift provides and it's really cut across both the operational and the network side. So what that allows us to do as people who want to run applications in containers is really not to think about the stuff that we used to think about, which is how do we harden an operating system, how do we make sure that we have consistency in the administrative rights, how do we make sure that once we put a server out there it doesn't really change over time and might introduce security risks that were not initially there. So OpenShift and admittedly also other container platforms, but OpenShift in general is very much security focused, doing a lot of good work for making sure that the defaults of Docker that may not be as secure are actually addressed and it really gives confidence to actually run the platform. But that's just one side, that's just the platform. The applications themselves are still the applications. Organizations still develop applications in containers and that code has nothing to do with Dockers or Red Hats or Kubernetes or anything that the configuration of the platform can address. The applications are still applications. And 80, 90% of the code that is going to run in a containerized environment is not going to be the platform, but it's actually going to be the payload that does the business purpose for the application. And in that respect, security still has some concerns. The prepackaged images, the things that go out of the development world and then being put on a particular server or particular node through a deployment is not well understood. There's not a lot of transparency in the way that applications are written in containers, especially the way that they are put together with the operating system. And that creates a lot of uneasiness to security operations because they just don't feel that they have control. And that feeling is because they really don't know where security fits in the process. Security has very, very good history in being at the junction where applications get put on servers and that everything can be assessed and the risk can be understood. But now that we're not building servers anymore, there's really nothing for security to hang on to. So that's a problem. Containers, even Kubernetes itself can provide a lot of operational views into containers, but not a lot of security views into containers. So the traditional security tools that are being used to view the environment, to assess the risk of the environment are not in use. And then because there's a lot of open source usage, some of it being assembled as a platform like OpenShift, some of it can be instantiated just as an open source component. That also creates an uneasiness for security. I'd like to be able to point a little bit about the process because in the pre-container world, you use to basically build your code and that's the top line there. You can do some static analysis, evaluate the code, make sure that coding practices are in place. And then you would compile a package or a component that can then be run on a server that was provisioned beforehand. So somebody would provision a server, configure all the necessary operating system. They would put Java on it if that's the case. They would put the application server on it if that's the case. Any type of middleware that is required, assess the risk, correct it, configure it properly, and then these two things get married and then deployed. And after that deployment is done, there is still an opportunity to then take a look at the configuration security and other security parameters for servers and then fix them while the server is in production. Containers work very differently. And in the container world, the coding and static analysis still should happen. We are talking about applications that are still written in programming languages that can benefit from static analysis. Codes still need to be compiled. But then when building an image, when doing a Docker build, this is where the risk assessment comes into play. It can't be done later in the process. Because once the container is instantiated, once the deployment is started, once pods are instantiated in the Kubernetes environment, it becomes almost impossible to patch them. And we really shouldn't because containers really should not be touched after they're rolled out. So what we're doing is we're now moving security from the very end of the process into the kind of beginning middle of the process. And that represents a change. It not represents a change that needs to have both the procedural and process and communication practices in an organization to support it. But it also requires some software solution that can provide the right of visibility into where the process is. So what are we actually doing about it? And what is Aqua doing about it? And why are we educating the market in order to embrace containers? Well, we want to answer the the needs of security people and make them feel comfortable with deployments of containers. So what do security people want? They want safe images from trusted sources, images that can't be tampered with, images that we know what the components are. Common security practices, like all the things that OpenShift can do, making sure that no out of band change can happen to the environment that there is right authorization, network segmentation to make sure that whatever sensitive data you have is still segmented, still segregated and safeguarded. Anything that we need to do in an environment container or not, especially if it's a regulated in scope environment needs to be audited so that we can find root cause analysis, but just provide the data for demonstrating compliance. A lot of the rules for security, and I know if you're coming from the dev upside team arbitrary, but that's the universe we live in. A lot of times you just need to provide data for compliance because you need to provide that data. So all of these have been developed over the years to support the server environment, the VM environment, and the same process actually happened where we moved from physical servers to virtual machines. All these questions need to be answered, and it took a little time for security people to come on board. And this is where we are with containers, but we want to accelerate that process and we want to make sure that we give security people and DevOps people as well the tools in order to adopt containers in a secure way. So there is an opportunity to actually change the way that security is done. Security could benefit from the shift left, which I hope I don't need to explain. This is where a lot of the processes are shifting towards the development side. We want to make sure that there is automation in place, so that whatever automation is done by the orchestration or anything around it, security can also benefit from. And we also want to be more preventative. There's a chance because containers are microservices to be a lot more proactive, a lot more defined in the way that we do our security. And the way that we actually insert that into the process is to start to look at the kind of classic phases of the container lifecycle and figure out what security processes and what security controls need to be done in each and every step. And at a very high level, and this is a very incomplete list, but at a very high level when you build a container, when you do a docker build, make sure that the code is done right, make sure that we have a good understanding of what goes into the image. It starts from the from line, really understanding what the base image is and then understand what other components will be built on it all the way to the payload of the application. As containers are promoted from environment to environment or also in the pipeline, we need to make sure that our assessment is still valid. So preventing any change or tampering with an image is something that will need to be done all the way up to the rollouts to the nodes. When we deploy to the nodes, the nodes themselves are operating system. They don't have as many components as operating system that basically carry payloads of complete applications, but there is still a lot of times an SSH service out there. There is still the ability to run operating system commands. The docker group is still valid even in a Kubernetes environment. So the access controls both to the physical node, but also to the docker engine itself are important. And then when containers run, we need to make sure that they are running in line with their business purpose. And this is where we can insert a lot more of the security control. So what I like to do is kind of dive into each of those areas from an application security point of view and mention how well we can execute them in a OpenShift Kubernetes environment, but also in a natural docker environment, the same things really, really need to happen. What OpenShift is helping us with is by providing a lot of the controls that docker doesn't provide by default and making them available. So the first thing after a actually before an image is built is to figure out where the image is coming from and how do we want to build it. So by selectively designing the build process of a container image, we need to make sure that the images are secure, that the base images are secure, that whatever we're building on is something that is not going to bring with it a set of vulnerabilities or set of configurations that is not in line with the best practices of the organization. We want to make sure that we register those images so that only approved base images can be used, scan vulnerabilities on the entire environment, share information between developments, sec and ops, and basically get a good visibility into the entire system. If we get good visibility, if we're transparent, then we have a much better chance of that environment being seen as secure and being seen as something that security feels comfortable with. So on that note, it really all starts with the development. So let's go into an environment and you've probably seen that before. This is Jenkins. Jenkins is a CI tool that basically drives the steps in which an application is done. And there is a way to with Aqua to provide a service that those processes, the CI processes or actually anybody else can ping and get an instant assessment of an image. So this is a build that was done in Jenkins. And this build basically starts with the pool of the base image. So this is the base image that we're pulling. We are then running a the Aqua client container called scanner CLI to do an assessment on the base image, make sure that it complies with policy and make sure that it's registered as something that is approved for use. We are now collecting all those packages that that was in the base image and we can provide information if the base image is okay to use. In this case, it is. We are then doing the build. So that's pretty normal. We're doing the build. We are copying some files. This is not a very robust build, but actually we're copying some files, installing engine X, putting in the engine X command and so on, building the server. I'm actually pushing it into the registry and then we're going to do an assessment on it. And you can do the reverse. You can also do the assessment first and then decide if you want to push it through the registry. This is just for the purposes of my demo because I need to use that image later. So that image assessment is now taking place on both the base image and the entire stack. And we're getting a response. And the response is unfortunately that this image is disallowed. And we're also saying that we're going to prevent this image from running, which is something that we need to remember because we're going to show how that's done. So right now we have a build. That build failed for a security purpose. Okay, why? Right? Is it a developer or an office person? You can ask yourself. And we are providing that answer. So we are providing an output that is going to tell you exactly why this failed. This is a CVE, a block TV that is too high for the purposes of the policy. And therefore we want to make sure that if we can avoid using this component or or maybe change this component or update it to a new version, this vulnerability is not going to be there. And then the image will be allowed to continue. And that's exactly what I did. So my version two of that image is something that has, now I'm going to go to the build, something that has more or less the same thing. So getting the base image scanning the base image and so on. And then building the image and now we're getting success. So this is not the end of the build usually because there are other things that need to be done. But for our purposes, this is where the build is finished successfully. And what we're doing is we're still providing that level of vulnerability, but right now we see that their scores are pretty low and there's nothing there that violates the policy and therefore the images is allowed to continue. Maybe somebody decided at one point to to do a new build or experiment with a building the same environment or the same application on a different base operating system. So in this case, I'm building it on Debian and not Alpine. Debian of course has a different way of doing application. It comes with some vulnerability sets and so on. But for my organization in this demo, Debian is really not assessed, right? I don't know what that is. Security hasn't really evaluated it. It's really not authorized to be used as a base image. And even though the build carries on, we're still disallowing the image. We're disallowing the image not because of a vulnerability, but because it wasn't built on a trusted base. So even though it has the same amount of vulnerability as the image that was allowed to proceed in version two, version three may not have a much bigger vulnerability posture, but it is something that security hasn't assessed yet. So we're not only dealing with vulnerabilities here, we're also dealing with the configuration and the base image and assessing whether or not that is acceptable for the organization. What I'd like to do is take a look at the Aqua side of things. So this was the CI side of things in the Aqua side of things. We have our demo application here. Let me just sort it by alphabetically. And we have the same information in the Aqua UI. So demo number one is disallowed because of a CVE. Two is okay. And three is disallowed because it's not using an approved base image. All of these actually corresponds to an image assurance policy that can have many parameters. But the ones that I chose to use in this demo is the fact that there are some vulnerabilities that should be blocked and that these are the approved base images that can be used in my environment. By the way, if I wanted to, if I, if I, I'd build it on Debian with, if I use Debian Jesse, that build would have been successful because that is an approved base image, right? So sometimes it's not really the type of the operating system, but security may be a little bit behind in assessing the compatibility of newer versions of the OS as a, as a good base. And that just takes time because security needs some time to do their work. That's something that organizations will need to negotiate and make sure that we have the right versions in place. So this is the, the, the, the image policy. And that's why we have the, some of the tags available to use and some or not. Another thing that, that we're providing with Aqua is, is some information that ops and security might want to know about the image as a whole. So it's not just that the vulnerability posture is here and we can take a look and we'll see them a little bit, the, the vulnerabilities and what their, and what information we get on them. But just the packages that are deployed in that image, some of the metadata about this image. So if you remember, you know, we were using NGINX. So just knowing what the command is, is probably going to put a lot of people at ease because once you instantiate an image, you really don't know what it's going to run. So that's, that's the, the, the one thing that we can provide security and make sure that they have the right authorization for. As far as the vulnerability posture, there needs to be a lot of information passed along back to development in order to know what to do. And, and, and in Aqua, we are doing a lot of work to provide good understanding of what the vulnerability is and what might be the impact. And you can see that we have several types of vulnerabilities, actually CV is just one of them. So we are using white source as, as our, one of our sources for code that, that is not really operating system based, but really some package based. So, and we can give you some fixed solutions and advice on how to address them. We are correlating the Red Hat vulnerabilities with the NVD vulnerabilities. So if you know how to read the NVD, those are the common vulnerabilities that have been kind of pushed up to the national database, even though Red Hat may have a different view of them. And again, we're providing description, fixed version, and the solution advice, and we can link back to the NVD and also to Red Hat so that every time that you develop on a Red Hat or CentOS based image, you have the ability to get a good understanding of what not only is, is the, the NVD thing of the vulnerability, but whether or not Red Hat agrees. And, and Red Hat is actually doing a lot of good work in order to assess the security of, of the tools here. So here we have another vulnerabilities where there's correlation between, between Red Hat and, and the CVs. Something to, to kind of make a note is that sometimes there are vulnerabilities that there's no agreement on, and there's not a lot of agreement in the vulnerability space sometimes. So what we have at AQUA is we've done the work to address some of those things that are negligible and may not be something that you need to worry about. And in this case, the, if you scanned it with, with basically any, any type of vulnerability scanner, this will go to, is going to pop up on this version of BASH. But, you know, Red Hat no longer considers this to be a security issue because there are maybe other factors that, that mitigate it. So that is something that as a development organization, or as ops, you may not know the exact impact of a particular vulnerability. That's why we need to have collaboration between DevOps and security to just make sure that we, we are on the same page. But we are arming you with a lot of information in order to make the argument that if you do need to use a component, then, then you can use a component and you can allow to, and you can allow it to run in your environment. So at the end of the day, we want our, our images to be secure. So we want to get an agreement that an image is, is okay to run. We can put those rules in the CI. We have the information that allows us to then collaborate with security and make that determination. But at the end of the day, the image is going to be uploaded to a registry and then should be available for use. And then what we're doing, we are going into the second phase, which is we also want to make our Docker engines and our, and Opershift nodes only accept those known images, images that have been assessed and images that have the security posture is known, approve them based on the risk and also maintain the integrity of the image so that if somebody changes it or the name changes, we can detect that and make sure that the image is, is, is proof for use before we run it. So we have those three demo images. Let's kind of run through that pretty quickly. So what we can do is we can pull our demo 1.0 image and try to run a container from it and, and we get the message that, you know, we don't have permission to execute it because this is an unauthorized image. So, so demo 1.0, as you remember, is this allowed and the message was, you know, we won't be able to run it. And that's, that's how we won't be able to run it. And that's because Aqua is safeguarding the Docker engine on the particular node and doesn't allow that image to, to instantiate. We can't swap out the image name, right? Docker tag still works, even, even in a Kubernetes environment.  But if you try to run that 2.0 version, it still tells us that this is an unauthorized image. And the reason why we know that is in the course of assessing the security of an image and getting all the vulnerability information, what Aqua is doing is actually doing a hash of the file system in all the individual file and then a complete digest of that image. And what we're doing is we are providing a state for each of those images. So a state can be either registered, it can be unregistered, or it can be an invalid digest. And in this case, we have a, our 1.0 image is registered, it's the same image, but it's blocked because it's disallowed. My 2.0 image actually very, very iffy, right? Because the server digest is one thing we've looked at it before. But locally, it doesn't look like what we expect. And therefore, we would block the running of it. The only way really to run this image is to pull it again. And that's the 2.0 image.  And then that image becomes registered. So it's not only the ability to understand what the risk posture of an image in the pipeline, but we also need to have our engines, our nodes, only accept images and deployments that are allowed to use. And we have the ability to then stop images that are not allowed to use or that are different than what we expect them to. One of the things that Aqua provides as a compliance view is that we can do the same view across all the nodes. And this isn't my host images view. And you can see that there are, you know, a few of them are not like the others, right? Some of them are not registered, some of them are not registered and don't comply with policy. This is really not what we want to see. We want to see something that is more in line with the rest of my server environment. You know, my number three server is probably the best one because I didn't put anything unauthorized on it. This is really what we want to see. We want to see that everything is registered and everything complies with the policy. The same view, by the way, can be done on containers. So on every running container, we have the ability to see whether or not it complies the policy or it comes from a registered image. So this is the phase where we're able to basically say that everything that we deploy, everything that we ship to a particular node is something that A, we expect and B has passed the organization security policy, which would make everybody a lot more comfortable in what can run in the environment. In addition to that, the deployment can be done a lot of times with automation in a Kubernetes environment. It really should be done with automation. But we want to separate automation from human actions. So not allowing access to the node, controlling who can again privilege if you do allow access to the node. Make sure that we limit what permissions, volumes, networks can be used in the course of a deployment and basically give you a lot of an audit trail. And that's another thing that Aqua can do because our ability is to audit everything that happens in the Docker engine itself. So this is the audit log from the last few minutes.  Everything else is successful. So another thing, if you are working in a Kubernetes environment, you expect the user context to be the user context of Kubernetes to do all the heavy lifting around changing and starting stopping containers. So it's really easy to identify if there is a user, a named user that is doing any of that work. And that of course can be funneled into a log aggregator or a security information management platform and then takes from there and correlated with the rest of the environment. So preventative controls are great. The detective controls, the ability to see the logs is also very, very useful because it provides us with the ability to then prove that our controls are working. And then we get to running containers themselves. So we've seen that the images are good enough to run because we've done a security assessment on them. We know that they haven't changed. We know that they are run by authorized services or authorized people. But when a container is running, there is a lot of things that the container still can do, right? It's still running software. It's running software that's a lot of times exposed to incoming traffic. And we want to make sure that our container is run really according to plan. So there's a few things that we want to make sure. We want to make sure that the user context, that we run a container is the right user context, that the executables are in line with what the container should do. We want to prevent any significant drift between the container and the image because we really should not be patching or doing any changes to a container. And then we just want to understand what the usage data is. And that's not usage around resources, but really who's using what and whether or not there is any misuse of the container, basically an attempt to co-opt it to do something that it's not supposed to do. So understanding all that, Aqua is really providing those controls while a container is running. And one of the first things that we want to do is just kind of get a baseline on what a container is doing. So if we take a look at our list of images here, I have WordPress as one of the images. And if I just start a WordPress instance, one of the things that happened is that this WordPress instance, we are starting to get some telemetry from. So we are getting some usage information from it. We are getting all the executables that it was run, that were run. And you can see that WordPress is a pretty heavy application. It does contain a lot of processing and web server. But even that, there may be 22 or something or 12 processes that need to run. We can understand what the networking requirements are, if there are any environment variables that were passed along to the container and what user accounts it's running on. This is actually not a very good image because it's running on the root. We want to make sure that that doesn't happen in production. But let's take a look at the resources right now. So now we have an idea of when WordPress is running, really what it needs. Now let's take a look at the image itself. The image itself, if we do let's say a Docker exec into it even as root and go into our container, we can see that there's quite a lot of executables there. It's actually not as bad as some of the other full operating system, but it's more than the application needs. So one of the things that we need to ask ourselves is do we want to run every single executable just because it's in the image? But another very important question is do we want to allow those executables to change? So now I'm root inside of a container. There's namespaces here, so I'm not root on the host. I really can't do a lot of damage on the host, but I can do quite a few damage to the container. I can take LN for instance, which is a pretty innocent command, but I can do like a copy. Let's copy that to another executable or maybe download an executable or do something that is going to add some code to the container that was not found in the image and then let's try to run it. Well, we can't run it and the reason why we can't run it is that one of the fundamental policies in Aqua is to prevent drift between the container and its image. So one of the ways to allow for a more free usage of containers is to limit what can be done to them once they're instantiated. So even if I change a LN itself, let's copy ping to a LN for instance. So we could use a LN while it was the right command. Now we can't use it. So all of these things are designed to make sure that if a container is running and instantiated, there's very little that it can be exploited by that container and that's called drift prevention. This is actually what allows us to then go back to our list of running containers and do some search. Let's search for a vulnerability. We're able to search throughout the environment for a particular vulnerability and get all the containers that run from it. This is an instant impact analysis. We can go into the containers and look for a particular package or an executable and look at all of those that run Python. And this is relying on the fact that we know that the container is based on an image. We've already pre-assessed the image. We know the security posture of the image. We know the components of the image. And we're also preventing any addition of executables that can be run from the internet or from anywhere else or even something that was written as a script inside of the container. So the idea is that in order to maintain that assurance that images are known, only known images can run, only containers can run from known images and they cannot change from the known images allows us to have that assurance and to end that the images that we are running are indeed the ones that we expect and we can actually provide that search capabilities between them. Once that happens, we can then again go back to the list of executables and all the other resources that we found in the container. And I'm switching from WordPress to JBoss now because it's a little bit of a shorter list and we can actually make it into a more complete profile. So this is a profile that is based on JBoss and we can see that the files for it are actually just seven executables that it needs to run. We can add a lot more things to the profile. We can add whether or not the container needs networking at all. If we can add read-only files, if there's a configuration file in the container that should not change, we can control the executable list. We can control the user context in the container, right? WordPress, run as root to JBoss is actually a little bit better. There is a user ID that is specific to that. This is the parameter that tells us not to run executables in the original image. We are preventing running with privileges. So this is in the case that a container instantiates a spillage outside of the OpenShift controls. And then we can add things like a second profile, which can be a little bit more granular than SC Linux and can run per repository. We can drop capabilities, control the volumes for the container, control the limits, again, in a way that is complementary to what the specifics are in the deployment for that particular container. And we're getting to a situation where a particular application can now be even more limited in how it can run. And the way that we do that is that if we run our application and we're going to supply some parameters to it and we're going to give it a name, give it a port, and so on. So it's a little bit more in line with how a deployment would look like. But then let's try the same thing. Let's try to do a Docker exec and try to do basically what we did with WordPress. So this is my app and I want to run BashWit. And I'm getting permission denied off the bat. And that's because root is not an authorized user for this container. Root is something that should be reserved to basically nothing. Really, a container should not be run at all with root. If we eliminate that, what we're doing is we are doing a failover to the user that is defined in the image and that's the JBoss user. So now we are in the container. But you can see there's a bunch of permission denied there. And that's because anything else, ping, ls, ps, curl is really not, really shouldn't run, right? Even though it's available inside of the operating system, it really shouldn't run. And the reason why it shouldn't run is because it's not in line with what this container is supposed to do. It's not in the list of authorized executables. In this case, this image is not well built. If we add or let's say that we just move this to an audit only and we save this, now we do have ls and the bin directory is just huge. There's a lot of stuff in there. So something that I probably should have mentioned in the beginning is that size really does matter. The smaller images usually have less of an attack vector. This has a huge attack vector. Anything here can either have vulnerability and can be exploited. So if you're using big images, which sometimes there's a reason to, limiting the processes that can run to something that is only required for that image is going to greatly improve the security posture of the entire environment. So let's go back and reapply my policy here. And let's take a look at how we're actually passing parameters to a container. So secrets management is something that is talked about a lot. In the last DockerCon, I must have had 50 conversations on secrets management alone. And there are some organizational issues with using the built in secrets management inside of the orchestration tools. Not that they're not good, it's just that they don't play nice with the rest of the environment. So as an alternative to that, what Aqua is doing is we're using our capabilities to interface into containers to provide some aspect of secrets distribution. And the way that we do that is that we have our ticket distribution on the front end, as far as the nodes are concerned, and our back end can be a variety of integrations. So it could be a hashical vault, it could be the Amazon key management services, Azure key management services, or maybe even our own internal database that can provide those secrets. And they really live outside of the orchestration because security sometimes wants to control them, right? Orchestration may be a little bit too controlled by ops. But if you run our application, what we're seeing here is that we have our user here, which really should not be encrypted. We have a token here, which maybe should not be encrypted. And we have something that is coming from a vault somewhere. So if we do basically a Docker inspect on my application, and let's do grep so we didn't get a big block here, you can see that the unencrypted is still unencrypted, that whatever is tokenized is still tokenized. And my token here is encrypted and we really can't see it anywhere outside of the container. So where is this secret coming from? This secret is coming from, in this case, the Aqua internal database. It could come from hashical vault. It could come from the key management stores. And first of all, we get tracking of which container is using it. So that's really important because if that leaks out, you want to know the impact. And we can actually change the value. So we can put here something, you know, open shift and save the change. And that gets transmitted directly to the container. So if we go into the container and take a look using an exact command at the environment variables, we are getting that value that is being decrypted and handed off to the container. So that secret management is something that can be done external to the orchestration. It can be under the control of security and not ops. You can mix and match. So if there are secrets that are very, very operational in nature and you still want to keep them in Kubernetes and make sure that they're part of the system, you can still use them. If there are secrets that are more corporate that need to be put into a separate vault or there needs to be rotation on them that is more automated, then you have the ability to do it with Aqua where Aqua is actually distributing that secrets to the environment. And everything that we've done so far is also audited. So we audited the fact that we've changed the secrets. So that's important. That's something that security really needs to know is whenever secrets are rotated. We've seen all the Docker inspect and start commands. We've did a lot of detection of the file execution. So this is where LS was was permitted. This is where all the file execution inside of the containers were blocked. And you can see the difference between the detect and the block. We're getting the actually original users. So this is me logging on to the container to the host, even though I did a lot of work inside of the container. So that's something that usually the compliance organization is interested in to figure out who did what in the environment. But we're getting a lot of information. And really at the core of it is the notion that we have the opportunity to do better security with containers. So if you have security people that are resistant, please tell them that containers are actually good for security. And somebody who's been doing security for 20 years is saying that. And that is that we can do all of these capabilities. I'm not going to read them out loud. But these are the things that are important for security. And these are the things that we can execute in a containerized environment, which we should provide us with the ability to run meaningful workloads in scope applications and applications that are subject to regulations based on the security needs of the organization. So I hope this was beneficial. Please visit aquasite.com. There's a lot of information there. You can read some of our white papers. You can look at the OpenShift partner page to take a look at some of the specific things that we do around OpenShift. But I'm going to open it up for questions if there are any. All right. Well, thank you very much, Sevi. This has been, it's been really, I got the demo when we were at KubeCon, but I didn't go into this much depth. So I really appreciate it. It's great stuff that you guys are doing. There have been a couple of questions. And I think what might be the easiest thing to do is if I unmute Peter, who's been asking most of those questions, Peter, you're unmuted now. Why don't you go ahead, Peter, and try and frame your question. And that should kick off some conversation. Sure. It's basically, I'm trying to figure out the scope of the scanning. A lot of the questions we get is about compliance. And that's the concern. It's not just the CVEs, but it's also, is the server actually allowable to go into production? Hence, is it following government standards for what it was security standards you have to apply? So that means that the scanner, when we do an OpenSCAT scanner, for instance, is mostly interested in the configuration of the components that are running, not just that they're running on the right and the latest binaries and all that, but that they might not allow bad things. Examples could be allowing root logins on SSH or Xiaowan or even 256 for encryption and stuff that are all not allowed by, once you get up to just even a minimal level of security. So I was just wondering if those kinds of files included anything from JBas to the Apache and so on, part of what you're evaluating are those configuration files? Yeah. So we are evaluating the makeup of the image in addition to the file. So I didn't really go into the policy, but one of the things that you can do actually, and you said that, is identify images that are, where is that control, right here, identify images that are defaulting to run as root, right? So that's equivalent of the, is root open to SSH on a server. The configuration requirements are going to be a little bit different because containers really should not have direct access to them, but you're absolutely correct that the, both the vulnerability and the configuration really needs to follow the guidelines of your server environment. So we're actually using this as a preview in the course of the next couple of months. We're going to release a version that has the ability to run code snippets and script snippets to assess the security of certain elements of the operating system, and also SCAP support. If you're using that, if you know how to use that language to provide a structure that can be, that we can assess the image against. And we definitely recognize the fact that vulnerabilities are not the end-all be-all of the security posture, but the actually configuration of the image, whether or not an SSH key was left in there, whether or not your web server is running under SSL, all these things are important questions, and we are adding those to the image assessment part of the AquaTool. Does that answer your question there, Peter? I think he's muted himself again. Yeah, I try to be nice and not make any noise. Yes, that answers my question. Okay, perfect. And it gives me a perfect way to segue, and we're going to have to have you guys back again when you get that next release out with those new functionalities to show off that as well. So keep us posted. We're almost to the end of the hour, and I don't see any other questions. I'm wondering if you have anything else you want to add, Sevi, or if Apesh wants to butt in and ask any questions at all? I think most of the questions got answered in the Q&A, and they were questions that preceded things that you then explained in the slides and in the demo, so I think we did a pretty good job of covering everything off today. I had a quick question. So did you guys say that you are looking into doing the scanning using SCAP and SCAP profiles? That's in the roadmap. Is that what I understood from the end, that end question? Yeah, so the intention is to have a feature where you can either have a small shell script that checks for something or an SCAP expression that can check for that thing. All right, and thanks for asking, Lucy. Anyone else have any questions? If not, you can always check these folks out on aquasect.com or jump on Slack. There's a couple of them that are in the Slack channel for OpenShift Commons or hit them up on the mailing list as well. So again, Sevi and Apesh, and I think Raini was on there as well answering questions. Thanks very much, and we're really pleased to have you guys as members of the OpenShift Commons and look forward to hearing more from you in the future. Yeah, thanks very much, everybody.