 Great, welcome everybody to this session on security and securing DHIS too. This will be a pretty high-level kind of overview session, particularly around the new processes that are being implemented by the DHS2 core team and what that means for implementations. There's obviously a huge depth of information that we could talk about when it comes to security and privacy and how to implement those in implementations, DHS2 servers as well as just user management processes in countries and in implementations that are running DHS2 servers. As Bob likes to remind us, that could be a whole weeklong session by itself and probably we should have one of those sessions at some point in the near future. So look forward to that, but this is just one hour, so we'll just do a high-level overview. I'm going to start with some security principles that are what we as the as the core group, particularly the security team that has been developed and formalized here at the core team are trying to embody and to evangelize in the community. So the first of those is robust formal and predictable security policies, sorry my videos in the way, processes. And this is particularly important so that you know what is going to happen when a vulnerability is detected in the DHS2 software or when something goes wrong, we know what to do and everyone in the community knows what will take place. And that goes along also with maximum transparency which is just like it sounds, trying to be as open and clear as possible about what happens in the process for addressing vulnerabilities or dealing with security issues and particularly with what happens after the vulnerability has been identified and fixed and disclosed going back and exposing or sharing the process that went into that, what we learned during that process and so on. I mentioned disclosure. This is something that's relatively new for the core team but we are working on developing a process for full and responsible disclosure of all vulnerabilities in the DHS2 software. So when something is discovered, a vulnerability is discovered in the software, we will address it, we will spend a fair amount of time trying to make sure that vulnerable implementations have time to upgrade before that disclosure. But the goal is to always disclose those vulnerabilities in a responsible way to the public so that they are fully available and readily accessible to everyone in the community. And the fourth principle here is to advocate for and to embody a strong security management culture. This is not only applicable to the DHS2 core team and the security team itself but also to all of the implementation teams and groups around the world that are building security practices on top of DHS2 software. So we hope to not only lead by example in that sense by building our own strong security management culture but also to advocate for the adoption of that security management culture in implementations. So we're going to talk about a few things today. We'll talk about what it entails when we say DHS2 security. There's a number of different pieces within that and we're going to focus mostly on software security today but we'll talk about what the other pieces are as well. We'll introduce the security team, what that means, who they are and what they do. One of the things that they do is vulnerability management which is a formalized process and a policy for how we deal with vulnerabilities when they are reported to the DHS2 core team or discovered by an implementation and shared with us how we go about triaging it, fixing it, disclosing it and we'll even we'll talk about how that actually has played out in practice in the last just a couple weeks. Then we will share a bit about what it looks like to secure DHS2 for a particular implementation. So this is on top of hardening the DHS2 core software to prevent intrinsic vulnerabilities in that software but also building the processes and the group of people and the policies on top of that software in implementations to be able to actually have secure implementations of DHS2. And then we'll see where we're going from here and how we look forward. So what does it mean to be security for DHS2? There are a number of components of this what we call DHS2 security and the one that we're going to focus most on today is software hardening. I'm not sure if that's exactly the right term but that's what I've been calling it and this deals with vulnerability management. So if there is a vulnerability in the software in the way the software has been built then that is something that could be fixed and hardened the software to protect against bad actors or hackers or people that are trying to do things that they shouldn't in a DHS2 system. And these are things that are basically functionalities of the DHS2 core software. It's not something that you build on top of it. We also talk a little bit about software security features. We've started to really lay these out on our new security website which I will introduce a little bit later as well. But these are things like user management, sharing settings, integrity checks, and data loss prevention. And those are all things that DHS2 can do in order to allow an implementation to implement secure practices to have fine grained privacy practices and control over their users and those types of things. Similarly data privacy practices is a little bit more than security which is who has access to what, but privacy is where data can go, who has access to it, how do we know who has accessed it and who has changed it. And this is particularly applicable to PII or personally identifiable information. In the case of tracker programs this is becoming more and more prevalent. And the final piece here is information security management and this is sort of the soft security practices which is the people around the DHS2 software and the processes that are built around it in order to have a culture of security. And security is much more than just software. It also is almost I would say more important to have the right people and the processes and knowledge of what's going on more than just having functionally secure software. And again all of these apply not only to the DHS2 core team but also to individual DHS2 implementations which Bob will talk about a little bit later. Next I'll introduce the security team. So DHS2 has had a security group or people that deal with security for quite a long time. But it hasn't had a formalized clearly defined team that focuses on this and is clearly the ones responsible for when a vulnerability comes in or something like that. And so we've recently created that official security team. It's got a well-known membership list which means that we know exactly who is on that team, who is responsible for what when a report comes in. And the initial focus of that team is on software security which is distinct from data privacy, distinct from software management practices that we are doing a bit of all of those. And what we're focusing on primarily in the initial focus at least with this security team is on the development process and prioritization of the core software, how we embed security into all the features that we build, how we manage and disclose vulnerabilities that are reported against the DHS2 software, and how we support and promote best practices for DHS2 implementations that are actually running production instances in the field. Again this doesn't mean that data privacy is less important than software security. I'll get into more about this a little bit later. Privacy is something that is addressed by the core team as well as DHS2 implementations around the world every day. But you can't really have a strong privacy if you don't have a foundation of secure software. If there are holes in your software that will leak information, it's very hard to build privacy practices on top of that. So the initial focus of the security team is to harden the software in order to build a foundation for very strong data privacy practices going forward. I'll talk a little bit now about the vulnerability management that we have started to implement here with that new security team. We've built a process, this is a rough kind of overview of that process, but this goes from the moment a vulnerability is reported to the moment it is disclosed to the public and all the steps that need to need to happen along the way, as well as gets into who's kind of responsible for each where we have the different choices along the way of what makes a critical vulnerability versus one that we need to fix but isn't as critical that it needs to be out the next day. And there's a whole process that goes on under this, it's something that we have developed and we have started to implement in practice and are iterating and learning as we go as well. We also published a new vulnerability management policy on our website and this is targeted at security researchers, hackers, auditors, anybody that might be reporting a vulnerability against DHS2. It explains some of the process that we described in the previous slide and it also defines the scope of what we actually consider core software vulnerabilities. So there are a lot of things that might be reported as a vulnerability but are not something that's actually a vulnerability in the software itself. Those are things like the configuration of the Play DHS2 instance or the configuration of an email server or some test instance that is set up by DHS2. So there are a lot of things that are out of scope but it also explicitly defines the things that are in scope which is if there is a flaw in the functionality of DHS2 that will expose some information that it should not, that is considered something that we can report as a vulnerability and address accordingly. So putting this into practice, we had the opportunity I'll say to put our rather new vulnerability management process to the test just a couple weeks ago when we discovered a vulnerability or had a vulnerability reported to us around June 8th. It was a pretty serious vulnerability and we very quickly were able to identify what the issue was and merge a fix for it into the root of DHS2. This is something that is a learning experience for us but we actually merged that into the core DHS2 repository which had been the practice for some time and but we're trying to kind of harden not only our software but also our processes so that we don't inadvertently disclose vulnerabilities before they're announced to the the implementations that can then upgrade their vulnerable instances. So this is a learning experience that we actually had inadvertent disclosure at that time. We quickly got out security patches and launched them or released them for all of the affected versions of DHS2. We reached out to a wide list of our known security contexts who are responsible for DHS2 instances in the wild and who received a confidential notification that this vulnerability existed and that they should upgrade to that newly released patch. We also informed them that we intended to have responsible public disclosure of this vulnerability at a certain date in the future. The majority or everyone that we know of in that group updated their server instances to a patched version and then in just yesterday, June 23rd, we publicly disclosed that vulnerability and released the patch and the patch releases were announced starting to the public. We also applied for what's called a CVE which was we have assigned a publicly disclosed number that is a reference to this particular vulnerability which has been patched in those released versions. This is a pretty quick turnaround. The total time from first identifying the vulnerability to public disclosure was about 15 days and probably in the future we intend to have more time between discovery and fixing of an issue and public disclosure because we can have full and barcode vulnerability upgrade time or remediation time for implementations so that they can upgrade their instances that are affected before we publicly disclose that that vulnerability exists. During those 15 days, information was mostly embargoed except for the inadvertent disclosure of merging the fixes a little bit early which is something that was a new process for us at the core team and is something that we are proud that we were able to implement that but definitely have some learning experiences that we will take going forward. We responded very quickly and professionally to the vulnerability as it came in and tried to address it in a responsible way. We very quickly fixed identified and fixed the issue when it came in. The patches were cut and published also in a short time frame and the processes just worked in terms of cutting those releases and publishing them and everything was automated and used our existing systems pretty smoothly. We were then able to discreetly notify a large group of known implementations and this is something that we hadn't really done before but we were able to reach out to that large group and get positive feedback about instances being upgraded in a response or in a reasonable time frame and we actually achieved our goal of responsible public disclosure for the first time with one of these vulnerabilities and that's something that we're proud of as well. There are definitely some areas in which we need to improve. The embargo as I mentioned was imperfect because we had a fix that was inadvertently published to the public repository. This could be considered disclosure to a very savvy attacker who happens to be monitoring a DHS2 repository and sees a fix go in. Obviously the vulnerability still exists so it's only disclosure in that it makes it a little bit more noticeable potentially to somebody who isn't probing DHS2 for that vulnerability but it can potentially be a disclosure to those types of people. Fixing vulnerabilities without disclosing what was fixed is a difficult task and that's something that we're working on implementing in our process in the future but it involves a number of steps, a number of private forks of the DHS2 repository to be able to implement those fixes potentially on multiple branches, release those fixes, disclose the source code of those updates to particular implementations but not to the public until that public disclosure happens and that's something we're working on improving in the future. Another area we can improve is that because of that imperfect embargo the timeline was a bit rushed so like I said it took us 15 days from discovery of the vulnerability to public disclosure including a discrete notification of the affected implementations that we knew about and ideally we'd like that to be a little bit more extended so that those implementations have more time to respond and to upgrade their servers. One of the nice things that we did have in this case and we should have in any critical vulnerability patch release is that the patch release only included the security vulnerability fix and so it was a very low risk upgrade for affected instances and so since 230 I believe we have had numbered patch releases that are discrete releases on top of a major version stream and that allows us to basically say if you're on the latest patch of a particular major version and patch releases should be very low risk upgrades this one is as low risk as it possibly can be because it shouldn't include any other fixes or any other changes and so it's much easier to adopt those fixes in production environments in a quick way. The last point here, something where we need to improve is that we need to maintain a list of trusted DHS2 security contracts possibly contacts probably with NDAs in place in order to make responsible embargo disclosure to those security contacts allow them to upgrade their instances and secure their implementations before that public disclosure and with that I will yeah so there's probably a number of questions that people have about this particular vulnerability or about our process or about our team and I think we'll take maybe questions at the end unless any have come up in the chat that I want to address right now otherwise I'll turn it over to Bob to talk about securing DHS2 for implementers. Thanks Austin, great summary of our learning experience to date and improving of process. As you say I think we've got a way to go and it's going to be great post-mortem now as we sit and figure out what we've learned from this one. Okay I'm trying to change the slide because we can't do that. Yeah, having one slide to say how do we implement a secure DHS2 system is a bit crazy but I did give a slightly longer presentation to the Tracker Implementation Academy about a month back. I mean probably those slides and that YouTube may still be found somewhere but if I were to summarize I would say that the most important thing for an implementation to get a grip on its security management is I mean it sounds simple but is to actually have somebody on your team whose job it is and it's kind of surprising but in the Tracker Implementation Academy we actually asked this question so who on your team as party will implementation is responsible for security aspects and there was I think more than 50% of the implementation said well no they don't have that class so that's the first thing it's got to be somebody's job and I know it can be hard because you might not have a professionally qualified security consultant who you can just draw upon it might be somebody who's got to learn on the job in a sense that matters less what matters more is it somebody who it's in his job description to be concerned about security and that makes contacts for example what Austin was talking about earlier if we had a list of the security contact of every implementation that would have helped with the disclosure process that person like part of his job is to stay up to date with security announcements as Austin was referring to but it's also to have general oversight of the kind of organizational and configuration aspects and the technical aspects of the implementation a big mistake that I have seen is that people take someone who's involved with the server administration and say right you're the security guy that shouldn't be the case I think a security manager should have a much more much more an oversight role the job of the security manager is to make sure that the server admin guy is doing his job but if you bury security management down to that low technical level then you've got to miss out on lots of things the second thing that's really important is to have a security plan and what constitutes a security plan is it's something that they make great material for for an academy I think we should do it definitely but a good starting point is look up ISO 27001 and look at this quite a lot of free resources around ISO 27001 ISO 27001 describes in quite general terms but pretty much any organization how to set about managing your security without going into the details of what kind of SSL algorithms you're configuring or what have you the kind of things that you would include in a in a security plan or you have management tools like maintaining a risk register and inventory how many instances do you have where are the SOPs around how systems get installed something very few people implement and we could do better in terms of perhaps providing some templates on things around incident response I mean from the software developers perspective incident response to things like vulnerability disclosure is something like Austin has just gone through but in terms of an instance in the field when you have when you have data loss or when you have when you have a suspected breach or whatever it might be what do you actually do next if you don't have a plan for what you do next then the chances are that you'll make a mistake that will make the problem worse as often described to me is if you're standing on the side of the road and you step into the road that's your first mistake then you see a car coming and then you run into the road and that's the mistake that kills you right so having an incidence response plan those are all kind of things that you put into your security plan backup and disaster recovery probably the biggest issue that we've seen in implementations in the wild have been kind of self-inflicted injuries in a sense they've not they've not been attacked by some malicious actor they simply made some kind of mistake because of having unclear processes and and losing data that way version management I mean we keep trying to put this message out I guess but the the security team software development team in general undertake to provide security management of the last three major versions of DHS2 and so if you're on version 229 then you need to be aware that if there are vulnerabilities detected in version 229 they may or may not get fixed but if you're on one of the latest three versions then then you're part of our management plan a big part of of being on a major version then is to make sure that you keep up to date with Apache versions but talk about that I think I mentioned a bit in my next slide the other thing is having lots of training and and and and messaging wherever we can have messaging I mean they're anybody who's worked with security a lot will know that security policies can be those kind of things that you know big masses of dusty piles of paper that sit in a drawer somewhere you got to get the message out there right and use every opportunity of getting the message out what I like to recommend is when we do academies when you produce training material whatever it is have a standing item have it on all of your training material there should be something called security considerations and for end users security considerations for end users might be to do with things like not sharing passwords try not to do like what I do and have millions of tabs open at the same time as working on my DHIS to logging out rather than waiting for the session to time out etc I think yeah we should take the opportunity of all our training material all our training events to put in a little note on are there security considerations for this particular audience even if there are not many or there may be many at least the placeholder is there something I haven't mentioned in having a security planner course is having audit audits are good for you it's a bias like going to the dentist right there's not very pleasant everybody hates being audited some implementations I think are fortunate even though they don't think so that they're subject to government audits there's a process every year you go through it should be part of the costing plan of an implementation you might have to pay to get an external audit done but getting audited every year at least is an important part of the cycle of security management so those two things right having having someone whose job it is and then making some kind of a plan and the making a plan can be intimidating you hear Bob talking about all these things you might not be familiar with most of them that shouldn't be a good excuse not to make a plan in fact that's the best excuse to start making a plan a plan doesn't have to be perfect and once you have a security plan in place of some description then you've got something to improve and so it's a cycle so those three things have somebody whose job it is have a plan and then make sure you have a process that ensures that you keep refining the plan um typically what you see in a lot of corporate situations your your your chief information security officer is going to report on the monthly meeting to management what's my progress this is what my risk registers we looked like last month this is what it looks like this month um he might have a lot to report you might have nothing to report but if it gets put into the cycle then um you're on the road to producing something which you can improve over time that's security management on one slide um limited i know Austin what do i have on the next slide i will just to kind of move away from very abstract things i mean there are a few very particular things that we thought we just take the opportunity to add in here and some of which i've already mentioned about about keeping in touch with the last three major versions people are very cautious about upgrades and understandably so i mean sometimes an upgrade can be a traumatic thing systems get broken not everything always works properly um obviously when you do an upgrade you should have a again a process around an upgrade a testing instance have have users get into to test all the various functionalities to make sure nothing has got broken there because it's quite a bit of process around a major version again it's something you frequently going to have to budget for major version upgrades can involve new training because there may be new interface features there may be new whatever it might be so as part of your again this is why security management is a management issue it's not that it's not the server admin right it should be part of your annual budget that you're going to do a major version upgrade at least once a year because we release once every six months that would mean you'd never be more than two versions behind patch releases as i've said contain critical bug fixes and very often they can be related to security so again it's got to be somebody's job to monitor when those patch releases are made and then to to upgrade as as as quickly as possible it shouldn't i shouldn't have to say this but i've seen it quite a few times even this last year don't go upgrade your production instance without testing thoroughly on some staging or test instance and involve users in that make backups before doing an upgrade we had an incident so i won't name names wouldn't be fair we had an incident in the country earlier this year somebody did an upgrade from 234 to 235 everything was broken when they got to 235 the only thing they could think to do was to go back to 234 so they went back to the backup and they discovered they didn't have a backup and so they were stuck on 235 and it took probably two three weeks to get everything back up and running again a little word of caution about backups you know we go to a lot of effort sometimes to secure our databases and secure our systems and then we make backups and we send them around to one another on email or leave them lying on our laptops and in home directories and what have you it makes good sense to have some kind of SOPs around the handling of backups and yeah probably my main message of the day remember it's not all about the back end yeah it's a it's a much more broader concern being involved with security management of an implementation users users is probably it probably the most important thing to manage outside of the actual the software installation a lot of cases we've got very often have very good processes around people arriving in the system and and get given user accounts and whatever but we've got very few if any processes around what happens when somebody retires from the service or or resigns or gets kicked out many systems I know have probably particularly the ones that have been going for a long time might have 30% of the users who are now dead that's really not too much of a concern until the dead users start logging in and that happens unfortunately as well so your security management needs to needs to have a kind of holistic approach and as I say tools like ISO 27001 it can be quite a good starting point and yeah we're hoping to put a bit more work into developing more kind of perhaps what can we call it's not dumbed down but implementation guidance around taking something which is complicated like ISO 27001 and putting it into a palatable format that we get the major aspects of it out but these are the kind of issues which would be paramount Boston do I have another slider am I done ah this was yeah this was this is from our presentation of implementers um I think Austin has covered pretty much all those points already thanks I'll take questions I guess at the end if we get a bit of time happy to continue the discussion with anyone who wants to follow up sorry I was muted um yeah and I think it would be a very good idea for us to have to plan a plan a security training session um of more than more than a couple hours um to specifically target some of some of these hard security issues and and then also to uh and I know that there are some of the training team as well on the on the call here to embed uh security into all of our trainings as much as possible when when that makes sense um I think that's a very good piece of advice for the again for the University of Oslo outreach teams but also for implementations themselves as their training users and and that type of thing so where do we go from here we've talked a little bit about the new security team we've talked a little bit about the vulnerability management processes that we have implemented and put into practice and in the last several weeks um one thing that we talked a little bit about is that the the security team is initially focusing most of its effort on the security software hardening so that's hard security of the software the vulnerability management um making sure that there aren't clear gaps in the security features of the software itself um an example actually a good example of this is bob mentioned that users users might have died and no longer be able to log in a feature that was just introduced in 236 of dhs2 is the ability to have a scheduled job to disable users who have not logged in after a certain amount of time and I think that's it's a fairly simple feature but it's something that everyone should think about and enable so that if someone hasn't logged in for three months you disable that account and they need to manually activate it again and you need to make sure that they're alive and who they say they are when they when they do that activation and there are other features as well that have been coming out as as kind of software features but the next step beyond that is is really building up our our corpus of guidance for implementations and particularly in the health sector health implementations on top of dhs2 for privacy of data as I mentioned this is something that a lot of people at the the uiocore team as well as at implementations around the world are thinking about every day but it's we we want to kind of collect a best practices set of guidelines and and collaborate on building up that that set of documentation and guidance for implementations so that we can provide a kind of a a standard way to build a secure dhs2 implementation and this is yeah particularly interesting to relevant to as I mentioned personally identifiable information and longitudinal tracker data in health systems and in addition as kind of the next steps for the security team and the security process that we've outlined is to continually improve that process as bob mentioned in and the advice to implementers it's the same advice to us is make a plan and then continually revise that plan so learn learn from what happens and and continually think about security and how to embed it even more in in everything that you do so that's what we're doing with the at the core team as well and one of the first things that we'll be doing is publishing a post mortem analysis of our handling of this recent vulnerability and the things that went well the things that went maybe could have gone a little bit better and how we're improving our processes to address those those deficiencies in in the initial response which I think went quite well and was much much more responsible and professional and and kind of respectful of of our users than I think a lot of a lot of other systems in the in the ecosystem don't don't necessarily have those processes in place so it's good to see that process going forward we'll also be improving the documentation of that vulnerability management process we have put a new kind of outline of that process on the security website or security page on the dhs2.org you can find that dhs2.org slash security as well as many of the things we talked about here today and disclosure of vulnerabilities vulnerability management policy best practices and guidelines for implementations and we'll also be looking into publishing some security audit tooling to be able to both automated and manual checks on dhs2 instances to be able to kind of determine to perform kind of a lightweight audit on those systems in an automated way this will hopefully prevent some of the the low hanging fruit of implementations that have totally open systems where everyone can access tracker data for instance or systems where they don't have the disabled users after a certain amount of time enabled and can can show the show a system administrator or a security manager what what pieces might need more investigation and might have security vulnerabilities there and some of those will be manual processes or manual check boxes as well such as do you have a security plan do you have a security manager who is your security contact those types of things and we're also ourselves as the the University of Oslo core team dhs2 core team hiring a information security manager who will help to kind of expand this security posture and strategy and implementation guidelines supporting guidance around security and privacy and particularly around individual level data potentially that's something that the the security team and myself are kind of stepping into that role in the moment and but we want to have someone who's dedicated to that and in in a management position as well and will also be publishing promoting security and privacy recommendations for implementers as I mentioned to kind of help to promote that security that security management context and that security management forget the term that I used in the in the guidelines but if it was culture and security management culture in implementations that are built around dhs2 and obviously we're still embedding security into the development teams themselves and the features that we build and building more security features on top of dhs2 such as token authentication and some other things that are coming down the line we've recently done some significant upgrades Morton Svanes the our security engineer has done some significant upgrades to some of the security infrastructure in the dhs2 software itself implemented things like open id connect for authentication and those types of things so we'll be pushing that forward as well I'm going to reiterate the security principles and and just very simply these are these are what we try to embody and try to promote in in the community robust formal and predictable security processes maximum transparency full responsibility disclosure and strong security management culture with that I think I can we can open it up for questions I can also show the the dhs2.org social security website if we don't have too many questions but I'm sure people are are raring to raring to ask us some things so let me go ahead and see if there's anything in the chat or Martin or Bob if you want to shout out to me if there's anybody any questions that have come in so far yeah there's been quite a few questions actually I'm not sure what to start to be honest we are going to be posting these in community of practice of course so actually if anyone wants to make a live question why don't you raise your hand and we can answer that question here yeah I've been I've been answering questions as you were talking Austin Claudia has just answered something I was just asked us something there Claudia would you mind reading out Martin is she able to unmute I can make it so hi hi can you hear me thank you thank you um very important topic that I had learned from you I mean I am from Paho but I I wonder for the security manager do you need a full-time job or can be somebody that that is doing the other security things in order of course that depends on the number of instance and all the stuff but um can you expand more about the need of of the security senior security manager thank you yeah thanks Claudia I think Grant has pretty much answered you in the chat there um look an information security officer he's quite a highly skilled management job um so yeah in an ideal world you want somebody full-time competent and and trained in that area but I mean we're all fully aware that these people are not thick on the ground and particularly with with working in public service can take you 10 years to create a new post as as people will know I think one of the biggest dangers is to say well because we're still trying to recruit a security manager or because we're still trying to create a post for a security manager we're not going to do security management um so yeah ideally yes you do want somebody as good as you can get in that security management post but um if you don't have one somebody and somebody reasonably senior within your project simply needs to be assigned to that role um and they can learn the learn the basics as they go along um some of the aspects of security management is actually not very complicated um it's a little bit bureaucratic requires a slightly bossy bureaucratic kind of person um and there are quite excellent training courses available as well um so yeah my answer that would be much like Grant as a best practice would be to appoint someone but don't wait to appoint someone before you start implementing the question that just came in is about a feature of dhs2 which is the the audit system and there is an audit feature you can find it in the documentation to monitor or basically to log what happens when and by which users in the system particularly in tracker implementations um we also have a feature called break the glass which you can learn about it's also listed on our security web page which allows a user to in an auditable way request access to a tracked entity instance for instance for example that that user doesn't naturally have access to it might be from a different org unit um that is has been referred to their system or to their to their org unit um and you can enable them to basically provide an audit message to say why am I requesting access to this person that's outside of my org unit assigned org unit um that goes into the audit log and you can you can review that later so yeah the answer is yes there is an an audit feature in dhs2 any other questions here i'm going to go ahead and open up this security page but you can see it still can you see the security page of dhs2 while we're waiting for more questions yes yeah yeah um so yeah this is the an updated page about our basically what this what this presentation was about um our practices and policies for security in the the the core team the principles that we've outlined um the features that are available in the core dhs2 and android we're expanding this today as well um there are also uh best practices and guidelines similar to what was presented today uh for implementations um information about supported versions uh a the vulnerability reporting disclosure policy that i mentioned i'll share that in just a moment um and a list of also the the disclosed vulnerabilities that we had so far um in and that's the the one that i mentioned today um which you can see in this list and and find the the patched versions as well um i'll show you also the disclosure reporting and disclosure policy which as i mentioned defines the scope what is in scope and what is out of scope for um uh reporting vulnerabilities in in dhs2 um for security researchers or anyone that wants to do a pen pen test or a penetration test against dhs2 and report those vulnerabilities to us um we also have a disclosure policy here and we are happy to give credit to security researchers who help us to identify vulnerabilities and fix them in a responsible way yeah thanks also i do want to draw people's attention maybe to the very very first sentence on there where we say dhs2 takes security seriously um i think then in terms of most implementations when you talk to implementers they will say the same thing right we take security seriously but if you are hoping to stay out of jail right usually what will get you sent to jail is if you have a breach on your system um and then when you get investigated you need to be able to demonstrate in most national legislation it's pretty much like if you can demonstrate that you have taken all reasonable efforts to prevent that breach to have happened then you're not going to be legally um in trouble uh and part of being able to demonstrate that you've taken efforts is to be able to have these kind of to be able to point to your plan right to be able to point to your your manager to be able to point to your policies and that's why i think it's been a big step forward for the dhs2 developer team to start having sort of formal processes in place like this um but i think the same thing is true in implementations get things written down establish establish policies they may be the very bits of paper that keep you out of jail there was a question here from from pete um the the break the glass audits and the audit log in general is in the the database so it is not i don't believe there's a an interface for it at this point but the log is there and you can't access it we're getting close to the end here does anyone else have any any questions or comments feedback concerns we are transparent and trying to trying to learn as we go as well so very very open to any any comments that anyone has and we will also be looking to build out our our training material around security management policies and practices sounds like we do not have any more questions at the moment um i think we tried to end five minutes early so people have time to go to the next session so maybe we can wrap it up here unless anyone has any any final thoughts no final thoughts okay thank you everyone and please feel free to reach out to us also the the entire security team is available at security at dhs2.org if you have any questions or comments or want to share any vulnerabilities