Presentation for new/existing Security Champions

1. SECURITY CHAMPIONS

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

3. Security Champions are a key
element of an AppSec team
They create an cross-
functional team focused on
Application Security

4. 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, …

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

6. 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’

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

8. 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!!

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

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

11. 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)

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

13. Threat Models - Start on paper

14. JIRA Risk workflow
▸ Key to entire system/workflow is this workflow

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

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

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

18. Questions?
THANKS