6 ms·

I’ll just keep saying this, and getting dismissed by everyone I know - any data security discussion around a centralized data store that doesn’t begin with the

I’ll just keep saying this, and getting dismissed by everyone I know - any data security discussion around a centralized data store that doesn’t begin with the recognition that that data store will be compromised, is a discussion that is just a joke.

anigbrowl 7y ago
You and a whole bunch of other people making the same extremely basic observation. It would be good if you would suggest some alternative strategies, since 'don't bother keeping that data' isn't a realistic option in this context.
- joeblubaugh 7y ago
  sure it is! you don't need to keep a centralized photo db of every person who enters your country all in one place, even to build ML models on. This could have been federated in a variety of ways that would've reduced a breach risk. Or, we could avoid building a massive surveillance network that doesn't help make our world better.
  - anigbrowl 7y ago
    I'm not arguing for centrality, but how do you see this actually working? People submit photographs when they make visa applications, so how are you going to store that?
    - DennisP 7y ago
      These were not photos submitted with visa applications. > The compromised photos were taken of travelers in vehicles coming in and out of the US through specific lanes at a single Port of Entry over a one and a half months period. The article also mentions this was part of a new program to use facial recognition on everyone entering the country. We've never had that capability before, so I see this working like it always has. Regarding the visa photos, it depends on what they're used for. In general I'd prefer avoiding ongoing surveillance as much as possible, which reduces the need to keep digital photos preserved in accessible places.
- projectileboy 7y ago
  I’m not sure why you’re being downvoted; I think it’s a fair comment. My response is that I’m honestly not sure what the best response is. But if we start with insecurity as a given, then I feel like we could at least be exploring better alternatives around... people storing data locally and always providing it for every interaction? Maybe.
- manicdee 7y ago
  1. Don’t bother collecting the data since it is not a net gain. 2. Don’t collect data that doesn’t actually help enforce any laws. 3. Don’t produce new legislation that doesn’t actually solve any existing problems (it is already illegal to break the law). 4. The best way to keep secrets is to not have secrets in the first place. Once you have secrets the best way to keep secrets is to not share them.
- munchbunny 7y ago
  Part of my job is designing software that is resistant to amplification once the hacker is already in, so maybe I can help here. When you plan your security, step 1 is making it hard to get in, step 2 is making it hard to persist, i.e. plant a command and control process somewhere inside the perimeter, and to move laterally in the system, i.e. get from one service into a more important service. There's some basic stuff, such as firewall rules that prevent outbound traffic from ports/processes you aren't expecting. That makes it harder for the hacker's command and control systems to get instructions. There's other stuff like using separate credentials for low sensitivity vs high sensitivity systems, two-stage approval processes for especially sensitive operations to prevent a single compromised user from being able to get to the good stuff, automatic password rotation so that exfiltrated tokens aren't valuable, and more. Those are just single things though. I think the more interesting part is an exercise like this: assume that the hackers have compromised a developer's computer. In that case, what does a system look like that would prevent that developer from exfiltrating payment info? I would argue that the developer doesn't normally need access to real payment info, so maybe the network should be configured so that the developer is unable to SSH into that set of database servers without first requesting a special short-lived SSH keypair. That at least means the developer has to explicitly ask for access. That doesn't make the hacker's job impossible, it just makes it harder. Also makes things less convenient for the developer, so is it worth the trade-off? For especially sensitive data, it probably is. With this setup, maybe the hacker gets to the account information, but they're stopped short of account numbers long enough to notice the breach. This is all on the theoretical side, but that's the thought exercise once you go "let's pretend someone compromised ____ system."
  - CGamesPlay 7y ago
    One of my favorite Hacktober tricks was putting an alias around SSH on the developers machine, so the next time they used 2FA to get into a remote host I would drop a note into their MOTD (to prove persistence). That short-lived SSH token would be enough to install persistence. So obviously, your payment hosts should be very wary of things like port forwarding over SSH, and any unknown outbound traffic.
    - 7y ago
ariwilson 7y ago
Why does decentralization save you from compromise?
- munchbunny 7y ago
  I wouldn't frame it as decentralization, more like compartmentalization. You harden your systems to prevent horizontal movement between services. For example, you could try to put payment credentials in a separate subnet where they are never read out of that enclave. Access to that subnet might require separate authentication credentials that most employees don't have, and API calls might require the calling server to possess a separate type of short-lived certificate. So when the main DB is compromised through an employee, it's still hard to laterally access more sensitive data.
  - Thorrez 7y ago
    It sounds like CBP might have done that. What was stolen: > The compromised photos were taken of travelers in vehicles coming in and out of the US through specific lanes at a single Port of Entry over a one and a half months period. What wasn't stolen: >No other identifying information was included with the photos and no passport or other travel document photos were compromised, the official said. Images of airline passengers from the air entry and exit process were also not involved.
    - munchbunny 7y ago
      > On May 31, 2019, CBP learned that a subcontractor, in violation of CBP policies and without CBP’s authorization or knowledge, had transferred copies of license plate images and traveler images collected by CBP to the subcontractor’s company network Sounds like CBP's issue was less about compartmentalizing, more about controlling for how the subcontractor accessed the data. Honestly the problem sounds more like something borne from ignorance than malice. It's a headache having to download every image you have to analyze, so why not copy the whole thing to a local network drive and work with it here? And then some hacker lifted it from the local network drive. Anyway I wasn't talking about the CBP specifically. I was responding to the question about why decentralization saves you from compromise. My response was that compartmentalization is useful for damage control.

anigbrowl 7y ago

You and a whole bunch of other people making the same extremely basic observation. It would be good if you would suggest some alternative strategies, since 'don't bother keeping that data' isn't a realistic option in this context.

joeblubaugh 7y ago
sure it is! you don't need to keep a centralized photo db of every person who enters your country all in one place, even to build ML models on. This could have been federated in a variety of ways that would've reduced a breach risk. Or, we could avoid building a massive surveillance network that doesn't help make our world better.
- anigbrowl 7y ago
  I'm not arguing for centrality, but how do you see this actually working? People submit photographs when they make visa applications, so how are you going to store that?
  - DennisP 7y ago
    These were not photos submitted with visa applications. > The compromised photos were taken of travelers in vehicles coming in and out of the US through specific lanes at a single Port of Entry over a one and a half months period. The article also mentions this was part of a new program to use facial recognition on everyone entering the country. We've never had that capability before, so I see this working like it always has. Regarding the visa photos, it depends on what they're used for. In general I'd prefer avoiding ongoing surveillance as much as possible, which reduces the need to keep digital photos preserved in accessible places.
projectileboy 7y ago
I’m not sure why you’re being downvoted; I think it’s a fair comment. My response is that I’m honestly not sure what the best response is. But if we start with insecurity as a given, then I feel like we could at least be exploring better alternatives around... people storing data locally and always providing it for every interaction? Maybe.
manicdee 7y ago
1. Don’t bother collecting the data since it is not a net gain. 2. Don’t collect data that doesn’t actually help enforce any laws. 3. Don’t produce new legislation that doesn’t actually solve any existing problems (it is already illegal to break the law). 4. The best way to keep secrets is to not have secrets in the first place. Once you have secrets the best way to keep secrets is to not share them.
munchbunny 7y ago
Part of my job is designing software that is resistant to amplification once the hacker is already in, so maybe I can help here. When you plan your security, step 1 is making it hard to get in, step 2 is making it hard to persist, i.e. plant a command and control process somewhere inside the perimeter, and to move laterally in the system, i.e. get from one service into a more important service. There's some basic stuff, such as firewall rules that prevent outbound traffic from ports/processes you aren't expecting. That makes it harder for the hacker's command and control systems to get instructions. There's other stuff like using separate credentials for low sensitivity vs high sensitivity systems, two-stage approval processes for especially sensitive operations to prevent a single compromised user from being able to get to the good stuff, automatic password rotation so that exfiltrated tokens aren't valuable, and more. Those are just single things though. I think the more interesting part is an exercise like this: assume that the hackers have compromised a developer's computer. In that case, what does a system look like that would prevent that developer from exfiltrating payment info? I would argue that the developer doesn't normally need access to real payment info, so maybe the network should be configured so that the developer is unable to SSH into that set of database servers without first requesting a special short-lived SSH keypair. That at least means the developer has to explicitly ask for access. That doesn't make the hacker's job impossible, it just makes it harder. Also makes things less convenient for the developer, so is it worth the trade-off? For especially sensitive data, it probably is. With this setup, maybe the hacker gets to the account information, but they're stopped short of account numbers long enough to notice the breach. This is all on the theoretical side, but that's the thought exercise once you go "let's pretend someone compromised ____ system."
- CGamesPlay 7y ago
  One of my favorite Hacktober tricks was putting an alias around SSH on the developers machine, so the next time they used 2FA to get into a remote host I would drop a note into their MOTD (to prove persistence). That short-lived SSH token would be enough to install persistence. So obviously, your payment hosts should be very wary of things like port forwarding over SSH, and any unknown outbound traffic.
  - 7y ago

ariwilson 7y ago

Why does decentralization save you from compromise?

munchbunny 7y ago
I wouldn't frame it as decentralization, more like compartmentalization. You harden your systems to prevent horizontal movement between services. For example, you could try to put payment credentials in a separate subnet where they are never read out of that enclave. Access to that subnet might require separate authentication credentials that most employees don't have, and API calls might require the calling server to possess a separate type of short-lived certificate. So when the main DB is compromised through an employee, it's still hard to laterally access more sensitive data.
- Thorrez 7y ago
  It sounds like CBP might have done that. What was stolen: > The compromised photos were taken of travelers in vehicles coming in and out of the US through specific lanes at a single Port of Entry over a one and a half months period. What wasn't stolen: >No other identifying information was included with the photos and no passport or other travel document photos were compromised, the official said. Images of airline passengers from the air entry and exit process were also not involved.
  - munchbunny 7y ago
    > On May 31, 2019, CBP learned that a subcontractor, in violation of CBP policies and without CBP’s authorization or knowledge, had transferred copies of license plate images and traveler images collected by CBP to the subcontractor’s company network Sounds like CBP's issue was less about compartmentalizing, more about controlling for how the subcontractor accessed the data. Honestly the problem sounds more like something borne from ignorance than malice. It's a headache having to download every image you have to analyze, so why not copy the whole thing to a local network drive and work with it here? And then some hacker lifted it from the local network drive. Anyway I wasn't talking about the CBP specifically. I was responding to the question about why decentralization saves you from compromise. My response was that compartmentalization is useful for damage control.