 Hey, thank you so much for all your hard work in setting this up. Can the fine lady with the tiara stand up? Liora. Hey, Liora, everyone give Liora a round of applause for setting this up. She is the queen of details. Well, let's get this party started, everyone. Let me switch PowerPoints here. You know, I've been working with technology and code and software engineering my whole life and now I'm an expert in PowerPoint. That's really, wow, that's where my life is going. So I want to talk to you, this is a key note, I'm going to talk about a general overview of application security in some way. This topic has been so fundamental to my life, and it's something that's my job, it's my personal passion, it's my hobby, it's all encompassed my life in the last ten years. It's something that's very happy because this is, in my mind, the ultimate puzzle in information security. And I look at traditional security and everything is quickly running to app sec because it's all about code these days, even infrastructure is code. So all of you in this room who are committed to application security, who care about this topic, in my mind, this is what information security is about. Let's give us all each other a round of applause for being here, yeah. So let's talk about the very unabridged history of application security, right? The point I want to make here is that things are getting extraordinarily better in the world of secure coding and application security, and nobody wants to say this, I don't hear this from anybody, but I want to give you some evidence and a debate and some speaking points of why things are dramatically getting better, we're moving in the right direction and we're going to see great improvements over the next decade in this area. Now the thing, and by the way, my name is Jim Annicole, I'll be your presenter today. I'm a former board member of the OWAS Foundation, I wrote a book on secure coding for the Java ecosystem, I invest heavily in the application security space and I'm based in Hawaii, D.C., whatever hotel I happen to be in, so I'm a traveler and I love the lifestyle of traveling and teaching, it's something that's very satisfying, it sates my wanderlust, it's a great life I have because of application security. I see several of my customers in the room, thank you all for being here and for working with me as well. Let's redact some of this and redact it, yeah there we go, let's move on. I want to start back in the beginning of application security or the beginning of information security in a lot of ways. This really all started back in October 1967, this is a task force that was organized by the Advanced Research Projects Agency, this is before DARPA, what led to DARPA eventually and this was a study to recommend appropriate computer security safeguards to protect classified information and this report was actually only written so well, RAN picked it up around 1970, published and eventually declassified this very famous report, February 1970, R609, the first really high end comprehensive report on information security from any major government that was declassified and sent out to the world to review. Anybody want to give me a guess or anybody want to take a guess, what was the summary of this report about the state of information security in 1970 in the U.S. government? Anybody have an idea here, bleep is messed up, it was bad, it was literally like every aspect of protecting information was fundamentally wrong and so, you know what, a lot of us today who are experts in application security, when you take a close look at what you're working on today, the code you're reviewing today, the organization you're assessing today, it looks bad and that's an interesting note about our industry in application security, the people that I know who are working on this problem, especially those who are really passionate about it, they're fatigued, they're a little downtrodden, they're beat up, why? Why is this app sec world that we're in, why does it weigh so heavily on so many of us? Anybody? It's rare where folks write secure code. How often did developers listen exactly what you say about security? Almost never. And so it almost seems like as we move down this path that it feels like we're taking two steps forward and sometimes five steps backwards and it's frustrating, it is emotional drain, there's a high rate of depression and even suicide in our industry, not even joking around, this is hard work that drains people but I want to take a look at all of this from a different perspective. Let's pull back everyone, let's take a look like at 1939 where bomb came out, the first professional pen testing tool. Anybody know what this is? Back in 1939, what is it, go ahead. It's a crypto breaking device, World War II, who is the lead of this project? He's on the currency for you Brits. Is it Turing? This pen test tool is made to crack German ciphers of the era, access ciphers of the era. And how do they build this with software? No, with hammer and nail and wire and cable and electricity, it was a large physical device that helped defend the free world and give us the liberty we may have to, let's just raise that idea for this, we'll get back to that later on. So jumping ahead, we have 1972, we have the Anderson report and Anderson made a lot of contributions to information security but for the purpose of this, I want to highlight two of them. In 1972, he pushed out the Anderson report which followed the 1968 defense science board's wear report in which Anderson also participated. But this report in 1972 came out after Rand. This really set information security research across the world for a decade and finally brought out some of the advanced principles of security defense for the first time, really changed the game around this era. 74, the Air Force starts testing on Amutix, right? 79, Lint early static analysis tools released, holy cow, this tool is still out there and some people are still using it. So we got Lint out there doing some, the original static analysis tool of the industry. We see the security administration tool for analyzing networks in 95. Anybody ever use this? How did this change things when this tool came out? I barely remember that. Wow. Okay, you're not helping. Who else? Who remembers 95 when this tool, when the state didn't first came out? This changed network assessment, one of the first really automated tools to take even lay folk and give them the ability to start doing assessment technology. And 1998, this is Jeff Forstall, right? On Christmas Day at a USNIC meeting is the first one to ever coin the term SQL injection. This is only 98 when SQL injection was first discovered. In 1999, we see cross-site scripting first described by Microsoft engineers. 2001, OWAS WebGoat is released. Why is WebGoat so significant to application security today, everybody? Why does WebGoat matter? Why did WebGoat matter back in 2001? Because for the first time, this very small application security community had a common tool to hack together. And we could suddenly talk about specific kinds of SQL injection, cross-site scripting, test control bypass on a common platform, and it became like the main tool that almost every security tester I know went through in some way. So it helped take all this scattered ideas about application security and give us a common thought piece to talk about. So I think WebGoat was extremely important. Who here has beat up WebGoat sometime in their career? So half the room here, it's a broken web app on purpose. Metasploit only came out in 2003. 2008, 2006, the first OWAS testing guide came out. I think this is, if you look at it as a book, it's not written very well. A lot of different authors. But the content within it is top of the game even now. So we have literally dozens of testers helping write this book around how to test security applications and web applications. Very important guide. 2010, we have Firesheet coming out. We'll come back. And OWAS Zap came out. 2013 is the beginning of the DevOps era. Only a couple of years ago. And what do we have today in 2019? Most major development shops now have some kind of automated pipeline that's doing some form of security testing every time developers touch code. So let's go back to 39, hammer and nail, making a testing tool to like keep the free world running at the time to today where most mature development shops are running static and dynamic and third party analysis tools every time someone tries to check someone in, something in. So pull back and look at this. Are we getting better? Oh, yes, we are in a dramatic way if you look at the history of software engineering. If you look at this moment in time and what you're doing, it is rough. We got to pull back and look at the big picture and let's do some more of that. Let's look at HTTPS. How important is this technology to the secure web today, everyone? What do you think? If there was a major break in HTTPS, what would happen to the web? It's done. So whether you like or do not like HTTPS, it is a fundamental foundational technology that keeps the web secure. It's gotten a lot better in the last 10 years. 1994, Netscape creates the initial version of HTTPS. Moxie Marlin Spike, who's like an activist in the area of transport security in my opinion, he went and called this original engineer and asked him about the creation process of HTTPS. He specifically asked him about the certificate authority system. You know what the original engineer who wrote that said? He said, oh, yeah, I forgot about the CA system. Yeah, we realized at the end we needed someone to sign our keys. So we kind of just kind of threw that in at the end in the last minute. And that is how the CA, I'm not kidding, that is exactly how the CA system was created. Some engineer with a hand wave threw it in there in the last minute and it's now foundational to transport security. 1999, TLS 1.0, something you should now disable. We're in the era where TLS 1 is dead pretty much now. If you look at SSL Labs, another evaluation engines, they dink you for using TLS 1.0. The only lowest level legit TLS 1.1 was pushed down in 2006, right? 2009, this is a big moment in time. SSL Labs releases their free tool from Qualls. I'm not particularly pointing at any vendors, but this tool, who uses SSL Labs in their work in some way? This is, I don't think it's just a tool. This is the standard for evaluating public websites. And when they push this out, and now some of you who know me, at times I'm a bit of a troll, just a little bit. I try to be a happy troll. But I went out and tweeted the URL to every single security company on the planet and their grade, like Symantec D. You're A now, I'm sorry, I'm sorry Symantec, but a lot of big companies and upset companies had very poor grades on their website. And so, and I'm like doing the LOLs and oh, you got an F and could be in a little showboat about it. I had a lot of senior people from different companies say, please stop this, Jim, you're causing trouble. Ivan Ristick, who wrote this tool, showed up and said, I have a suggestion everybody, how about you leave Jim alone and go fix your freaking web server? Thank you, Ivan, wherever you are. Ivan Ristick is the author of SSL Labs. Still, I think one of the most foundational, fundamental evaluation tools for TLS today. 2010, Chrome starts to preload sites. It happened early, where in 2010, Chrome was hard coding their own properties and you can't use Chrome to visit Google properties and HTTP as early as 2010, right? And then, yeah baby, Firesheep comes out. Who had a little bit of fun with Firesheep? That's illegal, what do you talk? You shouldn't do that, that's illegal, sorry, whatever. Back in this era, back in the Firesheep era, which is, yeah, right around 2010, most major sites would log you in over TLS and then drop back to HTTP for performance reasons and Firesheep came out on OSX, you run it, run on a wireless network and you'll just see other cookies light up, click and you're that person and this really forced an entire industry to standardize on what we see today. You're doing HTTPS everywhere, well configured, or you're not doing security. Is there any excuse to use HTTP anywhere, anybody? Anybody wanna play that game with me? Is there, maybe to redirect HTTPS only, but there's no good excuse to use it anymore. Maybe to download updates that are properly signed. All right, let's move on, let's move on. 2011, we see the introduction of forward secrecy in modern ciphers, so even if someone steals your private key, they can't use that to break confidentiality of your connection. 2013, we see TLS12 go live, 2018, Let's Encrypt shows up and they take such a major stance in giving out free certs that we see some of the big commercial players start to sue them and go after them and that's a sign that Let's Encrypt is doing the right thing. It would be rude of me to point that vendor out who is suing them Komodo, that would be rude. I'm not gonna do that. 2000, 2016, half the web is now HTTPS. Chrome 51 now defaults to HTTP too. How can you do HTTP and HTTP version two in a modern browser? The answer is no. So this is a new protocol coming out where plain text communication and bad ciphers are not even possible as early as 2016, that's standard in the browser. In 2017, certificate authority authentication or authorization becomes mandatory so if rogue authorities start minting certs in your name, you're gonna know about it fast. And in 2018, Let's Encrypt offers wildcard. TLS13 goes live, published 8446 and almost immediately we see that live in several browsers and now certificate transparency is required for all new certs. These are extraordinarily high level esoteric ways to augment TLS, they're now standard in the browser. So let's go back, 94, what's the CA system? I kinda threw it in at the end. And what do we have today? Some of the most astute, detailed and effective protocols to lock down TLS are now standard in the world's most popular browser. That's where we've gone. We have come a long way in a very short amount of time and we're only getting better. And there's SSL labs, that's what your grade should be. Right, let's move on, let's move on. Let's talk about password history for a second. So let's start in 1961, one of the biggest password bugs, one of the earliest password bugs in history I could find. This is an old like a time sharing MIT device at an academic university. And you know what MOTD is? Anybody old like me, what's a MOTD? Message of the day. So when you log in, the administrator pops in the midst of the day. So they had a flaw within the system that the message of the day would walk through the messages and then walk through everybody's password. And so the message of the day as you log in and log out would be someone else's username and password. And this is, in my mind, how would you rate that bug? Would you go green? Would you go yellow or would you go red? You go red, he's going red. I'm going red too, it's pretty critical. But this is where we start around password security. 61, really early use of passwords and bleep is bleeped up, right? So let's move on though. 1970s we see Crip 3 released in UNIX and that's using an old M209 code from World War II Cypher devices. They literally took this really old piece of garbage cypher out of military grade hardware that was literally not used anymore and port that code directly to UNIX and that's how they're storing passwords. Password storage is important when your storage media is stolen. We can use supercomputing power to analyze that to crack a password. We see Hashcat as one of the big players in this area. In 1978, Crip 3 comes out. It's now DESP, DES-based. It's the first time we see a stretching part of a password storage algorithm. The first time we see salting and the first modern use of password policy. We're getting started now. But then in the 80s, the 80s were kind of like a dead area in security research. Very few advances from 80s to the 90s for some reason. But we do see UNIX access to the past WD database limited to only the root user. So they're starting to lock down authentication around UNIX for the first time in this era. 1991, MD5-based password storage. It's got some modern properties. We can do better than this. 94, MD5 is based on Crip 3 with 1,000 iterations and a 48-bit solve that can handle two to the 48th potential users. Now we're getting into modern password storage. We see 95, SHA-1's released and 99, we see Bcrypt release for the first time. And by the way, Bcrypt today is still an excellent choice for password storage. Anyone have an advice on how many rounds you should use on Bcrypt? 13 is the minimum that the hash cap pros have told me. Some people say 10. I think 13 is the right number of rounds to slow it down to stop even advanced attackers who've stolen your data. 2000, we see PBKDF2. This is good for military US applications, although it's the weakest of good password storage algorithms. 2001, SHA-2 comes out in 2007. PHP starts defaulting to Bcrypt, giving a whole generation of developers a great default in a common language to store passwords correctly. And Scrip comes out in 2009, which lets you even tune how much RAM each round uses to stop like custom hardware attacks. 2015, beginning of the modern era, we see Argon2 released. And now Argon2i, which allows you to have stretching, slow it down, consume memory, to even limit the number of threads operating on your ciphertext. Boom, we have a real modern algorithm that will last out the next decade. And in 2016, this is a really important date. This is Dr. Devdata Akue from Dropbox. He publishes an article on how Dropbox is storing their passwords. This is the first time a researcher actually describes the details of password storage from a programmer's point of view in a highly accurate and useful way. So this really begins the current era where you really gotta store a password using rigorous techniques, Argon2, salting, maybe even internal salting, good memory hardening usage, good thread hardening usage, and so on. This is the beginning of that era. And if you haven't read this article, I highly encourage you to do it. So now we're looking at OWAS, right? So around 2001, the OWAS Foundation began. This is, of course, the Open Web Application Security Project where a 501C3 charity, our mission is to make application security visible so that all of us, our customers, can all make good decisions on application security risk. I'm a board member of OWASP, I know the community. This is some of the happiest moments of my professional career, we're around OWASP. Some of the most miserable ones being a board member is not always the funnest thing to do, but that's a different story, but I'm really fond of the OWASP mission. I love it when people come in and try to organize us. I think half the brilliance of OWASP, it's not organized, it's chaotic, and people are doing whatever they want in terms of research in this area. So I'm a big fan of OWASP and the people within it. Around 2002, we see the first developers guide released from OWASP. 2003, the first OWASP Top 10 shows up. This is written by Jeff Williams and Dave Wickers in this era as a comment to the Sands Top 10, which was about infrastructure security and network security, and we did our own application security list as early as 2003. Unfortunately, PCI picked it up, right? And they said it was a standard. It's a top 10 list, but that's a difference. That's a different story. 2006, the OWASP testing guide work begins. OWASP reform and ASAPI come out. These are the first two libraries, really early era that help you stop cross-site scripting and are meant to be security libraries to solve some of these web security issues. At 2008, the first standard from OWASP comes out, the application security verification standard. I'm one of the members of that project. It's really meaningful to me. We just released version 4.0 recently, and I do believe it's one of the most rigorous standards for secure coding and for assessment professionals. I'm a big fan of the work of the team that puts it together. 2010, we see the start of ZAP, Mod Security Core Rule Set moves to OWASP. These are tools used in the ZAP. I mean, ZAP is a professional tool that goes head-to-head against BIRP in terms of its scanner capability. It's free and open source. Right on. That work started about nine years ago. 2013, we see a defect dojo. 2014, Juice Shop shows up from our friends in Germany. This is a full mean stack application, Angular, API, completely vulnerable as like a CTF to teach you how to hack. And it's frankly, it's a commercial product. It's such a brilliant piece of code. It's a commercial product. This is a Jordan Stimmits who just is obsessed about making this as high quality as he can. Understands his responsibility as an open source developer. Who's hacked a Juice Shop? Who's done Juice? Half the room again. You agree it's that sophisticated? I'm blown away by the detail in it. And as he publishes more and more, he drops all and puts these poppin' new labs into it too. So he takes it seriously. 2015, we get Jeremy Long showing up. Jeremy Long was working at Wells Fargo in this era. And he needed a third party library security solution. I won't mention the vendor. That would be rude. So they show up at Wells Fargo sonotype and ask him to buy their solution. And they're charging a lot. And he's like, I'm not going to pay for this. They go, why don't you go build it yourself? And they walk out. That's what Jeremy started doing the next morning. Yes, sir. What did he do? He started building it himself. So he actually is the main author of the OWAS dependency check product. And this is literally another commercial product you can wire into your pipeline to check out if your third party libraries are up to date. I'm really proud of Jeremy. He wakes up at 5 a.m. to work on this to relax before he starts his day as a software engineering banker. So a brilliant, brilliant piece of software. What else do we have here? 2018, the IoT top 10 shows up. That's how you know things have jumped the shark, where we have now like 20 top 10 lists on every topic there is. And 2019, just a matter of a couple of days ago, the OWAS cheat sheet series just made flagship status. And we have over 50 cheat sheets helping developers write secure code. So what do we start? We see OWAS founded in 2001 with like a one page web page and about 20 people who are just starting to get started. And then not too much later, what, like 18 years later, we have books, commercial products that compete with the public sector and a number of publications that are hit, literally tens of millions of times a year to help people write secure software. I know it's stressful. I know what we're doing is challenging. I know a lot of us who go home upset every day at the frustration of our jobs, you got to look back, got to pull it back and look at how things have changed in just 20 years and you'll see we're not just getting better, we're getting dramatically better. And take a look at the OWAS flagship projects that we have here. They are instrumental in application security work today, whether they're open source or not. So let's talk about one of my favorite topics, cross-site scripting, right? Cross-site scripting is, of course, content injection, JavaScript injection in the browser, in a mobile, in a web-based user interface. And this is a problem because there's been so many attempts to solve this problem. Anybody ever do an assessment with no cross-site scripting? One, tell me about this app. Was it a web app? Okay, it was a web app. Gotcha. Now, to do access to defense, you need to do contextual output encoding, you do HTML sensitization of untrusted HTML, you got to make sure using proper JavaScript functions, get your content security policy, embed JSON with serialization, make sure you do trusted types in your library. It is really tough. So to find an app that doesn't have it is extremely rare because of how complex the problem really is and how poor web standards are at addressing cross-site scripting. Cross-site scripting was first discussed in 1999 by Microsoft engineers. And in 2002, we see Microsoft rolling out HTTP only. Why is HTTP only important? What's that? It's not integrity. It's cookie confidentiality in the face of cross-site scripting. It's to stop JavaScript from accessing cookie data. And actually, you know, it's not even that important, I dare say, because if I get XSS in your app, I don't have to steal your cookie. I'll just force a request, which will automatically use your cookie anyways. I can do a stored request forgery. It's not that important. We still should use it. But as early as 2002, the first defenses at the standard level was coming out for cross-site scripting. 2005, go Sammy. Oh, yeah. Sammy, most of all, Sammy is my hero. This is the first time cross-site scripting was used to conduct a worm against a major social media site. This one little attack we're looking at right here took down all of MySpace. It blew screen the entire global cluster of MySpace because Sammy had forced someone else through cross-site scripting to do a forgery quest and make him a friend just by looking at his profile. And if you looked at his profile, you'd have a copy of his profile on your friend list, and if somebody looked at your profile, Sammy would be added to them as well. So you'd be added to Sammy's friend list as well. Within a few hours of releasing this attack against MySpace, Sammy had millions of followers, and that follower count was so high in loading from the database that the entire MySpace.net app at the time, problem, blew screened across the world and took days to recover from XSS. Oh boy. So let's go ahead here, 2005. Omicline releases a famous article about cross-site scripting DOM XSS. I don't even like the definition today. He says that it's a fragment that you can't see on the server. I don't agree. You can have a stored XSS that's DOM based and how it executes. So I think of DOM XSS is you got to write JavaScript code properly to stop the risk. Use Reactor, Angular, or low-level JavaScript correctly. 2006 reform comes out to stop XSS. The XSS prevention cheat sheet was first written in 2009. Again, Jeff Williams, the most heavily hit resource in the history of OWAS, that one guide. 2010, the goat love worm strikes Twitter. The second major XSS worm because of one malformed URL and how Twitter handled URLs. And even Apache's entire infrastructure was popped with XSS via 2010. A lot of people are like, I don't care about XSS. It's no big deal. That is not a good attitude. Sorry, folks. We've seen XSS do massive damage across the world many times in recent years. 2011, modern tooling comes out. We have Jeff Ikenowski, Professor Ikenowski, writing an encoder for Java, the only good encoder for the Java ecosystem. And around the same time, Michael Samuel from Google releases the Java HTML sanitizer through OWAS to do sanitization of untrusted HTML snippets. These are two of the most brilliant security engineers I know of and they open source their work. We had to twist their arm a little bit, but I'm Ceciline. We know how to do that. So 2011, the DOM XSS prevention cheat sheet comes out of Wells Fargo open sourced. 2012, CSP1. 2014, CSP2 in the original DOM Purify library. And 2015, we got CSP3 released. Take a look at the work of two Google engineers, Lucas Weischelbaum and Michael Michelle Spagnolo. They released a series of talks on how do you CSP3 with a very simple policy that you can roll out quickly and get a great defense across any browser and it degrades properly. And that's kind of the state of where we are today. Now, in the future, we see Chris Christoff who leads a Google Zero project. He just released trusted types in the browser. So as a programmer, you can programmatically set defaults on how the browser handles certain syncs in JavaScript. This is the solution to DOM XSS by far. So where do we start? We started with HTTP only and Microsoft engineers talking about this without good defense strategies to now standards being written that are effective in the browser to eliminate this risk altogether. I predict because of CSP3 and trusted types that XSS in under 10 years will be largely eliminated from our ecosystem of web applications. You can quote me on that. So trusted types, if you haven't looked at this yet, it is a key progressive future technology that we're going to see in our frameworks in the very near future. It's going to change the game in terms of browser security. Here's a few more important dates in AppSec history. Again, Netscape released HBS in 94. We see TLS in 99. Where am I going here? We did this already, didn't we? We're going to move on here. We're going to move on. We're going to move on. So now where are we today? AppSec is now global. I travel the world giving talks on this topic and you'd be surprised the countries and the people that still ask for these talks. It's everywhere in the world. AppSec matters. Small islands in the Pacific but small governments care about AppSec. The smallest companies now realize the code they're writing is their security and OWAS has 264 chapters of people just interested in this topics at a meet-up level all over the world. Again, 20 years ago this topic was not even discussed. Even five years ago very few folks were doing AppSec type of services and today is a global phenomena how much AppSec services, tools and professionals are needed. Are you with me on that folks? Who here is an AppSec professional? How many of you that are AppSec professionals are hurting to find work? Please raise your hand. One. That's a personal problem. No, so. Was that rude to say that to him a little bit? All right. Good to see you. Anyone know the unemployment in the AppSec industry right now? It's literally zero percent. Hey, Linda, are you looking to hire anybody in AppSec? Yeah, yeah. Get out of here. The mine. I get them first. If you do AppSec the world is your oyster right now and it should be because this is a hard topic. It takes years of ramp up to be effective and in my mind, AppSec is really where the rubber hits the road when it comes to information security. Yeah, you can go hack your pretty badge. I have fun doing that too. You can go parachute with your toaster and it's good. But my belief is those of us who are helping secure code who are working with developers, working with organizations to actually secure applications, in my mind that's really what information security is today. As we see the next 10 years progress as your infrastructure disappears and it becomes all cloud based your security becomes a YAML file. So code matters not just at the app level but at the end of the day. AppSec is not done and the work is extremely important as well. A few notes of how things have progressed. AppSec has become so important. One of our volunteers, John McCoy has led the charge to make sure OWASP does outreach at DEF CON. I'm really proud of the work John has done. He's been at DEF CON since the beginning. It means a lot to him and he wanted to make sure AppSec was here. Same with the folks who organized the AppSec Village here. We see OWASP doing that as well. I'm just really proud to see the passionate volunteers care to spread the word of AppSec in a community that's traditionally not very AppSec based. In 2018 OWASP gave out 35 scholarships. This is another amazing professional Zoe Baderman who runs Women in AppSec for the OWASP foundation. And we even allocated $25,000 just to diversity at our next big conference. I know this is kind of a diversity. Yeah, exactly. An inclusion. I know this is a politically charged topic just mentioning it upset some people but I think it's important to try to make a difference in this area because we've not done that good at this as an industry. The conferences I went to ten years, the things I saw are just not right. I like the idea of trying to clean up the mess to make our conferences and our community safe for everybody. Does that make a little bit less fun? I really don't care. I care about safety and I care about making places inclusive for everybody so we can learn together. And if you don't like that, go f yourself. Thank you. So let's talk about the future. What's going to happen in the next 20 years, right? So, yeah, aging. These are my like conspiratorial ideas and some reaching into the future. This is where I think we're going, right? So number one, all identity becomes tied to blockchain-like security architectures. It's hard to even say those words. I'm sorry. But seriously, I don't care about Bitcoin. It's all fake money anyway. Sell your Bitcoin and get real money and real investments enough playing around. Come on, people. But the concept behind blockchain and the integrity behind it I think is really fundamental. It's tied to that so we have accountability at that area. What else do we have here? Hardware-based authentication and individual HSMs for every person on the planet will become the norm. And we already see that. We look at NIST Special Bulletin 863B, which is your homework. You got to read it. SP800-63B The Digital Media Authentication Guidelines for the U.S. Government written by Jim Fenton. Amazing piece of work to achieve AAL Level 3. This is authentication for critical infrastructure or you're handling billions of users' accounts in similar level of risk. You have no choice but to use hardware HSM. In fact, in European law with banking, you've got to use certificate-based authentication. So when I wrote this a year ago, it's now actually come to pass and it's already in the legal system. We're going to be forced down that path. I do believe like any other multi-factor technology that involves you typing in a number, it's vulnerable to phishing, it's garbage. We're at the era now where we've got to push to hardware like a Yubiqui type tech if we care about security. Bob Lord gave a keynote and he's like, look, I know we got ML and all this fancy stuff but I'm rolling out Yubiqui to everybody and I think that kind of back-to-basics thinking is going to make more of an impact than any MLBS we have out there on the market right now. Extremely secure frameworks in languages defaults are the norm. This is already happening. Anybody use React or Angular? Anybody assess React or Angular? How are your assessments? Is it easy? No problem? You're lighting it up? I'm saying when you see Angular, do you see an improvement? React. Do you see an improvement in security posture? Let me give you a quick hint though. Let's attack React six ways real quick, shall we? Real quick. Number one, dangerously set inner HTML. React prior to point one four, easy bypass. Embedding of JSON with string of phi, you can always bypass that with easy XSS. Anytime you're using props or types in a create element, boom, neither of those can escape. There's another easy vector. Five, let me see if I can pull this off. All the CSS stylers in React, they don't escape by default. You got to get in there, fix that code, CSS escape, native and JavaScript. Six. Let me see if I can do this. I said five or I said six? I said six. Sorry. Five. What was that? I'm going to come back to that. I got five. I'm going to go five. We got five. Five ways to pop React. Like I was saying, five. Cloud native serverless security functionality drives most software. That's not even that advanced. That's already coming to pass. What's the most important language in the cloud native world? If you're doing lambdas, what's the most important language today? JavaScript. Python. Oh, my God. Python. I'm a Java guy, so move to Python. Hurt me a lot. The most important language in the planet right now, by far, is JavaScript. If I was in Deadpool 2, I would go back in time and find Douglas Crockford and Brendan Eich and just Jack Bauerham off the back of a truck somewhere. But we're stuck with it. No, I love you guys. I'm sorry. We're stuck with that now. Smart contracts. Whoa, whoa, whoa. Getting a little alien here. Smart contracts control most real world infrastructure. Interesting. Appset critical tasks augmented by AI type systems. Whoa, whoa, whoa. I'm getting, I'm getting, I'm going to put them all up here. What else do we have here? At the right key, Jim. Secure architecture design becomes common and mandatory. Why did I put that in there? Because it's happening in the world of insurance now where these these kinds of architectural views in the world of healthcare in the world of cyber insurance. It's now becoming the norm in certain industries where this is required and I think we'll see this trickle out to other industries as cyber insurance becomes more important and other industries realize, oh yeah, the security of our devices matter early on in the life cycle. We see an HTTPS will become the norm of the internet in all of our lifetimes. There will be a day within our lifetimes where none of the internet is playing text traffic. We're actually approaching that extremely quickly right now. We'll see that the current CA model needs to burn in a fire and we'll see more distributed CA systems that will take over the current centralized mafia style CA that we see now. Did my CA opinion, my opinions on the CA system come out in this talk? Yeah, I think they did. Automatic data sanitization and escaping is native in all major languages. We see that in technologies like Go. When you're using Go templates, it does extremely rigorous, astute contextual escaping by default. We see that in React. We see that in Angular and if we look ahead 10 years, it's going to be default and native in every UI type of framework out there. Because you know UI frameworks, any JavaScript developer is like, oh that's a nice framework but I could build it better. That's why we have 50,000 new frameworks published every five minutes. It's nuts. My vote is if you're a JavaScript developer and you write a new JavaScript framework you should be banned from development for three years. You're out. Sorry, sorry. Data centric access control, native at the data level or not the kernel level in all major databases and OSs. One of the biggest failings of our industry is we have not done a good job helping developers build complex access control. The entire industry helps us solve the easy problems of role-based access control but when you have access control problems like multi-tenancy, data contextual access control and other complex topics, our whole industry fails to solve that. Someone needs to solve that and even the best out there don't because of how hard the problem is. I actually teach developers, most of you should be building your own access control system from scratch because commercial products don't address the hard problems and that's what we need to solve. So I still think access control is one of my top 10 items near the top of that list. So before I wrap this up, we're closing up just a few minutes. Does anybody have any questions about anything in the world of application security before we wrap this up? Yes, sir. Where is the queen of detail? Queen, my queen because she was not involved, she got involved, she made it happen and we're done. DEF CON is really about glorifying the hacker. DEF CON is about glorifying the beauty of breaking things hopefully for good in some way and it's glorified here at the most magnanimous level of anywhere else I've seen. So those of us who are doing app sec we tend to be of a builder bent even though we do pen testing a lot, we're still working with developers, helping people fix software, that's the real, to my mind that's real app sec work. That's very that kind of thinking is kind of counterculture to DEF CON but the world of traditional security and application security have collided so hard in recent years the app sec is no longer a secondary thing. App sec is information security in the modern era and that push is going to happen only more and more in the future. That's my opinion on that. You had a question as well, sir? Yes, ma'am. Honestly, that's all I have to say about that. I don't know. I'm not trying to be rude in any way, sir but my answer is, what was it again? That's all I got. All right, you're up. I'm sorry, ma'am. Yes. In all the studies I've seen a lot of big shops have done studies on this. They've looked at all different languages, frameworks and similar. Do you know what makes a difference in terms of the number of vulnerabilities per framework? The team building that code. So it really doesn't matter what you're using but you need to have in my opinion, you need to have number one an app sec professional who knows how to write secure code, embed it with your team day in and day out and you need to have mastery over the framework you're using a priori before you get rolling. Without those two things the chance of you using that framework securely is zero. That's why even among relatively decent frameworks you still see insecurity. Because the expertise to use these well is still esoteric. And so I don't care if using one framework or using 20. And if these are important apps to you you need to have expertise about a configure, use and code to those frameworks in a secure fashion or your chance of releasing secure software goes to zero fast. And in my world, I'm an educator. I teach to write secure code. I go back a few years, there's Java things that was easy. Now today there's this proliferation of frameworks I've had to bring in many other instructors who have specific expertise in each area to make my customers happy. This is brutal. The research needed to be done to teach developers about secure coding is getting rapidly more difficult in a lot of areas because of this problem. So if you do have a company using every framework under the sun, that's usually not a good sign in your ability to write secure code across the organization. I'd recommend doing a long process to reduce the attack surface to standardize a couple common frameworks. Get rid of the esoteric ones you don't need. It's easy to say, hard to do. That's why we're here to help solve this problem, man. Thank you. Yes, sir. Well, if you're writing a vulnerability in a web app, it doesn't matter if you deploy it locally at your company or in the cloud, that is still there. SQL injection still lives in the cloud. So in my world, the cloud has only changed the world of secure coding so much where my bet was wrong on that concept is the whole idea of a YAML file. So much of your infrastructure is now code. And I did not see that coming. Did anyone see that? Did anybody see like four years ago, besides Jack Minino? Anybody see that? Hey, what's up, Jack? How you doing? Jack was telling me this four years ago and I was like, I'm nuts. He was right. He's like, all of infrastructure is changing to source code. And that's something I didn't see. And being able to lock down your cloud configuration, guess how many static analysis tools look at that well? None right now. It's a hard problem. No diss to the vendors. So, yeah, this is a rapid evolution. The cloud is going to dominate obviously. And it doesn't stop our responsibility for writing secure code at all and our infrastructure is moving to code as well. We have to assess that configuration as well, which is really difficult to do right now. Hey, that's why we're here. What's that? What about it? I personally think containers are dead and I think the real future is serverless technology. I do not want to maintain a container. I do not want to maintain a Kubernetes cluster unless I really hate myself. It's a complex style of BS I've ever seen. Even though it saves money, I don't want to have to tune infrastructure anymore. I want to go new lambda, drop code, have it run 50 million security tests and I'm live, baby. That's the future of computing. Not containerization, not Kubernetes BS, not OpenShift, but drop code and run serverless. That's the future, in my opinion. Jack? We'll drink about it. Web application firewall. Ooh. Ooh. I'm a founder of Web Application Firewall Company. I can't answer that question objectively, but I'm going to quote Jim Bird. Even though I've invested in one and I care about the space, I'm going to quote not Jim Bird, I'm going to quote, I forgot his name, but he's one of the largest executives who ran software security programs for the healthcare world. WAFs are for wimps. Fix your freaking code. That's really my take on it. And I founded a WAF company. Let's move on. Rust. Rust is the future, I think. Rust is such a brilliant language. One more question. How much time do we have? Where's the time, guy? Ten minutes? You like Q&A? More Q&A? What you got? IoT. Really low-power devices that can't do TLS and stuff like that. It's the same problem starting over. A lot of the IoT device comes from manufacturing. Anybody work in manufacturing? How good is manufacturing at doing software engineering? Exactly. I need to consult an expert in manufacturing software engineering. Ma'am, what's your name? Iris, how do you think the manufacturing industry does at software engineering? Really bad. It's horrific. What's the problem with IoT? So many IoT devices are coming out of an industry with zero software security culture. In fact, let's go back in time. Brazil 2015, ASUS Router was given away as part of your internet service to third of Brazil. And this router, if you're in Europe, router if you're American, right? This had two vulnerabilities. You can hit the Change Password feature without being logged in and the Change Password feature didn't require the original password. And this was given out to a third of Brazil. So five million people get C-surfed and have their DNS settings changed to an attacker-controlled DNS, which was trying to get banking fishing across every South American and Mexican bank they can get their hands on. This is heavy duty. I actually hunted down the product manager of that router as a research project, right? I found him on LinkedIn and he's retired. He's like, hey, can I talk to you about this ASUS browser? Oh, sure. I'll tell you anything you want. I'm retired. I don't care. All right, this is going to be great. How did that router with those vulnerabilities go? I remember them well. I saw the paper. How did that get out of security testing? And he starts laughing at me. Guess what the next comment was? What security testing? But I'm pumped. Next question. There's my IOT answer. Yes, sir. What's that? This is like the successor to FIDO for hardware authentication, right? I don't know the details of it, but those I know who research it and are astute, I think it's a huge improvement on FIDO. Remember, I'm suggesting hardware based authentication is the only possible secure future for identity and Web Authent is going to really make that a reality across web apps. Let's see what happens, right? Ubiqui rollout is pretty small. Who is maniacal using a hardware token for all authentication? Only like 5% of the room and we're security professionals. It's not easy to adopt. A couple more. What we got? Yes, sir. What's that? Mongo. Magno. Code or die. If you're a security professional and you want your career to continue to advance well, you need to learn the basics of how to code. And when I say this, a lot of people's feelings get hurt. I said this on Twitter and several pros block me out. And one of the guys that blocked me out from DC is a friend of mine and I'm like, why did I get blocked out? What happened was he just interviewed for a job a very big director position at a big software security company. This is a guy, no, he's super smart. He didn't get the job. Guess why? Because he didn't code. And I felt bad that I unintentionally rubbed out any block me and he will not speak to me to this day. I feel bad about that. But he should learn how to code. And I don't... I don't I don't mean this meanly. Learn a little bit about HTML. Take a few basic classes on secure coding. It's all just software engineering. It's all free on the net now if you want to learn. So honestly if you're an AppSec pro and you're not willing to take a little bit of time to learn about software, just a little bit to learn about code I think it's going to do harm to your career. You'll still be successful. You'll still get stuff done. But learning how to code augments your career in so many ways. And I'm going to bug Jack for a second. Here's what... Jack is basically a bastard but I respect him for one... Am I right? Am I right? It's mutual. But there's one thing I've always respected about Menino over here. He's now like a CEO of a company with a lot to do. How often do you code in Jack? Every day. He's a CEO of a company and he's coding every day to keep sharp. That's what you want to do if you want to get ahead. Jack! So one more question up front. Set requirements. Go grab ASVS 4.0 Grab your lead developers, your lead architect and your lead security folks and set a definition of what AppSec is going to be for your company. I'd use ASVS 4. There's about 284 requirements to base that. Now, and pick which level? One, two or three. I don't care. But I have some requirement lists. So we all have a common definition of what secure software is going to be for organization. This is a little bit self-serving but I don't mean it to be. This is what a lot of the other SDLC say. I would also rigorously train your developers as early in the project life cycle as possible. If you're training them at the end, it's the worst place to do it. Early on, just some basic training. I don't care who you hire. So that all your devs understand the basic OASPY type of risks or whatever the risks are specific to that platform. Three, I would make sure early on in the project that whatever frameworks you pick, that you go out of your way to have someone be a massive SME, subject matter expert in how to secure that framework from a programming point of view. And everything will flow from there in my opinion. That's my take on the world. Not a very popular one, but it's my take on how to approach AppSec from a software engineering point of view. I'm John McCoy and Zope Raderman for helping with the research of this presentation. And I want to thank you in the room for helping the world be more secure, have a great DEF CON, and go forth and write secure code, and help your friends write secure code. That's how we lock this stuff down. Thank you very much, everybody. All right.