• Of dead bodies and log files



    I HAVE a close friend who accepted a job in information security heading a large security operations center (SOC). Although we both started out as network engineers tinkering with modems, hubs, routers, switches, etc., I slowly migrated to the ‘sexier’ field, no doubt enticed by the mystery and geekiness of it all. As we narrate how our day ends up, he confesses that security is a very volatile and dynamic world. Unlike in networks, where it is easier to resolve issues because the IT infrastructure is pretty much structured and consistent. When a connection is slow, you can easily check whether it is a problem with the service provider, the network devices, and even the physical cable that connects them. The parameters are quite constant and any aberrations are easily spotted.

    Information security is the polar opposite. As security issues happen, it becomes a cat-and-mouse game, a race against the clock and even if you do manage to halt an attack, you still won’t know, nor can you be sure that it is over and done with. Because in security, any part of the IT ecosystem can be attacked or be used in an attack. That’s why the Anti-Cybercrime Law focuses on: 1) crimes against the computer system; and 2) crimes perpetrated using the computer system.

    In a “computer security incident response” scenario, there are four basic steps that are typically followed in dealing with attacks (not counting the other equally important tasks and processes in the incident response lifecycle – other entities might have a similar but more detailed process): 1) preparation; 2) detection and analysis; 3) containment, eradication, and recovery: and lastly, 4) post-incident activities which include root cause analysis and/or forensics and lessons learned.

    If there’s one thing that is not in short supply in information security investigations it is data. Applications or programs, servers (web, DNS, database, directory, etc.), switches, routers, firewalls, intrusion detection systems, anti-virus software, even the workstations themselves spew out a lot, depending on how it is configured. What is logged are called ‘Events’ – and these events may not even be a security incident at all.

    That is why an information security analyst would need to collect all of these logs and determine whether it’s just noise or an ‘actionable item’ worthy to be investigated. Just like in the hospital ER, they need to ‘triage’ a case and decide whether it is a real emergency worth sending to the doctors. Thankfully, modern-day tools are available to automate most of these but it doesn’t take away the raw talent, the keen eye, and experience an information security analyst puts in the table. They have a secure and stable role in security operation centers for years to come – until Skynet becomes self-aware, that is.

    You may ask, why not focus on the logs of a particular device itself like some other people do. Highlight the eye-catching stuff like ‘root,’ ‘Anon’, ‘grep,’ or all the other fancy and geeky-sounding words in that log file.

    Well, because if you do that, then you are just guessing. Another task that security analysts do besides conducting a ‘triage’ is ‘correlation.’ As stated above, an attack can come from almost all of the running parts of the IT ecosystem, internal or external of the target network. Getting logs containing the events, from various sources, arranging the pieces, linking them together and correlating each event will undoubtedly produce a more accurate conclusion. It’s akin to getting statements from several witnesses versus a solitary individual. More sources mean more facts to corroborate or dispute the incident.

    Going back to the four incident response steps enumerated above and skipping #1 (in the interest of space), #2, detection and analysis are done by security analysts; #3, containment, eradication, and recovery is usually the primary set of activities and the main focus of incident response as it is imperative to prevent the attack from spreading, remove the source of the attack (or block it temporarily), and get the system back up and running again.

    Then only afterwards, we can go to #4 – post-incident activities. This is where the ‘how’ gets answered and is usually the toughest part of the deal. At this stage, the forensics team will sift through all the key information both from the scene of the incident, to even other factors and data outside of the organization such as threat intelligence (events or chatter in the Internet or “dark web”) if it may bring light to determining the reason behind the attack, just like in a murder case, where you have to process the dead body to look for clues, you must also collect information from other sources. Most of the time, it is sometimes easier to process a body than a computer system. At least, the number of limbs, and organs don’t change.

    If there’s no intention to pursue legal action, post-incident analysis goes faster as investigators won’t have to worry about this little thing called ‘chain-of-custody’ and the preservation of the original state of digital evidence. Otherwise, root cause analysis (it will now be called computer forensics) would have to happen on ’mirrored’ storage systems and duplicate computer systems in order to preserve the original state of the target systems and guarantee that fidelity of the data.

    Else, who can dare say that screenshots and log files have not been altered to further one’s own interests?


    Please follow our commenting guidelines.

    Leave A Reply

    Please follow our commenting guidelines.