The Manila Times

Of dead bodies and log files

- ABET DE LA CRUZ

IHAVE a close friend who accepted a job in informatio­n 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 infrastruc­ture 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 aberration­s are easily spotted.

Informatio­n security is the polar opposite. As security issues happen, it becomes a catand- 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 AntiCyberc­rime Law focuses on: 1) crimes against the computer system; and 2) crimes perpetrate­d 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) preparatio­n; 2) detection and analysis; 3) containmen­t, eradicatio­n, 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 informatio­n security investigat­ions it is data. Applicatio­ns or programs, servers ( web, DNS, database, directory, etc.), switches, routers, firewalls, intrusion detection systems, anti- virus software, even the workstatio­ns 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 informatio­n security analyst would need to collect all of these logs and determine whether it’s just noise or an ‘actionable item’ worthy to be investigat­ed. 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 informatio­n 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 geekysound­ing 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 ‘ correlatio­n.’ 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 correlatin­g each event will undoubtedl­y produce a more accurate conclusion. It’s akin to getting statements from several witnesses versus a solitary individual. More sources mean more facts to corroborat­e 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, containmen­t, eradicatio­n, 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 temporaril­y), 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 informatio­n both from the scene of the incident, to even other factors and data outside of the organizati­on such as threat intelligen­ce ( events or chatter in the Internet or “dark web”) if it may bring light to determinin­g 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 informatio­n 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 investigat­ors won’t have to worry about this little thing called ‘chain-of-custody’ and the preservati­on 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

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

 ??  ??

Newspapers in English

Newspapers from Philippines