Block Confirms Cash App Breach After Former Employee Accessed US Customer Data (techcrunch.com) 17
Block has confirmed a data breach involving a former employee who downloaded reports from Cash App that contained some U.S. customer information. From a report: In a filing with the Securities and Exchange Commission (SEC) on April 4, Block -- formerly known as Square -- said that the reports were accessed by the insider on December 10. "While this employee had regular access to these reports as part of their past job responsibilities, in this instance these reports were accessed without permission after their employment ended," the filing reads. Block refused to answer our questions about why a former employee still had access to this data, and for how long they retained access after their employment at the company had ended. The information in the reports included users' full names and brokerage account numbers, and for some customers the accessed data also included brokerage portfolio value, brokerage portfolio holdings, and stock trading activity for one trading day.
Not all people think about the long term (Score:4, Interesting)
It is tempting when you have access to massive amounts of data, to think of ways of getting away with selling it for a lot of money. However, if you miss one step, for forget a single thing, you go to prison, you don't get to keep the money, and you may not be able to get such a good job again.
I know every tech out there thinks they are an exceptional tech, and everyone else in the organization is an idiot... However, you are not as smart as you think you might be, and the others are not always as stupid as you think they are.
I once had to collect data to prove an ex-employee stole data from our company. I met that employee once and my Boss, told me that this guy has an ego, so don't make yourself look too smart, because we need him to work with us at the time. So I played dumb, he thought I was an idiot, he stole the data and quit the company. My boss was pissed, but the next day, I had collected tons of evidence that we used in court against him to prove what he did and when he did it, and how he did it. The company didn't push criminal charges, but civil charges (It would have been criminal today), which bankrupt the guy, and had to sell all his possessions.
Usually the difference between doing something good vs something evil, isn't the actual action, but considering if the long term effect of ones action is overall good or bad.
Re: (Score:2)
+1 Insightful. But was really hoping the ending was where you do the Hollywood thing, when he's walking out of the courtroom in handcuffs he glares back at you with the realization that you really weren't an idiot and then you give a cool smirk CSI-style as the ultimate I completely pwned you arrogant jackass.
Dangit.
Re: (Score:2)
Real life, I didn't even have to go to court. I did work with the companies lawyers to explain my data to them, also the hired computer forensics expert to give him some details of data elements that would disprove his claims. I saw the guy during the court ordered forensic analysis of the guys equipment, we didn't talk or even bother looking at each other, I was just making sure as a witness of the process to make sure things were fair from my companies end.
Tough problem (Score:3)
I'm at a much smaller company, but I've also struggled to develop policies and tooling to ensure this sort of thing doesn't happen. It's a balancing act to an extent between human processes and technical controls, and between UX/features and security.
There's no great answer. You obviously want the technical controls, but that requires integrating every bit of technology into the same central authorization framework. With some software this is straightforward, with others it's an exercise in spaghetti (another security risk). Developers are constantly adding new services and new systems requiring authorization. It's a rapidly moving target.
Sure, this isn't too hard if you start out with this in mind. But how many companies were cobbled together from open source parts?
Re: (Score:2)
I'm at a much smaller company, but I've also struggled to develop policies and tooling to ensure this sort of thing doesn't happen. It's a balancing act to an extent between human processes and technical controls, and between UX/features and security.
There's no great answer.
Very much this. Some of the most vetted out people turn out to be spies, and we cannot stop that. Imagine trying to filter out the bad guys and gals in a normal circumstance.
Now all that said, in this case, it would have made sense tor a terminated of leaving employee to have their credentials terminated at the same time, in the case of termination, do it as a priority before they know. Not perfect, but it appears this bad guy had access after he left.
Re: (Score:2)
Re: (Score:2)
You can require that all permissions given are stored in a database and whenever somebody leaves the company, they all need to be disabled and a second person needs to verify that for each one. Yes, that is costly, but it is the price for failing to have centralized IAM. Oh, and any sane enterprise absolutely forbids new development that does not integrate with centralized IAM, so this should be a legacy-problem only. If this problem continues to get worse, you have a CISO and potentially CEO that is fuckin
Re: (Score:2)
I'm not clear on the why someone needs to verify each transaction.
If access is being programmatically revoked based on their employment status, shouldn't the unit and acceptance tests of the automation be good enough?
If it is a really high risk environment I'd want an independent team signing off on the QA tests, but I'd rather not rely on a very error prone human to be verifying that thousands of account credentials are revoked every time an employee leaves.
Re: (Score:2)
I'm not clear on the why someone needs to verify each transaction.
Because it is a critical and manual process. Manual, because this is the "no central IAM" case. Manual processes are error-prone, hence 4-eye principle. If it is automated, no need for verification. But that typically means centralized IAM. Note that "centralized IAM" can also mean "automated process that knows and can access all account-bearing systems via SSH or other remote command interface and that can query and change the access permissions on those systems" or the like. That process would of course b
Re: Tough problem (Score:2)
And what about the guy with creds to the central DB?
Re: (Score:2)
And what about the guy with creds to the central DB?
Special manual process for the DB, all his other accounts need to be in the DB. This is a role you do _not_ give to just anybody. System administrators, DB administrators are people you need to keep satisfied with their jobs so they are loyal. If any of them want to leave, be generous with severance. If some of them misbehave, you have a real problem. Best to offer them a different job as soon as you see the first signs of dissatisfaction you cannot fix. Also note that this is a role that several people nee
Re: Tough problem (Score:2)
You're still falling back on human processes. That's kind of my point. Technical controls don't cut it.
Not so simple (Score:2, Insightful)
Non-working off-boarding process? (Score:2)
That is CEO and CISO responsibility. Time for some personal penalties for gross negligence.
I'm SO glad (Score:1)
...that the folks at Credit Karma sold all my tax info to these assholes without giving me a way to opt out of the transfer. I can't get them to delete it either, because just like in the summary, "Block refused to answer our questions" is actually their modus operandi for ALL situations, including their own privacy policy.
I can't wait for the $0.89 check from the class action lawsuit after my identity gets stolen.