Around the globe, car rental companies rely on technology for operating in an efficient and responsive manner. Here at RideWell we use a website and app for making and managing bookings which integrate into our back of house systems, which allows us to manage our fleet, manage customers and receive and make payments. These systems support our core business, which is car hire, and our fleet is special – our point of differentiation is that our fleet is all connected cars, with advanced safety and control features all underpinned by technology. So it follows that cyber risk is something we need to consider, and events around the world confirm this: a ransomware attack on Canadian Discount Car and Truck Rentals in Canada (Abrams, 2021); a report by IBM’s security team highlighting that connected cars are vulnerable to cyber attack (Kosowan, 2020); there are concerns that connected vehicles can be remotely controlled or stolen (Paganini, 2021); as well as attacks seeking to steal sensitive information about customers and staff (Hercher, 2017). This risk assessment is a first step towards protecting us from these threats.

Task

Following on from our recommendation to move to an advanced cyber risk monitoring regime and to adopt a qualitative approach to risk, senior management have requested a risk assessment consulting report comprising of:

1. Perform a risk assessment, identifying the top 5 key assets to the organisation, then produce a risk register and treatment plan per ISO27001 standards. Summarise the process undertaken.
2. Perform a Business Impact Analysis on the top 5 key assets and determine Recovery Time Objective (RTO)/Recovery Point Objectives (RPO), then roduce a continuity and disaster recovery guidance document that provides theoretical high level steps on how to respond to an outage for the top 5 key assets. Summarise the process.
3. Deliver the assets processed in the above summaries.

1 Perform a risk assessment 

This section summarises the process to develop a risk register and treatment plan

Identify five key assets

The five key assets identified were:

• Website/app
• Backend systems
• Cars themselves
• Corporate data
• Email functionality

The rationale for these assets is include in the Business Impact Assessment.

Produce a risk register 

Identify risks

We adopted the approach recommended in my recent presentation, where we focus on the business risks. This was done in workshops with the cyber fusion team and stakeholders from the relevant parts of the business. The cyber fusion team then identified risk sources and actors. Following the recommendation of my recent memo, we will be implementing a qualitative risk assessment methodology. As discussed in the memo, this requires likelihood, consequence and risk scales, and contextualising these to our business can help overcome subjectivity that is inherent in the qualitative approach.

Contextualise likelihood scale

Using the likelihood scale from ISO270005  A.1.1.2.2 (International Organization for Standardization, 2022b, p. 42), we then added statements to allow us to consider the likelihood in the context of RideWell, these are included in the risk matrix. 

Contextualise consequence scale

Using the consequence scale from ISO270005 A.1.1.2.1 (International Organization for Standardization, 2022b, pp. 41-42), we added statements to contextualise each consequence level, included in the risk register section.

Contextualise risk level scale

Using the risk evaluation scale from ISO27005 A.1.2 as a guide (International Organization for Standardization, 2022b, p. 46), we defined our risk scales as:

• Very low (1 – 2) – acceptable as is
• Low (3 – 4) – acceptable as is
• Medium (5 – 9) – tolerable with mitigation measures placed in the medium to long term
• High (10 – 16) – tolerable with mitigation measures placed in the short term
• Very high (20 – 25) – unacceptable, the risk must be treated in the short term to reduce it or we need to avoid it

Create a risk matrix

These scales are now unambiguous with clearly defined levels which do not overlap and are described in objective language (International Organization for Standardization, 2022b, p. 43). This will help our qualitative approach to deliver less subjective and more consistent results because we are using RideWell’s experience, environment and appetite as a guide, not just relying on the assessors’ interpretation of the scales. This is included in the risk matrix section.

Produce a risk treatment plan 

Building on the risk register, the risk treatment plan requires planned treatments, risk owner, due dates and review dates.

Identify treatments

We have decided to implement controls for low risks as there is a potential for escalation from these to higher risk events. For each of the risk sources, treatments were identified in ISO270001 Appendix A, they were also supplemented with practical treatments identified by the cyber fusion team.

Identity risk owner

The risk owner will be responsible for ensuring that treatments are in place, these were identified for each treatment.

Treatment due date and review dates

The treatment due dates are informed by the risk severity and inserted into the register. Finally we agreed on a risk review date one month after the due date of the last treatment.

Populate the risk register

Included in the risk register section

2 Perform a Business Impact Assessment

Summary of BIA

Define business environment 

Due to this being our first BIA, the cyber fusion team has agreed to focus on our top five assets, gathering this information was covered in the risk assessment. We have focused on the tangible assets that are critical for our core business, this suits the risk management maturity of RideWell as we may become overwhelmed in trying to place values on intangibles such as reputation at this stage of our risk journey. 

Information gathering and analysis

For the purposes of our first BIA, the risk assessment has been used for our information and analysis.

Identify business mission

Our business mission is to hire the right car to the right person at the right time. To do this we need to have a channel for contact/booking (website); be able to process bookings (backend systems); have cars to hire out; use data to match customers to cars (corporate data); and be able to communicate with customers (email). Note that this BIA is applicable following the implementation of our risk treatment plan.

Calculate fundamental matrices

Using the information we have gathered, we identified our: Maximum Tolerable Downtime (MTD); Recovery Time Objective (RTO); and Recovery Point Objective (RPO).These are presented in: BIA Output

Disaster recovery guide 

As noted in our BIA, we have very low MTD across our assets, this is a function of our reliance on technology to scale and operate, the dynamic nature of our industry and relatively low staff count. We simply don’t have the people power to manually undertake tasks if any of our five assets are impacted for a period of days (specified in the BIA).

Due to this, our focus in continuity and disaster recovery is on contingency, getting our systems back to operational, however there will be some business continuity activities. This recovery guidance is applicable after we have implemented the recommended treatments in our risk treatment plan, and was created to align with ISO22313 Security and resilience — Business continuity management systems — Guidance on the use, particularly sections: 8.4.4.8 Resumption of prioritized activities, 8.4.4.9 ICT systems and 8.4.5 Recovery. This is presented in the Disaster recovery guide.

3 Deliver assets produced

Risk matrix

Risk Matrix
CONSEQUENSES		Severity	5 – Catastrophic	4 – Critical	3 – Serious	2 – Significant	1 – Minor
		Website/app	Unavailable or unable to accept bookings for more than 3 days	Unavailable or unable to accept bookings  for up to 3 days OR functionality modified	Unavailable or unable to accept bookings for up to 1 day	Unavailable or unable to accept bookings for up to 3 hours OR content modified.	Momentary disruption to availability or ability to accept bookings.
		backend systems for taking bookings	Unavailable or unable to process operational requirements for more than 3 days	Unavailable or unable to process operational requirements for up to 3 days.	Unavailable or unable to process operational requirements for up to 1 day	Unavailable or unable to process operational requirements for up to 3 hours.	Momentary disruption to availability or ability to undertake tasks.
		Cars	Accident resulting in death OR fleet wide  vehicle operation affected	Accident resulting in injury or theft of vehicle OR fleet wide vehicle non-operational systems/data affected	Customer data stolen from synced vehicle OR single vehicle operation affected	Single vehicle non-operational systems/data affected	Evidence of access in logs but no changes to vehicle systems/data.
		Corporate data	Sufficient PII leaked for: identity theft to be performed; or physical acquisition undertaken	Data leaked that can be used for further targeting eg: name and email or telephone number	Data leaked that can associate customers or suppliers with DriveWell	Anonymised data leaked. Could be used in an inference attack on customers or suppliers.	Data accessed but no personal data, IP or financial data accessed or stolen.
		Email unavailable	Unable to send email for over 3 days	Unable to send email for up to 3 days	Unable to receive email for up to 1 day	Unable to send email for up to 1 day	Momentary disruption
LIKELIHOOD	5 – Almost certain	Happens to us often	Very high	Very high	High	High	Medium
	4 – Very likely	Has occurred to us, probably will again	Very high	High	High	Medium	Low
	3 – Likely	Has occurred to us, may again	High	High	Medium	Medium	Low
	2 – Rather unlikely	Has not occurred to us, but may	High	Medium	Medium	Low	Very low
	1 – Unlikely	No known incidents in our industry	Medium	Low	Low	Very low	Very low

Risk register

Below is a screenshot of our risk register and treatment plan.

BIA Output

Asset	Reason	Risk	Recovery Point Objective (RPO)	Recovery Time Objective (RTO)	Maximum Tolerable Downtime (MTD)
Website/app	If our website is down for more than one day, we will begin to suffer financially and have concerns for our reputation. After 1 week of website downtime we would have trouble recovering due to the financial impact.	Website unavailable, website hacked	Last code base change (stored in GIT).	1 day.	3 days.
Backend systems	If our backend systems are down for over a day we would have difficulty in continuing to operate. After 1 week of backend system downtime we would have trouble recovering due to the financial impact and backlog of processing would lead to further lost income.	Backend unavailable, backend hacked	Last code change, backups taken after each.	1 day.	3 days.
Cars	If we could not hire our cars for 1 day, we will begin to suffer financially and have concerns for our reputation. After one week of not being able to hire out cars we would be in a difficult situation.	Cars hacked and control lost/shutdown/data stolen	Last firmware update. Similar to our website, the cars are relatively static when it comes to software requirements.	1 day.	1 week.
Corporate data	If our data is unavailable we cannot place customers with cars. Our website and backend systems will also become non-operational. Without our data systems, neither our website or backend systems can function	Data breach	1 day. These systems include bookings and enquiries, we operate in a dynamic environment where these can change by the minute. One day to the last backup is the most we can realistically catch up on with our small team.	3 hours.	1 day.
Email	Not applicable following our risk treatment plan	Email unavailable	We can now tolerate email being down.	NA	NA

Disaster recovery guide

Asset	Continuity	Recovery
Website/app	Load ‘maintenance’ page informing customers that we are having technical difficulties and to contact us via email or one of our social channels	Spin up a new instance of our websiteTest new instancePoint DNS to new instanceUndertake detection, analysis, containment, eradication and recovery on original instance, report lessons learned.
Backend systems	Load a message onto our website notifying visitors that we are experiencing technical issues and to try again in 30 minutes.If the disruption lasts longer than one hour, update the message to notify them that they may experience a delay using our services – if they need a car today or tomorrow then email us.	Spin up a new instance of our backend systemsTest new instancePoint DNS to new instanceUndertake detection, analysis, containment, eradication and recovery on original instance, report lessons learned.
Cars themselves	Part of our SLA with our supplier of cars is that in the event of a cyber incident, their response team will be on hand to handle the incident. We have a limited availability of emergency vehicles from our supplier, this can cover 70% of our baseline business with a staff requirement 24 hours a day.	Contact supplier response teamProvide assistance as needed to response team Report lessons learned.
Corporate data	Load a message onto our website notifying visitors that we are experiencing technical issues and to try again in 30 minutes.If the disruption lasts longer than one hour, update the message to notify them that they may experience a delay using our services – if they need a car today or tomorrow then email us.	Restore backupsAssess requirements under privacy act if any.
Email functionality	NA	NA