BONUS: Cole & Toby Review The Cyber Bible (2023 - Information Security Manual)

Cole Cornford:

Hi, I’m Cole Cornford and this is Secured, the podcast that dives deep into the world of application security. In this bonus episode, I speak with Toby Amodio, Chief Information Security Officer at the Department of Parliamentary Services about the latest update study Information Security Manual. The ISM, also known as the Bible, is a great reference for anyone looking to understand what threats the governments is looking to address and where, as a community, we need to be more vigilant. So let’s jump right into the latest changes to the ISM. All right. Welcome. Thanks, mate.

Toby Amodio:

Thank you, Cole. Today the intent is to go through the June quarterly update of the Australian Cyber Bible, that is the Information Security Manual. I intend that hopefully others can follow along at home should they want to because it’s all released on the ACSC’s website. But before we jump in, I just thought I’d do a little bit of a overview about the ISM.

And so the purpose of the ISM is to provide strategic and operational guidance on how an organization can protect the systems and data from cyber threats. Now, that’s the very dry approach, but as Cole, you and I would know from working in government, it can also become the compliance stick to whack the government’s back. But as with many things put out by the ACSC over the last couple of years, it has developed into a really valuable resource for cyber intelligence and standards. And so looking at the changes that happen on a quarterly basis becomes a ritual for government, but could also be beneficial for the private sector to look at what should they be focusing on and what controls are good to focus on within their organizations. Now, the intention is in this piece to kind of focus on the key changes, the thoughts on them, the implementability, which isn’t a word, but we’ll make it a word and the applicability to government and private sectors.

Before we jump in, I wanted to thank those who contribute to the ISM, I know it sounds a bit dry, but we’re probably going to make a few LOLs at their expense and it is a valuable document and it is something that we can use to improve the cyber posture of the whole country. So what did you think of the ISM before we jump into the core section, Cole?

Cole Cornford:

So for reference for people on the podcast, I basically worked in federal government from about 2014 ish until 2018, I think around that period. And so it was a very different time period. The top four was what people would refer to and we were just starting to get used to the essential eight coming out. The ISM didn’t even really have the ability to distinguish between different tiers of sensitivity, whereas nowadays you actually think about applying risk instead of being told the red wires and the blue wires need to be separate. And I guess another thing I really like about reading the most recent update is they got technical writers in and they’ve really focused on making their language very clear. And I know when I first started that it was a lot harder to actually comprehend why people were making these decisions and it was quite lengthy. So it’s not so much a King’s James as much as a pocket Bible nowadays, but I prefer that because I can take it with me when I need to.

The most recent update, I think I’ve really been enjoying watching from a distance what’s been happening in the sphere because, I don’t know, I’m a little bit of a guy who just likes to see what’s happening in the space to see what all my friends are being subjected to back in the public sector. I’m kind of clear the AppSec, you just do whatever modern programming stuff that people tell you to do and YOLO, have some fun, try to keep up with all of the tech yahoos, but it’s a little bit more structured in government I find. So it’s good to see where we’re moving. And so yeah, the most recent update, I actually liked reading through these.

Toby Amodio:

Yeah, awesome, awesome. So the approach that we’re going to take to jumping through them is the ISM is broken up into guideline sections and the guideline sections provide the practical guidance on a domain of cybersecurity and how people can implement those to protect their systems. Now, before we jump in, I will note that a number of the updates, as Cole referenced on the back of them having new tech writers and having people who are reading and diligently checking their work. And so instead of CBEs in the vulnerability space, I really call them CCE, which is critical control areas where it’s a spelling mistake. So there are a number of critical control areas this year that we will pass over, but there are a couple of interesting things to talk about.

Cole Cornford:

I think it’s actually really important that they are continuously working on improving the grammar and spelling of the document. I just have a bit of a stickler for it nowadays in how I do written communication because I’ve seen what has changed from 2015 to 2023 and it’s a remarkably different document. So I know right now the iterations are incredibly small, but where it is right now makes a big difference for people who are coming at it and not having to spend an enormous amount of time shifting through jargon or having to deal with sentences that are seven or eight paragraphs long to try to comprehend what’s going on. I think we still absolutely should give congratulations to the people over at ACSC for understanding that clear communication is really important.

Toby Amodio:

I couldn’t agree more. And it’s effectively crowdsourcing the assurance of our wording. And so I think that there’s a lot to be said for crowdsourcing, whether it’s in improving the grammar and the contextual reference of our controls or through to improving our code. And to what you said as well, where a full stop is or how a sentence is structured is not just critical for ensuring understanding, but it’s very critical if you’re getting audited because that can be life or death of how a control is interpreted.

Which brings us to a perfect segue to the first guideline is the guideline for cybersecurity incidents. Now, with the guideline for cybersecurity incidents, whilst there is one minor update based on wording, there is an update to ISM control 0140, which changed from being prescriptive about having to report to the ACSC to now encouraging people to do as soon as practical. So that control, be what it may, is a great control to ensure that the whole of the country gets visibility to the incidents that are going on and then they can feed that back into the cyber threat intelligence and into this document being better. So whilst we don’t need to go through it in depth, it is one of those controls that people are aware of. And if you’re in the private or public sector, I do highly recommend that you report to the ACSC where you can around your cybersecurity incidents because it makes us all better.

The next guideline and section is guidelines for procurement and outsourcing. And nothing in cyber is more interesting than procuring and outsourcing. And so ISM Control 1572 is focused on updated the concord notification clauses for changes and locations by hosting service providers. This is interesting because it’s about making sure that you have a new contract so that people can contact you when they’re going to move your cloud services offshore. I don’t know how effective this will be, it’ll be interesting to see how enforceable this would be with some of the big agencies. And again, don’t want to boil the ocean on it, but it is one of those controls where it’s easy to write down but maybe hard to implement. And I think that there’s a couple more like that that we will really sink our teeth into.

And I think that the first one we’re probably going to sink our teeth into is control number 1163, which is underneath the guidelines for security documentation. So this control update is to expand the continuous monitoring plan to drive the need for vulnerability and penetration testing as part of services prior to go live or at any significant change. It’s a pretty robust implementation of active validation of services prior to deployment and throughout the life cycle, that what is the continuing monitoring plan of an organization. I think given your space in AppSec, you’ve probably got a position on how we can shift left rather than pen testing at the end but I won’t put words in your mouth. I’ve got some strong thoughts on this applicability.

Cole Cornford:

This concerns me because I guess it depends on what they classify as a service or a system, right? Because we have to think outside of the box of just the software applications. It could mean something like we’re providing some kind of change to tax affairs like a taxation system or some kind of ability to log in and do Medicare records or whatever. A system may not refer specifically to an application, but all the processes and stuff around it, in which case, yeah, I could kind of see that because you have a fixed point in time where that has to be delivered based on your legislation and that seems okay. My problem is very clearly if the definition relates to some kind of software system, in which case generally in my world people are deploying multiple times per day.

But even if you’ve got remote frequent windows and stuff, there’s just no ability to have assurance processes done by humans at the speed that people are iterating with their software. And if you’ve got say 40, 50 different development teams and they’re all deploying two to three times per day, then you need 150 pen tests per day where usually we say they’re about five days each, right? And this pen test has to be on this one API that’s probably had a spelling error update or the contract’s been amended to add an authorization header. Regardless, there’s no way they can ever scale without investing in application security services, so we just don’t have enough pen testers in Australia, and even if we decided to hire all of them into the federal government, which that’d be interesting, I still don’t think we’d be able to meet this control.

Toby Amodio:

Yeah, I agree. And it is one of those pieces where the whole concept of continuous monitoring and ongoing adherence is obviously essential. And this is a perfect example to me of how a compliance audit read of this could be overburdensome and then the risk implementation becomes essential because it is really, as you said, how you define the system, how you scope what you’re going to do. And so for implementability, I would say anyone who’s reading this control should have a policy around their continuous monitoring implementation and which parts of this they’re going to implement and not and which systems within their environment they’re going to apply them to and when, because if you just were to blanketly apply this, as you said, you’re going to just set yourself up to fail and not meet your own bar. But obviously the concept of doing continuous monitoring is essential to ensure systems don’t drift from their compliance state. So do you see this as applicable within that private sector space?

Cole Cornford:

Well, it depends. There’s a few things, to put my policy hat on, prior to go live and significant changes. So when we say go live, if we’re talking about project delivery models, it’s quite a big difference between we now have released Apple Pay or blocking pipes for Telstra or something, right? Or a new superannuation app. The go live for them is the project delivery date, it’s not when the software is in the production environment, that’s a very different case.

But deployment of significant changes is the other piece. So if you’re iterating on really small bits of content continuously, none of that’s ever going to be significant. So theoretically, if you have modern engineering practices where you’re committing code multiple times per day and it’s running through CI and it is being deployed, if it passes all the tests, then that’s not really that significant. It’s more of those big bang projects where they say we’re going to do 30 to 50 services are going to be modified and then we’re going to do it, have an outage over the weekend and pen test has to happen before that. So I can see people trying to adhere to this in both public and private sector and getting really angry on that wording of what is a service because software application is a service, doing bank telling is a service. Support center staff and then what is go live, what is significant change? And I don’t know, I guess this is why I don’t work in policy.

Toby Amodio:

That’s it. The devil will be in the definition and you should know with that definition that the auditors, whether they’re external or internal, will hold you to your own account usually. So where you set your bar will be where they hold you. So make sure you know where you’re sitting in your bar and why you’re setting it there. Because even the wording in there that talks about the fact that the penetration test should be undertaken at least annually, as you said, we don’t have enough penetration testers to scale to that within federal government, let alone across the private sector. So what does that look like?

Cole Cornford:

Yes, so just that risk management approach, right? So what matters to your business? And as a public sector person, there’s going to be quite different conversation about what matters compared to private sector one. But generally the private sector is, how do I make money? And I guess if you’re working a tax, it’s the same question, how do I make…?

Toby Amodio:

It’s true, it’s true.

Cole Cornford:

But still, revenue is generally where you want to be looking at things, things that actually actively help your business to be able to earn money. And the other thing I guess is what is externally exposed? And lastly, what is a tremendous reputational operational impact for you to be able to earn money in the future? So I’d be kind of looking at those places using that risk-based approach that I feel like most cyber professionals have kind of picked up over time, but I don’t see any way that this control would be able to be followed without at least having some kind of automated program for assurance in place. And at least if it’s system based, it like AppSec and vulnerability scanning or product security makes the most sense for me to invest in.

Toby Amodio:

Yeah, I agree. Moving on, the next updates they did I personally enjoyed, which was guidelines for personnel security, which was 1852 and 1853, because they ensured that least privilege applies to both admin accounts and standard accounts, which I was surprised had not already occurred. So we’ll just leave that one there as a comment.

Cole Cornford:

Look, people forget about things. That’s all right.

Toby Amodio:

People forget about standard accounts and ensuring that standard accounts have least privilege too, but least privileged just consider it to be good practice no matter where it is in your environment.

The next section was focusing on guides for communication systems. And I found this one to be funny because our organization’s really trying to push or going paperless and this really hits to the risks of having paper. So the controls 589, 1854, and 1856 all apply to MFDs, multifunctional devices, or weapons of multifunctional destruction because we have seen a lot of issues across the environment with MFDs being configured wrong or being used as pivots into the environment. So what did you think about the changes and about its applicability in that private sector?

Cole Cornford:

I guess it just really depends, in my view, I work for a lot of places that just are paperless, right? They just either they are fully remote companies or have been operating in a way that having a physical printing device is usually a break class, “What the hell? We’ve made a mistake,” kind of thing rather than you have offices with a bunch of printers that people need to go to. So I feel like migrating people across are getting used to not interacting with it can just mitigate this risk and I guess you saved the environment.

Toby Amodio:

Yeah, well look, and I felt the same way that it seems like they were trying to push that if you had multi-factor on your normal environment, you needed multi-factor on your printer and Lord knows that MFDs aren’t really going to love that.

Cole Cornford:

Oh, that’s just going to be like, I can’t even imagine pulling out my RSA token or something and then being like, “Yeah, okay, I’m going to punch these numbers in,” after already getting angry about paper jams or whatever. So just maybe what they’re trying to do is make it so hard that people just are never going to print documents again, right? You just can’t comply with this so we’re done, multifunctional devices are gone because it’s too hard.

Toby Amodio:

This is the nail in the multifunctional coffin.

Cole Cornford:

Yeah, that’s it.

Toby Amodio:

I wish that was the case. I feel like we’re going to be 15 years, another generation out, being able to properly retire them. But you never know, we might have something happen like get another COVID where everyone’s locked up at home and suddenly printers will be properly destroyed.

Cole Cornford:

Then you’ll have everybody buying their own office works and then being like, “How do I put MFA on this?” And then you cry. You do, I don’t.

Toby Amodio:

Yes, yes, tears occur, literal tears. But I do say in there the concept of follow me print, authenticating to print is a really good idea because even just having that old, “I printed to the wrong printer,” is a recipe for destruction. No matter where you are though being at least at a minimum, if you’re in an organization, you’ve got MFDs, make sure someone can swipe to make sure they print it wherever. Even aside from the fact that it’s better to stop data being sent to the wrong place, it also means you don’t even have to know which printer you have, you just go to any printer and swipe it, it pulls it down from the print server. I do remember hearing about a previous organization where they complained about it because the EA couldn’t go grab the person’s printing because they couldn’t swipe for them, which I thought was funny, but increases your steps as well.

Cole Cornford:

Thinking back to when I did printing, so back when I was in government, that was all the time, I feel that I did struggle a lot of time with choosing the right network device and the network tabs and Microsoft Word and not really knowing if it was supposed to go level 4, 6, 12 or which of the printers it would go to. When I went to Westpac, because I had a hot desk kind of arrangement it, they did use that kind of tag, I just completely erased it from my mind until you brought it back up again because I think I printed twice in my entire time. But both times all I had to do really was go up and go beep and then it just turned up, right?

Toby Amodio:

That’s it, that’s it.

Cole Cornford:

So I think you used a card as something you have instead of, and then it would require you to enter a pin from your phone as well or something. So there you go, look at the bank is so ahead at a time, the banks in 2019 already know how to do MFA for MFD. So those MFs.

Toby Amodio:

Look, I’ve got some recommendations, even if you can, don’t, just stop printing.

Cole Cornford:

Just get away from it.

Toby Amodio:

And if you can’t stop printing, then definitely at the minimum and follow me print. That’s probably enough of the old printer shenanigans.

Cole Cornford:

Weapons of… We don’t want any more printers in life.

Toby Amodio:

No, no, no. The next section was guidelines for evaluated products and more critical control errors in this, more grammar updates so thank you to the grammar lords for that. But the next section for me was more interesting because it has that AppSec feel, which is the guidelines for ICT equipment. This control 18757 is good because it basically notes that we should preference vendors with good secure by design principles. It’s an aspirational control there. Reading through it, I actually thought this is one of those things that’s great in principle but hard to do. What was your think having a read through it?

Cole Cornford:

So for the audience, just going to read it out, it says, “Equipment is chosen from vendors to have demonstrated a commitment to secure by design and secure by default principles, use memory safe programming languages where possible, secure programming practices and maintain the security of their products.” I mean, it sounds wonderful, I just have no idea how you’re ever going to test that people even do this. Because if I think about just if you go to vendor assessments, have you really seen a successful third party assurance vendor assessment in your career? Because I like Daniel Miessler’s kind of take on it, which is pretty standard is to ask someone if they’ve been breached and then ask him if they’re an ax murderer and if they say yes to either of those, then you probably need to think about them because what are they going to come back with? Just say, “Yes, we do every security, please buy our product. And also it’s too sensitive to show you.”

The other method is, what, just go get a bunch of certifications like 27,001 and say that, “Yeah man, my letter of attestation, I’m not going to show you, but it’s specifically for my dad’s head house and-|.

Toby Amodio:

Scoping is key, scoping is always the key,

Cole Cornford:

The scope, it’s very important. The hen house is protected, see we’ve got 27,001 compliance. We are a healthcare institution, but the letter of attestation for is was one chicken in here and he is protected pretty good. So I don’t understand how you could even apply that in software when if you think about the kind of verification standards that are available, which should be like OWASP SAMM or OWASP VS, very few companies, even remotely followers, let alone would be audited against them. There’s no kind of procurement thing. So what? They’re going to just throw a bunch of static analysis reports at you or something and say, “Hey look, we run a tool, is this good?” And then you look at it and you’re like, “Ah, clang, find bugs, that’s from 1998.” It’s modern death practices.

Toby Amodio:

Yeah, as anyone knows who has even run automatic code scanning against your own systems, actually reading it and making sense of it for yourself and then contextualizing it from a risk perspective is hard. If it was easier, everyone would be doing it. So then extracting that out to make it so it’s something that’s consumable by a client to show to them that you’ve got secure by design or secure by default principles, it’s almost practically impossible at the moment, from my understanding. I’d love for someone to write in and tell us how we’re wrong and this is the thing, but if it’s there, I’m not fully aware of it.

Cole Cornford:

So I don’t know any vendors who actually demonstrate any of these principles. The best I see is they say, “I’m Hippo, I’m FIPs, I have PCIDSS, I’ve SOC2,” but almost all of them usually have a single piece within them that just says, “Do AppSec somewhere,” there’s no secure by design, secure by default. It’s messy.

And also all of these, they’re not really indicative of the fact that vendor isn’t actually going to be secure. It’s interesting to me to see use of memory safe programming languages because that implies two things to me is either they can say, “I am using C Sharp and Java,” which are full of, they managed memory. So if they’re some backend service, then they have a lot of their own kind of problems within them. Or you can use something like Rust, in which case the product has basically got no memory issues, but it’s never going to be built upon because it’s built in Rust, no one knows Rust. So even if you use memory safe languages, they can just put the unsafe keyword in and start buggering around the pointers anyway, so that doesn’t even protect.

Toby Amodio:

Yeah, exactly. It is one of those things where I go, this is great, but it’s probably just going to lead to more vendors having more buzzwords in their sales documentation, which says secure by design and secure by default. And then you just have to shrug and take their word for it and we all walk forward into the CV apocalypse.

Cole Cornford:

I guess you can just send some kind of AppSec company out to audit every vendor on earth and then see if any of them willing to even let you look at the source code because I guarantee none of them are going to let me do that, I don’t want this guy going out there and seeing all my hard coded credentials for all the production systems through all these government agencies.

Toby Amodio:

Well, and you do joke, but I do think that, I’ll put this down as a thought bubble, but the concept of a cyber coordinator or a whole of government cyber capability should be to be able to attest to this to some level for entities. And so that way an entity could write to them and say, “Hey, I want to apply to be accredited as secure by design,” and they get someone into doing an insurance activity and then they get put on a list. Now no one wants to maintain those lists, you could tell by the change to the SECC Secure Cloud list that got canned because it was too much work to have a central list. So I’m not saying it’ll work, but for me that would be the only way that this happens where there’s a central authority who just goes, “Yeah, we did this and these are the things that we did and we’re doing it consistently for all of them,” so that way at least you can know if it’s bad, it’s consistently bad, or if it’s wrong, it’s consistently wrong. But then also if it’s right, it’s consistently right. I think that that would be a great way to do it.

Cole Cornford:

So you just do IRAP, but it’s ASRAP, right? Like AppSec registered assessors.

Toby Amodio:

Sure. I’m not even going to touch that with a barge pole.

Cole Cornford:

I don’t know, man. I feel like the biggest issue with this if you do something like that is just no one’s-

Toby Amodio:

The name, no? The name’s not the biggest issue?

Cole Cornford:

No, I’m happy, I used to live in a team that was called the ASS Team until someone pointed out to me, they were like, application security assurance or something. I was like, “Why are we ASS?” So I was like, “Yeah, we should probably change that.” So it’s AppSec Assurance now, not application security solutions or something. So yes, I’ve been in those boats before. So that’s not our job, we’re security professionals, we’re not marketing people.

Toby Amodio:

We come up with the ideas, they’ll brand it.

Cole Cornford:

They’ll figure it out. They’ll call it the ACSC rep or something. But yeah, man, another thing I want to bring up about this one is that at least with most networking technology and operating systems and so on is that they’re relatively long shelf times and lifetimes and generally you can apply the same kind of auditing methodology over years. Whereas if I think about the programming languages I’ve had to pick up over the last 10 years, I made a mistake of being a Go lang programmer in 2015 and now it’s actually kind of being great and a lot of people are starting to use Protobuf and all sorts of cool things, except I also remember specifically not choosing to learn Angular too or Solidity or Rancher and a million other things.

So I don’t know how you’re going to be able to cover the broad scope of stuff and unless you just pick C, C++, C#, Java and hope for the best because it’s just too much. And that’s just languages, you’ve also got to do it for the types of software architecture and systems that they use for building applications. So that’s the CI. So that could be anything from GitHub actions to Bitbucket pipelines to Azure DevOps to, I’ve just said all the Microsoft things, I guess, but there’s a million different ones available like Travis and Jenkins and it just keeps going. And the SCMs and how you deploy it in cloud environments because nowadays we write code to actually say what our cloud environments look like.

Toby Amodio:

Yeah, infrastructure is code.

Cole Cornford:

So if you’re a Bicep guy or you’re a Terraform dude.,

Toby Amodio:

Ansible, yeah.

Cole Cornford:

Like Docker, Ansible, yeah, Puppet, whatever, I don’t think there’s any particular ability to just get people to understand almost all of these technologies and the risk associated with them and stick them in a room and say, “You need to audit everything everywhere.” So I would say, yeah, this is more than likely going to end up with a framework like SAMM where someone comes along and says, “Tell me what you do for DevOps,” and then you just see if they mention the word SaaS somewhere and then you can give them an extra point and if they don’t, you can take a point away, which is kind of what SAMM does. So OASP SAMM, software assurance maturity model, there’s not a bloke called Sam who is part of-

Toby Amodio:

Who’s part OWASP?

Cole Cornford:

Yeah, I just call up Sam.

Toby Amodio:

Sam the head of OWASP, you just give him a call. Sam said it’s okay.

Cole Cornford:

You just give him a call and you say, “Hey mate, I’m part of this new IRF kind of place, so you need to come out and do it, mate.”

Toby Amodio:

So you’re saying any new assurance model should be someone’s name?

Cole Cornford:

Yeah, so we’ll come up with the Toby assurance model soon.

Toby Amodio:

It’ll be named like hurricanes are, just a name taken off the list, that becomes the next one. We won’t believe that it too much, but I think it’s fine that we both broadly agree that it’s good in intention but almost impossible to enforce. So it’ll be interesting to see what comes out of that.

The only other control that’s been updated in that section is a great one, which is 1858, which basically just says if you’re going to put anything in and there’s a guide on how to implement it at the ACSC, then follow their guide. That makes perfect sense.

The next major guideline section is to system hardening and there’s a heap of minor wording updates in there. I don’t want to talk about it in depth, but there is two control updates that I find great, which is 1795 and 1685 where they explicitly include break glass accounts in the length of requirements for passwords, which means it seems self-evident, I would’ve said that break gloss accounts are privileged accounts. But the reason that I love this one is because then ISM control 1403 was also updated, which is the existing control relating to locking out accounts after a number of failed logins. And so they’ve updated that control to exclude break glass accounts,

Cole Cornford:

Someone fat-fingered and then got locked out of like AWS root account and then, I don’t know, some system was offline then everyone whinged for a day, however long the lockout period was.

Toby Amodio:

Yeah, look, it is good when you’re basically telling them to have super long passwords and then saying, “Hey, but maybe don’t lock out your break glass after five goes because you’ve just given it a super long impossible password and that’s your final entry in.” So I thought that was a fun little spicy piece in there. There is also 1861, which is a configuration piece around local security authority for orth protections for Microsoft, which if you’ve got Azure AD implementations or Microsoft implementations, I recommend you do it.

The next page of updates in guidelines for system management are all just wording updates so we’ll skip through them. Similarly, we’ve got guidelines for software development. They’ve got a new control that applies for web application firewalls covering both the avoiding of disclosure of internet protocols and web services infrastructure forward. I’m not going to go to it too much in here because there is a massive section on DDoS, but it is really, you can see this is indicative of what happened, the updates as a whole, there’s heaps of CEEs in the guidelines for emails so heaps of wording updates, you don’t need to talk about them.

But the ones I would like to talk about next and it’s the last major section, is the guidelines for networking. So there are extensive updates here focusing on online service health and DDoS mitigation, a lot of controls talking about basically not allowing enumerate your local resources, only using a CDM where possible, using various controls to protect against a denial of service event. I think these are very timely, given that Russia’s going a bit ham on denial of service across the five eyes at the moment. So there’s some good takeaways here. What did you think about these updates?

Cole Cornford:

It’s about scale, a lot of it’s the cloud environment scale. So I noticed that 1431 has changed a little bit, but it’s in an important way where we say instead of having just saying that a cloud providers can dynamically scale, it says verified account cloud service provider can dynamically scale. I’m going to hazard a guess and say that a lot of the government systems haven’t been architected in a way where you can actually scale. Because let’s say you just go out and get an EC2 box, you do a lift and shift program and you pick up your thing and you put an EC2 and you give it max. Well, how are you going to do load balancing and scaling it on beyond that? And the answer is probably not particularly well because you’ve got a monolithic application, it wasn’t built for cloud services.

And so that’s why the verifying piece is very important because they’d come back and say, “Hey, if you want disorder scaling thing, you need an ALB in the front and you also need to actually find a way to distribute load between all your different EC2 boxes. And also maybe you should consider not using straight EC2 and think about serverless and actually architecting for a cloud environment.” But also that’s very hard.

Toby Amodio:

It is. If it was easy, everyone would be doing it.

Cole Cornford:

You need to re-architect your applications and yeah, I mean that’s how I get paid big bucks, right? So it’s an intense area, it changes a lot. And even if you’re a really good software developer, learning cloud in addition to that, it’s a lot to go across. So yeah, I thought that one was really cool because I feel that, at least in my experience, there’s a lot of people that misunderstands that AWS or Azure or Google, they just don’t solve all your problems. You are basically paying for a box in a data centre or more specifically you are paying for a portion of a super computery kind of thing and a little rack somewhere in a data centre, you’re not paying for them to manage when you go to a local provider like a Next DC or a Macquarie Telecom actually physically manages offices or if you have your own data centres. And you just make these assumptions about what people are in charge of and then it falls apart when you get hit with a hundred billion requests per second.

Toby Amodio:

And it is interesting there, because there is a lot of really practical advice, like including 1581 where they talk about making sure you have continuous real-time monitoring of your environment or that you have the ability to search when you see attacks. And for me they actually removed wording around, they removed a control called 1518, which related to maintaining a pre-prepared low bandwidth version of your website, which for me, I think that’s still a good control. It’s kind of been rolled into 1431 and if you scale appropriately, you probably don’t need this, but for me it’s still a good backup where you go, “Even if everything gets taken out, this is how we file over to a known state,” so that you can point people towards that.

I think that there’s a lot of work to be done in this space and as you said, as people move to these as a service models, increasingly things that were traditionally part of their big gateway vendors or that is going to be some entity with check boxes having to configure it appropriately and maintain that configuration. And that’s critical for both public and private sector people to think about.

Cole Cornford:

The low bandwidth one I think is actually good to be removed and I’m coming at it from a different view, which is that you basically don’t need to maintain two versions of your application. And that is a lot to ask because why not build an application that just actually considers bandwidth fence minimizing the ability for actual functional calls? Go take that kind of content and get it run server side. Again, it goes back to if you understand and build your application in a way where you’re taking advantage of micro front ends and http free so you can actually be very sensible with your performance and what you’re actually pulling down, then having the need to maintain two different iterations of the website is not so important anymore, right? But again, you don’t have, what do you call it, people going and building applications that are cloud native and that’s not so easy.

Toby Amodio:

That’s really fair. And I do think that when I think about it as well, that load bandwidth up to me is almost like a maintenance page so that you can have some level of presence, but you’re not intending to do a regular cadence to it, if that makes sense. It’s not like your whole website, but without the login pages, it’s just a 404 effectively, a pretty 404.

Cole Cornford:

I feel like when you show those kind of things though, what happens is a consumer navigates to it and then they get scared. You have a reputational plummet. Whereas I feel like if the website’s slow, they would just kind of forgive you a little bit and just be like, “Oh, these guys kind of suck a bit,” whereas if it comes up with a low bandwidth version they’d be like, “Hang on, something’s going on. Maybe I should call up the AFR.”

Toby Amodio:

I smell a rat there.

Cole Cornford:

Well, is this census fail again, right?

Toby Amodio:

This seems like a failover, yeah.

Cole Cornford:

Yeah. So I feel like providing that backup can be nice, but also at the same time it’s probably better to just focus on making a website that’s more resilient.

Toby Amodio:

Make it work.

Cole Cornford:

It’s easier said than done, I know.

Toby Amodio:

A lot of cyber controls there is are insane hard to do. Basically brings us to the end, the guidelines for cryptography and the guidelines for data transfers both had some minor grammatical changes which improve the readability but don’t change it overall. So for me, the updates really the general impression away from the updates were that it focuses a lot on some aspirational pieces like the pure coding standards and the embedding of that into our procurement processes. But there’s also on that backend a lot around, how do you ensure that your websites and external services are resilient and not just from the presentation lab, but also from the server backend? Which I think is really, really critical.

Cole Cornford:

Yeah. Cool. So what was your favourite part of all this, mate?

Toby Amodio:

My favourite update had to be the fat-fingering of the 30 character password for the break glass accounts, obviously I do like that, it gave me a little bit of a chuckle. But all jokes aside, I really did enjoy the inclusion of security by design, even though I think it’s impractical to enforce, sometimes having it written down there forces people to think about it.

Cole Cornford:

I mean, I feel like it creates a competitive vector for entities to actually invest in security, right? If I’m in a private sector and I’m producing a software product to give specifically for government, by being able to market that I comply with this thing and giving practices, this means it could be the difference between my product getting selected and someone else’s who choose not to do that kind of thing. So I feel like it will slowly start to make changes in the private sector when you are doing procurement for that because it gives-

Toby Amodio:

And mandating these concepts, yeah.

Cole Cornford:

It’s a carrot, it’s not a stick this one, right? So instead of forcing the government to actually go out there and validate and verify the people are doing these things, instead if someone does validate and verify, then it incentivizes people to pick it, right? So yeah, I feel like if we shift our perspective away from, “I’m going to look at this from a, can I comply with this?”

Toby Amodio:

Compliance and implementability? Yeah, exactly.

Cole Cornford:

Instead of a, “How do I get people who don’t have to follow the ISM but would like to do it to change their behavior?” Then I feel like it actually can be an effective control. So I like that one the best.

Toby Amodio:

I agree, and I think that’s a really great lens to look at it and probably to wrap up because it’s really, how can the ISM then also promote better cultural change, even if it’s in an indirect manner? And I think that this is one of the benefits of it. So again, from my side, I just wanted to thank everyone that contributes to the creation of the ISM. It’s been, as you said, Cole, a vast improvement over even the last couple of years. It’s improved in leaps and bounds, but it’s a completely different beast from what we had five or six years ago. And it is a critical resource for professionals to secure their organizations, not just government, but it is applicable to any entity around the world that would like to uplift the security of their organization. Did you have any closing thoughts?

Cole Cornford:

Yeah, I just want to thank you for coming on and giving your view points about a lot of these as someone who’s actually quite knowledgeable in the space. I thought it would be a really great topic to talk about and I enjoyed going from turning the King’s James version back down to the pocketbook version. It’s been a lot easier for me to digest, so I appreciate you giving up your time. And I also want to thank the ACSC for over the last seven, eight years, really improving the quality of his document, it’s a lot better than it used to be. Thank you.

Toby Amodio:

Yeah, I couldn’t agree more. Thank you so much, Cole, and hopefully I see you in three months when they released the next quarterly update.

Cole Cornford:

Sounds good, mate. All right, catch you later.

Toby Amodio:

Thanks Cole, ciao mate.

Cole Cornford:

Thank you for listening to this episode of Secured. We hope you enjoyed today’s conversation. Don’t forget to follow the podcast on your favourite platform and leave us a review. Want some more content like the above? Why not subscribe to our newsletter at glacyber.com.au/newsletter and get high quality AppSec content straight to your mailbox. Stay safe, stay secure. I’ll see you next episode.