33C3 preroll music basically textbooks have been written about it countless talks have been have been Illuminating all of the errors of our ways and still all those sucky software is out there but Fefe over here the hero of our show has put out has put all of these best practices into you know into his work to try to create a secure website he's going to show us how it's done so that we can all sleep way better at night and with that template go back and and secure our own software and so with that I'm going to hand it right over to Fefe give him a round of applause Applause thank you I have to start with an apology because I did submit this talk but it was rejected so the slides are not at the stage where they should be these are our slides for a previous version of the talk it contains all the material and I tried to update it more but that destroyed the flow so we we're stuck with it basically the difference was the the audience so while I expect more developers here the other audience was more and hackers and business people so I try to get them from where they are and the main question usually is "are we there yet?" right so about me you probably seen this before I'm a code auditor by trade I have a small company and companies show us their code and I show them bugs I find in them quite easy but before we start I have a small celebration to do this actually happened just a day before the first time I talked about this so Kaspersky message they found some malware introduced tied to libc which I have written so this is like a Applause some of the malware people know what's good so basically the main question when I talk to customers is we spend so much money on this why isn't it working and the answer is you're doing it wrong so I will try to show now what exactly is wrong and there's a small preface here people usually say there's no time to do this right and that's just wrong you have exactly as much time per day as other people who did great things so you can do great things too you just need to do it so let's play a little warm-up game it's called how it started and how it's going so let's have a demo round IBM Watson is revolutionizing 10 Industries and it's going like this whatever happened to IBM Watson that's a typical pattern in the security industry right so here's another one how it started revolutionize security with AI right we all know where this is going Laugther right so that's the pattern let's play IT security mine sweeper right so everybody here probably knows who Gartner is they publish recommendations and they even have a voting section where people can say this is the best product in this section right so let's look at a few of them and see what happened to people who trusted Gartner first is a firewall right so how it started the number one recommendation is for Fortinet and they have a lot of marketing gibberish Laughter and if you look how it's going it's not going so good so let's extend the pattern a bit why what happened to me in this regard so I don't need a firewall I don't have any ports open that I need blocking right so you don't need this strictly speaking you don't need it next discipline endpoint protection so it started with Trellix this is the number one recommendation on Gartner I hadn't heard of them there like can make a feed joint venture or something who cares they also have great marketing gibberish and then if you look at what happened it's like they made it worse okay so this didn't apply to me either because I don't use snake oil let's see the third one password manager also very popular how it started recommended LastPass you probably know where this is going Laugther yeah they got owned and then people got owned so you may notice a pattern here this didn't apply to me because I deserve a password authentication use public key which has been available for decades right so small bonus the last one 2FA Gartner recommends Duo which has been bought by Cisco but doesn't matter so if you look at what Duo does your server asks the cloud for permission the cloud goes to the telephone telephone shows a popup you click yes and then the cloud tells the server it's okay you can let them in if you look really closely you can notice the cloud doesn't have to do the popup it can just say sure so this comes pre-owned there is no need to hack anything here Laugther and something many people don't realize you don't need two factor if you have public key that's already the second factor Okay, so yeah let's skip over this briefly Splunk is the the recommend option here and they make the organization more resilient unless you install it Laughter Applause okay so this one is dear to my heart because people start arguing about whether to install patches and which patch to install first and it used to be simple you look for problems then you install the patches and then it got a bit more complicated and the result is this right that's a famous podcast in Germany it's about municipality who got owned by ransomware and then had to call the army for help inaudible chatter in crowd and what you should do I'm having this for completeness install all patches immediately but that's a separate talk right so you may notice a pattern here the IT security industry recommends something and if you do it you're [ __ ] so don't do it in case you can't read this says snake repellent granules and then there's a snake sleeping next to it laugther coughing right so if we can't trust the recommendations of the industry what shall we do and so I had a lot of time on my hands because I didn't have to clean up after crappy IT security industry recommendations so what what did I do with my time and I decided I need a Blog some time ago now and I started thinking what do I need and it's actually not that much I could have just shown basically static content a little search function would be good but it's optional um I didn't need comments for legal reasons because people start posting like links to maware or whatever I don't want that I don't need that right so the first version was actually really easy it was a small standard web server and I had the blog entries a static HTML files one file per month it was actually really easy if you want to search you just can ask Google and limit it to my site so posting was also easy had a little script that I could run on the server and I just SSH in and SSH I trust for authentication so there's no new attack surface I have that anyway and this is a great design it's secure it's simple there's low risk it's also high performance but you couldn't do a talk about it at the CCC right so it's too boring so I started to introduce risk in my setup *laughter so the first idea was I had written a small web server I could just implement the blog in the web server because you know it's my code anyway but that has downsides if the the blog is running in the web server then it can access all the memory of the web server in particular it can see the TLS private key and that I don't want people to extract right so it can't be a module in the web server and the the obvious solution is it has to run in a different user ID on on Linux I'm using Linux or but any Unix or Windows would be the same basically it runs in a different user ID and then if you if you take over the process of the blog because there's some bug in it you couldn't access the TLS key and while I did that the industry was doing this chatter that's like the running gag of this talk I show all kinds of interesting things the industry did and then show what I did in that time right so next question where's the content I could just have files on disk like static HTML as before but I think that's not professional enough right so for a good CCC talk you need to be more professional also for a different project I had just written an LDAP server so I decided to reuse it and while I did that the industry did this I took this photo at the airport of Jerusalem so this is an actual ad it's not photoshopped right it's for Northrop Grumman which is a military contractor and it's about full spectrum cyber across all domains chatter so why would I write my own LDAP server mostly because it's small and because I'm an auditor by trade I know that if you want a chance to actually audit the code it needs to be small because that's a limited resource the time you can spend on auditing code right so Postgres is a common SQL database slapped in the the open LDAP implementation of the server and tinyldap is mine and you see it's much slower and much smaller yeah so there was more to this ad campaign I collected a few funny images right so um if someone manages to hack the blog CGI or whatever module I use to to have connect the blog to the web server they can open any file that the blog can read right the UID can read so I should probably do something about that that was the next step and the industry was starting to think about vulnerability management so there is a mechanism on Unix on Linux I did a separate talk about that on the last Congress it's called Seccomp and Seccomp it's like a firewall for sys calls so I can use Seccomp to block open the open sys which is used to open files but if I have to use open myself then I can't block it right so what to do about that for example my blog calls local time which converts Unix's time into the local time zone and for that it opens a file containing the description of the system time zone and that calls open right so if I just disabled the open system call from my blog then it couldn't do the time translation and this is actually an old problem that also applies to set ID programs and has has applied to them for decades so what you can do is you can reorganize your code so before you block or before you drop privileges generally speaking you do the open calls in this in this example and then you disable open and then you look at the the data provided by the attacker because if the attacker or any untrusted source is trying to hack you it is via data it gives you right it's the environment is compromised so you look at what kind of uh elements in the environment are attacker supplied and before you look at a single byte in them you do all the dangerous stuff if you can right so in this case I call local time once before I drop the open sys call and then my libc will cache the time zone data and the next time I call it after I have looked at the attacker supplied code there is no need to call open right so that's a major advantage of Secom over similar Technologies like SELinux where all the prohibitions on sys calls are applied to the whole process so there is this is an example and you should make use of it you should look at your process and you can see if you have the source code at least you can see which parts do I need to do before I can drop privileges and you move them up right so that's what I did this is actually a mockup from the Estonian cyber security center so this is real okay so next thought so let's say someone hacks the blog module and someone else uses the same module but supplies a password right this is a common problem in website in websites there's some kind of login something you get maybe a session token or whatever and if someone manages to take over the middleware or like the server component they can see all other connections too if they are handled by the same process right that's a major problem and you can do something about it so that's the good news here and in my example it led to me using CGI instead of fast CGI which is fast CGI is a newer version of CGI and the idea with fast CGI is that you don't spawn a new process for every request but you have like a Unix domain socket or another socket to a fast CGI process and that opens maybe a threat per request or something but usually in fast CGI you try to handle the requests in the same process and then you can use that process to cach data so there's a perf advantage to using fast CGI but for security reasons I don't I don't use fast CGI so I can't do caching right so that's a major downside and you would expect the block to be really really slow in the end so first thing I need to use CGI instead of fast CGI and secondly you could still use debug APIs so if you use GDB or another debugger to to look at another process they use an API called ptrace but that's a sys call so I can use seccomp to disallow ptrace if I do those two and the attacker takes over a blog process all they can see is the data they supply themselves right that's a major advantage Okay so ENISA is actually an EU agency which I find really disturbing because they're burning lots of taxpayer money anyway so let's assume the attacker can hack my blog they can sill circumvent any access control I do in the blog so for example if I have an admin site or some login site part of the webiste and it's handled through the same program and the access control is done in the blog CGI and someone manages to hack my blog CGI they could just skip that so it's really hard to do access restrictions that can be circumvented if you do them in your own code so the solution is not do it in your own code I don't do any access restriction in the blog I do it in the LDAP server so if you connect to my blog and supply a password then the blog doesn't know if the password is right or not there's an for example there's an interface where you can add new block entries or you can edit an old one and for you need to supply credentials but the block CGI doesn't know if they are right or not it opens the connections to the LDAP server with that credential and then the LDAP server says yes or no so since we removed access to the ptraces calls and the processes are isolated from each other that means there is nothing to circumvent here so if someone hacks my blog the only advantage they get is they can do the exact same stuff they could do before basically they can just talk to the LDAP server okay so I'm starting to get into James Bond territory here right with the attacks they getting more convoluted right so the industry started doing threat intelligence feeds which are useless don't spend money on those okay so let's say the attacker hacked my blog and then went to my tinyldap and now is attacking tinyldap then they can watch other logins because tinyldap handles connections from other instances of the blog too right so the same problem we had before we just moved the goal post a little and we need to prevent this and the obvious solution is to do the same thing we did with the blog we have one process of the LDAP server per request and then we just allow ptrace right so now you can't watch even if you get code execution inside the LDAP server you can't watch what passwords other people use you can still see okay the industry does some [ __ ] again you can still see the password in the LDAP store right so the LDAP server has to have a version of the password to authenticate against and the industry practice best practice is to use salted hashes so the password is not actually in the store still if someone manages to attack tinyldap through the blog they can extract the hashes and try to crack them but since I'm the only one adding users I can control the password complexity so good luck brute forcing that right okay so this is actually a real problem not for my blog specifically but for other web services or services that are reachable from the internet what if an attacker doesn't want to steal my data but it wants to encrypt it so the ransomware what can you do about that and my idea was to make the data store read only so the UB server has a data store that contains all the blog entries and let's read only to the add up process you can only read from it and if you want to write to it for example to add a new entry it gets appended to a second file which I call the journal so SQL databases have a similar concept and they use it to to roll back transactions I can do the same thing it's basically a log file and that means um all the differences from the last time the store was created the Ron store all the differences are sequentially in the log file in the journal so that that the performance gets worse the bigger the journal gets so every now and then I need to combine the readon part and the journal to a new bigger readon part and I do that manually um because tiny elab couldn't do it because I didn't allow tiny elab to write the store right that was part of the security here and uh so um with set comp I can just disable whole CIS calls I can also install filters so I can say open is allowed but only if you use o append o append in the open sis call on Unix means every right you do to this uh descriptor is automatically added to the end so I know if someone manages to to access the tiny Elda binary and can write to my journal then the only place the changes can show up is at the end and that's actually a really good good thing to have because it means if someone hacks me and adds junk to my blog I can only remove at the end and I'm good again compare that to a usual SQL database um if someone wrote to the database you need to in to to play a backup uh in to restore backup because they could have changed anything anywhere right so but tiny adup doesn't even have file system level permissions to change anything in the store so I can re re uh sleep soundly yeah the industry spent money on cyber security mesh architecture right so the journal integration has to be done by me manually out of band so it's not something an automated process does um I do it manually and when I'm doing it um because it's not that much data it's like for a week or two I can just read it again and see if something doesn't look right this may not be available to all other scenarios but uh you have to realize if you have bigger data it's usually not all the data that's big most of it is usually static and readon and then you have some logs that are or you know billing data that grows and grows but usually there's part of the data and this is the the part with the you know um uh identifying information personally identifying information or you know Bill billing details that stuff is usually small and mostly static and you could use this strategy for that too well yeah okay so the attack can still write garbage to my blog that's still not good right but since all they can do is a pen to the journal I can use my text editor open the journal and truncate at some point and then I get all my data back till the point where they started puting the blog right this is still bad but it's it's a very good position to be in if there's an uh emergency because you can basically investigate calmly first you turn off right AIS then you you delete the vandalism and the journal and um you know you haven't lost anything because if you want to delete an entry in the blog you could do that too but that means at the end of the journal you append a statement saying delete this record and I can just remove that and I get the record back right so there's no way for someone vandalizing my blog to U damage any data that was in it before all they can do is a pen junk at the end and I can live with that right this is this is should be the guiding thought between any security you do um if someone hacks you you will be in a very stressful position the boss will be behind you breathing down your neck are We Done Yet is it fixed and you want to have as little to do as possible at that time you want to to move all the stress to before you get hacked because then you have more time okay the industry did other things again um so what if the attacker doesn't write garbage to the journal but writes some exploit to the journal that the next tiny El up instance that reads the journal gets compromised by that is a possibility and that would be bad so agreed that there still a problem but uh realize how Preposterous the scenario is so we are talking about an attacker who found stable zero day in the blog and then used that and another stable zero day in tiny ad up to write to the journal and then have the third uh third zero day to compromise the the journal passing code so I mean yes it is still a problem but we reduced the risk significantly uh and that is what I'm trying to to tell you here uh it's not it's not all or nothing it's good enough if you can half the risk that's already very important and you should do it so as much as you can uh slice off the risk the better the better off you will be if something happens right because the smaller the code is that is still attackable the more you can audit it and be sure it's good you show it to your friends and they can audit it too uh and and you need to save yourself that time because it happens every now and then that I get to get to see the whole code base and the usual code base for commercial products is like gigabytes of source code nobody can read that like I'm I'm good I'm not that good so um this is a good place to be in I think right so the industry was selling dos mitigation sure whatever so what happens if someone attacks the web server that is still a big problem um and it's actually uh it it's a full damage right that's the worst that can happen if someone manages to attack the web server they can see all traffic coming through they can look inside TLS secured connections and they can sniff all the passwords so that's really bad unfortunately there is not too much you can do about that um you could do uh um a separation so this is something people have been talking about for a while open S AG is doing this they moved the dangerous crypto stuff in a second process and use sandboxing to lock down that process uh that could be done but nobody has done it for open SSL yet so so open SSL doesn't support that um my web server also supports embed TLS they don't support that too so I I could spend time on that and I've been actually um spending some time already but it's not it's not ready yet but this would be a good way to reduce the risk and you may notice that the the tools I'm using to reduce risks are actually just a handful there's not it's not you know it's not witchcraft I'm I'm not inventing new ways to look at things I'm doing the same thing again I'm identifying the part of the code that's dangerous and then I think about how I can make that part smaller maybe put it in a different process lock it down so we need to do the same thing with the web server obviously um but it's an ongoing process yeah so again whatever um why haven't I done that yet uh so in my web server you can it's a build time decision if you want SSL support or not and you can see the binary is significantly bigger if you have SSL and I'm showing you this because it means the the bulk of the attack surface is the SSL code it's not my code so if I if I can put the SSL code in a different process they still need to see the the private key because that's what TLS needs the private key otherwise it can't do the crypto so the bug of the attack surface would still have access to the key I can still do it because there might be bucks in my code and not the SSL code but that's just 5% of the of the overall attack surface so um it I will probably do it at some point but it's I don't expect miracles from it bugs and open SSL will kill kill me there's not much I can do about that okay so I know what you're thinking what about colel bugs so I looked at a few of the recent kernel bugs and it turns out that they usually apply to SSS that are rarely used in regular programs and uh because I'm blocking all the CIS calls I don't really need none of them apply to me right and this is a this is a pattern with Colonel bugs um uh there is a a project called Sandstorm um that also uses p trce and and Secom tracing to reduce the csol U surface and then puts regular Services into a Sandbox for for web services and they uh evaded all kinds of of Kernel bucks just because of that so this is like a zero effort thing because obviously if you have a list of CIS calls you'd use a white list and you you have a list of things you are explicitely low and the rest is is disabled not the other way around right so none of the usual kernel bugs apply to me um because of the the seom stuff I already do so kernel bugs aren't as big of a problem as you might think at least I still have them if I haven't patched but you can't get to them via the blog so I have a small confession to make uh I'm a bit of a troll and that applies to this project as well so um I use the worst programming language I used C right so I'm trolling the security people and then I'm trolling the Java people who have been saying you should use multi-threading for performance and not have one process per request so I'm doing actually two fork and xx per request um I'm trolling the database people I don't have any caching I don't have connection pool TOs and the perf people too because I'm still faster than most of the regular Solutions so there is no there's really no downside if you if you architect your software to use this kind of thing um it will be slower than other ways to do it but most other software isn't as fast anyway so there's enough Headway that you can use to do security instead of performance you will still be faster so let's recap the the methodology I used um first I make a list of all the attacks I can think of and this means concrete attacks so what could happen and what would what would be the problem then right and then I think for every item on the list I consider how to prevent this can I prevent this uh what what I need to do and then I do it right so that's easy it's like this the fine man problem solving algorithm in spirit and this process is called threat modeling it's it's like a it's dirty word because it sounds like there's effort involved and nobody wants to do it but it's really it's easy it's just these these steps you you look at your software you consider all the ways it could be attacked and then you consider what you could do to prevent the attack or in some cases you can't prevent the attack and then you say well that's the risk I have to live with right so that's called threat moding you should try it it's awesome and um you saw that I'm trying to optimize something here I go for a specific Target in this case I want as little code as possible um the more code there is the more bugs there will be that's an a very old uh Insight from I think it was originally in IBM study and they basically found that the number of bugs in code is a function of the lines of code in the code so there's a little more to it but basically it's true so and it's not just any code I want to have less of um if the code is dangerous I particularly want to have less of it and the the most important category to to make smaller is the the code that enforces security guarantees so like one security guarantee would be you can't log in if you don't have the right password right so the code that checks that I wanted to be as small as possible um one or two lines of code if if I can manage it and then it's obvious if it if it's wrong or not the more complex the code is the less less easy would it be to see if it's correct or not and that's what you want in the end you want to be sure the code is correct so how far did I get it's actually pretty amazing I think um you can write an elabs server in five ,000 lines of code the blog is 3.5 lines of kilo lines of code um plus the Ed client Library plus zet lip um but I'm only using zet lip to compress not to decompress so most attack scenarios doesn't don't apply to to my usage of Z Li um and the web server is also pretty slow if you only look at the HTTP code unfortunately uh it also contains the SSL Library which is orders of magnitude more than my code and that's how you want it you want the biggest risk not to be in the new code but in an old code that someone else already audited if you can manage it right so this is the optimization strategy try to have as little dangerous code as possible sounds like a no-brainer but if you look at modern software development you will find out they do the exact opposite pull in as many Frameworks as as they can so this strategy is called TCB minimization you should try it and I gave a talk about it already it's actually pretty easy so um I told you what I did to the to the blog to uh uh diminish the danger that can be done uh if someone manages to take it over and this is actually part of the TCB minimization process so the blog was a high risk area and then I took away Privileges and removed exess checks and in the end even if I give you remote code execution in the blog process you can't do anything you couldn't do before right so it's no longer part of the TCB the TCB is the part that uh enforces security guarantees which the block CGI doesn't anymore so that's what you want to do you want to end up in the smallest TCB you can possibly manage and uh every step on the way is good so no step is too small right if you can shave off even a little routine do it this is the minimization part of TCB minimization right I could I was able to remove the block from the TCB tiny El up still still has a risk so I I you saw the threat model if someone manages to take over tiny El up they can read the hashes and try to crack them that's still bad um but I can live with it right uh if they vandalize the block I can undo the damage without going to the tape Library so that's good if you compare that to the industry standard you you will find that my Approach is much better um usually in the industry you see platform decisions done by management not by the techies and um it's untroubled by expertise or risk analysis and you you get a diffusion of responsibility because if you even if you try to find out who's responsible for anything you find uh well it's that team over there but we don't really know and then you find out the team dissolved last week and it's really horrible and brand new we have ai tools which is also a diffusion of responsibility and then you get people arguing well it's so bad it can't get any worse let's go to the cloud where obviously it gets worse immediately so I prefer my way um I think in the end it's important to realize that the the lack of security you may have in your projects right now is self-imposed there is no guy with a shotgun behind you threatening you can do it you just have to start right so this is self-imposed helplessness you can actually help yourself you just have to start right how did we get here this is obviously not a good good place to be like all the software is crappy and there's a few it's not just that people are dumb there's a few reasons for that so um back in the day you used to have bespoke applications that were written for a specific purpose and they used the waterfall model and you had the requirements specification and it was lots of bureaucracy and really horrible but it also Al meant that you knew what the application had be had to be able to do so that means you can make sure anything else is forbidden if you know what the application needs to be able to do you can make sure it doesn't do any other stuff and that is security if you think about it deny everything that the application wasn't supposed to be doing and then that's what an attacker would do if they take over the machine right so if you know beforehand what you're trying to get to you can actually implement privilege even architecturally as I've shown you now we have more of an Ikea model you buy parts that are uh designed by their own teams and the teams designing the parts don't know what the final product will look like right in in some cases even you don't know what the final product will look like but it's even worse if you consider that the the the team building the part you make your software from doesn't know what it will be used for so it has to be as generic as possible Right the more it can be done with with it the better and that's the opposite of security right security means understanding what you need to do and then disallowing the rest and this means be as generic as you can the parts are optimized for genericity Gen what's the name genericism I don't know so they are optimized to be as flexible as possible and they are chosen by flexibility the developer of the part usually has no idea what it would used for uh and that means you can't do least privilege because um you don't know what the privilege will be that's least so this this is actually a big mess so if you use Parts programmed by other people you will have to invest extra effort to find out what kind of stuff you can make it not do because it will definitely be able to do more than you need and the more you can clamp down the more security you will have uh it's even worse if you do Agile development because then by definition you don't know what the end result will be so if you don't know that you can't do security lockdown so another argument why we got here is economics of scale so it used to be that if you build some kind of device that needs to do something like I don't know uh a microwave then you you find parts and you combine the parts and you solder them together and then they solve the problem but these days uh you don't solder parts anymore you assemble from pre-made parts and these are usually programmable right so a little arm chip cost like a tenth of a scent so why use a special part if you can use an arm chip and then program it but that means you still need to use software that actually solves the problem the hardware is generic and that means the hardware can be hacked and this is turning out to be a problem right if you had a break in in 20 years youo um it it breaked right but now it's programmable and people have realized how bad that is but it is bad right so that's that will bite Us in the ass oops so um the response from the industry has so far been the ostrich method basically we we install stuff that we know is untrustworthy and so we install other stuff on top of it that's also untrustworthy and then we call it Telemetry or big data and to some risk uh logging analysis in in aze or whatever uh and in the end the attack surface has mushroomed like a nuclear explosion right so that's our fault nobody has forced us to do this you don't need to do this in your own projects that's the hopeful message of this talk in conclusion if you remember nothing else from this talk remember that threat modeling is a thing and you should try it TCB minimization actually helps least privilege is another facet of the same thing and if you can uh use a pendon data storage you should consider it hm blockchain yeah not blockchain a pend only data storage it's not [Applause] [Music] blockchain so two more you two more slides yeah two more slides sorry I'm an imposter no problem so the rule of thumb should be if if the blog of some unwashed hobbyist from the Internet is more secure than your it security then you should improve your it security right that shouldn't happen all right so that's all from my talk I think we still have time for questions do we yes okay awesome okay now you can put your hand [Applause] together so if you want to ask a question we have four microphones in the room 1 2 3 4 and I'm going to take a a question the first first question from the internet the internet is saying you actually got hacked or can you elaborate on what happened Yes actually there was an incident where someone was able to post stuff to my blog and because I had a pend only data storage I Shrugged it off basically so use use a pendon data storage it's it will save your ass at some point the problem was a bug in my uh Access Control lists I had used some some Access Control list in my alab server and I had a line in it that I should have removed but I forgot to remove it and that meant you could post without having credentials but um it happened and it wasn't bad because my architecture prevented damage um as people are leaving the room could you leave very quietly thank you um microphone number one yeah is there a second alternative for Windows and Mac OS a secure alternative well so basically you can do the the principles I um I showed in this talk you can do on those two so usually you will not be hacked because your your Mac OS or Windows had a bug I that happens too but the bigger problem is that the software you wrote had a bug or that you the software that you use had a bug so I'm I'm trying to tell you Linux isn't uh particularly more secure than Windows it's just it's basically you can write secure software and insecure software on any operating system you should still use Linux because it has advantages but if you apply these Tech techniques to your software it will be secure on on Mac OS and windows as well right so this is not for for end users selecting the software if you select software you have to trust the vendor there's no way around that but if you write your own software then you can reduce the risk to a point where you can live with it and sleep soundly sure is there a a technical alternative or similar similarity like sa comp for Windows and Mac OS so can you drop your privileges after you have opened a file for example uh uh so for meos I'm not sure but I know that that free BSD net BSD and open BSD have an an equivalent thing I think uh Macos has it too but I'm I'm not sure about that for Windows there's are sandboxing methods you can look at the Chrome source code for example they have a Sandbox it's open source you can use that to do this kind of thing okay thanks so microphone number two except down that's gone so microphone number three in that case this is four I sorry four four yes um will your next talk be about writing software secure software in Windows and if no uh how much assets would you request to compensate for all the pain no it's not a question of money okay uh microphone one um have you tried removing unnecessary features from open SSL uh Yes actually I've I've done this pretty pretty early but it's still it's still much bigger than my code so um for example op SSL has support for UDP based TLs but there's a lot of shared cyers in there you can remove ciphers you don't need and and that helps a bit but it's still it's the biggest part of the web server by far I think there was an internet question was there no doesn't look like yes no yes no no yes okay uh then microphone four as someone who is uh connected or was connected to an industry which has programming programmable brakes um what is your opinion about things like mizra well well so there are standards in the automotive industry for example like misra to make sure you write better code and it's mostly compliance so they give you rules like um you shouldn't use recursion in your code for example and the functions should would be this big at at most and this is more I mean it will probably help a bit but it's much better to to invest in in good architecture but you may have noticed I I've said I wrote the code in C and I said nothing about what I did to make sure it's it's good code so that's that's a different dimension that's orthogonal right so follow those standards it will it will make your code a bit better probably um but it won't solve all the problems and I think personally you should do both you should make sure or try to make sure that there's as little bugs as possible in your code there's ways to do that I had to talk about that too but after you do that you should still have these kind of architectural guide guard rails that keep you on track even if someone manages to take over the process so now I think there was an internet question yes uh the internet is asking how would it work to like scale This truly impressive security architecture up for more use cases and more like larger theme or would the theme size and the feature keep ruin it yes so oh no oh [Laughter] no well I'm sorry [Music] la