DevSecOps & friends

Posts

Content-Security-Policy and third party JS, a Threat Model view, PART 1

A lot has been done to defeat XSS and other potential vulnerabilities in nowadays frameworks (contextual encoding in React Angular... etc) and development practices, still, XSS, and in general the ability for an attacker to execute arbitrary code (mostly Javascript) is still in the OWASP TOP 10 and at the root of many cybersecurity incidents. As mobile applications also became a wrap on top of a browser-based web application, the attack surface for XSS and other related malicious code injection widens even more. Given the situation leveraging browser mechanisms to restrict the Javascript code that the client can execute to only the expected one sounds like a great solution. Content-Security-Policy (some of the advanced features) has this potentiality but is mostly unused. I saw two main reasons for this: The advantage is hard to defend: 1) It needs to be fully understood, it needs clear evidence and arguments to justify it (that's why I'm writing this article). 2) It is

STRIDE (enhanced)

Everything can be improved. Here's Geoff 's proposal for improving STRIDE taxonomy, he granted me the permission to publish it; in his words: The STRIDE mnemonic was created to simplify the ability for non-security members to identify areas where software teams commonly made security mistakes. It has covers 6 unique security weakness points. The mnemonic is enhanced by integrating it with the Security Frame, a framework that highlights the 10 most common security patterns that get improperly designed and implemented. The enhanced STRIDE is here: · Spoofing (Authentication) · attempting to gain access to a system by using a false identity · cause - poor authentication of entities · Spoofing (Session handling) · attempting to gain access to a system by using a false identity · cause - poor management of session tokens (key length, key lifetime, key storage) · Tampering (Validation) · unauthorized modification

Practical Threat Modeling series, part 6 - STRIDE vulnerabilities enumeration

We saw in part 3 what STRIDE is, now we are going to apply a two-step process to list the vulnerabilities for the assets in-scope as described in part 5 . Keeping always in mind that the threat model should be useful both to the development team, to perform security analysis and understand what can go wrong, as well as other stakeholders, to document and give awareness of the security status, rationale and risks of the system. For our methodology example, the system is a simple e-commerce website with a database containing products and user.customer identities, the same architecture used previously: Two Step process for listing vulnerabilities Listing all the identified vulnerabilities and their associated mitigations could be a rather complex and long task. As usual, we divide a complex task into smaller, easier steps. My Advice is a two-step process. STEP 1 consists of associating threats in the taxonomy (in our case STRIDE) to assets. The second is to detail the vari

Practical Threat Modeling series, part 5 - Design Level, get the thing done!

The major threat for a threat mode (pls excuse me for the wording game) is to feel lost on the vast "sea" of things that can go wrong, and how to prioritize them. This feeling of vastness, or the opinion that everything needs to go inside the TM, is the first enemy or getting the TM done. So, don't panic and get the thing done...so, where to start? A good place to start is the highest diagram of the architecture of the system itself. It is not something meant to be used to TM but is useful as a starting point for the analysis. You also have limited time, let's focus on the most important things and prioritize them. It is often the case that teams perform threat modeling after the design phase, or when the system is already in production. In this case, this practice could be considered technical debt, and you might find out that already many mitigations and countermeasures are in place to defend against threat agents. In this case, bear in mind that the threat is pre

Practical Threat Modeling series, part 4 - Waterfall Vs Agile

Threat model can be done at different levels of abstraction and in different phases of the SDLC. If the more consolidated techniques are about creating a Threat model in the design phase (before implementation). Nowadays needs are often to integrate TM inside a maintained (production) system that may also have an Agile methodology of development; new features coming in all the time. When we want to approach a design level TM we most likely will use architectural, design, and data flow diagrams (DFD). Security architects and engineers will apply a more rigorous framework (e.g. STRIDE) create a TM document and maintain it. The TM is on a whole application scope. When delivering a single feature (Story or Epic in Agile terminology) we should also apply TM techniques that imply adversarial mindset, delivers mitigations, improve implementation and show documentable security efforts. In this case is advisable to follow a different modus operandi, much lighter, and agile developer or

OWASP based Secure Coding Training

Those are the presentations I used for secure coding training. Feel free to use them, some protocols may be outdated, they are mostly from 2016. The training is for two days of around 6 hours, including discussions and practical sessions. https://drive.google.com/drive/folders/1frn1R2GTmz74DU9GP-RPqCw8yQByY-pE