All Posts in Technology

|In: Architecture|Last Updated:

Last week, posing as Tinkerbell, I asked you to let me know if you still find KJR valuable. Hundreds of readers took the time to answer in the affirmative.

For a writer, there’s no greater gift than having an audience. Thank you all for letting me know my weekly sermons are still useful.

# # #

I guess I’ll have to publish it here.

You might have already seen the now-not-so-recent piece on The Wall Street Journal’s editorial page, titled “It’s Time to Get Rid of the IT Department.” (Joe Peppard, 11/27/2021).

It isn’t all that different from Nicholas Carr’s tiresome and business-illiterate “IT Doesn’t Matter,” which, in 2003, led to his earning the Rocky and Bullwinkle Wrongway Peachfuzz award for polar opposite prediction. After all, here in the present, IT saved the world economy by enabling remote work during the COVID-19 pandemic.

That was after it became the centerpiece of business strategy, driving the Digital revolution.

Highly visible yet profoundly wrong ideas, even if they’re mere rehashes, require rebuttal, but the WSJ, by editorial page policy, doesn’t accept rebuttals. I guess they don’t like to be contradicted.

So I’ll have to publish my nominees for Mr. Peppard’s wrongest propositions here. Feel free to share.

Proposition #1: IT is a box on the org chart, with its own management hierarchy and budget, and that’s a problem.

KJR rebuttal: If a box, managers, and a budget are problems, they’re problems for every business function in the enterprise. Why single out IT?

Proposition #2: IT-as-partner is a bad thing. And I quote, The problem starts with what I think of as the “partnership engagement model” … While intuitively appealing  this model positions the IT island as a supplier, mandated to build IT solutions and deliver services to the mainland.

KJR rebuttal: Say what? IT as partner … more precisely, IT as partner in achieving intentional business change … is the polar opposite of IT as supplier to internal customers.

Proposition #3: IT is measured on inputs, not outputs. Examples: money spent, system availability, project completion rates, and, OMG! deploying technology on time, on budget and meeting the specs. These don’t, Mr. Peppard tells us, correlate with success.

KJR rebuttal: So fix the metrics. The solution to measuring something wrong isn’t to eliminate what’s being measured. And oh, by the way, if the specs are right, meeting them does correlate with success. If the specs turn out to be wrong, fix the process used to create the specs.

Proposition #4: The Crystal Ball conundrum. And I quote: The partnership model also assumes that it’s possible for the various corporate units to define upfront and many months in advance exactly what they will need from the IT department. The assumption is reinforced by the demands of the traditional yearly budgeting process.

KJR rebuttal: The problem isn’t reinforced by the annual budgeting process. It’s caused by the annual budgeting process. Solution: Fix the annual budgeting process.

Proposition #5: Decentralizing technology also requires some centralization. And I quote, excerpted from an account of an organization that supposedly has eliminated IT: Everybody has to use the same security protocols and software programming languages, and conform to a prescribed architectural blueprint when building digital products and solutions. But within those guardrails, employees have the scope to do whatever is necessary to get the job done.

KJR rebuttal: Presumably, these security protocols, languages, and architectural blueprint are created and maintained by IT professionals, who also establish protocols for assuring compliance. Presumably, these IT professionals live in a box somewhere on the org chart. What should we call that box? Wait … I know! … my hand is raised – call on me! … let’s call it “Information Technology!”

Bob’s last word: Boil it all down, and Mr. Peppard’s proposition is that business departments are in a better position to figure out the information technology they need than a centralized IT organization.

That is sometimes correct, and when it is, IT ought to support DIY IT efforts for all the reasons I’ve written about over the past couple of decades (see, for example, “Stop stomping out shadow IT,” 9/4/2012).

But Mr. Peppard ignores the very real complexities associated with sound, secure, and compliant technical architecture, and especially with integrating what would otherwise result in inconsistent islands of automation.

So DIY IT gets a thumbs up. IT-supported DIY-IT gets two thumbs up.

Making all IT DIY IT gets a big thumbs down.

Even if it does look superficially persuasive on The Wall Street Journal’s editorial page.

Bob’s sales pitch: In response to last week’s column, one commenter pointed out that I don’t make subscribing to KJR easy enough.

And so … if someone has forwarded this to you and you like what you read, here’s where you can subscribe: Subscribe – IS Survivor Publishing.

Comments

|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