 It's 11.30, so go ahead and get started. My name is Eric Brown. I am an open source engineering manager at VMware. I manage a small team of folks that contributes 100% of their time doing patches upstream. But prior to being in management, I also did quite a bit with security, specifically with linters and tooling. So today, we're going to talk about your open source security liners suite. And I wanted to dive into why this is important, why, you know, what the heck is static code analysis and what tools are available. I saw this on a recent hike. So I thought this was a very security-mining person. He's got eight locks to lock this gate to nowhere. Pretty much exemplifies the message nowadays that we need more security and we need to have that mindset with the software that we develop. So why is it so costly? So in the development life cycle, with any bug, the sooner you find it, the cheaper it is to fix, right? And this is a chart way back from 1996. And this totally still applies today, except for those crazy low-price numbers. But when it comes to security, it becomes even more expensive to fix post-release. And it actually damages the reputation of your business, too. So in terms of business impact, it's very costly. Like you've probably heard about a lot of the breaches with Target and other companies. And there's actually a company called Zerodinium that actually will pay for exploits, right, to get them out of the black market. And they pay huge sums, but at the top there is a million dollars. So it's very essential we try to secure our code as much as possible before they enter into mainstream. And the types of security bugs keeps changing year to year. And so we need to educate ourselves on the types of issues that can arise in your code. Nowadays, you see a variety of these attacks where they use multiple techniques at once. It isn't necessarily important to know the percentage of attacks per year, but it is important to educate yourself to know how these things occur. So what is the struggle in fixing this? So there was a survey done that said only 26% of companies ignore the security bugs just because they don't have the time to do them. And I've seen this with development teams a lot where security is kind of put on the back burner, right? And the feature function is the priority. So security is actually more important to get in place earliest in the dev cycle and plan for it not being an afterthought. So as I said, education is essential, right? And it's the first way as a developer that we can better address these problems. And there's a plethora of coursework out there. You go to YouTube, Pluralsight, whatever it may be. There's plenty of courses out there to learn up that every developer should learn about. Supply to front-end developers, back-end developers, whatever it may be. Books are good, but books become outdated rather quickly. So reading a book from 2005 on security probably is not going to help you much today. But if you want that in-depth knowledge of how something happens, it's good to read. And then finally, attending these conferences, attending sessions like this to learn more is essential, I feel. As far as tooling, so education is good, but you always have developers that don't necessarily aren't as educated about potential problems. You can catch some things in code reviews and peer review. But tooling is an excellent aid to supplement finding these problems. And number one, I tell everyone, is unit test, right? Every bit of code, you essentially don't know how much code works until you've unit tested it. And target, like, 80% coverage when you do that. And you'll flush out a lot of the problems that may occur. Secondly, one of the high priority things to do nowadays is your code may be perfect, but, however, you may depend on numerous number of packages that aren't. And GitHub, and there's a plethora of other tools that do dependency checking. And will notify you of potential packages that you need to upgrade. So definitely, that should be part of your tooling in your product. And then finally, the static code analysis, which I want to talk about today, is the other tool in your tool chest, I guess I should say. So what is a linter? So linter is a source code analysis. You don't have to build the code. You just give the source. You use something called the abstract syntax tree, which is the same as what a compiler uses to look at your code. So it's more sophisticated than just grepping your code. They tend to focus on common mistakes, right? And some of the examples that you'll see per language, like if you're a Python guy or a girl, you might be Pylint, Java, CheckStyle, ESLint for JavaScript, and Golint for Go. And these are the ones that focus mostly on style, not so much security. But we should be running these linters, like I said before, as early in the development life cycle as possible. So integrate them into your IDEs. There are a lot of plugins out there for existing tools. So integrate those, fix them as you code. And then secondly, they should be in your CI system in some form or fashion. So if you use Travis CI, if you're open source and you use Travis CI, Jenkins, whatever, there are a lot of plugins to integrate various linters into them. The downside, the number one downside is false positives, right? You may get quite a bit of false positives. The more code you scan, the more false positives you gotta go through and look for, and that takes a lot of time to do. There are ways to mitigate that by looking at only high severity or looking at only the high confidence issues because there usually is a level like that. But these tools are just tools and they're not meant to replace humans. So they're meant to supplement the human code review. And there is a marginal time that your CI system would also have to run these tools, but that's pretty marginal. So the first tool I wanna talk about is Bandit. The last one is pretty near and dear to me because I work on it as a maintainer. I was there from the very beginning back in 2015. So it started when a group of OpenStack developers like myself went to a local meetup for OpenStack with a security mindset and they identified that there was no real good linter when it came to Python. So over the course of that week, they integrated it into Git. We integrated it into several of the projects in OpenStack, started running with it, found a bunch of bugs, which is great, and it got those fixed. But now it's migrated out of OpenStack just because there was nothing specific to OpenStack, so it's now part of the Python code quality authority. And it runs on all major versions of Python, including a testing of 3.8, which is still in development, runs on Linux and Mac. It probably runs on Windows, but we don't officially test it on Windows, so we don't claim that support, but it would probably work just fine. And it's very pluggable, so you can write new plugins to extend it. One of the plugins that was added was company lift, same one, your ride sharing service. They added a plugin to look for high entropy strings so they can find private key files and check into code, which is pretty neat. And it runs quickly with minimal resource, so it works rather well with your CI. So the types of issues it can find are use of cert. Some people don't realize in Python that if you have an assert as a conditional, that will get compiled out. So it'll flag that, checks for hard-coded passwords against a set of patterns there. In some cases, you'll find code that tries to write files to slash temp as a hard-coded name, when you should be using the API to do that. So there is a check for that. And weak cryptography, so like legacy algorithms like DAZ or just using two small keys, it'll find insecure protocols like Telnet, FTP, things like that, it'll flag. One of the big ones that comes up a lot is, you'll find code that isn't doing proper certificate validation. And developers tend to get a little bit lazy when they make these connections or if they have self-signed certificates in place. And to avoid the errors, they just turn that flag off and say verify false. And then that gets into production and then it's not, then you have a vulnerability and as a result, because you're susceptible to a man in the middle attack. So the output goes to standard out by default, but there are a lot of output formatters that you can customize or choose to use, depending on whatever integration you're gonna plan for. And one of the cool extra ones with Bandit is this custom one, so you can actually create a template and within that template define whatever type of format you want. But it covers all the major output formats you would probably see or need. So you can filter by severity and confidence, which is quite useful. You may want to only look at high and high confidence, high severity. You can create plugins where you can customize just about everything that Bandit does under the covers. So you can customize a specific test that looks for certain functions and you can modify which functions it looks for. So in the output, which I'll show a little later, it'll group the snippet of the code and the offending code and you can change the lines of output of that. So if you just want to see one line, you can do that to make your report smaller. Group the results, you know, pretty basic, but to address the problem with false positives, it does have this technique where you can add this comment that says no sex on that line and Bandit will effectively ignore that line. So this is what a typical config looks like. This I grabbed from GitHub, from Netflix. So they're using Bandit inside their TOX INI file. So TOX is similar to a May file kind of system. And what's slick here is they're using the INI config to do like command line parameters and then just referencing itself in the TOX.INI. So they have this Bandit section where they're skipping one of the tests. So a pretty slick way they're using that, but it makes it pretty convenient to have that feature. But if you really want to get for the power user of Bandit, you can customize through this Bandit YAML and that's where you can run this Bandit config generator file and it'll dump out a Bandit YAML and you can customize the plugins however you like. And there's some documentation too that defines how some of these things work. So in terms of use, Bandit is used quite heavily. So these are stats from GitHub and there are over 1200 repositories on GitHub that are using Bandit to scan their code. So pretty cool. If you want to integrate Bandit into your IDE, it does support Sublime, VS Code and Flake8 and Jenkins. There's this thing called PI report card, which is equivalent to Go report card if you're familiar with that, but it'll give you a report of the health of a project. And so it runs various linters and other things to determine this health and actually Bandit is part of that health metric. So this is what it looks like when you integrate it into Sublime. So right within your code, as you're typing, it will show this red or yellow dot that will show the flag, the line of sending code. In this case, the RSA key size was too small. And if you look on the package control for Sublime, it's like over 15,000 downloads so far. It's pretty good use. But VS Code is similar. It shows a red highlighted line of the offending code. And then this is a sample bit of code. I think I either took this or crafted it myself, I can't remember. But I wanted to ask if anybody can tell me what may be wrong with it or what Bandit might flag in this small, if you can see it. Hope it's not too small. Any ideas? Anyone? I heard, not in this case. So there are two offending lines. So the first is the auto add policy. So this bit of code is using Paramiko, which is an SSH client. And what it's doing is automatically accepting whatever host it connects to, whatever host key is presented. So if you use, I'm sure most people have used SSH. You make a connection, you get a response that shows the fingerprint. This is effectively ignoring that fingerprint and not displaying it to the user at all. So you have no validation that the crew you're connecting to is actually the proper person. So in the HTTP world, this would be the equivalent of ignoring the certificate. On the second flag is it's flagging a potential for command injection by using exact commands. So this is a little anime gif running Bandit on that slice of code. And it flags those two problems, I'm sorry so tight. But it does find both of those issues. If you go into the code, and in the case of the auto add, and I change the policy to reject, the ideal scenario here is that you would tell the user the host key as a fingerprint. So you rerun Bandit. And in this case, I'm also skipping the second test because maybe as a developer, I know that second case is a false positive, right? And then you'll get a clean Bandit scan for that bit of code. But alternatively, you can go into the code, like in this example, and modify that line, and basically add that no sec comment. And that'll also tell Bandit to ignore that line. That's what this is doing. Go to that exact command, so the comment no sec, save it, rerun Bandit. And voila, you have a passing test. So that covers Bandit. It is open source, of course. I am one of the maintainers, and we welcome all new contributors. So please, if you have ideas to share, please go. The documentation probably could use some work, so that's one of the ideas to help out. New integrations would be nice, with some other IDEs like Dim, maybe or Emacs, if you guys use that. One of the things that's kind of new and cool is, I've seen this with like ESLint, but not only identifying a problem, but also suggesting a fix for the problem, right? A lot of these tools will just point to documentation, and sometimes that's not the best thing to resolve the issue. It may be confusing, but it'd be nice if it actually offered a solution, rather than just removing that line of code. So the second linear I want to talk about was GoSec. This is your Golang security linter. And this was started by one of the guys who also created Bandit, like a year later, and it runs on Linux Mac and Windows. It's pluggable. It has a lot of similar Bandit, just because of the creator of it, but it'll find hard-coded credentials. One of the things it'll know is binding to all interfaces, so a lot of people don't realize that when you have a service and you listen on the 0.0.0 address, you're effectively listening on every interface that is on your system, and usually you only wanted one public interface, and that can lead to trouble. But it also looks for injection, and weak cryptography, bad versions of SSL and TLS, and ignoring host keys with SSH and such. It has slightly less in terms of four matters, but it does cover all the ones that people generally use, like JSON, YAML, and it only allows you to filter by severity, which is unfortunate. It would be nice to be able to filter on the confidence because it does give you a confidence factor, so that would be something to add for a future item. But you can create profiles just like Bandit to customize how it runs and add it to your project, and you can group by severity. The actual, the way it resolves false pauses is exactly the same way as Bandit, so it uses a no-sec comment. One of the differences, too, is that it has a tool to generate TLS rules. So if you've ever posted like an Apache server or some kind of HTTPS server, there's this long list of ciphers and algorithms and key sizes that you need to place in there, and you have to keep that up to date constantly. This provides a nice little tool that'll generate the code snippet for all of that based on the Mozilla recommendations, so it's pretty slick. But one of the drawbacks of GoSec is it does rely on the GoPath, so whatever your scan has to be in your GoPath, you can't just take an ad hoc Go file and then pass it into GoSec, it won't work. It'll say it can't find it. It integrates with Sublime, with DS Code, Atom, a bunch of others. One of the things I would like to see it added to is the Go report card. A lot of the major projects have this Go report card that shows the health of a project, so I think Kubernetes has that. But it'd be nice if GoSec was part of that health rating. You'll see that badge on, in readmease of GitHub projects, a lot of times with Go. I'll try to, I'll post the slides too, but it'll help. This is what the Go report card looks like. This is actually a report of GoSec itself, so a little bit of inception there. And this is what it looks like in the Linter, or in the IDEs, so in Sublime. It looks pretty much the same as Bandit, and pretty much the same with Visual Studio Code, if that's your preferred idea of choice. And then here's another sample bit of code. It's a little bit smaller, so maybe you guys could help me out and identify what may be wrong in this bit. That's one. They're actually cute. That is, not in this particular case that has been brought up before. The other one's a little, maybe not so much security related, but in this case that same, the same line where the key size is too small, it's also not handling the error that can come out of that at all. So if you run GoSec on that snippet of code, those two errors, it doesn't give you a color output, so it's not as pretty, but it does give you the essential information you need, including a summary of the errors and the lines of code it scanned and whatnot. When you go into the code and we wanna increase that key size, right? That's way too small for RSA, maybe that's 512, set it to something like 2048 bits. Rerun GoSec. And I think in this case, yeah. And then it clears the, oh, sorry, the other error is still flagged because I didn't skip it or I think in this example is I go and you can actually specify whether you wanna skip that entire test. So each of the tests that it runs have a code, prefix with like a G, so a bandit uses a B, so, and then you skip a test, you get a passing test, but you can also alternatively go in and again, make that NoSec comment to ignore that line. I can slow. Here we go. Run GoSec and you get a clean report. Yep. When you, that you, you could, someone could potentially do that, right? I thought, oh, you have. I have seen that before and that has been, there's nothing in GoSec itself that would enforce that. Maybe it should, but I totally agree. That would be useful to have the reason why you're excluding. Yeah. Yeah, I totally agree. And that could be a future enhancement. I have seen people put reasons just because they're like, hey, why are you ignoring this? And in this case, so GoSec abandoned, don't go to the granularity to like say, NoSec for test, you know, code block, but you'll find that ESLint and some others do. So that would be another great enhancement to have in these tools. So, you know, definitely something I'd like to see. There might be issues on that already open on GitHub, but I'd have to double check. Yeah. Yeah, in that case, you're. Right, exactly. Yeah. I totally agree. That's something needed. These tools are rather new, so I think you use improvement. And we're always looking for new developers to do this. So, one of the ways GoSec differentiates, though, is it has that TLS config. So when you run that, this is the code snippy yet. You get a full set of the, the algorithms as actual code that you can just simply import into your HTTPS server. So pretty slick. However, in TLS 1.3, which I think Go just mess of these algorithms is totally very simplified. So I highly recommend reading up on that. It's kind of a void having to do with this big mess. So, of course, open source. I'm very much proponent of using open source tooling for these kinds of things. And we're always looking for contributions in this case. I am not a maintainer in this project, but I do know one of the maintainers. So I do like to go in and help out every once in a while or find issues or recommend feedback. The documentation is a little weak. That's one of the areas I'd like to see improved. And maybe the, you know, like was brought up here. I'll take that back to something to enhance. So the third one I want to talk about is ESLint. It has, so ESLint is for JavaScript of course, but it has a plugin specifically designed for security. And this project started around the same time as these others coincidentally, but it runs on all the platforms you can imagine. It uses a different system to ignore false positives. It just says ESLint disable line. But, however, it gives you that granularity to define, I want to ignore this line and for this error code. So you get that granularity. So it's a little better in that regard. And it uses a config file system also. And I think you can do it without it, but you define it in your project and it works quite nicely. One of the things it does that I really think is cool is it has this auto-fix feature so it'll suggest fixes based on what's reported. So in the case of like weak cryptography, you might say, I don't think it's a scam for that, but if it offered like, hey, you should be using a higher bits here, that would be awesome. In terms of formatters, it pretty much supports the world of formatters, just everything you can imagine because they've integrated it into everything you can imagine because ESLint is very widely used. The issues are fine. So a lot of these are kind of UI kinds are related. So that cross-site scripting problems, like if you didn't escape your markup, you'll find issues with that. Types of injection are slightly different here. So if you have like a variable that you're passing to a require statement or a reject, it'll flag that. And it flags timing tax, which is kind of interesting too. You don't see that with other inlinters. So it's integrated into Sublime, into VS Code and to Atom. So it covers a lot of the major IDEs that people use. Looks just like the others, right? This is Sublime. Flags is the line of code. One of the weird things about this specific plugin is that everything comes through as a warning. There is no differentiating on the severity level. So that's unfortunate. But this is what VS Code has native ability to suggest a fix. So if you click on the quick fix button, it'll actually tell you how to resolve this error, which is neat. In this case, it's not quite handily pretty nicely because it ends up saying to comment out that line, which, you know, it'd be better to get a more appropriate. Okay, here's another quiz. So this is JavaScript this time. So anyone have any ideas? There are actually three problems in this one. Any JavaScript pros in the audience? File path? You know what, it does not, and it probably should. Unfortunately, that isn't one of the things this plugin is scanning for, but yeah, totally agree. MD5 isn't something people should be using nowadays. Yes, that's one. So if we look, if I blur out the rest, yeah, so either require on that. So there's a variable being passed through the require, that's bad. There's a variable being passed into this load, which is applied for object injection. So if that variable came from input from a user, that's potentially super bad. And that pseudo random bytes, right? That's something not to use. You should use the true random. And when you run it, I don't have a video this time, but when you run it, this is what you get. Like I said, they all come out as warning, which is unfortunate, so there's no way to know which is more important than the other. Put the flags off three. Again, open source. One of the major downsides in this case is this was maintained pretty well up until recently, and now the maintainer's kind of been ghosting the community, I would say. There's questions on whether or not it's still being maintained, and there are actually issues asking about that and not getting a response. So that's rather worrisome, because there really isn't much in this space otherwise. And I already mentioned how the severity is a little lacking. But additional tests like this MD5 would be really useful to add to that. So at this point, I'm getting pretty repetitive with the different liners, so I just wanted to point you guys and gals to other sources of information. So if you go to the awasp.org, there is a really great list here of all the open source static analysis tools. So if you see, it recommends a foie finder. Now, we were talking earlier, there's grumbles about using that, but if you're a Java, it recommends spot bugs. And there's Ruby in there, and there's a bunch of others, but I definitely recommend going to there and learning more. Finally, I wanted to talk about precaution. So this is a project that we started. It's totally open source. It started within VMware, but we threw it out on the web on GitHub. And what we try to do is create an abstraction to take all of these existing linters and run them within a GitHub app. So that's what it is. We started late last year, so it's very new. It uses a new API that GitHub provides called the Chex API. Travis, CI, and these others have this Chex API that they integrate into in order to annotate code in your pull request. So it will, whenever someone smits a new piece of code to your repo, once this is installed, it'll automatically run various linters, depending on what languages you're using, flag the issues right in the code changes. So I can show you some snapshots of that, but it only supports Python and Go at the moment, but we're adding ESLint, and we want to add a wide spectrum of languages. This is a, let me play the video. This is a short video of me creating a pull request on this file. So this file already has some issues. This is Python again. But it's using weak cartography. I'm going to go in and make it even weaker, change even more lines, and create a commit out of it. Almost done. There we go. Create a new commit, being lazy with the labels, and then get message. Create the pull request, and boom, this is the pull request created, and if you wait a few seconds, it'll actually start precaution, so you see that precaution is starting. It takes only three seconds to run, which is pretty quick. If you click on the details, it'll take you to the checks tab, and that's where you get the summary of all the issues found, and a total count of these issues, including more information. But what's really cool about this, I find, is that you click on the code changes tab, and then you can get, then you can see line by line what may be introduced in your code stream. So as a code reviewer, this is a great tool to run, because I have a tool that's automatically gonna scan code from other people prior to me reviewing it, and flag potential issues. And you can actually, so actually if you need more information, there are links that'll link to whatever linter you're using on the covers, so in this case it's using Bandit, links to the Bandit documentation from there. But yeah, the whole purpose of this is to make it even easier for people to use and secure their code when you're using things like GitHub. And so finally, this is an open source project too, so we welcome contributions. And we wanna add further languages, we probably Java's next, C++ is next after that. And it really lacks a configuration mechanism right now, so we need to add something along both lines. But one of the neat things is you can add a branch protection rule, just like you would with Travis CI or something in your GitHub, and when percussion runs, that can prevent any pull requests from merging if it finds problems. And that's all I have, there's my contact information if you wanna reach out, and otherwise thank you for your time. I'll take any questions, yeah? Any questions? I wanted to. I think the OWAS recommends spot bugs, so I haven't tried it out myself yet, but we'll definitely be looking into it soon. So I'll give that a shot at first. Here was the other one, yeah. Yeah, I am not entirely sure, 2008, this one. I think some of these exploits just didn't exist at the time, like maybe new techniques were fine. Yeah, I think that's why. Yeah, I mean there were some technologies that didn't exist back to the server, but that's actually kinda, I don't know, my question. Anything else? All right, guys, thank you. Test, ooh, all right. We're gonna do this to actually start for a couple of minutes. Hope everybody's scale is going well. And I know this is the first presentation after lunch and the last day, so I'll try to be quiet so I can get a nap in if you need to, but I don't promise to actually achieve that, I'll just try. Do you wanna thank you for, oh, see? Do you wanna thank you for coming out? I do have a few, I'm doing this on my own, so I do have a few giveaways I'll give away as we go. I stole a penguin from Linux Journal. Anybody wanna penguin from Linux Journal? Ooh, you can see why I was second team in court in football. And then I also have some GNU Coasters that I made. So we'll give, we'll toss these, well, I'll not toss them out, but maybe I want a GNU Coaster. Yeah, what do I do? I'll give you one, but you gotta, one of you has to earn it by taking it to the other one. One person come get it, all right. Okay, I've got two more of those. If I forget, come get them afterwards. There's one here and I put one on display. Hey, so, all right. Let's see if we, oh, we've hit the point of time. We could actually start. I'll give it just a second. Go ahead and get started. So again, thank you for coming out to scale and sticking it out through the last day. As a start, I do wanna go ahead and plug software freedom conservancy. A lot of the fans will be, Bradley's doing a presentation right now over in the other building, so they probably have a bunch of people over there. But they do a great job of helping us with software freedom, and they are non-profits, so if you'd like to support that, Software Freedom Conservancy is a good organization to make some donations to. And then where do I come from? So I've been, I've done everything in technology. I've been a system administrator, I've been developer, I've been a manager. I've been CTO for a small company. I've done a lot of different things over the years. DBA, taught at a community college. Taught at a lot of different companies, internal training. So I've been doing just basically free software, work everything for many, many years. And I've also been doing presentations at conferences, scale has been fantastic. I've presented here for 10 or 12 years or something like that. So, but I also have spoke the last few years at Siegel. Last year, it was actually an awesome, I got an opportunity to speak, to go to a library planet and they accepted to talk. So I really had to show up, that was really nice. And over the summer, I actually got to speak for the first time on a different continent. And I got to speak at Tubics and do a couple of presentations in German. One that I did here last year, and then a new presentation on one of the tools I'm gonna bring up. So anyway, so I've got a bunch of stuff with that. And I've been trying to do more evangelism and advocacy for free software on my own time. For that, I started the Flock's Advocate. And my idea behind Flock's is we talk about free, liberate, open, but it's not just the software. I mean, we've been doing software stuff a long time. But we also need open hardware, we need open firmware. You need the whole stack because if your software is open but your hardware is spying on you, or your hardware is just doing things you don't know about, you can't fix, we will talk about the evil of IoT, then it's good to have, to look at that whole thing. So my idea was X is everything. So free, liberate, open, everything. All right, so those are both masses on instances. So you can get ahold of me that way. At the end, I'll have some more information about IRC and other ways of getting hold of me if you want to. All right, start off, I am not a lawyer. Specifically, I am not your lawyer. So I'm gonna talk about security. I'm gonna make, my suggestions have to do with technology and technology decisions. Some things, depending on who you are, where you work, et cetera, might have legal implications. If they do have legal implications, don't talk to me. Talk to somebody else. For instance, EFF is probably not your lawyer, as we have an EFF jacket out here, but maybe they can be. So also, specifically, the surveillance self-defense guide from EFF is a great resource. I had proposed this talk to Liberty Planet and gotten the accepted Liberty Plan and I was working on it and I had a whole bunch of it written and then they announced the surveillance self-defense guide and I was like, oh, I can just tell people, go read that. We're done. So it is a fantastic resource and breaks down into detail. A lot of things, I'll cover a lot of things beyond what I'll cover today as well. So, all right. Also, I have another very huge time-saving tip for personal security. Just by New Harbor. Pipeline speculation happens. So for those of you that don't quite catch what that is, maybe the next slide will do you. Remember two words when we're talking about security nowadays? Meltdown Inspector, okay? So this is from a year ago. We learned about pipeline speculation where your CPUs are now able to spy on you for other people. It's awesome, great feature. In the last week, we've had a Meltdown Inspector related new bug come out where somebody was able to figure out a different way of exploiting pipeline speculation. So even our CPUs can't be trusted at this point. We're not even talking about firmware. We're talking about the actual CPU, the actual hardware is a problem. So that's part of why I said, I want to start doing blocks where we're talking about the whole stack, all right? So for this talk, there's actually two other words that are better for us to think about. And this is the thing that you should be thinking about in regards to everything I say and everything that you're, whenever you think of privacy and whenever you think of security, these are actually the words that are most important for you as an individual or for your organization, depending on what hat you're wearing. And that's threat model. So threat model is what are the likely security threats that you personally need to worry about, right? So for me, as a normal person, I want to worry about whether people are spying on me through my phone, whether somebody's trying to break into my SSH server or things like that, right? When I was an IS manager for Canonical, my credentials had access to the drives. So using my account and more knowledge than I admittedly have myself, you could go change any bit in the repos, all right? So my threat model went up quite a bit when I had that particular job. When I was going through and pulling student data for Cisco, I worked for Cisco for a while and I was pulling student data for people to go analyze how the coursework was going, my account had access to a whole bunch of private data that I needed to make sure was staying secure. I wrote an external article about that without specifying it. I said, if you have a compromised server, well, the compromised server was Cisco's own bastion host. Nobody had broken into it, but the guys that had root, the people that had root on that server did not have authorization to look at the student data. So I needed to be able to move data across that host without letting them hit that. The way I did it is I created an SSH tunnel that went directly from my box, my laptop, to my box inside the network using the bastion host as the crossover. But I needed to make sure I had a secure tunnel between those two boxes so that the bastion host couldn't read it, right? So you gotta think about the threat model for what your particular position is, both for your data and then the data for anybody that's entrusting you with their data by virtue of your job or your position. All right. So what is being threatened? This is a great article from Matt Honin. It's a few years old at this point, but it really points it out. So some guys thought Matt had Matt at Twitter.com or something like that. So he had a really short handle and had a couple guys that thought, oh, this would be cool if we could steal that and use it to post things about some, the cockroaches are gonna take over, whatever their political thing was, right? And so they broke into various accounts of his just to get control of his Twitter handle because they thought it would be fun. Well, once they got into his Gmail account, they could have used that then to send email from his account to all of his friends and family. Since his Gmail account was being used for his credentials for his bank and all these other things, they could have also started going after other accounts that he had using that. And then really one, the biggest one for him was that one of the two guys, just for giggles, decided to go through and start deleting all of his data. Amongst that data was the only pictures he had of his daughter that they were wiping out because everything was on the same service. Go read the article for information about the service and stuff like that. So, as a parent, I would hate that if somebody went through and destroyed all of the pictures I have of my kid, right? When my kid was born in the first 24 hours, we had more pictures of my kid than there are pictures of me up until now for my entire lifetime, right? And it would be, I would hate that if those were all gone. Luckily I spread them out amongst different places and stuff so I've, you know, aside from, you know, the city I live in completely ceasing to exist, I will have, you know, copies of them. And even there, I've got some copies outside of that area as well. So types of threats, theft, right? So we think about, you know, you hear a lot of people in digital say, oh, it's not really stealing because you still have a copy. Stealing means that they take your use of it. I haven't come up with a better, simple analogy. And then when it's your data and somebody has a copy of it you didn't want, that's still theft, I mean, from your perspective. Sure, maybe you still have a copy, right? If they hadn't deleted Matt's pictures, they could have still made copies of all of those, right? Now, unfortunately, they went into loss, right? Somebody destroyed his copies of it. And because he was a reporter for Wired, he was able to get quick responses from Google. He was able to get quick responses from Amazon and from Apple because of his position. Most of the rest of us don't have that, right? I come speak here every year for a decade plus and I go speak at these other conferences. If I was relying on Google, I'm not picking on Google, but if I was relying on Google for something and my Google account disappeared, I don't have a way of, I'm not in a high enough profile to get any attention whatsoever, right? Most of us aren't. So, you gotta think about what is that threat model to you for your particular data? So theft, somebody gets a copy of something you don't want them to have a copy of. Ask Mr. Bezos what that can entail. Loss, somebody destroys all your copies of it. Maybe he would prefer those copies were completely destroyed, never to surface again. And then spying. So somebody is looking at your devices and tracking you, right? So now spying, we already know that happens, right? Whoever your manufacturer of your operating system is on your phone and whoever your phone carrier are, they are spying on you to some extent, to a large extent, perhaps. If you have any voice control devices in your home, those are spying on you. And I'm gonna bring this, I'm trying to remember to bring this up later on too. They're also spying on your guests. Or even if you don't have one, you go to somebody else's house. Their devices are spying on you, right? If you know people that have reading doorbells saying or whatever, they're spying on you. If your neighbors have that, they can track when you're coming and going because they can recognize your car. So all these other devices are spying on you, not just yours, other people's stuff as well. So those are things to think about for your threat model, right? What data do you have and then what kind of loss can you have? So what kind of attack might you take? Some threat model examples, TLA. So most people don't need to worry about a three-letter agency knowing who they are, right? Once a three-letter agency cares who you are, probably you've lost, at least in this country, right? If the NSA wants to know more about you, the NSA is gonna know more about you. They have more resources than you do, right? You know? So most of us don't need to worry about that. Mr. Snowden does as has come out and there's a few other people. Chelsea Manning got a reminder of that recently because she's doing some, she's in jail again, right? And then she's refusing to testify, right? But the fact that they cared, she's high enough profile, they can get more information if they want to, right? TSA, now this one actually caused me a problem. Theoretically, they just get your hardware for a short period of time as you're going through the check, right? Well, unfortunately, one time to me, they flipped an empty bin over the bin that had my laptops in it and walked away with both bins. So my laptops disappeared and I didn't catch it. So my own fault, I didn't realize what happened. I didn't realize that they took the bin with the laptops and I didn't realize that I had not repacked my laptops when I walked away. So they had my laptops for a while. I don't know what they did with it, right? I know that certain three-letter agencies have far more capable and knowledgeable people than I do, not to mention, boatload more resources, right? So that can be a problem. You've got to take personal accountability for your own devices and I failed there because I didn't realize what they were doing, what happened. I think it was just a mistake. I don't think they actually did it for nefarious reasons, but I can't prove that, right? You also have the aspect of like a nosy neighbor, somebody that keeping an eye on you, whether it be an office mate where they can see your system while you're in your cubicle or people that are walking by while you're at a cafe. So keep in mind, and nowadays it's not just a person, right? So the old, I think it was sneakers thing where they're able to zoom in and see what the password is when the guy types it and stuff. Nowadays we have surveillance devices everywhere. We have security cameras. Well, if you're typing a password, somebody can go through and zoom in with a security camera and figure out what your password was. So if they can track other information about you so that they can use your credential, tie that with other parts of your credentials, they can potentially get a hold of your account, take control of your account. Fishing, so we get two different types of fishing. We'll talk about fishing, spear fishing. So fishing is just casting a line net. Spam people and see what happens, right? This is the malicious software type of stuff. Also the, oh, you're running out of space in your account. You need to log in or somebody's attacking your bank. Follow this link that for some reason goes through Russia or China to get to your bank and log in so we can make sure your money's still there. Oh, guess what, it's not, right? So you get the fishing type of stuff. We also have the spear fishing as in this country both political parties have learned over the last few years as they've both been attacked. Also a bunch of different county recorders and so forth, so voting pieces. And a bunch of high profile companies have learned, right? Where somebody's gone through and gone for credentials from specific people, from specific roles within organizations so that they can break into the organization. And then espionage, directly and intentionally attacking you, this kind of goes with the spear fishing, but I'll give a specific example. So this happened a few years ago at Intel, more than a few years ago at this point. But a foreign agency, so foreign country, paid to send a bunch of their software engineers and hardware engineers over to the US to get jobs as janitors. And they wanted to make sure they had people that were sufficiently knowledgeable in order to look at the screens and figure out what would be good capture. And they basically, as they went through gathering the trash, they had the big trash cans, they mounted video cameras on the side of them. And they just went through and did video camera screen captures as they were wandering around Intel for, longer than Intel will admit. So if you've got those types of government resources, again, you've got that, so again, talking about threat model, most of us don't have to worry about that, but I wanted to cover the gamuts, right? And we just didn't have to worry about that because he pissed off enough people in the US government that, you know, there's significant resources after him. Julian Assange is getting a very, very direct reminder of that daily, I think, at this point. Threat modeling basics. So identify the assets at risk, envision potential attackers, determine the acceptable risks, right? You can't make things, a bank's job, when a bank is holding on to $2 billion with a gold bullion, the job isn't to make it to where people can't steal the $2 billion of bullion. The job is to make sure it costs $2.5 billion in order to steal the $2 billion of gold bullion, right? You can't make it impossible. The goal is to make it more costly than in what it's worth, right? So, you know, but it's gotta be what it's worth to the other people, right? So envision potential attackers at the acceptable risks, determine the acceptable precautions. What are the things you're willing to do, right? So you say, okay, I wanna make sure that people can't gather my password. Maybe I'll just put my hands over the keyboard while I type it, right? Maybe you say, I'll do two factors, right? Maybe you say, two factors, too much of a pain because I'm always losing my phone. So, you know, you gotta look at what are the acceptable cautions you're willing to take. And then AARP, because I'm getting kinda old so it seems like it's appropriate, assets, attackers, risk, and precautions. Those are the four things we're looking at. So determine your threats. I'm an older, not-svelte young man, right? So a heart attack is a big threat for me at this point in my life. What time of threats do I personally have? Now, several friends of mine recently have been diagnosed with diabetes. Did my threat of diabetes go up? My threat of diabetes didn't change. I'm still old fat male. I still have a pretty high threat of diabetes as well. But my awareness of the consequences of diabetes has gone up. And we see that a lot of times. Something comes up in the mail, oh, they're doing spear fishing or they're doing fishing attacks and we get worried about that. But think about what are your actual threats? What are the things that matter? And it's just because you're aware of it doesn't mean that you worry about it came up, right? Don't worry about the thing of the day. Look at the long term. Because if you think about the thing, it's the same thing with IT support, right? Do you spend your entire day chasing tickets as they come in? Or do you plan things out and take care of the problems? If you're just firefighting, you never get anything taken care of. You gotta fix the actual problem. So remember, for your security, for your privacy, think of it the same way. All right, some types of data, financial, banking, information, things like that. Locational, where are you? Does that, you know, it doesn't matter whether or not people know where you are and contract that over time. Medical, so your medical data you probably don't really want, you know, put on a billboard somewhere. And then authentication, your credentials, because those protect all the other types of data. Now privacy and security. Now notice I say bull. You hear a lot of people say, oh, it's a trade-off. Everything in life is a trade-off. But you can have both, right? Again, go back to what are the precautions you're willing to do. First of all, security updates, if we just see too much of it. Install your security updates, right? And use only trusted software sources. Don't just go grab something off of some random website. Use this, get the security updates from your distribution. And I recommend going through and setting it up so you can get only security updates from that particular distribution if you can. See some of my posts elsewhere for how to, in fact, my talk on Thursday, for how to do that with Debian. Debian makes it easy and yet difficult. But you can get only security updates and make sure that you're getting those as quickly as possible. And then you can worry about other updates later on if it, whether or not they matter for you. And you wanna get those security updates as quick as possible. Especially nowadays where zero day is one of the favorite words in the language, right? Or we keep thinking things and coming out. And like I say, even the CPUs can't be trusted at this point, right? So encryption and privacy, you have at rest. So when you've got it sitting on a disk somewhere, and to some extent sitting on your monitor, right? In transit, you're copying data from one place to another place. So if you log into your bank, your credentials are going in transit back and forth. But also then, so is your banking data, as you're getting that from the web server to your web browser. And then third party, this is something I think that a lot of people don't, we talk about it, but we don't think about it in terms of threat model. And I like to do that. So I've got an account with a bank, but who are they sharing that data with, right? And my particular bank isn't doing too terribly much, but we have lots of other places where we have personal data that we might, so if you've got someplace where you're storing your pictures in the cloud somewhere, somebody's holding on to this for you, well, who else has access to these pictures? Your social media stuff. Your social media stuff might have your locational information, right? If you have a Fitbit or other type of device, who else is getting access to that location information, right? As it turned out for the Army, Al Qaeda, and that caused a problem for them. As the secret base that nobody knew about, suddenly everybody knew about. So where is that information getting shared? So third party, one of the things is cloud, right? Cloud is forever. When you put data in the cloud, there are certain things you go through and change it, and you think, oh, it's gone. Well, they have backups. They have retention and stuff like that. Last year I was talking to somebody about Dropbox, and Dropbox has a mechanism, apparently, where you can, two weeks after you've deleted data, you can get it restored without having to ask anybody. Well, up to six weeks after that, if I remember the numbers correctly, you can contact them and they can still get it. So that means that even though you deleted it, it's not gone, right? There's still copies of it up there. And not picking on Dropbox, just talking about their particular model. So think about, you know, when you, if you're using, if you keep a, if you have a password manager that you're using, and you find out that somebody's gotten your password on it, you go change the password on your password manager and update that to your cloud instances, there's still old copies with the old password on there. If somebody gets a hold of that, they, and they have the password, they can still use that old version of it, right? You updated your version, but doesn't mean all the other versions got updated. So don't rely on cloud. If you, if you wanna make sure your data's secure, make sure you're making sure your data's secure, but also don't rely on cloud to delete things to not have it anymore, right? Corporate affiliates. So who, who else is the company sharing data with? You know, and who else is getting, getting information off there? I will pick on a particular company in a little bit. Advertising networks, right? So which advertises somebody recently asked for all their data from QuantServe? And everybody, everybody know what QuantServe is? So QuantServe is a company that does tracking from site to site to help people for advertising and other things like that. It's one of the, one of the domains that I flat out block because I know exactly what they're doing, right? So this guy was a privacy person who, who should, you know, works for privacy international or something like that, went and asked for his QuantServe data and found out how many things he done. He's like, I didn't realize I'd been to that bar that many times and things like that, right? By, by pulling that. And it's spying at you from, from multiple sites and pulling all, pulling all that data together. And then IoT, the little spies who infiltrate. So I already talked about devices that listen to you, right? But you also have other pieces in there. IoT does not, does not get updated very well. They have lots of security problems and most of them are sending data to the cloud. At Seagull we had a talk, somebody who talked about getting camera, he got a little security camera and then started looking at what it was doing and it was sending all of his data to a site in China. It was unencrypted and it was non-random IDs or you know, not random enough IDs. So he could then figure out who other people's accounts were and start using their security camera to spy on their house for them, right? And there was no way to, to turn that off. There's a lot of IoT devices that if you just say, okay I'll fire while, so it can't talk to the internet, they don't work, right? So they're dependent on being able to get to that third-party service and if that third-party service goes away, like the company goes out of business or the FBI is like, oh we're tired of this and they shut them down, then that IoT device stops working, right? So they're taking that information and then like I say, depending on what the device is, if it's a camera, if it's something that's listing, it's spying on your friends, spying on people that visit you, spying on your neighbors or their devices are spying on you as well. And then we have the browser loophole, the email loophole is very similar but I'm going to talk specifically about the browser loophole. As I put here, it's like a first grader, it lives inside your firewall and imports lots of viruses, right? Brings whatever's in the playground into your home. Isn't that wonderful? Or into your workplace, as the case may be, right? So you can lock down your network. My local network, all my traffic, all my local traffic is over SSH. Everything I do is over SSH. But if I've got a browser that's compromised that then compromises my operating system, they can then use that access to spy on my SSH connections. And through my SSH connections, they can have access to all my other devices, right? So this is a significant issue. Browsers try to make sure that they're secure and they kind of do a good job at there's some other issues that are going on. So a couple of the trends that we have in browser, to me, privacy issues and stuff, there had been a spate in the last 18 months of people using JavaScript to crypto mine. So you go look at a webpage and it uses your computer to mine Bitcoin for them, right? So you're paying for it and they're getting the results out of it. You also have the ransom encryption stuff that's going on. Some of that has been JavaScript delivered, mostly on an operating system that hopefully most of us are not using, but there has been some of that. And of course there's spying. Again, the QuantServe and things like that, but also if they can use that to break out of the sandbox. And then IoT is also an internal outside risk. It's gathering data from inside your network and sending it off network. Cookies, oh there's so many options for cookies. Cookies are good, all right. So you get the traditional cookies, which is storing a small piece of data on your computer and then broadcasting that back to the site so they can track you, right? For QuantServe, it's coming from multiple sites back to QuantServe so they can track you across multiple sites. Not picking on them particularly, although I have no problem with that, just they're the ones that were in the news recently. So I recommend a browser plugin called UMatrix. I use that in Firefox, it's also available for Chrome and Chromium. And UMatrix, if anybody familiar with NoScript, it's been around for many, many years. NoScript is awesome, it was the absolute minimum browser plugins I had. When Firefox moved to the new model, NoScript was not quite available. So I looked around for other solutions because I'm like, I'm not going without a JavaScript blogger and a friend of mine recommended UMatrix and it's fantastic. It's like NoScript, but much easier to use and it also does cookies and a whole bunch of other things. So it blocks XHR, which is callbacks separate from JavaScript, JavaScript and some other things. Now I did find out recently, I had not realized this, the cookie blocking it does, it actually allows the cookies to be sent, it just doesn't allow them to send back to the corporation. So JavaScript can still look at, I'm kind of worried about a little bit of data exfiltration that way, but they're blocking the cookies from going back out straight. So anyways, it's great, it's easy to use, I do a presentation on it, but you can also find some good guides on it. Now Flash cookies, most of us should not have these anymore because we don't need Flash, but it finally, finally fees go away. But Flash cookies, Flash puts cookies in your home directory, so if you have multiple browser instances as I do, they are shared amongst all those browser instances that allow Flash. I actually have one browser instance that's allowed to do Flash, so I don't have to worry about it too much because only that one thing can. I haven't actually opened that instance over here, so I'm succeeding. Super cookie is what I'm calling the ISP based stuff. So Verizon was setting up a super cookie, so if you go through and browse something from your phone, basically external to your phone on the network, they add a cookie to your HTTP request, and that cookie is unique to your phone, so it doesn't matter what set you go to or anything else, it can be tracked back to a particular device, and you can't do anything about it because it's upstream of your phone. One of the things you can do is set up a VPN, so they're not seeing browser traffic, they're just seeing tunnel traffic. So your browser connection, that HTTP connect request doesn't actually go to Verizon, it goes to your VPN over the tunnel, and that way they're not going through and adding that, and Verizon isn't the only one doing it, they're just the ones that have been called out the most on it, and had some unfavorable responses publicly, as far as I'm concerned. Tracking pixels, also known as web bugs, beacons, clear pixels, and 400 million other marketing, so of course they have multiple terms for it. So again, U Matrix is one of the ways of blocking that, blocking those, but those are then sites that have just a single pixel, so again that external site can go through and look at you. An example I'll give is a company actually like, so I like New Egg, New Egg's done a lot of really good work to fight patent trolls, and they've done some nice stuff, and I've been mostly happy with their service, other than their web page sucks, their website sucks, it's gotten better, but it still sucks quite a bit. One of the reasons it sucks though, is because it's got like 50 different tracking pixels on it. Now those mostly don't affect me, because I have all that blocked, but if you ever go look at all the different calls they have, and all the different cookies they set, there's a lot of tracking on the new egg site, and I'm gonna keep saying things bad about them publicly until they change it, so which means they'll probably be, my final thing will be New Egg's site sucks, because I don't think they're gonna change, but I'm gonna keep trying, especially since I, as a customer, I would like them to be better. I avoid buying from them sometimes because I'm annoyed at their site. And then browser fingerprinting, and this is somebody who looks at all the data from your browser when you make a web request, and try to figure out if they can make a unique guest to how unique you are, right? So if you go through and make sure that you can have Icelandic and Caribou, your foreign language, I don't know if Caribou's an option, but let's say it is, then they can look at that and go, well how many other people have Icelandic and Caribou as foreign language options, right? They can look at what your dimensions are in your browser, a whole bunch of other things. Panopclick is a browser plugin from EFF that will help you see how unique your browser looks to that third-party web server. Broly, okay, oops, sorry. Privacy and security add-ons. So U Matrix I mentioned, no script plus plus. It's got a better UI, controls JavaScript, cookies, iframes. Go look at some more information on that. HTTPS everywhere, also from EFF, that is a tool, a plugin that will try to redirect all browser requests to an HTTPS, so a secure connection, if available. It's doing it via whitelist, and the reason they're doing it via whitelist is, let's say, okay, FSF, www.fsf.org, as it turns out, HTTP and HTTPS on that particular site return the same site, right? But for years, we often had things where the HTTPS site was only for internal stuff, so it was actually a different site. I think that was the foolish decision, because it's confusing, but that was still the case. So EFF is actually maintaining a whitelist of, when you go for www.fsf.org, oh, it's okay to use the secure site version of that, and they're doing that. But it also gets to where when you just type FSF.org, and then their plugin will say, okay, let's go look for the secure version of that particular site. If somebody links to the non-secure site, again, they will intercept that and try to go to the secure version of the site. So it helps you from inadvertently going to non-secure sites. And it does some stuff to block JavaScript and search as well. Since we're talking about, I'm talking about more client side, but if you're running a site, whether that be personal or for work, Let's Encrypt is doing a great job of making it easy to automatically and for no financial cost, get SSL certificates that work in the browsers. So if you have your own website, or if you have your own website for your local log or whatever else, you can use Let's Encrypt to go get a certificate so you can set up a secure site as well. All right. Privacy Badger, ad block, ghostry and other things like that are specifically set up to block trackers and block advertising. And that's what they're actually doing. I have used, I haven't actually used ad block plus, but I've used Privacy Badger and ghostry. I have actually mostly disabled those because I'm taking care of it through U-matrix, but I'm less concerned about ads and more concerned about spyware. I don't mean mind seeing the ad so much, but I just wanna make sure they can't do anything nefarious. Then Lightbeam is a really awesome plugin that will let you see what kind of third-party connections your browser's making. So when you go to, if you go to New Egg with U-matrix set up, or actually U-matrix is a lot more, so let's say NoScript is much better. So you go to New Egg with NoScript enabled, New Egg is bringing up a couple third-party sites. And then if you go through and enable all the JavaScript and NoScript and say just let it do all the things it wants, it goes poof. And that's when it starts talking to six different sites and sharing data with Facebook and Tinder and the NSA and whoever else that they're allowing to speak on their site, right? The Lightbeam is a great way of seeing that. You can go in it with it, your security stuff turned on and see what connections you've got. Disable your security stuff, reload the page and then go back to Lightbeam and see who's being allowed then. Sometimes you have to allow it a second time because it pulls up and goes, oh, we're gonna allow Facebook, but then Facebook allows something else and that allows something else. So you get multiple layers of third-party, so you get third-party, fourth-party, fifth-party type of spy stuff on there. This is the U-matrix interface that I mentioned. Just a quick sample of it. Again, for the SFS.org, by default, for the site that you're visiting. So what they call the first-party. So for fsf.org, by default, it allows all the things. It used to deny frames. I guess they're allowing that now. It allows all the things, so it's JavaScript, XHRs, and there's callbacks and stuff like that. And then it allows CSS an image for any site, but only those. It blocks all the other things for all the third-party sites. I go through and remove the rules that whitelist all those things. So even for the first-party site, I only allow CSS an image and then go enable JavaScript if I need to. So for the fsf.org site, I think it works just fine without JavaScript, if I remember correctly. There are lots of sites that do, but some of them, it's just the nature of how the site works. So you can, if you need to go to the site, you have to allow it in order to work. But again, this makes it fairly easy to see what's going on, and you click at the top to enable, click at the bottom to disable for each of the things. Play with it, and it's fairly intuitive. Browser profiling. So one of the things I do is I use multiple profiles. For my bank, I have a profile that only talks to my bank. It doesn't talk to Facebook, doesn't talk to any other site, so that if I get broken into because of some JavaScript issue, it's my bank's fault. They're the one that was hosting the malicious JavaScript, or one of their partners. And since I block most of their partners, I don't have to worry about that too much either. My particular bank actually doesn't have partner stuff except for a couple of services where they go off site for it. And then I also have one, so I do a lot of mastodont stuff. I have an instance just for mastodont. Actually, I have multiple mastodont accounts, so I have an instance for each of the mastodont accounts for different reasons. I have an instance that I do all my web searching on that doesn't allow any cookies or JavaScript or anything from anybody, and I keep getting ads for completely irrelevant things. So it seems to be working in that I don't keep getting ads for the things I searched for yesterday. It's one of the reasons I don't mind the ads so much because it's my way of tracking the tracking. I get to see what I'm getting through. If I start getting ads for stuff I looked for yesterday, I know they're able to better track me and better target me. Use different profiles for different things. And say if you're using web mail, same thing, we use Gmail for some of the stuff for scale. So I have a Gmail account set up and the only things that go into that particular browser instance are the scale related G products because we use a couple of other products besides the mail. And if you want, I didn't link it anywhere, but I actually have a script that I wrote and I put on GitLab that makes it easy to create new profiles and to choose a profile from the command line. And if you have to have Flash, set that in one profile and don't allow it for any other profile. Pan up, click, I mentioned. Another way of doing that is setting up a bunch of different profiles. There's Firefox containers. So I've been doing the different profiles with that script for a decade plus. Firefox containers are relatively new. I think they've only been around for like five or six years. So that's a way where the browser is keeping that isolation for you. It has not worked the way I need it to work for my particular personal use, but it might work well for you. I'm actually trying to figure out a way to use the two together so I can, some of my one-off profiles and I don't need to have a completely separate profile. And then of course you've got OS containers and virtual machines. I actually, for some of my browser profiles that I want to keep extra separate, I keep those in a container and then I SSH into the container and bring the browser and it's just back to my desktop. So I make sure that even if something happens that it's even harder for them to escape the sandbox because there's a sandbox inside a sandbox inside a sandbox. If you've got hardware that's supported, you want to play Cubes. I hear a lot of good things. I haven't used it myself, but that is trying to make it very automated to where everything that you open up starts up in its own VM and you can do firewall rules and they're trying to make it really, really easy to go through and do security stuff without having to be an expert in firewalls and stuff. Authentication, password manager, please, please. Use a password manager and unique strings everywhere. I had, you know, you get in the mail recently about we know what your password is. I don't. My password manager does. I have never seen it. When I see that email, that might be the very first time I've ever seen that password if they did actually get my password from some site, right? So key pass X, key pass XC, the C is a community edition where they're doing more changes faster. I've got some, there's a couple of bugs that are hitting me really hard right now, but it's a great tool and there's also available key pass droid. There's a couple other ones available for Android that will allow you to use it on your phones and tablets. Use random strings everywhere you can. User names, sub-addressing, if you don't know what sub-addressing is, go look at that. I think I've got an example later on. Use random strings for your security questions and answers, right? If it gives you a chance to say what is your security question, give them a random string, you know? What color elephants? You don't need that. Give them, you know, staple horse battles or whatever the thing is from XKCD, right? Yeah, correct, but yeah. And then the other is, if you do use security questions and answers, though, try to get something that's pronounceable. So multiple words is probably a good thing to do that instead of just complete random jid-rear string because you're gonna be using that on the phone. And especially some security questions, somebody needs to ask you that, be nice to them. They're probably not making that much money and if you're talking to them, you need them to do something for you. So give them something they can pronounce. Even if it doesn't make sense, give them something they can pronounce. And of course, birth dates. Why? Back to the, I'm not your lawyer, but why if you can? In my key past presentation I did last year, I point out, you know, I can get a free dinner at a restaurant every month of the year, right? Give them a random date. For certain organizations, banks, and things like that, you can't lie. But for the things that you can, where I had a thing for my kid recently, where they wanted to know what my telephone number was and what my birthday was. And I'm like, they need neither of those things. So I called the PTA, and it turned out to be a friend of mine that was in charge of this and said, hey, there's a problem. She's like, well, do what I didn't mind. I'm like, okay, but they shouldn't be asking the question. But yes, of course, that's what I'm gonna do. I think I was born in the 1920s for that particular application. All right. Oh, for the birth dates, do be cautious. I've got a one-liner that works pretty well. And if I remember correctly, my one-liner sets it up to where you've got to be at least 25 years old. So I had a place where, because I wasn't allowing JavaScript, I had to, and this was for work, I had to go back one month at a time to select my birth date. And so I clicked in. I was like, this is for work, so I'll try to get something appropriate, approximate, right? And I clicked for like 10 minutes. And I finally was like, okay, I know they're paying, but this is just wasting my time. I selected whatever date I had, right? Turned out I had chosen a date where I was 14, and I couldn't get access to the thing I needed to get access to, because it required being 18 in order to access it. And then there was no way to change it, because your birthday doesn't usually change. Luckily for me, it was in the hidden field, so I was able to bring up a web browser editor and change my date and hit reset or whatever submit, and it went through and changed my date that way. I'm like, oh, I should have done that way to begin with, it was easier. All right, but lie about your birthday, if you can. Lie about your shoe size, right? Multi-factor. So SMS is not safe. We got 400 examples of SMS as not safe, not secure. People can intercept it, people can give you spoof stuff. Don't use SMS for two-factor. If somebody's requiring that, remind them that was a bad idea. I had a previous recent employer that was the only option we had for it. I reminded in for a sec, it was a bad idea. I called them back and reminded them again. I had to use it, but I was like, if there's a problem, I'm gonna remind you it's your fault, right? Use time-based, multi-factor, TOTP, there's the Google Authenticator. There's a couple of free software applications that will take care of that. They work really well. That's what I use, what I recommend. Hardware tokens, they're doing the same type of thing. You can also get tokens that you use on your laptop. All right. Secure connections and tunneling. HTTPS everywhere, I've mentioned that. Tor browser, right? This is a chance to make it to where your browsing experience is anonymous. Keep in mind that cookies and JavaScript and other things like that can still track you, even though you're going through the securities route. So don't think of Tor browser as being an absolute, yes, you're anonymous on the internet. No, if you start getting on some forum and yelling at people and being mean, they probably might be able to still track you back, especially if they own the forum, right? If you go through and start making threats that three-letter agencies care about, go back to my early slide where I said, if they care about who you are, you've already lost, right? So don't think that just because you're on Tor, you're invulnerable, you're not. But it is a great tool and it does a lot of really good things towards helping you be anonymous and protect where you are and things like that, right? VPN, so this is what I call customer-ready service. So you can hook up your phone, they've got apps and stuff where you can get a VPN and it's giving you private connection from where you are, whether that be a cafe or your phone, to them. Now once you leave the VPN, it's just another ISP, right? So whoever is south of them in the data stream can start tracking you that way. They do some things to make it a little bit more difficult somewhere better than others. For the most part, we can't audit them, so you kind of just have to trust what they're doing. So that's their business model, ostensibly. Now I like SSH, but it does require a little bit more knowledge. Most of us here have that knowledge, so I put it in here. Using SSH and Foxy-Poxy with your browser is a great way of going through and doing stuff. Now in my case, I tunnel back to my home and do everything through that, so my ISP can be watching everything I do, but they already can do that anyway, so. And if I've got from my home, I've got a Tor node set up or something like that, I can combine these things, right? So there we are. VPN, does all traffic. So private internet access, they actually are sponsored this year, I forgot to update the wording, but they sponsored Scale last year, he had a huge booth, they sponsored LibrePlan as well. And I've been hearing good things about them for the most part. London Trust, which owns them and has been funding them, also bought FreeNode and has been funding them. So they're doing some good things in the public sphere. I'm gonna call that, I don't know what they're doing behind the scenes, so but I'll call it, they're supporting the community, which I think is important. Also at LibrePlanet last year, they announced that they were releasing their client code as free software. I haven't followed through to make sure they've done that and they've been following through on that, so. Email client internet access. So email clients should never run JavaScript. Email should not have JavaScript in it. Shouldn't also not allow cookies. And email clients should show you your full address. So last year or the year before, I guess at this point now, somebody decided to punk the new cabinet that took place in this country. And they said, hey, dear cabinet level person, this is Jared Kushner and this is my private email address. And then, and it said Jared Kushner. But if you looked at the email addresses, I'm not really Jared, I'm just trying to punk you at gmail.com, right? And a bunch of people responded and gave them information about what their private email addresses were, what their private phone numbers were, gave them information about things that were going on. Okay, so first of all, these are things that are supposed to be shared on non-government resources anyway, so that you really feel. But the problem was that their email clients were only showing Jared Kushner, which you can set to be anything you want. Cookie Monster, whatever, you know, some guy from Mars, you can set it to be whatever you want. So when you're getting email, you wanna see what the actual email address is and make sure it matters, right? If you know any, you know, I know it used to work for a guy named Tim Jones and everywhere he went where they wanted his name, he spelled Jones with a Z, because he said one of the places he went to, he said there were so many people named Tim Jones that their system crashed trying to pull up his account with his name just because there were too many matches for his particular name. So he had to spell with a Z so he could get in and buy things, you know, if you wanted to use the services stuff. So if you know multiple Tim Joneses, which one are you actually getting the message from? You need to be able to see that email address. So they should have an easy config that blocks all the email-driven network access just so there shouldn't be web bugs in your email, things where it says I can track whether or not somebody opened the email. That means they have a web bug in there, right? Your email client should not let that happen unless you want it to go in there. Same thing with remote images because those remote images are essentially web bugs. So nothing remote without approval. Gmail does block them. I'm told Gmail does block that to some extent, but if it's in your address book, they start allowing more things. I don't trust the people in my address book so please don't. All right, use sub-addressing, this is the thing I mentioned. In most places, Gmail specifically, you can use a plus after whatever your user name is for your email account, and then put whatever you want. So I have, for every company I work with, for scale, I have a unique email address using sub-addressing. So if I start getting a whole bunch of spam, if I start getting a whole bunch of things to that email address, I know who gave it out. And one, I can go block it, but I can also go through and make sure that if I know exactly who that email is coming from, I can go through and filter so that only email from that entity is allowed to send mail to that particular account. I have a presentation that goes into that much deeper stuff in my presentation last year. So again, email clients should never run JavaScript from the mail. I don't think they should be running JavaScript from anything, so that kind of blocks out web mail for me for the most part. Magigate ball, outlook is not good, please. If you are forced to use Outlook for some reason, please don't. It has been a crappy security problem since the very beginning. They haven't fixed it. It's been 20 years. If they haven't figured it out by now. Yeah, I mean, when the security things are old enough to drive, stop using the thing. Please, if you can find any way, don't use it. All right. Client configuration. Show if you mail an email address. Here's some things on stuff I've done. I've only done cursory testing with it. I was gonna bring a couple examples, but I'm out of time for it. So look at your client and look. Does it show you fully email address before you open the mail, right? Can you block JavaScript? That should be default on everything. Can you block email, internet resources, and can you see what the URL that's linked the actual URL is? Notice I say yes for Alpine, all of those. Guess what mail client I use. All right. Phones and tablets. So if you want a full and free distro, live them five. Should it be released someday? I had to talk with them about that earlier today. So they have a booth in the expo hall. It's too late to get back to there because they're closing, they're closed already. So sorry about that. But Purism's doing a really good job with publicly with the things they're doing. I like their goals. We'll see if the product matches up, right? And then you have some freedom-respecting forks like Replicant and LineaJet OS. LineaJet OS used to be called Cyanogen Mod. They changed the name long enough to go hopefully everybody's recognizing LineaJet OS at this point. Phones and tablets security. Use a password or a pass pattern to get in. Don't just leave it open so anybody can open up your phone and get onto it. So if you forget it at a cafe or something else like that, you make it to where people can't just get in and start cruising through all your contacts and your bank and whatever else that you've got automatically set up. Encrypt the file system on the phone and then do regular backups. So while we were here, my wife's phone fell apart, physically fell apart. I haven't backed it up in a few weeks so we're gonna lose some pictures and stuff and I will have a price to pay when I get home because I'm not gonna be able to restore everything on that. So make sure you're getting regular backups of anything that matters. Apps for phones and tablets. So Snowden has from where he's at in Russia in undisclosed location in Russia. He has been working on a couple of projects, introspection engine and Haven introspection engine is a physical add-on for your phone that tries to look at your radio traffic. Whether that be Wi-Fi, Bluetooth, et cetera, or your GPS or your phone connection and look at what's going on and what you're actually sending upstream. And then Haven is the thing if you've got an extra device, you can put it on top of other things and if they get moved, it starts screaming and starting things and starts taking pictures of stuff. For those of you that saw the guy that put out the package for people to steal so he could get pictures of them and glitter bombs and stuff like that, he could've been using Haven for that because it's already set up to where, you know, go through, but the difference was he wanted to go off when the package got opened rather than just when it got picked up. Check package permissions before installing an application. The flashlight apps do not need internet access but there was a thing a couple of years ago about the number one exfiltrator or phone information was this some fast flashlight app. It was grabbing all this data off the phones and sending it off to some third party in a different continent than we're on right now. Doesn't need internet access, so don't allow it. FDroid is an awesome repository for free software. A lot of the tools we like are available both in the Google Play Store and in Asteroid. Get them from Asteroid if you can but also go through and look at that. So like I say, instead of using Google Authenticator, go use one of the applications available from Asteroid. Firefox and Tor browsers, use those on your phone. Firefox has a, I forgot to put this in here but a specific security or privacy related release for phones and then also on Firefox you can add this plugin. So one of my Firefox instances on my phone also has U-matrix on it. Kind of a pain to control on the phone so we need to get some work on that. It's not really ready for use but I like that I have that option. And of course you can use a VPN on your phone as well. Cameras and microphones, this is Liberium 5. Liberium 5 has a physical switch that turn off the camera to turn off the microphone. I believe it's the same switch for both of them. I would like just the microphone separated but you've got a physical switch for it so you know that it's off, which is great. My microphone needs to be off 95% of the time. I don't spend that much time on the phone. I would like to only have it physically on when I'm actually on the phone. And you need a, but I like to say I want an internal switch that takes care of it instead of something that can be controlled by software because it can be controlled by software, people can listen in. Sonic Tracker's, for those of you who've been paying attention to that, the McDonald's app had a thing to listen to stuff outside of human hearing so that when you were watching TV and it played a McDonald's ad, your phone would report that you were watching McDonald's ad. And my biggest question is, why do people have a McDonald's ad? I was like, what? All right, Wi-Fi is not secure. Like I said for SMS, just not secure. This has been a public service announcement. If you're gonna use Wi-Fi, it's great, use it. But make sure your device is encrypting the data going back and forth. Don't depend on the Wi-Fi for security. Data sharing, sharing the storage. Next Cloud, we had a couple really good presentations from Next Cloud. They had a booth. So they're doing private cloud where you can store your data but you've got control over it. And they're doing federations so you've got ways of sharing with other Next Cloud instances and stuff like that so you could set up a community thing or call your siblings and go, hey, I'm gonna put this little Raspberry Pi in your closet and you're gonna do backups for me, all right? You know, for those of you that have kids, I'm helping pay for your food. You're gonna store this for me because your siblings might be like, I don't trust you. Freedom Box is similar to Next Cloud. It's a slightly different way they're doing things but it's a similar type of thing. And of course SSH, I love SSH. I will always talk about it. Most IoT devices can't be audited. Most phone home, it should be internet of things. Keep things on inside my network. Put it on a separate network segment if you can. Block by default for access from that network segment so you're keeping it from phoning home, right? If you've got a printer, printers don't need to go talk to HP. HP thinks they do but they don't. So my printer's set up on a USB connection. It's talking to the internet and then if I need to talk to it from elsewhere, I use an SSH connection. SSH solves all my problems. All right. Well, SSH and installing Debian. Those two things solve most of my problems. All right, block by default. Use a proxy if IoT does need internet access both ways so you can have a little bit of control over what's there. Last year, scale had a really good but very depressing talk on IoT. So go look at last year's stuff if you want. Messaging, Signal, JMP Chat, which also sponsored over at Liberty Planet. Next button and matrix are all options. The last three are free software options for messaging. Signal's free-ish so go look at that your way. A couple of terms, man in the middle means that somebody can, so if I go talk to the FSF website, a man in the middle, if somebody sits on the network in between and can intercept the connections. The intersect the messages. If I'm not using a secure connection, that means they can read all the data. If I'm authenticating, they can capture my credentials. And end encryption is where it's encrypted from me to that server so they can't do that. All right, now I have, let's see what we got. Well, I've got several slides left. I'm over time. We've got a half hour break, but I am over time so I want to make sure everybody knows that. Presuming nobody's yelling at me, I'm gonna go ahead and continue. I'm sorry for running over. All right, so anti-social media. So we've heard a lot of things about Facebook in recent times. There was news last year, this is from last year, like, oh my gosh, Facebook is doing stuff we just learned about it. No, we've known about it the whole time. That is Facebook's model, right? So Cambridge Analytica was not a scandal, it was a proof of concept. I'm not, I'll say a lot of bad things about Facebook. I don't think that Facebook and Zuckerberg are evil per se, but the business model is to grab as much information about you and use it against, or use it for advertising. And Google's model isn't totally separate, but there's a lot of, I think there's a lot of difference between looking at search results and looking at all the other stuff. Both companies have recently gotten in trouble for their applications on phones that are spying on a lot more than they claimed that they were spying on. So keep that in mind, right? But just because I'm paranoid, and just because I wear a tinfoil hat and block wires, radio signals going in and out of my house, doesn't mean they're not trying to spy on me. We do have some options. And some of these are brand new options, some of them have been around for a while. We have options, and that's the main control we have over Facebook and Twitter, where one person, each of those companies, gets to decide, right? Mark Zuckerberg gets to decide what Facebook does and doesn't do. Now other people might be implementing it, and there's some other things in there, but in the end, he decides whether or not something can get on there. Twitter, one guy decides, hey, this one account is breaking all of our rules, all the things that we say we're gonna ban, but they're really famous, and we need them for people to use our service. So they get free reign, they can do whatever they want. So that one person gets to decide that. By using federated social media, you can choose an instance that has the rules that you want. You can choose an instance that says no Nazis, you can choose an instance that says all Nazis. What is it that you want? A lot of Tumblr, I think, has started one of these picture sharing things that says, okay, no more nudies. Well, they started up a whole bunch of pixel fed instances that are like, hey, we're fine with nude pictures. So people move that. If you don't want all the nude pictures, don't use those instances and block those instances, right? And that goes outside of your life, right? So you can have the different things and they can share or not share, which is a nice thing. So ActivityPob is a protocol that's actually W3C approved at this point that is meant for allowing different social media services to share data, share their microblogging messages. It allows pixel fed so that when you update it, add a new picture, you can then, you can send an update to Mastodon. And you can use Mastodon for doing comments on your pixel fed picture if you wanted to. I don't know how they're setting up the instances, but ActivityPob becomes the common standard between these different things. We're not quite there yet. Chris Limeleber, one of the people behind ActivityPob has been talking recently about what we're getting instead is getting, you know, federated versions of Twitter. We're getting federated versions of YouTube. We're getting federated versions of picture sharing right over, right? And he's like, data, ActivityPob says it's just data. I do different things. And what I would like to have is a service that can share whatever. And then on my clients, I can decide. So like if I'm sitting on my phone, I want the thing that gives me micro-blogging so I can go look at little messages while I'm standing in line, or maybe I just want the one that gives me cat pictures, depending on who you are, right? I want penguin pictures instead of cat pictures, but you know, same thing, right? So your client then allows you to choose what is your viewing from the place you're viewing. You're sitting in front of your TV and like, oh, I had all these videos I was gonna watch. Let's go look at all the funny videos of cats or funny videos of penguins or whatever, right? So here's a bunch of different ones. A lot of them will talk to each other. Other ones are getting there. Some of them, I think like Diaspora, I think has said they're not gonna do activity pub, they're doing their own thing. That's, it's a free world. They're allowed to work with it or not. GNU Social, I believe is working on activity pub, and I believe Pump.io is as well, but all the other ones are all activity pub. Now, data liberation. It's your data. Can you get a copy of it? With Macedon, you definitely can. You can grab a copy of it. With Google+, you can and you need, if you're using Google+, and you want your data, go grab it because they're shutting it down next month. Can, and then the other thing is the exported data will format it. So a couple of different proprietary services. One of them is an accounting company that I won't mention. We'll give you a dump of your data, but then it's in a proprietary format, binary format, so I was like, oh, I've got a copy of it, but the only place I can use it is into a different instance of your company, right? And Alan, I've heard from people that usually in order to restore it, not only is it, can you only do it to an instance of their company, but you have to buy a new license to restore it to the new instance, and usually a newer version of their software because only full-width compatible makes sense for backups. So anyway, so make sure you can get a copy of your data that you think is important. If you don't think it's important, don't worry about it, but if you think it's important, make sure you can get a copy of it. I was using a message on instance that had a crash and wiped out its databases and wiped out all of my data. I didn't care, but if I had cared about it, it was gone because I didn't have a local copy. So if you do care about your data, make sure you've got a local copy, whether it's on your home system or in the cloud or somewhere, but someplace that you control. Backups and just cloud all the things. Just take everything you take and put it in the cloud. That's awesome, right? Great service, it's free, must be secure. In practicality, there's a lot of things that just go in the cloud and it's not horde, but think about where you're putting it, what the circumstances are. And if you can go through and encrypt it so that it's encrypted, it can only be unlocked on your side if it's something you need to keep secure. Now data escrow, so escrow is an arrangement where something of value is held in trust by a trusted third party. So if you're uploading something to the cloud, you're doing escrow. But we think of, oh, we're just putting stuff up there. But think of it as an escrow as somebody's holding that data for you for some reason. Now remember what your reason is and what their reason is, and make sure you trust that. Now I like, so KeePass XC, it's password manager. So why do I talk about that for data escrow? Okay, well it's escrow for my passwords. But the other thing is you can add attachments. So I have a KeePass XC database instance that has my family information in it that we need. So that if I die on the way back home tomorrow, my wife can get in there and get the life insurance information, get the information about my car insurance, all that stuff. Except for I still haven't given her the password. But once I give her the password, she does have access to it, she just doesn't know it. So hopefully she can figure it out. But we're putting all the information in there. But we've got like social security numbers for the family, bank account information, all the things that we need for if my house burns down, these are the things I need to rebuild my life. I've gotten that KeePass file. My last car, I bought a car and they gave me a PDF of the purchase contract. I added that as an entry in KeePass XC. So now I have a copy of that. I don't have the home purchase contract in there yet. I still need to scan that in. But it's like 4,000 pages. Dreading that the six months is gonna take the scan that thing. All right, safekeeping data cloud, next cloud and other free software services allow you to provide your own service for that type of thing. And again, like I was talking about early at the beginning, old versions, they're still around depending on the service you're in. So think about that as far as your escrow and that it sticks around even if you don't want it to. If you do get compromised, do a full backup of your disk, your device, but then reinstall. There's all these Windows people, oh, I just did an anti-virus, removed all the viruses. No, you didn't. Reinstall the thing, whether that's your phone, your computer, whatever it is that they, if they broke into your car or computer, figure out how to get that thing redone, right? Whatever they broke into, go through and do a full reinstall on that thing. In IoT devices, that might mean you send it off to the crusher and have to get a new one, right? That one won't be secure either, unfortunately. And then, of course, change your passwords. So that, whatever they've gotten access to. Oh, I hit the end. Okay, so again, sorry for running over. I've got a couple of little slides I'm gonna do and I'll come back to this at the end in case you want to grab the contact information. But I wanted to point out, we have some free software companies that are doing things to support the community with their products and Purism was here and they also, Kyle Lankin was one of the speakers we had, their CTO. Tourist last night had a really awesome presentation. Nick, so that CZ and Czech Republic has a product project and product tourist, which is a home router. That was a really great presentation. I'm glad that they were here. I first found out about that project a year ago and I've been waiting for the last two months to go see that presentation and did not disappoint. And then, Think Penguin is a great organization. They had a booth. I didn't get a chance to stop and talk to them this year, but they were there. And then the resource, the EFS Surveillance Self-Defense Guide I mentioned earlier, there's a link to it here. My slides will go up online. And I will post out the link to both Plume and Mastinon. I usually put my URL in here and I forgot to do that, so sorry about that. All right, any questions? Yes, I have not. So, it says, Alias is the name of the project? Okay, so it's a DIY project called Alias that you can throw on top of your Alexa or Google Home product and it will then control what's being sent upstream. Okay, so what I was talking about in here, I said, set up a proxy, but it's a proxy specifically for those devices, so it can be monitoring those things specifically. Okay, that's awesome. No, I had not heard of it. I refuse to get those devices, so I've not had to investigate it, but that's good. So, Alias is the name of the project, right? Yep, okay. Any other questions, comments? Okay, well, you know, tell them to set up an Alexa in their bathroom and tell us what the results are. You know, so the thing is, you know, saying I don't care about privacy, I've got nothing, you know, it doesn't matter if people are looking at me. That's like saying that free speech is not important because you don't have anything you want to say right now. Well, what happens when you do wanna say something next week? Well, what happens when something you said last week now becomes a problem? Ask people in Venezuela right now whether or not free speech matters and whether things they said last week matter because things are changing, right? So, you know, hopefully we will never have that problem in this country, but we need to protect it not just for us, but for other places as well. And there are definitely places in this country where in my lifetime, we didn't really have free speech a lot of ways. I should have added that to the messaging. I forgot about that. I looked at Keybase a little bit. I'm not particularly interested in it myself, but I should add that to the list for those that might be interested. So, thank you. If you would message me, because I've got a really bad memory. And by the way, if anybody's got suggestions for talk things that I should have included or you have further questions, please do go ahead and message me. I do most of that through IRC and Massadon, but go ahead and message me and let me know because I want to improve the talk. Even if I never give it again, I want to improve the content. And I'm going to take some of the things and expand with blog posts and stuff too. Any other questions? No? Well, thank you again for coming to plug, or plug, where am I, scale. Thank you again for coming to scale. Thank you for sticking out when I ran over quite a bit. I appreciate that. Have a safe trip home, however far you're going to home. And I have two coasters and another penguin left. We have any you may want? Which coaster or penguin? All right, I won't throw the coaster. That's probably going to do some damage. In the back, what would you like? All right. Hold on. You go ahead and take this off. Ooh, hey, it is. Check mark number one. Okay, I guess we can just get started. I don't know if there's a room captain or anything in here, so we'll just go for it, right? Okay, thank you for coming. Thank you for sticking around towards the exhausting end of the conference. So tired, oh my gosh. So this is building security into your flow with InSpec. InSpec is a product, project of Chef Software. We're familiar with Chef. We started out doing configuration management. This is one of our other projects that we're going to talk about today. After me, my name is Mandy Walsh. I am the technical community manager at Chef. I have been with the company seven and a half years, so like four internet lifetimes, right? If you'd like to get in touch with me, I have my email address. I'm pretty much LNXCHK on all your popular social media, except for Snapchat, because I'm like 20 years too old for that. We're going to talk about InSpec. And I do this talk and I do a workshop version and I've been based in Europe the past couple of years, so I've been shopping this around over there. Dean Wilson, who does a bunch of thought-leadering and things like this was very nice to unpaid, right? Tweet nice things about InSpec the last time I gave a workshop. So we'll hope that you find it as interesting as he does. So you're like, okay, well, you said this is a security product, but you're in the security track, like Chef does configuration management, so like what's the story here, right? So Chef, we know we've been working with large enterprises for the last five, six years. The Fortune 500, the Global 5000, big, big companies. A couple of years ago, we had the CIO of Alaska Airlines at our conference and he gave this amazing talk about what it means to be a modern business and the things that you have to care about to make your customers happy. And increasingly that means being super available over social media, like if you're complaining about an airline, you're probably doing it on Twitter, like all the time, right? And basically what he said was that they're gonna be a software company that has airplanes. You think about the capital overhead, the amount of money that they spend on equipment and berthed airports and like all the other things that go into running an airline, but the things that set them apart and the stuff that they associate with their positive interactions with their brand comes down to how they manage technology and how they improve that customer experience through technology. So there's a lot of companies out there doing all kinds of things with software that we weren't thinking about 10 years ago when Chef first got started. There's definitely pockets of holes in the marketplace for things that we need to do a little bit better, things we need to think about in a different way and those things ended up sort of being sort of plugged into what we do. If you saw my night last night, I picked out a couple of particularly heinous security problems over the past couple of years where I just kind of, we're just kind of boners, right? Like we make a sort of dumb mistake and it costs a lot of money. So this one, Honda, they had WannaCry, it's on their platform and it comes into their factory and they patch everything up and everything runs fine for a while. Well then they have to build some new machines to deploy something or a new production line or whatever it is and the image that they use to create those new systems wasn't patched. So what they thought they had mitigated and fixed in their platform snuck back in again because their security life cycle didn't include rebuilding all of their images that they needed. So it's not anything that's like super hacker. Like it's not razor and blade and it's hacking your gibs in. It's like crazy sort of things that sneak into the complexity of your day-to-day systems. This is another one I absolutely love, right? That's like where configuration management company and like they left a default setting on a new server and it cost them $2.14 million. That's a lot of money to not change the default configuration and not really be paying attention to the things that you're deploying, right? So what we wanna do, we're gonna try and help mitigate all of these things and it's too much for one person to keep in their head so we're gonna encode it into code and work with it that way. What we found working with these larger companies is that they have a lot of people who are really stakeholders in the entire security and compliance sort of ecosystem. The compliance office maybe is not necessarily the most technically savvy people. They're not the hackers on the keyboards usually. They have a checklist. They might have some consultants that they work with if you are working with like a PCI consultancy for audits or other government agencies and things like that. You have like security team and I worked at AOL for a long time and like our security team was like often some other building and like would send us random emails of things we needed to do every now and then and like they weren't always in our day-to-day. And then you have the folks like actually doing the day-to-day work of the operations of your systems and they all use different tools. Your compliance folks are probably working with large PDF files. When I worked at the government they come in with these binders and we go into the data center with our code form because we were gonna spend hours with the binder. And then your security folks, a lot of those tools come in in languages that are most portable. So usually shells, so things that you can do. Not necessarily an item potent sort of tool necessarily. And then we have our DevOps folks and they're using something else probably like maybe they're using a chef, maybe they're using other things that aren't chef but those are sort of a different generation of tools but they all have a part to play in the things that they need. So what we wanted to do is give everybody a local place or centralized location to deal with all of these things, right? The requirements that they have plus the greater ecosystem of badness in the internet. And what we're hoping to accomplish with Inspect is to get folks to that place where they have one central location where everybody can contribute the things that they need and get their goals met. So what is Inspect? We strive to make Inspect human readable and if you're a Ruby programmer or lived in the Ruby ecosystem for a while the spec probably tips you off, right? It's kind of built off of the RSpec testing language for Ruby. So we're looking for something that's human readable because some of our compliance folks like they're not necessarily used to Grockin code, right? And that's fine. They have other knowledge that we need so we need to be able to communicate with them. We wanna test our security and compliance components, right? There's lots of things we can test but we're specifically looking at how we have configured our learning systems to be as secure as possible. And we wanna be able to create, share and reuse these things because they're going to get pretty complex. Has anybody seen the CIS profiles for Linux, right? 836 pages of PDF, right? Like that's an extensive thing and you need a bit of knowledge to figure out which pieces of it you want and which pieces of it you don't want and they give you run the whole thing like the system isn't even connected to the network anymore so that's not totally useful but there's a lot of stuff in there. So we wanna be able to build to that sort of standard, right? That's what our compliance folks are sort of looking for as well. We also wanna be able to extend it for our stuff. So if I have things that my company has written I wanna be able to test those as well and make sure they're configured the way that I need them to be configured. And finally, we're gonna plug this into our existing stuff. So things like our CI CD pipelines so we can check these as often as possible. Before and after code gets shipped to production I wanna be able to test my new images and my old images and all these other things. So we want these tools to be pretty flexible. And has anybody heard of Test Kitchen? Has anybody used the chef people in the audience? Thank you. So Test Kitchen is a tool, I'm not gonna get into the Test Kitchen workflow in this talk but it's a tool for fast feedback on your laptop. So it uses Vagrant under the hood and allows you to fire up a little virtual machine and get fast feedback on it. So one of the other workflows for InSpec is actually doing unit testing of your chef or other configuration management codes so you get some fast feedback there. That's super useful if that's what you're doing and it's awesome. Like you can totally read about it on our website but I'm gonna talk about just how to be using InSpec sort of in its own right. So to get our life cycle, like I was assistant then for a long time in a very large organization, right? And every now and then you get these emails from the security folks in the next building over and they'd be like, hey, this CV came out, you need to patch all your systems, whatever, blah, blah, blah. And in the days before systems automation, like that's a bitch, like oh my gosh, okay. So I've got, I've got 1,200 hosts running behind six load balancers doing one big thing and then the Akamai's in front of that and there's also their crazy business going on and you wanna repatch what now? And sometimes you get like just random emails in the middle of the week and they want it by Friday and all that great stuff and then they're gonna audit you and they're gonna publicly shame you for not doing it and all kinds of other dysfunctional things that organizations do. It's still important, that's just a better way to do it. So we've also worked with companies that do like the single big scans, right? The financial industry is really big on this. They do like a big scan once a year and it's all red. And then they spend like eight months paying contractors to fix all of it by hand and that's crazy too, right? So you get these massive scans and there's a remediation fire drill, you're a call contractor or these folks that kind of ship themselves around to help you fix all that stuff. All that stuff sort of, it's really dysfunctional. Like you're making changes all the time if you're doing sort of modern workflows, right? Like stuff's gonna sneak in in between your audit and that's how the audits get read in the first place. So you wanna have some tool, we hope, that helps you fix these things as often as possible. So let's say we get something weird, right? Our version of Linux is sufficiently aged that it still has SSH support for two protocols, right? Most of the new ones in seven and eight on the CentOS side, I'm not sure where the Debian versions are beyond this. But the version we're running supports two different protocols. The original one, V1, we know is bad, right? It's subject to a whole bunch of security issues. We want everybody, no matter how many hosts you have, to update all your stuff and make sure in some way that that stays that way, right? So what do we do with this, right? Well, I have to figure out where the configuration file is. If I'm in a homogenous environment, it's probably in one place everywhere. If I have two or three different versions of various distributions, it might be in a similar place. If I've got two completely different versions, it might be in two places. If I've built my own because I wanted Kerberos or something weird in it, who knows where it is? It might be in slash OPT somewhere. But to find that file, I have to figure out the right setting is. Usually my security guys are good enough that they're gonna send me what they want my file to look like. If not the whole thing, then at least a snippet so I can test for it. Now I'm gonna schedule my fix and restart and hope somebody upstream for me the next time I build a system has already fixed that image so that I don't have to worry about this again. So remember, they're gonna publicly shame me for not having fixed my stuff. So it's craziness. Then do I need to actually test it? Do I have ETLs that need to SSH into things? I have to make sure it still work and like all this other stuff is going on. So there's a whole lot of things that go into this process when you have just sort of these crazy requirements and not a good way of sort of automatically fixing them. So let's take a look at what this actually would look like in something like Inspec, right? So Inspec has a series of what we call resources. We'll talk about them in a minute that are just components on the system. In this case, SSH D-config is significantly complex and useful enough that it's built in, right? Everybody on Linux has one somewhere, probably. And we can break down the things that we need. We can say how important it is. We can give it a title for talking about with our compliance officers or our security auditors. I can give it a description here to say, all right, this is what I was actually asked to do. If I get a JIRA ticket or a CVE or something like that, I can just plug that right in there and save that for later. And then it's gonna go into my file and it's gonna dig around and say, all right, here's the thing that you want me to look for, right? For a call. And then I have a series of matchers. In this case, I'm comparing it to the value of two. That was in the file, it could be like one comma two and that's not what I want. I want it to be two. So I can run this against as many machines as I need to. Inspec on the back end is doing all the hard work for me, right? It's finding the file if it's in a default location and figuring out where this is in the file and whether or not it compares. It's a bunch of Ruby code underneath there. Some Ruby classes that are helping us out do all this hard work rather than doing it by hand. So our resources examine common services and system stuff and different configurations and there's a whole bunch of them that are built in for Linux and for Windows. And they are really after the things that when you think about, okay, I need these ports not open. I need like the NFS demon should not be installed. Like those sort of common checklist security profiling. Super easy to encode with these resources. On Windows, you get stuff like registry keys are super important for certain fixes there. Lists, dig into the list of service packs and stuff like that to investigate the state of the system and make sure that it is in a good place. So just check all these characteristics. For files, you get like file size and owner and those sorts of things. For more complex stuff, there's actually these matcher classes that are digging down into config files and things like that. If you think about something like one that's built in is the HTTP config for Apache. And like I still have nightmares about crazy things you can do in that config but it is super useful to have looking in here, making sure my directory listings are turned off and other sort of security settings for that sort of thing and those sorts of resources are built in. We can also group resources into controls to make her to these logical connections. And we'll talk more about this in a minute but I'm basically saying like I have a whole bunch of things that AuditD needs to be set for and I can group them all together because AuditD has a lot of different stuff in it. There's maybe six or seven maybe more settings that I care about so I can actually group them together in one place so that they sort of all hang together. And then I group all those into profiles that's sort of the pack of stuff that I can then share out to the rest of my teams. So my resources include an item and how to look at it and then the parsers in the backend do the thing and what it looks like is like our specs. So uses this language called it's and should, right? And Ruby, idiomatic Ruby programmers have ways to talk about this and I'm not a Ruby programmer so I apologize if I send any Ruby programmers. When we're looking at simple things even like it should exist. If I have a file that should be just in the directory to flag for an action I need to be there. I have services or packages that should be installed on the system for that. I have a service that should be enabled, right? So it should start when the system reboots. I can dig down to config files as they are my max log files I should keep six. Like that's a pretty common setting that I wanna compare and figure out what that looks like. If I get a script or some kind of fix from my upstream vendor and sometimes they do give you a bash script to fix whatever CVE they've come across I can actually run that thing with inspect and then make sure that its exit status is good. So I'm not stepping completely away from my under workflow I'm actually incorporating it into this workflow and giving it sort of a better abstraction that way. I can also test for things like DID and that kind of stuff and on files like anything that comes out of stats and stuff like that. So it's super interesting that way. So then I get to my SSHD configuration. I have my resource, it's built in and then that's what inspect is gonna dig around in my file and find. So then I can run it and it's command line and you can do it a bunch of different ways. I have it installed locally on your workstation and then run it against remote targets or against your own system. You can run it as an agent on all the systems that you're looking at and you can run it on a regular basis if you'd like to for that in that way. Also run it, there's a reference shell that you can actually just get into and play around in so you can test out the things that you wanna be working on. So it comes in, it's a Ruby gem or it's also a part of ChefDK. If you're working in a Macintosh environment we also publish it through Homebrew so you can download it and run it from there. So let's say I have a basic test. I want to make sure temp is a directory because I have like some road process that continues to screw it up or do something weird to it. We also want it to be owned by Root but be totally open, right? And I wanna make sure this is all good stuff that the system needs to have done. So you can check out the file resource, right? We have lots of documentation on how all these work and the things that you can test on them for what it actually looks like. So for this kind of example, I have a file that I'm talking to and then I have a bunch of things I wanna ask about it. I wanna make sure it's there, number one. And then I wanna make sure it's a directory and there's a couple of different ways to do that. In this case I've picked this particular syntax but there's a couple of others. And then my owner and my mode. So let's go ahead and run it. Make sure I can switch my stuff here. There's my test file. Is this an RB file in this case? It doesn't have the extra like discussion part and those sorts of things in this simple test. So I've got basically like six lines of code here to just try this out. And on this case because the resource I'm talking to in this example is open to the world. I don't have to use sudo. If I was digging around in system files I would have to have extended privileges. In this case, I'm just gonna talk to run sec runs this thing. It comes back. It gives me a bunch of like a nice information there. I have a checklist of all the things that I tested and it tells me that it was all successful. Now if I change this and I say, all right. Maybe we change this to, we know that's wrong. Let me run it. It tells us it's wrong, right? And it's gonna tell us how. And for things that you're sort of testing down into config files it'll give you a diff, right? So I know that whatever config file it is this is what's in it and this is what I told it I was looking for. So it gives you a bunch of information that way. All kinds of targets. I'm running this on the command line. So in testing the local system from just doing in spec except. If I wanted to test a remote system that had SSH on it I can do that via the regular SSH flags. Dash I and with my keys or whatever else. If I wanted to do a window system it runs currently over WinRM. So I can talk to window systems remotely that way. And then I got a Docker container that I have access to on the system. I can also get into that and see what's going on there. So a number of different ways to talk to the systems that I might wanna look at. If I wanted to plug these tools into my workflow in Jenkins or other CI CD pipelines it works in a hopefully predictable way, right? When it, when you have failed tests you get a non-zero return code. So you know in your workflow that in fact failed and you can drop out. When all the tests have passed then I get zero as my return code and my workflow can continue. So it gives us something that's super easy and repeatable to use over the course of your different state. So when we work with this we kind of work through a bit of test-driven development for people that are comfortable with it. So if you've done any test-driven development you kind of have, you create the test first. You're allowed to fail. So I know, okay this port is open when it shouldn't be, that's fine. I know the test works because it failed. Then I make the change to my system, whatever it is. Close the port, take the service off, turn it off, whatever it is. And then I rerun my test to make sure that it passes after the change is made. This is super helpful for checking your assumptions about the state of the system. If you have a bunch of stuff that's hand-built and you're not sure what exactly is on it and how it got there and things like that you can actually start in this manner and say all right I know I have this port open and how do I accomplish that? I know I have this service running. How do I accomplish that? It's also super helpful if you're moving to a new version of an operating system where your settings might have changed or the syntax is slightly different or those sorts of things. You can sort of run that inspect test first and say oh this has changed the last version and now I need to change my assumptions along with it. So then we've used them very, very complex workflows that way. So when I have a lot of things that I want to be testing I can add a lot of information for the rest of my team. For folks who aren't necessarily hackers or into all this stuff all the time and we can help them out with how important things are and adding descriptions. So there's a lot of things that, there's a lot of sections for impact and if you have like, there's also commercial offerings that sit on top of inspect that help do reporting on some of these. But you can do super low ones, right? Information only. Like we know this is out there. We don't think it impacts our environment but we should know that it's there and in the future if it needs to be fixed we'll have record of that. And then we go up from there and so you get to critical which is usually stuff you should fix as soon as possible, right? Super important and it should be done. And then your description. You can give ticket numbers, CVEs, other descriptions, where the requirements are coming from is it related to your PCI requirements? Is it related to HIPAA? Is it related to any of the other things that you might be working on? And the example again, there is that our impact and all the description areas where I can be pretty verbose for everyone who needs to read it. So this all sort of comes into play when we start working with profiles. And you think about how long the CIS requirements are, right? How am I gonna get those 850 pages of PDF into these little bits of InSpec code, right? So InSpec profiles allow us to package all these sets up into repositories or however you wanna share them that way. And basically sets of InSpec tests and you can build them by specific applications like this is our requirements for Tomcat. These are our requirements for whatever else we're running. And then share them out to your folks. And they're made up of these controls that have the resources embedded in them. And the controls have resources and tests, priority and metadata, just like we saw in the last slide. So you name your controls, based on what they do, or you can link them to their written document. We'll take a look at that in a minute. Each profile can have lots of test files in it. So you have the ability to make them as simple or as complex as you need them to be depending on your requirements. So I have a, the host that I'm working on happens to be CentOS 7. It's in AWS, so it's their current version. And all I installed on it to get started was InSpec and Git, right? Git brings all its Pearl friends around, but that's all that's there. And I'm gonna work through this OS hardening piece with a Linux baseline that the InSpec community has put together. So dev-sec.io have links at the end. They have put together a bunch of these sort of example profiles just to give you an idea of how complex these can be and what they can accomplish for you. So I'm gonna work through this example. So the Linux baseline profile isn't as extensive as CIS or some of the others, but it has a lot of the highlights of those sort of industry standard profiles in them. So there's stuff that digs down in. We've got this one is, it has a name, right? So this corresponds to maybe a paper document, a PDF document somewhere that has a description. And I'm going to check owner permissions on EtsyShadow. Basic stuff that I'm not really assuming out of the box is wrong, but want to guarantee on my systems is always going to be right, right? So I'm looking forward that way. I am checking the permissions here, so I've got my description. I've got my file. This is a file that I'm talking about and these are the tests or a specific set of them, existing via file, be owned by root and have the rest of these setups. Now out of the box, I sort of assume this is probably correct on most of the OSes that I use, but I want to always guarantee that no one has gotten in here and installed something incorrectly or changed something so that it has diverged from my requirements. So I'm in my house here and because I'm going to talk to some system files, I want to do this with root privileges. So I'm going to run that Linux baseline. So Linux baseline, just a set of files there. All the cool stuff is under controls, but they're sort of packaged up together. So I think that relate to the operating system, so that's OS underscore spec. I think the deal with specific packages on the system, so we know certain characteristics of the packages the way they're installed by default, maybe don't meet our needs. And then the third one is dealing exclusively assist cuddle because it's a monster, right? So I can run all of these together as one big workflow. They're all packaged in that same directory, so I just tell inspect to go ahead and run all the controls that are included there. So I see a whole lot of red, oh my goodness. It's crazy, what happened? Remember this is just a box off the shelf, right? Out of the marketplace. So I'm talking to Etsy shadow and Etsy password and login definitions and there's other things in here that are kind of interesting. And stuff that I probably want to fix in some manner. But there's a lot of tests included in here. And I can talk about picking and choosing the ones that we want in a minute. Overall, there's 26 total controls, so there's 26 objects that passed and 27 that failed. We're talking to 53 objects. And then individual tests, there's 125 individual test lines that the thing is going through and investigating. So there's a whole lot of stuff that is in there. The joy of this demo is that it changes almost every time I run it. So the last time I updated my slides, which was like Thursday, there were slightly different numbers. So you get a report on how many successful controls you have, how many failures you have, and you can work from there. So one of the things that the DevSec community has put together for us is remedial components. So I can go through and I can actually fix these. And they're supposed to match sort of one to one. There are, this one is a Chef Cookbook, but there's also stuff for other configuration management tools that we choose to use those. So what this helps us do is look at that host and say, all right, I have all these bad things here because it was just a default image. It doesn't meet my requirements, but I want it to because I want to be able to do Dev on it or whatever. So I can go through and use this companion to fix everything. So I'm gonna use Chef to do that. And so InSec detected some issues and I'm gonna just use a quick example of what we call policy file and not use a Chef server if you're familiar with that at all. And we keep all these on a site called the supermarket which allows us to sort of share things out. They're also available directly from GitHub. So I have a policy file that I'm going to run. And in this case, I'm gonna call it server hardening so I know what it's gonna do. It's gonna talk to the supermarket and it's going to run this OS hardening cookbook that the DevSec community has published for us. So I'm not going to worry about connecting to a Chef server and download all this stuff locally. So in true cooking show fashion, we have one here. Okay, so server hardening. We'll talk to the supermarket and then we'll deal with our run list there. We'll see how this goes. You're gonna install it and then export the components and then run the Chef, make sure I get all my typing correct here. I'm just gonna copy it. Okay, so at the end of the day there, we talked to 206 resources, 141 of them needed to be updated. That's that last line there. So there's all kinds of things that get touched, right? Cause there's all kinds of things that were wrong. And so the whole workflow sort of function is that I'm asking the system to get hold of some publicly available cookbooks. We're gonna download them. I can see the versions of them there to see how they line up maybe with other requirements I might have. And then it just goes through and starts fixing things on the system, right? So I'm root here and I can change as many of these things as need to be changed. So all kinds of stuff gets touched. Now we hope that this fixes all those errors that we had from the Linux baseline. Let's see what happens. I fixed most of them. Okay, let's see how close we are this time. I had two the other day. Let's see where we are here. So we can scroll up. Oh, this one, this one always happens. So my requirements for AuditD aren't met. I have one particular control, package 0.8, that is not fixed by my remediation cookbook. So now I have to decide, all right, well, how much do I care about this? I don't know, let's find out. We can talk to our security team and figure out what they think about it. We can investigate with the other folks that we're working with to see how much of it we really need to do. So when I ran this the other day, I had two failures. It was package 0.8, and then it was also some file system stuff, no worries. So I have to find the controls that aren't passing. I decide if I wanna fix them or forget them, as it's totally possible to do either one. If I wanna fix them, then I'm probably gonna go into my configuration management code and make some adjustments and change some file settings around, things like that. If I wanna forget them though, that might be interesting. So what we're gonna do, we're gonna build a new profile around little spacevine to exclude the things that we don't care enough to fix right now, right? So at some point, my security team hopefully will give me a new configuration for this and that would be great. In the meantime, I wanna keep working and we've decided that for what I'm doing, I'm not too concerned about this right now. If it were something super serious, I'd wanna get a fix, but we're just going to exclude it. So profiles have the ability to bring in profiles from other places. So these sort of default ones that we've published, super helpful sort of in the generic case and I can use them, I can ingest them around the other settings that I might need. So if I'm actually doing some specific tests around Tomcat platform or some other application that I'm working with, I can use my links, spacevine, inside of those larger profiles that are more specific to me. So I have my application profile, it might have controls that are specific to my problems and my particular environment and then I have sort of this generic one that's down here. What I can do, I include all of the controls, maybe by default, but I can also come in here and I can skip the ones I don't need anymore or the ones that I've decided to just sort of ignore for the time being or maybe aren't appropriate for my particular environment. I don't wanna turn off SSH or I don't wanna turn off cups on my print server or whatever the case might be. So I can actually do that. So I can create myself a new profile and InSpec has a bunch of tools to allow you to do that so that you get all of the files that come along. See if I put one in here already. I did not. Make sure I get my, yeah. So I get sort of this default package, right? And there's two places that are super interesting. One of them is the inspect.yaml and the other is the controls directory. So controls directory is where all those RB files are stored that have all the tests in them. And I have one in there so far. But inspect.yaml has the configurations that allow me to bring in and consume other profiles. So in this case, the one that I'm working with is Linux baseline. I can consume it in a number of different ways. I already downloaded it. I have it locally and I could use that version. But if I wanna save this profile and use it in different places in different times, I can actually just talk to Git and say, hey, you know what, just go out and pull out the latest version and we'll work with that. So in this case, what we've done is we have our hardening profile and we've allowed it to depend on the Linux baseline but directly from Git rather than from a download. So it's gonna go out and investigate the Git repository and bring down the new one as it runs. And then I'm going to tell my controls that I want to include the controls from Linux baseline. That's all the good stuff that we saw before. But at OS 10, that's super annoying one or I guess a package or eight that I'm gonna fix here in a minute, I'm going to ignore that. So I'm gonna skip that control so that it doesn't fail my stuff anymore. So then when I'm ready, everything is green. So I'm up here, I'm checking all this stuff and all the things that I needed. I have my version of my local profile and there's nothing in it, right? And then I go out to this version of the Linux baseline and there's all the things that it tested for me. So I can just consume these profiles in this manner so that I know I'm always getting the latest version. I don't have to be the person writing those, I'm just using what my security team, what my compliance team has written for me. So it's super easy for me to consume that that way. Rather than thinking about how many bash scripts I have to use after I build a host or the other things that end up being checked. So there's what that looks like, a little bit larger. So in fact, we'll find or retrieve the included profile. You can choose to use all of it or just pick a few things. If you only want a handful of those controls, you can do that as well. And you can exclude the ones that don't meet your needs like we just did. And then you create a new file and you can manage all the other components that way. So we skipped package 08, OS 10 was from Thursday. So something changed in the meantime. And then we get all green return on our profile. So now I have a host that is compliant with my requirements for my group and can move forward. And it was just a basic host off the line at Amazon. It wasn't in a special image or anything else that I built. But because I'm using these components this way, I can turn it into a good state that I can now use to move forward. So there's other stuff that InSpect talks to you. There's constant work going on with InSpect. It's very much an in-process service. We're working with the cloud providers to provide tests for resources in the cloud, right? So if you hear interesting stories about people who publish documents to S3 buckets and then open those S3 buckets inadvertently to the world, super interesting to read everybody's grades off an S3 bucket, but it's probably not what was intended. So there's ways to test that kind of thing. So unintentional misuse of complex setting in these environments, we're gonna be able to help you to make sure that you're doing them correctly. And then our CIS, we published the full CIS profiles as part of a commercial subscription. So they are available, they've been certified. Test Kitchen, as I mentioned earlier, InSpect will also run as a test suite in Test Kitchen. So if you are doing active configuration management programming, you're creating your cookbooks or modules or whatever, Test Kitchen will make use of InSpect for testing those components. There's a number of YouTube videos and some other good content on that, regardless of which tool you choose, but you should be using Chef. So that's more information about that at kitchen.ci. Finally, resources about where you can find more information about InSpect. InSpect.io is the current home of all things InSpect. DevGest.io is the InSpect community. So it's folks that work for us, but also folks that work for other groups that are working with InSpect. There's a couple of interesting stories here then too that I've highlighted. One is Annie Hedgepeth. She had a series of blog posts, they're a couple of years old now, but the main information is still correct. She had been, she'd taken time off of work to raise her kids, right, like you do. And she had been in the creative space before. She wanted to get into tech and her husband's one of our customers. And she went through and was like, I'll learn InSpect and see how that goes. And what she did out of that was create this series of blog posts about how she was learning InSpect and how things were going. And it's a really nice step by step discussion of how you think about InSpect and how she was associating to it having not really been in tech before, right? So instead of different beginning assumptions, I guess you could say. And it's actually really good. There's another set of stories about, this one in particular is about Dirty Cow, just about how this particular organization went through and investigated their systems and remediated their issues. And then we're sure they were always being, always correct by InSpect. These slides are already up on SlideShare. You can find me, slideshare.net slash lnxchk, all my stuff is there. The workshop version of this is also up if you're interested in that. Finally, we'll have new stuff about InSpect coming in May. May is our big conference. It will be in Seattle this year. We have content coming from some federal government contractors about how they're using InSpect and compliance in their environment. We have some folks talking about these digs and some approaches on that side. And Google's coming to talk about generating these tests automatically in a couple of different ways with some libraries they have. There's really good content coming with InSpect in the near future. Having said that, I have five shift cost tickets if anybody would like to go. And my marketing person wasn't super helpful in like deciding how we should give these out. But if anybody would like a shift cost ticket, I'm happy to give them to you. And I'm also happy to take whatever questions you have. We have about 10 minutes left, so if you have any questions. Yeah, so the question was that log in the output when you disable a test under a couple different levels of the output it will. Otherwise, it suppresses that. So you don't have extra output for things you're not running. Yeah, yeah, exactly. Anything else? Has anybody run InSpect before? Are you all new to it? Yeah, a couple. Okay, awesome. Very good. Oh, okay, yeah. So Lance over here is, they're converting from service back. So if you're familiar with service back and you're like, this kind of smells kind of the same. Like it certainly didn't happen that way. Service back being sort of an older project was really good, right? Like they launched it at, I think it was on ignite at velocity in like 2013 maybe. Really interesting. And the genesis of InSpect sort of taking that idea and sort of going into these profiles and some other things that service back didn't really then go in that direction. So it ended up just a little bit different. Yeah, also a very good tool for working on these kinds of things. Awesome, thank you. I have some info card to the front if you would like the links and that kind of stuff in a printed version. Also card for our LearnChef project that has tutorials and videos and that kind of stuff. If anybody would like to visit us in Seattle, please come up and get a ticket. Yeah, email Susanna and she will hook you up. Test, test, test. But anyway, so I'm testing this one and you're talking in that one just at the same time. Test, test, test. Okay, so. Whoa, whoa, whoa. Yeah, hello, hello. Test, test, test, test, test, test, test, test. Testing one, two, three. Test, test, test, testing one, two, three. Testing one, two, three. Testing one, two, three. Yeah, awesome. So if by chance something happens and I've got to turn that down, can you show me which one it is? Okay, cool. Do you have my computer audio? No, not for this. Test, test, test, test, testing, testing. Probably just gonna be me and you. Can you guys hear me all right? Probably don't even need a mic, but we'll use it for the... Let me know if this gets too loud. I can adjust it. Okay. I wish. Anybody need more stuff to take home in their bags? So find disc. Take home to your kids. Find disc. Find disc. Find disc. Hey, almost got it. I used to be able to throw real frisbees, but that's exactly right. Yeah, I got in trouble because my accuracy's not so good. And my boss got nervous and he said no more hard find discs. Yeah, that's, I'm shooting for that. Thank you. So we still got another minute. Get started. So you guys probably deserve some sort of medal for being here for the last talk, talking about security. And so hopefully we'll make it worth your while. Simus is the open LDAP people. Open LDAP. Have you heard of that product? Yep. That's where the maintainers provide commercial support. Okay, it's time to get started. So this is the anatomy of a secure Java web app using Apache Fortress. And for the next hour, we are going to be thinking about how to secure web apps if we pulled out all stops. That's me and my timeline. I've been at this for a while. I like to tell people when I meet them that I've made a pretty good living, writing bad software. And then the follow-up is it's all bad software. There's a lot of bad software out there. When I'm not riding my bike, I try to get some work done during the day with the software architect with Simus. Again, they're the open LDAP people. And I'm Apache directory PMC chair. And I moonlight with open LDAP. So our agenda is we are going to have a little discussion about security breaches real quick. Talk a little bit about vulnerability scanning before we get into the main topic, which is really end-to-end security based on a couple examples. And along the way, we're going to look at some security principles to try to explain the rationale for the approach here. So I do have a recommendation there's going to be a bunch of slides. And so these slides have links to a bunch of artifacts. And so if you try to take notes, keep up and probably be a little overwhelming. So these slides are published right there. My contact information will be at the end. Actually, you've got my business card and those flying discs. Just contact me if you want to copy the slides. What I want to do is have a conversation about security with you guys. So, you know, I'm going to throw some stuff out, try to keep me honest, and let's learn together. Okay, I like this quote from John T. Chambers. There are two types of companies, those that have been hacked and those who don't know they've been hacked. This one's mine. It's not a network as much as an ocean, not a tear machine or container, but islands separated by miles of hostile waters, almost be attended to and defended each with unique challenges. Okay, so this problem statement we're going to be coming back to. This is going to keep us focused. But our goal is we're going to try to make our systems more resilient to cyberattack via the application of a few common security principles. Okay, so what's the problem? This is 2019. Why are we talking about security breaches? Are things getting better or are they getting worse? Those right up there, those are the top five breaches of 2018. Those are in numbers of users with their personal information exposed. At the top, that's a B as in billion. Not to pick on those companies. This is a widespread problem. What's going on? Why is this, why haven't we figured this out yet? Why are we still talking about breaches and exposures? Is it a technology problem? Is it a process problem? What is it? Thank you. For example, you get a prize for that. This is the one I've studied, Equifax. I think that was one that really kind of, that might have been a tipping point. They disclosed a breach in September of 2017. 150 million people in North America and United Kingdom had their personal information exposed, including their social security numbers, birth dates, addresses, phone numbers. Probably everybody in this room. Had their personal information exposed. I know I did. Who's Equifax? They're one of the big three credit reporting agencies along with Experian and TransUnion. You may not know who they are, but they definitely know who you are. They're keeping almost a billion. Consumers information, they're up to almost a billion. They are a very large company. Remember the Fortune 500, got 9,000 employees. What's up with that? So what happened at Equifax? Specifically, it was CDE 2017-5638, which is a vulnerability in Apache Struts, which is a web framework for the Java platform. It's a commonly used web framework. It was a vulnerability that was detected out in the wild in April of 2017. And for whatever reason, Equifax chose not to apply the patch. Couple months later, in the early summer, the attackers breached their website and that went on for a couple months before it was discovered. And in September of 2017, Equifax actually disclosed the breach. What happened specifically? How did it work? It's called a remote code execution exploit. In this case, the attacker tricked the website into accepting a string of data that was executed as a command, a system command. How exactly did that happen? Within Struts, there's a library called the Object Graph Navigational Library, OGNL, which has been a target of exploits like this before. And you have kind of a string of data that looks something like that, that gets uploaded in a header and it gets interpreted via the Java runtime. This is contrived. We're executing a calculation command there, but in the actual attack, they installed malware on the server right and then that was the beachhead that they were able to set up shop and then eventually do their work. If you're interested in this, there's a webcast by Blackduck that goes into the forensics deep dive. They talk about what tools were used, how those tools were used, how could that be done? It's simpler than you would think. So again, the exploit was disclosed in September of 2017 and there was quite an uproar about it in the press, as you might expect. And the fingers came back to Apache Struts team and they were catching some heat and as a result of that, the vice president of the Apache Struts team, Renee Guillen, published this statement on the Apache Software Foundation website in response to the uproar. And we're gonna look at some of the things he said because I think it illustrates some of the problems and some of the things we can do to get around it. So this first paragraph here, Renee says, establish a process to quickly roll out a security fix release of your software product once supporting frameworks or libraries need to be updated for security reasons. Best to think in terms of hours or a few days, not weeks or months. Most breaches we become aware of are caused by failure of the software components that are known to be vulnerable for months or even years. And indeed that was the case with Equifax. They chose not to apply the breach or I'm sorry, they chose not to apply the patch which would have prevented the breach. So back to our problem statement, how can we make our systems more resilient to cyber attack? The solution must be to ensure all appropriate patches have been applied. Okay, we can do that. There's some tools out there that are useful for that. The old lost dependency check mechanism actually works on several platforms, Java.net, Ruby, Node.js, Python, CC plus plus and what it does is it compares the dependencies in your application to the list of vulnerabilities in the libraries in the IST database and it will spit out a report and so you just look at that report and then you can fix those libraries or update them. So this is a Java talk. And so these are the tools that you can use to run this mechanism on the Java platform. There's an ant, Maven, Gradle, Jenkins plug-in. So I use Maven in my projects so I would apply, you know, enable the plug-in in my POM file like this and you know, I'd run that target on a release cycle and it would flag any vulnerable libraries and then you would just upgrade the version and life is good, right? Or is it? Let's go back to Renee's statement on the website. Any complex software contains flaws don't build your security policy on the assumption that supporting software products are flawless especially in terms of security vulnerabilities. So that gets back to my earlier statement all software is bad. So, you know, all irony aside, you know, there is a lot of, you know, that's a flippant statement but this is hard. It's extraordinarily difficult to understand all the different ways that a piece of software is going to be used. And so I would assert to you that the list of unknown vulnerabilities is orders of magnitude larger than the list of known vulnerabilities. And there will never be a scanner that can detect them all. That's impossible. So what we do about that. Back to our solution, which is in response to our problem statement, how do we make our system more resilient to cyber attack, practice the principle lease privilege by enforcing mandatory access controls. Principle lease privilege is in a particular abstraction layer of a competing environment. Every module such as process user program depending on the subject must be able to access only the information and resources that are necessary for its legitimate purpose. Mandatory access controls, restrictions on even administrative users can be enforced at a granular level. Okay, so there are a lot of different ways to do this depending on your platform and your operating environment. Linux, you've got positive security controls, things like sudo, and you can file permission certainly can help you here. We've got SE Linux for Red Hat, all sorts of things. Well this is a Java talk, one of those things that we have in Java is the Java security manager. So are we Java guys here? Anybody use the Java security manager? Yeah, so that's really been my experience is nobody uses the Java security manager. Why is that? We'll get into that in just a second. But it is a way in which to enforce mandatory access controls. So as soon as you enable that Java security manager in the runtime, everything's off by default. So things like opening up a socket to a website, reading and writing the files, executing files that's turned off by default, and you have to enable it via permissions. So if you've got some kind of remote code execution vulnerability in your application like Equifax did, if they had been using Java security manager, it wouldn't have happened. Okay, so this is gonna be the first of four examples that I'm gonna show you. It's called the remote code execution sample. It's in my public GitHub account. These are all available for you guys to use. But we're gonna just take a little test drive of the Java security manager in a sample app. So this sample app has a readme, which explains sort of the rationale of it and kind of sets it up. And then it explains how to basically download it, build it, and run it. So when we run it, we are gonna execute this program. There's actually three examples in here. We're gonna do the first one. And it's just a simple application that simulates one way or remote code execution vulnerability can occur. So this is a contrived example, can you guys see that, okay? And it's basically kind of doing everything for the lifecycle of a serialization exploit in one app just to kind of show you how the security manager can halt it. So it's kind of, you've got this first part where an object is being instantiated and serialized. That's what the attacker would do in this case. And then they'd send it over the wire somehow, presumably they'd upload it to a website. And then when the website deserialized it, that's when the exploit occurs. Here's the object in question. And so in this case, again, it's a contrived example, but what's going on inside of this object is that it's basically running a script here, you can see with the runtime. And that script is kind of a silly little script, but it just basically takes the .cpassword file concatenates it into another file and the target directory that the program's running in. So let's go ahead and run this and show you how this works. Can you guys do that, okay? So you can see here, or can you see that? I can actually zoom in a little bit. That better. That's too much. So you can see there that we are enabling the Java security manager right here in the runtime. And so we're just gonna execute this app and it runs. And basically the exploit was successful. I look at the target directory and you can see there's a file there you've been hacked, which contains my .cpassword file. So let's look at the Java security policy right here. And you can see that there is a permission being granted for this hacker script to run, to execute. Okay, so no one would ever allow that in their right mind. So practicing the principle of least privilege, you only allow what's minimal for this application to run. So if we comment this out and run it again, you can see that it failed with an access control violation right there. Okay, so access denied, can't execute that file. So that's just a very kind of a simple example showing how the Java security manager can prevent things like remote code execution exploits. Again, that sample's out there. If you wanna try it out, there's a couple other types of things in there as well. It's not a perfect solution, that's why nobody raised their hand. Supposedly it's got performance implications. I think those are overblown, especially with respect to the security implications. You know, hardware's cheap, remediation's probably not so cheap. But there's a caveat or two. One is it doesn't play well with reflection. Reflection is Java's dynamic instantiation framework, pretty much used by all the parsers. So in order to do something like using the job security manager in a Java runtime, how to suppress access checks on reflection, which is another open door. Reflection is another way in which some attacks can occur. So it's not a perfect solution. But it is a tool in our toolbox and it certainly will give you good information about your application. So even if you don't run it in production, it's kind of a nice thing to just run it in a test environment and look at what your application's doing. Look at all the resources that it's accessing and that might give you some insight in how to protect it going forward. Okay, so it's not a perfect solution. What now, do we just kind of hope for the best? Let's go back to Renee's statement. He's got some pretty good insight. Look at this one here. He says, established security layers, good software engineering practice to have individually secured layers behind a public-facing presentation layer such as Apache Stress Framework. A breach into the presentation layer should never empower access to significant or even all backend information resources. Back to the Equifax exploit. The attackers use the vulnerability to pop up a web shell on the server weeks later and managed to retain access for more than two months and were able to pivot through the company's various systems by obtaining an unencrypted file of passwords on one server, letting the hackers access more than 48 databases containing unencrypted consumer credit data. During that time, the hackers sent more than 9,000 queries on the databases, downloading data on 265 separate occasions. Huh. So it's probably a little bit more than Apache Struts going on there, right? So let's go back to our solution. Again, with respect to our problem statement, how do we make our systems resilient to cyber attack? Let's add something there and say apply defense in depth. What is that? The building up layering, overlapping of security measures is called defense in depth in contrast to a metal chain, which is only as strong as its weakest link. The defense in depth aims at a structure where should one defensive measure fail, other measures will continue to provide protection. So that's where you get this onion where the data is surrounded by the applications, surrounded by the hosts, surrounded by the network. If one defensive measure fails, another one picks up the slack. If Apache Struts fails, something picks up the slack. You don't have unencrypted files sitting around with passwords, for example. Every single node on the network should be protected. Every, even into the layers. And we're gonna talk about that right now. Okay, so this is a Java talk. I'm an old guy, right? So I don't have containers in there. But these are the layers. For the application I'm getting ready to show you, which is sample app, these are the layers that are available to us as security architects for when we wanna decide where to apply controls. Do you apply controls in all those places? Yeah, maybe not, depending on your use cases. But it's best to be aware of them and know that they're there. So these layers are gonna be specific to your operating environment if you're operating inside of a PaaS platform as a service. You're gonna have more layers there, Kubernetes, whatever. It's gonna be specific to your operating environment. So this is what we're looking at for the sample I'm getting ready to show you. They don't all do the same thing. So you're not just doing the same check in every layer. They all have different capabilities. So the outer layer in this onion, we're talking about Java. I see security, we already talked about it. That's the principle of these privilege. The next one in, GSE, Java secure socket extension, that's confidentiality. Java EE security, that's another subsystem that most people don't use for various reasons. We're gonna use it today. That's the deadbolt on the front door. We're gonna talk about that in a minute. Spring security, once you can get in the front door, what pages can you hit? You know, that's what we can use Spring Security for. Web app framework, you can get in the room. What equipment can you operate? What buttons can you push? What links can you hit? That's where you would do that kind of control. And finally, down in the database, that's where you're gonna do content filtering. Okay, so this is example number two. It's called the Apache Fortress demo. This is in my GitHub account. So this is a sample web application, a traditional web application. Again, if you're running inside of something like Kubernetes or microservices, you're gonna have more layers, but you still have this inside of all that. And so there's a web application, there's a directory, and there's a database in the sample application. And so all of the infrastructure is open source. All of the instructions to set this up are in the tutorial, step-by-step guide, the software you can all use either in test or production. You can lift it, steal it, use it, whatever. So we're not gonna go through the installation instructions. What we're gonna do is we're gonna talk about these different layers and what they're doing for us. Okay, so those layers we saw are really in two areas of access control. You have kind of an outer area, which is declarative, and that's where Java SE, JSSE, Java E, and Spring live. And that means programmer unaware, right? Declareative is, you just enable it, it just works. In the inner area, we've got programmatic controls down in the web app framework and the database, that means the programmer had to do something. Now, could these controls have been declarative? Possibly. In your architecture, maybe you could do that. That's always something to strive for. Declareative is good. But sometimes the lower down you get, the harder it is to do that, especially when you start to do fine-grained authorization like we're gonna do in this application. So we start out with Apache Tomcat servo container. First thing we're gonna do is enable HTTPS. The instructions walk you through the steps that you gotta do to generate the cryptography artifacts and where you put them, use an open SSL. We're not gonna do that here. Okay, so Java EE security, that's the deadbolt. So that is really, you enable it at the container level and it does it on behalf of the application and there's nothing the application can do to break it. So that's a nice layer to have that I almost always use in any of my applications. There are specifications that surround Java EE security. This is not a Java EE security talk, but if you are a security architect on that platform, I would recommend that you get to know those specifications and know what they're for and if you're not using them, know why you're not using them. This is in Tomcat, so Tomcat is not a full-blown Java EE container, it's a servo container, so we are gonna use what's called the Tomcat Realm, which has been around forever and it's basically just a database of users, passwords and roles that are stored that are used for the security checks. So Tomcat has a number of realms that are available out of the box, there's a file realm, which you would never use in production, there's a JDBC realm where you store the data in tables and I would say you would never use that in production either, there's an LDAP realm where you use basically kind of a general purpose LDAP structure and that one's fine. We're gonna use what's called the Apache Fortress Tomcat Realm. So Apache Fortress is a project that I'm a maintainer of, we're gonna talk a little bit about that here in a moment. But basically what we're gonna do is we're gonna enable the realm at the container level and it's gonna enforce this sort of core screen policy on behalf of the application. How do you define that policy? It's in what's called a deployment descriptor, a web.xml file which specifies a contract between the application and the container and you specify a URL pattern which that's saying, hey, these are the resources that you need to make sure are secured. That should pretty much be all of them other than the logon form and the air page, everything else should be behind that and then you have a list of one or more roles. So I am prescribing this as a deadbolt, it's core screen authorization so I'm gonna say just put one role in there, one and only one role. So the user can pass authentication and they must have that role in order to get that into that app and that's sort of a fail-safe mechanism, can't be screwed up, just you gotta have that role to get in there. Okay, so in order for all this to work in this setting, we've got the Apache Fortress Tomcat Realm which is using the Apache Fortress security system policy decision point. Policy decision point is a resource server that sits out on the network and it's answering questions like authentication and authorization, authorization would be can I hit this page? Can I push this button? Can I hit this table? So let's talk a little bit about this policy decision point so that we understand the context of this. So the Apache Fortress system uses a security model that's called role-based access control. So most people have probably heard of role-based access control. They at least understand what the generic term means. The role-based access control is not really a generic concept. It's a model that's been kicked around for decades. It started out in the 80s in the academic and government world and that model was formalized in the early 90s by the team at NIST, David Ferriolo and Richard Kuhn and they basically are defining and describing what a role-based access control system should do. This model was further refined in the early 2000s by a team led by Robbie Sandu where it was formalized into a set of functional specifications that describe exactly what the different operations of a role-based access control system should do. That was formalized into the specification in 2004 by ANSI, inside 359. That's what Apache Fortress implements is ANSI, inside 359 role-based access control. Any questions about that? Oh, there's a companion spec called Insights 494. That's where you add attribute map modifiers to the equation. Kind of an A-back thing. And we're gonna touch on that at the very end of this talk. Okay, so I told you it's not a generic thing. There's a very refined and defined object and data model. In data model. And so there's kind of the entity model right there. And there's four areas that Insights 359 covers. This R-back zero, that's the minimum that a system has to do to be compliant. That's users' role's permission. Then a session. A session is really kind of the cellular feature of the R-back system. Just because that role has been assigned to the user doesn't mean that it's gonna be considered in an access control decision. The session is where the role is activated. Okay, so that's in keeping with the principle of these privilege. So that sets the stage for some of these higher-advanced features. R-back one's hierarchical roles. You can establish inheritance relationships between them, which is for administrative easing. R-back two's static separation duties. That's where you can specify mutual exclusion constraints between assigned roles. So there are possibly combinations of roles that should never be assigned to a user in conjunction. Think of something that would be a toxic relationship. And so that's a way of enforcing that at the policy decision point. R-back three's dynamic separation duties, which is mutual exclusion constraints between activated roles. So the role can be assigned, but they can't be activated together. So the classic example there is you have a check rider and a check approver. A user could possibly be one or the other in any given situation, but never both at the same time, because that would create the opportunity for fraud. Does that make sense? So we're gonna talk about that here in the demo, which is coming up. We were talking about the object model. There's a functional model, which is the shape of the APIs. So there's three broad categories. There's admin, that's how you get the policy in there. There's review, that's how you interrogate the policy. And there's system that's runtime evaluation of the policy. That's what most people think about is the system manager APIs, what you do at runtime. These are all what you would expect. Create session, that's where you would authenticate and activate zero or more roles into the session. Setting the stage for check access where you're checking the permission. Session permissions would be get all the permissions for that session, say you're in a GUI or some sort of application where you don't wanna go and do a bunch of round trips. You can add and remove roles from the session. And that's, we're gonna see that here in a sec. If you're interested in that, I've got an example that talks about what's called role engineering. That's how you would synthesize a policy in our back and you would apply it to an application and enforce it. So it's kind of soup to nuts, that's out there. You wanna check that out. Okay, so back to installing our policy decision point. There are, the policy for this Apache Fortress system is being stored in a directory. It's an LDAP server. Do we all know what LDAP servers are? Kind of a special purpose database for security. Apache Fortress works out of the box with two LDAP servers. One is a Apache directory server. The other is open LDAP. The tutorial instructions will take you through all the steps to set one of these up. You just take your pick, you'll work with either one. There's also a Docker container which will simplify that somewhat. Okay, so we've got our policy decision point installed. We're now, we've got this directory server out on the network. And so we are going to encrypt traffic because we are sending data over the wire like passwords and we should encrypt that, right? We're practicing defense in depth. So the tutorial will walk you through those steps, taking those cryptography artifacts that you generated in step one and where you put it and what bits do you flip to make that happen on whichever directory server you're using. Now we're into, we're gonna put the locks on the room doors. We're gonna use spring security for that. So that's where you establish a policy between roles and pages. To hit this page you gotta have that role. To hit another page you gotta have another role. So we're gonna use spring for that. That's still declarative. So the application, we haven't instrumented the application yet. We're gonna do that on this dep which is the web app authorization layer. Okay, so this sample app is using Apache Wicket which is a component based web application framework. So the way I chose to instrument this layer is to, I created in this sample app, secure controls. So there's a secure button, there's a secure link and the way it works is if you have the permission in your session then the button will show up or the link will show up. And if you don't have the permission then it won't show up. And if you hit the button, it's gonna check not only do you have that permission but you have that permission for a particular customer. So we're gonna be doing fine grain authorization down to the context level with this sample app. Okay, so the last authorization we're gonna do is down in the database layer. We just popped up the database server so this is in this sample is MySQL. The instructions to install that is in the tutorial. And so we are going to instrument the database layer with programmatic controls to verify that the user has the permission to do that database operation on behalf of a particular customer. So you might be scratching your head right now and saying, well, why are we doing authorization in the database layer? And the web app layer, you know, I pushed a button to add a row to a table. So I checked it there. Do I need to check it here too? You know, that overboard. So we're back to defense in depth. Would if the attacker was able to circumvent your web app, authors, you know, what if they were able to circumvent your web app? Would if they were able to instantiate your database component via say reflection? What then? So again, defense in depth when one barrier doesn't hold up, another one holds, you know, picks up the slack. We're almost done. Last thing we're gonna do is we're gonna encrypt that channel to the database via SSL. So we're going to instrument MySQL with, you know, the cryptography that we generated earlier and we're gonna instrument JDBC to make that channel secure. Okay, so those are all the steps that I've done here. We could keep going. There's more here that we could do. You know, we could have say column level encryption on the database. You know, you could encrypt the customer column, for example, that's another thing you could do. You might have stricter access control lists on these resources to say, hey, the service account that's accessing that can only access it for these specific rows, these specific tables. So that's, you know, you get the idea of sort of defense in depth practicing the principle of lease privilege. We're trying to sort of limit the attack vector, the surface area of an attack. Okay, so talk a little bit about the functional requirements of this application. It's just a contrived example where we have three pages. There's some data sitting in the database for three customers. And I've established a security policy, a fine grade access control, security policy where I'm saying to hit a particular page for a particular customer, you've got to have that role. So three pages, three customers, that's nine roles. And furthermore, I'm saying that a user may be assigned to one or more roles for each role would give them access to that particular page for a customer. And then we're gonna apply dynamic separation and duty constraints on those nine roles to say that the user can activate one and only one of those roles in the session at a time. Does that make sense? So let's go ahead and take a look. Well, before we do that, so you know, we can now have this sort of slice and dice the policy in any way we want. So I have this user, user one, two, three, that has access to all pages for a single customer. User one has access to a single page, all customers, user one, one, two, three, single page, single customer, you know, on and on and on, right? So just based on the roles, then that's what you get. So let's go ahead and try this out real quick. So this is the app, I'm not a web designer, so it's not very beautiful. And I'm gonna log in. Can you guys see that okay? Okay, and so this web form right here was presented to me by Apache Tomcat. The application did not put that web form there. So I'm authenticating, I'm authenticating with the realm and I got through. And so the realm decided that yeah, the password was right and yeah, he's got the one role that he needs to get into this application. So once it passes that check, then I land on the landing page where the, you can see that the web app framework said, yeah, he's got the roles for these three pages. So it put the links on there. And so I can click on these links and I can get to those pages, which question, go ahead. So the question is the web form that we hit in the very beginning, which is this, is enforced by Tomcat. And so that gets back to, there's a deployment descriptor called a web.xml file that goes in the webmpt folder. And in that folder, you specified to Tomcat what the policy is. And so yes, now the data's not in web.xml as far as the user ID and password. That's correct. That's correct. Okay, so again, I'm gonna log in as user123 with the container. Yeah, that's well. That's me. You have, you can actually put a form. You can give it a form. So that was my form. So that tells you, yeah, that tells you how bad I am. But you can, or you can also have an HTTP basic auth where it just puts up a little box. But yeah, obviously you could do better than what I did. Okay, so here's the landing page again. So I can click on these links and Spring is okay with it. So I can go to page one. Spring lets me go to page one. So I must have a role for that. I can go to page two, page three, so on and so forth. But where are my buttons? There's no buttons on the bottom. Because I haven't activated one of those page customer roles yet. So I'm gonna do that now. So there's a, you know, and again, this is contrived just to kind of show you how this is. You probably wouldn't have a user do this. But I'm going to activate page one, 123 role. Okay, so I click activate. The buttons pop up down at the bottom. See that. And so now I can interact with the buttons and do things like I can pull back data. You can see on the bottom. So all this is, you know, like I said, this is HBS up here. That's SSL over there. The traffic on LDAP is LDAP-S. What happens if I try to change the customer to say four, five, six, and do a search? I get an authorization error because the user doesn't have the role activated to hit that customer data for that page. Question. Okay, so the question is, is the logic in the Java code to check for the roles or is it checked by the framework? And the answer is it's checked by the framework. So the Java Apache Fortress subsystem, which is this role-based access control system, is the thing that actually checks those roles. And you're basically, you're interrogating with APIs. So in this case, when we saw this error, it was doing a check access on that button. And so it was saying, can the user click the button on page one, customer one, two, three, for say search or add? So it's a permission, you know? Page one, one, two, three, add. That's a permission. And so you call the policy decision point with that question, check access with that permission and it just returns a yes or no. In this case, it returned a no. So the application doesn't have to worry about that. It's just calling these APIs. That's correct. Okay, so the question is, can, is there a declarative mechanism, say in the spring framework, to do these fine-grained policy checks? So the answer is no. There isn't anything that works like this in the spring framework where you can do that declaratively. You know, I'm sure that you could probably figure out some way to do it. But, you know, I mean, it's absolutely. Yeah, so the comment is it would be nice to annotate the button and I agree with you. And I believe that that's possible. And so it could be just that I don't know how to do it. Question. Okay, so the question is, is this JSP syntax or is this Java code? So this is, the framework is Apache Wicked. And so Apache Wicked is a component-based framework, so you're not actually coding JSPs in Wicked. You've actually got Java classes that you're writing and that renders into HTML. Yeah. So, okay, so where are we? We filled the authorization check for this user because they tried to interrogate on customer 456 because they don't have that role activated. So let's just jump to another page for this user. We're on page two, the button went away, right? So that means that we don't have the role activated for page two, customer 123. Remember, this user has access to all pages, single customer, right? So we can go to any one of the three pages and interrogate customer 123. So all I gotta do, right, is activate this role for page two, one, two, three, which is in the dropdown, right? So I'm gonna activate that role and I get another error, which is a dynamic separation of duties violation because I can only have one of those page customer roles active in my session at a time. So before I can activate that second role, I must deactivate the first role. So I'm gonna deactivate the first role and then I'm going to activate the second role and then the buttons pop up and then that user can then interrogate on that page. And so that, I'm gonna show you one more user real quick and we're gonna move off this example. So user 123 has access to a single page one customer. So let's log in as that user right now. Okay, so similar to last time, only now we just have one page there because this user only has access to a single page, single customer. I can click on that link as before, the buttons, he would have to activate that particular role before that button shows up. But what I wanna show you here is what happens if this user tries to bypass the web app framework in the link and enter in the URL to the second page manually. Can't do it because Spring knows the policy, right? So defense in depth, one layer fails, another layer picks up the slack. Okay, so that's enough of that. There's a bit more to this. Testing is important. We verify the policy, performance is important. That round trip of that policy decision point should be less than 10 milliseconds. I sat in a talk yesterday where the round trip was 100 milliseconds or something, the policy decision point I was saying, well, it sucks to be you. You should be able to get that down to a lot faster. That's why Apache Fortress is using an LDAP directory. It's not using it because it thinks LDAP is complicated and we're just gonna put it somewhere hard. It's because directories are fast and efficient. And so Open LDAP has legendary performance. The round trip time's getting down into the microseconds. So the question is, is when we do a check access in the application, is it doing a round trip with the policy decision point or is it cached? And so the answer is it's cached. So remember when I was showing you those access control functions and one of them was session permissions that pulls back the whole list. That's what's going on in the beginning is it's pulling back all those permissions and it's caching it in the session. But you could do it round trip. When you're talking about just a millisecond or whatever. And so that's one of the impediments to doing fine-grained authorization like this is the performance. And that's what architects will tell you. Well, we can't do it because the performance. And so I beg to differ. You can do it. The performance is there. If you pick the right resource, it will work. That's Apache Fortress demo. We keep it up to date. So try it out. If you've got any problems, let me know. And we'll help you with it. OK, so there's still a problem here, right? I'm presenting this last application like it was the best thing since slide spread. But there's a problem. And it's, I don't know, can anybody guess what the problem is? It has to do with the policy and the fine-grained policy. So we had nine roles, right? Fine-grained. So for every page customer, you had to have a role. So our roles are exploding, right? So as soon as you introduce context into the equation, then you've got this role explosion problem. So basically what it means is the number of roles that you're going to need for your policy is the number of roles times the number of relationships. So in the case of the app that we just looked at, we had three roles and three customers, so we had nine roles, no big deal. But what if you had 100 customers? What if you had 1,000? What if you had 10,000? What if you had 100,000? Then this quickly becomes unwieldy. And then again, we're back to we can't do fine-grained authorization because we've got this role explosion problem. And it's a huge problem. And it actually exists. And so this is why people will tell you don't use RBAC. That's one of the main reasons they'll tell you don't use RBAC is you'll have a role explosion problem. And so there's a solution here. And the solution is use attributes to constrain under what conditions the roles may be activated. So remember earlier when I was pointing you to the specification, there was insights 4.94 attribute modifiers on the roles. So ANSI not only allows, they encourage the use of attributes with the roles. So we're going to talk about that right now. So basically what we have, well, that's basically the physical data. So in the first example that we just looked at, we had these page customer roles. So the customer number was actually embedded in the name. And so for every page customer, you had to have a role. Use an RBAC, we're back to generic roles. But we can constrain them by a particular attribute value, in this case, customer. So what that looks like is we've got a new policy construct where we're establishing role constraints where we're saying, hey, this role is kind of special. It's now constrained by something called customer. Now that could be hair color. That could be what kind of car you drive. That could be anything. So the type of constraint is irrelevant to the security system. What you define that is as policy setters. And then you have a construct on the user to role assignment where you're saying, yeah, user one, two, three is assigned to page one, only for customer one, two, three. So in code, we've got to do things a little bit different at runtime before we call create session. Remember, we're talking about the APIs create session is how you create the RBAC session. Before we invoke create session, we've got to push the value of that constraint into the runtime context. So we're saying this user is logging on on behalf of customer one, two, three. And so that's the cue for the policy decision point to say, OK, for all the constrained roles, it's got to match that value, or I'm not going to activate it in the session. OK, that brings us to the next example, which is actually our last example we're going to go over. Let's call the Apache Fortress ABAC demo. That also is in my GitHub account question. Yes. OK, so the question is, is LDAP holding those attributes? And the answer is, yes, LDAP's holding those attributes. So I'll show you that here in a minute. Absolutely. So there is a schema to hold those attributes. If you're interested, I'll show that to you after this. I'll show you the physical data and how it works. OK, so this example is in my public GitHub account. And again, all the infrastructure's there. This is skinning down. We don't have a database. We're not doing SSL and all that. This is really to just kind of illustrate this policy construct with attributes. So it's the exact same policy as before, where you have these three pages and three customers. And users have access according to which page is customer combination. So we're going to log in. Oh, I've got to go to the app first. OK, it's just as ugly as before. Again, this is Tomcat saying log in. So I'm going to log in as user123. So this user, you might remember, has access to all pages for a single customer. So the landing page is exactly as before, where I've got the three links to the three pages. I click on a link. And the buttons are not there as before. Here, we don't have a dropdown. We have an entry form. OK, so again, this is contrived. I would expect the application to push the value of the attribute into the session, not the user. But this is just to show you how it works. So I'm going to go ahead and push that customer123 constraint down into the runtime. When I do that, as soon as I do that, the buttons pop up on the bottom. And now this user can operate on that. So if they try to, say, push a customer ID that they don't have roles, privilege for roles, and they activate that, the buttons go away. So it works exactly as before. Only now we're using attributes in conjunction with coarse-grained roles instead of these roles that are fine-grained. Does that make sense to you guys? So it's fairly subtle, but it fixes the role explosion problem. A fifth example we don't have time for. This is the RBAC A-BAC demo. It's more of a concise, simpler one to use. So if you want to try this out, I'd point you to this one, probably. The other one was just in response to the first anti-pattern of the role explosion. OK, that's it. Closing thoughts never allow users more than they need to do their jobs. That's the principle of least privilege. Apply security controls across many layers. That's practicing defense and depth. Role-based access control may be combined with attribute-based access control for fine-grained authorization. These are the examples that we looked at. Again, these slides are published if you want to try this out. There's a bonus there on the bottom, which is using role-based access control with SAML 2.0. So I like this sample. I used to do it in this talk, but it got pushed out by A-BAC. And so I didn't have time. But the nice thing about this is you don't have to set up an identity provider. I don't know if you've ever had to set up a SAML identity provider. That's not something for the faint of heart. And so this sample uses a common identity provider from SSOcircle.com, which is like a free one. You just kind of register with them, and then you can kind of test with it. It's kind of nice. And then the service provider controls are in the SAML app. And then basically what happens is, instead of authenticating with a web form with Tomcat, you're authenticating with the identity provider. And then you get the assertion gets pushed into the app. And Spring SAML is doing the validation for the deadbolt instead of job at East Fury. So you can move these layers around according to your needs. And then it shows you how to sort of take that assertion and to use it with A-BAC. So that's something out there if you want to try it out. I also keep that one up. There's my contact info. Feel free to contact me. And if you've got any questions, I'd love to hear about them. And you guys have been real patient with me. It's a pretty gnarly talk for the last one of the conference you guys have sat through it. So thank you for your patience. And I guess we can do some questions since nobody needs this room, or we can go have a beer. So thank you. Anybody got any questions? Link for the presentation is at the very beginning. So I wanted to show you the data for the attribute data. So I can do that now if you guys want to see that. OK. I'll let you guys write this down before I switch. And you can just email me if you want me. And I'll send it to you if you don't get the link. I mean, that's a pretty long link. Apologize for that. So any other questions while we're waiting? Did this make sense to you guys? Yeah? Good. Well, that's the thing is that's kind of where the rubber hits the road, right, is testing it out. And I don't know about you. I've been a security architect for a long time. And I never generated certificates or public keys. I mean, that was always something that the IT guys did. So if something went wrong, I was beholden to them. And so that's one of the nice things about that Apache Fortress demo is it shows you how to do that in sort of very specific terms. And that's kind of a nice exercise to do, because you get a really good feel for all the things that can go wrong. And while I wouldn't say that it's difficult, it's complicated in that if you miss any of those steps, it ain't going to work. And it can be tricky to troubleshoot. And so it's good to know that because you kind of get a feel for these things. So as far as the data structures, this right here, this application that I'm showing you is the Apache Directory Studio. I don't know if you guys have ever seen this. This is one of the sub-projects of Apache Directory is the studio, the Directory Studio. And it's a general-purpose LDAP browser. So I am right now browsing the open LDAP instance that's on this machine right here that I've been using today. And so underneath the people folder is a user curly right here who has some constraints, some attribute constraints. So let's look at that. So this FTRC is what we're talking about, which is the fortress role constraint. Yeah. Yeah, you can have multiple roles, multiple constraints. And so that second A-back demo that I showed you the link to, the R-back A-back demo, this is that policy. So I've got Curly, Mo, and Larry are the users, the three stooges. And they can either be a teller or a coin washer on a particular branch. And so based on the constraints, so you can see right here that Curly is a teller in location east. So that teller role is being constrained to a location. And that's the east location. And he is a washer in the north and a washer in the south. Location is just an attribute constraint. So in terms of the way Apache Fortress looked at this, they're arbitrary. You could call it XYZ. You could call it hair color. It's just that it has to match what you push into the runtime. Yes, you can use the location to specify where that role can be activated. Remember, the role is always assigned. But to activate it in the session is a function of the policy decision point at runtime when you call create session. So Apache Fortress does that automatically. So in this case, before we call create session in our program, we would push a name value pair into the runtime location east. And then Apache Fortress, when it's iterating over all the roles that have been assigned, it's going