Doug – Page 3

Herd Immunity and Microsoft Legacy Patches

May 15, 2019 By Doug Leave a Comment

Microsoft just released patches for a ‘wormable’ vulnerability, and took the unusual step of including XP and Server 2003. That’s prompted conversations and comments about legacy operating systems and ‘enabling’ tardy upgraders. While there are people who still have their head down in denial, there are other cases where it’s much more complicated.

Clearly end users shouldn’t be on XP these days (and soon shouldn’t be on Windows 7). But what happens when that endpoint is controlling a multi-million dollar piece of industrial equipment? Or when it’s embedded into devices like an ATM that require significant investment to replace across an environment In many cases the vendor doesn’t support an upgrade (or has gone out of business), and requires either a major overhaul or outright replacement of the entire system.

On the Server 2003 side, it can be similar – large scale applications have been built that cannot be upgraded easily (or at all), either because the vendor is out of business, or there isn’t sufficient capital available to replace the system. In some cases, it’s a critical line of business application and the source code isn’t even available.

Security folks tend to default to a ‘replace it’ approach, and that’s definitely reasonable given the legacy nature of those platforms, but it’s never that simple. Risk has to be balanced with cost, and often that results in lingering legacy environments. In most of those cases, companies have either firewalled or airgapped those endpoints, sometimes moving to a virtual environment as well. Unfortunately, some do require internet access for maintenance or functionality, so there may be ways in.

So when a vulnerability comes along that can be ‘wormable’ – autonomous spreading of malware without user intervention, there’s a small (but very important) set of infrastructure that’s at risk. These systems can’t just be unplugged or disabled easily, as it can have significant impact to the business – potentially to the ‘go out of’ level.

That’s why Microsoft’s decision to issue the patches is commendable. They’re protecting the ones that legitimately can’t upgrade from the tardy upgraders. In some cases folks won’t, so a worm may still hit, but if a significant portion do, the effects will be contained and isolated – and that’s where herd immunity comes it. If we can get most of the legacy systems patched, the risk to the entire environment drops.

If you have legacy systems, by all means, use this as a reason to have the conversation (again) with your stakeholders and vendors about upgrading. But first, find the machines, and get the patches applied, courtesy of Microsoft’s good will. Kudos to them for protecting the herd.

It’s 2019 and we know better

March 1, 2019 By Doug Leave a Comment

Over the past few weeks I’ve run across, either personally or via press, case after case of companies with poor security practices. These aren’t small shops like Bob’s Bait and eCommerce site, rather big brand name organizations that have sophisticated security practices. So why do these things continue to happen?

Let me walk through some examples first. A fairly large regional credit union asked me to submit some paperwork for a mortgage loan….via email. I reached out to the security department, introduced myself, let them know of the request, and they had those instructions removed from the site that day. Took the situation very seriously, and I still would do business with them.

A major bank decided, without a request, or authorization, to start sending email notifications of credit card payment’s being due, including last four of the account, balance due, and credit limit, all of which are sensitive. This is the same company that continually does a soft pull of credit scores to put on the bills – again, it’s opt-out instead of opt-in. I reached out through their public contact info, heard no response, and closed my account a week later.

Press reports this week talk about a large telco provider that uses a default PIN on accounts of 0000 to ‘secure’ them. They are ‘working on it’. Fortunately that line of business has widespread competition, but in other areas they have monopoly control. I could probably cite dozens of reports of common default credentials.

There was another report of a social media site exploiting user information for profit, via a free analytics kit embedded into applications. Why anyone is surprised is beyond me. There’s no such thing as a free puppy, or social media site.

A number of password management software vendors badly muffed the PR response to the recent report of credential harvesting from direct memory attacks. Technically they’re right – the machine has to be compromised for the attack to work, but from a PR standpoint it’s a bad situation. They build their company on trust, and customers feel as if that’s been broken. I still use the software, but then again, I’d read the security paper, so this wasn’t a surprise to me.

An ecommerce site reported a loss of credit card information when their shopping cart software – which was out of date – was hacked. There’s a new thunderbolt attack that can dump memory. Companies continue to produce public computers where people can enter sensitive information (think hotel business centers and all those tablets in the airport). And there’s dozens of companies, including some of the world’s largest brokerage firms, still relying on mother’s maiden name, last four of SSN, or other easily discoverable/guessed alternate authentication schemes.

In many cases, to paraphrase Ian Malcom from Jurassic Park , these companies are focused more on how they ‘could’ rather than if they ‘should’. I’m sure that some marketing person thought it would be cool to proactively provide credit scores, balances, and credit limits, and didn’t bother to ask anyone in the security or privacy departments if they should – or how to do it safely. The telco provider, I’m sure, made that decision by the support and account people who were more worried about account recovery challenges than account takeover attacks. They are paid on minimizing call center costs, so optimized for their own interests over that of the customers.

Both those tie with previous articles, from having the CISO report to the CEO or CRO instead of the CIO – so that they are a peer of the business, rather than subordinate to a service organization, to pushing not just internal security awareness, but also productsecurity awareness throughout the business. But even when training occurs, without a formal multi-stakeholder risk management workflow, people will focus only on their immediate scope.

The most insidious reason though is inertia. They’ve asked for mother’s maiden name since the beginning of time, and continue to do so because no on pushes change. They don’t patch criticial vulnerabilities, because ‘the system works’. They don’t upgrade to the new OS because it requires a hardware refresh. In some cases, like hardware, that may be a valid business decision (though I’d argue it’s a reflection many times of poor prior planning – like the Windows 7 desupport date. Not a secret!), but most of the time no formal decision was made.

Changing the reporting structure is a major undertaking, and something for CEO’s to consider. Building a risk management workflow across stakeholders would be a good initiative for COO’s. CISO’s can provide a conduit for ‘bad behavior escalation’. CRO’s can expand the requirements for product security and privacy training. For everyone else, there is something we all can, and should do, especially as security professionals.

Speak up.

If the company we work for is doing something legacy, dumb, risky, or thoughtless, we have a duty to escalate and try to effect change. There’s no excuse for these bad practices to continue in 2019. Better that it’s driven internally and proactively, than in response to new legislation or worse, to a breach.

Striking back against cyber attack: tempting, but no

January 28, 2019 By Doug Leave a Comment

Andy Kessler wrote an op-ed in the Wall Street Journal last week advocating for striking back against every cyberattack. I’ve written before about why that’s a bad idea for private organizations, yet in this case he’s advocating for a government response. While it’s very tempting emotionally, when we step back and look at the options and risk, it’s not really viable.

Look, I get it, we have nation state actors probing our networks, attacking our critical infrastructure, intercepting sensitive government communications, and conducting economic cyber espionage against us. We, and every nation state, does all that except for the economic espionage. The argument is that if these were kinetic attacks, we’d be dropping bombs on the perpetrators before lunchtime, but unfortunately the analogy doesn’t really apply.

First, there’s the problem of vulnerabilities. Unlike bombs where we can just manufacture more, once a particular exploit is used against a target, it’s likely spent. Upon discovery it’ll be remediated, so if we’ve used it to ‘fire a warning shot’, we may not have a capability to take more aggressive action in the future. That’s also true if it’s a simple credential compromise – once used, the credentials are changed, and we lose access for future action.

But what’s worse is the potential for the adversary to capture the exploit code and weaponize it against us. Or, and history shows this to be likely, a targeted attack causes widespread collateral damage because the code is self-propagating. Both bring us to the problem of stockpiling vulnerabilities versus having vendors patch them. We use many of the same systems as the bad actors do, so we’re at as much, or more, risk than they are. Put simply, I’d much rather have my water system or power grid patched so we stay up, than be able to take someone else’s down.

Of course, before we even have the option of hacking back, we have to know who hacked us to begin with. I’ve written in detail on the problem of attribution, and not much has changed. If it becomes known that we hack back reflexively, we’ll see one actor spoofing attacks by another in order to create international chaos. Both hacking the wrong target, and even hacking the right one risks significant escalation and put our civilian population in jeopardy. The lead time to replace major components of our electrical grid, fuel pipelines, and water systems is measured in months, not days or weeks. Yes, we’re at risk of that now if, as one CISO put it, “the cyber cold war turns into a cyber hot war”, but so far, Mutually Assured Destruction (MAD) applies as much to cyber as it does to nuclear warfare. It’s irrational, but it works – and we can even back up cyber-MAD with kinetic attacks too.

A better option is to unilaterally declare, much like the START treaty, a Strategic Cyber Arms Reduction Effort (SCARE, yeah, sorry) by aggressively testing and remediating vulnerabilities across our critical infrastructure. Every vulnerability we find and patch removes the exploit from everycyber arsenal. Fewer cyber arms makes for a safer world – and we have far more to lose than our adversaries.

Fortunately most of the impactful attacks at the moment are economic in nature, and deserve an economic response. We can’t conduct economic espionage because no American company would ever use that information – lawsuits abound (and the government isn’t exactly going to sell foreign credit card numbers on the black market!). So the only viable option to address things like intellectual property theft, and one for which there’s widespread bi-partisan support, is via trade policy and other diplomatic efforts, which are underway.

Those two efforts aren’t perfect. Diplomacy is open to violation of agreements. Testing and remediation is unlikely to find everything. Yet the combination is a far better option than playing chicken with critical infrastructure.