This document discusses building application security teams. It begins by introducing the author and their background in application security. It then discusses creating an environment where security enables business goals rather than hinders them. It suggests embedding security into culture by focusing on quality, testing, and engineering. It discusses the importance of application security policies being customized and delivered effectively. It emphasizes the need for application security activities like threat modeling and code reviews to avoid relying on "security pixie dust". It argues that even non-software companies should view themselves as software companies due to their reliance on code. Finally, it discusses building application security teams internally by training and educating developers rather than exclusively hiring specialists.

1. Building Application Security Teams
Dinis Cruz, CISO

2. Me
▪ Developer for 25 years
▪ AppSec for 13 years
▪ Day jobs:
▪ Leader OWASP O2 Platform project
▪ Application Security Training
▪ Part of AppSec team of:
▪ The Hut Group
▪ BBC
▪ WorldFirst
▪ AppSec Consultant and Mentor
▪ CISO (soon)
▪ “I build AppSec teams….”
▪ https://twitter.com/DinisCruz
▪ http://blog.diniscruz.com
▪ http://leanpub.com/u/DinisCruz

3. CISO POINT VIEW

4. What type of security organisation to create
▪ Create an environment and workflow where Security (InfoSec
and AppSec) is an enabler.
▪ Allow the business to ship faster with quality, security and
assurance
▪ InfoSec protects the organisation and operations
▪ AppSec protects the code created, used and bought
▪ Developers code in environments where it is very hard to
create security vulnerabilities
▪ Applications run in environments where security exploits are
contained and visible
▪ Align business risk appetite with reality (using proposed Risk
Workflow to allocate responsibility at the correct level)

5. How to embed security into the culture
▪ Give security teams a mandate to focus on Quality, Testing
and Engineering
▪ Create a network of Security Champions
▪ Become the ‘Department of Yes’
▪ Measure code pollution using Risk Workflow
▪ Understand that developers are key players and need to be
trusted
▪ Testing and Quality are core business requirements (and what
gives you speed)
▪ Create an central AppSec team (usually there is only an
InfoSec team)

6. What about security policies?
▪ Security policies are the foundation of decisions
▪ They underpin the reason behind actions and risk accepted
▪ But, if not based on reality, most policies will NOT be
▪ read
▪ followed
▪ enforced
▪ For policies to work they need to be customised to its target
(for example Secure coding standards for App XYZ)
▪ They also need to be delivered in the target’s environment (for
example IDE)

7. Security magic pixie dust
▪ If you don’t:
▪ have an AppSec team
▪ do Threat Models
▪ do weekly code reviews and security assessments
▪ have embedded security automation automation in your SDL pipeline
▪ have secure coding standards, bug-bounties, dependency
management
▪ …. and many other other AppSec activities
▪ There will be massive security vulnerabilities in the applications you use
▪ Because where is security going to come from?
▪ Without these activities:
▪ Your security model is based on the ‘skill level’ and ‘business model’
of your attackers
▪ … and … ’magic security pixie dust’ (which works until attacked)

8. WHERE IS APPSEC?

9. You are a software company
▪ Even if your company does not hire developers, you are already
a ‘software company’
▪ You probably don’t view Software Development as a core
competency, and don’t control the Software/Applications that
run your business (which is a high risk)
▪ If your company operations, customer experiences and sales are
controlled by software that you write, then you ARE A
SOFTWARE COMPANY (regardless of industry sector you’re in)
▪ The question is how much does your board and exec team
realises that, and how much priority and focus is given to
(secure) Software development
▪ ‘Code’ controls your company
▪ The question is how much do you ‘control’ your code

10. Quality on the code that runs your business
▪ Quality is not something you can sprinkle at the end
▪ Security is just like Quality
▪ Specially Application Security (i.e. secure code)
▪ Key concept:
▪ You can use Security to measure quality
▪ because although
▪ not all quality issues are security issues
▪ all security issues are quality issues

11. If your not deploying daily/hourly
▪ You’re not in the game
▪ Will struggle to innovate
▪ Depend on your competitors being worse than you
https://github.com/blog/1241-deploying-at-
http://joshuaseiden.com/blog/2013/12/amazon-deploys-to-production-

12. CISO MindMap
http://www.aurorait.com/2016/06/13/one-size-never-fits/

13. CISO MindMap (Zoomed in)

14. Top level functions (from CISO MindMap)
▪ Business Enablement
▪ Selling InfoSec (Internal)
▪ Governance
▪ Security Operations
▪ Project Delivery Lifecycle
▪ Budget
▪ Security Architecture
▪ Compliance and Audit
▪ Legal and Human Resources
▪ Risk Management
▪ Identity Management
But where is
Application
Security?

16. Where is AppSec?

17. Should AppSec be this low down the priorities?
▪ Of course you need to get the other security functions right
(Risk, Networks, SecOps)
▪ But if you don’t write or buy secure code, your assets will
be exposed
▪ In fact with the current move for DevOps, Continuous
Deployment and quick releases
▪ You will create an environment where security
vulnerabilities will be pushed into production in days (or
hours)
▪ Application Security (AppSec) needs to be a first class citizen,
with strong budget and staff

18. I like this Security Group Structure
▪ Key Areas:
▪ SecOps
▪ SOC
▪ RISK
▪ AppSec
▪ Testing
▪ Also important:
▪ Security
Champions
▪ Knowledge
▪ RND

19. Example of Security Function Budget and Team
▪ Budget should be 4% of turn-over (same as GDPR max fine)
▪ 26 staff
▪ 4x Management (CISO, Senior Director InfoSec, Project Manager, PA)
▪ 8x SecOps (2x Network & Information Security, 2x End-User-
Computing, 2x DevOps, 2x SysAdmin)
▪ 4x Risk (DPO - Data Protection Officer, 2x Standards, Policy)
▪ 4x SOC (2x SOC SME and 2x SOC Engineer)
▪ 5x AppSec (Senior Architect Manager, 2x Senior Dev 2x Dev)
▪ 1x Testing (1x RedTeam)
▪ Each function has individual budget (for tools and 3rd party
consulting services)

20. AppSec is a first class citizen
AppSec as a top
level function

21. APPSEC FUNCTION

22. Service driven organisation
▪ AppSec and Testing services can be requested by existing
Teams/Squads:
▪ External Pen-Tests
▪ Code Reviews (internal and external)
▪ Threat Modeling
▪ Static and Dynamic scanning of code
▪ AppSec Training
▪ AppSec Advisory Surgery

23. AppSec Functions Provided
▪ Security Champions Network
▪ AppSec Risk Workflow
▪ AppSec knowledge base (Wiki based)
▪ AppSec Policy
▪ Secure Coding Standards (based on JIRA Risk issues and
OWASP ASVS)
▪ SDL (Secure Development Lifecycle) programme owner
▪ Internal and External Bug-Bounty management
▪ Maturity Models mapping (based on OwaspSAMM)
▪ Application Registry and Attack Surface mapping
▪ Visualisation of existing architecture/code and Business
reporting of existing risks

24. Security tools integration in SDL
▪ Evaluate and deploy tools to perform Static (SAST) and
Dynamic (DAST) scans of existing Application and
components
▪ Customisation of rules in order to create highly defensible
findings
▪ Work with Security Champions on how to fix issues

25. APPSEC SQUAD

26. AppSec Squad is an
horizontal service/team
focused on Securing
Applications and code

27. AppSec Squad Function
▪ The AppSec Squad is focused on Secure Code and Fixes
▪ It is an horizontal team (vs dev squads/teams which are vertical)
▪ Works independently or directly with devs (on AppSec
issues and fixes)
▪ Helps Security Champions in activities or code-fixes that
require significant resources
▪ Independent from ‘product’ owners and deadlines
▪ Focus is on making applications/products more secure, resilient
and safe
▪ Made of developers and graduates
▪ Creates next generation of expert Security Champions
▪ 3 months rotation by internal developers/graduates

28. Security Features != AppSec Squad
▪ Security Features are focused on creating, coding, deploying
and maintaining business features that have a security angle
to them
▪ 2FA (two-factor authentication)
▪ Secure file upload
▪ Data encryption
▪ HTTPS support
▪ Authentication/Authorization/RBAC improvements
▪ …other
▪ The AppSec Squad is focused on Secure Code, Security
Testing and Visualisation/Documentation

29. Example of AppSec Squad driven projects*
▪ Mass fixing ‘systemic’ security vulnerability
▪ Create targeted and global SAST rules (scale security knowledge)
▪ Create Attack Surface mapping tool
▪ Web Services Visualisation tool
▪ Standard Schemas and validation across the company
▪ Application registry (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
*Security Champions to be involved in these projects

30. Team
▪ Project Manager: 1x
▪ AppSec Specialist: 1x
▪ AppSec Developers: 2x to 4x
▪ AppSec Graduates: 2x to 4x

31. AppSec Developers (2 to 4)
▪ Activities:
▪ Fix Security issues
▪ Improve QA environments
▪ Write tests
▪ Harden Dev environment (creating secure-by-default APIs and
runtimes)
▪ Improve apps logging capabilities and visualisation
▪ Create data-flow and architecture diagrams from code (used by
Threat models)
▪ Skills:
▪ experts in language(s) used in company
▪ Interested in AppSec and Security
▪ Able to write code fixes and tests with confidence and speed Able to
find innovative solutions for improving the Test and QA environments

32. AppSec Graduates: 2 to 4
▪ Activities:
▪ Simple/known security code fixes
▪ Support AppSec Function activities
▪ Support Security Champion’s activities
▪ Help with JIRA tickets maintenance
▪ Help with Threat Model diagrams
▪ Skills:
▪ Developers
▪ Passion for AppSec and Security

33. SECURITY CHAMPIONS

34. SCs Roles and Responsibilities
▪ Allocated to each Squad
▪ SME for all AppSec issues related to allocated tribe
▪ Maintain JIRA tickets for allocated code-base (projects and
components)
▪ Write Security Focused tests and embed SDL practices into CI
pipeline
▪ Triage AppSec Findings and Fix relevant issues

35. More expanded definition

36. If you don’t have an SC, get a Mug

37. JIRA RISK WORKFLOW

38. JIRA RISK Workflow

39. Key for AppSec JIRA workflow is this button

40. PATH #1 - Fix issue

41. PATH #2 - Accept and Approve RISK

42. PATH #2 - Variation when risk not approved

43. JIRA Risk workflow
▪ Open JIRA issues for all AppSec issues
▪ Write passing tests for issues reported
▪ Manage using AppSec RISK workflow
▪ Fix Path: Open, Allocated for Fix, Fix, Test Fix, Close
▪ Accept Risk Path: Open, Accept Risk, Approve Risk,
(Expire Risk)
▪ Automatically report RISK’s status

44. Separate JIRA project
▪ This is a separate JIRA repo from the one used by devs
▪ I like to call that project ‘RISK’
▪ This avoids project ‘issue creation’ politics and ‘safe harbour for:
▪ known issues
▪ ’shadow of a vulnerability’ issues
▪ ‘this could be an problem…’ issues
▪ ‘app is still in development’ issues
▪ When deciding to fix an issue:
▪ that is the moment to create an issue in the target project
JIRA (or whatever bug tracking system they used)
▪ When issue is fixed (and closed on target project JIRA):
▪ AppSec confirms fix and closes RISK

45. Always moving until fix or acceptance
▪ Key is to understand that issues need to be moving on one of
two paths:
▪ Fix
▪ Risk Accepted (and approved)
▪ Risks (i.e. issues) are never in ‘Backlog’
▪ If an issue is stuck in ‘allocated for fix’, then it will be
moved into the ‘Awaiting Risk Acceptance’ stage

46. You need volume
▪ If you don’t have 350+ issues on your JIRA RISK Project, you
are not playing (and don’t have enough visibility into what is
really going on)
▪ Allow team A to see what team B had (and scale due due to
issue description reuse)
▪ Problem is not teams with 50 issues, prob is team with 5
issues
▪ This is perfect for Gamification and to provide visibility into
who to reward (and promote)

47. Threat model
▪ All issues identified in Threat Models are added to the JIRA
RISK project
▪ Create Threat models by
▪ layer
▪ feature
▪ bug
▪ … that is a topic for another talk

48. JIRA AppSec Dashboards

49. Weekly emails with Risk status

50. Full details on “SecDevOps Risk Workflow” book
▪ Get it for free at https://leanpub.com/secdevops

51. GDPR

52. GDPR (for Apps)
▪ All this applies to GDPR
▪ If you trade with EU customers you will need to do it
▪ GDPR should be easy if you have an
▪ SOC
▪ Effective RISK team (with DPO)
▪ SecOps team
▪ AppSec team
▪ See great presentation at
https://www.owasp.org/images/c/
c8/2017-01-25,GDPR_Readiness-Handout.pdf (some
screenshots shown in next slide)

53. 7 Key principles enshrined in the EU GDPR

54. Twelve steps towards GDPR Readiness (1/2)
https://www.owasp.org/images/c/c8/2017-01-25,GDPR_Readiness-Handout.pdf

55. Twelve steps towards GDPR Readiness (2/2)

56. MATURITY MODELS

57. OwaspSAMM and BSIMM
https://www.owasp.org/index.php/OWASP_SAMM_Project
https://www.bsimm.com/

58. OWASP Maturity-Models project
▪ Tool to help collect and visualise maturity models date
▪ Open source https://github.com/owasp/maturity-models
▪ All data stored as Json using Git as data store
▪ Supports both OwaspSAMM and BSIMM schemas
▪ REST API to consume data
▪ Easy to deploy using docker image
▪ 97% to 100% code coverage
▪ Try it out on QA server http://138.68.145.52

60. BUILDING APPSEC TEAMS

61. You can’t hire AppSec specialists
▪ AppSec specialists will cost £120k+ (UK/US) and even then, they
might not be aligned with your values, technologies or focus
▪ Best to hire (internally) developers
▪ from £50k to £80k
▪ invest %25 of salary in Education/Knowledge (£12,5k to £20k)
▪ OWASP conferences (US or EU + regional)
▪ OWASP Summits
▪ BlackHat, DefCon, HITBSecConf, Shmoocon , DevSecCon
conferences
▪ Classroom based training sessions with security experts
▪ Web based learning tools (massive innovation in this area)
▪ Books, books, books, books
▪ 20% of their time allocated to learning and RnD (1 day a week)

62. Build your AppSec team from inside
▪ Ideal path is:
▪ Company hires Developers
▪ passes internal quality control, culture and skill’s requirements
▪ Developer applies to become a Security Champion
▪ Developer likes being a Security Champion and applies to an
open position in the AppSec Team (or other Security Function)
▪ Another option is:
▪ Hire specific individuals from 3rd-party ‘Application Security
focused’ or ‘Quality development focused’ companies
▪ Give them a job :) (with full transparency and support from 3rd
party company)
▪ ‘Worse case scenario’
▪ Hire developers from outside (via recruiters or directly)

63. OWASP

64. Epicentre of Application Security
▪ Best (dedicated) AppSec conferences of the year
▪ 100s of chapters around the world
▪ 100s of research projects on AppSec
▪ All released under OpenSource and Creative Common
licenses
▪ Best concentration of AppSec talent in the world
▪ Please join, collaborate, participate

65. Conferences

66. Chapters

67. Projects - Flagship

68. Projects - Labs

69. Projects - Incubator

70. OWASP Summits
▪ Imagine a place where (some of) the best Application Security and
OWASP minds come together to collaborate and work
▪ … a meeting of minds focused on solving hard problems that we
all have everyday
▪ … a place where security experts, developers, users, government
agencies and vendors work together on shared goals
▪ … a place where you will find like minded individuals that care
deeply about what you are passionate about
▪ … an environment designed for maximum geek-time, synergies
and collaboration
▪ … basically it’s AppSec from 8am till 2 am (next day)
▪ This place is something that only OWASP can create
▪ This place is an OWASP Summit

71. Summit - 2008

72. Summit 2011

73. OWASP Summit 2017 (June 12,16)
▪ http://owaspsummit.org/

74. Industry working together on hard problems

75. THANKS
Any questions?