Presentation - "Surrogate dependencies (poc in node js) v1.0"

Here is the second part of the presentation I delivered at the OWASP London Chapter event (29 Sep 2016)

Presentation "NodeJS security - still unsafe at most speeds - v1.0"

Here is the first part of the presentation I delivered at the OWASP London Chapter event (29 Sep 2016)

Threat Model Community

(from Software Quality book)

There is currently (late 2016) space within the application security world to develop a community focused on Threat Modeling. Such community would allow the many parties working on Threat Modeling to share information and provide a voice to all different stakeholders.

The business model of selling a fork

(from Software Security Book)

An open source based business model that I really like, is the idea that the company (or team) behind a particular open source project, sells a fork of the master repository, that is customised and/or maintained for a particular customer.

What that means is the customer buys access to a fork, from the authors of that particular code/repo/project.

That way the company developing the application has a direct connection with the client, and a regular revenue stream.

AppSec should buy tools for developers

(from Software Quality book)

This is a great opportunity to generate goodwill and positive working relationships with developers. If the AppSec team is able to actually find the budget for tools, it will help developers be more productive.

Two great examples are WallabyJS for javascript and NCrunch for .Net

Inside a large organization, you will find teams where for some reason or another, management hasn’t seen as a priority to invest in tools for developers.

Developers need data classification

(from Software Security Book)

Every type of data that exists in an organisation, especially the data that is consumed by applications, needs to have a Data Classification mapping.

Developers need to know if a particular piece of data is sensitive, and what value it holds for the business.

A good way to determine the expected level of confidentiality and integrity, is to ask what would happen 'If a particular set of data were to be fully disclosed?' (for example uploaded to PasteBin) or 'If some of the data was being maliciously modified over a period of months?'.

I Abuse the term ‘Unit Test’

(from Software Security Book)

For me a Unit Test is a test of an 'unit’. The only question is how big is that 'unit’.

If you go to Wikipedia page for List of Unit Testing Frameworks you will see a large list of ‘unit test’ frameworks which range from traditional ‘unit tests’ (on individual function or procedure) all the way to:

• integration tests,
• production tests,
• e2e tests (end-to-end)
• performance tests
• smoke tests, etc…
• (i.e. every-type of automate-able test).

For me, if you can run it with a unit test framework, then it is a unit test.

Putting Data in PasteBin

(from Software Quality book)

One of the best ways to make Developers, Architects and Managers understand confidentiality of data hosted by their application, is to ask the question, 'Can we put all of the data on your database on PasteBin?' [^PasteBin]

That question makes all parties involved really think about what that database contains.

Ideally, the correct answer is yes, there is no problem. All that data could go to pastebin because the data shouldn't mean anything by itself.

Graduates to manage JIRA

(from Software Quality Book)

One of the challenges of the JIRA RISK workflow is managing and maintaining the opened issues. This can be a considerable amount of work, especially when there are 200 or more issues.

Note that, in large organizations, the number of risks opened and managed should be above 500, which is not a lot, and in fact, is the level when visibility into existing risks really starts to happen.

The solution isn't to have less issues.

Describe Risks as Features rather than as Wishes

(from Software Quality Book)

When opening up a risk JIRA ticket, it is key to describe the exact behavior of that issue as a feature, versus how you would like to see happening (i.e your wish list).

For example:

• instead of saying 'application should encode XYZ value', you should say that 'XYZ value is not encoded'
• don't say an 'application shouldn't be vulnerable to XSS or SQL injection', you say ' application is vulnerable to SQL injection'. In this case SQL Injection is a feature of the application, and while the application allows SQL Injection, the application is working as designed (whether that is intended or not, that is a different story :) )

Know what was not tested

(from Software Quality Book)

When you're reading an application security report (like a pentest), one of the most important questions that you should get an answer to is 'What tests did they run?'. This is especially important for the tests (i.e. exploits) they tried to run but were unsuccessful.

The report(s) will show what was successful, but that's only half (or potentially less than half) of what you want to know.

Broken Tests Aren't The Problem

(from Software Quality Book)

It is quite worrying how many times you hear complains about test's execution (for example their speed or how hard they are to maintain)

These complains can be so strong, that they can even question if the tests are 'worth it'? (i.e. the negative sides of maintaining the tests are higher than its benefits)

This is very dangerous because it is promoting the idea that it is OK not to test your code. And that is just crazy!

"Turning TDD upside down - For bugs, always start with a passing test" - v0.5 Sep 2016

Here is the presentation I delivered at LSCC (London Software Craftsmanship Community) on the 22nd Sep 2016

Title: Turning TDD upside down - For bugs, always start with a passing test
Description: Common workflow on TDD is to write failed tests. The problem with this approach is that it only works for a very specific scenario (when fixing bugs). This presentation will present a different workflow which will make the coding and testing of those tests much easier, faster, simpler, secure and thorough'

Start with passing tests (tdd for bugs) v0.5 (22 sep 2016) from Dinis Cruz