Show HN: Breach Insider – Detect a data breach using realistic pseudo-users | Hacker News Reader

Show HN: Breach Insider – Detect a data breach using realistic pseudo-users

breachinsider.com

71 pointsgraystevens43 comments

Dictionary makers used to do something similar. They would make up words to detect if a competitor was copying them. Map makers before the internet also did this- make up places to detect copying.

I don't know if they still do this. I haven't seen a physical dictionary in a while. Now with online maps and navigation I don't think map data providers can afford the risk of a navigation system misdirecting someone due to an imaginary place.

But it's possible some of these things took a life of their own. Say someone saw a made up word and started using it because they thought it was real. Or a made up park name for an open area led someone to start using it and others to start calling it that. I don't know if that actually happened but it's possible.

There was a story on here a while back about such a label actually spawning a small town.

https://news.ycombinator.com/item?id=10324499

There's value here in detection of a breach that's already been monetized, but this isn't in the kill chain; it's long-after, so it appears reactive-only.

Why should a non-massive company implement this rather than boosting and refining centralized logging and monitoring which can, if done right, provide far more immediate (even real time) notification of a breach? Your Wells Fargos of the world might do it because they can spare the change, and in your position I'd target the whales for initial revenue, certainly, but why should any mid-sized SaaS firm do it?

Not asking cynically. I want you to sell me on it.

Any measures can miss the breach.

For example disgruntled insider admin quietly stole all users data on his last day at work.

Properly calibrated monitoring should catch that scenario with near certainty though.

I completely agree that preventative/proactive measures are always going to be better than something retrospective such as my service (although I’d argue that they complement each other nicely, of course).

In terms of why a mid-sized SaaS should go this route - I would like to think that Breach Insider is a slightly more cost-effective option. To do detection and correlation properly, you’re looking at a SIEM with the right logs and hopefully some well formed rules. However at this stage, I’d argue that to get the absolute most out of this, you’re looking at supporting & monitoring this with at least one dedicated employee, else all those logs will be wasted.

The brilliance of this service is they don't even need to do any real work in keeping their dictionary that up to date, and they've been given a license to print money.

Cool. Like canary passwords but for identities.

Not enough use of canary passwords people!

A quick Google didn't yield much for "canary passwords", but it sounds like monitoring for passwords as opposed to user email/details as described in the OP.

Care to shed a bit more light on what you mean here and how to effectively use them?

I think he’s referring to the idea of having fake users in your database whose passwords should never be used to sign in. Someone successfully signing in with one of those accounts indicates that your user account credentials have been compromised.

Yep. It's either fake users, or weak passwords for existing users.

Another name for that is backdoor.

Somewhat related, but anyone have any best practices or can recommend a service to protect your users who have been pwned in another sites data breach?

Rate limiting login attempts for an email address or ip address is all well and good for protecting against brute force attacks, but when the attacker has the correct email and password combination already for the user, and access to massively distributed botnets, how do you block those logins?

You email the account owner and tell them they've tried to login from somewhere new and ask for their permission to allow the login. If the email has already been pwned, then, well...I don't know, it's game over really.

That does kind of confirm to the attacker that the credentials are valid on your system though. And do you do this for every different IP? Kind of annoying for users with dynamic IPs.

Every site (with a few rare exceptions) lets you confirm whether an email is a real account or not. You can block the reset password and login flows ("If you've entered a valid email address, we will email you instructions to reset your password" / "Your username and/or password is incorrect").

But every site still exposes it during the sign-up process ("You already have an account. Login here >"). Hiding it during the login flow is largely security theater leading to a poor user experience making people guess & check which email address they used for your service.

If you cannot do more advanced risk analysis: a) email the user after a few failed attempts, b) lock the account down for a period of time, c) lock that IP out from attempting any logins for a period of time, and most importantly, d) monitor lock outs. If an account is getting locked out frequently, be proactive and reach out. 99 out of 100 times it's the user struggling with things like your password requirements, but 1 out of 100 it might be an attacker.

I've read something about a method used by online banking services some time ago: They tracked the way the customer moves their mouse, calculated their arm lenghts etc. and when the movements were suspiciously different, the system assumes it's a fraud and logs them out.

I did similar project with Tensorflow. Mouse movements were captured then converted to images and DL model was trained to classify user or not user.

It can also classify classes of users I.e. new portal users are moving mouse differently from users who are familiar with portal.

To add - by itself it’s not a reliable indicator of yes/no.

But rather another risk scoring input to overall identity detection system.

This is actually clever. Thanks for sharing the technique!

Pleasure :) Here's writeup:

https://www.splunk.com/blog/2017/04/18/deep-learning-with-sp...

AWS Cognito just announced some security features to help with that.

https://aws.amazon.com/about-aws/whats-new/2017/11/announcin...

It looks like something that Distil [1] is doing, among other things. AFAIK they will be expanding this functionality in the coming months.

Disclaimer: My company have been using Distil for a few months; mainly for detecting and blocking bots, but they provide a range of other security features.

https://resources.distilnetworks.com/customer-stories/accoun...

This service is great, I just wish it was about half the price. $600/yr (for something that doesn't increase sales) is just slightly too expensive, for me, for a small-time solo software business.

Any integration with Troy Hunt's haveibeenpwned to get notice from him?

That’s on the roadmap, as Troy sometimes get breaches personally handed to him. Ideally I’d like to be the one detecting the first of course :)

Any email or mobile number can and will receive spam.

So you need your system to check every spam email, call and text and decide whether it’s a breach or spam.

Completely agree, and that’s why our email addresses are formed in a way which shouldn’t be bruteforced/guessed to help reduce this. We’ve purchased a handful of our own domains that we monitor, rather than relying on any other suppliers.

In terms of mobile numbers, they are definitely prone to this, and that is why we make them optional - depends if you want to risk any false positive alarms. Some countries are more prone than others - US mobile get reused a lot it seems!

I wouldn't expect a non dictionary secret email address to receive any traffic.

I did a similar implementation in production using DigitalShadows. We basically created "honeywords" in the database at random, and then had DS monitor for those out in the wild. That included random lines in the source code that didn't do anything other than be used as IoCs.

This seems miserable to maintain. I feel like maintaining a code base with code in it that is simply there to be grepped in the wild would make it incredibly messy.

Well, that is actually a clever service.

Clever for sure. But I wonder how they can identify the leaked account even if they actively scan web / deep web. I mean it's not because Carlos Sanchez is for sale somewhere that it's my "insider".

Creator here – There are a few ways we can detect a breach/leak using our Insiders.

1. The unique email address assigned to the Insider is contacted. We gather forensic evidence of the email along with any attachments. Useful to identify specific attacks against your users too.

2. An optional real mobile number assigned to your Insider is contacted. Again, we store all of the details, including the original SMS details or even call recordings.

3. Your Insider shows up on the Internet or dark web somewhere - we check a number of common sources for dumps, such as Pastebin for any references to the Insider. We currently keep a copy of the contents of the paste, as the original details could be removed at any time. However, we are working on better captures (full page screenshots, entire copy of the DOM etc.)

We are working a few more detection methods too, which we shall reveal soon...

It sounds great. Thank you for the explanation.

Any plans to work with credit bureaus? I just mentioned last week[0] that credit checks against canary records could be an effective way to combat identity theft.

[0] https://twitter.com/JimDabell/status/935433996787384320

Would love to – We have quite a few cool features and interesting link ups that we would love to do, and this is certainly one of them.

The match would be if there's a Carlos Sanchez combined with a specific email or phone number.

I see. Thanks.

Pretty cool idea. How long does it normally take for an alarm to happen after an email is sent to the insider's email address? I just emailed my insider about 5min ago and there is no alarm yet.

It should alert as soon as it hits our mail servers - let check its route and see what happened for you.. apologies.

Edit: Bug fixed, really sorry about that! I've sent an email to the insiders address, to give you an example alert.

This is a good idea. My only suggestion would be to whitelist addresses only, not domains, since it is sadly not uncommon that an email account is compromised, especially at large orgs.

That’s a very valid point - whitelisting DKIM domains was the quickest option as it is easily parsed and verified. Will certainly look into this.

Reply on news.ycombinator.com