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.
The Client-Side Universe
1. 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
What a Thorough Root-Cause Approach Must Do
2. 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.
3. The approach should be flexible, platform-agnostic and business-friendly.
4. 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.
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.
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.
What Use-Cases Are Required?