 Okay, so now we have identified all our assets, we know what the value is, what the consequences of an exposure are, what threats there are, what kind of mitigation strategies we have, and now it really goes down to how do we design our system in a secure way. And there are a number of things that we might want to look at. First of all, we need to keep in mind what I already said in the very beginning that this is a trade-off and a typical trade-off on an architectural level is with the performance and the usability or user experience qualities. So that's always something we need to keep in mind that at some point we can add more security but it will slow down the system or it will make it less scalable. At some point users will start resisting and for example a common issue here is if you make the password policies really complex and you require users to change the passwords all the time, what happens is simply that the users will start writing them down and they will be annoyed. So in the end it might not help you very much with the overall system usability and not even with the security maybe. So that's something that is very important to keep in mind and then you can really try to go into the different aspects of a system and this starts with the choice of technology. So you might choose certain components of the shelf, so existing libraries, existing subsystems and they might impact your choice. For example, a system might require a password authentication and does not support two-factor authentication. So then what do you do with this? A programming language might have certain security concerns. So for example if you use C or C++ you need to handle memory management and that's something that can be security relevant because if you don't do it properly someone might just be able to read or write to any memory location which makes it very difficult to protect certain parts of your memory. So the programming language might have consequences, the deployment for example might have consequences if you choose to use the application through a web interface and access is possible from everywhere in the world through the internet that has consequences. So all of these on a technology level needs to be taken into account and that's for example why in certain areas in safety critical systems for example there's a preference or sometimes even a requirement for certain programming languages because they're for example better for security or safety. But at least these are the things you might want to look in on the first level what kind of technology choices are we taking or what choices do we have to take depending on dependencies for example or depending on requirements and what can we do against this. And usually this again leads to the discussion about threads and how do we mitigate them. So if your library for example requires an authentication you're using a component that's deployed in the web and you need to communicate over the internet so you cannot change that then maybe you want to take other measures so that even if the network traffic is intercepted it still doesn't lead to an intrusion. So that's for example one thing that might be there and it might the alternative might simply be to develop this component yourself which might be very expensive. So it's again another trade-off it's a cost trade-off. So this is on the technology level then we have the architecture level. So the question is how do we design the system how do we break it down into components that it is more secure and an aspect we typically talk about in this area is the notion of protection versus the notion of distribution and the idea here is that it's much easier to protect your assets your data if they're in one place. For example you have a single database it's much much easier to just add layers of security around it you can add encryption you can add additional authentication you can add all these layers that make it very unlikely that someone can access it or intrude in any way. The problem is if someone manages the consequences are much larger because you essentially have a single point of failure so if someone manages to get into your single database or crash it then he or she directly has access to everything so either the entire data gets exposed or the entire system is unavailable so that's the drawback of protection and the alternative is to say well we distribute the assets for example in the patient case we have the patient names in one database and the patient data in another database so then if it gets exposed the person either has the names or the patient record but not both together so one alone might not be very useful or we just for terms of availability we deploy the same patient records to multiple databases so if someone manages to crash one the system is still operational. The problem is exactly the opposite as with the protection if you distribute the assets it's much harder to protect them because you need additional communication between the different places and that basically adds additional places where someone could intrude for example additional network connections additional bugs in the technology that you're using so this is also not an ideal thing and this is in practice again one of our trade-offs that we need to take into consideration how do we do this and there is no easy answer to that it depends a lot on your assets for example if you might have assets that are not as critical it might be a very good idea to distribute them because it's not that important to protect each of them but the availability is maybe more important so the answer here is it depends but you need to think about this and depending on your needs you might need to choose different security architectures so if for example protection is the focus it might be an idea to use a layered architecture where you have a single layer where all your data is stored and you can add a lot of encryption if you need more distribution then maybe you need to choose a different approach of doing this for example a client server model where you have multiple servers with the same data there are concrete on the third level there are concrete design guidelines that we can look at both for design and for programming I'll discuss the programming later because programming guidelines are usually or often they're specific to a language but we have some general guidelines and in the slides there are ten of them I will not discuss all of them here but maybe just a couple of them so the first one that's maybe a bit abstract but you should kind of base your security on explicit policies so I've mentioned this before you should think about the policies in your company assets procedures regulations and the main idea here is that security is expensive it comes at a cost of performance usability at other trade-offs so you shouldn't just throw security at your system but you should really think about it in a concrete way what needs to be protected what needs to be available how do we assure this and how do we balance it with for example usability so think first and then go into the security you not just add whatever you can another one which is related to protection here is don't have a try to avoid having a single point of failure like a single database because if it crashes if it's accessed the severity is much larger the entire system is gone or the entire data is getting exposed another principle which is five in the list is log user actions or I'll just write log here because in general the idea is attacks happen and the better you can identify them the better you can understand them the more you can protect your system in the future and the quicker you are aware of what happened for example if all your passwords somehow get exposed there is a difference whether you realize this two hours later or two weeks later so usually try to log as much as possible for example changes to your assets log in of users actions of users to understand what's going on then there is the concept 8 in the list just maybe a bit hard to understand that's why I mentioned it here and that's called compartmentalize complicated word your assets and what this means is essentially that you shouldn't have all the assets in one place because then the exposure has quite severe consequences and I already made the example here if you for example have the patient records if you manage to separate the names from the record then and successful attack doesn't have as severe consequences you might need the entire the entire picture the entire distributed data to actually get some kind of value out of your intrusion so trying to compartmentalize that might help with it and then I think the other one that might be a bit tricky to understand so I'll mention it here is design for deployment and that's not directly clear what this means I think from the name or why it's security relevant the idea here is that your application is designed is programmed in a way that it's easy and it's straightforward to deploy it and in practice many applications are really really complicated to deploy so they need lots of configuration you need to make sure that everything is in the right place all the configuration scripts are correct and so on and the problem is that because this is so complex this could easily lead you to introduce vulnerabilities so for example if it's very complicated to set up the database then what happens is that people forget to remove the default password for example and someone can just lock in with admin admin so it's these kind of simple mistakes that are being made because the deployment process is very complicated the idea here is basically don't forget about it don't forget about the deployment try to really think about how can you make this easy and efficient to deploy because this does have a security impact it has a lot of other impacts as well like the usability for the administrators or the operators like the frequency how often you can deploy but it's definitely also security relevant so there are a number of other ones here another guidelines I would recommend you to look at the slides I will not cover them all in detail but essentially we have these abstract policies guidelines that are independent of what programming language or what technology you're using so in addition to looking at the technology and the architecture is a good idea to think about what kind of guidelines can we follow and now in the last part of the module we go some we look at some concrete guidelines for a programming language doing secure