All Posts in Technology

|In: Technology|Last Updated:

Enterprise risk management (ERM) recognizes four responses to risk:

  • Prevent, aka Avoid: Reduce the odds of the risk turning into reality.
  • Mitigate: Reduce the damage should the risk turn into reality.
  • Insure: Share the cost of the damage should the risk turn into reality.
  • Accept, aka Hope: Do nothing, figuring the cost of prevention, mitigation, and insurance exceeds the cost of the damage should the risk turn into reality.

Which brings us back to what you ought to do about ransomware.

Last week’s KJR provided a starting point for recognizing that Accept is an unacceptable response. “Oh, dear, there’s nothing we can do except hope, and pay the ransom if we have to,” is just plain wrong.

In cop shows, kidnappers provide “proof of life” before anyone pays the ransom. There’s no such thing as proof of life following a ransomware attack; no reason to expect attackers to follow through on their restoration promises.

That leaves Prevent, Mitigate, and Insure. This week we’ll go deeper on these subjects, courtesy of my There’s No Such Thing as an IT Project co-author Dave Kaiser. Dave?

# # #

Here are some ways to prevent and mitigate an attack:

Prevent: To reduce the odds of successful ransomware penetration, create a very hard exterior defense:

  • The biggest challenge with ransomware is that most victims have no idea that they’ve been penetrated, let alone when. We’ve seen lags as long as six months between infection and discovery. If you detect it anywhere, infer it’s everywhere.
  • Remove admin rights from all PCs. This is critical, as PCs remain the #1 entry point, mostly via phishing attacks.
  • Block executable files at the firewall so users can’t install them without assistance.
  • Run an enterprise-grade PC/Server protection software system (my company uses Crowd Strike). Norton isn’t an enterprise-grade match for the newer, more sophisticated attacks.
  • Segment your network and have tight rules on what traffic can flow from PCs to your backbone and cloud servers.
  • Require multi-factor authentication for any web-facing email (including Microsoft 365), and for all system logins as well.
  • Filter all email through a filtering service. Even the best of these services can’t eliminate phishing attacks, but they do improve the odds.
  • Conduct quarterly (at least) phishing tests with your employees. Provide additional training for any employee who falls for the simulated attacks. While you’re at it, test your employees for vishing (voice phishing) attacks too.
  • Engage a white-hat service to continually attempt to break into your network. Also conduct an annual deep dive security audit.
  • Put a law firm specializing in this area on retainer. The legal challenges are complex, especially as applicable laws and regulatory requirements vary from state to state.
  • Physical security: For intruders, “tailgating” into a victim’s offices and sitting down at an unoccupied, logged-in computer is still a popular intrusion strategy.
  • Finally, patch, patch, and patch. Patching is critical, especially for preventing zero-day attacks.

Mitigate: To reduce the damage from a ransomware attack, take steps to recognize attacks early and facilitate rapid restoration:

  • Run a tool that monitors the network for suspicious activity. The tool you select should be AI/machine-learning-based, capable of autonomously discovering good versus bad patterns.
  • Deploy honeypots. Only intruders will hit these, warning you you’re being targeted.
  • Snapshot your data frequently. Snapshots can help you determine when malicious encryption began, supporting both data and system recovery. Backup your data too, of course, but when you’re trying to recover it from a ransomware attack, you’ll find snapshots are sometimes more valuable.
  • Establish IT security breach procedures and document trails.
  • Operations staff should practice tabletop ransomware recoveries at random times – “pop quiz” style.
  • Everyone else needs to plan how they’ll limp along until their systems and data have been restored.
  • Make recovery plan updating a CAB (change advisory board) responsibility so recovery plans don’t get outdated.
  • Keep your platforms and applications current. If you don’t or can’t, reinstalling them might not be possible – the versions you were running may no longer be available from the vendor and your installation files may be corrupted. Server snapshots and change logs are essential.

Insure

Buy cyber security insurance. If you do decide paying the ransom is the prudent course of action, and/or you have to pay penalties for one reason or another, it will help defray the costs.  Your cyber insurance company can also provide prevention, mitigation, and response expertise in the event of a breach.

Dave’s last word:

  • Align ransomware recovery priorities with those defined in your business continuity plan. You won’t be able to recover by flipping a switch. Your business continuity plan will help you with triage.
  • Have a forensics firm under contract and on speed dial. You want them to know you and help you prepare for a ransomware hit by determining in advance what logging they’ll need in the event of a breach.
  • Remember that perfect is the enemy of good. Insisting on unbreakable protection will interfere with establishing better protection.

Bob’s sales pitch: Dave and I hope it’s clear that ransomware isn’t an attack on your company’s information technology. It’s an attack on your company.

That’s one more reason the old-fashioned view that IT has to be “aligned” with the business is inadequate. Check out my recent CIO.com article, “The hard truth about business-IT alignment,” for guidance on how to go beyond alignment, to integrate IT into the business.

Comments

|In: Architecture|Last Updated:

I’m working on a (probably) three-part sequence on technical architecture, to be part of the IT Management 101 series I’m writing for CIO.com. As a famous person once said about health care, who knew architecture is so complicated?

This isn’t a substitute for it. It’s more along the lines of stray thoughts you might find helpful in assessing and managing technical architecture in your own organization.

Beware the seductive siren call of metaphor. The parallels between technical architecture and what professional building designers do are limited at best, and dangerous at worst.

The work of professional architects begins with a sketch and ends with blueprints. Technical architects don’t create blueprints, and if they did they would be embracing waterfall methodologies.

Agile methodologies don’t rely on blueprints of any kind. They often do rely on the equivalent of a sketch, but if so it’s the business analyst / internal consultant who draws it.

Crowdsourcing is a dicey way to gather data. Given how much information you’re going to want about each component in your portfolios, crowdsourcing it … sending out questionnaires to subject matter experts … is tempting.

Given that many enterprises can have a thousand or more components across all of their portfolios, crowdsourcing might not just be tempting – it might be unavoidable.

So if you do crowdsource your data-gathering, make sure you educate all of your information sources in the nuances of what you’re looking for.

And, assuming they do complete your questionnaires, curate the daylights out of the information they provide.

Version is data. Currency is information. You should include in your technical architecture database how current each component is, “current” meaning whether it matches what the vendor currently ships (fully current) or, descending through the possibilities, whether it has fallen out of support (obsolete).

Keeping track of which version of a component is deployed in production is relatively straightforward – just make sure than any time the responsible team installs an update they know to update the architecture database to match.

But what you care about is how current the component is, and you can only determine that if you know the product’s full version history, so you can match your production version to its position in that history.

Currency scores are, of course, perishable. As they change each time a vendor issues a new release, someone needs to keep track of this across every commercial product in every portfolio in your architecture.

It isn’t just your technology that has to stay current. You have to keep every piece of information you collect about each component in your architecture current, too.

You collect information about each component of your technical architecture. Some of it is constant. But quite a lot may change over time. For example, you’ll probably want to know how well each application supports the business functions it’s associated with. But business functions change, which means an application’s business function support score changes along with it.

So your information-gathering process has to operate on a cadence that balances the sheer effort required with the rate of decay of information accuracy.

Bob’s last word: Speaking of balancing effort and information it’s tempting to collect a lot of data about each component in the architecture. Tempting, that is, until you pivot from collecting it the first time to updating it on a regular cadence, over and over again.

In the framework I use, I’ve identified about 30 attributes just for the application layer of the architecture. That’s a starting point. An important part of the process is whittling them down to the essentials.

Because 30 is too big a number. Ten will usually do the trick.

Bob’s sales pitch: I’m still whittling down the CIO.com architecture articles to their essentials. I’ll let you know when they’re available for your reading enjoyment.

Comments