Unbutton Your Website

In This Issue:

  • Unbutton your website
  • When the "insider threat" isn't your insider
  • Honda, your database is showing
  • No phish for you

Unbutton Your Website

In what is certainly not going to be the last ruling of its kind, Europe’s top court sharpens guidance for sites using leaky social plug-ins. The purpose of this ruling is to dive in to the privacy issues raised by large social media sites, something the GPDR makes much easier in Europe: It's official: Deploying Facebook's 'Like' button on your website makes you a joint data slurper.
 
Large, predominantly American social media sites are a popular target for politicians in 2019. Like North American telecommunications companies, they are nearly universally despised, even (perhaps especially) by their own users. This makes social media a fantastic legal wedge to test the waters of dictating what can and cannot be on a website, but it won't end there.
 
The real purpose of this ruling is to demonstrate that those who publish websites are responsible for the code that comprises their websites. The debate over whether or not a website publisher is responsible for third-party content will rage for many years yet; but it’s becoming quite clear that website publishers are responsible for deploying third-party code on their website.
 
The takeaway from this is that using third-party libraries, frameworks, etc., on your website makes you responsible for whatever that code happens to do to your visitors. If it violates their privacy, that's on you. If they get infected by malvertising, that's also on you.
 
This is huge. The implications of this cannot be overstated. This ruling cements the liability of website publishers for the code they publish, at least within the EU. And while the EU may lead the world regarding the protection of its citizens' rights, the other non-U.S. western nations tend to catch up within a decade or so.
 

Countermeasure:

If you don't have a formal audit process for every line of third-party code on your websites, now is the time. All plug-ins, social media buttons, analytics, libraries, and what-have-you need to be vetted. Ideally, they should be viciously pruned back to only what is absolutely required, and those that are maintained must be regularly (and automatically) audited to ensure that they have no unexpected or untoward impacts on your visitors.

Read More >

When the ‘Insider Threat’ Isn't Your Insider

We here at The Countermeasure have been debating for a few days whether or not the Capital One breach merits a mention. On the one hand, this is Yet Another Financial Sector Breach. But it does seem to be the story getting the buzz this week, though that could just be that the summer months tend to be slow on news.
 
Articles relevant to this topic include:

 
In terms of making this relevant, we could probably have a bit of a discussion about the insider threat angle. There's a podcast about insider threats in this weeks' links, and there's an insider threat story worth reading here: Logins Stolen From Admin-Backdoored Club Penguin Rewritten Site. But the more we noodle on this, the more we come to believe that the relevant bit is largely missed in the, by now, entirely formulaic coverage of such events.
 
There's a knee-jerk impulse to excoriate Capital One for various technical failings that, in hindsight, weren't the best calls, but it is entirely understandable—and very human—for the people in charge of Capital One to have made decisions that amount to "we're going to trust that Amazon has good enough controls that a rogue engineer inside Amazon can't ransack our security".
 
Nobody builds custom-made security. At the end of the day, we all have to trust vendors to provide us tools to use, and then we implement those tools the best we know how. They won't always work, some form of compromise is inevitable, and it's how we cope with the inevitability of compromise—from incident response to PR—that really matters.
 
In this case, we here at The Countermeasure have a lot of respect for at least some of how Capital One handled the situation. Capital One's CEO opened the discussion with a mea culpa, saying in a statement "I am deeply sorry for what has happened." He said he apologizes "for the understandable worry this incident must be causing those affected," and that he is "committed to making it right." Bravo.
 
More importantly, shortly after this mess hit the wire, a raft of job openings for every kind of information security position imaginable appeared on Capital One's careers page. There hasn't been any mention of them firing all their existing security people, so it looks like this is more of an exercise in raising the relevance of information security within the organization, which is exactly the right move.
 
There is room for debate about whether or not Capital One took too long in going public with information about the incident, but that discussion should also bear in mind that we don't know all the facts. We don't know, for example, when they came forward to law enforcement, and what they were advised to do by law enforcement regarding the incident, or the timing of going public. What we can do is learn from what they did wrong... and from what they did right.

Countermeasure:

There's a lot to unpack in Capital One's response to the compromise event. They took a very different approach than is typical. How successful were their PR moves? How successful were their staffing attempts post-event, and will they be open with their technical approaches toward remediation? If so, what can be learned? The Capital One incident provides many opportunities to compare and contrast with other major breach events, and should be carefully studied by multiple groups within your organization to refine your own incident response and crisis communications plans.

Read More >

Honda, Your Database Is Showing

Honda had a bit of a whoopsie: Unsecured Database Exposes Security Risks in Honda's Network. Make that a huge, mind-bogglingly insane whoopsie: Honda Motor Company leaks database with 134 million rows of employee computer data. Rather than paraphrase, we'll quote the discoverer directly, because we're still reeling.
 
"I was searching Shodan yet again when I discovered an ElasticSearch database without any authentication. The data contained within this database was related to the internal network and computers of Honda Motor Company. The information available in the database appeared to be something like a inventory of all Honda internal machines. This included information such as machine hostname, MAC address, internal IP, operating system version, which patches had been applied, and the status of Honda's endpoint security software. I would like to thank the security team at Honda Motor Company for their very prompt action to secure the database shortly after being notified."
 
Holy crap. On the one hand, at least they appear to have an inventory of what is on their network. But "ElasticSearch database without any authentication"… there's no happy way to complete that sentence. The relevant database sounds like the sort of thing made for internal use by IT, but "findable on Shodan" makes this a resume-generating event.

Countermeasure:

Find or build a tool that blocks databases from being created at all unless they are configured to require authentication. Find or build another tool (shock collar?) that forcefully re-educates everyone involved with directly making a database—or database management software—directly visible on the internet. It's one thing to allow IP-specific access to an authentication-required database when the applications accessing that database either come from a static IP or a known DNS name; but "database" and "findable on Shodan" must never, ever be a thing.
 

Read More >

No Phish for You

To round out our collection this week, we bring you a lighthearted little tale of…well, spoiler alert: the hack didn't work. Dear hackers: If you try to pwn a website for phishing, make sure it's not the personal domain of a senior Akamai security researcher.
 

Countermeasure:

Read the article. It's got some information about the kinds of attacks website face on a daily (hourly) basis, and some defense tips. Also, it's nice to have a story where nobody made an egregious mistake and the bad guys didn't win. Infosec can be super depressing.
 

Read More >

Thread of the Week

I saw a tweet asking why sometimes when you unsubscribe from an email list it says it can ‘take a few days’. Buckle up, as I have a RIDICULOUS story about this happening in The Enterprise™... – Joe Pettersson - @Joe8Bit.
 

Resource of the Week

Defenders have playbooks on how to respond to different attacks. People talk about attackers having playbooks too, though they’re probably not imagining actual documents when they say this. (You'd be surprised what's on the dark web, though.) Palo Alto Networks has been documenting major cyber-attacks and has posted threat intelligence about them on GitHub in a playbook format.
 
Unveiling 11 New Adversary Playbooks. This is an overview article. The actual playbooks are here.
 

Podcast of the Week

Quick Links

 

Get Your Copy.