Customer Roadshow

[TITLE: Your Business Optimised. Telstra logo and Telstra Purple logos] 

[INTRODUCTION SLIDE: Your Business Optimised Customer Roadshow 

Optimise Cloud Secuity with AWS and VMWare.] 

KATRINA BURKE: Hello, and thank you for joining us this afternoon after quite a tough act to follow with Todd Sampson. I might encourage you all to take notes with your left hand or something like that just to follow on and rewire the brain. 

But thank you for joining us today with our session around 'Optimising Cloud Security with AWS and VMware'. 

[SLIDE: ‘Our Panel’  – list’s the name of Panel at this breakout session] 

 I'm Katrina Burke and I'm the Partner Development Manager at Telstra from AWS. And I'm also the AWS Emerging Partner Lead across Australia and New Zealand. 

Thanks so much for joining us here in Melbourne today, along with my colleagues from Telstra and VMware, on a topic very dear to our hearts in securing Australian businesses. 

Today we'll be covering how you can improve your security posture through the cloud and a fully funded offer to help you to get started. 

Please hold your questions to the end because we've got a lot to get through, but we'd love to talk to you at the end of the session. 

[SLIDE: The power of three. Joint innovation and investment in our customers]  

Now, these three organizations don't need much of an introduction, but I wanted to highlight that Telstra, AWS and VMware are strategic partners working to transform Australian businesses together. 

I'm sure you're familiar with Telstra, but a little intro into the Telstra Purple team who are the largest-owned Australian tech services business with 1,800 developers across cloud, network and security. 

And AWS, where I'm from, AWS earned the Gartner Leader position in cloud computing for the 11th consecutive year. 

And lastly, VMware, who's not the new kid on the block, 80% of the on-prem workloads are on VMware at this point in time. 

Now to dive into the crux of why we're here today.  

[SLIDE: Quote defining Optimise “The process of making something good or effective as possible”] 

The theme of the roadshow is optimization, and optimizing is often seen as reducing costs. But reducing costs in a complex cyber environment has the potential to cost businesses more. For example, the average downtime a business experiences after a ransomware attack is 7 to 21 days. 

In a previous role, I was a CTO of a business that was hit by a ransomware attack. Now, fortunately, it had limited impact on us as we had a robust disaster recovery backup in place, incorporating components of cloud as a part of that. This meant we were only impacted for about 12 hours. But having said that, I'm also aware of a fairly well-known government department who had a large ransomware attack before Christmas. And now they're only 30% up and running with their applications, and the recovery is costing them millions. And they've still got at least another six months to go. 

So how do we solve for this? For that, I'd like to hand over to Stuart Low, who's Telstra's Security Capability Lead. 

Thanks, Stuart. 

Thank you. 

STUART LOW: Again, tough act to follow. 

[SLIDE: Proactive measures- five resilient controls ] 

So I'm going to talk about a number of things. But before we do that, I'd like to lay out what we're going to do this afternoon. So we're going to talk about two elements to building optimized or resilient services.  

[SLIDE: A multi-layered approach to cybersecurity] 

And there are two elements to it. One is what we call the 'proactive controls', what we can do before anything bad happens and to stop bad things from happening. Then we'll also cover off the reactive of when something bad does happen, how do we recover quickly. 

Look, before I start, I'd like to get a volunteer. 

[SLIDE: When you hear “Disaster Recovery” is this what you think of? Slide shows photos] 

 I just saw everyone just go, "Not me, please." Don't worry, you don't have to come up. I just would like somebody to set a timer on their phone, please. I've got a volunteer. We've got two volunteers for eight minutes. We'll see why in a minute. 

So while we're doing that, so I'm going to talk about resilience to start with. 

To ensure a system's security, it must possess resilience. 

A resilient system, by definition, can withstand or recover from an incident. 

And in ICT, we immediately go to the recover, and we immediately think of disaster recovery. 

Now, the first time I came across a disaster recovery was when I was working at the Electricity Commission many years ago. We had a computer room. We didn't have data centres in those days, and this was on level two. On level three, we had a staff cafeteria just like me, a relic of the past. And one day, we had a blocked drain in the commercial dishwasher there, which led to flooding on level three, which meant water flowed downhill and it ended up in the computer room. And we had to enact a disaster recovery plan because power and water didn't really mix. So we shut down the computer system. We then spent a lot of time mopping up with buckets with large fans. We had tarpaulins. And the idea was to recover as quickly as we could. 

But things have changed. We now have a different category that we didn't have back then, which is ransomware. 

[SLIDE: Disaster recovery events. Text shown: #1 cause of disaster recovery events is ransomware. Twice more likely than natural disasters.] 

Ransomware is now responsible for more disaster, enacting more disaster recovery than we have ever had. And to do that, we need a different approach. We don't need buckets and mops anymore. We need to be able to work out how do we respond from this.  

[SLIDE: Top fice resilient controls. 1. Secure Design, 2. Security Hygiene, 3. Security Monitoring, 4. Incident Response Plan, 5. Backup] 

But wouldn't it be great if we didn't have to respond at all, that we could set up a secure or resilient system that could withstand these attacks? 

So I'm going to talk about the withstand part here. So how do we do this? There's a lot of frameworks that can provide guidance for us. We know that there's the essential eight. There's the critical ten. There's the ASD 37. We have NIST. We have ISO. We have OWASP. We have APRA. We have lots of frameworks that can give us guidance to build secure systems. But what we find is a lot of these have a number of underlying principles that are common to each of them. 

[SLIDE: Secure Design & Hygiene] 

And we're going to just cover these as quickly as we can. I like to start with what I call a 'secure mindset', so designing something securely. I have a thing called the '10% rule'. That means that security is 10% of everything that you do. So if you're launching an application, you are building a new system, think of what is the security component to it. And it should be, on average, 10% of everything you do. So using the systems that you either have internally or building security into those systems. And we know how to do that. 

So what we do is we then build, we segregate our data, we have segregated services, we have secure applications, and there's lots of good frameworks for that. We secure our devices, we secure our users, and then we use things like multifactor authentication. And I know that Phil from AWS was asking everyone to enact that. A lot of the large data breaches recently were as the result of credential compromise, user and password. And people were able to compromise these systems remotely just with a username and password. There was no multifactor authentication enacted. So use multifactor authentication. 

Now, we build system securely. So what do we do next? Last year, there were 18,353 new vulnerabilities published, up from 13% from the year before. This year, we will break it again, which means that systems are not static. We have to keep them patched. And I know everyone probably rolls their eyes and goes, "Patching, this is the most boring thing," but it is the most critical thing. So we have to keep our security watered and fed. It is not static. 

And we go to the next one.  

[SLIDE: Back up] 

Now, when I worked for a... Let's see. There was a large government. I won't tell you who it was, but it was a large government department. I was doing consultancy for their security operations team. I remember the day we had our first CryptoLocker event. Now, this is sort of like ransomware 1.0. And we had good monitoring in place, so we were able to detect that when this happened. 

Extensively, they used shared drives, which meant that when that one device was impacted, it impacted a whole lot of users. So the blast radius was quite large. We were able to identify this device. We were able to quarantine the device. Then we went about the recovery process. So we went about that whole recovering from backup. Now, this took us about 24 hours. We thought it should have taken us about six to eight hours, but we hadn't practised this a lot. 

We then had a lot of senior managers that thought, "Oh, CryptoLocker, this sounds cool." And then they came down to help us. And that's just delayed the recovery unnecessarily. However, despite better controls that we put in place and better user training, I always say stupidity finds a way. And we were getting CryptoLocker events probably about once a week. What does that mean? After about six months, we were really, really good at recovering from CryptoLocker events. We got this down to like an hour, which we thought, "This is great," but the fact that we still had people clicking on things when we told them not to or weren't able to block it for whatever reason. But it showed us the importance of a backup. Not only that, we could recover the data, but then we thought to ourselves, what would happen if this backup was compromised? 

So we then had to look at the access to the backup, the types of backups that we had, where they were, where they were being stored. If that backup was compromised, did we have a backup of a backup? So it did start to make us question, do we have those right things in place? 

So we had good monitoring, good incident response. So it's a bit like a muscle. If you don't exercise it, it will atrophy. And when you go to use it, it's just not there. 

How are we going for time, timekeeper? We've got one minute 30. That's great. 

So what I'd like to do, just like in summary, I talk about, you know, you design it securely or build it securely. So think of that 10% rule. If there's one thing you take away from today, the 10% rule. Always question, even if you are in security and you're not invited to a project, always ask that question. Threats are not static. Always think of patching your systems. What are those threats? If your systems change in any way, architecture changes. Again, think of what do I need to do to keep it secure. Do not have blind spots. Make sure you have monitoring. If you don't have monitoring, enact monitoring. This doesn't mean necessarily having a security operations centre there. Having good logging, having good alerting, there are great tools around to do that. Incident response, it is like the new fire drill. You have to keep it exercised, and backups, backups, backups, backups. 

And I think we're just about at time, pretty close. And why did I say eight minutes? Two reasons. 

One, I had eight minutes to talk. So it was a really good way of making sure I didn't go over. 

The other is that every eight minutes in Australia, there is a security breach. Last year, the ACSC had 76,000 reported security breaches. So every eight minutes, that is how many security breaches. So we've had one since I started and we'll have another three before I finish. 

So with that, I would like to bring up our next speakers, who are Michael and Nathan. 

Thank you. 

[SLIDE: Proactive measures – enhanced security through AWS in the Cloud.]  

Thank you. 

NATHAN WHEAT: Alright, so I'll start off today and Michael will take over some parts of the session. So we're going to talk about the proactive measures that you can take by enhancing your security through AWS in the cloud. I'll start by setting the context. 

[SLIDE: Why is on-premises security traditionally challenging ] 

The reality is that security is not a new conversation and a lot of systems that run on-premises aren't well secured. Why is that? Why is there a difference? One of the main reasons is that on-premises systems have been built in project chunks over a long period of time. They're a decade old or more. There are complex, layered approach to multiple technologies from multiple sources implemented at multiple times, which means you have very little visibility through the entire stack of technology, from your applications to your network to your storage to your hypervisor. They're all being put together by you as a customer. So you've got a unique blend of technologies that have been built in discrete efforts over a long period of time. When we do cloud migration assessments, it's almost always the case that customers are surprised by what you do during discovery. 

They go, "Oh, that's right, I forgot about those systems over there in the corner." The other thing that makes on-premises environments hard is that they're not fully automated most of the time. Some of that is because the technology isn't API first; it's built with consoles, human intervention as the default way to manage the environments. 

A term that was used in the general session this afternoon, earlier on was single pane of glass, and that's been a mentality that exists in on-premises environments which, if you kind of break it down a little bit, means a human is looking at a screen, operating a bunch of buttons. And that's been the default of how on-premises security is also being done. 

So visibility, lack of automation means that things become inconsistent, they become opaque, and they become therefore very hard to secure. So what we propose is instead of in the past, you would either have the choice of innovating and moving quickly and therefore opening yourself up to security problems because you're moving faster than these humans and these tools can keep up with change or you stay secure and you move at the pace that the security team allows you to go through change, review boards, architectural approvals, implementation and operationalization of new technologies. 

But you couldn't have both. You couldn't innovate quickly and be secure at the same time. And what we're proposing is that you can. So we think that through using cloud services, AWS and Telstra's implementation thereof,  

[SLIDE: Move fast AND stay secure] 

that we can help you to move fast, implement the bleeding edge, innovative value, creating things that you want to do and keep security up with that journey as you go through. 

Part of that is the services that you automatically inherit by using a cloud provider like AWS. So we have a global network of multiple data centers in multiple regions.  

[SLIDE: Infrastructure & services to elevate your security] 

We have a global network that we ensure is providing encryption of data in motion between locations inside of your private environment. 

We have physical data centres that we provide. The security guards, I think, was Stuart's reference there. No, sorry, that was during the panel discussion where somebody talked about having a security guard as their version of security. That's stuff that is physically happening inside of Amazon day in, day out. The resilience that you get that's provided by our services means that we're able to take care of a lot of the lower-level layers. So you inherit the compliance rules or the compliance frameworks that we've already gone through. PCI, the payment card industry, data security standard, APRA validation, IRAP validation, all of the security measures that you would like to have done in your environments, but it's very expensive to do, are automatically there underneath the covers in AWS infrastructure. 

And everything has been built with three key principles in mind in Amazon. First, job number zero, priority zero is security. We can't afford to not have security at the front of the mind whenever we implement a service. The second is scale. We implement things as a cloud provider that are intended to be used by our millions of active customers all the time. And so, therefore, that brings in the third principle, which is everything is automated by default. There's very little that we do other than carrying bits of hardware in our physical data centres that humans are involved in. Everything is based on APIs, scale analytics. And if anyone's used AWS, you've got services like CloudWatch, CloudTrail, AWS Config that automatically can inspect the entire environment from who's coming in, where's your data at all times, and if anything goes wrong, what happened to change that fact. 

[SLIDE: Shared responsibility model] 

We do this through a shared responsibility model. So it's our job to make sure that the cloud services and the physical infrastructure that we provide and the technology that you're accessing is secured by us, so that security of the cloud. 

And that's our role is to make sure that if you're going to use a service like Elastic Compute Cloud or the storage services that they have encryption and security built in from the start, and that we are encouraging you to use services that provide very fundamental capabilities. 

Then there's your responsibility as a customer, which is, as you use those services, to use them in a secure way, and that's security in the cloud. And so they're your particular applications, your particular data, your particular set of identities and access rules, and to help you do that part of it, while it is your responsibility. And again, Telstra would be there to take their expertise into your environments. 

Phil Rodrigues earlier talked about the well-architected framework, which is part of how do you build that maturity into your environment so that you're being guided through that process. 

[SLIDE: How do I get to the Cloud] 

So why are we here talking about AWS, VMware, and Telstra? How do you get into the cloud? What people are hearing and why they're attending sessions like Telstra's event today is all the latest technologies, AI, and creating value for the business. But what you have today as the very first Slides made clear was that most technologies are still running on VMware if they're in the data centre today, 81%. 

So Andy Jassy famously has been quoted as saying that most customers, as they use the cloud, they're coming from an in-built on-premises environment, and they'll be in a hybrid state for some period of time. That hybridity is partially about where your systems exist, but more importantly, it's about the architecture and the operating processes that you've used to manage your environment. And you'll be in a dual state for some time. 

And that's where VMware Cloud on AWS comes into the conversation. And we find that when customers use VMware's technology that take advantage of the infrastructure and the frameworks that are provided by AWS, they can innovate and use more advanced cloud services because everything's co-located, fully integrated, adjacent to each other, no matter where you are in that hybrid mix of technologies. 

Michael, do you want to talk about the migration speed there?  

MICHAEL HUYNH: Yeah, absolutely, Nathan so we've worked really closely with both VMware and AWS for the last four and a half years. The service VMware Cloud on AWS has existed for five and a bit years. So we're somewhat of an early adopter of this technology. 

And as we've taken our customers on this journey, what we've found is that not only do we migrate faster, we end up migrating more of those workloads into the cloud and we remove what AWS call the great stall. So when you start a project and then you run into something difficult, sometimes it stalls the project and it overruns, right? 

The other part is that when we have taken customers on this journey, you move from an operate and manage model to a model where the management of the platform is done for you by VMware and AWS. So we talked a little bit before about security in the cloud and security of the cloud. 

I guess the security of the cloud component is taken care of for you when you move into this platform. So all the patching, life cycling of the VMware platform, etc., is somewhat taken care of for you. And that frees up time, frees up time for your valuable employees to take advantage of that. And they can invest that time back into learning the native AWS services. And that's what we see as an enabler for the accelerated native service adoption. 

So if you're not doing lots of things at the same time and you can concentrate more time on transformation, you'll get that sort of done a little bit quicker.  

NATHAN WHEAT: Yeah, and just to double-click on what you've mentioned there, a lot of customers have VMware Technologies that just work, and that's one thing that VMware has been known for 20 years is it does what it says. 

The unfortunate consequence of that is that nearly half the customers are running on really old versions of the Hypervisor and really old hardware. Who's patched the firmware, who's patched VMware, who's been looking and reviewing the environment? Probably very little attention is being paid to that because it works, and it's risky to introduce changes all the time to these fundamental layers. 

VMware Cloud provides that evergreen platform. It's patched and managed by VMware every day so that you don't have to do that. 

But it's always up to date, and you don't have to wait until the security incidents that Stuart's been talking about hit you before somebody says, "Actually, that was a version 6.7 hypervisor. We knew it had vulnerabilities, but it was really stable." 

SLIDE: Migrate and mordernise application portfolio 

MICHAEL HUYNH: So a really good example of that is, I guess... I don't know if anyone remembers the Log4j vulnerability issue that we had. Our customers on VMware Cloud on AWS had their entire platform patched over a weekend. So when they came back in on the Monday, the platform side was patched for them, not the OS. 

The OS is something that is the customer's responsibility, and they still had to take care of that. But half the job is sort of done for you, and it's all done via automation. And it was something that we really noticed that was absolutely a benefit of the platform. 

NATHAN WHEAT: We've been running the service here in Australia for four years now, five years? Yes, five years. And we used to talk about the number of updates that were happening, but it's just a continuous stream of people applying updates, changes, patches, replacing hardware all under the covers, and we just don't even kind of focus on that anymore. 

At AWS, we're encouraging all customers to innovate, to create value through exploring new technologies. We do the innovation and introduce a service for customers to consume very easily. We do a lot of the innovation so that you don't have to reinvent everything every time. 

So we talk about this journey of migrate to modernize, and modernization and innovation is the tail end of that. What we achieve by bringing the VMware-based environment into the cloud is at least half of that conversation. So we're able to migrate the environment, take care of the bottom layers, everything from the VMware environment down through networking storage, physical security, hardware, green kind of currency away so that you've got a whole lot of time that your staff don't have to spend just keeping the hamster wheel running. 

The second part is that we help you to shift your investments to the cloud models that you're all trying to do. 

So instead of locking up your CapEx budgets every three to five years in these massive projects to kind of stay still, you can start to shift that spend and that attention, the organizational attention to the cloud projects. So VMware becomes just another cloud project, but it has all the applications and data that you need to access as you're implementing new initiatives. 

And the last one is that you're ending up on a scalable cloud infrastructure. So you don't have to do capacity projections for the next three years so that you know what you need to buy for today. You scale on demand. So if you've got demands that scale up your business, universities have enrollment times, the ATO has tax times, every business has times where fluctuations happen, and you've got access to that elastic cloud infrastructure. Even if the traditional application architecture is three three-tier models based on VMware as the stable hypervisor and monolithic applications, you can still use that scale and elasticity. 

And Michael, do you want to talk about some of the ways that innovative services? 

MICHAEL HUYNH: Yeah, absolutely, Nathan. 

So I guess the VMware story with VMware Cloud on AWS is only half the story. And what we do is once we move customers onto this platform, they are adjacent to the 200-plus native AWS services that will help them drive further transformation within their environment. So, examples of that are the data services that would not be available to you on an IaaS platform that's on-premise. Now you're next to them, right? It's low latency, high bandwidth connections within the AWS network that connects you, and you get to blend and I guess get the best of both worlds, so to speak, right? So as you're going on the start of the journey, your staff get to operate the environment the way that they've been used to on-premise, and over time, they can invest more of that time into the native services to drive real outcomes. 

NATHAN WHEAT: Yeah, fantastic. 

[SLIDE: Stage approach to modernization via VMC] 

Michael, do you want to talk about this staged approach to modernization and how it differs from what many people would think of as cloud adoption? 

MICHAEL HUYNH: Sure, sure. 

So I might actually use a customer case study to sort of describe this. And the customer that I'm thinking of here is Golding Contractors, right? We took them on this journey. And for Golding, one of the key things that they wanted to do was uplift their DR capability. 

They didn't have it on-premise. It was too costly. Traditionally, if you wanted DR, you had to stand up a duplicate environment in another data centre. The same amount of compute in a duplicate data centre, the same amount of storage, etc. Golding also wanted access to these AWS native services to help them with their app transformation. 

So what we did was we proposed VMware Cloud on AWS, as well as another technology set called 'VCDR' or VMware Cloud Disaster Recovery. 

So they were on premises, and the migration path was fairly seamless. The same VMs that ran on-premises were moved into VMWare Cloud on AWS. We put them adjacent to the native services, and implemented Veeam which ran in EC2. We made sure that their backups were immutable using Object Locks in S3. We also introduced VCDR which gave them the ability to recover in a secondary datacentre and only pay for that compute when they most need it.  

And there's more to that story, but I'll let Paul Woodward sort of take us a little bit further into the VCDR journey and the technology that that brings. 

NATHAN WHEAT: Alright, and Telstra's offering. 

[SLIDE: Telstra Managed Service for VMC] 

And what you can hear from that story is that Golding is an example customer, and there are many of them, who were able to digest the change that was being introduced to their organization. One of the hardest things for cloud adopters to do is to just completely wipe the slate clean and do everything again. There is value in the systems that have been running the business for ten years. There's value in stability. There's value in the operational team that keeps that alive. 

So while the aspiration is to become cloud natives in your own right, there's a transition journey. And so Golding is a great example of combining those kind of approaches, the combination of technologies and architectures in a cohesive way. That means you have all the access to the latest and greatest technologies, the innovations that we create as cloud providers and the things that have kept your business stable and running and reliable and servicing your customers for decades.  

And Telstra adds even further layers on top of that. 

MICHAEL HUYNH: Yeah, so we spoke a little bit before about security in the cloud and security of the cloud. 

So shared responsibility model, and some of that responsibility is the customer's responsibility. 

And where you may not necessarily have those skills or you just don't have the capacity, Telstra-managed services are there to sort of augment that part for you. We can take care of some of those responsibilities that you have in the cloud. 

NATHAN WHEAT: Yeah, fantastic. 

So we've mentioned a couple of times, disaster recovery is a service and ransomware and how that ties into this conversation. 

So with that, we're going to bring Paul Woodward up on stage to talk about a deeper dive into that particular dimension here. 

So, Paul. 

[SLIDE: Reactive measures – Disaster Recovery through VMWare Cloud DR (VCDR)] 

PAUL WOODWARD: Thanks very much. 

Thank you. 

Thanks, guys. 

And look, I guess what I'm going to talk about here, we're just going to hark back to something Stuart showed you.  

And I'm going to labor on this just a moment because what he showed here, not only is it the frequency of occurrence of these types of events, it's the fact that these types of events require a very different approach, right? 

[SLIDE: Disaster recovery events] 

Fundamentally, we've all been building infrastructure. And hopefully, most of you are VMware customers either today or have been in the past. You've used VMware Technologies across multiple data centres to save yourselves in the case of a disaster. 

Now, unfortunately, the new types of disaster, no longer we're talking about power failures, hardware failures, systems failures where maybe it's human error, where critical systems go down. And we're actually in a position where, potentially, there's been a bad actor or some sort of attack, we call it maybe - it's referred to as ransomware. But really, I would argue, to broaden that category to a cyber incident has occurred, right? 

So you're a customer, you've had a cyber incident occur. The number one thing that happens is a forensic team is going to come in and they're going to ask you to turn it all off. They're going to shut it down. 

The unknown then is what happened, when did it happen, and how do we get back to good? 

Now, this is very different from a typical disaster event. And that's why, unfortunately, more and more of this is occurring. So it takes a different type of approach. 

And we've been working with customers for many years around disaster recovery. 

VCDR is a technology that we acquired through a company called Datrium. We've been using this technology now, and we've built a new type of disaster recovery using this technology that allows us to provide a solution that can cater to this type of concern. 

So how does it work? 

[SLIDE: VMWare Cloud Disaster Recovery On-Demand DRaaS] 

Fundamentally, what we've got here on the left-hand side is our production site. 

That site can be on-premise. It can be in a cloud, any VMware footprint. 

Now, we're going to protect that site. 

That's our protected site. 

We might have multiple protected sites. 

So we're going to put in an appliance into that protected site. And much like VMware Site Recovery or SRM, if you've used it before, we're going to selectively choose to protect some of those VMs at that site. 

We may fan in multiple sites, but ultimately, we're going to take the information on those VMs. And like any sort of typical protection technology, we're going to replicate that. This time, though, we're going to replicate it into what we call a scale-out file system. This is the technology we acquired. We happen to operate, build, and do that on top of the AWS platform. It's a great place to build. If you're not building there already, you should think about it. 

We built our technology there on the basis that we could provide a very cost-effective recovery place where instead of having to require you to have two sets of infrastructure running all the time, you could have your primary site set of infrastructure. Your secondary site becomes our cloud scale-out file system, just a storage system. So we're not going to run compute, we're not going to scale up our compute. SRM does have some limitations in that respect in relation to you needing compute memory and CPU running all the time. That makes it a little bit more costly. So this is a different type of approach. 

The other key thing here is you've got a SaaS orchestrator. So this is a SaaS-delivered service, immutable storage provided to you as a service by VMware on top of AWS. And this allows you to build those policies that runbook in order to bring up your virtual machines. And then what we do is we've got this ability to, and we've talked a little bit about VMC, we've got an ability to define a recovery location. And in this scenario, we're going to use VMC. So, VMC, we're going to, with our technology, instantly power on the VMs off the scale-out file system. So those VMs are available in power-up time, so minutes, right? And then we're going to move those VMs from the scale-out file system onto the vSAN storage in VMC. That allows us to quickly recover into a new isolated environment, our recovery software-defined data center or SDDC that can be potentially completely new. 

Now when we talk back to the failure scenario, you've been told to turn everything off, well, we can stand up an SDDC in VMC on AWS within two hours. So within two hours, you've got a clean net new environment to go from. You can start powering on your VMs. And this really provides a very different approach to DR on the basis that you're able to actually establish a new environment to build within. 

[SLIDE: Reactive measures – Ransomware Recovery as-as-Service] 

Now, the cybersecurity events, though, put this in light. 

You know, historically, we've had a disaster. 

First thing we're going to do is when are we going to back up? 

When are we going to go back to? 

[SLIDE: The need for Ransomware Recovery as-a-service] 

Well, the real concern is that most of the times, customers have no idea how far back they need to go in order to escape the cyber event that occurred. 

A lot of these attacks are no longer your typical ransomware or encryption CryptoLocker-type attacks. 

Most are in memory attacks that aren't easily trackable and traceable. 

And so going back in time requires your operational team to sit down with the forensics team and start bringing up recoveries, bringing up recoveries, start going back in time. 

This is not a solution that works well with traditional backup, unfortunately. 

You are recovering data and you're recovering lots of data going back in time, getting into the time machine. 

So because of that, we're seeing a lot of customers take weeks to months to recover systems that would have otherwise, in a typical disaster, been recovered very quickly. 

And sometimes they run out of time. They just recover the best version they can and they lose data. 

So the acceptance of data loss is something that in traditional disasters, we just say, "No, we're not losing any data. We're going to have an RPO of 30 seconds. We're never going to lose any data." 

But the reality is a lot of customers do lose data. 

And I think this recovery time, we've got to shrink this recovery time. We want to get those systems back up as quickly as possible. 

So what we did to solve this is really build ransomware recovery into the solution. 

[SLIDE: Top challenges in ransomware recovery] 

So we provide a way in order to actually validate restore points. 

As you're bringing up those restore points, you can actually validate them. 

Now, the way we do that is obviously, again, fileless attacks. 

We need to power on the VMs. 

We need to power on the VMs in an isolated environment to actually have a look at them and inspect them. 

Now, normally you wouldn't do that in a typical infrastructure because you're potentially infecting the rest of the environment. 

And then, you need to sort of limit that data loss by instantly powering on those VMs, creating that recovery environment so you can actually go through and quickly look at your VMs and identify what's the right candidate. 

And once you've identified a clean candidate, then promote that into production. 

So the add-on actually allows you to do that within VCDR. 

This is completely built-in as an optional service within VCDR to actually let you curate your systems and go through those. 

And really, from that perspective, it provides you a really good way to recover because disaster recovery is not so much about the disaster, it's about the recovery. 

It's about recovering quickly and it's about responding to the new types of threats and dangers. 

And VMC is a great location to recover, but again, it's a VMware SDDC. 

So you may choose to recover into VMC, but we give you the flexibility that you may then want to Delta Failback. 

So we support replicating those machines back to on-premise so that you can then recover on-premise. 

And that provides you the ability not just to do DR in the cloud, but then start to do automation around DR in the cloud. 

And with that, I'll hand back to Katrina. 

[SLIDE: Funding & Telstra offer] 

KATRINA BURKE: Thank you very much. Thank you very much. 

Alright, we're quickly running out of time, but most importantly, the deal. 

So you're probably wondering, this all sounds great, but where do I start? 

And I know, when I was in your shoes, I was thinking, "If only I knew what I know now back then." 

And the good news is you don't have to know it because we're here to support you. 

[SLIDE: Reduce entry barriers in your journey towards successful digital transformation.] 

So AWS has a migration strategy that we've done with thousands of customers globally, and it's a very clear process that we'd like to take you through. 

Number one is building the business case, helping you to have a look at your environment from a cloud application perspective and see what are the real benefits that you can get out of moving to the cloud. 

And the good news is that that is funded through AWS, up to $80,000 run by Telstra Purple to do that business case with you to create a momentum for change. 

The good news also is that you don't have to make a commitment. There's no strings attached, but we know it creates a compelling event for change for your business. 

The next step is running the mobilization. 

So this is actually doing the planning. 

And that's the most critical thing of a successful migration, is doing the planning properly. 

And that's planning out what your security is going to look like, how your applications are going to move, and how you can use the best of what you've seen today. 

And finally, the migrate - and importantly, $150,000 of funding from AWS to do that. 

Finally, the migrate, up to $400,000 to help you to actually do the migration. 

And the other good news is if you've got Telstra tech funds, they stack on top of that funding because we want to make the bar as low as possible for you to get into the cloud, to secure your environments and make the most out of what the cloud has to offer to help you to innovate in your business rather than worrying about the security of your environment. 

So that is a wrap for today. 

Thank you, everybody, for your time. 

Most appreciated. 

[Your Business Optimised. Telstra and Telstra Purple logo]