The Single Most Important Part of Dealing with a Phishing Attack is Preparing for the Attack Before it Actually Happens.
Phishing attacks come in all shapes and sizes. Well, pretty much all the same shape, but certainly different sizes. Victims are both users and organizations. Depending on the nature of the attack, those users can be organizational users or private consumers. I have written about phishing emails before, and sometime later added additional advice on how to see and avoid them.
But nadie es perfecto. Stuff happens (or something like that…).
Modern phishing attacks can be long lasting, pervasive attacks that can be very focused. Chances are that if your organization is the target of a prolonged phishing attack that eventually, people are going to break. The main questions then are around who broke and how bad is it? And, the “who” is not really that important for assigning blame, as much as it is for assessing damage. Consider for instance the impact if a call center employee loses their credentials. If they have limited internal or external access, someone getting access to their system probably does not gain access to highly sensitive information. Now consider the impact if the person compromised is your main system administrator, or the person who approves all ACH transfers. Now you have a whole different problem.
What do you do when your organization has been victimized by a phishing attack? Well, if you wait until you are actually under an attack it is too late. And, unfortunately, that is not hyperbole. The truth is, as with any incident response process, the single most important part of dealing with a phishing attack is preparing for the attack before it actually happens. As a point of reference, I once worked with a company who pretty much ignored any disaster preparedness or incident response. I was discussing their incident response process with the Director of IT, and he basically said that a successful attack or other “incident” at his company would essentially be classified as an RGE - Resume Generating Event.
Prepare for the Phishing Incident
So you prepare for a phishing incident. To some extent, the phishing incident should be handled essentially similar to any other kind of incident. That includes all of those things related to ensuring that you have defined security policies, and a tested incident response process BEFORE the actual incident, instead of trying to make stuff up on the fly in the middle of the chaos of an actual phishing attack (trust me; that process has “fail” written all over it).
But, you should also being doing things that are focused specifically on things that will support you through a phishing response. You want to think about how ready you are? You would prefer to be able to answer all of the following questions with a “yes”.
Do you have a list of all Internet domains owned by your company?
Having this list will allow you to focus your response to sites that you know include your organization and organizational systems, and will help ensure that you do not omit any websites, and, for that matter, identify websites that appear to be involved but are not owned by you.
Have you prepared an informational web page that warns partners and customers about an active phishing attack?
You would basically hold the warning page in storage, and you would only publish it if you are the target of a phishing attack. The web page would be one page to communicate to partners and customers that you, and possibly them, are being targeted as part of the Internet based attack, and that they should exercise reasonable suspicion when receiving emails.
Have you developed and tested procedures to ensure the proper deployment of the informational web page to the production environment?
Yes. This is completely a paranoid IT view of the world. If you didn’t test it, and prove it worked, it isn’t done, and it doesn’t work.
Have you drafted e-mails that you can send to providers and other external resources in the event of a phishing attack?
These e-mails will be used to communicate to outside resources such as those who may be unknowingly hosting phishing sites, and should include a request to the hosting company for them to disable the offending sites. You should prepare these e-mails in every language in which you do business in order to simplify the communication process during an incident.
Have you consulted internal and external legal counsel about what kind of legal action you will/might take in the event of an attack?
Realistically, you would probably not have a good target for legal action, but you should think about this beforehand. The decision whether or not you intend to sue or involve legal authorities can shape your response, especially when you think about how much investigation and evidence collection you want to do, instead of just restoring normal operations.
Do you maintain an internal escalation list, including names, contact information, and responsibilities for all staff involved in incident response and management? (and, have you tested your escalation?)
Sometimes, the devil is in the details. Make sure you have the right people in your escalation list. Are the people who register your domain names on the list? Did you include all of the required technical resources, legal team contacts, PR firm, and any other persons who are responsible for supporting incident response efforts? And do you have current contact information for all of them? Better yet, do they know that they are on the list? I was working with a company that recently did a disaster recovery exercise, only to find out that several of their “key” resources could not be found. One had no idea he had been added to the escalation list, while the list included outdated contact information for at least two other key responders. At least they found out during an exercise (remember that “prove it works” thing?
Does your contact list people who actually know how to deal with an incident?
Ensure that your escalation list includes properly trained personnel who are authorized to make decisions and take actions in response to incidents. Their responsibility and authorization should be written in a clear and concise manner.
Have you clearly communicated incident handling and management guidelines to responsible staff?
The responsible people should have available all the procedures and knowledge they need to be able to respond to an incident in a meaningful manner. You don’t just need an incident response policy; you need people to know where it is and what it says.
Have you trained staff on phishing?
Do your people know what “phishing” is? Cold they identify a potential/probably phishing email? Do they understand enough about how and why phishing works? “Phishing” is a different enough beast that understanding some phishing details can be invaluable during containment and recovery.
Do you also have a list of contact information for external resources that may be involved?
It will be handy to have a centralized contact list that includes all of your contacts at hosting companies, registry organizations, and any external e-mail providers so you do not have to go digging out information when you need it.
Do you have a way to communicate externally if your phishing attack escalates?
Many phishing attacks are accompanied by Distributed-Denial-of-Service attacks to help distract responders from the phishing related attacks. You can implement a simple point of contact email address that is simple for anyone to remember (e.g., firstname.lastname@example.org). You should also ensure your organization maintains a means of external communications in the event primary communications are lost during the incident. You might use alternate web pages or web sites, or social media, such as Twitter, Facebook, or LinkedIn.
Have you already set “phishing” expectations with your partners and customers?
You should set your internal standards about how you communicate with customers and partners by making explicit decisions about whether or not you will ask them to update information via email, and whether or not you will include links in emails. To help defeat phishing attempts, you should avoid including links in your emails, and insist on advising customers and partners to visit your site directly. You should communicate with customers and partners in a proactive manner by educating them about phishing attacks. You should advise them that you will not include links in emails, and, if appropriate, that you will not ask for sensitive information via email and/or phone.
Actually dealing with a phishing attack once you get hit is still another matter. Remember the old adage – “An ounce of prevention is worth a pound of cure”? Incident response is just another example of where that is actually true. If you aren’t prepared for the attack before it comes then you are behind before you even start.