 So a general principle in security is that security is a cost, security is expensive. So it's not the case that the more security you have, the better it is, but usually it is a trade-off between the risk. What is the risk that something goes wrong? What happens then? What is the value of the different assets, the different things you have in your system if they get exposed? And another trade-off is, for example, very often the performance of the system or other qualities. So if you, for example, add a very strong encryption, it might make things slower. There are always other trade-offs, for example, user acceptance. If you add a many-layer authentication, like two or three-factor authentication or biometric authentication, there might at some point be a resistance from the users. So in general, it's not that you should have the maximum security. You should try to analyze what's a good security level for the application that you're having. And what usually happens is that you do a trade-off analysis between what is the risk and what is the likelihood. So in a way, what's the consequence if something is happening and what's the likelihood that it happens. This is something you very often see also in other areas. For example, if meteorological organizations often use this to decide whether they should give out a warning, a weather warning, where you say that, okay, if the consequence is very high and the likelihood is very high, we need to do something. In the security case, well, this is really where we want to reduce this somehow. Either we want to make it less likely or we want to reduce the consequences of something happening. If something is very likely but it also doesn't have very strong consequences, maybe we don't need to do something. And similar, if there is a very strong consequence, it's very severe if something happens, but it's so unlikely that maybe we also don't need to do anything. So this is usually what you do in this kind of trade-off analysis or assessment of what is going on. Now, what you want to look at is essentially what kind of policies should be in place. What kind of things do we need to decide in the company with respect to security? Usually what you look at are, I already mentioned it, are the so-called assets. There's basically things. What kind of data do we have? What kind of objects do we have that are somehow valuable? For instance, in the coursebook, the example is of a medical system, a medical information system. So imagine you're in a hospital and you're storing patient data. Then the assets might be that you have this kind of patient data. And if it gets exposed, that's quite severe because someone could read the patient records and figure out what kind of diseases they have. And that's rather confidential data, so it shouldn't get exposed. So usually you start looking at that. There might be other things that are simply not relevant. So you might have an asset database of who are the suppliers the hospital is ordering from. And if this is getting exposed, well, the severity is maybe not that high. The consequence is not that high. So there are different levels depending on what kind of assets you have. And the first step is usually which of our assets do we need to protect because they're very sensitive, which ones are not as sensitive. So that's one thing. Usually you also look at procedures. What are we doing to protect our assets? For example, if we look at application security, we might talk about are we following certain programming guidelines? If we talk about operating security, are we, for example, having password policies that users have to change their password often enough or they are only allowed to log in if no one is nearby or I don't know what. So different procedures that are in place. Then we have the responsibilities. So who in the organization is responsible for following up on these things, for example? Who is responsible that the passwords are changed? Is that automatically enforced by the system or is someone reminding people? Or if we talk about confidential data, is it the responsibility of the nurse or the doctor to make sure that the name is not mentioned in the patient record so that if the patient record gets exposed, the person reading it doesn't know who this patient is. So that might be another thing. And then very often in companies, there are existing policies already. So if you introduce a new system, it's not like you have to come up with all the new things but there might already be certain procedures or responsibilities in place that, for example, say whenever you edit a patient record, you should do that on your own computer only. It's not allowed to use the phone or things like that. So these are typical things we might want to go through when we look at application and operating security for software. And the way we can do this depends very much where we are in our development. So if we look at the classical waterfall model, so we have the requirements engineering or the planning phase, we might have architecture and then we have design and implementation and we have the operating of the system. The system is rolled out and operated. You can make these security assessments, of course, at very different stages. So you could do this in the very early beginning when you plan the system that you basically say what are the assets we are going to have? Do we need to protect them? Do we not need to protect them? What do we need to do? When you do the architecture or the design, you can think about are we following any architectures that are very suitable for application security like the layered architecture, for example? And when you're operating, you can again do security risk assessment. You can look at, for example, what are the operating procedures we're having? Do we need to change anything? So again, there are multiple ways of doing this and it's not necessarily better to do it here or here in practice. It's a combination because certain things are good to look at when you're planning. Certain things might be more suitable in the design or in the operation of the system. So essentially, you try to cover a certain ground when doing these security assessments. Okay, so that's a rough overview of how do you look at security? How do you plan this? When do you do it? We'll now dive a bit into the assets and this kind of risk assessment. What can you do there? There are quite some examples in the book, so I would strongly recommend to look at that to get some more practical ideas. But we'll just quickly look at one way of doing that, which is essentially coming up with a tabular format where you try to identify the different assets, look at how valuable they are, look at how critical it is if they get exposed, and then come up with strategies essentially.