Industry secrets for security engineers

everyone have been doing the event so far my name's Campbell worried and I'm talking to you briefly about security engineering secrets but I'll let you into the secret from the start is that move this is actually secret security engineering principles are well documented as an STL see there are books this fake written about it what I'm gonna convey to you today I work a lot in training there are a security engineering the consulting with organizations post pen testing or post them having been destined by another organization or red team and I'm familiar with examining their processes and looking at their techniques and models and there's a common couple of issues that are always prevalent in

majority of organizations SDLC processes so we're going to cover those today and show you how to do them properly but show you how to be one of them properly first thing we're gonna talk about is threaten one you know certain ones a term that many people be familiar with not all of you have done it as such but suffice to say it's pretty prevalent around the engineering world there are lots of different ways of doing threat models lots of different models I'm going to be looking at today's stride this one's pretty prevalent it's based on Microsoft's Roman system which you can get a free software download for that from Microsoft which takes you through the process as well assist you

with it pretty good or do you recommend it there are about 12 kind of long lines throughout modern methodologies out there tower being quite a popular one we see that a lot in automotive and manufacturing companies using tower past there's another popular one as well but there's about twice as fast not safe there alone so take a look have a read through what we find about each one of them is that they're simply acronyms they describe the steps in the process so terrorist threat assessment remediation analysis and perform those operations in that order so we take a look at straight most people should have seeing this as said it's an acronym stands for spoofing tampering

repudiation which I'll talk about in a moment information disclosure denial of service innovation privilege now I want to clarify repudiation because it's terminal if I know many people are actually that familiar with what it means it really should take non-repudiation but STN I wouldn't have the same ring of strikes I think that's why they said repudiation and non-repudiation this concept of every action cannot be repudiated in that it's locked it's recorded I can't love on to a system and say I didn't if I can then I have a non repudiation issue so that's one things that we look at in this threat model the steps that we take while we run through our stride platform are to identify

threats you need to rate the threats and there are lots of different ways of doing that I wish I had more time to go into risk racing for you today simply don't and mitigating the threats and there are different steps within all of those we identify threats we can use strike to classify the threats as well into the strike platform racing the threats is quite complicated cbss is prevalent but one of the things that we do find is an issue is the application of racing the risk in a consistent way and if you have a large team you may not all be working the same park system and you get one person's from one building

running the CDSs scoring system slightly differently to somebody else you end up with different gates and a bit of a mess so that's something else needs to be aware of that's a secret for you so we do a throne and we are at he was thrown model this thought because we can ease from modeling and everything doesn't have to be my team's and have to be information security everything that we look at any kind of access control and it's gonna perform a function being physical or I see can be threatened then we go to a threat model list or so for a start we have to define first of all we need to understand what is the purpose

of the door and it's clearly an access control is so either let people in let them out will keep people in will keep people out and that's the function that's really everything that that dog can provide for us so I look at it from that context of what its function is do we have spoofing vulnerability well we do because in framework that we see there in the context of that access control it is just the door now there's nothing stopping me from putting on a company t-shirt high-vis jacket or clipboard whatever going in there sending to be somebody's illegitimate access there are no empty spoofing controls so that's one part a thermal tempering I'm gonna roll letting

the denial of service in this example soon because temperate zone of service are two different things but because there's access control is quite simple as we said it keeps you in or keeps you out doesn't really do a lot else we're going to put those two together not repudiation well there's clearly an issue here because there's nothing recording me coming in or out the door if I put on gloves so I don't leave fingerprints on the door handle you can't prove in the current model whether I went through that door or not so we have a repudiation we have a clear information that's close to initiate the windows I can see through them it's probably a pretty thin door here

conversations behind the door I can get close enough to it so we have a clear information disclosure mission can either service this have wrong limit temperent I mean we could look at it this tampering as being we could change the locks so that you don't have the keys that's a potential tampering issue but I would also be an amount of service issue in this instance us why we're bonding living together now to deny service to remove the functions at this door actually provides I could put wood wedges under the sill to stop from opening I can wrap chain around the handles and padlock it but there's plenty of things I could do to stop that

door from working so we have actually turn on a service and I like this example because when we talk about elevation privilege we doesn't really have any elevation privilege issues and this is an important take away from any kind of threat modeling exercise regardless of what methodology you're going to be using not every step is always going to apply but we record it we keep it as part of our threat model and we need to record these and this is another thing that I see not done properly when the threat modeling comes up in the SDLC building runs through the threat models write notes down on the back of piece of paper down there I can

fix those things we'll put those positions in place whereas we really need to formalize it then we need to record it so we can view our risk over time and we can use some example this is a very simple table for recording our threat model that we've just done so the component is the door we've got our stride methodology left threat mitigation whether the mitigation has been implemented and whether it's actually been recorded and heaps these historically because women go back systems change and complex systems change all the time you apply patches something's changed you need to go back and do that risk assessment threat modeling again and we need to see what by changing your system effector

hasn't had against our previous ephemeral so you can really understand our risks of granularly so recording things and keeping these in an orderly fashion is something again which I don't often see in the majority of organizations so another takeaway from fragment one again prevalent problem the exercise must be done for every component and it needs to be regularly updated so when we starting for a modeling is easy when we're looking at mitigation so go it's okay we will put CCTV on the door that'll stop some of our issues but we're going to secure its gotta be led batches that electronic locks ypu in and is easy to expand your threat model and so what about the ID backers for

something new system what if somebody intercepts or fabricate CCTV we've lost a lot of our threat model and I see this all the time need to keep a threat mom down on component so if we have a typical very very simple DMZ firewall some kind of service application API website whatever had a date space on the back end move stuff from them is very easy for us to lose track and encompass all of the components but a top tip if you're doing threat modeling is just focus on one component do that threat model before moving on to the next and when you've completed those focused threat models and you've recorded them then you can put them but

you need to gain that granular information each component you can also think of it as where data flows so it might be a cluster of components but your threat modeling the security of the data in transit problem you can threat more than that and use a cluster but that means to be an individual scramble like I say that's a prevalent problem one let me see people to do incorrectly all the time the threat modeling is a very powerful tool when done properly and if you choose a threat model that's appropriate for your risk and for your organizational culture that works well with your deaf teens and your security teams then you do tend to stick

with one and that again is also an issue that we see that there's no reason why you can't use more than one thread more type of more than one methodology there's no reason for you can use stride and then go back and revisit things and run through tarah or octave absolutely no reason at all and keep those foraminal separate you can interact no mutant with cross reference against them and in doing so doing this exercise it's quite time-consuming not going to line I think that's why people do just kind of like skip on and go that's get this done let's look at the whole thing the threat model system as one entity rather than focusing down on components is because

it's quite laborious however with discipline and with a good sdlc which we'll talk about next a threat modeling is very very powerful tool and SDLC we're going to talk about for a few minutes now now I teach a course on SDLC and security engineering and it's four days long but I have less than ten minutes to talk to you about it now so we're really gonna fly through it really quickly but the purpose of the SDLC is to give a rigid milestone approach to your development so components like threat movement are a part of the process and following the sdlc rigidly and hitting those milestones and completing those actions correctly and thoroughly is the keystone to making

this TLC work it truly is what is it I mean it's a formalized process the idea is to get bugs and design issues in your code your architecture whatever it is you're building again just like we threat model the dog there's no reason I can't have miss TLC around anything else if you're doing what we can project home doing some DIY or maybe fixing the car you know restoring a motorcycle whatever you're doing you can design an stl see around that activity and following that removes the the danger the are inherent procrastination to just skip parts I'll just do it like this because I'm hungry nor my lunch if you follow the SDLC is hard to go wrong not going to be perfect

because we know that but it improves and there have been studies done on how much extra effort is required to just go as just build the thing as to let's design a nesting LC and build a thing to the sdlc and studies indicate x1 11% more effort which when you actually know he looks like a little effort lentil elapsed time and a resource that goes into making using - TLC - producing better well-documented product at the end is only 11 percent water to 111 percent of just doing living so it's a marginal increase in effort to create better products all run through CLC quickly now there's no real rules are in this DLC I've seen lots of different

ones I've seen five stage ones very common I work with a company have a 17 stage s TLC which was really complete and they were very very good they stuck with it rigidly well take a look at commonalities between all s DLCs really session all SCS fees should cover these basic points or at least touch on these subjects so there are many informal methods there are some great books out there about software development lifecycle a lot of companies and say they've developed their own they might be using formalized method but they might be tweaked it to see themselves event that's very common nothing wrong with that so but all SCLC should cover these basic subjects which is training

first make sure everybody's got the same level of training and that they have the core competencies designing the requirements we all do that that's pretty straightforward but formalizing that stages is key to to developing numerous TLC your design requirements not just how many users does this need to satisfy your requirements for your design requirements around how does data flow what are the user stories and having awareness of those so we can build them into our models as well how we're going to implement it what we do when we release it and something that's often missed out is how do you respond to an incident and whilst I've seen the response piece in formalized SCLC's organizations that tends to be the

partner picture that's the least well-developed because once it goes down at their pinions prot it becomes a security teams problem right but the devs are gonna have to respond at some point if a bug is found it's not the security team are gonna go and refactor the code right it's the dev team we're gonna have to do that it's a response plan around we miss something how do we deal with that is often there but not very well developed but it's probably one of the most important pieces now this isn't a CL see example that I've seen in several organizations it's not quite the seventeen step one but it's getting there so as we said before establish the

core training now this is crucial when this might be learning threat model one of the core bits of training has to do is how to rate the risk if you're using CB SS make sure everybody's using and applying it in the same way as otherwise if something's not doing it properly they might rate risk too low or too high and that could put a stopper in your development process if the risk is rated to nine you might be spending unnecessary effort trying to fix that if it's rated too low it's below but ganked and then you might put a vulnerability into your code without realizing it so that core training is absolutely essential establish the security

requirements of course you know what is it you're protecting is that personally identifiable information which actually have a higher security requirement see I've got a database of pictures of cats whatever you're building you know you have to look at the data and say what is it how much protection do I need and what are the issues here and what about reputation wishes they might not be personally identifiable information but what happens if my website my API my hack whatever I'm building like it's compromised and I'm rinsed publicly humiliated and I have a reputation damages you have to think those things through creating the green gates is where do you stop what is important enough to make you stop and they're back

in your sto C and that's an organizational it's fed by your security requirements all of these do follow logically not all organizations will do the same order but there is a logical progression to it performing risk assessments that's been outside of the sdlc that is a security function and so that's where that team's work with security teams to took funds and risk assessments and other design requirements we spoke about those already attack surface reduction once you've got a rough idea of what our apps and look like having applied the principle of least privilege have you actually reduced having do you need that login do you need that user functionality and then once were threatened the rest of them on the

right-hand side might slightly want me listener the tall this is very important agreeing tools there are issues that become inherent in any development if somebody's using Mac with Visual Studio and somebody else is using Linux with some other IDE you've got different code standards it might work but it's much better as much easier to clean up and fix a project if everybody's using the same tools and you've recorded what those tubes are including versions deprecated unsafe functions is a secondary SDLC process if you're coming to update an application you can look at it look at the Bill of Materials which you will have because you've threatened little bit and you'll know everything that's in your application you look and

say about SSL library are any vulnerabilities with that that have become known since we released this up if there are get rid of it updates or get rid of it the rest of its kind of active ongoing doing your own security reviews dynamic and static analysis of your source code fuzzing is something I often don't see in development models because it's not well understood quite often and people don't realize the value of it but it is an important part is basically whether people groupies I don't know I always recommend it but you know not everybody sees about a minute reviewing the attack surface all the time and again number 13 ear is that release piece that's the incident

response plan and also the archive so the archives needs a response plan cookie in the SDR C and in the security process in general just because if you have a checks on dark-eyed bottom code if somebody out there Hackel and releases on a relative says oh you know this code is vulnerable how do you know that they haven't tampered with your coat that they haven't reverse engineered it changed it recompiled it and then said that codes one rule the only way you can prove that if you have eight let's grab all kinds of your original code and then you can say that's not our code and you can't do that if you haven't followed through

with your incident response plan the final review in the archive so key takeaways but get some bass having the methodology for rating is absolutely crucial as I say racing cbss I do it I'm a penetration tester Red Team I do it all the time and even between two experienced pen testers they're going to argue about CSS school should be so this is why evening development crucially have a standardized methodology for doing that score that's a real big takeaway and of course I can't underline another what is it often frequently forgotten about our boys instant response plans and code comment so fossil more secrets of SDLC I hope what I've given to you today is a bit of

insight into some of the common problems I see as a consultant around both code reviewing and also working with organizations and training them I've been in too many large well-known organizations and sat with dev teams for three to five days and gone through their processes and taught them how to do code analysis yeah looking at that code and showing them where they've got some know where they could improve but the incident response plan code archives are often missed out and they aren't very very important parts so that's a very quick takedown on an absolutely enormous subjects it's quite contentious I'm sure lots of people say no we do all of that and lots people go yeah that was

interesting but I hope it was interesting great to talk to you and enjoy the rest of the day thank you very much oh I've got here is a reading list for you before I go if you do want to read more about security engineering these three books here are excellent and highly recommended so as particularly security engineering by Ross Anderson so on that note I will say thank you very much