Forem: Lau

The logic of Value

Lau — Mon, 24 Mar 2025 20:38:27 +0000

Not all threats matters equally, and not all vulnerabilities hold the same relevance, unless analyzed through the lens of the attacker’s profile.

Adversary profiling allows us to optimize defense in multiple areas. But before profiling attackers, it’s essential to understand how attractive our business is to them. I call this: the logic of Value.

Defending like an Adversary Attacks

The logic of Value puts us ahead of our adversaries from the very beginning, allowing us to distinguish between seemingly similar likelihoods, reveal a hidden relevance, and uncover a hierarchy within the attack surface that would otherwise remain invisible.

By introducing this logic, we move beyond evaluating threats along a single axis. Instead, we shift to a multidimensional model—one that connects likelihood with attacker intent, business sensitivity, and operational impact.

Understanding our organization from both the attacker's and defender's perspective, guided by the potential financial gain the company represents, and securing our resources arranged in layers of priority. It reflects a holistic conception guided by the reason behind the attraction.

Additionally, the type of business, industry, and sector are key factors in inferring what skills and tools attackers may have, what techniques they typically use, and which assets or processes they aim to compromise.

In this way, if we take a lateral approach, we can think of the company’s characteristics as defining the threat, its level of sophistication, and the techniques, tactics and procedures used.

Every organization has a unique combination of data, systems, and processes that may attract different types of attackers. Without this understanding, we might fail to recognize the exploitation paths into our business—whether for one goal or another. We may overlook our hotspots, fail or delay to apply security controls that protect our most critical assets.

Scenarios

Each company operates within a context that defines its exposure to attacks. A financial institution with millions of customer records will be a very different target than a startup developing software.

The first thing we must understand is which elements of the organization represent real value to attackers. It’s not just about digital assets but the business logic of the company within its industry, the data it handles, and the relationships it maintains with other entities. For example, a company that provides essential services may be a high-value target for actors seeking to disrupt a supply chain.

Although not every company holds strategic information or financially valuable data, every company has something to protect: its reputation. In many cases, the true impact of a cyberattack doesn't stem from the direct loss of data or money but from the consequences it generates in market perception, customer trust, and the legal implications of a data breach.

For an attacker, there is no need to sell the data on the black market: it’s enough to threaten publication to extort payment.

For this reason, the cyberattack in such a scenario is fleeting—the true objective is reputation—and the technique used to extract economic return is extortion. Reputational damage can translate into millions in losses due to consumer distrust or a drop in the company’s market value. In this sense, the security breach is just the lever, and at the same time, the pressure point and bargaining chip is the company itself.

Shifting the angle of observation

When it comes to defense, having priorities is as important as moving away from the fiction of imaginary enemies and theoretical attacks to focus on real threats. By using the logic of value, we can make those threats tangible and predictable.

We can introduce a parallel dimension to threat prioritization—one that sees business logic as a predictor of attack patterns. Abraham Wald arrived at a similar kind of insight through the concept of survivorship bias, where strategic understanding emerged by shifting the angle of observation. There, the key insight came not from what was hit; here, it comes from what we are.

Understanding which attacks will be more probable and frequent—which are likely to occur sooner than others, what areas of our surface will be more actively targeted, which threats will be more common, how these attacks might evolve or chain together, and how our own systems may be exploited—given our systems, processes, and market position, allows us to stay one step ahead in defending our infrastructure. That lead can be translated into time—and that time can be used to deepen our defenses against advanced and other threats.

Through this approach, we gain a view that encompasses the full range of potential threats, while operating with a customized model tailored to the unique needs of our organization. It strengthens our specific weaknesses, adds real threat awareness, and the path itself leads to a more efficient use of time—allowing us to turn that time into strategic advantage, defend more effectively, and stay ahead of our adversaries while keeping our systems secure.

Why not underestimate the 'loose ends': Bridging Web Development with Cybersecurity

Lau — Wed, 25 Sep 2024 20:19:17 +0000

We often see meaningful data when we work on web development, like credentials as key-value pairs of username and password, secrets, and authorization tokens carrying a unique alphanumeric combination that allows us to access private information or restricted services.

Probably, this might explain why many developers tend to overlook 'loose ends' or information that doesn’t appear dangerous. In other words, developers might unintentionally ignore small details or risks because they don't seem significant at first glance.

Additionally, since cybersecurity decisions are often based on potential impact, anything not immediately seen as impactful might not be considered a potential risk for system exploitation.

The risk of 'loose ends'

For example, what would you think if you see the word 'Daniel' appearing in comments in the codebase? Nothing, right? It might be perceived as non-dangerous information, but I would like you to consider this: What would happen if 'Daniel' is the word corresponding to a username with access through SSH.

Then, maybe 'Daniel' is a 'loose end' in our codebase revealing a valid SSH username, and this piece of information could lead to our system exploitation.

The risk of defaults

The risk with defaults often involves both predictability and disclosure, which allows attackers to quickly plan exploitation strategies. Default settings are often well-known, which can make it easier for attackers to exploit them for unauthorized access or data exposure.

Default configurations can expose predictable endpoints that attackers can exploit to gain insights into the system or find weaknesses, reach resources, or reveal sensitive information that can be used to compromise the system further.

Defaults can expose predictable endpoints or paths that attackers might exploit to gather information about the system, find weaknesses, reach sensitive resources, discover vulnerabilities, or reveal sensitive information that can be used to compromise the system.

For example, consider an attack simulation on a Windows system with SSH enabled. If the system has default configurations, there might be predictable elements that attackers can exploit. For instance, if user credentials are stored in default or known locations, attackers might target paths such as C:\Users\[user]\.ssh\id_rsa, where sensitive files like SSH keys could be found.

Consider the case of 'Daniel', a valid SSH username. If the credentials are stored in the default path as C:\Users\[user]\.ssh\id_rsa, and an attacker knows 'Daniel' is a legitimate user, they could exploit this information. If there's a vulnerability in the web platform, it might allow the attacker to exfiltrate the id_rsa file and potentially gain access to the system through SSH.

Conclusion

Risk management isn’t just about assessing the impact after something happens, it’s also about proactively preventing risks from emerging. This underscores the importance of preventing the exposure of system information, no matter how harmless it may seem.

Security Awareness, Secure Coding, and Zero-Trust - Bridging Frontend and Cybersecurity

Lau — Tue, 02 Apr 2024 17:49:18 +0000

What is "Security Awareness"

Security awareness is about the knowledge and attitude of team members about protecting the company assets or software.

Let's talk about the attitude (letting OWASP Top Ten for the knowledge for now since defects, bugs, and logic flaws are consistently the primary cause of commonly exploited software vulnerabilities).

What is "Secure Coding"

So, we can think that code review, code style guides, well-maintained, well-structured, and tested code is on the very basis. Then, following these practices (along with others, like implementing code analysis e.g. Snyk, Semgrep, etc.) might let us assume certain feelings about the code being secure.

Building secure software requires more than this, let me remark that, It also requires a basic understanding of security principles and practices, insecure patterns, and the language, technologies, third-parties, and aspects upon which the frontend relies on along its development.

What is "Zero Trust"

But the attitude (along with training) plays a relevant and not prescindible role. And our key to attitude is not to trust. And this is why:

The approach developers follow differs from the one attackers walk down.

A development team designs an application to perform specific tasks based on functional requirements and use cases.
Meaning a Dev team approaches an application based on what it is intended to do.

Conversely, attackers primarily think that "any action not specifically denied, could be allowed". Having more interest in the unintended or unexpected behavior than the expected use case results.

Not trusting that the code will always be used as expected is the basis and first layer of defense in our attitude. Even in terms of verification, limiting the impact, and properly handling a response. In this context, It's what we can call a Frontend Devs Zero-Trust.

Conclusion

Let's summarize:

What is "Security Awareness"? attitude and training.
What is "Secure Coding"? principles and practices.
What is "Zero Trust"? Not trusting that the code will always be used as expected is the basis and first layer of defense in our attitude.

Resources

Fron-End:
- OWASP Foundation: https://owasp.org/www-project-top-ten/
Back-End:
- OWASP Foundation: https://cheatsheetseries.owasp.org/cheatsheets/Nodejs_Security_Cheat_Sheet.html
- Security Best Practices: https://nodejs.org/en/docs/guides/security
AWS Vulnerabilities already found:
- CVE AWS: https://www.cvedetails.com/vulnerability-list/vendor_id-12126/Amazon.html

Application Security - Bridging Frontend and Cybersecurity: How do we identify what to protect by teams or companies?

Lau — Tue, 02 Apr 2024 17:15:21 +0000

We addressed the question "What is application security?". Now let's address the question "How can teams and companies identify what to protect?", bridging frontend domains and cybersecurity concepts, serving as a practical continuation of security awareness in web applications.

The main purpose is not to precisely or exhaustively define any term but rather to bridge both knowledge shores to build a solid and iterative foundation enabling conceptual tools for a deeper immersion for those who desire it.

How do we identify what to protect by teams or companies

The more we know the web application, the better we can identify the entry points that an attacker sees as the surfaces to attack. Identifying which assets are most vulnerable, and which are most likely to suffer data breaches, information disclosures, or unauthorized access, helps to build the structured representation of the application from the cybersecurity point of view.

Attacker's actions often go from the binary substitution of boolean values like false by true to advanced techniques for chaining vulnerabilities, errors, or behaviors to break into companies, clouds, or networks, steal sensitive data, or blockage the whole company via ransomware. Identifying the pain points allows us to understand and communicate the actual threats we expect and the mitigations we can achieve to protect our company and the software we build.

This structured representation of threats or threats model, identifies potential security risks, enabling proactive measures to protect our digital assets. Conducting comprehensive threat modeling teams can determine the complete attack surface of its components and the interconnected data accesses.

What is Threat Modeling

Threat modeling identifies potential security risks capturing, organizing, and analyzing the web application producing a prioritized list of security and privacy measures, requirements, and implementations for the web application.

Threat Modeling Manifesto

The Cost

Performing threat modeling will be cheaper than remediation costs, let's see why.

Have you heard about PlayStation, Uber, or Yahoo? They have in common a very very expensive characteristic: They all have suffered cyber attacks that cost Hundreds of Millions of dollars. Other companies like Youbit (south Korean crypto exchange) went into bankruptcy after being breached, and 60% of small businesses closed within six months after the breach.

Most Critical Security Risks to Web Applications

Every risk differs from each other by frequency of occurrence, severity, magnitude of potential impact, etc. In this way, we can define a landscape of web application security awareness, explore and include well-known vulnerabilities and mitigations, attacks and defenses, exploitations and practices, to minimize the presence of well-known risks in our web application.

In the Web Application Security field, the OWASP Foundation has maintained a widely agreed list of the Top 10 most critical security risks for Web Applications.

OWASP Top Ten

OWASP standards help companies and developers adopt processes and increase security awareness toward minimizing risks enabling code improvements. In the top ten, we can find Injections like SQL/NoSQL attacks, Outdated or Vulnerable Components, and Security Logging and Monitoring Failures among many others.

Conclusion

Looking through the eyes of the attacker helps to create a defensive analysis, tackling well-known techniques and attacks early, enabling us to build the big-picture map of threats and attack surfaces from our services and web applications.

Working together as one team, we can conduct a comprehensive analysis to construct a holistic fortress that proactively approaches security, empowering frontend software and safeguarding our systems, endowing them with resilience.

Application Security - Bridging Frontend and Cybersecurity: What is Application Security?

Lau — Tue, 02 Apr 2024 17:09:08 +0000

Let's address the question "What is application security, and how can teams and companies identify what to protect?", bridging frontend domains and cybersecurity concepts, serving as a practical continuation of security awareness in web applications.

I'll split the content into two parts, presenting here "What is application security", and "How can teams and companies identify what to protect" in the following part.

What is Application Security

Application security is about taking steps to ensure that the software we're building and deploying is protected from dangers.

It involves taking actions and procedures throughout the application life cycle to ensure and prevent malicious actors from accessing data.

In simple terms, It is like having smoke detectors to alert us of vulnerabilities or issues found within our code, helping to identify and implement measures to ensure the security of the application.

Likelihood of Vulnerability in Key Areas of Web Applications Development Prone to Exploitation

Vulnerabilities in code can exist for different reasons:

Legacy code or lack of maintenance.
Evolution of code can introduce new vulnerabilities due to various factors such as changes in functionality, integration of third-party components, or unintentional oversight security considerations during development.
Supply chain vulnerabilities and risks associated with dependencies in the NPM ecosystem.
Insecure patterns in components.
Lack of API governance relying on the network's security.
Not considering an "attacker perspective" disrupting the subsequent "defender analysis".
etc.

Scanning the codebase

Scanning tools help to secure the application landscape by analyzing and detecting threats from a crossed and multilateral perspective: reinforcing best security practices, analyzing dependencies for vulnerabilities or malicious code (supply chain attacks example), and highlighting security flaws, among others.

Static scanners analyze files (the codebase) to highlight mostly insecure implementations or patterns.
- Early occurrence in the Software Development Life Cycle. Kind of A priori deployment (analysis of the application before running).

Static Application Security Testing Tools Overview

In a rush, I analyzed ten SAST tools based on two keys: readiness (how quickly they could be downloaded, installed & used) and usability (how easily the selected tool could be used). The analysis was not exhaustive and the tools were:

Checkmarx - https://checkmarx.com
Contrast Scan - https://contrastsecurity.com/contrast-scan
Coverity Scan - https://synopsys.com/software-integrity/security-testing/static-analysis-sast.html
Fortify Static Code Analyzer - https://microfocus.com/en-us/cyberres/application-security/static-code-analyzer
HCL AppScan - https://hcltechsw.com/appscan/offerings/source
Kiuwan Code Security - https://kiuwan.com
Reshift (NodeJs) - https://reshiftsecurity.com
SonarQube - https://sonarqube.org/features/security/
Semgrep - https://semgrep.dev
Snyk - https://snyk.io/product/snyk-code/

All of them have in common that they are free and support Javascript, in the end, Snyk and Semgrep were both those with the higher readiness and usability: I started using them with a few clicks, easy to use CLI, both had a clean and useful dependency analysis results and code analysis.

In contrast, most of the other tools required users to "book for a demo", delaying access to the tool and relegating the experience from immediate to later, or were not sufficiently simple to use when considering the learning curve over time, or forced third-party authentication, which I declined to proceed considering sharing my profile as a way of opening an unintended risk vector for my company.

In no way is my opinion based on their quality, effectiveness, or efficiency, and it is not my intention to not recommend any of them, as I have not tried them.

The code to test should be according to the task of highlighting security flaws, so the target software was the well-known "Very Insecure Web Application" called Juice Shop.

Benefits

Requiring no app execution, the scan is faster as testing suites.
Applies all the rules to the whole codebase.
Indicates problematic code locations and explains the issue found making flaws simpler to understand and remediate.

Limitations

False positives and false negatives.
Language specificity

Examples

Semgrep

Snyk