Survey about Security Champion program

Once you have a Security Champion (SC) program in place, you need to keep track of its effectiveness.

Here (see below) is a survey created by Vinod Anadan designed to learn from the current SCs and make it better

Any other questions we should be asking?

---

The AppSec team would like to conduct a survey about the Security Champion program.

Use AppSec to visualise logs

Once you've got your logs, a typical challenge is how to process, and visualise them.

This usually happens when you try to address visualisation as a whole. But until good filters and multi-stage-analysis are in place, there is just too much data, too much information, and you will be left struggling with the sheer size of the data you are looking at.

The key is to create an environment where we are only querying an subset of the data, with fast queries and REPL like workflow.

One of the ways to manage this is to start with a small AppSec question (ideally codified as a Test).

Is your pentest delivering on AppSec?

Here is how to review a pentest and figure out if it is a network security assessment or an AppSec security review.

When you look at a pen test, you can tell very quickly if it was done by somebody who understands AppSec (somebody who can code), or by somebody who is approaching the problem from an network security point of view (usually running lots of tools).

The first main points to notice are if they asked for the source code, and if they performed an threat model on the target application. If they didn't, then it is most likely going to be a network security assessment.

Who is Paying for AppSec on open code?

When there isn't a commercial company behind an application or library, who is paying for:

• secure development
• secure coding standards,
• threat models,
• security reviews,
• dependency management,
• etc...

One of the interesting questions that arose when we talk about the need for open-source security coding technology, security coding centres, and everything we need to build secure code is: Who pays for it?

No server-site generation of dynamic web content

A very powerful design pattern that can provide a huge amount of security for web applications, is when there is no server-site generation of dynamic web content.

This avoids the pattern of:

• starting with clean data objects on the server
• merging code and data on the server
• sending it over to the client as HTML
• rebuilding it on the browser site for rendering and execution

The way to make this happen is to make all your web pages and content to be downloaded as static resources. This is done from a locked down server, ideally using git as the deploy mechanism. Data is provided to the UI via AJAX requests from dedicated WebServices.

Make sure your Security Champions are given time

It is very important that security champions are given the time, the focus, the mandate and the information required to do their jobs.

The good news is that now that you have security champions (at least one per team), their work will allow you to see the difference between the multiple teams and the parts of a company who are able to make it work, and those who are struggling make it happen.

The currency of AppSec is provability and assurance

(from Software Quality book)

When we (AppSec) make a statement about a particular security issue, it always be clear and unambiguous.

We should never say "This might be a problem", or "That might be exploited". When it comes to problems or weaknesses in AppSec, we have to express ourselves with confidence.

InfoSec (and AppSec) lack of respect for users

(from Software Quality book)

InfoSec (Information Security) tends to have a really bad attitude towards end-users of technology and developers, where they (the users) get blamed for doing 'insecure stuff' and causing 'security incidents'.
This is crazy, it is like health and safety officers complaining that people are 'doing things', so it puts them into danger.

The fundamental logic is that security is there to empower users, not to be a tax or dictatorship.

Do you have an AppSec team?

(from Software Quality book)

Let's be clear. If part of your InfoSec team you don't have a team of highly skilled professionals who understand AppSec (Application Security), who can program better than most of your developers, and who will be totally hireable by your dev team, then you don't have an AppSec team.

The Power of Exploits

(from Software Quality book)

If you work for a company that doesn’t have a strong AppSec team, or a company that has not seen powerful (or public) exploitation of their assets, you need to write some exploits.

Never underestimate the power of a good exploit.

A good exploit will dramatically change the business' and developer's perception of what security actually means to their company.

Get 40 days of consulting services to kick start AppSec

(from Software Quality book)

If you don't have a big list of security issues or need exploits, then one option is to hire a security company for forty to sixty days, and let them review your applications across the technology spectrum, and across the platform.

Capture the success stories of your threat models

(from Software Quality book)

One of the key elements of threat modeling is it's ability to highlight a variety of interesting issues and blind spots, in particular within the architecture of the threat model. One of my favorite moments occurs when the developers and the architects working on a threat model realize something that they hadn't noticed before.

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