 Okay, so good afternoon everybody. I'm Arjen Lentz and I'm going to be talking about Drupal and Infosake Assurance. Now that's a very broad and lengthy topic, particularly the Infosake Assurance bit. And that's why I'm inserting a bit of humor and just giving you an overview. And then I hope to have at least about five minutes open for questions. And after that you're most welcome to contact me over email, Twitter, phone calls, you know, whatever you like, whatever's suitable. But the space is so broad that there's really only time for a brief overview of what we're talking about. So first of all, there are a couple of ways of doing the various assurance mechanisms such as ISO and IRAP. And Dilbert of course is brilliant at presenting, oh dear, let me just kill that. That would be lovely. Give me a moment, didn't expect that. Of course that's a security fail, any example. So that should now all be gone. Okay, so Dilbert is nifty at describing these issues and has done for many decades. And basically there's a Dilbert way of doing this thing and just having it being a tick box party and there's a proper way of doing it. Now, I don't know how other organizations care to do this. Sometimes I have my doubts and they appear to have taken page 42 out of a Dilbert book for reference. And we just use Dilbert as in how not to do this. So we actually try to get benefit out of these processes and actually improve our own, the way we do things in a technical way and also in a documentation way and also in the way that we interact with our clients. So I'll go through a number of different standards and processes that we're involved in. So ISO 27001, it's very topical for us. We're actually in the middle of our stage two audit. That means that in stage one, our documentation has already been reviewed. That has been found okay with a couple of comments. And in stage two, the assessor would outside of COVID times visit our offices and just have a chat with various people. They just look around as well. So if someone for instance goes away to see about their coffee in the kitchen and they leave their screen unlocked, then that becomes a minor non-conformity because screen should be locked if someone is not at their particular disk. So that's just one example. Similarly, you see the photo at the bottom right of the slide. When looking at the information security policy, there has been commitment from management and certain things have to be put in place that everything is safe and secure. If the management office, the general manager's office were to look like this, and now this is not the photo from our offices, then that would be an indication that it's not all well. So there's a broad range of things that can be taken into account. There are 114 controls and 14 categories. And one example I've again put on the screen. So it's a fairly broad and open way of describing an information security system where a system is basically a way to look at security in an organization. So when you develop a way to look at that, that is called the information security management system. So here we see password managers shall be in a particular way. It doesn't prescribe it in detail, but it does say that you have to do something. With ISO, as well as other ones that I'll describe, the implementation is done on a secured on a risk-based, it's risk-based. So that means that when you implement the control, you're trying to get the residual risk as low as possible. We always aim for low. So it can be low, medium, high, critical, depending on your rating system that you apply, you would need to specify that as well. We always aim for low. And we always aim to implement a particular control. If a control is not applicable, for instance, at Catalyst Australia, we do not do outsource development at all. We always hire directly or for permanent full-time people, sometimes part-time and sometimes contract basis. We do not outsource to other companies for development. So there's a control in ISO that talk about outsource development. We say this is not applicable because we never do that. So for us, everything is regarded as in scope, except when we have a particular justification for that. But other than that, yeah, the system is fairly broad, generic, and there's a lot of practical implementation that you then have to do after that. Then there's the ISM. Now, this one is the Australian government information security manual, which I actually regard as one of the better ones. It's much more descriptive and prescriptive than ISO. Essentially, you can see it as a super set. So if you look at ISO and then you look at ISM, you'll see that the ISM controls actually cover the various aspects of ISO very nicely. One key difference is that when you're implementing ISM for your organization to get IRP certification, the IRP certification, which we'll get in a moment to, it actually applies to a particular part of your organization. It doesn't apply to all of it. So for instance, when talking about a Drupal site for a government entity, the IRP system would be that particular site, the infrastructure on which it's hosted, the pipelines for the integration system that is communicating with that, possibly the laptops of the people that do development, people who access it at the back end, such as administrators and content managers, the system administrators that deal with the environment, the infrastructure. And for instance, on AWS, the controls on there. So it is very specific to a particular environment, but obviously you can apply the ISM to your entire organization and just have the benefit. And that is what we have done at Catalyst. So there are over 700 controls. Now, this actually changes monthly. There are some old controls get tossed out, some new controls get put in and various controls get rewritten. In many cases, it's not particularly drastic, but over the last year, quite a few changes have been made in particular with regard to the cloud hosting. So earlier, the ISM was very prescriptive in terms of that. And then what happened is that the cloud providers, such as Azure and AWS, would get their own certification or assurance on the ISM for IRAP in that mechanism. And then anyone getting IRAP certification would basically be able to use that as the component of their own certification assurance. That is no longer directly the case. We kind of now have to make our own risk assessment. And in due course, what will happen is that AWS and Azure will still do those assessments and then provide clients such as us with detailed documentation on that. So that's a more detailed rather than just the final report. And then we include that in our own assessments. Now, to have a look at one of the examples here, you can see, I think you can see my mouse, yes. So this is one of the controls. They're not really that many, they just keep numbering. So if one gets tossed out a new one, get 14, it gets a new number. This one happens to be a revision one, not rephrased at any point. Comes from September, 2018. This is official protected secret top secret. So for those security classifications, it is applicable. And then it says very specifically when multi-effector authentication is implemented, what is required with that? Basically that if you use a password and in some cases a security token, a UB key or TTP from your phone, like Google authenticator, you can't be allowed to use that same password somewhere else without the security token. So that's a very, very specific specification that it has there. Now, an organization can choose to not be compliant with this and then it has to make a residual risk assessment. So what would be the risk of not actually implementing that or partially implementing that? Now, again, as I mentioned, catalyst that made the choice to implement wherever possible and that has resulted in this. So the only part of an actual IR report that I can show you today is that little code from our assessor and that particular system was classified to official which is kind of like the basic level in IRAP space, official sensitive actually. And we got to 93.6% compliance. So on 700 controls, there's a couple of dozen controls that we weren't at that point able to implement or that we are not going to implement and then for each of those we would have a justification on exactly why we take that approach and make sure that the residual risk is nevertheless low because that is the objective. It is important that whatever you do or don't do, you mustn't expose yourself to problems whether it is organizationally or on a technical level. So that's IRAP. So the IRAP program is specific to Australia and it's run by Australian defense signals and it implements the information security manual and then an assessor again, similar, it's actually very similar to ISO in that respect. Some cases you get to stage zero to look at whether an organization is ready to get assessed, stage one is documentation review, stage two is a, as I call it, show me review. So the assessor says, well, you stated in your documentation that you handled this in a certain way. The SSH servers are configured in this particular way. The configuration is actually prescribed by ISM, show me, and then one of the system administrators will have to go in to one of the systems and actually show that that is indeed the case. So it's actually very, very specific and prescriptive in that sense. But in return, you get the pretty good assurance that the system is actually fairly secure rather than just on paper. So in that sense, the chances of doing IRAP but not properly are less high than with ISO. However, if an organization chooses to implement less and do more risk assessment in a way, then you could still get a fairly low compliance rating. So it's my understanding from assessors that typically the percentage of compliance is somewhere between 40 or 70%, which makes our 93.6% look very high. I don't have insight in what other organizations do, but for us, it wasn't that complicated. It's a lot of work, but it was essentially what we do already well documented. And again, I'm happy to answer particular questions that you might have because I don't know who my audience is today. Whether you're an executive in government that's fine to all arrange something or whether you're a techie looking at this from the other side, I'm expecting essentially all types of questions and that's perfectly fine. I see a type on the page here, of course, that's NIST. So when implementing our information security systems, we take a close look at the NIST publications, particularly 863 series. The reason we do that is because typically it kind of runs ahead of some other ones. For instance, in NIST, the identity proofing, authentication, those processes are already described in a way that is more up to date with how things work now. Some of you may have seen the XKCD cartoon about the fact that a password that consists of four individual words. I need to kill another app. There you go, the things we do today. So that the password that consists of multiple words is much better in terms of being secure and actually possibly being remembered, although I do recommend using password manager, then requiring a number of letters and then uppercase, lowercase numbers, special characters. It becomes very arduous for people to use. It tends to get circumvented. If you require people to use numbers, they use point one first, one, and then in three months if you require them to change the password again, they'll use point two. That's entirely predictable and it doesn't actually make things better and more secure. What it does is it creates a predictable path for computers to actually brute force these systems. And that is exactly what happens. So NIST describes password security as if it has to be remembered by a person, it actually needs to be easily remembered and it actually needs to be really secure. And we work inside catalyst on the basis of bits of entropy. A password needs to have at least 65 bits of entropy. So basically using a word and then replacing some of the letters with the numbers, like catalyst, you could replace the A's with a four. That doesn't make the password any more secure. In fact, in some cases, less so. So those are the interesting things that we look at. So NIST we use to create the best practice on top of ISM and ISO. So what we have done in terms of implementing ISM is we've said we're not compliant with this control. We actually implement a superset and that is NIST in this case. Okay, I need to click there. OWOS, so OWOS we use internally to review our own applications to see whether it actually has been developed with secure coding practices. And we also use that for external applications such as Drupal to see whether all is well there. Now, Drupal and Gavzimes are pretty decent. It depends a little bit on which plugins, which extra projects you use in there, but overall it's actually very, very good. However, it does depend on configuration both of Drupal itself as well as the web server environment. So that all comes into play when reviewing whether something is actually secure. We also get, and that is a requirement generally for at least IRAP, for a particular system, for a particular environment, we get an external vulnerability assessment done by a pen testing organization. We do that internally ourselves, but you do want that external assurance to assure to the client that you haven't just done an internal tick box. All right, so very quickly an overview. And again, I'm happy to share these slides as far as you haven't recorded it already. This provides a quick overview of how we build our infrastructure. We build across different availability zones in Sydney. So these are three different locations at AWS. In Sydney, we're all hosted in Australia for those applications. So it's scalable, it's secure because of the way we set it up for IRAP environments. All this is within a virtual private cloud and then in separate segments of that. Only this segment is actually available from the outside. The others cannot be. It is resilient because of any of these systems goes down or component inside that doesn't matter, it is okay. Within the components, also we scale. So there can be many, many dozens of web servers happening here. There can be many, many more database slaves and servers around. So that's how that works. We use Linux. Of course, we use the AWS technology and we use a lot of Docker containers. And internally in our organization, we all use Linux-based laptops and infrastructure. I see so the chief information security officer of Catalyst that makes me very happy because about 95% of the security alerts that fly past are not applicable to me very simply because I don't use Windows. And the final bit, we of course keep an eye on things. And that is very important both for IRAP and ISO. They get reassessed, but even if they didn't get reassessed we want to do right by our clients obviously. So the monitoring of systems is very important keeping up to date with vulnerability alerts and then doing regular updates. So that is built into our pipeline system and we do regular security updates, both of the underlying platform as well as the versions of through ball and its components. All right, I've run a bit over time for my talk which means I have less time for questions but as I mentioned, I'm quite happy to answer more after that. So Timothy Cosgrove asked, are there any ISM controls that are found to be particularly problematic for Drupal? No, I honestly have to say I haven't. So we've worked with Drupal and we've worked with Moodle learning management system and Totera also learning management system like more corporately based. There's nothing particularly complicated. The things to look out for are things like password controls, but it's not difficult to actually implement that properly in many cases in corporate environments you actually use single sign-ons. So you essentially log on via SAM or LDAP rather than Drupal directly which makes it, you kind of outsource that problem but you still have to deal with it. How do we keep staff up to date with controls? Am I still allowed to go? We don't give details on this to staff directly. So I have CSL and I have someone who works with me for compliance and risk. We look at these things and then we look at the context within our organization. And what happens then is if we think something is relevant in terms of change, we write up a work request for the CIS admin to follow up on and actually make a change in configuration or work towards a different way of doing it and that gets to start and discussed with our operations manager. But that's essentially the way we do it. It is completely impractical to have all your staff up to date for all these things. It's just not the way you can generally work. You really need compliance or security people who are across this. And I can't say it's a joy and a pleasure to read all this on a regular basis but it's part of the work and you can actually make it fun. Okay. Other questions? Yes, we shield our team where possible. Yes, I mean, why should we all go through the pain? You know, I'll happily read that. And so does my colleague Claire who does the compliance and risk assessment. And then we share with our team as necessary and of course we need to do internal training and then those things need to be read. Okay. Yeah, we have to wrap up. So thank you very much and I'm happy to follow up and answer more questions. Thank you.