Kisha Gulley was once kicked out of a Facebook group for mothers with autistic children after a c...Read More
I recently spoke to a Chief Information Security Officer (CISO) who explained that he disliked marketing and saw it as a risk and cost center to his business. He seemed to believe that everything his company’s marketing team did on its website was a risk and even called some standard marketing practices “reckless.” I get it. To those who are unfamiliar with marketing, a lot of what marketers do can seem strange and intimidating. It is the marketing team’s job to make sure prospects know the business exists and convince them to interact with the business by reading blogs, downloading content, and sharing their contact information. Collecting a prospect’s contact information and safely storing that information is key to building business relationships, conveying product/service value propositions, and, ultimately, generating revenue.
By digging deeper in the conversations with the CISO, I discovered that he had a deep fear that his company’s marketing team and any assets they controlled (e.g. the website, third-party applications, etc.), would become the weakest link in the security chain.
Conceptually, his fear was justified. Reducing website breach risk is crucial, because website attacks are a very real and dangerous thing. Fortunately, there are things that can be done to mitigate a breach when it happens and prevent breaches before they do significant damage. Let me walk you through some steps and best practices on how you can quickly recover from a website breach.
First things first. Take a deep breath. Accept that your website or web application has experienced a client-side attack, and keep in mind that the attack may have been ongoing for weeks or months. The damage has been done and the task at hand is to recover quickly but not make things worse or demotivate your people. If your business already has an incident response plan in place, go ahead and follow it. In the event that this is your first client-side breach, work closely with your team to learn and grow together. Encourage them to use the opportunity to enhance their skill set.
Do whatever is recommended and necessary to contain the breach. This may mean temporarily shutting the website down, so that the attacker can’t steal any more data or engage in other malicious deeds. Although, depending on the type of attack, this may or may not be the best strategy. For example, some security investigation teams may want to keep the system up for a short time to stealthily observe intruder activity to help ascertain the type of threat and even possibly identify the intruder. (This is particularly important if it is an insider threat.) Further, if you take the site down for a week to contain the breach, only to find out that the attack wasn’t targeted at your customers and you could’ve investigated while the website remained functional, the effect on operations and sales may be significant. Ultimately, though, it is important that you take whatever steps you feel are necessary to protect your customers, particularly if they are the ones being victimized by the attack. This may mean that you shut your site down for a time, while you investigate and remove any malicious code.
The investigation process involves carefully reviewing each first- and third-party script operating on your website to understand what data the scripts have access to and why. For example, are any of your scripts sending data to a foreign country or to a known command and control domain (C2)? Are any of these scripts unused or are they zombie scripts? If you find unidentifiable scripts, then shut these scripts down or change their configurations to prevent them from accessing sensitive data, until you can ascertain their authenticity. In addition, deploy a Zero Trust approach across the website to prevent any remaining scripts from accessing or manipulating data that the scripts have no need to retrieve.
At this point, you likely have zeroed in on any corrupt third-party or malicious scripts, malware, or backdoors running on your website. Typically you will be able to find suspicious or unauthorized client-side applications or scripts running on your website or web application. Learn as much as you can from them, such as the file path and where data might have been sent, and then shut them down immediately.
If you are able to identify the attacker, you may be able to determine whether the attack is the result of an insider threat or an external cybercriminal. You may also be able to determine the point of origin or entry for the attack. This is critical to avoid future breaches and enhance any current security controls (or add new security controls to cover an exposed gap).
Once you are comfortable that your website or web application is operating safely again, it’s time for damage control. If customer data was exfiltrated, you need to follow your local laws and regulations to inform your customers of the breach. It is important to note that depending on the compliance regulations, cyber insurance policy terms, or any contractual obligations you have with your customers, you might need to notify the authorities and your customers and partners ASAP, even before you have recovered from the incident. Talk to your legal and public relations teams to determine the best approach.
When you do notify your customers, they will want to know what information was exposed and how you plan to ensure a breach doesn’t happen again. There are a few key items to outline for them if you decide to announce the breach:
Once the breach has been contained and you’re certain your business and customers are no longer at risk, then you need to prepare for future attacks, because in spite of your best efforts, no web application or code is going to be perfect, and the threat of future attacks is always looming in the distance.
If you are like most organizations, a client-side attack is something new and unknown. In order to properly prepare for future attacks, you have to collect as much data, intelligence, and information as possible. Here’s a quick list of the types of information your organization should capture:
Threat actors love to find vulnerabilities in your code so that they can exploit them. When preparing for future attacks, it is important to ascertain whether your website is up to date. Are you using the most secure code libraries? Have you deployed all available patches? Take your time to scan your website or web application and mitigate risk as much as possible. If there are any vulnerabilities without an available patch, track it, or find a work around. Make sure you identify:
One thing to note, traditional vulnerability scanners are designed to scan back-end code and systems, a.k.a. server-side technologies. It is unlikely that they will be able to detect every client-side vulnerability that a industrious threat actor might use against you. To learn more about client-side vulnerability scanning, check out our blog.
Next, patch all vulnerabilities you uncovered immediately. If there isn’t an available patch, do some research to find out if there is a way to reduce the risk of vulnerability exploitation. You will likely have to end any unauthorized or foreign processes, remove corrupted or unauthorized files, and, if the threat actor modified any client-side script, replace modified files with approved or sanitized versions.
Once you have regained control over your web applications and websites, use the intelligence you have collected to validate and, if necessary, upgrade your defenses. Use the threat actor tactics, techniques, and procedures (TTPs) that successfully breached your website previously to see if the same TTPs still work. Use the client-side cyber threat intelligence (CTI) you have collected and look it up in open-source CTI feeds or in paid feeds like VirusTotal. Learn more about your attacker, see how else they might attack you, and pressure test your website to see if those other TTPs might work.
You may also wish to create a clone of your website to test your defenses. If you are using real TTPs, you don’t want to harm your customer-facing website. The goal is not to disrupt your businesses ability to grow and interact with your customers.
The post How to Recover from a Client-side Attack appeared first on Feroot.
*** This is a Security Bloggers Network syndicated blog from Feroot authored by firstname.lastname@example.org. Read the original post at: https://www.feroot.com/blog/how-to-recover-from-a-client-side-attack/