What Lane Roush’s Arctic Wolf Perspective Means for CIOs Running a Digital Transformation

If you searched for Lane Roush, you are most likely looking for the Arctic Wolf security leadership view on where digital transformation programs come unstuck. The short version is that transformation moves the attack surface faster than most security operating models move, and the gap between “we deployed it” and “we can see it” is where incidents live.

REDD sat down with Arctic Wolf executives Lane Roush and Steve Craig to talk through global security trends and what they mean for Australian and New Zealand organisations. You can watch that conversation in full on our discussion with Arctic Wolf executives Lane Roush and Steve Craig. The rest of this article is the practical part: what a CIO actually decides, and in what order.

The real problem in a transformation program

Transformation work adds systems faster than it retires them. A twelve month program typically means a new ERP or finance platform, a cloud migration, an identity change, a handful of SaaS tools each division bought on its own, and remote access patterns that did not exist last year.

Each of those is a new set of logs, a new set of admin accounts and a new set of integrations. The security team usually finds out about them after go live. That is not a people problem, it is a sequencing problem.

The three failure modes we see repeatedly:

• Identity sprawl. Old accounts in the legacy system stay live “just in case” during parallel running, and nobody closes them.
• Blind spots in logging. The new platform is monitored by the vendor’s own dashboard, which nobody in your organisation looks at outside business hours.
• Integration accounts with no owner. Service accounts created for a data migration, with broad permissions and passwords that never rotate.

Sequence security into the program, not after it

The cheapest time to fix any of the above is before cutover. A workable order looks like this.

1. Inventory before you migrate. You cannot protect what is not on a list. Applications, data stores, admin accounts, third party connections.
2. Decide identity first. Single sign on and multi factor authentication for every new platform should be a go live condition, not a phase two item.
3. Define what gets logged and where it goes before the platform is configured, not after. Retrofitting log forwarding on a live ERP is painful.
4. Agree who watches it out of hours. Attackers work weekends. Most internal IT teams do not.
5. Run the incident scenario once while the project team still exists and still remembers how everything was wired.

The Australian Signals Directorate’s Essential Eight is a reasonable spine for steps two to four, because it gives you maturity levels you can point at in a board paper rather than a vague assurance that things are “secure”.

Choosing how monitoring gets done

This is the decision most CIOs are actually weighing when they start reading about security operations vendors. The options compare on a small number of criteria.

	Build internal SOC	Managed detection and response	Managed IT provider with security built in	Tool only, no service
Time to useful coverage	Longest, hiring dependent	Weeks	Weeks, if they already run your environment	Immediate install, slow to value
After hours coverage	Needs 24/7 roster	Included	Depends on provider	None unless you staff it
Who tunes out false alerts	You	Provider	Provider	You
Context on your environment	Highest	Lowest at the start	High	None
Ongoing cost shape	Salaries, hard to flex	Subscription per user or device	Bundled into managed service	Licence only, hidden labour cost
Main risk	Key person leaves	Alerts land with nobody to action them	Provider capability varies widely	Shelfware

The fourth column is worth dwelling on. Plenty of organisations buy a detection tool during transformation because it was on the project budget line, then discover nobody owns the alerts it generates. A tool without a response path is a log file with a nicer interface.

Where REDD sits in this is on the service side: managed technology for the day to day environment, and cyber security services for the detection, response and uplift work that sits over it.

Questions worth asking any provider

Ask these before you compare prices, because the answers change what you are comparing.

• What exactly do you monitor, and what is explicitly out of scope? Get the out of scope list in writing.
• When something is detected at 2am on a Sunday, who does what? Name the action, not the notification.
• Can you isolate a compromised device, or can you only tell us about it?
• What do you need from us to onboard, and how long does that take realistically?
• During our transformation, how do new systems get added to coverage, and does that change the price mid term?
• What happens to our data and logs if we leave?

A provider who answers the isolation question honestly is more useful than one who answers it enthusiastically.

The reporting obligation nobody plans for

If personal information is involved and there is a likely risk of serious harm, you have notification obligations under the Notifiable Data Breaches scheme administered by the Office of the Australian Information Commissioner. The assessment clock starts when you become aware there may have been a breach, not when you finish investigating.

During a transformation this gets harder, because data is often sitting in two places at once and the answer to “whose system was it in” is genuinely unclear. Decide in advance who makes the notification call, and make sure that person is not the same person doing the technical response at 2am.

What to do with a transformation already underway

You do not need to stop the program. Pick the three highest risk systems in the migration, confirm MFA and logging on those, and get after hours eyes on them. Then work outwards.

If you want to see how other executives are thinking about this, the Arctic Wolf conversation sits alongside other interviews we have recorded with security and business leaders. And if you would rather talk through your specific program than watch a video, get in touch.

FAQ

Do we need a security provider if our cloud vendor already includes security features?

The features are real, but they are configuration options, not an operating model. Someone still has to turn them on correctly, watch what they produce, and act when they fire. That someone is either your team or a provider.

Should we do the transformation first and the security uplift after?

It is usually more expensive that way. Retrofitting identity controls and logging into live production systems means change windows, user disruption and rework of integrations that were built assuming looser permissions.

How do we brief the board on this without overstating the risk?

Use a framework with levels rather than adjectives. Saying you are at Essential Eight maturity level one on three controls and targeting level two by a set date is a conversation a board can act on. Saying the environment is “secure” is not.