 Because, as the famous saying goes, those who know don't talk, but those who talk don't know. So if you have the feeling this guy doesn't understand anything about the other side of information security after my talk, it's because of Lao Tzu, okay? Good. What I will do today is I will give you and the audience a very small overview of what I coined the other side of information security or if you call it the organizational side. Not sure because of time constraints. But I hope that after my talk you get a good idea, okay? We have the technical side, that's one. But we have the organizational side as well, and this is what it's all about. This is what I want to talk about. I'm not going to read the agenda. You can read it for yourself, so just skip to the next session. First of all, I want to give you some background information from the perspective of the organizational side. I will discuss the four fundamental security questions. The components of a total security solution. The trend in the market as I see it. The security triangle and the domains. Okay? Four fundamental security questions. Most organizations jump immediately to the questions how to protect. Despite the fact that this is an important question, it's not the first question that you should ask. There are three others that you should ask first from my perspective. The first is, why should I need protection at all? If I do not need protection, why should I care about the top edge new idea systems, full-blown crypto? I don't really care. But given the fact that you need some protection, how difficult will it be to protect? By the way, I will come back to these questions later on. So I just skip them briefly now. But another important question is the constraints. I mean, if you have a financial budget of $1,000 and you are asked to install a full-blown crypto infrastructure, I don't think you can go far even with open source software. The third question then is, okay, what and against who should I pretend? When you have a good picture of these questions, then you can go to the fourth question, how should I do it? So for me, this is very important. This is the start of the whole security. Asking and answering these questions first. If you look at the total security solution, from my perspective, there are two main components, technical and organizational. As you can see, technical issues, I won't discuss it because the whole conference is about technical issues. The speakers know by far more than me about the subjects that I skip it. But if you look at your organizational part, you see that there are different aspects that you have to cover. For instance, the business assessment, the PSPG for the people among you, policy standards, procedures and guidelines, I will talk about it later. Risk management, security awareness and also legal experts. You wonder maybe, okay, I see 20%, I see 80%. What is this? These are average numbers. And it means that if you look at the total security solution, 20% comes from technical and 80% comes from the organizational side. Before you jump on the stage and kick my ass and say, this is not true because of this and this and this. I said these are average numbers. And it can be the case that it's vice versa in some situations. Second command I have is although that 20% of your solution is technical, it does not mean that it just takes 10% of your resources. I mean, it can be very costly. It can take more than 80% of your resource pool of people to do the job. But if you look at it from a global point of view, these on average are the numbers. So what is the trend in the markets? The trend in the markets, as I see it, is that security is considered more and more as just a part of the normal business process. Like we have human resources, facility management, whatever, financial business. It's just a part of, okay? Does it mean that technology is dead or something? No, of course not. Technology is still very important, but it's still part of it. It's not the leading factor, not always at least. The point is that most securities are seeing this, but they just don't know how to do it. Today I will give you, hopefully, a brief overview of how you can do this. Do this, meaning taking security from a business, a strategic point of view, coming down from strategic to technical to operational to the bits and the bytes, okay? Question. If you have to protect your information and you have to define three fundamental issues that you have to be implemented in an organization, which we would not be. I came with these three. These are not the three. I mean, everybody in the audience may have his own idea about this, but I think that the most important factors are the business assessment, risk management, and the PSPG, the security awareness, and as third fundamental pilot, the security architecture and infrastructure. I'm being backed up by this picture by 400 international security professionals. We did a survey for this, and this was what came out of it. It doesn't mean that this is the security triangle, by the way, but it's just the way how I see it. Okay, I skipped this because of the time. Okay, the first step, meet the balance. Well, meet the balance. I don't know if you've seen the movie, but if you see the balance for the first time, you want to make a good impression. So meet the balance should be read as meet the management because this is where it all starts. They are the only responsible for security. It's interesting to know that this is also stated in an ISO law. ISO 13335 says literally management of security is a management responsibility. So if management of your company asks you, okay, who says so, the international standard organization. Another important point is that they decide about the budget. Without budget, you cannot sell or buy any tools. You cannot hire people or whatever. You cannot go to conferences like DefCon. Okay? They should support security from a top management point of view so that everybody organization knows, okay, this is supported management. And they have authority. The question is how do you do this? Well, I suggest to do a business assessment at risk management. Coming back to the four fundamental questions. The first question was, sorry, why should I need protection? Okay, because you have stakes. You have different types of information that you want to protect. There are different security requirements. And you have to do the questions. One of the most important questions is is IT a supporting service or is it from strategic volume? Examples of stakes. Company image. What happens with the company image when there is a security breach? What happens, for instance, when your service is lost, if you have to provide 24-7 service, you have an unavailability rate of 95%, let's say an availability issue of 95%. What does it mean for your customers when in the timeframe of 5% unavailability? What does happen? Will it go away or are there other points? Another important stake is human lives. Believe it or not, but one of my customers, it's in the telecom, and I asked him these questions to management and said, are there human lives at stake? And he was thinking, he said, yes, I think so. I said, give me an example. I said, we had an accident last year, a heavy car accident, and people tried to connect to 911 by means of the mobile phone. And it didn't work. So because of this, it was not in America, by the way, but 911 is in your country, you're decoded out. But because of this, people that were part of the car accident died, because the ambulance was not in place at the right time. Needless to say that, for instance, human lives are certainly at stake in the healthcare industry. If you look at information, okay, I think you're familiar with this, you have all kinds of different types of information. Public information, you don't care about any security requirement, confidentiality, company critical information, you name it. The point here I want to make is that certain types of information has as a consequence certain security measures, because if you have a confidentiality issue, well, maybe you should think about it like an cryptography encryption to encrypt it when it's sent across untrusted networks as an example. While you have public information, just publicize it and say, I do not back up any security requirements for this, so if it's revealed to anybody, I don't care. If it's not available for one hour per day, I don't care. So depending on the type of information, this reflects later what kind of security measures you may have to take. When I read the newspapers, the magazines or whatever, I think that most of them stick to very high level security requirements. So we talk about confidentiality, the C, integrity, availability and the R of lower radiation. But I think you can do with more fine-grained. For instance, what about internal versus external? What about function versus data? I will explain. In case you have data that is compromised internally, you may not care, because everybody in the organization may see it, even if you're not authorized, I don't care. However, when this same information is being compromised externally, then it may become an issue. So we're talking about the same type of data, so we cannot say confidentiality is or is not an issue. You have to say if it's compromised internally, if it's a low issue, if it's compromised externally, confidentiality is an issue. So function versus data. I gave example accountability, also known as normal predication. Meaning, okay, the sender cannot deny that it's being sent, or the receiver cannot deny that it's being received, as a definition. Broken anonymity. This is something, I don't know if you understand that the mixed manian talked yesterday, mixed manian about the anonymous email protocol. Okay, yes, I see somebody. Well, you can imagine that when the anonymity is being broken, that this is a major impact for these guys. So this is something that is important. About unavailability of accountability function. Well, it's nice all those digital signatures, but if I just have 7S attachment, which is the digital signature, but I don't have any algorithm or any function that can use this type of data and prove that this is a real valid digital signature, I cannot guarantee accountability. Okay, so the data is there, but the function is not there. You see? So if you look at the security requirements, you can even go for distinction between function and data. If you do it this way, I don't say that you should do it every time this day, but if you really wanted to go for fine grained security requirement assessment, this is the way you can do it. One of the ways you can do it. Second question was, how difficult will it be to protect or in other words evaluate the constraints. Well, some constraints may be trivial, like the financial constraints, but what do you think about political constraints? One of my customers is in the Middle East and we are designing security architectures and infrastructures for this customer. Guess what? Checkpoint 501 is not allowed because it's a product from Israel. Okay, we can argue whether checkpoint 501 is a good firewall or not. This is not the question here. The question is if you build your security architectures around checkpoint security, checkpoint 501 and you want to implement this architecture in a country where it's not allowed because of political issues, you have a problem. Okay? Internal knowledge. Yeah, of course. Everybody wants to go 24-7 monitoring ideas. It takes at least six to eight people to do this, at least. Okay? If you don't have these people, if you don't have this internal knowledge, I mean you can have the people, but if those people do not have the knowledge to do the work, what do you do about the monitoring? Okay? There are so many examples of constraints that you have to take into account when you develop a security solution. Okay? Risk management. Let's see. No, this will not work. Sorry. I want to try something. Sorry, I don't know if it works because of the resolution. But let's see here. Where is it? Okay, I don't see it. No, I wanted to show here. I don't know if you can see it. Can you see it? Okay, good. Okay, just one more time. Well, okay, I have to admit I love martial arts, but the reason why I want to show you this is there is a saying as you know that a word, sorry, a picture says more than 1,000 words. For me, a video clip says more than 1,000 pictures. This is risk management. What you saw is risk management. Why? Because the good old guy thought he protected everything. But security, as you know, is expected, unexpected. So he was kicked in his private parts and I want to make the metaphor to risk management. Risk management is if you are going to do risk management, do it from a perspective, expected, unexpected. Meaning, if you're going to discuss risks, try to come up with risks that you think, well, this will never happen here because of this and this and this, you will be surprised how many risks are still applicable. Okay, now to the formal definition of risk management. Risk management consists of two parts. You have the risk assessment part and the risk treatment or risk mitigation part. Risk assessment is analysis. That is, what kind of risks do we have after all? And are there real risks? And if there are real risks, what is the potentiality of this risk? This is a difficult question. This is the risk valuation. This is not always possible. I mean, how do you say that, okay, the company image is a risk when there are security breach? I mean, how do you value that? Do you look at the stock prices when you are on the stock market or do you try to calculate that this is a difficult question? Therefore, you have two approaches in this. You can do the simple approach with the qualitative analysis. Just say, okay, it's low, it's high or it's medium. Or you can go for the qualitative analysis and try to come up with figures like the probability that a hacker will attack our web server is 0.775671. Okay, if you have fun with this, go for this, but it's tedious. So, the risk management part coming back to the third fundamental question gives an answer to against what and who should I protect? This is the risk assessment part, okay? And finally, we are at the risk treatment part in other words, how should we protect? Okay? Remind you that there is a difference between security requirements. No, there is no difference. Yeah, there is a difference, but there is a dependency between security requirements and risk management. To give you an example, it might be that I have a high risk for unauthorized access to my internal network, but if I don't care about security requirements, I don't care about security measures at all. So there is a dependency between those two, okay? Keep it in mind. Okay. Some attention points for risk management in practice. I mean, in my talk, I will give you some theoretical backed up information, so to speak, but I also want to make it practical for you. So the practical points that I mention here is based on my own experience. I leave it to your own judgment. If you look at risk assessment methodologies, you have globally speaking three parts, three different assessment methodologies. Generic, as the word implies, very high level. Detailed, like CREM is an example. It's used in the military. This is the methodology that you are really trying to calculate probabilities for five numbers behind the point, behind the decimal point, and the business oriented approach. The business oriented approach is the approach that I discussed up until now, and I will discuss a little bit further. I also already told you sometimes difficult to determine. More important is, when you are going to do risk assessment, make sure that you have people who know the business. Okay? And make sure that they have the authority to decide that they say this risk level is high because of this and this and this. There is no frustrating part more than doing a risk assessment and afterwards, you know, oh yeah, this guy, he's not the management. He doesn't know what he's talking about. We do it again. Okay? So make sure that you have to write people. If you have people who have the authority to decide but who don't know the business process, don't do the risk assessment. It's useless. And be careful when using risk management tools. The problem with risk management tools can be that you have to follow a certain methodology because it's in the tool. I can imagine. However, if the tool is not flexible and you want to do a risk assessment from a different perspective because this is a different organization that you normally do, this can be a problem. To give an example, when I do risk management, I do only big projects. But I do not use any tool. You're crazy. Maybe some people think, well, that's true. But if you don't use a risk management tool, the only tool I use are some spreadsheets in Excel. It obliges you to think carefully about each situation individually. Of course, doing a lot of risk assessments gives you experience to do it quicker and quicker when you get experience with this and you become handy in this. But it obliges you to think about carefully what is this situation instead of just point and click. So be aware of this. Maybe the difference I can make is the difference between a script kitty and a real hacker. As you know, downloads a tool, click, it doesn't work. I don't understand a tool, download another tool, click and see if it works. The hacker, maybe he uses tools, but he likes to think about behind the tool. He builds those tools. He does the same attack or whatever without the tool by making his own programs. He uses the management tool of doing this management without such a tool. Okay. I'm pretty sure that everybody of you is involved, has been involved or will be involved with policies, standards, procedures or guidelines, whether you like it or not. One of the problems with policies is it has a bad reputation and I can imagine why. Because the problem with policies is that if you just write them from scratch without seeing it in the total picture, without doing it with the whole crew, it will not be accepted because it's an ivory tower syndrome, so to speak. But policies can work. Standards can work as well. To give you an example, this is more a graphical overview, but I want to go to this slide. Just to give you an overview of what's the policy. The policy is a high level statement about an objective that you want to reach. Okay. For instance, a policy can be that access to computer information systems is restricted to authorized users only. Okay. The question is, how are we going to do it? Well, we define the standard, which is requirement. The views are required to have a unique use for the and confidential password. This is what you want to do. This is how we do it. The procedure is, that is, how are you going to do it in practice? Okay. You have to fill a form. It has to be authorized. And the form has to be checked by an authorized signature list. And the guideline could be password shooter 5 to 8 alphanumeric characters. Okay. So this is the difference between those four statements. Okay. Now something about the building blocks. The first policy that you should build in your company is a corporate security policy. This follows directly from your risk assessment and your business assessment. To give you an example of a corporate security policy. Okay. I will increase ... It's a high level. This is readable. Okay. Policies should be very high level and to the point. This is a little bit, this is very high level. And the census is maybe a little bit longer because this is the corporate security policy. This is the model of all policies. I just show you an example to give you an idea. Okay. Policies. How does it look like? I emphasized the important points. This is the most important point that you can find. Management will therefore formally stress security. This is your backup. This is your support what I'm talking about. They say, okay, we will do something about the security requirements. More important in this is that they say that we will create a corporate security officer. We will create a corporate security committee. Okay. So discussing all the security issues. As you see, it's very high level. But this document should be just two or three pages. Maybe less. Maybe more. It depends a little bit on your organization. Formally stressed by the management and signed and communicated by the management. And this is the backup that you need. Okay. So this is the first policy. This is the root of all... not all evil, but the root of all policies. The second level, the first other five important bullet blocks in your organization are asset classification. This is what are we going to protect? I mean, if you want to answer the question, you have to know all your assets. I mean, otherwise, how do you protect what? Security organization. This deals with if you want to take security seriously, you have to assign people to a certain job, like the security officer, as we said, the security administrator. Okay. So this is all about that. A high level incident response plan. This is most of the time lacking in organizations. Yes. We have antivirus tools. Okay. Yes, we update them regularly. Okay. What do you do in case of a virus? I don't know. The high level means this defines a framework who is going to do what in the organization in case of any incident. A virus is just one example. But also unavailability of a web server that is business critical or a hacker attempt or whatever. Education training. Also something that is underestimated. I think some of you, maybe most of you I don't know for sure that when you go to your management and they say, okay, you have to implement this tool. Okay. What about training? What training? Read a book or just do it. This is underestimated a lot of times. Okay. So on the one hand, they want security, but they are not willing to invest heavily in education and training. And the fifth one is the business continuity framework. It's all about, okay, in case of a disaster, what are we going to do as a company to survive? The third level that you can build are the access control who is authorized to access with systems, backup recovery, I skip it. And the fourth one are general policies like cryptography policies, system specific policies. Okay. Some tips. Make sure that these documents are supported by the system owner. Every system in the company should have a system owner. System owner are ant responsible. Just clearly in your own company who is the system owner of your systems. I'm curious to answer. Make sure that you develop the documents with a representative group within your organization. Don't go for the ivory tower. You will lose. Make sure that the group that you have are representative from the end users, from IT, if necessary, from the human resource and legal department. For instance, if you talk about the acceptable use policy, which is a policy that defines the, let's say, the rights and obligations for the end user, make sure that you involve human resources and legal departments. Okay. They should be communicated and used from pragmatic. The last two points are very important. Please, please pay attention to the organizational culture. Developing policies for a bank is totally different than developing policies for, let's say, information internet security provider. Because the organizational culture of internet security provider is more it's dynamic. It's I think the average age of people is lower than for a bank. Different kinds of people are working. Fast time to market. All these kind of input you should take into account your policies. Another point is international cultures. I can talk a lot about international cultures. I won't do it now, but remember that when you have a very hierarchical culture, like in Asia, this reflection policy then compared to, for instance, the Netherlands where I come from or America, which is a totally different culture. Okay. So this is the only point I want to give you now. Please pay attention to the culture. Okay. We know now, we need security. We know the security requirements. We know the risk profiles. But how are we going to do it? Are we on our own? No. We can use security standards. Security standards can best be seen as a set of best practices. Set of best practices developed by thousands of people worldwide thinking about security and saying okay, we think if you want to cover this aspect of security these are the best steps you can take. This has an advantage and a disadvantage. The advantage is, okay, it's all that. I think the most well known example is the ISO 17799 or the former British standard. Here in America for the healthcare is the HIPAA. However, please be careful not to implement a security standard because it is like going to a car shop and saying I want the car now. Okay. What are you going to do with this? I don't know. I want a car. Okay. Is it for shopping? Is it for pro tracing? Is it for formula one? Is it for the desert? What are you going to do with the car? You get my point. To give an example, if you look at the ISO 17799 on the third page it says literally first perform a risk assessment because the risk assessment together with the security crimes profile provides you insight which message you have to take and which not. If you do not want to do with photography, forget about section 10 of the British standard or nine whatever, because it does not apply to you. Okay. So yes, you can use them. Yes, you should use them if applicable but please be careful how to use them. It is the same with a security baseline for UNIX or what. If you stood down the kernel okay, you can do it, but some applications are dependent on certain kernel parameters. So if you stood down the kernel really hard or really tight and the application does not work, well there is a mismatch between those two because at the end is the application that provides the business service and it must run. Okay. So this is the same example. Well, some examples of security requirements I mentioned here. A few of them are on your CD, the common criteria not the ISO, but the predecessor that was input for the ISO normation, the NIST, they have a security handbook and the EITF and the first four I did not put on the CD because of copyright issues but for $200 you can get all four. It is not much amount of money compared to what you get. Okay. Another important issue about security standards is certification. You see that most, no, not most more and more organizations are looking for certification. Why? Because if you say I'm certified against the ISO 17799, what does it say? For me personally nothing. That's not entirely true. I put a little bit direct so to speak, but it's comparable with a certification for your car. If you go to the garage and you look at your car from the maintenance guy and he says okay, this is okay, this is okay, this is okay you can go for one year. It does not guarantee that you don't have any accidents. It doesn't guarantee that your tire will not be flat. It does not guarantee that your brakes will not work or whatever. It says something but it's a certificate is something of one point in the time. So when a company shows you I'm certified against this standard, okay, ask them, okay, how did you do it? What is your process? How do you handle this and this and this and this? May I see the independent third party reviews? May I look at your procedures? May I look at your policies? May I talk to your people? Because only then you get a good picture of what they are really doing. Okay? There's a difference between window dressing meaning okay, to the outside world and what you're really doing. I mean, a notorious example is the ISO 9000, the quality certification. The order passes by, you know exactly when. So one week before you take your bunch of invoices and you're going to sign them. Okay, this is not the way to do it. So only certify when you think that security is an essential need that you really want to. Now, I'm coming to one of the most important success factors of information security, which is security awareness. If you talk about security awareness, you talk about psychology and I give you this overview. Let's assume that most people in your organization are not aware of their incorrect behavior. Meaning, when they go home, they leave all the confidential information on their desk. They do not put on their screen saver when they go for lunch. They leave the laptop in the car just on the back seat when they go shopping. You cannot blame these people because they don't know what they're doing from this perspective. So what you want to achieve is from the red bullet to the green bullet, or going to unaware correct behavior. In other words, security must be a second nature. Yes, of course I switch on the screen saver when I go to the bathroom. Yes, of course. I take my laptop in my house when I go home by the car and I park it. Of course. That attitude. So you want to go from red to green. However, you cannot make this jump directly. It blows the psychological mind. So we go via another route. We go from incorrect behavior to unaware incorrect behavior. So we try to people do realize what the consequence is that you leave your laptop in the car unprotected. Do you realize what it is when your screen saver is not popped up and your computer is accessible when you are in the toilet? Okay, so make them aware of the fact what is the result of their behavior. After that they go from, okay now I know what I'm doing wrong and I'm going to improve myself. Hey, I have to go to the bathroom. What did he say? Okay, control all the lead. Put on the screen saver. I'm going home in my car. Halfway the path to my house. I forgot something. Go back to my car, pack up the laptop. So this is the training phase. Okay, become aware of good behavior. At the end you come at the right point that people are treating it as a second nature. Believe me or not, but if your security in your organization is not let's say at the right level you will never ever implement security successfully. Never. Compliance. Okay, compliance is about yes, we have all kinds of documents. Yes, we have our risk assessment. Yes, we have our security crimes and so forth. Do we still comply? Because the risk that the organization runs is that they define very enthusiastically a set of documents but after a year, they are gaining dust and people go back to the normal situation. Okay. So how can you do it? You can do auditing. You can do a quick scan, meaning just jumping for one or two days in your organization ask some questions, so get a high level picture about the most that are concerned. Do a review, which is something more than a quick scan for audit, meaning, okay, I read every document, I interview the people, I know how I am going to see how this business process is running, so investigating. Okay, so you have different classifications of auditing. Monitoring, which is more real time. Auditing is always, okay, something happened and afterwards. Monitoring is at the moment a lot of stuff. You can do it internally, externally. Who is working for a bank? Okay. It doesn't matter if it's a bank or not. The point I want to make is that big organizations have their own internal or department. The question is, is this department independent? No. They are semi-independent. They are independent because they are a staff department directly from directors, so from this perspective they are independent compared to the other organizational units, but they are still part of the same organization with all the political war game. External auditors are those independent? I would say no. And this is maybe a little bit bluntly put. The point with auditors is that yes they are, to the most extent they are independent, but when it comes down to commercial relationships what is going to win? I mean, look at N1 as an example. What happened there? That's my case. Technical first organizational. Auditing doesn't have to be organizational per se. You can have real in-depth technical reviews. So you really go down to the routers, to the systems, to the firewalls and really check how they are locked down. Really check all the routers, the parameters, et cetera, et cetera. Okay. Okay, thank you. I'm coming down to the end of my presentation. Here I want to give you some examples where organizational meets technical. It's still relatively speaking high level because of the time constraints, but I just want to give you some examples how it's interrelated. Let's say that the corporate security policy says, okay, we support accountability principle. In other words, we want to make sure that we can trace every action back to a unique individual or a unique entity because it doesn't have to be a human being. Then you say, okay, because you have the accountability principle very high level, the access control policy says, we want to use strong authentication. And the standard we're using in our organization is we are going for tokens. Another example is let's say that the corporate security policy says, information across untrusted network should be protected. Okay. Then the crypto coffee policy should say something like, we go for triple desk, 128, and three different keys. And the guideline is we try to use hardware encryptors. It's not a standard because a guideline is a recommendation. If you cannot have to write hardware encryptors because of a financial constraint, okay, maybe we should look at IPSec as an example. This is a more detailed example. Let's say that you have a business process electronic transactions and there is a high need for integrity and normal predation. The defined risks are, okay, we are afraid of unauthorized change and we are afraid of denial of sending. Okay, then the standard says in order to avoid this, we should use digital signatures. And the crypto coffee policy says, okay, we are going to use a normal key length of 1,024 bits. By the way, is this the only solution for this problem? No. I can do normal predation without any photography. How? Be creative, be simple. Why? Why don't we agree on the fact when you send me a transaction, give me a call and just summarize the transaction and I will say, okay, I agree on this or no. Or like you do in the dealing room in banks, when you place an order in the dealing room, they record your orders. You know this because they want to make a difference between did you say 1 million or 1 billion? Okay, so the normal predation part has nothing to do with photography but has to do with voice recording. So be creative. Okay, last slide. Will you find some useful links? That you can track down. Especially I think the last one is an interesting one. Who of you are security programmers or develop security components or whatever? One, two, three, okay. Are you familiar with the capability maturity model? Yeah, okay. They thought about the capability maturity model from a security point of view. So the security software engineering group, SSA developed a CMM model specifically for security. It's interesting to see. Okay. Some useful books. Well, you can read it for yourself. I would recommend especially the first four because it gives you a good background. By the way, you can also find a lot of info on the internet but these books summarize it very well. If you have to write policies for your company and you don't want to reinvent the wheel and trust me, you don't want to buy the book of Christian Ruth. It's expensive but it's about, I think, thousand pages full of policies and examples that you just can use. Make sure that you fine tune it to your own organization. I mean, there are so many information out there. Use it. Pay attention to the copyright, please. Okay, instant response. Unlimited. This is just a few examples. Okay. If you really have nothing to do really nothing to do then I suggest you read those standards. For the management, the first one is especially important. The ISO technical report 1-335 because this describes in management terms like, say, security for dummies these describe in management terms what security is all about. It's an ISO norm so it's internationally recognized. It's very interesting. I think this is the end of my discussion. Talk. Are there any questions that you want to raise? Yes, sir. The presentation is on the city including some additional material as well. Do you want to have it? No, I'll send it to you. Because I cannot put it on the city anymore. Sorry. Okay, I can do that. Other questions? Okay, I did what was very boring or it was understandable. I leave it up to you. Thank you very much for your time. I have to say something, I think. Okay, the next speaker. What's this? By the way, this talk has been taped on video for a while now. I'm very tired. That's something that I have to say. And please announce the following. Okay, the next session is at one o'clock. It's in this room and it is watching. Yeah, I'm just following orders here. Okay, what's the day? Okay, the next session is the Hacker Nation by Simple Nomad. Again, thank you very much for your time today.