security

Viability scanning: discovering the security risk of technical debt

July 31, 2019 By Doug Leave a Comment

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

July 10, 2019 By Doug 1 Comment

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.

It’s never ‘just email’ – secure your endpoints

May 24, 2019 By Doug Leave a Comment

Like many security folks, I always grab and read the Verizon Data Breach Investigations report when it comes out, looking for trends and themes. One of the things that struck me this year is that email remains a broad attack surface. At that same time, my own conversations with security teams have seen a troubling anti-pattern: unmanaged devices, especially mobile and BYOD, because users ‘only get email’ on them. Combine the two, and it’s an attack vector in waiting.

Email is a broad theme across sections of the report – it’s the most common entry point for malware, phishing (almost always via email) is the top social action in a breach, sending data to the wrong people, attempts to compromise accounts either for or via email, fraud perpetrated by a man-in-the-middle attack in payment email chains, and a number of others. Part of the threat is that Email is the most common vector to reset passwords, bypassing most MFA systems – and attackers know this, and force fail back to that method. If they get access to your email account, they really do have the keys to the kingdom.

At the same time, there’s growing demand by employees to allow BYOD, especially on mobile devices. Coupled with financial pressures to reduce corporate assets, a highly mobile and remote workforce, and a blurring of traditional office hours, access to email is happening on a growing number of endpoints. Most BYOD is mobile which are a mixed bag in terms of built-in security, ranging from Apple’s hardened iOS environment and walled garden at one end, to cheap offshore android phones that come with free pre-installed malware. Validating email on mobile, as the report notes, is extremely difficult (ever try to view the raw headers on an iPhone?).

On the laptop side, allowing access to corporate email or systems isn’t as widespread, but it still happens fairly frequently. Even though it’s easier to validate email contents, it’s still not perfect. One company I work with had a C-level executive’s credentials stolen…by phishing his children, who clicked the link, installed malware on the personal machine, which then captured the executives credentials logging into the corporate system.

As an aside on personal email account, remember that free email accounts, along with the you’re-the-product privacy implications, can be very difficult to recover if they are compromised. A paid service, like Exchange Online, lets you have a separate administrator account which you can use to disable and recover control over your email account. Of course, you’ll also have access to actual people to help too. The services are cheaper than a latte, and worth every penny.

For both corporate and personal email our risk models need to change: email is a major threat vector that provides a foothold for credential compromise, account takeover, and malware installation, and we need to assess risk in that overall context, not just the risk of data leakage.

Put it more simply, the idea that we don’t need to manage endpoints that only get email is misguided – we especially need to manage them if they have email access.