 Today, anyway, we're going to talk about security management, particularly in the context of tracker managers. So yeah, maybe just before we get started, a little bit of local news. I live in Ireland and we recently had a pretty major attack on our health system, right? Our health system is managed by a health service executive and there was a cyber attack on a system three weeks ago. Apparently, the attack vector was through somebody's desktop computer, clicked on a link, which was the wrong link to click on, and that was obviously a socially engineered attack, which caused all kinds of havoc to break loose. A lot of sensitive data was accessed, probably being copied, possibly being made, well, some of it we know has been made available on the internet. HEC has encrypted all the data, look at the ransom, it's what they call a ransomware attack, to be in the biggest cyber attack in the history of the state. Lots of really essential services remain disrupted three weeks later, blood tests take ages to process, radiography tests. Normal outpatient appointments have been cancelled. The eventual cost they reckon for fixing all of this is being estimated as something well over 100 million euro. So yeah, it's probably a scale of disaster that's maybe a bit more than what you might expect with your little tracker implementation, but it's an indication really of how bad things can be. And I hate starting security presentations with kind of scare tactics. There's often the security consultants do that, right? They try to terrify the life out of you, and then tap you for lots of consultancy money. But a couple of really interesting lessons out of what's happened here in Ireland, and one of them being that we have a national cyber security centre, a director post for that centre hasn't been filled for the last three, four years. And partly that's because the salary offered by government is not considered to be significantly attractive for a proper security officer. Probably it wasn't taken seriously enough that you need such a person. Anyway, as you can see the costs today are enormous. Anyway, we'll just keep that little bit of news in our heads as we go through the rest of the presentation. What are you thinking in terms of outcomes for today? I start with what we're not going to do. What I'm not going to do is to talk about kind of detailed instructions, how you set about securing your system, how to best secure your database, how best to secure your Tomcat, all those kind of things. That's kind of detail. It's the kind of stuff that we do touch on more in the server academy. But also it's a different kind of audience. The point of being a security manager is not that you know how to do all of that stuff. It's so that you have a way of ensuring that all of that stuff is being done. So yeah, a security academy at some point would be a great idea, but we only have an hour, so yeah, we're not going to go into those kind of details. What I want you to come away with, I guess, is an understanding of what we mean by an information security management system, what it is, and what kind of tools can managers use to take ownership of the sort of risks and security concerns related to their tracker implementation. So that's kind of the level we're pitching it at. If you're looking for lots of technical detail, you might be a bit disappointed. So what's the problem? Well, I mean, I've been dealing with DHS2 aggregate systems for well over a decade now. Tracker systems change the parameters a little bit. Tracker systems, by their nature, tend to collect sensitive data, valuable data. Talking about valuable data here in the sense of, if you think there's a replacement value, for example, you think of its use value. If you lose patient data, it has, it has, patient data obviously has an intrinsic value that's more than just the dollar cost on it. So it raises all the issues which are classically the concern of security, confidentiality, integrity and availability. That's the CIA, right, the three pillars of security, if you like, anything which has to do with any one of those three generally falls under the ambit of security management. And I probably don't need to tell you, particularly having looked at previous slide, but security compromises can have quite serious consequences, lack of availability of the system can affect service delivery, particularly if you've got a transactional kind of system which is dealing with point of care. If you have data loss or corruption, that can result in you losing your job or going to jail, depending what the law is, I mean, I know in India at least, in South Africa at least, the law as it stands is that if you can't demonstrate that you have a reasonable system in place to have prevented this thing happening, then yes, you are quite possibly going to end up doing some jail time. Recovery from compromise can be extremely costly. And we've seen that with the example from Ireland with the HSE thing. When I often wonder about that, I don't know how much the ransomware hackers were asking, but it might have been less than a hundred million that might have been better off paying the hackers. Either way, it's messy, it's ugly, and it's complicated, and it's expensive. Nobody wants to find themselves in that situation. I've seen a number of DHS2 systems over the years get themselves into these kind of problems and that it's always a mess. So as a manager, you care about all of these things, right, in general. You might not have the technical skills or the tools to manage the risk, but you generally, if you don't, you should. But I think of course, the manager cares about security, partly because they have the patient's interest at heart, the subject's interest at heart, and also partly because they have some liability. So nobody's going to put you in jail usually if you can demonstrate, right? If you can demonstrate that you have done a reasonable job at mitigating whatever risks that you've identified or attempted to manage, but how do you demonstrate? Because demonstrating good practice is an important part of good practice. Now most of us, and this includes DHS2 developers, but also DHS2 implementers, system owners, by and large I think are well-intentioned and generally will always make a best effort, will do whatever they can to implement and improve their security practice. The challenge for managers is to ensure that these kind of good intentions that apparently exist are formalized into a set of practices, set of tools which can be checked and validated and improved on an ongoing basis. And that is really what we call making a security management plan of implementing an information security management system. It's not a piece of software, it's not a program that you run like Tracker. I mean there is software that you can get which helps with some of these things, but mostly it's not about the software. It's a plan that allows you as managers that don't know the details of how to harden SSH access to your servers or whatever it might be, but give you the tools to help you ensure that the people who are supposed to be doing these things are actually doing them. The well-known standards around security management is something called ISO 27000, well ISO 27000, in fact it's a family of standards, ISO 27001, 2002, etc. I'm going to focus here mostly on the very general aspects of security management which mostly covered in ISO 27001, but there are particular sector specific standards which relate to for example personal identifiable information kept in the cloud, particular domain specific around health records, etc. That's all great to get into, but I think everybody should have the basics of what's talked about in essentially the ISO 27001, what it means to create a security management plan of a security management system. You can't really argue that you're serious about security. I mean you ask, I don't think anybody I've asked who's implementing Tracker, are you guys serious about security? Oh yeah, we're very serious about security. So I say, well what's your plan? Well we don't actually have one. I think that's your first hurdle to get over, right? You can't be serious about security without having a security plan, a security management plan. How do you get there? Well, typically it's a long road, right? And a lot of organizations don't have a security management plan, partly because for some it's just a new concept. They've never really heard of it. For others it all just sounds much too complicated or too expensive or requires all kinds of skills that they simply don't have. None of those are really good reasons for not having a security plan, even if you're not the world's greatest security expert. You're still the manager, you still own the risk, you're still going to be liable for where things go wrong. So it's really important even if you're starting really simple to create a plan, even if it's a simple one, on the understanding that once you have a plan then you can improve it, right? You can't improve it till you have it. Yes, you grow with it as you increase your learning, your experience using it. It's actually possible for any tracker system manager to have a security plan. They will vary in levels of sophistication. But how do you set about it? Well, generally speaking, if you follow methodologies like what you find in ISO 27000 and pretty much most other security standards, there's really three important steps. The first one is to create a high-level executive security statement. I talk about this in many other academies in more detail, but a security statement is it's a one or two page maximum. One page is better, right? Because this is really your executive security statement. Having such a thing does three things, I think. It illustrates that you've got somebody in senior management who is concerned about security, right? Because your security statement is going to be signed by as high a person up as you can get to sign it. It also gives a bit of mandate to the person you've got to appoint to manage your security. And also it outlines your basic posture, your approach, your principles around what you are stating is important to you regarding security. So that's a first step. Doing so, and typically the way I've done this working with countries is it takes about an afternoon's work. You get sort of five, six, seven people who are important stakeholders in the system and you hammer it out. The kind of things you need to have in it, really important thing to start off with is the scope. You could be making a security statement for the whole Ministry of Health. That's obviously a much more complicated exercise. You could be making a security statement for just your DHS2 tracker system that you happen to be running. Whatever it might be, you have to define the scope in advance because everything else will follow them from that scope. The second step which is crucial is you need to appoint or anoint the role of a security manager. You've seen from the cyber attack that we had in Ireland, one of the weaknesses that the system in Ireland showed in general was a lack of leadership. Nobody took it seriously enough to appoint a senior person. And that's your situation as well regarding being serious about security on your tracker. Often you might not have the luxury of appointing somebody, but then you need to take somebody on your team. And I often say, rather than appoint to anoint, you're going to take that person and put it as part of their job description, their key performance indicators. You are the person responsible for managing security. The third step I would say is then you just put a standing agenda item. Most implementations will have technical working group meetings happen typically on a monthly kind of cycle. Useful thing to do is to have a standing agenda item on there for security. Now it could be for one month you say any security reports or concerns or issues this month to talk about, and there may be very little. Other times there may be much more. But the point about having the way a security management system works is it's a process. It's an ongoing thing. It's a cycle that you have to get into. It's not a one-off event. So it's my view anyway, and I'm opinionated on these things. I know that even if you're not an expert on ISO 27000, even if you're not a certified security consultant, it's possible to take three steps and by using those three steps and then enhancing your practice as you go along to start to proactively manage your security to take ownership of the kind of risks that you live with. Typically those three steps are just three steps which start a long road ahead. There are many other tasks which emerge as a result of making your security statement. You're going to claim all sorts of things which then you have the responsibility to start implementing. So many steps ahead. If organizations that go for ISO 27000 certification, for example, I mean that process can take a year or two. It's always about waking up in the morning and doing something a little bit every day. So today is a little bit better than it was yesterday. It's not about perfection. You're never going to have perfect security. You're never going to have a perfect security management system. Best you can do is to hope that today's system is better than it was yesterday. And the only way you do that is to have some kind of a governance loop, some regular routine activities which ensure that the process moves along. So how do you set about making an executive summary? Typically this thing is it's an afternoon's work. Typically you're going to sit around with the relevant stakeholders. They will include who they include. It depends widely on what the nature of your implementation is. But I mean they might include program managers, they might include system administrators, they might include someone from the National Data Center. And you hammer out your plan. As I said, the first part of your security plan must indicate what's the scope of it. So in the very simplest case, smallest plan, if you like, you're just going to talk about your DHS2 tracker implementation. And often that's all you can do because you might not have a mandate to make a security plan for the whole of government. That's somebody else's mandate. But your particular responsibility is your tracker system. Then you make a plan around that. If you're responsible for a number of DHS2 systems, you might incorporate the scope of all your DHS2 systems into your security plan scope. Could be all the information systems under your department, whatever it is. However you decide to do that, being explicit about it up front is important. What you typically then will find in an executive summary is some kind of principles. Some of the reasons why you have such a thing. The typical wording that I've seen working with a few of these things, you might say something. Your department's got custodianship of the citizen data stored on its systems. As a result of that, you're committed to ensuring the confidentiality, integrity, availability, etc. of these systems. You might here also draw attention to any applicable law acts of parliament or national ICT policy that exists. Very often when I ask implementers, what's the law that governs what you're doing here? What law are you going to potentially break? Or what are you obliged to do? What are your legal obligations? That question often draws a blank. People haven't done their due diligence around that. Often they say, well, there's none that they know of. But that doesn't mean that there is none. So an important part, I guess, of planning of a tracker implementation is do your research around, well, what's the applicable law? What's the national ICT policy which might affect what you're doing? And mention that in your executive summary. Often government might have nowadays there's a lot of work going into government cyber security policies. Some of that might also be applicable to systems which you are trying to set up and host. Then how are you going to do that? You're going to do that basically by developing and maintaining some kind of information security management system. And you might state tonight strongly push this out there. We'll talk more about this later. But all of your systems will be subject to audits annually, twice annually, whatever it might be. So those are typical starting points of your executive summary. And remember you're limited to a page. If you push it over two pages, not two, but if you go beyond two pages, then it's too long. You will have a section which talks about what are the actions. Well, what is it that as part of your security plan you're actually going to do? There's a couple of pointers I've put on here, the kind of things that you would do. The most important one being you're going to appoint or a security manager. You're going to create, maintain a tested backup plan. You're going to have routines around system upgrades. You're going to ensure installations conform to some agreed standards or benchmarks, etc. There are other tooling which typically associated with security management like risk register is a really useful thing to maintain. People familiar with project management would know a bit about risk registers from that aspect. From the security management perspective, it's also a really useful instrument to keep. Information Asset Register, it sounds like a really simple thing. And often if you're dealing with very small systems, it seems a bit over the top, but it actually can be quite important. Information Assets range from what are your hardware assets. These can include things like Android devices. They include things like servers. But also then you get down to your information assets. What information have you got on your system? What data are you actually collecting about patients, for example? There's many times I've gone into an environment and looked at a system. I was actually looking at one last week where there was very weak understanding of the information assets to the extent that there was a database system that was actually replicating the tracker database that the current maintainers didn't even know was happening. So there's a very weak understanding of what the assets were. So the best way to understand your assets is to gather them all up and put them on a spreadsheet. Starting from the hardware layers, things like keys, passwords, those are all assets. All the things that are important to you, if they get lost or if they get broken or if they get stolen. Going to your asset register. An incident or a change register is kind of an important thing. When something happens, when something happens, record it. That's important for people who come to the system afterwards and try to understand the current state of it. It's important as a learning, particularly if you've had a security compromise, then one of the only good things about a security compromise is that it's a great learning experience. It's often a very painful learning experience. But keeping an incident register or register related to any changes in the system as well is an important part of it. And those are the kind of actions or commitments that you might make in your executive summary. Then probably the most important thing that your executive summary does is it reinforces a mandate. You want to have your summary signed by as high an authority as you can in your organization. It's got to be coming from the boss. If security is not coming from the boss, then nobody's going to take it seriously. When you appoint this person as your security manager who might not be particularly trained as a security manager, the really important thing is you've got to try to reinforce this person's authority. And part of the way you do that is make sure that your executive summary is coming from the top. Right, so if we had more time and it's a nice exercise to do, you could kind of do it over an hour. You could go through the process of making a sample summary as a group. We don't have the luxury of that hour, unfortunately. So I'm just going to leave a little pointer here of the kind of things that might be in it. I've given you some links to some resources at the end of the presentation, which give you a couple of examples of this kind of thing. The reason why it's good to be just a page is you want everybody to read it. This is a document people should be familiar with. There are so many security SOPs and policies that I've seen, which are big thick piles of documents like that, which sit buried in a draw somewhere gathering dust. Your security executive summary, you want to have something that's agile, you can stick it on the wall in the room next to the picture of the president. People come in, they can see it. It's a short document which outlines what it is that's important to you, what it is you aim to do about that, who it is that you've appointed to do that, and how are you going to go about it? Okay, so let's assume that you have that. Next difficult thing is what about this security manager? Well, I mean, the truth is security manager is a tough job. It's one of those things that you get very little reward for. You get a lot of you get a lot of stick. It's not really a hugely technical job surprisingly enough. It's much more job that requires very good organization and communication skills. It's important to emphasize that it is a management job, right? You know, a lot of implementations I've talked to people about security and they'll say, well, who's responsible for your security? And they'll go and dig some grease monkey guy out from the basement. Yeah, he's the system administrator. He does all our security, and then they send him back down to the basement again. Yeah, that's not a security manager, right? The security manager is somebody who's part of the senior leadership of your tracker project. Don't take the poor lonely system admin and say he's my security guy. It's not fair on him. It also means you're not really taking ownership of security as a manager. And you're not providing the guidance and governance and and and parameters in which your system administrators and and technical implementers and the like are able to work with him. Now, there are trained professionals who do this as a career, right? You're your your chief information security officer is standard roles and information systems. Some of these guys can be very good. They also tend to be very expensive. It might not be. In fact, it's rare that I've seen in the projects that people have had the luxury to go about hiring a senior security professional. And as I said, I think on an earlier slide, the fact that you don't have the world's leading security professional on your project doesn't mean that you shouldn't be implementing a security management system. It just means that your security management system might be a little bit simple to start with. It might not be a perfect one. But it's one that you can grow and improve over time. As I said, already above, it doesn't require huge technical details, detailed technical skills. That's not the purpose of it. It's it's the technical people's job to do the technical work. And it's the security manager's job to ensure that they are doing what everybody has agreed that they should be doing. We talk a bit more about some of the ways of ensuring that. When you look at security management, kind of wrong. Sorry, this is a horrible slide. It needs to be broken up into about 20 different slides. But just to give you a bit of flavor, I guess, I tend to think of security around tracker and DHIS is in three distinct layers. I guess, I mean, you can make different models, you can probably do it in four layers or two layers. But this is the three that works for me. The top layer, I think of as the organizational layer. And this is the layer which is generally the most neglected, hardly enough, the most important layer. What are the organizational aspects of security? And they include things like, do you have a security manager? Do you have a plan? Do you have data sharing agreements with partners? Do you have non disclosure agreement templates? This is something that's come up quite recently. A lot of us from the University of Oslo end up with our fingers into into other people's systems. And I always try when people ask me to go and have a look at their system. Give me something to sign first, right? I should be signing a non disclosure agreement. And typically the templates are not ready for that. I think we can do probably a bit more work from the UIO side to provide a couple of templates around that. But these are the kind of organizational things. If you're doing an audit and you start at the organizational layer, these are the kind of questions I would be asking you. We tick all these things off and you're going to get a score at the end. When you were making your plan, right, for your budget, I heard somebody talk about budget earlier today. When you're making your plan, have you included in your plan that you're going to need to do an annual audit? And you might have to pay somebody to do that. Have you made security a part of all your training materials? This is a really easy thing to do. And it's not done, I think, just because people are not maybe, it was a question of awareness or consciousness. I like to think of security consciousness. Every time you make training material, every time you make a workshop, every time you do a training in the field, all of these are opportunities to disseminate or radiate security information. So it doesn't matter what level, if you're training users, then, for example, part of your training for data entry users is a little bit on security, right? Don't share your password. Don't go clicking on links like that poor fella did in Dublin three weeks ago. It doesn't matter what level you're working at. There's always going to be some security considerations that you can fit in. And I would just think of it as making it a habit. When you're having meetings, have a security item on the agenda. When you're creating documentation, have a little section on security. The section might be short. There's not many security considerations in this particular piece of work, or it might be quite long, but just make a habit of having it there. Anyway, those are going to organisational concerns, I guess. We could probably separate that out more with training or security dissemination as a separate layout. Others relate to the application itself. What are you doing with your DHS2 tracker? One of the first questions to ask is how much information are you collecting and do you really need it? You need to think in terms of what happens when I lose all of this or somebody else gets access to it. How bad would that be? Did I really need to collect all that information to start with? Generally speaking, with a lot of information systems, there is a tendency to collect more than you need. Partly, it's an adjusting time approach rather than adjusting, no, adjusting case approach rather than adjusting time approach. You're going to collect this data. You don't have any immediate need for it, but you might in the future, so better collect it anyway. That can lead you down a fairly dangerous path because you end up collecting far too much data, which then increases your responsibility enormously in terms of your management of it. In terms of your tracker, you need to ask questions around, for example, are there roles that you define sufficiently granular to reinforce the need to know access controls that you want to have? It's not sufficient to make everybody a super user and everybody else a data entry user, right? There's a granularity of roles. We'll talk a little bit about user management in a subsequent slide, but an important question is to ask how are users added to the system and more importantly, possibly, is how are they removed from the system? How is your metadata managed, right? I mean, when you make changes and updates and add attributes to things or remove attributes, what's the processes around that? Those are all application specific concerns around security. And the third layer, and this is the one that people think, well, this is what security is, is about the technology. I hate to push this one too much, even though this is the one I probably know most about, right? It's about securing up servers and things like that, but there obviously is in the technological aspects of security. And a lot of that come down to things like, do your server systems conform to an agreed standard? From a security manager perspective, you don't need to know too much about service. What you do need to know is, well, what standard have we agreed to, right? And that typically means writing down, these are the kind of controls that we're going to have on the server. This is how that might compare with some international standard. I can show you some samples later. And from a manager's perspective, what you want to know is that the technical guy has produced these documents. This is what they do. Because the great thing about that means you get some stage, you can audit that and make sure they do what they say they're doing. Does the backup plan work? These are important questions that you wouldn't think you have to ask, but you do. I'd say 90% of security issues I've dealt with with DHS two over the years has got to do with data loss. Somebody has done an upgrade and not done the backup before they did the upgrade because they assumed that the backup routine was running properly. Then they went to try to roll it back and found that there was no data in the backup on the day or the backup was corrupted. So then they were stuck, they were not able to roll it back. These kind of things happen much more frequently than they should. So yeah, probably the biggest security concern is kind of less to do with hackers from Russia and America and Brazil or wherever it is, the Chinese, wherever they're coming from. It's got much more to do with people shooting themselves in the foot. Do you have sufficient system monitoring in place? This is something where monitoring and alerting is frequently an area where our implementations are often weaker than they should be. Importantly, what about device management? I focus a little bit on the server side. I think you had some talk from Jaime late last week. He probably would have told you quite a bit about androids and the kind of challenges that they bring. In the sort of big hacks that I've seen over the last three years in VHS, some of these have been simply users hackers, should I say, one case was from China, other case was from France. Simply entering the system using SSH using a username and password, which means they simply got hold of that username and password from somewhere. The most likely being from a compromised device could be, in one case I know, somebody had set up a new user on the system and sent the password to them, probably on a mobile phone. And somehow or other, one or other of those devices were compromised. But literally within hours, the system was invaded. The timing is interesting. Often the timing happens so that's local time, wherever the system happens to be, you'll find you get attacked at about one o'clock in the morning when at least human systems are not in place. Anyway, the important thing about this slide is not the detail. It's the fact that you need to organize your approach to what your security concerns are. I think it's in three layers. We could model it differently, as I said. Look at the organizational stuff. First, that's the most important stuff. Don't start with technological stuff. That follows afterwards. Look at your practice around how you're configuring your application and how you're using your application. And look at issues relating to the technology that keeps your servers and systems running. That brings us nicely to our word of the day. Donkeys have layers. You need to remember that because I think at some stage somebody's going to ask you. As Martin will tell you, that's a famous quote from the movie Shrek. Donkeys have layers. Okay. That's how are we on time? Let me just quickly. I should be able to make a phone out. It's 10.45, Bob. Sorry? It's 10.45 when we haven't held on 15. That's good. I just wanted to make sure that we were still so we can half an hour ago. I'm stuck on Donkeys' layers. I need to move to the next slide. All right. I thought about doing a few questions on Mentimeter just as a little bit of a break for listening to me. You've heard a little bit about me talking about what security plans are and having a security manager on the backup plan. I think it would be interesting just for the sake of all of us to get an idea of where we all are as a group around these things. I think mostly what we have work to do. Now, I have Alice to make me some Mentimeter questions, fortunately this, but I don't have the link to it. Yeah. Let me share my screen. Oh, wonderful, Alice. You are there. Yes, I am. My guardian angel. Could you please stop sharing? Yeah, perfect. Thank you. You stopped me. The purpose of these questions is, let's not spend more than a minute or two on it. I just want to get a quick couple of answers checked in there and then let's pause and I'll give you an opportunity for one or two questions and then I'm going to move on to my final slides. Yeah, so for now we have four participants on Mentimeter. So please go on menti.com and you can use this code. Sorry, 411-61999. Now, obviously some of these questions may not be relevant to some people. They're only really relevant, I suppose, if you are managing a tracker application. But I think many of the people in this group, that's exactly what they're doing. That's the target audience for the questions anyway. Yeah. There's a lot of hearts. What does that mean? Okay, so this, all right, so I'm just looking at the... Okay, we have 15 participants. 16 more. Alice, can you show us the answers as they're coming in while you're sharing your screen? Yes, it will show. All I can see is hearts. Yeah, because this is how I know that participants are on Menti. Okay, we have like now we have 20. So let's start question one. That's good enough to get us out. Yeah. So question one, do you have a security plan for tracker? Yes, no. Okay, it's great to see the 36%. I hope for the remaining 65% or 67% that it's not going to intimidate you now to not make a security plan. I think it's kind of as expected. It's opening up visibility on a gap in a lot of implementations. That's good, Alice. Can we move to the next question? Yes, numbers are increasing. More plans are being made as we were talking. Do you have someone on your team who is responsible for security? Yes, no. No, we seem to be a bit divided again on this one. So this is an interesting question, Bob. For me, I think this is what I've seen is some of the security issues or the backup kind of results in I thought someone else was in charge of that. And then they come back and said, I thought you were in charge of that. So it's kind of like this, not having a strong governance of who's responsible. Yeah, okay. I often say the reason why the backups don't work or there are no backups in 90% of cases because it's not been put somewhere in somebody's key performance indicators in their job description. And that's a huge risk, right? And yeah, it's also one of those things that when things get tough and when you have some kind of a crisis and then people start pointing fingers and flinging muck at one another. One of the first questions you're going to be asked as a manager is exactly this. Who is it on your team responsible for security? If you throw your hands in the air, then yeah, that's when you're in a little bit of trouble. I like to think a lot about security is less about securing patients' data and things like that. It's also about protecting yourself right from liability. Any other comments on that? We move on to the next question. Do you have a documented backup plan? Here we move. I'm imagining we're going to find the same sort of 50% split that a lot of people have a backup plan, but they won't have written it down. And I think you have to account for a turnover. You might have had a backup plan, but then that person left and has it been in the nets in a drawer. So are you continually having these conversations and being sure it's up to date? Yeah, again, the kind of, I mean, it's interesting if you lay a relationship between this question and the first question. Do you have a security management plan? Or do you have a security plan? Roughly 60% said they didn't, and it's, I suspect roughly the same 60% who also then don't have a documented backup plan. So one of the ways of making sure that you have a documented backup plan is to have some sort of security plan in place. And then these things become deliverables of that plan. Alice, let's move along. Because there could be people answering no, because they're not managing systems at all. I hope that's not the case. I hope those people just don't answer. How often do you get audited? Here's a good question. That was a good question. It's a question. Who's doing the auditing, Bob? Is it an outsider? Who's it? Well, you haven't been specific on this slide. There's many kinds of audits, right? You can do internal audits. You can have, often in government departments in particular, you're subject to the Attorney General. So the Attorney General, or not the Attorney, the Auditor General. So the Auditor General will impose an audit on all government systems annually. I think that happens in South Africa, in Ghana, in India probably. So in some cases, it can be internal government audits. In some cases, you reach out and you hire a security consultant, get KPMG, or wherever it might be, to come in and do an audit. You can do it peer-to-peer. I'm giving away all my stuff. I've got a slide about this. Yeah, it can mean different things. Who does it? I mean, I've done it quite a few times, believe it or not. Country systems. Countries have asked me to come in and do a quick audit on their system, and I've done probably three or four places like that. But I wouldn't describe what I do as a particularly rigorous audit for reasons which I'll be described later. But what I try and do is I have kind of one of these, the top 10 concerns, and I'll just go through and see how people score against the top 10 concerns. So yeah, many ways to get an audit. And as we can see, the concern, I guess, from the answers to that mintimeter that we just saw is that there are many systems out there which never have an eye on them, an external kind of eye on them ever at all. Those are the big risk systems because the manager, basically, you've got a technical implementer, a system administrator, or whatever it might be, some technical person who you pay, or maybe somebody else even pays, and you expect that he's going to do whatever it is that he's supposed to do. But you have no way of checking that he's actually doing that. Anyway, now we'll talk a little bit about audits, some sequence, but with just a little bit to get a bit of, if anybody has any comment on this other than, well, I would say other than Kim, you're allowed another comment, but if anybody else has any comment, maybe chime in now before I get stuck into my next slide. Last chance for a comment. So there's things happening in the chat. Now, the comments are questions. No, let's just stuff around it in this room. If no one wants to ask me anything about what we've talked about so far, I'll press on. Okay, I'm back sharing again. Okay, I thought to opportunity just talk about a few things at a slightly lower level, not going very deep. Just depending on how time was going, two little issues, two little issues that I just like some reference to, just because I think they're neglected, generally, is about backups. I mean, it talks a lot about backups, but probably when you're making a backup plan, right, one of the most important things to make sure is your backups have to be automated, right, there's got to be an automated job that's running. That's going to take your backup on an agreed schedule once a day, twice a day, whatever it might be, take a snapshot every 15 minutes. I mean, there are various ways you can do it. But if I ask an implementation, how did your backups work? And somebody says, well, yeah, there's this guy, and he will log in and do a PG dump from the database and store it on his laptop. And he does that every day. Then basically, I don't believe you have a backup plan. It's too dependent on whether the guy actually does that or not. And even whether what he's doing is a good thing to be doing at all. But yeah, if you're going to make a backup plan, you're going to have it automated. If it's not an automated plan, it's not a plan. The other thing I would draw attention to, just because I see it all the time, is be really careful how you handle backups. Think about how you handle backups. Often, you put a huge amount of effort into securing your database. I've seen people with really well set up databases and good access controls tucked away, hidden on local network or in a container inaccessible to the world. But then they make backups and leave them lying around in their home directory, right? Worse still, they leave them lying around on their laptops. And worse still, I see people exchanging them by Gmail or Dropbox or whatever it might be. So part of when you're writing down stuff around your backup plan, don't just think about how your backups get taken, but also think about what are your processes and policies and procedures about how you handle backups. A lot of information security is not that different to physical security. You talk to people who work in the world of physical security. Think of it with office-related stuff. You always talk about having a clean desk. As a security manager in particular, if I can walk up to your desk and I see it's full of a big pile of papers, that's the way mine usually is, then you are not operating a clean ship. You're not having a very secure desk. You can have all kinds of bits of paper lying around on that desk that somebody may just walk by and pick up one day and you wouldn't even notice. It's the same with server rooms. I generally try to avoid having chairs and things in server rooms. You don't want people sitting in there eating their lunch. You want to just walk into that room, look around, it should be completely clean. If you see anything odd, you should be able to notice it because it's out of place. That's the same thing to do with users' home directories on systems. If you see things lying around in home directories, the chances are that you've got some stuff exposed that shouldn't be exposed. I think I've mentioned before, but just taking backups is an act of faith to really know that you have backups. You also need to restore them from time to time to know what backups that you're taking are good. There's lots of ways you can think about doing this. It can be part of, ideally, it's part of your automated backup routine. You back it up, you push it outside, and then you restore it and generate an alert if it doesn't restore. But even at a more pedestrian, human-driven level, it can be part of somebody's job description. Once a week, take a sample of the backups for this week and restore it. That way, at least, you know that the backups that you think you have, you probably actually do have. A lot of mixed opinions, particularly when you talk about long-term archiving and storing around encryption, it can be a good idea to encrypt backups. It's not very difficult to do. It's quite easy to make a script and make the backup and encrypt it simultaneously. So the backup doesn't actually appear on the disk in an unencrypted form. Really important thing about doing anything with encryption is, this comes back to asset management. I told you, lose the key. We have had a case, only a year or two back now. I don't want to name and shame. I won't talk about which country this happened in, but they're very, very pleased with themselves because they implemented Tracker and they did encrypted backups on their Tracker system. But a year later, they realized that the key that they had for their encrypted backups had been changed to the key that they currently have. That's because someone was using a Mac, I think, and they'd taken the key and dragged it and dropped it somewhere. They ended up, in fact, with a shortcut to the key. And that shortcut then became used for encrypting and decrypting the backups. So yeah, poor key management. So it is something to be, there are a lot of benefits of encrypting your backups. It makes it easier to archive them and store them somewhere. The danger is, particularly with long-term storage, is when you go back to find this stuff in 20 years' time, will you ever find the key? Anyway, there's a few thoughts on backups, people making backup plans. Another slightly random one, some thoughts about users. This is just because I see this all the time. I think it might be something worth thinking about. Often there are processes to how to use them. A new person joins the team. A new clinic gets added to the scope of the project. A new person joins the clinic. We've got processes around creating their user accounts. Sometimes those processes are not great and need some improvement. But usually, or often, there's some process around. What there rarely is, is processes around what happened when they leave. There are very few places I've seen which have got robust processes to deal with removing users or deactivating them. So it's really not unusual. I've looked at quite a few very long-running systems that have been running for 10 years or so. If you look at it, it's not uncommon to find 30% of user accounts who are either dead or they've left the service. Now, there's potentially problems with that, as you might realize. It's a particular problem when the dead users start logging in. When you see all the dead users logging in, then it shows that your security, your access management has gone out of control. So it's something that I would ask them to think about. There's ways of approaching this. Ideally, deactivating users requires a close coordination with HR. If you're working with civil service, they've worked in civil service for many years. You know what it's like. Getting in is generally easy enough. They give you a whole lot of bits of paper that you have to sign, and you just sign them without reading them, usually. And you might get a key if you have a physical office to give you a key to the office and a key to the cupboard. And then when you're leaving, you have to go through a demobilization process. You need to hand over your keys, give back your library books, and whatever. And you don't get paid your last month's salary until you've done all of that. So there are HR processes around leaving, but we often are not that organized that we link our information systems into these HR processes. That's ideally where it should happen. When somebody leaves, dies, or fired, or whatever it might be, then they need to be deactivated. It's not easy to do it. So one of the things I would advise people to do is to have a process in place to regularly audit your users. And regularly auditing your users when you've got 10,000 users is not an easy thing. Nobody knows all these 10,000 people, whether they've died or not. Doing it locally is good. It can be part of the job of your district manager, for example, to get the list of all the users for these districts. And each month sign off on that. So yeah, these people do exist, right? Because they generally will know. They have higher probability of knowing the individuals. So yeah, some kind of process in place for auditing your users. Otherwise, you're going to end up with lots of dead users on your system. And then your dead users, and when they start logging in, it means that you've got people in who you don't want to have in. Be careful with accounts, creative partners. I put partners in inverted commas. Partners can be many things, right? But it's something I've seen quite a lot done again recently. Often partners, funding partners, support partners, whatever they might be, will ask to have access to your system and to your data. And before you enter into that kind of thing, but I know the pressure can sometimes be quite, quite heavy. You need to be have very clear data sharing agreements in place and acceptable use agreements. There's at least one country I know that they were having problems that their system was becoming unusable for about three, four hours every day. And after carefully trawling through the logs, what we discovered was that one of their partners based in the US somewhere was sucking all the data out of their database every 24 hours. And that was bringing the system down. So yeah, be careful if you're creating accounts for outside users. And this applies often when you talk about interoperability scenarios as well. It's really important to get the data sharing agreements in place, acceptable use agreements. And if people breach them, then they get kicked off. Okay, now we'll be on time. I've only got eight minutes, quickly. Some thoughts about audits. As an audit, it's different to a security report or a test. Like with software, you do penetration tests, for example. These things will just basically try to explore your system and find out things that are wrong with it. An audit is not so much about that. A good audit presupposes that you've got a list. You get audited against something and say, well, this is my security plan. These are the things that I say that we are doing as a part of my security plan. I'm just the manager. I don't know what these technical guys do, but this is what they say that they are doing. This is what we've agreed that they will do. And an audit goes and checks against those things. If you can afford it, get an external auditor. If you're in government, you might be fortunate enough to have an auditor general do the report, do the audit. I mean, sometimes these audits are not great and people complain about them saying they're not really asking relevant questions. They're assuming that we're all running Windows and it's all about desktops and not about servers. And yeah, sometimes this is true. Sometimes the audit controls that are used are often a bit old, but in almost all cases, I could say, even though they're painful and frustrating, there is useful outcomes that come from them regardless. I talked a little bit earlier. It's possible to perform, to organize peer-to-peer informal audits. If you've got a good relationship with your tracker implementation next door, you can agree to show them yours if you'll show them yours if they show them theirs or whatever it is. You can cast a second eye over one another's system. That can be a very valuable thing to do and not expensive. It requires having a level of trust. Sometimes, and from my perspective, and it depends largely on the demand and workload, we have been able to assist with doing brief audits of most common issues. I would say we're not really geared up to do it on a big scale. Well, thanks to budget form. I know that a lot of this academy has been about planning and budgeting. So from a security perspective, there are a few things that came to my mind. There's probably more. But yeah, consider your backup plan. Whatever backup plan you're going to have, it's going to have some cost associated with it. Often, people start off with, well, what do I need for my server? How much RAM do I need? How much CPU do I need? And they're thinking about, well, what do they need to run the HHS to? Your backup plan can also have cost associated with it. So think about that. Training. A lot of security is about training, ongoing training. Your security manager in particular, particularly if it's somebody who's been thrown into the job, ill-prepared, which is most likely what it will be, then you might want to budget in some training for your security manager. Also your technical team, the people who are working day in and day out, keeping your Linux systems going, they can benefit from some refresher courses and some professional development and stuff like that. There are security management activities themselves. And I mentioned one that I didn't actually put in here, but the very first one, creating a security plan, creating that executive summary note, that little one or two pages. Now, that's an exercise that involves possibly bringing a load of stakeholders together for an afternoon. There could be costs associated with doing that. If you have it in your plan, then you've got something to budget for it. Same thing is true as if you're doing risk assessment. If you're going to go through a process, and this is a valuable thing to do, I find every six months or so, get people together from a variety of perspectives, different stakeholders, and just go through and evaluate and identify risks associated with the system. That's it. Your risk register is a kind of document that drives a lot of practice. Then, yeah, we talked about the audit. If you're talking about audit, you might be talking about budgeting for an audit. So these are things to consider in your planning. Okay, so I'm just going to finish off here. A summary, if you like, of some axioms according to Bob, as you know, I'm a bit opinionated on these things. They're probably more, but here's six things that maybe you can take away with. The first is that you're not taking security seriously unless you can point to someone, senior, on your team, and say he's the security manager. That's the very first question you'll get asked. If you can't do that, then you can't say you're managing security. Being able to demonstrate good practice means you need to have a written plan that shows that. It doesn't have to be perfect. You can improve it. Security management is a process. It's not a one-off effort. Often people think, ah, well, I'll pay a bit of money, get in a security consultant, we'll do the security, and that's it done. It's not like that. Security is about about bringing in process to your system. Securing tracker, to my mind, it's not primarily a technical business. Obviously, there are a lot of technical aspects to it, but mostly it's about people. I think, in fact, when it comes down to it, all information security is about people. My fifth point, I guess, and this, I think this is important. One is you can outsource lots of things, and often it makes a lot of sense to outsource a lot of things. You may not be great at server management, so you outsource it to a software as a service provider or something to do. You might not be great at making security plans, so you might outsource some aspects of making your security plan, but you can't outsource your security management. Security management basically means this is you taking responsibility for the risks that you are. At my last point, it's a little bit like going to the dentist, right? Nobody likes it, sometimes it hurts, sometimes it hurts a lot, it's generally worth it, or it is good for you. That's my six bits of advice, I guess, for today. I don't really have time to take a couple of questions. A few links to two resources here. I would advise people to take a look at. One is the ISO 27000 free. This is a collection of free materials. I hope I have the right link there. It doesn't actually look right. I'm going to check that. Check back on this presentation in half an hour. Just make sure I have that link right there. The tool kit basically consists of a lot of Creative Commons licensed materials, lots and lots of information about how to make a security management system, what it is, how to make it work, a couple of templates, that kind of thing. The other thing, this is more for the technical folks. A site I find really useful is the CIS benchmarks. Where you can look up, okay, I'm using an NGINX proxy, or I'm using a Postgres database, I'm using a Ubuntu server. There are security hardening benchmarks that have been created for almost all of the kind of systems that we use. I find that they're useful as a starting point. You might not comply with everything on the benchmark, but if you want to start making your own benchmarks that you want somebody to audit you against, then having these things as a starting point is really useful. Okay, thanks. That's it from me, and if we have time, I'd love to hear any questions or feedback people might have. I think we go ahead and open the floor for questions. Please raise your hand if you have any questions. I think we're in the break as well. There's now 10, 15, so if people want to leave and go and have their cup of tea or something, I'll volunteer to sit around here for 15 minutes anyway during the break.