CyberKsen Blog

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

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

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

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

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

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

The goal here is to leverage Jira flexibility to augment the representation not only of software "bugs" but to put in place a coherent and consistent representation of vulnerability and risk management. This big goal can be divided into a more detailed description: Defined top down and used bottom-up: single vulnerability and threats contribute con the organization's risk quantification, also directly from the technical source of truth, the engineers developing and maintaining the software system itself. Integrated with Threat Modeling, Penetration testing, development cycle(s), incident management... in a native/common manner. Non disrupting the common use of Jira by dev teams (standard schema). This would produce a push-back by most teams to the change proposal... Jira is for many companies the tool of choice for development, whether they use "agile" methodologies or a "waterfall" approach. It is always more used in bigger organization for

Keeping in mind the big picture of the Threat Modeling flow, there are obviously many ways to identify the vulnerabilities a specific design may presents. Among them:  Attack Trees,  PASTA ,  STRIDE CIA ... and others Considering the "practical" nature of this article series I'm going to focus on those more (de facto) standard methodologies: STRIDE and CIA. Having a taxonomy helps to consider a wider and more complete range of potential threats. Not basing a TM on a taxonomy lead to a higher probability of "missing" something when conducting the TM (we'll that considering ONLY the taxonomy, limiting lateral thinking will lead to potentially "missing" something else). Personally, I prefer STRIDE over CIA taxonomy as it helps to find more potential vulnerabilities. For people approaching for the first time TM, although, CIA results in an easier understanding of the main concepts, and hot to map assets (and dataflows) to threats. S

Or horribly wrong... Creating a software system is also an act of creativity and imagination. Somehow you need to be creative in forecasting what can go wrong in the system being built. We already talked about the adversarial mindset. Adam Shostak emphasizes this approach. Having always in mind the question "What can go wrong?" is necessary to make sense of the threat modeling in the first place. Based on experience I can say that TM quickly becomes a procedural activity in dev teams and lose the sight of the big picture. "TM is making the matrix of CIA or STRIDE on the assets", once done it, they feel relief that TM is sone and they can go on, or similar interpretations tend to lose the main point TM goal is not compliance, is making systems more secure and communicate better the risks with stakeholders. TM is understanding, better at an early stage, what can go wrong, then decide what you do about it. Put this in practice, one of the first push backs on th

Adversarial mindset is key to design and to implement more secure software and systems in general. Of course, is not the only requirement to achieve better security. Experience and traversal technical knowledge is key too. The question is also: how to ensure we applied an adversarial mindset in software design and creation? and: How can we assess that that reasoning was complete or at least enough? Threat Modeling is a practice that tries to address those questions: providing both frameworks and methodologies. Hoping in the competence of single engineers is not enough. Complex systems don't fit in the head on any one single individual. Having the best individuals, also with an adversarial mindset and cyber security knowledge/experience is a rarity and, even in that case, you need a defined practice to guide the activity of Threat Modeling. We're not in the early 2000s and we are lucky enough to "stand on the shoulders" of great individuals that developed several

In my career, I've taken before and then gave, secure coding training to developers. I consider the developers one of the most intelligent categories...yes they can code :) Still, when it came to secure coding training it is very difficult to maintain attention. Usually, the training is structured on one, two or three full 8 hours days. It is perfectly normal, after just a couple of hours (if you are strong) to experience attention difficulties, basically falling asleep. The request initially came from a big south-east Asian Bank. They wanted to organize a security hackathon for developers. That's what I did in collaboration with Maya7 security consultancy . For two months I created a custom made basic banking application, structured with their same languages and frameworks. Then during 2 days and one night, a series ex "missions" were assigned to the participant teams. Those "missions" or "tasks" were, of course, about implementing security fea