If you don't have a Security Champion, get a mug

If your developer team doesn't have an assigned security team champion, get one of these mugs.

That 'Security Expert' mug represents the fact that, without a securit champion, when a developer has an application security question, he might as well ask the dude on that mug for help.

I also like the fact that the mug reinforces the idea that for most developer teams, just having somebody assigned to application security is already a massive step forward!!

Basically, we have such a skill shortage in our industry for application security developers that 'if you have a heart-beat you qualify'

What it takes to be a Security Champion

To become a security champion, it is essential that you want to be one.

You need a mandate from the business that will give you at least half a day, if not one full day per week, to learn the role. The business should also provide the means to educate and train you and others who wish to become security champions. Increasing and spreading knowledge will increase awareness and control.

You need to be a programmer, and understand code, because your job is to start looking at your application and understand its security properties. You should also know 'the tools of the trade', and how to implement them, in the most efficient way. Lastly, you must be able to identify useful metrics and instruct on how to obtain them.

(from SecDevOps Risk Workflow book, please provide feedback as an GitHub issue)

If you have a heartbeat, you qualify!

It is important to understand that AppSec skills are not a key requirement to become a security champion. The essential quality is to want to become one.

I can make a good developer, who is interested and dedicated, into a good AppSec specialist in 6 months. If the developer is an expert in AppSec, then he should join the central AppSec team.

(from SecDevOps Risk Workflow book, please provide feedback as an GitHub issue)

Published "SecDevOps Risk Workflow" book (v0.63)

I just published version v0.63 of the SecDevOps Risk Workflow book.

You can get the book (for free) at https://leanpub.com/secdevops (when you become a reader you will get email alerts with every release)

The diff for this version (with v0.60) shows 113 commits, 63 changed files, 667 additions and 185 deletions.

Using Artificial Intelligence for proactive defense

We need AI to understand code and applications. Our code complexity is getting to a level that we need to start to use artificial intelligence capabilities to understand it, and to get a grasp of what is going on, so we can create secure applications that have no unintended side effects.

As AI becomes much more commonplace, we should start to use it more to source code analysis and application analysis. Kevin Kelly has some very interesting analysis on the use of AI, where he discusses the idea that one of the next major revolutions will be where we start adding AI to everything, because the cost of AI will become so low that we will be able to add AI to many devices.

In DevOps Everything is Code

A common gap in DevOps workflows is (ironically) Application Security activities on the code the DevOps team is writing (Secure coding, Static/Dynamic analysis, Threat Models, Security Reviews, Secure Coding Guidelines, Security Champions, Risk Workflows, etc...)

One cause for this gap is the fact that a large number of DevOps teams come from network and infrastructure backgrounds, or network security backgrounds (i.e. traditional InfoSec), rather than from development (i.e. coding).

Do security reviews every sprint

If you have an agile development environment, you need to implement security procedures and security reviews at the end of every sprint. In the period between the sprint finishing and going live, you need to do a push to get a sense of whether the original threats and issues, that were highlighted in the threat model, were done, or exist, in a verifiable way.

This task shouldn't be done by the central AppSec team.

Why SecDevOps

I like SecDevOps because it reinforces the idea that is an extension of DevOps. SecDevOps points to the objective that eventually we want the Sec part to disappear and leave us with DevOps.

Ultimately, we want an environment where 99% of the time, DevOps don't care about security. They program in an environment where they either cannot create security vulnerabilities, or it is hard to create them, or it is easy to detect security issues when they occur.

This doesn't mean you don't need security teams, or AppSec experts. It doesn't mean you don't need a huge amount of work behind the scenes, and a huge amount of technology to create those environments.

Presentation - "SecDevOps Risk Workflow - v0.6", InfoSecWeek, Oct 2016

Slides from presentation delivered at InfoSecWeek in London (Oct 2016) about making developers more productive, embedding security practices into the SDL and ensuring that security risks are accepted and understood.

The focus is on the Dev part of SecDevOps, and on the challenges of creating Security Champions for all DevOps stages.

This presentation is based on the ideas captured on the SecDevOps Risk Workflow book (that I'm currently writing).

Email to owasp-leaders about SecDevOps Risk Workflow Book

Here is the email I just sent to the OWASP-leaders list

SecDevOps Risk Workflow Book (please help with your feedback)

Hi fellow OWASP leaders and friends, over the past 4 years I made the move from 'breaking apps' into becoming a real Developer, an AppSec Trainer and creating multiple AppSec teams (protecting large companies from real attacks and helping developers to write secure code)

To try to capture my experiences, to help a wider audience and to get some feedback, I've been creating a book on leanpub called SecDevOps Risk Workflow which I would really appreciate if you could check it out.

You can get it for free at https://leanpub.com/secdevops 

Annual Reports should contain a section on InfoSec

Annual reports should include sections on InfoSec and AppSec, which should list their respective activities, and provide very detailed information on what is going on.

Most companies have Intel dashboards of vulnerabilities, which measure and map risk within the company. Companies should publish that data, because only when it is visible can you make the market work and reward companies. Obliging companies to publish security data will make them understand the need to invest, and the consequences of the pollution that happens when you have rented projects with crazy deadlines and inadequate resources, but somehow manage to deliver.

5000% code coverage

A big blind spot in development is the idea that 100% code coverage is 'too much'.

100% or 99% code coverage isn't your summit (i.e. destination), 100% is base camp, the beginning of a journey that will allow you to do all sorts of other tests and analysis.

The logic is that you use code coverage as an analysis tool, and as a way to understand what a particular application, method or code path is doing.

Code coverage allows you to answer code related questions in much greater detail.

Run Apps Offline

The ability to run applications offline, i.e. without live dependencies of QA servers, or even live servers, is critical in the development process. That capability allows the developers to code at enormous speed, because usually the big delays and expensive calls are to those services that allow all sorts of versioning, and all sorts of development techniques to occur. The ability to run your apps offline also signifies that the application development environment has matured to a level where you now have, or have created, mocked versions of your dependencies.

Ideally, the faster you can run the dependencies, even running them as real code, the better. The important thing is to be sure you are running them locally, without a network connection, and without an umbilical code to another system.

Abusing the concept of RISK

As you read [the SecDevOps] book you will notice liberal references to the concept of RISK, especially when I discuss anything that has security or quality implications.

The reason is I find that RISK is a sufficiently broad concept that can encompass issues of security or quality in a way that makes sense.

I know that there are many, more formal definitions of RISK and all its sub-categories that could be used, but it is most important that in the real world we keep things simple, and avoid a proliferation of unnecessary terms.

Fundamentally, my definition of RISK is based on the concept of 'behaviors' and 'side-effects of code' (whether intentional or not). The key is to map reality and what is possible.

Email is not an Official Communication Medium

Emails are conversations, they are not official communication mediums. In companies, there is a huge amount of information and decisions that is only communicated using emails, namely:

• risks
• to-dos
• non-functional requirements
• re-factoring needs
• post-mortem analysis

This knowledge tends to only exist on an email thread or in the middle of a document. That is not good enough. Email is mostly noise, and once something goes into an email, it is often very difficult to find it again.

Creating Small Tests

When opening issues focused on quality or security best practices (for example, a security assessment or a code review), it's better to keep them as small as possible. Ideally, these issues are placed on a separate bug-tracking project (like the Security RISK one), since they can cause problems for project managers who like to keep their bug count small.

Since this type of information only exists while AppSec developers are looking at code, if the information isn't captured, it will be lost, either forever, or until that bug or issue becomes active. It is very important that you have a place to put all those small issues, examples, and changes.

When Failed Tests are Good

When you make a code change, it is fundamental that every change you make breaks a test, or breaks something. You are testing for that behaviour; you are testing for the particular action that you are changing.

This means you should be happy when you make a change and the test fails, because you can draw confidence from knowing the side effects of the change. If you make a test change in one place and a couple of tests break, and you make another test change in a different place and fifty tests break, you get a far better sense of the impact of the changes that you made.

Security makes you a Better Developer

When you look at the development world from a security angle, you learn very quickly that you need to look deeper than a developer normally does. You need to understand how things occur, how the black magic works, and how things happen 'under the hood'. This makes you a better developer.

Studying in detail allows you to learn in an accelerated way. In a way, your brain does not learn well when it observes behaviour, but not cause. If you are only dealing with behaviour, you don't learn why something is happening, or the root causes of certain choices that were made in the app or the framework.

Chained threat models

When you create threat models per feature or per component, a key element is to start to chain them, i.e. create the connections between them. If you chain them in a sequence you will get a much better understanding of reality. You will be able to identify uber-vulnerabilities, or uber-threats, that are created by paths that exist from threat model, A to threat model B, to threat model C.

For example, I have seen threat models where one will say, "Oh, we get data from that over there. We trust their system, and they are supposed to have DOS protections, and they rate limit their requests".

Code Confidence Index

Most teams don't have confidence in their own code, in the code that they use, in the third parties, or the soup of dependencies that they have on the application. This is a problem, because the less confidence you have in your code, the less likely you are to want to make changes to that code. The more you hesitate to touch it, the slower your changes, your re-factoring, and your securing of the code will be.

To address this issue, we need to find ways to measure the confidence of code, in a kind of Code Confidence Index (COI).

Every Bug is an Opportunity

The power of having a very high degree of code coverage (97%+) is that you have a system where making changes is easy.

The tests are easy to fix, and you don't have an asymmetric code fixing problem, where a small change of code gives you a nightmare of test changes, or vice versa.

Instead, you get a very interesting flow where every bug, every security issue, or every code change is an opportunity to check the validity of your tests. Every time you make a code change, you want the tests to break. In fact you should worry if the tests don't break when you make code changes.

Developers should be able to fire their managers

Many problems developer teams deal with arise from the inverted power structure of their working environment. The idea persists that the person managing the developers is the one who is ultimately in charge, responsible, and accountable.

That idea is wrong, because sometimes the person best-equipped to make the key technological decisions, and the difficult decisions, is the developer, who works hands-on, writing and reading the code to make sure that everything is correct.

A benefit of the 'Accept Risk' workflow, is that it pushes the responsibility to the ones that really matter. I've seen cases when upper-layers of management realise that they are not the ones that should be accepting that particular risk, since they are not the ones deciding on it. In theses cases usualy the decision comes down to the developers, who should use the opportunity to gain a bigger mandate to make the best decisions for the project.

Sometimes, a perverse situation occurs where the managers are no longer coding. They may have been promoted in the past because they used to be great programmers, or for other reasons, but now they are out of touch with programming and they no longer understand how it works.

Developer Teams Need Budgets

Business needs to trust developer teams.

Business needs to trust that developers want to do their best for their projects, and for their company.

If business doesn't learn to trust its developer teams, problems will emerge, productivity will be affected and quality/security will suffer.

A great way to show trust is to give the developer team a budget, and with it the power to spend money on things that will benefit the team.

Published "SecDevOps Risk Workflow" book (v0.60)

I just published version v0.60 of the SecDevOps Risk Workflow book.

You can get the book (for free) at https://leanpub.com/secdevops (when you become a reader you will get email alerts with every release)

The diff for this version (with v0.57) shows 138 changed files, 459 additions and 174 deletions.

Hyperlink everything you do

Whether you are a developer or a security person, it is crucial that you link everything you do, to a location where somebody can just click on a link and hit it. Make sure whatever you do is hyperlinkable.

This means that what you create is scalable, and it can be shared and found easily. It forms part of a workflow that is just about impossible, if you don't hyperlink your material.

An email is a black box, a dump of data which is a wasted opportunity because once an email is sent, it is difficult to find the information again. Yes, it is still possible to create a mess when you start to link things, connect things, and generate all sorts of data, but you are playing a better game. You are on a path that makes it much easier in the medium term for somebody to come in, click on the link, and make sure it is improved. It is a much better model.

Getting Assurance and Trust from Application Security Tests

When you write an application security test, you ask a question. Sometimes the tests you do don't work, but the tests that fail are as important as the tests that succeed. Firstly, they tell you that something isn't there today so you can check it for the future. Secondly, they tell you the coverage of what you do.

These tests must pass, because they confirm that something is impossible. If you do a SQL injection test, in a particular page or field, or if you do an authorization test, and it doesn't work, you must capture that.

If you try something, and a particular vulnerability or exploit isn't working, the fact that it doesn't work is a feature. The fact that it isn't exploitable today is something that you want to keep testing. Your test confirms that you are not vulnerable to that and that is a powerful piece of information.

Presenting "Surrogate dependencies" at London LSCC on 20th of October (Thursday)

Here is the description of this presentation:

Don't mock internal functions and methods, mock external dependencies. How to do that? This presentation will present a framework and practical example of creating Surrogate dependencies (think custom proxies, similar to WireMock). They are based on data collected from Integration tests to create environments where target applications can be executed offline and be subject to advanced security, quality and performance testing. All data is stored natively (JSON, XML) and Git is used for content versioning and simulation.

You can register at https://skillsmatter.com/meetups/8431-lscc-meetup (here is the meetup page)

This is going to be an variation of the Surrogate dependencies presentations delivered last month at the Owasp London Chapter

Published "SecDevOps Risk Workflow" Book (v0.57)

I just published version v0.57 of the (previously called) Jira Risk Workflow book.

You can get the book (for free) at https://leanpub.com/secdevops (when you become a reader you will get email alerts with every release)

As you probably noticed, there was a significant change in this release. The title of the book has been changed to 'SecDevOps Risk Workflow' (see here for the background story)

I hope you will agree that this change will represent better the direction of the book and the content I've been adding to it.

AppSec memo from God

Having an Board level mandate is very important since it sends a strong message of AppSec importance.

The best way to provide a mandate to the existing AppSec team is to send a memo to the entire company, providing a vision for AppSec and re-enforcing its board-level visibility.

Sometimes called the 'Memo from God' the most famous one is Bill Gates 'Trustworthy computing' memo from January 2002 (responsible for making Microsoft turn the corner on AppSec)

Example of what it could look like

Here is a variation of a memo that I wrote for a CTO (in a project where I was leading the AppSec efforts) which contains the key points to make. 

Backlog Pit of Despair

In lots of development teams, especially in agile teams, the backlog has become a huge black hole of issues and features that get thrown into it and disappear. It is a mixed bag of things we might want to do in the future, so we store them in the backlog.

The job of the product backlog is to represent all the ideas that anyone in the application food chain has had about the product, the customer, and the sales team. The fact that these ideas are in the backlog means they aren’t priority tasks, but are still important enough that they are captured. Moving something into the backlog in this way, and identifying it as a future task, is a business decision.

Who is actually making decisions?

One of the interesting situations that occurs when we play the risk acceptance game at large organisations, is how we are able to find out exactly who is making business and technical decisions.

Initially, when a ‘Risk Accepted’ request is made, what tends to happen is that the risk is pushed up the management chain, where each player pushes to their boss to accept risk. After all, what is at stake is who will take responsibility for that risk, and in some cases, who might be fired for it.

Eventually there is a moment when a senior director (or even the CTO) resists accepting the risk and pushes it down. What he is saying at that moment in time, is that the decision to accept that particular risk, has to be made by someone else, who has been delegated (officially or implicitly) that responsibility.

Risk Dashboards and emails

 It is critical that you create a suite of management dashboards that map the existing security metrics and the status of RISK tickets:

• Open, In Progress
• Awaiting Risk Acceptance, Risk Accepted
• Risk Approved, Risk not Approved, Risk Expired
• Allocated for Fix, Fixing, Test Fix
• Fixed

Visualising this data makes it real and creates powerful dashboards. These need to be provided to all players in the software development lifecycle.

Email is not an Official Communication Medium

Emails are conversations, they are not official communication mediums. In companies, there is a huge amount of information and decisions that is only communicated using emails, namely:

• risks,
• to-dos
• non-functional requirements
• re-factoring needs
• post-mortem analysis

This knowledge tends to only exist on an email thread or in a middle of document. That is not good enough. Email is mostly noise, and once something goes into an email, it is often very difficult to find it again.

"JIRA Risk Workflow" Book , alpha version published at Leanpub

To expand the ideas I presented with Using JIRA to manage RISKS,  I decided to create a smallish book focused on how that workflow works. 

A key objective is to document the workflow better and allow to teams to implement it using their own version of JIRA (I have done multiple presentations where one of the follow up questions is "Ok, we like it, now what")

You can get this book from Leanpub (with option to get it for free) at 

https://leanpub.com/jira-risk-workflow

Please take a look and let me know what you think of the structure, font, layout, order, content, voice, idea, etc...

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.