INCIDENT RESPONSE FOR BREACH DETECTED AT SLIPPERY SLOPE LLC

Divya Kothari

Director of IT | Slippery Slope

On 3rd May 2016, information systems at Slippery Slope were found to have been breached. In particular,

the application server system was compromised from a remote location and a root kit was found. We

discovered that not all credentials for accessing the database were stored securely, there were suspicious

logins and incomplete logs to the database. What this meant was that the attacker had control over not just

the application server, but the web and database server connected as well.

Our company is a small organization but is steadily increasing. With approximately 95% of its sales carried

out online, it stores a lot of transactional and personal or sensitive company information, everything hosted

on the company’s own servers. Unfortunately the company does not have an existing incident response or

disaster recovery plan and this hack is the first of its kind. All the computers have anti-virus software and

firewall applications installed and updated with the latest patches. It is also compliant with the necessary

frameworks and is subject to regular state audits but there is no schedule for internal audits. The company

has a policy of conducting a system backup every night at 10 pm. Lastly, while connection between the

servers is encrypted, the data itself on the servers is not.

Immediate Action Plan

As soon as the breach was discovered, within five minutes:

News of the breach was communicated to each department within the company, the IT team

being one of the initial ones to have been contacted.

Assembled a team of IT specialists – Wanda, James, Jill, Ed and Mike – to contain the breach and

who could take measures to confirm the nature and source of the attack, identify the different

systems which were compromised, files accessed and sensitivity of the files.

A quick RACI chart was drawn on paper, according to which Wanda and Ed were heading the

responsibility for trying to isolate and remove the infected parts, supported by James, Jill and

Mike.

While Wanda, James and Ed immediately began changing encryption keys, Jill and Mike started

searching for all kinds of suspicious activity by reviewing log files, unusual connections, activity

during non-working hours, etc.

Meanwhile all three servers were disabled temporarily (two hours) and all updates were

continually reported to the top management with the help of a few more employees.

Jill acted as a liason between the team and the upper management, which in consultation with the

legal, human resources and public relations officer, chalked out what needed to be informed to

external stakeholders such as clients, law enforcement, vendors, suppliers, distributors, state

entities, etc. and in what manner. This included communicating the necessity of shutting down

the servers for a few hours.

Next 24 Hours

Soon after, the top management along with consultation with the legal and operations team created a team

in order to identify the stakeholders involved, prioritize the assets/systems/data affected and assess the

impact and consequences due to the breach. Meanwhile the IT team was instructed to:

Continue efforts in trying to remove the rootkit either manually or automatically. Eventually the

team decided to reformat and install the operating system which was successful in eradicating the

intrusion.

Ed was also working simultaneously with James and Jill, searching for other possible intrusions

by running a scan and checking system files, memory, etc. They were asked to record all their

findings – exact method, duration, length of attack, etc.

A team of legal experts was also gathered to collect forensic evidence of the existing logs,

difference between state of compromised system and baseline performance level.

Long Term Plan

Create a well thought out and structure step-by-step procedure to be followed in the event of a

disaster and the incident response to combat the same.

Maintain a risk registry of the dates, risk types, their description, and likelihood of occurrence

along with severity of impact.

Also create threat card for potential threats and vulnerabilities, the likely spots for attack and a

RACI chart to assign different powers to the right personnel within the organization. This will

save time and planning when a breach occurs with respect to action planning

Since the threat actor – individual or group was not identified, search for any signs that could

trace back to the source or keep a look out for potential activity on similar lines to prevent

intrusions in the future.

Plan to have periodic internal audits covering all of the company’s information systems. Also

encourage policies that ask employees to change passwords frequently, be aware of phishing &

employ techniques such as monkey chaos, etc. to make the internal infrastructure more resilient.

In a nutshell…

We saw that within the first 24 hours, the company was able to successfully contain the threat. Even

though it could have turned out to be a hasty decision but luckily for the company, there were

reasonably strong backups stored in a remote location. We know that rootkits can be installed in

several different ways, even commercial security products and seemingly safe, third-party

application extensions. Moreover, often these do not spread by themselves, but are just a component

of blended threats, their detection is tedious work, more than half the work was done as our

company discovered the rootkit embedded in one of our servers. Slippery Slope was very fortunate

as it was able to completely get rid of it as there are many cases where removal of this intrusion is

almost impossible. This incident acted as a reminder for everyone in the organization to be wary of

their browsing and downloading hygienic content and the repercussions of allowing an opportunity

for threat actors to enter and grow within an entity’s information system lifecycle.

REFERENCES

Stoyanov, 15th Jan, 2016. “How to remove a rootkit permanently” Virus Guides. Accessed on 7th May, 2016. Retrieved

from: http://virusguides.com/how-to-remove-a-rootkit-permanently/

“Responding to IT Security Incidents” Microsoft Technet. Accessed on 3th May 2016. Retrieved from: https://technet.microsoft.com/en-us/library/cc700825.aspx#XSLTsection127121120120

Richter & McDonough, 24th October 2014 “Creating a Risk Register” Bright Hub Project Management. Accessed on

6th May, 2016. Retrieved from: http://www.brighthubpm.com/risk-management/3247-creating-a-risk-register-a-free-

excel-template/

“Rootkit” Avast. Accessed on 4th May 2016. Retrieved from: https://www.avast.com/c-rootkit

Winder, June 2011. “Top incident response steps: Incident response team responsibilities” ComputerWeekly. Accessed

on 6th May 2016. Retrieved from: http://www.computerweekly.com/tip/Top-incident-response-steps-Incident-response-

team-responsibilities