cybersecurity

Sly like a (Fire)Fox

June 25, 2020 By Doug

Mozilla has been overriding network settings for DNS in the browser for a while now, motivated by privacy concerns, but recent actions to default to an ISP DNS service raise questions and seem inconsistent with that design.

DNS over HTTPS is an attempt to block eavesdropping on DNS requests, which is great in theory, but causes a number of problems, especially with the current design in Firefox. From an architectural standpoint having any application use its own DNS system rather than the network stack’s configuration is poor design.

First, network administrators have real requirements to monitor DNS requests. For more formal networks, this is often used to block malicious links, track malware, and prevent access to prohibited content.

In my own case, I run a Pi-Hole to block advertising and track across all of the devices on my network, and in turn have that pointed to Quad9 (secure DNS of course) to leverage their block list, with CloudFlare as a backup. Other home users will have parental control software active. In both cases, Firefox overrides those settings and bypasses any local blockers. By default. With no notification or consent.

Their original argument for making this opt-out was because most users won’t turn it on if it’s opt-in. I can sort of get that, and previously the default DNS servers were pretty benign. However, with the announcement recently, Firefox will now default to an ISP’s ‘secure’ server if you’re on their network. Mozilla claims that making this change is OK because users can opt-out, but again, that’s contradictory to their reasoning for opting users in by default in the first place. In any case, this doesn’t seem exactly in line with their previous position on providing secure DNS to avoid ‘ISP eavesdropping’ is it?

I’m not mentioning the specific ISP, because I expect it’s just the first of several that are going to go down this path. And while it’s possible that they’ll actually provide secure, private, non-tracked, non-filtered DNS lookups, there are loopholes in the Mozilla DOH Resolver Policy. And when it comes to ISPs, let’s just say that past practices are cause for reasonable concern.

What Firefox should do instead is pop a configuration screen that allows the user to opt-in both to DNS over HTTPS, and then select the server they’d like to use. No default. No automatic enablement. When new server options are added, just pop that screen up again and ask if they’d like to change. Empower the users to make a choice based on their own priorities and interests.

That’s how you support user privacy.

Viability scanning: discovering the security risk of technical debt

July 31, 2019 By Doug

Depositphotos_56141401_original — (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.

Cognitive Fuzziness – Getting the definition right

June 23, 2017 By Doug

There’s a ton of hype about cognitive security in the marketplace these days, and the marketing departments are operating in full force. So beyond the hand waving, cheerleading and me-too-ing, what do we actually mean by cognitive?

Cognitive involves three things: The ability to mine data for information, the ability to recognize patterns in that data, and the ability to understand natural language. The key component across all of these is an ability to reason and infer on a probabilistic basis from the context of the information. But it’s not Lt. Commander Data from Star Trek fame – cognitive isn’t artificial intelligence. It’s more like the library computer in the original series, that is, a machine that can answer questions put to it. Cognitive is a foundational technology for AI, but we’re a long way from real AI – 2001 came and went without HAL, and so will 2017.

Machine learning, which is often confused with cognitive (sometimes deliberately) has been around for years, and while it’s an enabling technology, there’s no magic there. It can be extremely useful, but also some limitations to keep in mind. The models created are only as good as the data inputs and variables selected. Poor input data yields models that may appear to work, but diverge over time, and you’d best hope that the data isn’t already compromised when the model is built. Even when you have a good baseline, continuously updated models can be either spoofed (reset the ‘normal’ baseline over time), or destabilized by a persistent, and patient attacker. There’s techniques to combat the attacks, so it’s worth asking about which ones are used.

Cognitive uses machine learning as a training tool when it’s being taught to understand a particular set of vocabulary and grammar – cybersecurity for example. Traditional unstructured information systems simply operate on keywords and often metadata, but cognitive systems understand the context of the information components in relation to each other. For example, if I talked about Apple’s CEO eating an apple while negotiating a contract with Apple, most engines would return the document based on a keyword – Apple, or potentially from tags or metadata a human added to the document. A cognitive engine with a large corpus might return that document for questions about computer companies, fruit that grows on trees, and the Beatles’ record company, depending on how the question was worded.

So when using terms like machine learning, cognitive, or artificial intelligence applied to cyber security, it’s important to be crisp about which one is used, and what it implies. We’re not quite in snake oil territory here, but there is a lot of both intentional fuzziness and casual laziness in the press and marketing. Regardless of which term though, remember that there’s no silver bullet that will solve your security challenges. Cognitive is a force multiplier, but not a magic army.