Hi and welcome everybody to this course on analyzing software using deep learning. This is a course at University of Stuttgart in summer 2020. Usually this is not an online course, but because of the current Corona situation this year it is an online course. And the good news about this is that everybody can enjoy this course no matter whether you're enrolled at University of Stuttgart or not. So what we'll do in this course is to look at the intersection of two fields namely program analysis and machine learning and more specifically deep learning. And this intersection of these two fields has emerged as an interesting and exciting topic only a few years ago. So most of what we'll do in this course is based on relatively recent research from the last five or so years. But at the same time a lot of these ideas have already transitioned into industrial practice or are in the process of transitioning into industrial practice. So it's a really interesting mix to be in. So before we start with the course, let me say a few things about myself. My name is Michael. I've been a professor at University of Stuttgart since fall 2019. Before that I've studied a while ago at a couple of universities, TU Dresden in Germany, E-Course on Paris and Paris France and also EPFL in Lausanne, Switzerland. After that I went to ETH Zurich also in Switzerland for my PhD followed by a postdoc at UC Berkeley in California. Then I went back to Germany to become an assistant professor at TU Darmstadt. Then back again to California to spend sabbatical at Facebook Menlo Park to see how software development works in practice and then finally I came back again now back to Germany and now I'm here at the University of Stuttgart. So I'm leading a research group called the Software Lab which has been my group since about six years. What we do is we do research that focuses on tools and techniques to help developers build better software and what better means can be many things and can mean more reliable software, more secure software or more efficient software. To do this we use a mix of techniques including a lot of program analysis techniques and a lot of program testing techniques and more recently also a lot of learning techniques in particular deep learning techniques. So what we talk about here in this course is really right at the core of our research interests which is why I'm pretty excited about this topic. If you are a student at the University of Stuttgart we regularly have opportunities for master thesis also for other kind of student jobs. So if you're interested in any of this for example on any of the topics that we talk about here feel free to contact me. The course is split into different modules and every module has a couple of parts. So this is the very first module called introduction and in this very first module we are in the first part which tries to give a bit of a motivation for why this is an interesting topic. So as I said this course combines program analysis and machine learning so let me start by saying what program analysis actually is. Program analysis is an automated way of reasoning about the behavior of a program. If you have ever written a program which I hope you have otherwise this course is probably not the right course for you then you have of course reasoned about programs. What program analysis does is to not do this manual but to automate this process of reasoning about a program by essentially having a tool that does this reasoning for you. Why do you want to do this? Well for many reasons. One of them is for example that you want to find programming errors or bugs in your code and want to have a tool that tells you where your code might be wrong. Another reason might be that you want to optimize your performance or maybe just better understand the performance of your program so that you can later optimize it manually or maybe you want to find security vulnerabilities in order to avoid being attacked by malicious people. So how does such a program analysis work? So let's first have a look at how a program usually works. So typically a program takes some input and then produces some output based on this input. Now what a program analysis does is to also provide you some additional information about this program. For example it might tell you that if the program gets this input and produces this output this output may actually not be what you want so there may actually be a bug in this program. Now an analysis can do this for one input and one behavior that the program has triggered by this input. But of course what you ideally want is to not only do it for one input but for many inputs and maybe even for all inputs that this program might ever take. So why do we need all of this? The reason is that program analysis is at the core of many developer tools that software developers are using in their daily work. One example is a compiler. So if you're compiling your code then under the hood a program analysis is running and it's for example type checking your code and making sure that you do not have any type errors. Likewise if you sometimes get some warnings in an IDE that tell you that maybe this particular piece of code is wrong then the tool that has emitted this warning is a program analysis that tries to reason about the behavior of your code and tries to reason about what may be right or what may be wrong. Another example of a program analysis that maybe some of you have used is a performance profiler which looks at the execution of a program and then tells you in which parts of the program a lot of resources such as CPU time is spent. Yet another example that I'm sure everybody is used in one way or another is code completion. Very often code completion is built into an IDE and tries to complete your code by basically helping you choose what parts or what tokens to type in next. And under the hood this of course is again a program analysis because the more the code completion tool understands about your code the better its suggestions will be. Yet another example are automated testing tools. For example the monkey tester for Android is such a tool which automatically uses your application and tries to make it run in order to expose for example bugs. And then there are many many other tools like code documentation code summarization tools and many others all of which developers are using very regularly and all of which are based on program analysis. So where do all these program analyses come from? So the traditional approach to create a program analysis is to have an expert in program analysis. For example someone who did a PhD in this topic sit down and take all the knowledge that he has about programs and about their behavior and then writes an algorithm which is called the analysis that tries to solve a particular problem for example finding a particular kind of bug. Now this is a good approach but it requires significant human effort to create a program analysis. One of the reasons is that there are a lot of conceptual challenges. So how to effectively reason about the possible behaviors of a program while scaling too large programs. Another reason is that even if all these conceptual challenges are solved there is a significant implementation effort in order to make sense of the code and really understand what's going on. And all of these factors are the reason why it takes pretty long to build a new program analysis and why typically only a few experts can really do this. Another property of this traditional approach is that a traditional program analysis analyzes a single program at a time. So it's meant for analyzing arbitrary programs but then at a given point in time it's analyzing one specific program. Now the motivation for this course is that as an alternative or maybe as an addition to the traditional approach you can learn a program analysis from existing data. One reason is that there is a huge amount of existing code sometimes referred to big code as in big data which we can learn from. And the reason why learning works pretty well on source code is because programs tend to be pretty regular and repetitive. Of course every developer is an individual and everybody writes different code but if you look at a lot of code it turns out that programs tend to look the same over and over again and there are many interesting properties that are repetitive across programs even written by different developers and even written in different application domains. Now machine learning and in particular deep learning is really good at extracting such knowledge from large amounts of data and seeing patterns that may not be obvious if you just look at individual examples but become obvious if you look at a lot of examples and to apply this knowledge in new contexts. And by using this idea learned models on code have been able to for example complete partial code so they essentially give you a code completion mechanism or they can tell you how to use an API by learning from existing API usage examples and then telling you as a developer how to use that API. Such approaches can also learn how to find bugs or maybe even fix bugs because they know how incorrect code looks like and they know how to make the code correct. And you can for example also use such learning-based approaches to create inputs for testing where you have an approach that automatically exercises a program by learning how to make best use of the tested program. Out of the many machine learning techniques that exist, this course will mostly focus on deep learning which is a specific class of machine learning algorithms. Deep learning refers to neural network architectures and the deep refers to the fact that there's not just a single formula that takes some input and transforms it into some output but usually there's a sequence of different layers and transformations that transforms the input to the output. Another important feature of deep learning is that you do not have to explicitly specify the features that your data, in our case for example your program has, but the features and also the representation of this data for example programs are extracted automatically. So basically what you have to do is to give the programs in some suitable format to a model and then it's automatically learning what parts of the programs are most relevant to solve your task. Deep learning has already revolutionized a couple of other areas, for example speech recognition where now your phone can understand what you're saying basically because there's a deep learning model running somewhere that understands what you say. It has revolutionized image processing and can really precisely tell you what is on an image and it even works pretty well in game playing and can compete with human players at the highest level. An area that deep learning has only started to revolutionize is how to make software developers more productive. And this is exactly what we look at in this course. So we look at this intersection of program analysis, tools that make developers more productive and deep learning. So automatically learn models that in this case will help us solve some of the program analysis challenges. So what we'll do here in this course is to cover some of the basics of these areas. So we look into some program representations, for example. So different ways of representing a program that go beyond what you typically see as a developer when you're coding. And we'll also look at some neural network architectures that are most suitable for this specific task. Most of what we'll cover here is based on recent research results. So basically ideas that have only come up in the last five or so years, which means that there's not really a textbook to look all of this up, but you can of course read a lot of this material in some of the recent research papers. To give you also some hands-on experience and a really concrete idea of how this intersection of deep learning and program analysis works in practice, the course also comes with a coding project where you will design and implement and evaluate a learning-based program analysis and so get a very concrete idea of how all of this really works. So now you know what this course is about. Let me also tell you what this course is not about. So this is not a detailed course of program analysis. This is also not a really detailed course on deep learning or machine learning in general. And despite the fact that there is a course project, this is not a tutorial on any machine learning or deep learning library. The reason is that there are plenty of other resources that cover these different really interesting aspects. For example, I'm also providing a course that is typically taught in the winter semester on program analysis, but this is not what we'll do here, but this course is really about the intersection of program analysis and deep learning. All right, and this is all I have for this very first part of the introduction to analyzing software using deep learning. I hope this sounds interesting and you stick with me for the rest of the course. Thank you very much for listening and see you next time.


Hello. Welcome back to the Security Dev Room. We are here to hear a talk by Jorge about container security. Please welcome him. Hello, everyone. Thanks for coming. I'm going to use the next 20-20-something minutes to... Sorry. No, you're showing me. Yeah, okay. That's good. I'm going to use the next 20-20-something minutes to tell you something about container security. How many people here are using any kind of technique or strategy to keep an eye on what are your containers doing from a security point of view? Okay. So, hopefully you can bring something home. Who knows SysDec here? We are not in the cloud on monitoring track. So, SysDec is an open-source system troubleshooting tool with container support. So, you can think it's like a mix of multiple tools, HSTOP, VMSTAT, like all the tools you normally would use for troubleshooting, but with container support. We also have a commercial tool, but I'm not going to talk about that. Microservices. We love microservices because they are good for security. Least privileges, least surprise, less access. But there are, in the same way that for bare metal servers or traditional servers, there are many ways of implementing security measures for containers. We got the same thing. But I'm not going to talk about this today. I want to focus on one specific technique. There are multiple of them that you should be using, multiple of them. But we are going to talk about scanning. The containers, they are like black boxes. They are great to deploy. They keep the application there inside, less dependencies, just one process, hopefully. But from the outside point of view, we cannot see at least very comfortable what they are doing. We have two techniques to scan what those containers are doing. We can do static analysis, which basically means scanning the Docker container image before having anything running. And we can do dynamic scanning. And this is, again, where I'm going to focus. Static scanning, why we should be doing this? Well, probably you have seen Docker files like this, where we download crap from the Internet without any kind of HTTPS, without any kind of signature check-in. And then we compile things. So we leave for hackers all the tools to compile their own stuff there. And then developers, they never update those images. This is very dangerous. That's why we have static scanning. We look at what the containers are, how the images they are built. We look for non-vulnerabilities, and we trigger on those. But is that enough? Well, explain here how it works, but probably you know, or you can find it on the Internet. Okay. We scan the image. No known vulnerabilities. Is that enough? Are our containers secure? Well, even there is nothing known or no vulnerability known. These are usually coming from CVE or any other vulnerability databases. Still, when we shoot our own applications or things they could be misbehaving, we need to look at how those containers they are executing. And again, we have two options, so two strategies here. We can enforce. So it's more or less we will see this in a minute. We can enforce on prevent things from happening, similar to up armor or SA linux. Or we can just audit and keep an eye on how things are doing. And if there is something not expected happening, we will let the admins know. Pretty much like security webcoms. This is, these are the different tools we got for dynamic scanning sitcom. We can do with sitcom BPF, we can do more advanced profiles so we can define capabilities and define wireless syscalls. We allow the containers processes to execute. We can use systems that we know already like SA linux or up armor. And then we can also audit with AuditD, which is the login diamond from SA linux. But we have come up with something new using the SysTech technology, Falco. I'm going to compare a little bit with the other systems, so I'll give you a little bit of context. Second, basically, it's sandboxing the container, the process. Basically, we do one transition, one-way transition into a process, into a state where that process, they cannot execute or can't execute only some system calls. There is a strict mode that basically only allows to read, write, exit and return. In practice, in real life, this is pretty much useless because you cannot open new connections or spawn new threads. And when the process does any other system call, it's killed. So with BPF, we can create something more useful, which is creating different profiles of wireless system calls that that container or the processes running inside the container, they can execute. And then we can define different actions. If we want to kill the process, if we want to trigger and alert, if we want to skip and ignore the SysCall, so it's more advanced. This is actually available in Docker already. You can drop capabilities, things like that. There are some system calls that they are obviously wrong if you're running those inside a container. Imagine that your container could review the whole host. So it's obvious using this if we want to do some basic security. But still, Seccom doesn't give you all the flexibility and all the features. So that's why we got SELinux and AppArmor. I'm not going to compare them here. I'm not an expert on this. But these systems, they come with more features. And at the same time, they are more complex to deploy. They have concepts that they are above SysCools like processes, files. So you can define those higher level objects when you are defining your policies. But still, it's complex. It's complex. A difference also compared with Seccom is that these systems are mandatory. If you define that they are running in the kernel, processes, you cannot avoid them. Seccom is something voluntary that your process decides to adopt. Another option for just watching is AuditD, which is the login service from SELinux. Defining real is more simple than SELinux. So we can put here a couple of examples. So there is kind of a syntax. But still, it's missing higher level concepts that we think they are quite convenient. So that's why we created SysDec Falco. SysDec Falco is an anomaly detection system built on top of SysDec Engine. SysDec Engine, basically what we do is we load a kernel module, a very small one that allows us to capture all the system calls and we move those into a user space process where we decide what to do with them. We have an event in the stream where we get all the system calls, but I'm not going to get here into the details. The benefit of this is that for every system call, for every event, we have all the context, the users, the IP addresses that we are related to, that system call and everything. So we came up with a piece of software that allows to define a very easy way, different rules. We cannot block things, we can just alert. This is like a security welcome sort of thing. And then because we are running in user space, we can do things that you shouldn't do at the kernel space. So I said before, we work very well with containers. So given that we are in the user space, we are able to talk with the Docker API, with Kubernetes API, with different container orchestration API to apply those metadata, those concepts in the security and in the rules that you define. So I'm going to give you a few examples. So if someone runs a shell inside of a container, defining a rule similar to that container ID, it's not the host, so we are not in the host, and then the process name is bash. If something like that happens, trigger alert. Or if someone is writing a binary, so we do FD directory and then on our right of different protective directories and executes a right to school, we trigger alert. Or changing a container name space, things like that. So we use those conditions or those rules in, yeah, conditions to create rules like this. So this is an example of a complete rule. So we have a name, a description, the condition. If we are in a directory that we know, and there is an event that opens one file for writing, and it's not one of the processes that we have on a list, that we know that they are package management software, it's probably something writing in a place that shouldn't be happening. So let's create like a message and trigger it somewhere. We can trigger alerts into different places. Syslog files, execute shell scripts, send it into your login system. This is completely up to you. So now, because I have a few minutes left, I'm going to show you a demo of how this works. And I need both hands, so, okay. So you can hear me like this. Yes? Okay, so... No, that's not going to work. Yes, please. It's going to be just five minutes. So basically, I have here, I have Node.js service, which I know it's vulnerable to some cold injection because I created, not because I'm a Node.js security expert. So I'm going to create or spam this together with Falcon. So I have here some nodes. So if I... Let me remove this. So when I access this web service, it returns like just one number, but I know that if I insert some code like this, it's going to execute it on the server. Okay, you can see here that when I insert into this endpoint any JavaScript code, it executed. So I created a reverse shell. Let me find it here in my notes. Dad, it's going to connect back to me. So I open NetCut and I do... This is demo effect, probably. Yes, I'm not in it. I'm in the wrong directory. So hopefully, if not the IP address is wrong. So hopefully we'll get here a connection. Now we are not going into connection. So let me find my IP address that probably has changed. Probably it. Not very efficient, but...  So now quickly connect to that IP. It was... 17... Oh, I forgot. So I'm showing you how to find out your IP address. And hopefully now this works. No. But I can show you... I can show you Falco output already. Okay, so I got here the output. Okay, well, I'm not going to lose more time with this. Hopefully you will have to believe me because what I want to show you is that this is how my Falco Diamond... Not very convenient having all these terminals here. So what I want to show you is that... No, I can't hold this. I'm not going to do that anymore. So this is one complete example of a rule. Run shell in a container. I created, okay, there is a new spawn process and it's a shell process and the progname exists. And it's not one of those binaries, trust the binaries that I believe can do things. Some changes I wanted to show, but we don't have time, then trigger and alert. And if we go back to my other console where I have Falco, we can see that Falco is triggering alerts like this. It's probably at the bottom, but hopefully you can see it. So these are the kind of outputs we can trigger. Now you can send this to your ELK or any other login system or alerting system and just keep an eye on what your container is doing. This is everything I have for today. Well, I have way more, but I don't have more time. So it's probably a good thing if you have a look at these links I left here. More deep comparison of Cessic Falco with other Docker container solutions. Another example or an example of Falco for intercepting or preventing someone else intercepting when I download software from the internet and shell scripts and I run them as route. So preventing someone injecting things there and Falco website and GitHub. And probably we have now like four, three minutes for questions. Anyone? Thank you. We have actually seven minutes for questions. Raise your hand. Yeah, there's one. Raise your hand so I can see it and I will come with a mic to you later. Thanks. So I'm not sure whether I understood the rule system correctly. Is this about allowing containers to do certain things or disallowing? Is this black listing, white listing? Can you do both? You're going to be running around. So the question was if this system prevents containers from executing things or not, we don't block them at all. We just watch and alert. If you want to block containers from executing things they shouldn't be doing, it's more complex. So it's more difficult to bring it into production and you need to use SecComp, SELinux or AppArmor. There is no other way integrated with open source products so far. Our approach has been, okay, that's complicated. Probably you should be doing it as well, but the first step is to keep an eye of misbehaving processes and alert on that. Any more questions? Yes. Do you have a standard rule set? Yes. Yes. What I show you, is Falker rules, which I'm going to open on read mode. This is messy. It's the default rule set that we keep improving and improving. We have started, this is a very recent project and it's still in heavy development, POC more or less. We have started to create default rule sets for some of the most popular services. So, Subkeeper, Kafka, Memcache, a few others. So, MongoDB. So when you are running those, you can come here and enable those rules directly. I have a question about the output of Falker. I know that you can enable the login output or sending the output to a program, but it's possible and I don't know. It's possible to enable the shell. When you trigger a rule, trigger a shell that does something in a specific rule and not in all the rules, because sometimes you can, of course, send the output to a program and then you need to filter the events. Like, okay, when this happens, do this. I would like something like, when this trigger, this rule is triggered, please inform the output assistant, but also allow me to run a shell. I don't think that's possible at the moment, but rings me the bell, it's in the roadmap. In worst case scenario, you could do a second filtering phase in your script. But yeah, it makes sense to have something like that. Yeah, yeah, it makes sense totally. Over there. How can you start this monitoring agent? So, in Docker Compost, do you have additional container? Yes. So, for convenience, we run everything on a Docker container and I expose my configuration file inside. You can run it directly with Docker, run, you can schedule it with your Kubernetes or whatever. The idea is we need to have one file instance in each of your physical hosts. And from there, we get visibility of all the containers running on that machine. Anyone else? Yeah. No? Okay, now let's thank Jorge for the talk. Thank you. Thank you. Sometimes, not all the time.


Everybody forced here ripping three boxes for Luke T. Luke has a 2021 Donner's Hoplick basketball hobby hybrid a 2021 prism football team all and a 2021 top scrim F1 sapphire Thanks for the order Luke here we go. Let's start with prism team all go to optic hobby hybrid And then we'll finish with the F1 sapphire. We'll base their rookie base semi-fajoco That's new some silver rookie Jake funk And a red and yellow Bradley chub Number 17 of 39. I do see some light scratching on the left of this card. I'm gonna send the empty box and wrapper So you can get this card replaced With panini optic basketball hobby hybrid from 2021 See a gold. Come on gold big rated rookie. Skyler maze. There's a Tyrese maxi rated rookie There is a gold after this red non-numbered to Montesa bonus. Maybe it's gold. Maybe it's just team color It's gold to me. It is gold 10 of 10 elite dominators LeBron James Congrats Luke Sick LeBron James Get that magged looks pretty sweet got Tyler Bay color match. Needless to say with the Lakers Devon Vasell Hello, Rudy Gobert blue, non-numbered Devon Vasell rated rookie And red Ben Simmons stargazing Brown McDaniels and on the mellow base now blue Jimmy Butler Red Kevin Hoarder and an auto coming up. How about that? That's pretty cool Ricky pier signature series Ricky pier 17 of 17. What a freaking box Auto is not guaranteed in the hobby hybrid low number two holler rated rookie CJ L to be Tyrese maxi on the red Start to finish. This is a great box nice maxi red and then all stars to go to yoke. It's F1 Sapphire. Let's see a monster Starting off with a Vettel and a green a Lewis Hamilton Lewis And it is the short print photo variation What a monster? Luke is killing it y'all Luke is killing it Luke. I see it in chat monster congrats What a card what a card. There's a max as well and a Marcus Armstrong Huge huge Lou Ham Fernando Alonso Vettel Fernando Alonso Juan you Joe Yeah, yeah a little easily took pure ghastly Leclerc Okon and Schumacher This was pretty bonkers couple of last boxes here. Oh an orange after the Daniel Ricardo his David Brevio 525 Daniel Ricardo Charles Eclair. We top load all the Sapphire cards Zendali with another orange. It is a Lewis Hamilton Grand Prix winner Bob Rain nine of 25 Broken box is broken Oscar piaz tree and a voluntary boat us That's how that's what I'm saying. Okay, dude. Oh Man Luke may Liz Luke might be unconscious now Yuri Vips George Russell George Russell max for stopping Crazy crazy Sergio Perez green Sergio Perez Grand Prix driver of the day Portugal 14 of 75 Daniel Ricardo Andrea Seidl the skull signs and that'll do Luke Congrats because right now to you