Coming up this week on Breaking Badness: Password to the Wise, Regulation, No Breaching, and Gold, Guidance, and Grievances.
Here are a few highlights from each article we discussed:
Password to the Wise
- Cisco Talos discusses what authentication might look like in a phishing-resistant future on the Talos Intelligence blog
- In this blog post, the authors discuss the different types of authentication and they provide a nice table for reference, where passwords are the most vulnerable to various attacks going down to device-bound passkeys
- The table is well done given the scope that they’re looking for in the post. It’s a good brief infographic to provide a certain model in an at-a-glance fashion; but given that it also oversimplifies, as any model does
- The old saying “all models are false, some are useful” applies here, and this one’s definitely useful for setting a frame of discussion, but I do think it downplays the human and social engineering aspects a little too much
- How recently would you say that multi-factor authentication (MFA) has been deemed not as safe as passkeys
- It’s been a few years since we started seeing longitudinal research from bigger organizations such as Google about how requiring multi-factor auth completely changed the landscape as far as successful attacks go
- But of course, some attackers never sleep either – they continue to refine their own practices and techniques just like defenders
- So MFA interception and other workarounds became a field of experimentation and advance; first it was “SMS MFA versus Authentication App MFA” in which a gap widened, and now the same for MFA versus passkeys
- We’re not sure of the hard research there, though – we haven’t seen as much research about passkeys versus MFA as compared to traditional auth versus MFA, but if anyone listening out there has it in hand, hit us up!
- The authors mention that device-bound passkeys release the user from the burden of creating and memorizing unique, complex passwords, but what about the adoption of passkeys?
- Will the infosec community be largely in agreement on the strength of these?
- Coming from user-based IT roots I worry about device-bound passkeys in the sense that things inevitably happen to user devices
- If it’s a business issue, hopefully there’s an IT department to help sort it out
- But for individual users, accidents, loss, and theft can lead to complete account lockout and utter chaos, especially when you’re dealing with behemoth organizations like Google that still don’t seem to care much about individual user support
- Horror stories still emerge of people getting locked out of their entire Google-bound lives, and Google being unreachable or unwilling to help
- Will the infosec community be largely in agreement on the strength of these?
- How does passwordless authentication impact registration, recovery, and revocation?
- Talos wisely brings up in the post that if the landscape involves passwords becoming defunct, attackers will shift to other methods to try and exploit weaknesses wherever possible, and often those weaknesses can be found in processes
- By definition, re-registering a device or recovering an account has to occur in a less secure manner in order to assist the user since they likely don’t have the device to which auth has been bound
- In the blog post, it also mentions that the phishing strategy could move from stealing login credentials to targeting session IDs
- That’s mostly a reference around token-jacking; whenever you sign into a web service it creates a session, and that session is usually managed by a token – often a sort of string your browser stores and refers to
- But that string of characters can be unceremoniously ganked by malware on your device, or stolen in a server-in-the-middle attack
- One of the threat landscapes Ian pays attention to is the cryptocurrency space, not because he likes cryptocurrency but because we see there some of the more advanced attacks that will likely emerge into the rest of the environment at some point
- One of the more subtle attacks there is malware that simply monitors the device clipboard, and when it detects a string that may be a cryptocurrency wallet address the malware silently replaces that with their own wallet address, so funds get misdirected
- While passwordless authentication shouldn’t – and I stress shouldn’t – use something like the clipboard, that kind of quiet monitor-and-replace may be something we see analogs of
- Does Ian agree with the authors that if phishing becomes harder that malware-based attacks will become more prevalent?
- He thinks it all depends on how we classify attacks, in one sense. In general that vaguely suggests attacks will become more technical – but circling back to one of his early points, a lot of this comes back to humans doing things humans do, and the reality that more than anything what creates opportunities for attackers tend to be each person’s cognitive and neurological and emotional frameworks. And he doesn’t think that will change
- Final takeaways:
- Ian really liked this Talos piece for a few reasons. It was well-written and well-thought out, but it wasn’t just “we saw X and determined Y.” It’s a great example of applied speculative thinking – something the cybersecurity industry doesn’t do enough of, he thinks. He’s a huge fan of the genre of speculative fiction, and the field of speculative design – this wonderful field of design concerned with future problems and solutions, and often more than a little subversion. Even the US department of defense taps speculative thinking and fiction, including a partnership with genre writers along those lines and a regular story contest
- Cybersecurity, on the other hand, when it does get speculative, restricts it to maybe tabletop scenarios, and consumer-based design and selling. There’s creativity in that, don’t get him wrong. But he’d love it if infosec in particular and the entire industry in general spent a little more time in the clouds, whether technology or go-to-market or whomever
- Also, a shout-out to the Cisco Talos crew, who operate one of the best infosec blogs Ian can point to, that also treads off the beaten path at times. In the run up to Blackhat last year, Talos even published a poem by one of their own that he continues to think about often, stark and realistic and human as heck. https://blog.talosintelligence.com/poems-0xccd/
Regulation, No Breaching
- The Security and Exchange Commission voted to adopt new regulations that would require publicly traded companies to notify the government when their IT systems are hacked and disclose details around their cybersecurity risk governance in public filings
- The rules here would require businesses to notify the SEC and public within 4 days of determining if the cybersecurity incident will have “material” impact on business operations, but do we know how “material impact” is defined?
- It’s not specifically defined
- This affects publicly traded companies to start – if you’re not publicly traded, but these things grow legs and can expand further, though it will likely involve Congress
- The biggest point of contention is defining “material impact”
- There’s some case law regarding that, but not yet in this realm of things
- Depending on your size with billions in revenue, if you have a few million dollars impact to your bottom line, is that material? Probably not
- The regulations would also require details on how the board of directors oversees risks from cybersecurity threats and identify a board committee or subcommittee responsible for oversight
- Daniel feels strongly of this and is in favor – a good corporate security program needs to have some kind of forum or council that has oversight so decisions aren’t made in a vacuum and are properly discussed among the different business units
- CISOs shouldn’t be members of the board – not sure that’s appropriate, but they should report to the board on the state of security, potential risks on the horizon, and a subcommittee for a publicly traded company is necessary
- In the article, it’s noted that the 4-day timeline is when a company makes the determination of the incident’s materiality, not the initial discovery. So what does that say about the timeline as a whole?
- There is a potential risk of undue delay because you could take your time to make a determination if an incident is material or not
- Daniel has worked a bunch of gnarly breach scenarios and has had short time frames, which is ridiculous because imaging hard drives can take 24-48 hours in and of itself
- To have any sort of objectively true findings takes time
- Not a fan of saying 3 months ago there was a breach is too much, but there has to be a balance
- The 4 day timeline could potentially be abused, but Daniel hopes that can get tightened down
- Do the new rules create compliance burdens on companies?
- Yes – it falls squarely in the compliance departments and Daniel is a believer that compliance does not security make
- There is sometimes a healthy tension between security and compliance
- It’s going to be tricky conversations where there are dedicated functions
- Yes – it falls squarely in the compliance departments and Daniel is a believer that compliance does not security make
- From an infosec perspective, should these regulations fall under the SEC?
- The SEC has the largest lever because they regulate publicly traded entities
- Doesn’t apply to non-publicly traded companies, but if this goes well, Congress could apply the same to non-publicly traded companies
- How do you think the infosec community will respond to this?
- Basic feedback is split – some are taking a wait and see approach because it is so fresh
This Week’s Hoodie/Goodie Scale
Password To The Wise
[Daniel]: 5/10 Hoodies
[Ian]: 5/10 Hoodies
Regulation, No Breaching
[Daniel]: 3/10 Hoodies
[Ian]: 4/10 Hoodies
That’s about all we have for this week, you can find us on Twitter @domaintools, all of the articles mentioned in our podcast will always be included on our podcast recap. Catch us Wednesdays at 9 AM Pacific time when we publish our next podcast and blog.
*A special thanks to John Roderick for our incredible podcast music!
