Presentation: Building AppSec Teams

Here is the presentation I delivered recently at an online SC Conference on Web Application Security.

This is the consolidation of my recent research (and practical experience) of creating AppSec teams.

I think this structure and focus would make a massive difference (if implemented) at a large number of companies (specially the AppSec Squad concept)

The video is available on demand here

Presentation: Security champions

Here is a presentation I delivered recently to a newly created Security Champions team.

The objective was to present them what are Security Champions, and to motivate them into wanting to become one.

Let me know what you think of it, and if there is anything missing from this initial 'motivational' slide deck

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.

What are Security Champions and what do they do?

Security Champions are a key element of an AppSec team, since they create an cross-functional team focused on Application Security 

Here is an good definition for you to customise to your culture and workflows:

What is an Security Champion?

• Security Champions are active members of a team that may help to make decisions about when to engage the Security Team
• Act as the "voice" of security for the given product or team
• Assist in the triage of security bugs for their team or area

What do they do?

• Actively participate in the AppSec JIRA and WIKI
• Collaborate with other security champions
  • Review impact of 'breaking changes' made in other projects
• Attend weekly meetings
• Are the single point of contact for their assigned team
• Ensure that security is not a blocker on active development or reviews
• Assist in making security decisions for their team
  • Low-Moderate security impact
    • Empowered to make decisions
    • Document decisions made in bugs or wiki
  • High-Critical security impact
    • Work with AppSec team on mitigations strategies
• Help with QA and Testing
  • Write Tests (from Unit Tests to Integration tests)
  • Help with development of CI (Continuous Integration) environments

Further reading

• Does your team has a Security Champion? If not, get this Mug and Library
• Security Champions at Mozila
• Creating a Security Champions Network

Thoughts on Security Authentication and on adding security into an SDL

Here is an (slightly edited) 'brain dump' I just wrote on the topic of Authorisation and SDL.

Let me know what are your views on the ideas presented below:

---------------------------------------------------------------------

The need for a strong Auth strategy

Knowing 'who is talking to whom' is a key pillar of security. Since there is going to be a number of parties and players involved, it will not be possible to have a one-size-fits-all Authentication technology/workflow (specially when dealing with the partner's systems and existing SSO technology).

Does your team has a Security Champion? If not, get this Mug and Library

If your dev team doesn't have an assigned security team champion, get one of these Mugs :)

Basically that 'Security Expert' Mug should represent the fact that at the moment when a developer has an Application Security question, he might as well ask the dude on that Mug for help :)

I also like that it re-enforces the idea, that for most developer teams, just having somebody assigned to application security, is already a massive step forward!!

Secure coding (and Application Security) must be invisible to developers

At OWASP a while back we come up with the idea that '...Our [OWASP] mission is to make application security visible...' and for a while I used to believe in the idea that if only everybody had full visibility into 'Application Security' then we would solve the problem.

But after a while I started to realize that what we need to create for developers, is for 'Application Security' / 'Secure Coding' to be INVISIBLE 99% of the time. It is only the decision makers (namely the buyers) that need visibility into an application secure state

We will never get secure applications at a large scale if we require ALL developers (or even most) to be experts at security domains like Crypo, Authentication, Authorization, Input validation/sanitation, etc...