4 ms·

> How do you test that in isolation? Is it easier to test after the ransomware attack?

by nn3 5y ago

bsder 5y ago
Yes, actually. Before the attack, all machines are active and being used. If you screw one of them up that happens to be running something obscure but vital, the screwup is your fault. After the attack, all machines are dead so the screwup is blamed on somebody else. If you have the email/memo (you did print it out and file it, did you not?) showing that you informed the CTO/CIO, blame for the screwup will get buried.
whartung 5y ago
Actually it is easier because you get to "test" it by reloading on the actual hardware, not separate hardware. To do a solid test, you need to restore the system. It's difficult to restore a running system because, well, it's running. That typically means a parallel environment. A single box represents a bunch of "magic values" that are stuffed in some config somewhere. Imagine several of those. "We need to restore SQL Server, the AD Server, the Application Server..." Reloading on a new environment is an easy way to find out those magic numbers, typically the hard way. Restoring on your existing hardware, with existing networks, existing IPs, etc. you're laying your software and configs over a known, working environment. How do you test a recovery of licensed software thats bound to the machine that you have running in production, for example? "Oh, sorry, you have a duplicate license detected" and it shuts down your production system for a license violation. "Sorry, we detect the wrong number of cores", or whatever other horrors modern licensing systems make you jump through. You DO have another dongle, right? (Do they still use dongles?) It can be far easier to do an image restore to your already working system than trying to load it up on something else. Since your production box is horked anyway, an image restore should "just work". But testing it, that's another story completely.
- Godel_unicode 5y ago
  Who is configuring physical servers by hand. Are you a part of some kind of museum exhibit? In all seriousness, you're talking about a business which is carrying a truly staggering amount of risk. If the margins are so tight they're running hand-rolled physical servers then restoration is a moot point. They'll go out of business if attacked. If you're not testing your backups, then they're broken with close to 100% certainty.

> How do you test that in isolation? Is it easier to test after the ransomware attack?

by nn3 5y ago

> How do you test that in isolation? Is it easier to test after the ransomware attack?

Yes, actually. Before the attack, all machines are active and being used. If you screw one of them up that happens to be running something obscure but vital, the screwup is your fault. After the attack, all machines are dead so the screwup is blamed on somebody else. If you have the email/memo (you did print it out and file it, did you not?) showing that you informed the CTO/CIO, blame for the screwup will get buried.

whartung 5y ago

Actually it is easier because you get to "test" it by reloading on the actual hardware, not separate hardware. To do a solid test, you need to restore the system. It's difficult to restore a running system because, well, it's running. That typically means a parallel environment. A single box represents a bunch of "magic values" that are stuffed in some config somewhere. Imagine several of those. "We need to restore SQL Server, the AD Server, the Application Server..." Reloading on a new environment is an easy way to find out those magic numbers, typically the hard way. Restoring on your existing hardware, with existing networks, existing IPs, etc. you're laying your software and configs over a known, working environment. How do you test a recovery of licensed software thats bound to the machine that you have running in production, for example? "Oh, sorry, you have a duplicate license detected" and it shuts down your production system for a license violation. "Sorry, we detect the wrong number of cores", or whatever other horrors modern licensing systems make you jump through. You DO have another dongle, right? (Do they still use dongles?) It can be far easier to do an image restore to your already working system than trying to load it up on something else. Since your production box is horked anyway, an image restore should "just work". But testing it, that's another story completely.

Godel_unicode 5y ago
Who is configuring physical servers by hand. Are you a part of some kind of museum exhibit? In all seriousness, you're talking about a business which is carrying a truly staggering amount of risk. If the margins are so tight they're running hand-rolled physical servers then restoration is a moot point. They'll go out of business if attacked. If you're not testing your backups, then they're broken with close to 100% certainty.