 So first of all we have a brief intro of some pre-plastic concepts I'm going to be talking about. Both of technical and some of our privacy project is organized. And I'm going to talk about how privacy has a project and security. And then how normal users can keep their privacy systems out of date with regards to security patterns. Finally, there's time. I'm going to talk about some case studies about specific security incidents, the privacy security example. So first, in the privacy life, there will be a difference between the base system, which is the main operating system with the kernel and a bunch of useful tools, which includes compiler, gel, but also some network of demons like sent mail combined. So most specifically, once in the base system, well, that's up to somebody else, but once things are in the base system, it becomes something for the privacy security behind it. The privacy release model is that there's always a current branch called the health development. That's not supported at all by the security team because that's so much the flux of this. We generally think that count on people running current to update often and to know what they're doing and being able to find out themselves with their affected by security issues. Generally, when we fix other, the privacy version of the current is also fixed but it's not always with the current team. Then we have the stable branch or branches, which is where the development goes in after it's been in the head branch for a while. All the stable branches once they are marked as stable by the privacy release team and then supported security-wise with regards to by the privacy security team. Finally, when the release is made from the stable branches, we have what's called a release branch. Basically, the state of the privacy base system, which was exactly when the release was made and then critical security fixes are applied to this and only critical fixes. We also, in part, when the security fixes are now, we also have a serious bugs they also work in. But generally, we're very conservative about what we're allowing to the release branch because it should be safe for administrators to upgrade their production system to the latest version of release branch as the version was called, without risking regressions or anything, regressions. Of course, we cannot always guarantee this but we try very hard to make sure that we don't break anything that wasn't broken before. Then for all the programs, which are not part of the basis, we have the possibilities. Due to the amount of programs and the possibility to sample differently, I'll talk more about that later. But basically, the possibility is every kind of magical and unmanifold software that can be low cost free release. Finally, we have the term for free release developers or committers. These are the developers who have direct access to the free release resource repository and can make changes directly to the tree. The committers are not the people they're selling or working on. They are the people who will commit things in and will basically, when a change within, be responsible for this change works. So generally, the committers with access are supposed to have regular access. The political organization of free release project is called Team which is elected. They are elected by the committers and they are basically the ones that, if there are conflicts that cannot be resolved by the committers themselves, we call Team are the ones that are also to be to go in and say, well, first they try to resolve, but they are the ones that may finally say, hey, we are going to do this. There are also some other team put out to mention them as needed later. So, we have decided to organize security handling. There is one person responsible for that free release security officer. He is a currently coding personal. The way it works is that the security officer, when he is in theory, if he wants to have a position in the law, generally nominates a new person to take over. This person then nominated to the call team, the call team who has the approval to say, okay, we will allow this person to be the security officer. Because the security officer's function will basically have dedicated some of the authority by the call team going to the exact instance a bit later. Basically, the security officer is the one that has final say in security matters. And of course, the security officer is responsible to call to the call team. So, in theory, a security officer could be replaced if the security officer does something different than the security officer, but that hasn't happened, so I'm not expecting that. So, even if we have one security officer, that's way too much work for one person to do. So, we have a hierarchy project where supporting the free release security officer and we have what's called security officer team. Basically, the security officer team which also includes the security officer are the ones who are able to send out the security advisers and were able to actually approve, commit to the release branches mentioned before. Basically, the authority to do all the things are dedicated to the security officer and the security officer, then dedicated to the responsible responsibilities on to other people. So, this is not that... There's no big document saying the security officer's team, the security team are not doing exactly this and this. It's generally handled by common sense and if somebody does something they shouldn't first of all be responsible to the free release security officer. But generally, people who are... Well, the end is probably not... People who help out know what's okay and what's not and know when to ask, when they end up, if they are allowed to override some normal procedure in the free release department. Yeah, then supporting the security officer and security officer team who have the security team which is in the context where most of the work, the security work of the project is done. When for almost all the security agencies providing the basis to make it, they will be dealt with in the security team. So, even though we have wonderful, wonderful, we have... The way they normally work, if somebody says, okay, I'll handle this particular issue and then the rest of the security team helps out as needed. Or more often, somebody needs to help people and say, couldn't you do this? We need to have this issue dealt with. Of course, it's how much running is needed that's very much varies about this serious issue. We are basically dealing with some very serious issues we get dealt with right away. We have some issues we got while they're not that serious, so they'll take a bit longer and more running to get. So, currently, the security officer team is just me, Samuel, and Robert Watson. Normally, the old security officer is also part of this team if he has time. A few months ago, the old security officer Shaq didn't step down because he simply didn't have time about it anymore. Then for the security team, we have, as I said, Marcus, Renko, George, Philip, Gryshin, and Dagenin, who help out in various areas. The authorities basically, the old security officer suggests a new one, and the call team approved this new one. Normally, this process of approving the new one, the security officer in the past has been sitting in a couple of years, and this happens very often. But generally, the new security officer suggested by the old one is the one that's appointed. Then, while technically, the document describing the authority of the security officer, which I'll show some parts of it, says that the security officer vets the security officer's security. In practice, the way it works is when the security changes, the security officer, while the old security officer, when we have three partners, the security team and the old security officer team just keeps on working. But whenever people, more people are needed to help out, while having, by generally, that the security officer sends out emails to their own windows list asking, well, we need more help. Who's interested in helping out? And then it's five minutes up to the security officer's side, who will we actually trust with the responsibilities? Because all members of the security team will be dealing with confidential information. We'll be giving information about security officers half-time before they are published. So you need to know to be able to trust these people, so don't go need this information to other people. I don't think this is a problem that anybody has intentionally needed information, but it could happen in theory, but the security team members are on the committees. They are generally considered trusted already, so hopefully it's going to be a problem. So to decide which authority to formalize the authority on the security officer, there's a challenge that we have to take an important point of view. Basically, the most important part of the security officer and thereby the entire security team is to keep the previously used form of security issues. This is done for the basis of security advisers and also for the population who we call the UX model. The next part is that the security officer and team are acting as the point of contact for all external organizations which deal with security. The main ones here are, for instance, the U.S. CERT security which responds to team and the similar teams around the world. Basically, one of these teams has green notifications that's not having about some upcoming security problem. Security problem is there, it's just not now yet. We'll contact the security officer who will then decide how three business projects are going to deal with this. Finally, the responsibility of the security officer and team to monitor all the public challenges of the reports of security vulnerability against the free business team. This last one can be quite a lot of work but I'll talk about this more. Yeah, we have the entire challenge with security work. How does the free business security team actually deal with a specific incident? Of course, the first thing that happens is we have to find out about how this issue exists and talk about minutes about how we find out about these issues. But the very first thing that happens when the new issue comes in is that we're evaluating how important this is. Of course, the verdict that promotes co-execution combined is very important and obscure a bug in some local utility like GCN or whatever kind of local utilities which are very likely to really affect many people if any, are given a lot lower priority. Of course, it would be nice if we were able to handle all security issues, by the way, but the free business project is volunteer and most of the work is done spare time for people so can't drop everything in our hands anytime when new issues are reported. One of the first things that happens if this is a severe security issue that administrators and teamers are involved, that's the people who maintain all the free business of all systems, all the system running the free business project, CVS or mail servers, web servers. This is, while currently, this is sort of gone wrong formally because I'm also part of the administrative team so I generally know if this is something that will affect our system or not, but some of the free business of all systems have been set up 10, 15 years ago and have been upgraded since and are rather interesting in their configuration so sometimes more people, more people from the administrative team are also building. So, of course, even though the members of the free business security team is composed of people who know of different areas of free business, some criminal hackers, some court developers and some of the hackers hackers in the criminal sense but this is a great system since. But since this very office, it's likely that we have an issue which is, this is especially in case of criminal box where we don't, the security team know enough how to fix this or how to fully evaluate it. Then we'll put in people who know about these things. The criminals and developers who are working on these parts lonely and have them help out both evaluating and fixing the box. Because this also means that we have to bring in more people who know about it which is not published yet but it generates this is not a problem but we try to minimize the number of people who know the details of an issue which is published as much as possible. While the free business project generally believe that all box should be fully open, we really prefer to have a bit of time before issues are published so that we're able to fix them. So where most issues which are important to us will have a bit of time to actually deal with this before the issue goes public. Of course, then the box fix has, patch has to be created. Sometimes we'll get it if the report came from someone who already made the patch but in any case the patch will always be reviewed for seeing if this actually fits the problem. Much more often than one should expect we get patches which, well they seem alright but when you look closer it turns out they actually don't fully fix the problems. And since that will mean that either people are or the main important thing is that this is not fixed for them and also for the security being set when people find out later that oh there was a block on the box fix we have to issue new security advice which means also more work so that's why we try to get it by the first time. It's several times in part we'll see that well the fruity product might be a bit slower getting out of our advisors but on the other hand then all the other vendors that we are coordinating would have to make a second advisory because we found a block on the box fix. So next we're starting getting here where we actually release the block fix to the public. Since the fruity is the training or is very large part of the time involved in some kind of release at least it's filled by that people seem to extra happy with more security when there is a release. So we need to coordinate with the people organizing the release which is the fruity is the releasing team and the fruity port manager team. Generally they are very open fast coming in and bringing over rules and saying we commit this now even though everybody else are not allowed to but we coordinate them so that we try to cause them as little problems as possible but we have managed to delay quite several fruited releases since there was just a security block and that needs to be fixed. Especially on the port front when we have serious security issues just before release it can cause a lot of pain because they suddenly have to recompile X amount of fruity packages right before release. So then we need to prepare for security advisory. The fruity project tries a lot to make very detailed security advisers because the advisers while in practice they won't affect that many users. This current box will require you to report your systems so that is at least something convenient. So we try very hard to make the advisers as detailed as possible so that people are able to evaluate does this problem affect my system because there is no reason my administrator should have to report the system if this is not a box that affects the system at all. And of course part of the writing of the advisers also so that we make sure that we understand exactly what the issue is with regards to valuing the patch. And then when it's going to release sometimes we have some box that is free business specific but more often than not the code is shared. I love when there are a lot of BSDs or perhaps it's code is shared in all the source projects. But in the Linux distributions we have a lot of correlation because most useful and too many useful tools are common. So if they have a box on the systems we have and since they also like to get their advisers out as soon as possible after something is made public we try to coordinate so that the issue is at the same time. And then the final part of the security I think security is of course creating a fix to the free business source cluster and sending out the security environment. Because for the last couple of years we have a system called free business the update which does binary updates so that requires recompiling having patches now in advance. So generally before release the patches are made ready for the free business update system so that more or less when we send out the security devices we can push the button and say these patches are now available through the free business update system. Kind of a policy or is it a clarification decision whether we send out an advisory for fixes or any other work? Well we always send it out with patches. Then we find patches rather fast or get them in advance. We have an issue where we want to inform people about this is actually generally this could happen if it's some so we do another form to advance and people are wondering does it affect free business? The way we know the activists is simply by speaking out in the public form the free business security and security we don't send out for the basic system and by troops without patches. I think it starts if we've done that only once where we need to have patches and so on. That's before my time from the end. That was like 95. So how are we informed about security issues? Through the security main list by track full disclosure being the main ones by track rather readable to monitor full disclosures more interesting considering the number of 13 year olds who like to brag about whatever they like to brag about and it has a lot of noise unfortunately from time to time there's also some issues being reported there which are not reported elsewhere at least until later so we have to keep an eye on that as well security companies they are for me to secure them for the Danish company but there are many others that they monitor the public list and we'll send out from various projects then we send out there on advisers and this can help us to monitor more more also that we know otherwise wouldn't be able to so basically we use this in information for finding out about issues we have on numerous occasions disagreed with them about how serious the issue is but it's a good way to find out about issues then we have the specific list mainly the privacy security it's not often that new issues are reported there but it happens and of course we have the privacy disloyal block tracking systems maps which also gets reports about security issues from time to time then we have the direct reports of issues too the security team on our private list the security team which is the entire security team then we have the security officer for when somebody wants to be even more strict about who sees the issue initially for when sending a mail to a free business officer mainly as people can also pgp encrypted so that's also used in time and while most of the privacy tracking when we try to make the decisions and workings in public but for issues like this we need to be able to work in private so that's why it is meaningless and finally before we get the reports from various vendors and all most specific that we get reports from business BSDs and also from to mention the US service security normally deals with the larger the issues affecting very normal application Apache, Bind some of the projects where we'll often get an application about security issues for concern more of the coordination yeah I was just wondering what is the ratio of internally generated partner reports as opposed to the one from outside now that we're using tools like co-meritings and stuff like that as a number of internally generated security issues internally discovered security issues is that increasing productivity in the internal world it was for a while when we first started using co-meritings to analyze the sources a number of issues were found which sort of had to send out security issues but it's not that really found internally by tools like that the most are reported internally most of the most of the security issues found are these tools they're the basic power overruns and for instance for the kernel that's the thing about that many of those kind of issues we have for various useful tools but fruity hasn't done full coverage around some of these things and also it's all the obscure codes so that's all we're finding yeah I wonder what's the average time that you spend on dealing with the security issues because it's crazy it really differs a lot we have we have issues where we get we have a couple of cases some issues which had to be coordinated with basically every operating system out there which includes companies like Cisco and Microsoft those could drag out for quite a long while but generally issues reported by the 5th and the 7th are I think it's often about a month something like that that's the time between we get informed rather than the public disclosure but it varies a lot we have had a few issues where it dealt with a certain amount of patching which I think it was three days from the initial informed to the public disclosure but it varies for the internal public reports are basically as fast as we can some issues you could make a patch in a half an hour and you're done other issues like for instance the first security vulnerability from this year about the jail ask these people they could talk about two or three weeks to make the proper patch so there's no more form of the law finally the actual coordination with other operating system vendors is often done which is called a vendor sec which is has I have seen that show which of these two years are but previous years several of the commercial units are I can't remember any more on the second group but and then most of the major digital distributions are there when issues like issues reported which has some things which limits when we are going to publish this information well even if we want to publish faster we won't do that we have to honour what we're about to submit the original reports because otherwise people will stop sending us well we can't participate in this anymore so that's why it's important for us to honour their wishes even though sometimes when we have security issues which we thought should be published much before they were is that a fixed time period or is that a person who submitted the it's a person who submitted basically the original often says I'm going to go public but it isn't the state if it's a complicated fix or whatever can we wait a bit or can we move this sometimes also can this seems pretty trivial, can we do this fast but in both cases we mentioned that benefits are also used for action-regular patches if we have questions saying this looks like we think we found this this patch but we have seen now four vendors have public security advisories are we missing something or then we can use the vendors as a communication tool to help verify we're wrong or was actually wrong so the Affirmity security team is actually not the only part free with the which guarantees any kind of support for releases for what we call normal releases we guarantee that we'll support the release one year from the day it was released for what we call have some releases which get extended support then two years basically we would like we would be nice to be able to say well we support all free with the releases for two years or after the war but free with the does quite a lot of releases so we end up having to support many different versions of free with the and sometimes it means that we have to adjust the patch for five six or something like that version of free with the often you can just use the same patch follow them sometimes so we try to do this as compromise basically we say that the last version of every major branch will get extended support so the current that's probably 3.5.0.5 there won't be any more 3.5.0 releases actually I can't even remember if it seems that the stream was extended all along but everything will generally do far the reasons we are not final branch will do every second release as extended support so that's why you actually sometimes see that free with the 5.4 expires before 3.5.3 but that's also to be able to allow people who know that we may have to very often to say okay we are going to use free with the which has extended support because we know we are going to get security fixes for two years so part of the valuation of incoming security we try to classify which type of mobility is this this is not really as simple as it may sound because the opinion of how to classify and vary a lot goes from we basically classify as most security and world code execution that could be some kind of error bind between the just set the packet bind and do run whatever code you want these are of course very serious issues and what the highest priority for us the second what's called the road amount of service that from now access to load machine you are able to somehow deny service this can be in various ways could be with the crack the deal so this just like running it all could also be the title of all system resources so the system is not able to respond next person for local privilege if you already have login system the most common one would be this type of mobility allow you to get the root access cause the definition of local what is exactly local sometimes you might have some program running that's actually being run for example by a web server or being run on incoming email or even better an antivirus scanner which well in theory people don't actually directly talk to this program but it's automatically run on incoming data so it's a program that's local well we generally say it's local if it's something that would normally require a local access but we still this is also we do security devices for these global privilege escalation the last type of mobility is the local deny service if you have access to the system you're able to run off with the crash system we don't do security devices for these some operating systems do we decided that it's well it's much work and it doesn't normally affect that many people this doesn't mean that we don't make sure that the issues get fixed but it means that we will not generally send out security devices for this sometimes we might send over called red notices which is what the releasing team also uses to break critical block fixes but I actually can't remember if we have done that, we discussed it it's a judge who made it so I'm going to go quickly to one of the primitive security devices this is one from April this year first in the initial part we have the two parts that affected the effects part says this effect this is a very generic way this one is accepted this is called the deny team this is very old this is basically from the spoiler version then we have the section saying when was this actually break in the security in the primitive solve tree this is going to be very useful people want to be able to see do I actually have a lot of data recently enough to have this fix sometimes there have been confusion in time because for our stable practice effects might have been created earlier and the fixes to bind were in the stable practice some more earlier which was an in-kit that was actually fixed because it was a topic issue where it was fixed in the primitive 6, running 6 some day before another part of this we have called CVE that's a project funded by the government organization which tries to identify that you need security vulnerability this means that you are able to find out cases if you compare to security for instance from different organizations I think actually talk about the same issue also you are able to if you want to know more just using this CVE you are very often able to just put it into Google and you are able to get a lot more information about this one finally we have the background safety we try to save which part of the system it is in the basic purpose this is also to encase our two programs with the same name so you are able to identify if somebody else makes a shell called bind we want to indicate that this is actually the state server bind or whatever then from there we try to differentiate between what's actually the problem and how does this impact people sometimes we succeed sometimes we don't we try to divide it into these two parts the impact is generally the one that's most interesting to people reading that by trying to see ok does this actually impact me on my system for instance this one if you don't provide me six it's too old to say it tomorrow you are not impacted at all and if you have some kind of file you might not be impacted at all then of course probably more interesting what's the solution to this and this is also the part where we try to as I mentioned earlier we try very hard to make sure we don't break things with the security but sometimes the security it cannot be helped that we will break some kind of functionality generally when we are afraid this is the same thing very either entirely unlikely to affect anybody or the the actual problem called by this is much smaller than the security issue but he will describe if we actually have to make some kind of regression yeah then we then we should upgrade to various or you can also download the patch we used for so you can patch the software in mind only if you don't use the CSR system which prevents the software from disappearing in time this second class so the patches can be quite long we will check that this patch actually works to each of the reasons and sometimes we have to make a patch for each release of the rule the section of this particular one we can try to say exactly what's required to actually fix to apply this we try to to the minimal amount required the minimal part we have to recompile of the system but sometimes the interdependencies between for instance in some library it might be rather hard to avoid rebuilding the entire fruiting with the bloatball.com so generally if this says suggest bloatball it's because we think we have to do it so even though you might need to do some work from or you can just speak about this unless you really know what you're doing you should do that because you might risk that you don't fix everything and then the final very important part for us to generate is exactly which files are these which should fix them this is done since almost all files for the fruiting software has a version identified you can look in the file and see which one it is so by looking at this section you can compare the version of us with the real thing is this active victim might only version if it went down in the earlier this was actually done by ANT by guessing how CVS generated version of us but now we got to title the manuscript and finally we have references if there's further information and as the photo indicates all the advisories are signed by the fruiting security of the PDP team as mentioned before this is the the security officer team so that's progressable from what's being happened as key so we are there once they are able to sign and send out these advisories so that's also why we might sign it but it might very well be something else from the security team that actually wrote the advisories so we have the fruiting support which has an increasingly growing number of thoughts and yeah initially the fruiting project has been all towards security crisis this did for about because it didn't scale over too many then we tried fruiting security notes where it's assembled a bunch but that meant that there was some large delay about when this was out so what we do now is we have a viewer HTML document where we describe the security issues for port in this document we don't wait until the issue is fixed necessarily we might document it before it's fixed generally the way it works is that each port has a maintainer which fixes the issue but sometimes somebody from the fruiting security team will go in and fix it directly this sort of bypasses the normal rules of how the project works to cooperate but this is done when we adjust that this is a more fixed and we need to get it fast and generally the maintainers don't complain about this because we try to meet amongst them yeah I'll just skip most of it but we have this XML document that people initially think it looks very scary very complicated but well the hardtie is not really filling out the XML it's actually finding all the information this was fixed in this version and so on and so on is that more like a trial for all of us? yeah it's getting quite large but generally it's not really a automatic process the entity part one we'll skip it until we have the viewer HTML website which is then where you can read about the issue and a sample for specific views and the more interesting part is that this can be called part of the bad habits we had more of a tool which was run on the system which then checks all the old stuff all to get this file with a number of other things that existed so very briefly to keep yourself informed if you run a free business system just write to free business and unscrupulous where we send unscrupulous business portal it can be used as a tool to check the local system it should also be mentioned that even if portal or stage system has no issues well we might not always be entirely caught up in the viewer HTML entry so don't think that this is mean to you entirely safe but we try to open as fast as we can of course for the more beautiful one we say the local system has actually time to before the public meeting yeah and we'll have to skip that any questions how about the port security well we need people to have public meeting that run for part of the security but we really need more people to help out with the deal with port security because as saw the graph there's more and more ports and it takes a lot of time and it gets really boring so if anybody ever wants to help out through business security help out with everything I've got for these security issues of course very good thing we shouldn't say this portal what? we shouldn't say this portal oh sorry yeah it's fine it's interesting well when you make your 100 entries start to get really boring but that's why we need more people to so you don't have to wait for the meeting you're keeping your audience from the cave oh let's coffee break now