Doug Lhotka

Technical Storyteller

Opinions and commentary are mine, and do not reflect those of my employer.

(C) Copyright 2019-2023
Doug Lhotka.
All Rights Reserved.
Use of text, images, or other content on this website in generative AI or other machine learning is prohibited.

Viability scanning: discovering the security risk of technical debt

By

(c) Depositphotos / @stockasso

Flash was one of the great 1990’s technology, bringing rich content to the (largely) text based Web at the time, but evolved in an era before widespread security risks and is no longer fit for purpose.  Adobe announced its end of life two years ago this month, and yet there are sites that either use it by default, or require it to function at all.  Windows 7 is much closer to end of life, but many companies won’t be migrated in time. Those are just two examples where technical debt will become a security risk, yet we never seem to learn.

If you’ve read my articles, you know I have a business focus.  I get business cycles, budgets, and risk tradeoffs.  In some cases, delayed migration might be the right answer – the classic is a Windows XP system that runs a multi-million dollar piece of industrial equipment. That’s fine to a point, but it requires compensating controls, which may work in isolated instances, but they don’t scale.  For ones like Flash, the only real option is replacement.  We know our adversaries stockpile vulnerabilities in systems with announced end of life to deploy once patches are past.  When that happens companies are going to be faced with either going dark, emergency replacements, or accepting significant risk and liability for what, at that point, will border on negligence.

Looking forward, companies need to move towards life-cycle budgeting for new technology acquisitions. That involves assessing the real lifespan of a particular platform, and planning ahead when the original system is acquired.  That will drive better decisions during the development and acquisition process, to avoid vendor, and version, lock-in that tie solutions to dead-end platforms.  We also need to do the same thing for existing systems: take inventory and do a realistic assessment of the lifespan of the assets.  Call it ‘viability scanning’ to go along with ‘vulnerability scanning’.

This analysis is a convergence of enterprise architecture, IT governance, program management, and cybersecurity.  On the technology side, it needs to include end of life dates, vendor history, vendor viability, product viability and openness.  On the skills side it includes the ability to hire quality staff to maintain, enhance and if necessary, port the application going forward.  On the business side, it needs to be baked into the overall business plan and multi-year budget cycle.  Technical debt always costs more at the end of the loan than the beginning – just ask the victim of any recent breach where the patches had already been released.

Equally important is the vendor side of the equation.  Vendors need to announce end of life dates, rather than letting people assume from past behavior.  Better yet, they need to have a policy forannouncing those dates – a promise against short-notice end of life surprises.  For example, on the good side is Microsoft, who has both pieces in place – no one’s surprised when they drop support.  The counter-example is Apple, who has neither – we never really know when an OS version is no longer supported…at best we’re left to guess.

In the end though, it’s up to the business owners to make the decision.  Technical debt only gets worse, and I’ve yet to see an organization that does well with deficit spending.

GDPR Fines: So now we know

By

Copyright © 2016 Alexey Novikov

Over the past few years, as companies I work with have been getting ready for GDPR, everyone knew about the potential fine size, but no one really knew if they’d be as big as they could be.  Now we know.

In the past few days, Marriott (https://thehackernews.com/2019/07/marriott-data-breach-gdpr.html) and BA (https://thehackernews.com/2019/07/british-airways-breach-gdpr-fine.html) were both hit with $100M+ fines for breaches. While both are going to appeal, the benchmark has been set, and we now know that the regulators are serious about enforcement.  One interesting fact – if the reports are accurate, Marriott is being finedunder the GDPR, while the breach occurred beforeit went into effect.   That certainly changes the risk equation, as retroactive security is, alas, still beyond our ability today.  I suspect we’ll see a similar seriousness with CCPA (the new California regulation), though those costs will include consumer litigation as well.

So what’s an organization to do?  Protecting against breaches is still critical, but they’re still going to happen.  I’d argue that early detection and quick response are table stakes in the current regulatory environment.    Recent studies show that lateral movement begins with 18 minutes of the initial breach, and data exfiltration can quickly follow.  Now to be fair, you’re probably not going to lose 90 million records overnight, but for a smaller firm, losing hundreds of thousands is still enough to close the doors.

Which leads to the big gap I see, particularly at smaller companies – business hour security isn’t enough anymore. At a minimum, after hours tier-1 with a rapid on-call escalation process, but for larger organizations it may include 7×24 investigation as well.  On top of that, I’ve seen a lot of teams focusing on improving detection over the past couple of years, to good effect, but without the ability to acton alerts very rapidly to stop a breach in progress, improved detection quickly reaches a limit.  Automation for remediation is critical – both to ensure it occurs rapidly, but equally important is that it happens in a controlled and planned manner in a stressful situation.  Running through the data center yanking cables to stop ransomware isn’t exactly an ideal response approach.

In one of my keynote talks, I note that security is an information management problem – without good information you don’t know what’s going on, and without taking action on that information, there’s little point in knowing.  The answer to GDPR, CCPA and other regulatory risk is to ensure that your security information lifecycle is complete, active, and effective.

Friday Photo – New Horizons

By

I’ll be leaving IBM at the end of the month and starting a cool new adventure with a great organization. I’m really excited about the opportunity for growth, and looking forward to jumping in with both feet. To all those I’ve worked with over the years at Big Blue, my sincere thanks for the collaboration and friendship. I’ve learned from each of you, and wish you all the best in the future.  Here’s to new horizons!