The Root-Cause Solution Approach

July 5, 2020

The Client-Side Universe

Client-side application security is its own universe. It is its own world. In most cases it requires an awful lot of manual work to ensure application security in this space. The client-side web browser front-end is a more different attack surface than the other web application interfaces. Just like in optimized application security, client-side security requires a completely new point of view, approach, and skills. For many, these concepts are not yet well understood. Let’s explore what components of a client-side security program that will help reduce potential “backdoor” risk.

What a Thorough Root-Cause Approach Must Do

  • The approach should look for the root cause by breaking down a big problem into smaller pieces and apply a risk management framework. Many GRC frameworks can help with this. By leveraging risk management frameworks, you can be confident that your approach is structured, measured, and complete. Some of the most popular frameworks to consider implementing are OWASP. CIS, NIST, MITRE ATT&CK. A framework is like a brick wall vs. a pile of bricks. The benefit of a framework is that you know if something is missing.

Security start with visibilty

  1. What assets do you have?
  2. Who has access to those assets?
  3. What is being done to these assets?
  4. What controls and protections are in place?
  5. Are controls effective and non-tampered with?

Feroot creates a sustainable security program operation with a continuous scanning and real-time protection and monitoring of the client-side (front end) surface area that is proactive, autonomous, and accurate

  1. A thoroughly optimized method implies looking for the root cause or reason behind the a given problem, not just the surface or the symptom of the problem. For example, if a patient is having chest pain, a non-root cause approach would be to provide some painkiller medications. Could it be a lung problem or even a heart disorder? The root cause method would be to find what is really causing the chest pain and remediate any associated critical issues.
  2. The approach should be flexible, platform-agnostic and business-friendly.
  3. The approach should be continuous and comprehensive to make it effective, efficient, and to help prevent future mistakes and missed vulnerabilities.

Now let’s move from a higher level to the concrete building blocks in the context of web security.

What Use-Cases Are Required?

Because the client-side code dynamically changes for each user session, client-side vulnerability inspection must include all JavaScript code loaded by the browser during user journeys. This includes code loaded by the first party web application servers as well as any code loaded from external third-party sources. Considering all elements of the client-side browser code will enable you to determine the security posture of the client-side and obtain a comprehensive list of vulnerabilities in this environment. An excellent methodology to tackle front-end security problems should consider these use-cases:

  1. Vulnerability Management - Penetration tests and security vulnerability assessments help diagnose immediately addressable vulnerability issues. Unlike penetration tests, however, additional scrutiny should be applied to runtime front-end code. This will help to accurately and precisely discover such vulnerabilities and provide actionable information. 
  2. Content Security Policy (CSP) – Includes the introduction of security controls to enable a business to operate flexibly without hindering business operations or introducing risk.
  3. Web Application Firewall (WAF) – WAF implementation should become part of the operation and embedded into the runtime as well. Unlike a WAF, however, there is also a need to secure the front-end at the browser level and while being platform agnostic.
  4. Secure Software Lifecycle Cycle (SDLC) – The secure SDLC should include tools that monitor and help manage change control over the entire software development lifecycle. Unlike traditional software management tools, however, a critical objective is to also monitor and manage in-house developed Javascript code and third-party code. True regardless if such code is loaded from servers under your control or dynamically loaded from third-party servers.
  5. Third-Party & Supplier Risk Management – The goal is effective management of 3rd party related vendor risk to critical IT and data assets. Unlike the 3rd supplier management systems, potential solutions need to address third-party technologies in real-time and at the browser-level of every user session. Once again, it should do so with no adverse impact on user experience and browser performance.

About authors

Ivan Tsarynny is CEO and co-founder of Feroot Security, Member GDPR Advisory Committee at Standard Council of Canada, and is based in Toronto, Canada.
David Mundhenk, CISSP, CISA, PCI QSA, PCIP, is a Principal Security Consultant for the Herjavec Group, and a founding member of the PCI Dream Team.