|
|
|
|
|
|
by jcrawfordor
2754 days ago
|
|
|
The way this article talks about IDS sounds, to me, like someone who has never worked with IDS professionally or on any large scale. This goes for other points in the article as well, but that seemed particularly glaring. I don't intend to defend Marriot, from other coverage it sounds like someone did a very poor job (although not necessarily Marriot itself). But this article also makes things sound far simpler than they are. My best guess is that the attacker gained access to a database server, and let's say they dumped the contents to a file and exfil'd the file (not always the best way to go, but often the best way to go). Assuming they stole database creds from somewhere else (e.g. some application), that might generate around a half dozen auditable log items on the database server. The retrieval of a large file would be a good opportunity for detection by SIEM content, but without further knowledge of the application it might not be - large file transfers from that machine might be normal as part of e.g. batch processing. For me, it's hard to say at this point that this would have been easy to catch at all. Perhaps it would have been, but if the attacker was some combination of competent and lucky (combined with the lack of measures like limiting database access rate for applications, which are quite rare in practice), they may have been in and out with very little detectable activity. |
|
|
Or an eccentric and occult edge case like "backups", especially if it's a database system. Sorry for the snark, but I've had to tell some people the importance of backups for production persistence like a broken record for a week or two.
And sure, you could have IDS rules / firewalls setup to flag or block traffic except to the backup storage hosts and the replication servers and the batch processing servers and the monitoring andso on and so on, flag files, ...
But that stuff is hard, requires a lot of maintenance and adds risk to a lot of critical / stress-powered processes. Change your backup storage at 3 am due to hardware failures? Whoops, the firewall of database host #13 wasn't updated, and now you have no more backups from that host.