As an example, in the UBS Duronio case, Mr. Duronio executed code that deleted everything in its path, but isn't there a backup server? Why was UBS hit by the loss of data? If the backup is available, even if rm command was executed, there would be a way to retrieve the backup data...
-
Hi Mark - I have edited to make this question more generally useful Hope that is okay.– Rory Alsop ♦Jun 14, 2012 at 15:53
-
2Isn't this question a bit presumptuous? A lot of businesses don't maintain and/or test their backups as well as they should. Even with good backups, you've still got the down-time required to retrieve and restore them coupled with the loss of data gathered/created since the last backup.– IsziJun 14, 2012 at 16:00
-
1For reference, Duronio's attack code is explained here. Deadly simple.– Mark BeadlesJun 14, 2012 at 16:03
Add a comment
|
2 Answers
A backup, if there is one, takes time to get restored, if it can be. In other words:
Not every company has good backup practices. Considering that, as noted in the security investigation, UBS had other poor security practices it may not be surprising if they didn't have good backups.
Even if a backup has been made it takes time to restore. During this time the server is not in operation. So if it takes a day to restore, you're down for a day, which can be a devastating loss for the kind of operations UBS does.
Not every backup can be restored. The only way to know for sure is to practice restoration, and this is so time-consuming and expensive that many places never do this.
answered Jun 14, 2012 at 16:00
-
10+1, a minor point to add: In case of an malicious sysadmin, he might delete the backups, too. Jun 14, 2012 at 16:05
There's several reasons deletion of production data, especially by a malevolent sysadmin, will have a significant impact on a company - with or without backups:
Many companies don't do backups, or don't do them right. Without good backups, you may not ever be able to recover data that's been nuked by a sysadmin.
Companies that do have backups don't always test them. Without regularly testing restoration of your backups, you can never be sure that they'll actually work when needed. In the middle of an incident response or disaster recovery is the worst time to find out your backups or your restoration process are no good.
The sysadmin may delete the local backups as well. If the company doesn't also keep off-site backups (and many don't) they could be entirely out of luck in this case.
Backups are a snapshot of the past. Any data between the time the last backup was made and the time of a total data loss incident is probably lost forever. If the company has to resort to using an off-site backup, this impact is likely even greater because off-site backups are usually older.
Backups take time to obtain and restore. In most cases, this means the production environment that relies on the data from that backup is unavailable until the backup is restored. If restoring from an off-site backup is necessary, that requires even more time.
Loss of data means loss of credibility and confidence. Any significant security breach such as this, especially if made public, will have an impact on the company's image. Even if you're able to fully restore data up to the very last minute before the incident, your company will never quite be looked at the same again.
To sum up: Even if you do have good backups that can be restored, there's still a significant short-term impact while that process is in work. In the long-term, you'll still suffer the impact of a hit to your company's reputation and will also see some impact due to data that couldn't be recovered.
-
I read an article once (can't find it right now) that about 80% of the backups made world wide, do not contain what the sysadmin expects it to contain. These are of course huge numbers. Caused a.o. things not testing backups / worn out media, ...– jippieJun 15, 2012 at 7:11