HackDig : Dig high-quality web security articles for hacker

What To Do-And What Not To Do-When You Discover a Breach

2014-12-03 23:40

world image.pngData breaches are becoming a sad fact of life for enterprise IT departments, and all staff members are being asked to become increasingly vigilant about security. But while organizations focus their efforts on stopping intruders from getting in the door, they also need to ensure they have a strategy for what to do once a breach has already occurred.

The days and weeks after a breach is realized are critical, but they can also be emotional. There’s a tendency to want to turn on exhaustive logging, take servers offline, or even try to respond to the incident without knowing that you might be accidentally deleting evidence. The truth is doing these things can be counterproductive to forensic efforts at best, and could lead to bigger problems. The key is to understand the typical flow of actions to take in wake of a breach, incorporate best practices and have an incident playbook ready.

One of the most important steps from the outset is making sure that there is a clear process for notifying IT of any potential security issues from across the company. Often times, a major security incident is not first identified by the affected organization. They are made aware of a security concern from law enforcement, business partners like payments brands or even customers, which can take time to make it to the desk of the CIO because the contact receiving the information may not know where to go.

1 day to 1 week post-breach: Once the CIO, CISO, and IT staff are made aware of the breach, the CISO should follow a plan which consists of three parts: Directing IT to preserve evidence and to assess the size and scope of the breach, working with the Legal team to determine what needs to be shared with the public, and advising the CIO and CEO of developments to update shareholders on the situation.

The most important job of the IT security staff (in partnership with a third-party forensics expert) should be to start pulling event logs, firewall logs, sweep for excessive network traffic, look for new domain accounts, review any endpoint protection alerts. The organization’s Systems Administrator should turn on predetermined logging mechanisms on servers and databases believed to be impacted by the breach. This logging may give insight into who and how the system was breached, however it is important to exercise judicious use of logging as some files can grow rapidly if they are collecting too much data. Define areas and processes to enact ahead of time if possible and test them often.

Sometimes, the first reaction of well-intentioned IT staff is to try and remediate the issue by deleting files or altering configurations after a breach, but this is the WRONG approach as it could mean destroying valuable evidence in some circumstances. No logs should be altered or removed in order to preserve data (e.g. SQL transaction logs in the event the breach was a SQL injection attack). Looking at server logs may present information that is too verbose, and there shouldn’t be a rush to turn all logging on across the network as those log files may quickly fill up and bog down the system, causing further problems. The best approach is to treat any log files, error logs, or antivirus reports like evidence at a crime scene; focus on preservation and analysis.

1 week to 3 weeks post-breach: As the breach is contained by IT and the scope of the breach is realized, the marketing and legal teams should begin to focus on disclosing more information to customers and key audiences regarding the incident. This sharing of information should disclose the facts of the breach honestly without inciting fear, disclosing how the breach was executed, or who breached the system. The reason for leaving out the “who” and the “how” is to avoid compromising an ongoing investigation or opening up potential exploits for future attacks.

Disclosure laws vary among states and between the state and federal levels, so consult your legal team extensively to avoid missteps. Make sure you’re also protecting yourself with latest version of Symantec Endpoint Protection for maximum security.

It’s important to note, that these suggestions should be considered directional versus diagnostic as no two issue are ever completely alike.  One thing that is for certain is getting prepared for what is ahead during a major incident is no longer optional. Without an incident response program and crisis communication plan which includes managers of these departments as well as IT managers, there may be a gap of several days before IT can take action.

Coordination between departments is vital in the hours after a breach is realized; having a plan and following a playbook eliminates the guesswork. Ideally you’ll want to define them before a breach to avoid confusion. I’ve seen an alarming number of organizations lose even more valuable data in the wake of a breach due to having little or no response/communication plan. Every incident is different, but if organizations stick to guiding principles and develop playbooks for how to respond to certain types of incidents, they will be better prepared to combat them when they arise.


Source: hcaerb-revocsid-uoy-nehw-od-ton-tahw-dna-od-tahw/sgolb/tcennoc/moc.cetnamys.www

“What To Do-And What Not To Do-When You Discover a Breach”0 Comments

Submit A Comment

Name:

Email:

Blog :

Verification Code:

Announce

Share high-quality web security related articles with you:)

Tools

Tag Cloud