CyberKsen Blog

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