161–170 of 319 posts
I wonder why data security professionals don't practice compartmentalization. 100 million accounts should not be accessible from one account. It should be like watertight compartments in a ship. Breaching one doesn't sink the ship.
> hacked into a cloud-computing company server, federal prosecutors in Seattle said > the cloud-computing company, on whose servers Capital One rented space, wasn’t identified in court papers. Does this feel like it was just an S3 bucket with permissions set incorrectly? I've come across sensitive documents in S3 buckets with a well crafted google search.
Actually looks like she worked for Amazon on S3. So there might have been some insider knowledge. From the complaint below, and googling her name you can find her resume I won't link it here, but here's a screenshot of a snippet: https://i.imgur.com/NezWVKw.png
How is this person's information wiped off the Internet? I literally cannot find anything related to her. Is it just me?
I get that much of this info is already public, but this feels like borderline doxxing.
Earlier quoted context omitted.
Miss the LevelMoney folks... Yeah AWS can’t protect you against a misconfigured environment
Are there AWS experts who can do some sort of quick audit or "sanity check" of an environment's configurations? AWS almost makes it too easy for someone who only sort of knows what they're doing (like me) to get things up and running.
I wonder if we should create a new BSI (Broken System Interconnection) model
1 - Customer
2 - Former Employee
3 - Current Employee
4 - Bitcoin Miners
5 - Unknown Hackers
6 - Own Government
7 - Foreign Government
8 - Hardware Vulnerability
Earlier quoted context omitted.
The problem with AWS (and other cloud providers) is that it's nearly impossible to properly configure an environment because of how many different methods there are to gain access to resources. Capital One has been all in on AWS and has dedicated an immense amount of time and money to developing systems for managing their AWS resources (Cloud Custodian for instance) and yet they still couldn't protect their data. Wha…
The whole point of moving to a cloud provider it allow the quick setup and deployment of new projects/products as well as trying to limit your costs. With that sort of open-ended system, unless everyone is always thinking security first and okay with the inevitable slow downs associated with a highly locked down system then you will more than likely always run the risk of this sort of situation.
There is nothing approaching quick setup and deployment at large banks.
Not Citibank, but previously worked for a financial firm that sold a copy of it's back office fund administration stack. Large, on site deployment. It would take a month or two to make a simple DNS change so they could locate the services running on their internal network. The client was a US depository trust with trillions on deposit. No, I wont name any names. But getting our software installed and deployed was as much fun as extracting a tooth with a dull wood chisel and a mallet.
This is my experience with one very large bank, but from speaking with others that have worked for/with other large banks, their experience has largely echoed mine. They tend to be very risk averse with external IT products, such as deferring critical security updates because they can't be sure what it could break and also likely don't have end to end tests for critical systems that could cost a lot of money if the upgrade fails.
I know this first hand, because you dont always know or understand whats going on in 3rd party systems. I once screwed up a 3rd party system hosted on site. I was testing an upgrade on a dev server. Part of it invovled schema changes, and I had dbo rights on both production and development servers. The hidden part that I didn't realize is that the 3rd party tool stored DB settings in your Windows roaming profile. So, because we only had 1 Windows AD domain and no otherwise network separation, even though I was on a dev box, I was talking to the prod DB. Didnt even realize it (wasn't directly evident unless you dug deep into settinga) until I started getting calls from my users, complaining of errors. This was on the 3rd of July in the US. By the time I figured out the issue, it was about 3-4am on the 4th of July.
Had to make the call of rolling forward or back. But, the supplied installer was missing some packages, so couldn't complete the install. If we rolled back, an entire days worth of tedious work by a 10 person team would have been lost. Worse yet, the tool was used by traders in Europe who were about to start their day. Being early in the morning on a US holiday, I couldnt reach their support. Couldnt even get of their EU support. I was on the phobe with my boss, his boss and the head of back office at the wee hours of the morning on a holiday.
Decision was made to hold off on doing anything until we could talk to the vendor on the 5th. Ended up rolling forward and completing the install, but I was nearly shutting myself. We were handling somewhere around 25B USD notional in bank debt for several days (which caused huge issues in PNL - proffit and loss - reporting for several business days) that we coyld take no action on.
Thought for sure I was going to be fired. But, in the post mortem, I explained everything, and it was agreed that while I shared some blame, the totality of it wasn't my fault and that because I had diagnosised it and fixed it in the most timely manner I could, I was ok. IIRC, I think the only real remediation we took to prevent a similar mishap was to disable roaming profiles on the dev server and delete all existing profiles on the dev servers...
Well, on the bright side it's a woman in IT. If only she were being recognized for something good, not bad.