SECURITY CHAMPIONS

This presentation

▸ For developments who are considering becoming Security Champions

▸ Present current model ▸ Explain key concepts, like: ▸ Security Champions activities ▸ Threat Models ▸ JIRA Risk Workflow

▸ Shows how Security Champions integrate and are supported by central AppSec team

Security Champions are a key element of an AppSec team

They create an cross-

functional team focused on Application Security

What is a 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 ▸ Aim to bridge the gap between security and dev teams ▸ Assist in the triage of security bugs for their team or area ▸ Focused on the AppSec part of Security activities: ▸ code, apps, CI, secure coding standards, threat models,

frameworks, code dependencies, QA, testing, fuzzing, dev environments, DevOps, ….

▸ vs traditional Infosec: Networks, Firewalls, Server security, Anti-virus, IDS, Logging, NOC, Policies, end-user security, mobile devices, AD/Ldap management, user provisioning, DevOps, …

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

20% of time allocated to Security Champions activities

▸ To participate successfully in the security of their projects, security champions: ▸ review code ▸ fix code ▸ write tests (improving test infrastructure) ▸ know what is going on ▸ maintain the JIRA tickets ▸ create Threat Models ▸ be involved in the security practices of the teams ▸ … basically be involved in non-functional requirements

▸ These tasks will lead to better code, better project briefs, up-to-date documentation and tests for the application.

▸ Security champions should spend at least one day a week on these activities (20% of their time)

▸ Mandate given by ‘AppSec policy’

Why you should become one

▸ Great opportunity for your career ▸ Learn more ▸ Application Security ▸ Offence techniques (‘how to exploit an OWASP Top 10 vulnerability’) ▸ Defensive techniques (‘how to write secure code’)

▸ code review techniques ▸ Improve your development skills (by looking deeper into the

code and frameworks used, since when doing AppSec reviews and fixes, it is key to understand ‘HOW’ things really work)

▸ Solve hard technological problems in development, testing, visualisation,

▸ Make your application more secure ▸ Meet members from other teams and improve your internal

network

Who qualifies

▸ Three requirements ▸ You are a developer in a team/squad ▸ You are interested about Application Security ▸ You have an heart-beat

▸ Don’t worry about lack of security skills (you will learn) ▸ If your team doesn’t have a Security Champion, get a Mug ▸ Since it usually will be him, or Stack Overflow (or internal AppSec

Wiki)

▸ Just having somebody assigned to application security, is already a massive step forward!!

Training Security Champions

▸ Training is key to improve SC skills ▸ Best training is done on top of languages and frameworks

used ▸ Wiki pages with links to actual issues and relevant resources

make a massive difference ▸ Using vulnerable by design apps (or older versions of

current main apps with known vulnerabilities) are a great way to learn (by exploiting them)

▸ Writing exploits and finding vulnerabilities is a key step of the required accelerated learning curve

What it takes to be a Security Champion

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

▸ 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.

Weekly meetings▸ Should happen every week, but a good compromise is for them to occur

every other week ▸ Everything shown and discussed at the Security Champions meeting needs

to be done via one or more slides (to be added to that week's slide deck) ▸ Some examples of what to present at these meetings: ▸ Latest news on AppSec (DDos, exploits, etc..) ▸ Latest bug-bounty findings and payments (a really good source of real-world

examples) ▸ Issues found and issues fixed (on the SC's application or service) ▸ Secure coding techniques ▸ Security tools and technologies (e.g. OWASP ZAP Project, OWASP dependency

checker) ▸ Tools/techniques to improve the Developer's Productivity (e.g. WallabyJS, NCrunch) ▸ Hack challenges ▸ Security reviews current in place ▸ Other OWASP tools and documents (ASVS, OwaspSAMM, AppSensor, Testing

Guide) ▸ Testing techniques, workflows and technologies used (which might be different from

the current development stack)

Threat Models

▸ Dataflow Diagrams (Dft) + STRIDE = Threat Model

▸ Threat Models as better briefs ▸ Performed by layers or features ▸ connected/chained to relevant Threat Models

▸ Threat Models map to Risks ▸ Pentest confirms Threat Model

Threat Models - Start on paper

JIRA Risk workflow

▸ Key to entire system/workflow is this workflow

Security Hackathons

▸ Security champions is need to provide evidence for the tickets they open or manage

▸ And a good exercise for example for hackathons or for get togethers is actually come to the table. So for the security champions to come to the table and say, "hey, I think there is a problem, I think there is an issue can we prove it?" ▸ Security Champions should organize the hackathons, as

hackathons are the next level of SCs applications. SCs can use them to find issues and learn new features.

▸ They should be held every Friday or Monday afternoon, preferably with some drinks and pizza.

▸ Ideally, a hackathon would happen every week, but if not it should be held every two, three, or four weeks. The important thing is to have movement.

Central AppSec Team

▸ Services provided (to teams/squads) ▸ External Pen-Tests ▸ Code Reviews (internal and external) ▸ Threat Modeling ▸ Static and Dynamic scanning of code ▸ AppSec Training ▸ AppSec Advisory Surgery

▸ Functions/Activites ▸ Support Security Champions Network ▸ Manage AppSec Risk Workflow ▸ Maintain AppSec knowledge base (Confluence based)

▸ Own AppSec Policy ▸ Own Secure Coding Standards (based on JIRA Risk issues and OWASP ASVS) ▸ Own SDL (Secure Development Lifecycle) programme

▸ Manage Internal and External Bug-Bounty management ▸ Maintain Maturity Models mapping (based on OwaspSAMM) ▸ Provide Application Registry and Attack Surface mapping ▸ Create Visualisations of existing architecture/code and Business reporting of

existing risks

AppSec driven projects (Security Champions to be involved in)

▸ Map Attack Surface tool ▸ Web Services Visualisation tool ▸ Standard Schemas and validation across the company ▸ Application Registration (and app-to-app connections) ▸ Security focused (unit/integration) tests ▸ Performance and DoS testing/visualisation ▸ Add reaction and mitigation capabilities (to app, not network)

▸ RBAC visualisation and testing ▸ Apps containerisation and instrumentation

Questions?THANKS