Note: Although this was created some time back (sorry for sharing this so late), there’re improvements to be made still. Discussions are always welcomed.
When responding to an enterprise network compromise, one big question (and source of pressure) is that network IOCs need to be determined quickly. While this information would usually come from the malwares/tools used in the compromise, the fact that the surfacing of network IOCs and triaging being done in parallel presents a Catch-22 situation: How do we find machines and malware without network IOCs available? How do we get network IOCs without analyzing any machines/malware suspects?
Proper setting up and regular monitoring of logs gives you the avenue to know what’s really happening with your box sitting out there in the internets, and to anticipate when bad things are about to happen. One of the warning signs would be that someone has been poking around your box, looking for an (easy?) way in.
The natural thing that would jump out at you then, is that this someone has been accessing your box in far higher volumes/durations, especially on services that should not be accessed by others.
This is one example of such accesses on a linux box: SSHD brute forcing over long periods of time.
The next version of Splunk is out!
Amongst the new features that Splunk’s advertising, a quick glance through the new version reveals that the revamped management interface might seem to make administering it/clusters easier. Also that the search and reporting features seem to have been beefed up too!
More to come after I poke around some more, and if I have the time to write something