7

I've read through How do I deal with a compromised server? and have followed the steps to cleaning-up/mitigating any future damage.

I'm just wondering if there are any post-clean up steps that are considered "best practice", such as:

  1. Informing the customers of the infection and clean up
  2. submitting the shells/infected files to any security firms
  3. reporting details of the exploit used to any security firms
  4. investigation/reporting of attacking ip address

I'm not sure if any of this information could be helpful to them or not, so currently I've just been meticulously record keeping.

Community
  • 1
Artsen
  • 71
  • 2

3 Answers3

2

This question could be highly opinionated in terms of "best practices."

However, there may be certain industry/contractual or legal requirements for customer notification or forensic investigation. To get the optimal response, you will need to seek guidance for legal counsel specific to a given incident. In the general sense, you should do what is right and in the best interests of your customers/users, but if you are operating a business you may have to balance that with your desire to have a going concern.

A good general place to start would be with NIST SP 800-61: "Computer Security Incident Handling Guide". You may also want to see SP 800-86: "Guide to Integrating Forensic Techniques into Incident Response".

There are also some CERT/SANS/etc resources:

Some references for laws and industry requirements (USA Specific Examples):

This report by Congressional Research Service also provides a summary of some US federal laws. This Berkley Law Paper may also be of interest for US federal laws.

Eric G
  • 9,701
  • 4
  • 31
  • 59
0

I will try to answer your questions as best as possible.

Informing the customers of the infection and clean up

I would not inform customers unless you have an SLA to do so or are compliance bound. Often this just causes panic by business folks. If there is PII lost, it may be in your best interest though.

submitting the shells/infected files to any security firms reporting details of the exploit used to any security firms

You can submit the files to Virus Total (virustotal.com). This is often distributed to AV vendors and you can view if this has already been submitted by others. Typically everything the vendor needs will be in the executable you will submit to them.

investigation/reporting of attacking ip address

You can submit details of IP addresses to vendors. I'm familiar with McAfee with my experience and their reputation engine is Trusted Source (trustedsource.org) and you can submit feedback to them.

Meticulous record keeping is in your best interest. Use the documentation to help justify and build additional policies around security and incident response. Surely this will not be the last time you will be breach (not anything against you, but that's just how it is), but a specific process you can build will help folks keep first responders' heads' clear and give them a direction to take. Look up a template for a incident response report to get started on this.

In all of the places I've worked (public and F100 private sector), the most valuable part of the post-incident actions is the debrief. Hindsight is 20/20 and it's important that you and your team understand all details and symptoms that were discovered. You must use these points to better understand your security posture and processes to handle such incidents or impacts to service. This is also the best time to review architecture as the business decision makers will be more loose with purse strings when a breach has occurred. Security is often overlooked or seen only as business expense without benefits to the business's profit margins when there is no security incidents.

PTW-105
  • 1,397
  • 9
  • 7
  • -1 for the advice about customers. You should urgently check with your legal services the applicable law and regulation to your company, your business and your country before doing anything else. **This can be a much bigger problem than the intrusion itself.** – ack__ Apr 22 '14 at 20:09
  • @ack__ - While I agree with you that legal counsel should be sought, I question notifying customers in large firms where security incidents like this are the daily occurrence. Informing customers every single time a piece of equipment is compromised is unlikely to happen. Often the business decides whether to make a public notification, not the security admin themselves. This decision often factors around a need-to-know basis and thus customer PII is typically the factor deciding to externalize a breach. – PTW-105 Apr 22 '14 at 22:42
  • I'm not saying customers should be informed of every security incidents, even less that the decision should be made by security. The point is to go for legal and management advice before doing anything else in case of a serious breach that might involve customer data. Doing otherwise is likely to put your employer at risk. Also, my job is precisely to help high profile and large firms manage their security incidents. – ack__ Apr 22 '14 at 23:06
0

Basically you're asking about incident handling best practices, but essentially as applicable 'after' you've already handled the incident. As far as I know and based on the specific questions you've presented, there is no cookie cutter approach for what your organization needs to do post "lessons learned" phase. It's really a matter of either what you are legally responsible or simply just willing/wanting to do. If valuable intellectual property was involved then that potentially opens up a can of worms. Likewise there are certain "things" which require you, like it or not, to contact law enforcement. etc. I think everyone gets the point. Characterizing the type of incident (I.P attacks and theft, DoS, malware, email stuff like harassment or phishing, espionage, policy violations like unauthorized use, unlawful activities, insider threats from casual non-destructive to intentional destructive, etc), determining the extent damages and then contacting the appropriate parties are all things which should have been done during the containment phase. Here is a resource to help you with said classification; CSIRT case classification document

Now, it seems you've already gone through identification, containment, eradication and recovery and I'm assuming you have watched and/or are watching carefully for the attacker's return? So let's just go over what's generally considered best practice in phase 6 of standard "by the book" incident handling. Many organizations/people "don't have the time" or bother to really go through with this phase but lets face it, the attackers are improving all the time so you need to improve as well. It's time to move on and make new mistakes, but the whole point of this process is to avoid repeating the same old ones. What you should do now is document what happened and how operations capabilities can be improved so as to prevent it and similar incidents from happening again. One way to do that is by creating a follow up report. Ideally you want to start on this report right away, immediately after recovery. The SANS institute makes available some useful incident forms you can use in this process. It's generally good practice to encourage all affected parties to review your draft. Once the report has been reviewed, schedule a "lessons learned" meeting if you can. Ideally this meeting should occur within within a week or two of resuming production, while the events are still "fresh" in everyone's memory. In general the main purpose of the meeting is to get consensus on the executive summary of your incident report. IMO the key of the executive summary is illustrating the importance of having effective incident handling procedures in place.

Also, look into the "seven deadly sins" of incident handling. You might find it useful.

Anonymous
  • 149
  • 4