Software Security Engineering: Learnings from the Past to Fix the Future

hey all um and thanks for sticking around i hope there are still few people who are still around it's i know it's end of the day in delaware and uh thanks to besides delaware for having me uh my name is debasis mohanty and today i'm going to talk about software security engineering learnings from the past to fix the future so before i dive into the presentation a little bit about myself and how my experience is relevant to this talk presently i had the security services at sacra security it's a new zealand-based security consulting firm i have a little over 20 years of offensive and defensive security experience i have been working since 1997. the vast majority of my

experience has been related to a vulnerability research and exploit development but i have also spent 10 plus years working with midsize and large technology companies i have played their security engineering center of excellence and have worked closely with multiple engineering teams to integrate security across sdlc lastly i'm a simple security guy who likes to solve complex security problems using simple methods in case you like to touch base with me my personal details are below so um i have kind of broken down the entire presentation into four main parts i'll start with the history i'll talk about i'll showcase some of the historical data about some of the bugs that has been around since last two decades and

then i'll go over the reason why do we still continue to see these bugs for the last two tickets and then i'll talk about some solutions how to tackle these bugs so that in in future we don't get to see continue to see these bugs forever and then i'll clear some misconceptions around software security engineering life cycle to begin with the history so what you are seeing here are the top three application uh specific bugs so i assume most of you must already be familiar with these um application bugs so these are the top three bugs that has been around since last two decades so cross-site scripting was first time reported or exploited back in the 1990s

um and uh it was only in january 2000 microsoft gave it gave it its name called cross-site scripting sql injection has got a similar history it was for the first time mentioned in 1998 in the frac magazine and dc relation bug although it is not exactly uh two decades old but it is pretty much around the same time that the first bug was reported which was in the year 2002 august right so this is again not a comprehensive list this is the top picks from some of the bugs that has been around since last two decades these are application specific i'll also showcase the top three class of bugs that um that affects operating system

and os native applications so again most of these bugs must be already be familiar to you i'm not going to uh discuss definition here what is important to note is the timeline um so buffer overflow is is a broad class you you it can include things like stack overflow or heap overflow but it's a broad class it includes a multiple different types of overflows here so it was only in the year 1996 um sorry buffalo pro was first time uh publicly documented in 1972 and in 1988 a worm called morse worm leveraged buffalo upload to exploit uh systems and praise spread across network and it was in the year 1996 for the first time um

someone wrote an article called smashing the stack for fun and profit which sort of outlined how to exploit buffer opera and this was by alias levy who goes by the handle lf1 if you have never read this article i highly recommend reading this this is the original this is the first article um which talks about um how to exploit buffer output so if you are into you into exploit development and you have if you have never read this article i highly recommend going back and reading this um rest condition has got a similar timeline it was in 1995 it was documented in one of the publication and in year 2001 a bug was reported got a cv um

and used after free and uh double free are they are related bugs they're not the same bug they're they're they have kind of have a got a similar nature but they are not the same but i still kept kept both of them together because they have got some relation with each other now uh use after free is also known as dangling pointer so if you are reading an article um an old article like 15 years old article or 10 years uh more than 10 years or article you are more likely to see something called dangling pointer back in the days people used to refer use after free as dangling pointer i mean lately or i would say since last

six seven year ten years people have been calling it as the use after free um so it again in case of user appropriate for the first time it was covered in one of the publication back in 1996 and double free uh um the first time a double free issue was reported was back in 2002 um and so again some of these um issues are not exactly two dig at all but pretty much around the same timeline right so again these three issues affects operating system um especially in case of race condition it can affect applications as well uh but i still kept it um in in this section because it's the first time it was reported was more at a

system level not at an application level so what you are seeing in this slide on the right hand side is a table that lists different bug classes the count of the bug classes over the years so this is the screenshot i graphed from the cv details website and this is filtered by bug types so what you are seeing in the top row are different types of bug classes or the bug types and and here on the left-hand side is the year and then the corresponding number of bucks reported each year so the vast i mean all this all these issues or all these counts that you are seeing uh does not necessarily imply that this affects some

applications or some softwares or a single software it basically imply there are many many software's across the world which for which the bugs have been reported and that has contributed to discounts but what you actually also notice what is interesting to see is although these numbers are fluctuated over time but what is interesting to see is we are at 2021 and there is not a single bug we can say has been entirely eliminated we still see some traces of these bugs and although there's some bugs which are less found but there are other bugs which are you know there's a massive count there so which basically means that majority of these bugs have been around for the last

two decades the conclusion here is it it sort of implied that something is not right with the way the industry has dealt with these bugs i mean i would not really question this if these bugs have been around for let's say five years or for 10 years it's sort of understood can take time but 20 years is a very long period to retrospect and ask these questions that why these bugs have not been entirely eradicated why these things are still around so the big question again i just already said that so why do we continue to see one to two decade old security bugs so the reasons um i mean there can be 101 reasons and there are actually many

many reasons why these bugs are around but for the sake of time and with to keep things within the scope of this presentation i have picked the top two reasons that in my opinion are the two most prominent reasons um and it's not just my opinion as i go on explaining these um you know the reasons uh you'll be able to relate and you'll be able to also agree with me that yes those are the the top reasons why these bugs have been around so the two most prominent reasons in my opinion are obscured within the way the vast majority of the organization respond to a bug report of the applications and software that they are

responsible for fixing and they are not responsible fixing i could imagine that this can be a little confusing for you to understand i will expand on these two statement in the following slide so just remember that there are two um statements i'm making her here and i will expand on these two in the following slides so reason number one the reason number one has to do with the flawed approach the industry has taken towards mitigating software risk and which is why we still continue to see many many bugs so a typical approach is a common mitigation strategy of an organization or an independent developer upon receiving a bug report affecting their software that they are responsible

for fixing is you fix exactly what is reported you fix exactly what either you fix exactly what is reported or you fix exactly what is reported including any other instances of the same bug or fix based on bugs risk rating but follow the second approach what this means is you are basically prioritizing a bug uh based on the risk rating you are fixing the high rated issues but you are leaving behind the low rated risk and there are some disadvantages associated with these approaches which i will talk in the which i'll discuss in the next slide so let's start with the first one so you you get a pen testing report or you you get a a report from a bug boundary

hunter or you you your internal team found a issue and whatever is reported you you go and fix that particular issue you didn't care to check any other instances of that issue you didn't care to check any other variant of the issue in the same application you only fix what was reported right so the disadvantage here here is which is very obvious that you are likely to miss other instances and variants of the same bug in the application if they exist now the second approach was approached i mentioned was you fix all the instances and variants of a particular bug in an application but you do not check whether similar bug exists in other applications use support

so again the disadvantage here here is it is good that you fix all instances and variants in one application but if you are managing other application and you didn't care to go and check if those instances could affect other applications then you are likely to miss other instances or variants uh of the same bug in in other applications that you are maintaining the third one was you follow um the approach of fixing based on risk ratings and you fix critical high medium but the low hanging ones never get attention or rarely get attention so the only few companies who make sure that they fix pretty much all bugs regardless of the risk rating but there are many many many

companies which do not fix the lower low hanging issues and what we have seen historically there are evidence that majority of these low hanging issues can be chained together or any trivial looking issues can be chained together with other bugs to perform more practical attacks so if your organization or you are an individual independent developer follows such mitigation strategy you are far from making your application and software resilient for against any uh security bugs so uh so all these all these approaches although you fix some bugs you you you know essentially you are you are still living behind some bugs and at a later stage if you are getting your application pen tested or your application is either illegally uh

sort of attacked or you know and hacker is trying to attack your application find some zero days or you get it through tested through a pen testing company or internal team tester every single year you'll realize that similar issues you keep finding every in every iteration and that happens because you always tend to leave behind if you have been leaving behind instances and variants and you're not checking for those so chances are in every other iterations in future you do any kind of testing those bugs keep surprising back and that contributes towards the global count that that is what every single year you see similar bugs keep coming and every single year the same bug

classes gets its count increment so i did mention two words and i assume some of you must be knowing the difference but just in case there's there are a few who do not know the difference between an instance and a variant um i'll just quickly go over this so an instance is when a functionality in an application let's say a search functionality is used at multiple places in application let's say you are using the same code same functionality same set of arguments but used in different parts of the application that is called an instance of functionality multiple instance of a function functionality example so search for an active users in the store search for active users in a live session or search

for active users in the chat room if you see here i'm saying search for active users so that is probably is the same piece of code and it's just based on session you are using in a different uh areas of the application it's sort of giving you different result and if xss affect any particular instance it imply that it is likely to affect other instances of the same functionality used elsewhere in the application a variant is however is a slightly different implementation or it could be a slightly different modification of the same code that he used so let's say in case of search for active users you are looking for authenticated users you are looking for

unauthenticated user you are looking for you are using a basic filter you are using an advanced filter uh the same search functionality is sort of a modified or it might be accepting some entirely different arguments um in that case it becomes a variant of that functionality so if xss is affecting any particular uh functionality a variant is like you you probably have to go and look at if the similar functionality is used elsewhere with a little modification so is that a different variant that's been used so that's how you need to relate and it's same there's another another another case there can be another variant um but this variant is not same as what i just

mentioned ever this variant is more from the perspective of a bug's root cause so we need to understand how a particular bug exploitation occur or what is the root cause of a bug in case of xss the root cause is lack of sanitization or lack of output escaping so if that is the root cause if there are functionality which is sort of uh receiving inputs from the users and it's not sanitizing it and it is echoing back to the end user in that case that has got a potential to have a cross-site scripting bug in it so a variant could be like for example the search in case of the search the search functionality receives a user

input it sort of sends back to the server and fetch the data and you know echo back to the screen stating that so on so search was used and this is the output and in case of a form summit let's say there's a form waveform you submit some details and you do a submit and it sends back to the sends the data back to the server and it's echoed back without any sanitization in the following screen displaying what you submitted so there is a potential exercise over there and so more from a more from a bug root cause perspective this is a variant so everywhere you see data has been sent to the server and is returned back

without any sanitization that means that this is a this is the case of a variant over there this is a variant of the bug which you need to go and investigate so there are two types of variant i'm referring here and i'll leave the rest for you to read and refer so reason number two so reason number two has to do with the way that industry respond to any vendors or um or any developers software security advisory um for example you see a microsoft report and you don't work for microsoft or use the adobe report and you don't work for any of these companies and the first response is if you are a software developer or you are an

organization you are a tech company if you are not nowhere related to microsoft you are not part of that team your response is that is any any bug report affecting their software your response would be that that's not your problem that's that's microsoft problem or that's uh google's problem or that's adobe's problem it's not your problem because it's not your software which is obvious which is fair response however this is exactly where the problem is um and i will um expand on what it means and why it is a problem so as i mentioned the very typical response so this is a flow chart of how the industry respond to any public security report and i will go over two

different parts and i will expand on why it is a problem when these bug reports are ignored so a typical response when you see a bug report is to check whether um it affects your software if it affects your software then you feel that it's your responsibility to fix your triage it you assess the risk rating you assign a criticality rating if it's a high critical medium you plan for a urgent fix and then you release a advisory and then everyone is happy if it's a low risk then you plan uh your plan based on risk rating and you probably want to you know sort of pop mitigate at a later stage and whenever you release a

advisory you you know you then everyone is happy however as i already mentioned that if you if you realize that that bug which is reported it does not affect your software application then the the obvious response is it's not your problem and you move on and and that is exactly where the problem is so if i have to set up a um sort of a categorize that this path is path a and this path is part b so path a is the most common response to a security bug by majority of the organization while part b may look obvious this is where is hidden one of the significant root causes of why we continue to see common security

bugs that have been around for over one to two decades so before i dive further and explain um you know how in the path b uh is related to uh so many bugs been around for uh so many years uh i'd like to sort of give a little um explanation around what is a bug class and a bug nature because that's the wording that i just came up with to sort of suit the need of this presentation and it is important for you to understand when i'll be using that terminology so a class of a bug which most of you would already be familiar is is described as a way a particular bug is exploited or its

resulting impact for example when you say cross-site scripting cross-site scripting does not imply as you if you are a layman of you if you are hearing process scripting for the first time in its name it does not imply that it has got anything to do with input validation it does not imply it has got anything to do with uh output encoding it it implies as if you know if someone is hearing it for the first time they could sort of make a guess that it is it has got something to do with cross site or scripting right sql injection if you are hearing it for the first time you would um sort of make a wild guess it has it

has got something to do with sql it has got something to do with injection but no way you could uh imply that it has got something to do with dynamic queries or it has got something to do with uh insecure interpretation of the inputs as commands right so the the class names the way the industry has named these class or the types of bugs is the way they are exploited or its resulting impact right so cross-site scripting is the way it is um its resulting impact i would say sql injection is sort of imply the way it is exploited right however the nature of the bug is related to the root cause and this is

what i was referring to that i came up with a term called a bug nature and because i needed to use a term that is more close to the root cause and i couldn't find any other good terms and i think this this term suits the best so a bug nature relates to the root cause of the bug which basically mean that if your crosstalk scripting is the class name the nature of bug is missing sanitization of the tainted inputs which is basically the root cause of the cross-site scripting similarly sql injection is the class name however the nature of the bug is insecure interpretation of tainted inputs as commands so this is again a root cause

of the sql injection and there are some more examples here for you to refer i'm not going to go through each one of these but the slides will be available for you to refer but i'll just give you one example here cross site request forgery um so the way to translate this bug class is first identify the root cause the root cause here is the the cross side request forgery occurs due to lack of server-side mechanism to differentiate between legitimate and uh forged http or https request and at an abstract level you can call it a trust boundary violation right either you can call it whatever this long uh sentence is or you can call it

in as an abstract table so i still try to sort of you know broken down a bug nature as a root cause and bug nature separately so that it get a little shorter explanation or a little shorter definition wherever it's needed right i'll leave the rest for you to read and understand so let's take an example let's take a real world example and try to dissect um from its dissects and sort of decipher its its nature of the bug and and how it affects uh software and how it is related how it can be related to pretty much everyone else um developing software so here is cv 2000 so every time you read cv followed

by a four digit number that four digit number uh basically uh is related to the year it was assigned so cv 2000 means it was a bug found in year 2000 it got assignment of cv number uh in the year 2000. so this bug is basically um is a buffer overflow in the http protocol parser of microsoft network monitor that allows remote attackers to execute arbitrary commands by malform data also known as netmon protocol passing gopal never now if you are a if you are not related to microsoft you are not microsoft developer you are you run your own software development company or you are an independent developer again you you see this advisory you are

not bothered because this is not your product this is not not your worry the only thing you are probably going to be worried about is when microsoft is going to release the path so that you can fix your system right that's the only worry that you're going to have you're not going to be worrying about whether that bug could be affecting your your software so let's do a little root cause analysis and see whether that can affect your software or not right so when you read this um advisory uh a little in detail uh first you identify the bug class which is buffer which is also very much cleared in the first um sentence itself

um and then you try to identify the root cause so if you go and read this advisory on microsoft website you will also find a little more details about uh what what causes this buffer overflow so buffer overflow is the is a result of a particular root cause you know the root cause is exploited and that is why that leads to buffer overflow is not the root cause so when you do a root cause analysis and you can also read here as you read a little you pay attention and read it properly it says buffer overflow in the http protocol parser now i'm reading parser here this is important now for microsoft network monitor allows remote

attackers to execute average recommends via malform data also known as network protocol passing variability so when you're reading passing vulnerability it basically means it has got something to do with the passing that is the root cause so when you go and read the advisor you will find that they have stated buffer upload due to several unchecked buffers in the protocol parser now the exact uh root cause is starting to get exposed right the buffer overflow is not the root cause rather the root cause here is the problem with the parser functionality right so now if you if you have to isolate what is the nature of the bug then it is very clear that it is a

parsing vulnerability and the attack vector here here is the parser functionality so the the functionality that is that is affected is a parser functionality and the nature of the bug is passing vulnerability right this is this is the main reason why i use the word nature of the bug and i came up with that terminology um so again the conclusion here is so as soon as you see um it's a it's a bug that is associated with the password functionality the conclusion here is this bug implies that things can go wrong in a parser right if it lacks any relevant uh security validation during input parsing so now you need to check does your application

or software implement any kind of password functionality if yes then you have to go and thoroughly identify all instances of the parser functionality whether it is passing file whether it's passing protocol whether it's parsing paths you might have implemented image parser you might have implemented xml json parser so you need to go and find all different instances of the parser functionality that you have introduced so and once you find those instances or variants then you get a thorough security testing done you will be surprised how many issues you will find when you do such targeted tests and if you get it tested professionally right and once you find those details once you find those bugs then you need

to uh keep a record of such attack vectors you need to keep make sure that those attack vectors along with what you found um in in terms of bugs you need to keep a record of all of these in a attack vector database and this is the database that you need to create for your own organization right and and this is going to be very very useful in future because every time you do a design application or software design you can always refer back to these database and check what are the uh abuse cases what are the what are the uh you know sort of uh vulnerable functions that you need to pay attention uh and you this can help

you make solid design decisions in future right now i did cover this part this right-hand side part i didn't cover the left-hand side part so the left-hand side path is when you check when you did all this analysis and you can come here and you check that does it affect your application do you implement any similar functionality if the answer is no you still need to keep a record of that because you spend so much time doing analysis and you definitely don't want to get invested because this piece of information is going to be very useful you still need to keep a record of this attack uh vector and this nature of the bug so that in future if you are

implementing or introducing any kind of parcel functionality you have something to refer back you have something to reference test you know check whether anything can go wrong with parts or functionality that will help you make solid design decisions in the future so here are some more examples like uh of different passing vulnerabilities that has been found in the past so this i have sort of a group them as like file passing vulnerabilities the protocol passing vulnerabilities and then path passing polarities right and what what is common in them although the name looks all different and they may all these issues may be affecting all entirely different softwares but what is common in them if you see here this is a

cisco uh bug and this is a microsoft bug this asn is a microsoft bug all this ms ms ms is a microsoft bug but this is a cisco bug but what is common in them is that all of these are passing vulnerabilities and you will find many many many such examples as you go and look through all the tvs and you will find so many common pattern between all these bugs right so all these examples basically imply that any parser can have such security problem regardless whether it's a microsoft parser or it is a parser that you have implemented in your software right so in a way that microsoft report that we just dissected right is related

it is actually indicating it is telling you that hey things can go wrong in a parser if you have implemented a password functionality go and fix it go and fix in advance and you are actually getting a competitive advantage here because you you are getting to know these intel well in advance when you read these external bug reports and you can map that with your application functionality to find similar pattern bugs in your software and you fix them in advance so which basically means that even if later stage someone is testing it or a pen testing company or an attacker hacking trying to break into your software they are at least not going to find something that

is already known they because those are the known bugs that you have already taken care okay so if you want to eliminate all the known cluster bugs in your software the way the industry must respond is this this is again a flowchart i i kind of have covered most of it but i'll still quickly go over it so you you receive a um you know you see a bug report and you check whether it affects your application software already path this slide is something i've already covered i'll cover the path b so the path p should be that instead of simply ignoring that report you check first check whether you know the identify the nature of the bug and i

already explained how to uh you know decipher the nature of the bug and then you check whether uh your application has functionality or process that can be affected by a similar nature bug and if it is affected you know you you definitely need to take action and follow path a if no then yes i mean you are happy you can move on but you you still need to keep a record of um you know all that effort you put in dissecting and identifying the nature of the bug moving on so to summarize the learning so i discussed two main causes what uh what is the reason why we still continue to see a two decade old bug so the first

one i already mentioned that it was the main reason was with the flawed approach towards mitigation so and how it is still contribute to um the count the bug count is because each time you leave behind some bugs during your mitigation um you are not attending either it's a low issue or you didn't care to check the different work bug instances or variants um each time you're leaving behind this issue and every in every future iterations of testing or any attacker trying to find about zero day in your application you are creating that opportunity that the box that should have been taken care of before is actually found at a later stage and that that those bugs are

contributing towards those global count right and now reason number two which is the the learnings are that if you ignore any security bug report you are missing the opportunity to identify potential bugs in your application in advance right so these external reports are actually feeding you with intel and if you are ignoring them chances are the same app your application your software when tested will be found vulnerable to same issues that was already reported earlier in many many many other software and which is the main reason why you see when people find bugs in one software and they use the same information and find in rest of the test other softwares and find the same

bugs so imagine that uh you know if every other company start following you know all these cvs and all these um you know advisories and sort of try to map those um information and identify whether you got a similar functionality without getting tested you try to first identify whether you got a similar functionality and whether those would be vulnerable and then you address that in advance and you go to a pen testing company and say that hey i've taken care of all of these known bugs in the past now i want to get it tested now imagine what your software posture is going to be and when the pen testing company is going to test it

even if you go to the best pen testing company they're going to really struggle with finding any any known box because then they they will be down to actually finding any any kind of unknown box unknown classes right or they even if they find something those are going to be edge cases they're not going to be something that that is very obvious or easy to find so the solution i already discussed part of the solution in the previous slide but essentially what it is some to summarize is you you must make sure that you identify all the bug instances and variants each time you get a bug report a combing operation is very very important this part

it can be a little hard but if i have to run a software company i would go and check every single bug reports that has been that has been reported and documented in the past like all the cvs and all the exploit tvs exploits there are some some softwares which has got bugs for which it may not have a cv but if there could be an exploit for that uh software so do check exploit databases as well because there are many many software's which bugs which do not have a cv so just just following cv uh won't help so you need to check pretty much every single databases that catalog box and exploits and then over time you need to sort of

map these bugs with your functionalities and try to address similar um you know vulnerable functions in your application that will help you in a long run and in a future iterations you will see a decline in um all the known bugs being found so finding unknown or zero-day bugs is is okay but if the same known bugs keep repeating in every iteration then there is something wrong with the way you are mitigating risk attack vector database i already mentioned why it is important and how it is going to help you in making future design decisions so do create your own attack vector database uh don't wait for someone else to create and you're going to use it so you can

start creating it you will have more control over uh what you are doing so these recommendations um will take care of all known bug classes let's just assume that the world is will be a better place and all the known bugs are gone right so in few few years time uh so what about unknown work classes or zero days right which is a good question so tackling zero days or unknown box is it practical right um i get these questions very often in my opinion zero days are a bit overrated the question that one must ask is whether the industry has done enough to minimize the risk of zero does to the extent that it is nearly impossible to

exploit right there's too much talk on zero days you know can just bring down servers zero days can compromise any server there's a big risk on zero days which is fair which is which is uh understood but is it not way too much over hyped is it not way too much overrated because um there's always a solution most of the zero does actually bank on the known bug classes so if you if you take care of all the known bug classes chances are a large part of the zero days are gone already so the the the explanation i gave in the previous slide how you need to map external reports and and sort of sort of drill down to the bug nature and

find out um you know the root cause and and identify the vulnerable uh functionality in your application and fix them in advance that itself is going to take care of majority of your zero days present in your software right so i'll get give some more examples and we'll go over some recommendations so how do we tackle zero days right one one way i already mentioned is to look at leading all the known bugs the other other way is to string the attack option right and there are some learnings from the way the memory corruption bugs have been brought under control in operating system web browsers and voice native apps now i'm not sure how much how many of

you already aware um you know there's a there's a massive decline in um the way memory corruption can be exploited in modern operating system so have you ever wondered why it is getting harder and harder to exploit memory corruption bugs on the modern operating system and web browser or why do we see a decline in successful memory corruption exploit for modern systems compared to web application let's find out how modern operating systems and web browser mitigate uh mitigation approach excels as compared to wave application mitigation so here i've taken a windows example this is again just uh just to clarify this this pretty much um you know is a similar way it works in all other cases uh all other operating

system like linux or mac os but this is this for the sake of one example i've given a windows example here this is a typical stack based exploit building block um in a layman term um it's outside the scope to go through each one of these a technique but i'll i'll give a high level uh idea of what it is so in a layman term in an exploit you will have a trigger which basically is nothing but uh either is causing a crash or simply um causing an exception to uh leverage uh from there on to do something bad right so there must be some kind of trigger that should cause either an exception or a

crash um and then it is always followed by some set of sequence of steps uh in this case in the stack post exploit and this is a very vanilla exploit is there's an indirect jump or a call and then there is something called drop chain knob slid and shell core and the shell code is the final thing where you sort of introduce what you want to get done after you have successfully reached that stage it could be adding a user it could be um you know putting a reversal it could be doing something malicious at that stage so from this stage from triggering of the bug to shell code there are a bunch of steps or techniques i would call

that has to execute to be able to successfully run this exploit now what happened in modern operating system is especially this is an example for windows but a similar mitigations also are there in other other operating systems like linux and mac os so in windows system they have introduced targeted uh mitigation to kill individual techniques so these techniques here like aslr or cfg xfg xfg is uh is the successor of cfg cfg is going to get deprecated so um and and acg or tape or nx these are meant to kill individual attack techniques right individual exploitation techniques so broadly this can be um sort of a categorized as behavioral checks and non-behavioral checks so what it means by a behavioral checks a

check is um a an an analogy will be a dog at your house when it sees a visitor it's not about try to profile the visitor you try to identify whether the visitor is looking suspicious or doing some suspicious action or the visitor is friendly or it is already familiar with the visitor and based on that it does behavioral profiling and based on that it react you don't need to tell the dog what it has to do it has some uh knowledge based on that it sort of profile the behavior of the person entering your house and based on that it react right the reaction is never going to be static it's not going to be doing

one single thing every time every every other time it sees a visitor right depending upon whichever visitor is it's going to behave accordingly that's what is meant by behavioral check and these checks are doing targeted behavioral checks for um some actions in the exploit chain right and the non-behavioral check is of a more of a static thing which is like a security gate where you have either a key or a access card you get in you get out you don't even ask you for the key or access token or access card that you have because you have represented it let you in order let you out right that's a static check so if i have to broadly classify it has got

a behavioral and both non-behavioral checks as well which startup does a defense in depth for um for these kind of expert mitigation and sort of reduce the reduce the exploitation to the extent that it is getting way too hard these days with modern systems that doesn't mean that there's no bypass there are bypasses people are coming up with bypasses but then these operating system vendors are also going back and improving their mitigations and then again killing that bypass right so every time there's a new bypass there's always a update and then that bypass is killed so that's that keep on going so the example provided here again i've already mentioned that it applies not just to windows a similar mitigation

strategy you'll you'll also notice for linux systems and mac os and in the web browsers as well so with the web browsers are no way different from operating system they pretty much have their own sandbox they they pretty much like operating system in itself so they have similar mitigations uh in play when you are dealing with modern web browsers so these are some more examples of windows mitigations because of what they're again as i've already mentioned they're trying to kill all known ear techniques used in an exploit i'll leave it for your reading i'm not going to go through each one of these so however in case of web application there's some limitations so web

application mitigations um have been falling behind when it comes to mitigates when it has to be compared with modern operating system mitigations and the way uh they are heading on um you know killing all the known techniques of the bugs in case of web application what we mostly see is primarily non-behavioral checks which are static checks like input validation it doesn't do any behavioral problem it's just to import validation it's a static check output escaping parameterized queries these are all static checks there's not a single mitigation in web application that can be categorized as a non-behavioral check the only thing only mitigation that i'm aware of which is close to a behavioral check is google recaptcha

um because it has got a machine learning behind it which startup is feeding it uh to to set up a behavior do a behavioral check and based on it it's either block you or you'd stop you do some action but then again it is limited in nature uh it is it is not a comprehensive behavioral solution it's just just an independent solution it's only meant to only prevent automated form submission or a bot uh attack right so um when i was um you know coming up with these slides i did a lot of search to see that whether um my assumption is correct or not and it is correct to an extent that i couldn't find a single evidence at least

till today which is why i'm sort of a highlight in november 2011. i have not found a single evidence of a comprehensive behavioral based mitigation leveraging machine learning for web applications like machine learning in general there are many use use cases in the application but there is no single evidence that sort of talk about behavioral checks using machine learning to mitigate risk right so i've not seen a single one and if anyone knows of it you may want to correct me later so introducing behavioral checks so how do we do it um so before we talk about how to leverage machine learning it's a very vast topic and i it's outside the scope of this presentation i'll in some other

presentation i will cover that but i'll briefly throw some food for thoughts uh if you if you are into software development you can very well implement your own machine learning and start working in that direction i'll give you some put four thoughts here um so before we jump into using machine learning we need to understand what you want to actually uh uh train our machine learning for what it has to tackle so an adversary can only make finite set of moves right there's no nothing like um a hundred hundred thousand moves and adversaries gonna make or a million moves no the adversary only will have a finite set of moves it's most likely going to be less than hundred um

if if you have to even consider let's say even on the higher side let's say if there are some super duper adversary who knows more than everyone else the these number can go to a few more hundreds but it's never going to be that there are infinite ways an adversary can make moves no it's always going to be finite set of moves but technically applications and software can be programmed to analyze infinite moves of an adversary and respond accordingly right so that gives you a competitive advantage over an adversary now integrating machine learning with your critical application impact infrastructure can do such tasks with much ease it's actually getting much more easy easier to do those kind of

emulations and you know sort of identify different possible scenarios so machine learning technology has matured to a stage that any seasoned developer can leverage machine learning technology to integrate with applications and it is no more costly also the the best part is if you use a google cloud or azure or aws they they offer this off the shelf they have their own machine learning going on and you can if you are using their cloud services you can use that apis to sort of implement machine learning in your applications right it's becoming a lot more easier even if you don't use any external cloud provider you have your own on-prem thing and you want to use

machine learning you can still do that because there are so many libraries available to introduce machine learning in your application so now i did you know the same talk i did given wasp global this year but then there's a lot of changes in this talk as compared to the previous one this is a little longer version of the previous one but the the one the thing that i want to highlight here is i did mention about this this concept in wasp as well so other than myself i have not seen any other talk on this topic so chances are this is likely being this concept is likely being discussed for the first time in the world right and again i like

to be um you know i like to be corrected if anyone knows of any evidence uh do message me um at least i have not seen when i was doing search so the goal here is to create a lot of awareness in this space so that you know people start walking in this direction and start implementing behavioral checks for web application because i have not seen a single comprehensive solution for web applications to do behavioral checks and i'm not talking about wave application firewall here that is a totally independent technology i'm talking about anything that you can build into the application right so your application should be self-sufficient to deal with attacks so this is not

something i've i've come across anywhere okay moving on so tackling odes let's again um retrospec and surprise summarize that is it possible is it practical yes to a large extent you you'll never be entirely rid of all this but what you can get rid of is the effect of it right so oda is like you can definitely find a crash on modern operating system let's say you are not able to bypass any of the mitigations your order is useless right you found a crash and you cannot do anything with it even if it's the the very complex attack you came up with a very complex exploit you came up with but if you are not able to do anything

with it then it that oda is useless right so the effort should be to make oday as useless as possible there will always be your days but can you make it useless right and can you get a feedback that all day exploitation occur so that you can take that feedback and again improve your system so the first thing to do is as i already mentioned you need to kill all known bug classes every known bug classes in the history that you are aware of and and i already explained how to do that you need to refer back to cvs exploit database do that dissection uh dissect the bug class into the bug nature and see whether it

maps to your any existing functionality and you need to fix it um you know there and then and once you fix all the instances variants and you have gotten rid of all the known bug classes then you are at a better stage you have already taken care half there right now to take care of any new edge cases or any new orders in future is to introduce machine learning to your applications right and and train machine learning to analyze the legitimate in and out traffic now there's too much emphasis in case of application is what is coming in there's always input validation um there is the sanitizations for many many things the only place you are worrying about output

is output encoding that's the only place um you know when output is given some importance but there's too much emphasis on what is coming into the application as a traffic right now there's nothing no emphasis on what's going out now you can train your machine learning to analyze those traffic you can you can you can find uh good use cases and abuse cases so any deviation from the use case can be detected by machine learning pretty quickly and it can be reported and blocked and can be inspected that why there's a division for example suddenly you are expecting your traffic your outbound traffic has to be always between a gate an upper limit of let's say um

you know one gig right or maybe 100 mb okay and suddenly you see a spike up 500 mb your outbound traffic now is it not something that you should be inspecting now so if that is a deviation like that you if you can train your machine learning to look for all good use cases and any deviation can be immediately blocked and inspected right so that's how you need to improve so continuously training your machine learning with all these cases and misuse cases it can be it can reach a stage where any and not just it server detect any division in traffic it can also report back so you inspect if that is the exploitation of zero days

uh you get to see what that zero day is and you can go back and sort of improve your machine learning or improve your defenses that's the way to go about that being zero days to to an extent that at this particular stage you will meet where that could be zero days but exploiting your system will become so difficult that it becomes nearly impossible that should be the idea so tackling odors is again as i already mentioned is a vast topic and i'll expand over it in some other presentation later in some other conference it might be who knows it might be next year besides delaware however the above states are practical approaches to implement and start

building defenses again against orders this is just a basic diagram of machine learning integrated with applications i'll leave it for you to refer later there are much more advanced thing you can do this is just a very very basic diagram the misconception this is the final thing um the misconception around software security engineering so before i talk about the misconception i'd like to show you um a little bit of timeline or the paradigm shift uh in regards to software security engineering and when people started treating uh some you know introducing software security into the sdlc lifecycle now these are the three main uh or the three most widely used uh methodology uh that is stl waterfall um agile and devops these

are the three most widely used uh development lifecycle used across the world now waterfall was the the first one that was introduced in the year 1985 and security people started talking about security in the year 1988 it was 1988 people started talking about security it came up in the nist guide um that why it is important to introduce security into um into waterfall and in year 2002 and 2004 onwards you know people started you know then following the same foot step they started improving security into the water waterfall model and 2006 microsoft came up with a guide which is which is awesome guide it's a very very comprehensive guide if you have never read it i highly recommend going and

checking it and you'll realize how early and you know during that time people were talking about security in sdlc it's just about you know people have not followed it thoroughly or not taken it seriously in agile agile was introduced in 2001 and people started talking about security from 2005 onward this was the first known uh instance when you know people start talking about security in in agile the same was covered in microsoft 2006 publication as well they covered both waterfall and agile in the same document so that's why i've sort of mentioned the both in both places the same document here devops was introduced this idea of devops came up in 2007 it was introduced in 2009 and

in initial industry adoption happened in 2011 and from 2012 onwards we started seeing in several conference people started talking about dave cyclops and all of that stuff right and it people know you know pretty much every single year in every other conference we hear about dave's check-ups there's there's some talk so what is the misconception now over the last few years there has been significant rise in the popularity of devsecops um no doubt about it however without proper clarity on when to go for dev takeoffs there has been an increasing misconception about it right so these are some of the snippets that i extracted from various online sources um so i'll first read it and then i'll i'll

talk about why there is some misconception here so the first statement reads like devops is better with security and security is better with devops the second statement with devops security gets to be introduced early in the development life cycle and this minimizes risk massively and the third one reads as apps better apps built better why devsec ops is your security team's silver bullet so what is wrong with these statements right so if you if you read the highlighted red ones that is where it's making a wrong sense so devops is better with security fair enough that's a good statement security is better with devops in a way it is implying that if you are on agile or waterfall

security is better with devops you know as opposed to your waterfall or agile right if you have to infer that way now the second statement is security gets to be introduced early in the development cycle size life cycle so why devops it gets to introduce in every other life cycle and i already explained i already show in the previous one that how early you know in in the year like 1998 people started talking about security in sdlc so it's not just devops exclusive to devops it is um it is quite um you know applicable for other other development lifecycle as well so there's no special about devops here so devops devsecops is your security team's silver bullet so

again there's a there's a false sense of assurance over there that if you use devops then security is going to taken care magically right i'll explain why it is not the case so while promoting devsecops is essential but overhyping can be misleading now so without going too much deep into software security engineering i'll talk in a very very basic or layman language right so any software security engineering lifecycle whether you take waterfall whether you take agile whether you take devops they have few things in common that will be a requirement space that will be a design phase there will be a coding phase there'll be a qa phase there's a release base the way these

uh development life cycle are modeled they look different they they they are i would say their circle loop differently waterfall is more of a linear uh pattern uh linear development life cycle agile is more of a iterative life cycle it is more iterations but it includes more of a iteration of the waterfall model devops is automation that bundles agile and also some part of waterfall right so again it's a lot of automation in develop devops it's still a linear cycle but then it's there's a lot of automation that happens in devops right but all of these phases it's all become part of these lifecycles they're these phases does not change so you are still going to write code you

are still going to test a product you are still going to design product you're still going to end you know capture requirements you're going to release your product so no way anyone can say any of these life cycle is independent of these things they have to be they are the core of these life cycle right and when you talk about building security into these phases it basically means this is a common sense alignment of all the security activities that has to be done for each of these days so regardless of where you do or when you do the requirements capture you have to do a requirements review regardless of when you do a design design

documentation you still need to do a design review same thing goes for coding you need to do a coding code review and pen testing is done at a question you don't do a pen testing when you're writing code um release post release you do a bunch of testing right so this thing is applicable for all the uh life cycle it's not very specific to devops devops is more for automation and every every other so is um you know in case of other development life cycle you can pretty much integrate security and they have been done way before devops came into picture right so i wouldn't be surprised if tomorrow people start calling ml or ai ops as a next new thing

and or maybe in next few years some someone come up with a next generation cool software engineering lifecycle name and call it something else and suddenly that everything else looks deprecated everything else looks like older i deal with so many clients and i still see clients with waterfall doing much more insecure better in security as compared to devops so it's it's not about which life cycle it follow it's all about how you implement security that makes a big difference in terms of your outcome so building security into the sdlc is always an explicit process it's not an implicit process it's not going to be you're going to choose devops or any other future ops is going to magically

take care of security no no no or no future ops or any any development lifecycle is going to magically take care of security you have to explicitly introduce security and make sure it's thoroughly done so building secured into software engineering life cycle as i said is always explicit not implicit a fixed set of common sense security activities exist that remains the same across all types of development methodology there is no such silver bullet in software engineering the level of security assurance largely depends on how thorough the security assessment is done at each stage gate and whether the vulnerabilities are mitigated timely now still people want to migrate to devops or devsecops i've given a little

flowchart as a guidance to to decide whether it makes sense for them to go to for devops or not uh is first thing you need to do is is it a business requirement that should be the first question you need to ask if it is a business requirement then you need to check whether uh you know you need to do a little bit of return on investment i mean this can this is just one guide you can you can come up with more ideas um and the return on investment if the return on investment is in favor of your uh the outcome of is in favor of your favor of migrating to devops then you go for it

then you if it's making sense for your business then you go for it however if if the question is is it to ensure better software secure assurance and that is when you need to stop because if you are on agile or you are on waterfall and you are asking this question that i should move to devops because it it is probably going to take care of my security problem magically then you need to stop there because it means that you are probably not doing something right with your existing development life cycle your decision to move can only be justified if it is a business requirement if the business sees value in moving to devops uh it sort of saves money saves

resources or saves whatever you see more money through devops then go for it uh but if it is not giving any of that value and you think someone has told me that doing devops is going to take care of my security magically that's when you need to stop you need to do you need to look at your existing development life cycle and consider implementing security thoroughly so this is just a graphic it's not meant to really offend anyone but rather to create a little bit of awareness it's just showing that hey when you go with the flow why it is important to ask a lot of questions ask your whether when you're moving in the flow you are asking the

right kind of questions or you are taking the right move uh it's it's or you're simply blindly just going with the flow final words so treat all known security uh bugs as a pandemic especially if they have been around for over decades no one wants kobe to uh last for the next 20 years and i have the same feelings about and the same feelings apply to known security bug classes particularly those around this is required for over a decade or two and if you use suggestions made in this presentation to eradicate known bugs from applications and achieve success in eliminating them then spread the word and talk about your success and if your organization success story

on eliminating all known bugs will inspire other organization and potentially it could lead to a global ripple effect and let's reassess the state of known security bugs in uh 20 years from now um hopefully we meet in 20 years from now thanks for listening to this talk

you