Hackers Breached Virginia Bank Twice in Eight Months, Stole $2.4M

I am planning to move my stocks from ETRADE to Vanguard.

Vanguard's user agreement says this:

Data security is, of course, a top priority. To mitigate computer virus attacks and other acts of cyberterrorism, We have implemented controls monitored by a dedicated team of information security specialists. We also maintain a network of redundant systems, off-site data storage, and off-site tape vaults to ensure that all source data are recoverable in a disaster.

That seems a bit like a catch 22 to me - if you get hacked enough, it must be your fault, so no payout.

Or they disguised the IP addresses to look like Russian IPs? Although I'm no hacker- anyone know hard that would be to do?

That rider sounds to me like the ATM itself has to be compromised. It wasn't. The hack was upstream and the ATM was just doing what the network rules told it to.

Why would the Russian's care if their address was known? They aren't going to be extradited or punished by the Russian government, they may be funded by the government or people very well connected to the government. Not to make it political, but they hacked many of our election systems and didn't even get punished for that.

Yeah it makes it seem a bit implausible or at least should be cause for just a teeny weeny second of consideration. If I were hacking into a bank I'd consider myself pretty smart if I thought to pin it on the most boringly believable (by most Americans, stewed as they are in a soup of anti-Russia talk) hacking culprit.

Does this show it's come to pass at all?

It's possible, but the only evidence we have is that insurance companies want to avoid the payout, not that poor practices impacted premiums at all. Given what I've seen from security audits of the past, particularly when influenced by non-security professionals (such as the accountants in this scenario, both the insurers and the insured), I have little faith that if insurance companies dictate the practices that we'll get actual useful security increases, but plenty of extra bureaucratic hoops that will result in the same "productivity vs security _risk_" dilemma we have now, except the CBA changes to "is the hit to our productivity worth this hoop compared to the cost our lawyers would involve to prove this hoop was unnecessary or unrelated times the likelihood that it comes up"

From one example? Hardly.

What about Equifax?

It seems more likely that the ATM withdrawers were just normal criminals already integrated into normal criminal organizations. Everybody gets a cut, but nobody takes too big a cut because violence and repeat business. Normal criminals love ATM stuff because it's quite low-risk.

The article does touch on the matter:

> The bank’s complaint against Everest notes that the financial institution doesn’t yet know for sure how the thieves involved in the 2017 breach extracted funds. In previous such schemes (known as “unlimited cashouts“), the fraudsters orchestrating the intrusion recruit armies of “money mules” — usually street criminals who are given cloned debit cards and stolen or fabricated PINs along with instructions on where and when to withdraw funds.

Good catch! I wonder why?

IR people are in very high demand pretty hard for them to hire the best

However, I don't care how different or secure their security division is. If they're happy to run it under the Verizon brand they I will continue to assume they are incompetent monkeys and they deserve to loose business for this.

Either up your security so Verizon is finally considered a credible brand, or spin the security business off as a separate entity.

> and just start firing those in your employ who willfully and joyously thumb their noses at basic security hygiene.

Until it's your top salesperson who 2x'd the quarterly revenue target... I'd like to live in a world where everyone knew basic security hygiene, but we have to teach it first, not punish.

The issue at hand is the faulty Windows security model. Users have been trained to give full admin rights to anything that asks.

The problem is that most endpoint protection is a joke. Companies buy enormously expensive enterprise endpoint protection systems with big dashboards to tell them if their endpoints are protected, and one of two things happens: either the dashboard falsely reports that everything is up to date (and you have Outlook 2007 running in the wild) or the dashboard reports that you have 4,394,665 security issues that need fixing, and not only does nobody have a clue where to get started, the minute they move laterally in the org to try to update anything, users scream DON'T YOU DARE TOUCH THAT!

You can't fix your security posture until you fix your update culture.

Train the employees by sending fake Phishing attempts and then letting them know when they have clicked on them. Do this regularly.

If we're going to start firing people, first on my chopping block would be IT staff who implement security theater policies which go against NIST recommendations (like forced rotation of passwords every x days) and create security hygiene problems as side effects.

Let he who is without sin initiate the first termination process with HR.

Lots of supposedly known senders that are actually hostile actors, some account takeovers, and there are many external facing people who expect to receive word docs from unknown people.

Accounts payable, for example, gets lots of these things as an expected part of the workflow, as does legal, and various parts of management.

PDFs have had problems of their own.

Many of the people that you most want to secure are the same people who need to be exposed to the outside world. CEO and CFO HAVE to deal with random people, as it's the job, but they are the most dangerous. If someone needs a 5 step verification process that takes days to communicate with your CEO, then you are not going to get may new clients or investors.

We could reduce our risk a lot using a combo of technology that isolates executions to certain deprivileged memory ranges with tech that blocks code injections in general. Think a separation kernel running a desktop OS in one partition and in another a PDF viewer written in Rust. The general tech for stuff like that was being sold commercially far back as 2005, minus Rust of course. They did have Ada runtimes, though. The NSA and military ended up retiring the concept because there was too much complexity in PC hardware they thought would lead to attacks bypassing the VM boundaries. They did.

The old approach, which I used, was to use a mix of desktop and embedded boards physically separated with a KVM switch plus controlled, sharing mechanism. Just keep the untrustworthy stuff on their own machines. It's klunky but a greater chance of working securely.

I guess that is traditional 2fa that never occurred to me. Shouldn't we update that to include one-time passcodes like we do know for most things?

to add an addition OPT password, sent on the phone or something like that.

however, if your system allows one to disable even the PIN code that's pointless.