Appsec requirements with OWASP ASVS

one drink and that's it it will introduce our first speaker of the our air yes Yara Thank You Ryan great to be here all right so I'm here to talk about application security how many developers are here today oh that's a lot how many are doing testing anyone specifying requirements yeah so it looks like I got something for almost all of you because application security is concerned to many of us and that's why Oh wasp has actually a standard for application security isn't that a wasp top ten you say well I'll go into why we're talking about ASVs today and not top ten first of all I'm just going to give you a little bit of

context because I am working with security and people but not as a consultant I'm a founder and I'm a founder of a software company I'm not going to do advertising just to give you context because we do software development and that's why we also use SPS so just since not all of you probably know who we are we're a start-up in Trondheim here in Norway and we help people with suspicious emails and just like Google we have a button that you can click in this case to get help with your suspicion and find out is this a dangerous email or not even though all the spam filters machine learning didn't catch it so we use

natural intelligence and plus plus and then some gamification to make it fun okay so it's a cloud service we obviously need to take security very seriously right because a breach for us would be very damaging but there's also another reason why we do something structured with application security and that's because we're a start-up and if large corporations are going to buy our stuff well they need to have some confidence in us so our purchasers are actually security people as well so they would are likely to ask so what'd you do about security a SMS helps us with that I forgot to skip the slide sorry as well is a tool developed for architects developers testers

security professionals tool vendors customers to define build and verify secure applications it's a baseline it's a checklist it's a testing framework it's many things that's why it's something probably for most of you it was top 10 then what's that well that's a lot about awareness we have these big major issues like putting these JavaScript things into input forms SQL injections we heard already major problem being there all the time in the top create awareness about these big issues but it doesn't solve all the problems for you because these are complex issues and in order to produce secure software we have need to do it right and usually not for reinventing the wheel all the time so

we're over the top 10 gives you for instance on broken authentication some advice to check how your application can be tested is it vulnerable and then have to prevent one two three four five six seven eight bullet points on a page how to avoid broken authentication looks simple that's not the whole picture but it helps you to get started it's really good for awareness but it's not the complete picture so that's why as less as a standard the authors themselves writes in the forward it helps you to step up to an actual security standard so what is as yes well it's a lot of requirements and these are verifiable requirements and that's why they all begin with

verify that da da da da something and I jump it to the various parts here here's the requirement here is a number so you can refer to it 1 1 1 this is the first one verify the use of a secure software development lifecycle that addresses security in all stages of development simple this is one of the bigger requirements that requires a bit of work but it's still it's it's also a good entry point for working with secure software that you actually make it the job of all the people involved in developments then we have these levels here and this is actually it's not applicable to level 1 but level 2 and 3 level 1 is the level of your application

risk as you can see consider it we're actually level 1 represent requirements that everyone on the internet must really do so if you want to create the secure application do all the level one requirements it should be pretty good actually that's all you need to know as we will see there are many requirements to that but due to the level 1 and you're good for many parts this not all have this maybe they have one security guru who actually is doing very much work and it helps a lot but level 2 is should everyone should level 3 is high critical applications lot of financial data medical data nuclear power plants stuff like that so we see must should and high

assurance choose your risk level and do the math and then we have these categories it all shows you the the whole application development lifecycle main points 286 verification requirements mmm that's a lot of requirements it would be a lot of requirements to figure out yourself so it's a good thing that somebody did it for you is this the truth well it's a good place to start it's not the whole picture either there are several parts of your application development lifecycle we need to impact to resolve these requirements your architecture your coding how you do code review dev SEC ops how you do fan testing static analysis testing etc as well is a PDF and CSV it's on there

always web pages but here is the PDF where you see passwords I chose passwords it's section everyone can relate to requirements as we see it's based on NIST 863 B which is the famous standard says that passwords should not be replaced periodically for instance so it's really up to date and it's building on other standards as well so it's not just something I was people have been figured out themselves an every C first requirement verify that user set passwords are at least 12 characters in length here is a choice made on the length but it is actually based on something and you can read about that in the standard etc number to verify the password 64 characters are

longer are permitted who can remember those long passwords password managers right so this is a good help for you to think about the things that you need to think about but you don't have to come up with everything yourself as you can see both this apply to all applications regardless of risk level but instead of having a PDF I mean it's a bit tedious to just read them kind of circle around and it's on paper and stuff so for our own internal development we use Excel spreadsheet built a system for it it looked like this a bit noisy sorry about that but it's a spreadsheet and what we did was just take all the requirements

this is here verify verify verify verify and section it then we have also imported the levels and then we have a column here selected some are yes and some are actually no hmm and that's our choice to make SOS is not the truth you can challenge stuff if you have good reasons for it and I'm going to dive in a to a couple of those we also have a maturity columns here and we have a risk column these are not part of a yes it's just a tool that we use so first of all verify users can change their password okay we have that in our application why do you need that well some might have a

password breach not your application but they used reduce their password maybe so it's easy to select and verify just test it can I change my password yes done good this is where we see ASOS versus top 10 top 10 had eight bullet points for authentication as well has 57 requirements for authentication plus 20 more for session handling so that's the whole picture at least compared to top ten one reason also why I'm talking about as well as now is there is a new as well version for that came this spring actually and that also has undergone a major change so before it was only twenty six authentication requirements so it increased massively because of alignment with the NIST

standard for instance so it's a massive work so if you've been using it trying it before have a look again because some things may look different and better so the question are these level one requirements mandatory as I said well we have said no to something for instance verified that posture change functionality requires the users current and new password no we don't require that why do you do not do that well currently since we're a startup we cannot implement everything from the get-go so instead of having is kind of your profile here you can change your password etc we just tell people to okay if you want to change it use the forgot password feature and you get the token

sent to you to reset we're not complying with this requirement but still the intention is fulfilled at least from our point of view in terms of risk and so we comment that and need to know so is everything yes and no that's also a good question do we have it or do we not verify that well that's the simple yes/no maybe well we all know yeah I know we do that have you checked it no not really I just expect it to be like that something in between that makes sense yeah we have a ticket for developing it but we haven't done it should we say yes should we say no so that's why we use maturity instead

and this is to align with our information security management system also where we do this current and target maturity levels and we have also specified I'll show in the next slide what does these numbers mean prisons verify that unicode characters are permitted in passwords people actually want to use emojis as their password think about that well it's a good thing yeah we haven't done anything that I think should make this impossible for users we have multiple characters we use standard hashing that should support it I haven't tested it so it's a three but it could be a four if I test it and it could be a five if I can automate automate the testing so I say yeah I

want to be out of five it's not a big work to do so I say okay we set target to five we have to as a residual risk it's not part of as vest but it's just how we do it it's not the truth either but maybe it can help you so here's our table non-existing mean we have chosen not to do it this is where we say selected no we don't believe this is a problem one initial yeah we're aware that always pays versus as this is necessary I don't know if yeah we don't have an implementation we haven't consider it properly number two it's managed yeah we have an implementation but it may be omitted if it's to be done

repeatedly so it may be in part one part of the application but not in other depending on the developer etc three defined we have a standardized way of doing it all developed developers are trained and aware for it can be verified tested maybe it has been tested properly and five optimized it's doing automatically so talking about numbers what is our application risk what is it 41 no its 380 at least the fifth of May out of thousand and 59 how do we get there well you see we have these numbers here so if you add up all the target numbers that's the grand total of the where we want to be and if we are at our

target level and we can defend that target level s that's the secure level for us our risk profile okay then we have a secure application and then all the remainders that's where we have a residual risk here does it mean we're vulnerable there are very few emissions from the 280 requirements that we not doing and we should be doing where we not doing at all because that's the vulnerability there are a handful that we will fix of course but it's all about maturity level because it may be entered the application later if multiple developers are doing mistakes all over so what's the risk well it may be red yellow and green if we use like a

traditional matrix if we are on this 3/8 out of thousand fifty nine we have a thirty five percent risk oh that may be green but point is to show there is some development we have some remaining things to do our target is zero because that's the target we have set so I have three minutes left most all 286 be considered well there are 14 categories you may want to just do the authentication stuff maybe you're buying an application you want to test do they actually care about the application security well you don't want to test all 286 do you want to ask them for their ASVs spreadsheet maybe they only have any well go ahead and test one

category maybe that will give you an impression of where they are because point is these things can be tested all level one requirements can be tested black box level two and three may or could require hybrid reviews or you need access to source code developers documentation etc so just a couple more examples where that verify the users have a method to remove or export their data on the mom this is from the data protection section gdpr compliance that's also part of it verify that security LS is used for all client connectivity and does not fall back to insecure and encrypted protocols each test do you SSL labs scan for instance should be in place for all applications

verify the application never revealed sessions or tokens URL parameters session management easy to detect if you do some basic testing verify that compressed files are checked for zip bumps small input files I will decompress into huge files thus exhausting file search limits did you think about that in your application recursive zip files well level two requirements not the factor verify that random numbers are created with proper entropy even when applications under heavy load that's high level that's high assurance you don't need to have it can it be automated yes almost half of them can be automated I don't know how but I know how someone some of them can be automated and you may require access to

business logic flows that that's the hybrid testing part output from our spreadsheet is put into JIRA we have tickets for following up where we have gaps so that's one way of just putting it into our workflow and then when you complete this update table item two one for when completed okay move on so to sum up here's what you can use as best for a lot of things uses as your architecture guide replace all your off-the-shelf or custom made secure coding checklists use it as a guide for automated units and integration testing for development training take one part and train on that as a driver for agile application security or as a framework for buying software point is do not

reinvent the wheel people have been doing really great work to make it easier for you so mix-and-match and build secure software I'll be around so ask me if you want to know anything else thank you

you