3 ms·

How do top tier tech companies, who are very likely continuous targets for this kind of thing, avoid ransomware attacks? I know there's nothing like that at my

by wffurr 6y ago

How do top tier tech companies, who are very likely continuous targets for this kind of thing, avoid ransomware attacks? I know there's nothing like that at my employer.

formercoder 6y ago
The basics go a long way: two factor auth and privilege minimization.
staticassertion 6y ago
There are two big things you want to do: 1) App whitelisting. This is not the strongest mitigation (attackers with exploits can move in memory), but it stops drive-bys and 99% of malware, plus it massively reduces noise on the network. 2) Reduce lateral movement. If the attacker accesses an employee laptop, encrypts it, but can't move to other devices, that's not a very compelling ransom.
- mox1 6y ago
  As someone who runs a Banks internal Red Team group, the App Whitelisting is the biggest roadblock for us. Carbon Black (if properly setup and tuned) is a large leap to overcome. Drive-by attacks just stop, you need a dedicated method to bypass Carbon Black. That is usually very org dependent. You don't known Carbon Black is there until something doesn't work. That "not working" propagates an alert up to the security team.
  - staticassertion 6y ago
    App whitelisting is rarely rolled out, but it's just such a definitive win these days. a) You just kill ~85% of malware (rough estimate, probably technically higher, but I'm basing that on stats around interpreter-based/LOLBAS malware). Anything that isn't targeted is probably dead in the water. b) You know exactly what's running on everyone's computers, more or less, so you have a way easier time baselining and building monitoring. It's honestly easy-mode for security. But it's hard to roll out to a company a decade after it's been running, so you really need to do it early on. And most orgs don't care about security until after a breach, at which point they're too large and slow to get something like that done.
    - jjoonathan 6y ago
      It's easy-mode for security because it offloads the cost of security to employees. Done right, many hands make light work. Done wrong, it's the very picture of "if nobody can use it, hackers can't either." I'm interested in learning how to do this right, because I've only ever seen it done wrong. How do you streamline the process for getting programs approved? How do you accommodate developers who need to generate and run code?
      - staticassertion 6y ago
        > It's easy-mode for security because it offloads the cost of security to employees. Yeah, absolutely. But I consider this to be, when done right, a good thing. A single security team is going to drown trying to scale your company's security asymmetrically with your company's growth. For every 1000 developers you might have 5-50 security engineers depending on how serious the company is about it. Spreading out security work across the company scales extremely well. Of course, you want to minimize burden too. There are a number of ways you can go. Personally, at my company, we're so small that it's trivial. We rarely onboard new employees and pretty much all approvals are handled within a few minutes of the employee getting their laptop. As you scale it may make more sense to crowdsource this. 'Upvote' is one such tool. https://github.com/google/upvote https://github.com/google/upvote Upvote-like systems basically give you reputation based approvals. If you can convince a number of your coworkers that the app is worth installing, you can install it. I've seen a number of systems built this way that combine crowdsourced approvals with other forms of reputation. At my company we use Chromebooks. Apps/Extensions are only allowed once approved. The Linux environment is where development happens. This is nice because there's a strong separation between environments. That said, we don't do any sort of application whitelisting in the Linux environment today, due to a lack of tooling support. If we did, what I'd like to do is just have simple rules like "If the binary was created by gcc etc allow it to execute". Santa allows for process-tree based rules like this. Another option is developer VMs like in EC2. These can be nice for devs because they're often much more powerful than a laptop anyways. It requires a bit of tooling to work smoothly though with local IDEs and whatnot.
        6y ago
- AnIdiotOnTheNet 6y ago
  Active defense is another option. It is possible to set up a trap such that when certain canary resources are modified they trigger an action to disconnect and lock out the offending user account as well as alert admins to the issue. 98% of the time this will be triggered by an admin performing a task that just happens to touch that resource, but it is incredibly helpful the other 2% of the time.

by wffurr 6y ago

How do top tier tech companies, who are very likely continuous targets for this kind of thing, avoid ransomware attacks? I know there's nothing like that at my employer.

formercoder 6y ago

The basics go a long way: two factor auth and privilege minimization.

staticassertion 6y ago

There are two big things you want to do: 1) App whitelisting. This is not the strongest mitigation (attackers with exploits can move in memory), but it stops drive-bys and 99% of malware, plus it massively reduces noise on the network. 2) Reduce lateral movement. If the attacker accesses an employee laptop, encrypts it, but can't move to other devices, that's not a very compelling ransom.

mox1 6y ago
As someone who runs a Banks internal Red Team group, the App Whitelisting is the biggest roadblock for us. Carbon Black (if properly setup and tuned) is a large leap to overcome. Drive-by attacks just stop, you need a dedicated method to bypass Carbon Black. That is usually very org dependent. You don't known Carbon Black is there until something doesn't work. That "not working" propagates an alert up to the security team.
- staticassertion 6y ago
  App whitelisting is rarely rolled out, but it's just such a definitive win these days. a) You just kill ~85% of malware (rough estimate, probably technically higher, but I'm basing that on stats around interpreter-based/LOLBAS malware). Anything that isn't targeted is probably dead in the water. b) You know exactly what's running on everyone's computers, more or less, so you have a way easier time baselining and building monitoring. It's honestly easy-mode for security. But it's hard to roll out to a company a decade after it's been running, so you really need to do it early on. And most orgs don't care about security until after a breach, at which point they're too large and slow to get something like that done.
  - jjoonathan 6y ago
    It's easy-mode for security because it offloads the cost of security to employees. Done right, many hands make light work. Done wrong, it's the very picture of "if nobody can use it, hackers can't either." I'm interested in learning how to do this right, because I've only ever seen it done wrong. How do you streamline the process for getting programs approved? How do you accommodate developers who need to generate and run code?
    - staticassertion 6y ago
      > It's easy-mode for security because it offloads the cost of security to employees. Yeah, absolutely. But I consider this to be, when done right, a good thing. A single security team is going to drown trying to scale your company's security asymmetrically with your company's growth. For every 1000 developers you might have 5-50 security engineers depending on how serious the company is about it. Spreading out security work across the company scales extremely well. Of course, you want to minimize burden too. There are a number of ways you can go. Personally, at my company, we're so small that it's trivial. We rarely onboard new employees and pretty much all approvals are handled within a few minutes of the employee getting their laptop. As you scale it may make more sense to crowdsource this. 'Upvote' is one such tool. https://github.com/google/upvote https://github.com/google/upvote Upvote-like systems basically give you reputation based approvals. If you can convince a number of your coworkers that the app is worth installing, you can install it. I've seen a number of systems built this way that combine crowdsourced approvals with other forms of reputation. At my company we use Chromebooks. Apps/Extensions are only allowed once approved. The Linux environment is where development happens. This is nice because there's a strong separation between environments. That said, we don't do any sort of application whitelisting in the Linux environment today, due to a lack of tooling support. If we did, what I'd like to do is just have simple rules like "If the binary was created by gcc etc allow it to execute". Santa allows for process-tree based rules like this. Another option is developer VMs like in EC2. These can be nice for devs because they're often much more powerful than a laptop anyways. It requires a bit of tooling to work smoothly though with local IDEs and whatnot.
      - 6y ago
AnIdiotOnTheNet 6y ago
Active defense is another option. It is possible to set up a trap such that when certain canary resources are modified they trigger an action to disconnect and lock out the offending user account as well as alert admins to the issue. 98% of the time this will be triggered by an admin performing a task that just happens to touch that resource, but it is incredibly helpful the other 2% of the time.