2 ms·

The OS, files and configuration which can be unchangeable are trivially replaceable and thus does not really need to be protected. The configuration and data w

The OS, files and configuration which can be unchangeable are trivially replaceable and thus does not really need to be protected. The configuration and data which gets changed all the time is valuable (the effort that was made in making those changes) and the prime target of ransomware, and it can't be write-protected because, well, it needs to get changed. I mean, if "reimage all these computers to the default configuration" would be a viable solution, everybody would just do that instead of paying large ransoms.

mikewarot 6y ago
>The OS, files and configuration which can be unchangeable are trivially replaceable and thus does not really need to be protected. Precisely the wrong way to think about this. If the OS can't protect itself, you've got a system with zero security.
- PeterisP 6y ago
  Well, that's true, OS being able to protect itself is useful and necessary, but my point is that it's nowhere near sufficient (as your parent post seems to imply) for preventing consequences of ransomware attacks, because by the time standard OS protections (which are reasonable) are broken because attackers have privileged access, they can also do worse things than just attack the single computers' OS, and if they can't get privileged access, well, then the OS is effectively write-protected anyway unless you're using something totally outdated. IMHO if the OS and its configuration would be securely write-protected (perhaps from media that's physically read-only?) that wouldn't help much if at all. It won't prevent lateral movement through the network (that's often memory only, no need to write to disk), it won't prevent persistence through theft of credentials or kerberos tickets (and possibly make it harder to rotate credentials), and of course it won't prevent the exfiltration, encryption and/or destruction of the actually valuable data. If we look at an advanced ransom attack (e.g. as many described in this article - manually operated after initial access like many Emotet attacks, not some purely automated malware) then I struggle to imagine what parts of the attack would be thwarted if the OS and config would be write protected - do you have something specific in mind?
  - mikewarot 6y ago
    >do you have something specific in mind? First - protect the AD and authentication infrastructure from a black start event. I'd have an offline physical machine, no matter how old, that was a viable backup domain controller. I would have a stack of hard drives for it, and a copy of clonezilla. Every so often, clone the hard drive, boot the replacement, and sync it with the domain, then turn it off. For the truly paranoid, do this in each location. Keep the machine and drives in a safe. Test the black start backups on a temporary network built from spare hardware. Note that if you boot a Windows machine, it might adapt itself to the hardware and cause issues, so discard that image, and regenerate it. In a black start event, you could turn off all the outside networks, and start with the old AD server, and restore from backups. -- Any Virtualization or SAN layers should have administrative credentials that are unused for anything else, and only written down on pieces of paper, never scanned or typed in. All servers should have saved images in offline, unencrypted hard drives, in a safe. -- The main thing then is to get periodic offline unencrypted backups of the systems and data in a safe. -- So, if the system is breached, there is at least a way to restore to the last backup, and you have some confidence it actually works.

mikewarot 6y ago

>The OS, files and configuration which can be unchangeable are trivially replaceable and thus does not really need to be protected. Precisely the wrong way to think about this. If the OS can't protect itself, you've got a system with zero security.

PeterisP 6y ago
Well, that's true, OS being able to protect itself is useful and necessary, but my point is that it's nowhere near sufficient (as your parent post seems to imply) for preventing consequences of ransomware attacks, because by the time standard OS protections (which are reasonable) are broken because attackers have privileged access, they can also do worse things than just attack the single computers' OS, and if they can't get privileged access, well, then the OS is effectively write-protected anyway unless you're using something totally outdated. IMHO if the OS and its configuration would be securely write-protected (perhaps from media that's physically read-only?) that wouldn't help much if at all. It won't prevent lateral movement through the network (that's often memory only, no need to write to disk), it won't prevent persistence through theft of credentials or kerberos tickets (and possibly make it harder to rotate credentials), and of course it won't prevent the exfiltration, encryption and/or destruction of the actually valuable data. If we look at an advanced ransom attack (e.g. as many described in this article - manually operated after initial access like many Emotet attacks, not some purely automated malware) then I struggle to imagine what parts of the attack would be thwarted if the OS and config would be write protected - do you have something specific in mind?
- mikewarot 6y ago
  >do you have something specific in mind? First - protect the AD and authentication infrastructure from a black start event. I'd have an offline physical machine, no matter how old, that was a viable backup domain controller. I would have a stack of hard drives for it, and a copy of clonezilla. Every so often, clone the hard drive, boot the replacement, and sync it with the domain, then turn it off. For the truly paranoid, do this in each location. Keep the machine and drives in a safe. Test the black start backups on a temporary network built from spare hardware. Note that if you boot a Windows machine, it might adapt itself to the hardware and cause issues, so discard that image, and regenerate it. In a black start event, you could turn off all the outside networks, and start with the old AD server, and restore from backups. -- Any Virtualization or SAN layers should have administrative credentials that are unused for anything else, and only written down on pieces of paper, never scanned or typed in. All servers should have saved images in offline, unencrypted hard drives, in a safe. -- The main thing then is to get periodic offline unencrypted backups of the systems and data in a safe. -- So, if the system is breached, there is at least a way to restore to the last backup, and you have some confidence it actually works.