I might assume that you found this blog while conducting research on how to protect your business from skimming breaches. Let me guess… you just survived a Magecart-type, cross-site scripting (XSS), formjacking, skimming, or other client-side attacks? Now your CISO, CEO, or board are asking you to figure out how to ensure this doesn’t happen again?
You are not alone! Most security organizations struggle with finding recommendations on how to build a client-side security program. There’s a good reason for that. To date, cybersecurity has been focused on mapping out the attack surface and managing security operations solely from the businesses or server-side perspective. Client-side security (also known as user-side security) that is protecting customers, has been an afterthought at worst and a tedious task at best.
As an industry, we need to start to focus not only on “who is attacking me”, but also on “who is attacking my customers”.
Cyber threat actors have found that it is relatively easy to exploit constantly changing JavaScript code. Client-side security requires an awful amount of manual work to ensure the security of web applications and websites and the data that they capture, share, and store. The client-side web browser is a fundamentally different attack surface from any server-side technology. To successfully deploy and manage a client-side security program, security teams need to adopt a completely new point of view, approach, and skill set. For many security teams, the concept of client-side security is still relatively foreign.
Let me walk you through some of the basic components of a client-side security program. Hopefully you will learn some best practices to reduce the client-side attack risk to your business.
Inventory Management
Key Action: Map your client-side attack surface to make an inventory of your web-assets.
First and foremost, you need to know what web applications and websites your business maintains today. If you don’t know what needs to be protected, you obviously can’t protect it. The discovery and ‘baselining’ of all IT systems and processes is critical to any cybersecurity program. The same holds true for client-side security programs. Start by enumerating all of your websites, individual webpages, web applications, and other web assets. Inventory your client-side attack surface from soup to nuts.
Data Discovery
Key action: Discover client-side architectural elements and the data they use.
Look at all of your web assets from the hacker’s perspective. Seriously, do what the bad guys might do to your websites and web applications. The first step in the Lockheed Martin Kill Chain is reconnaissance. The first thing hackers do is look at your websites and web applications like your customers would. Then they start to investigate your scripts. Next they start to figure out your weaknesses. So, just like a hacker, you need to answer the following questions:
- What data is being exchanged via client-side assets?
- What sensitive data do my websites and web applications collect?
- What sensitive data might be exposed inadvertently?
- What application elements are touching our data (i.e., scripts and libraries)?
- What third- or fourth-party elements have access to data that is being exchanged on the client-side?
- Where is the sensitive data we collect going and do we have control over it?
Script Management
Key Action: Catalog all scripts on your web assets and the data accessible by these scripts. Quarantine zombie scripts immediately.
Next you need to determine what scripts have access to sensitive data. Follow the Zero Trust model on your client-side just like you do on the server-side. If the script doesn’t need to have access to data, don’t let it have access to data. Simple as that. Moreover, if your web assets are running scripts that are not actually being used, a.k.a. ‘zombie scripts’, then ask yourself if these scripts really need to have access to your data? When a script becomes a ‘zombie,’ it should immediately be quarantined. Hackers love zombie scripts. They are the easiest backdoors to exploit. If a hacker is currently evaluating your business as a target and they find a zombie script, they’ll start rubbing their hands together and say: “Hmmm… my target is not using this script and it has access to sensitive data? Gold mine! They’ll never know I was using it to steal their customer data!”
You have to have a full inventory of all the scripts running on your web assets and know what their access to data might look like. To properly evaluate your web assets and the scripts that built them, you will have to do static code analysis, dynamic code scanning, and manual review of front-end code. It’s the only way you will be able to keep hackers at bay. No two scripts are the same, so while conducting code analysis and review, please keep in mind that it is difficult to:
- Find all zombie scripts. You will have to hunt for them on a regular basis.
- Gain total visibility into which scripts are or are not in use.
- Establish visibility into security control and configuration variations.
- Block all access to sensitive data on the client side.
Change Tracking
Key Action: Continuously analyze your web assets for code changes, and deploy applicable security measures.
Here is where client-side security becomes extremely tedious and time consuming. Today, many websites and web applications aren’t built by a team of developers line by line. They are assembled like a sophisticated jigsaw puzzle. Chunks of pre-written code with varying functionality, built by multiple developers with varying capabilities, are pieced together to create the final product. Modern web applications load an average of over 20 third- and fourth-party scripts as part of the user experience.
If your web assets are assembled using third- or fourth-party scripts, then you can be sure that the scripts are changing all the time. Staying on top of this change and ensuring continuous client-side security is a full time job. Security teams often lose the client-side security battle on account of how applications are developed and enhanced overtime. On top of that, front-end code changes for every user session. So, how can someone review all of those code and script changes and keep track of zombie scripts, benign scripts, vulnerabilities & exploits, and data exposure?
For now most organizations deploy quarterly penetration tests (pentest) and vulnerability assessments to stay on top of their client-side code security. However, these tests and assessments are snapshots in time. Application developers move much, much faster than that and businesses leave their client-side attack surface wide open to breaches for extended periods of time.
There is a Better Way: Automation, Orchestration, and Communication
Our customers come to us bamboozled by the client-side security problem. They struggle to stay on top of all their client-side code to ensure it is secure. The biggest challenge they face is staying ahead of the threat. Quarterly pentests and vulnerability assessments just aren’t enough. Code changes too quickly for one single person to review in real-time. Let’s be real here, I haven’t met a person who can analyze millions of script changes at machine speed. If you know someone that is able to do this, send them my way, I’d like to hire them.
However, with the rise of machine learning technology, machines can learn to track, spot, and report anomalous behaviors better than any human can. With the right technology in place, a human can be armed with client-side security intelligence to keep track of code changes, malicious scripts, and abnormal code behaviors.
Time for my shameless pitch, Feroot Security technologies are able to analyze client-side applications, web browsers, and other front-end technologies in real time. Our technologies continuously scan web assets to detect anomalous behavior, and then provide crystallized insights and contextual details to security analysts to quickly take corrective action. Feroot products collect client-side telemetry and cyber threat intelligence that help security teams take corrective action and mitigate cyber attacks on web applications and browsers.
Yep, you are right. The client-side attack surface is unique and requires its own security program to reduce risk. Alas, client-side applications and assets are often overlooked or completely missed by traditional application vulnerability and pentesting methods.
Hopefully you were able to learn some best practices to start building your client-side security program. We hope that you can use our guidance to start protecting the client-side of your business and your most critical assets: your customers and their data.
If you would like to see how our products can automate the majority of the issues you will run into while building your client-side security program, request a demo here.