This document summarizes a presentation on securing 100 products. It discusses the challenges of securing multiple products, including mapping responsibilities, diverse technologies, and resource limitations. It provides approaches for prioritizing security based on product type and risk level. These include developing a security maturity program, product strategy, and correctly budgeting security resources. Automating security tools and finding partnerships can help scale efforts. Measuring effectiveness over time is also important.

1. SESSION ID:SESSION ID:
#RSAC
Nir Valtman, CISSP, CSSLP
Securing 100 Products - How Hard Can It Be?
ASD-W10F
Head of Application Security
NCR Corporation
@ValtmaNir
© 2017 NCR Corporation. All rights reserved.

2. #RSAC
Why Does This Talk Matter?
2
You Like Expensive Stuff!
Someone Will Pay You Lots Of $$$ To Do It
You May Need To Secure Many Products
It's A Big Challenge To Secure 100 Products
Provides Practical Approaches To Secure 100 Products
Why Does It Matter?
Why Does It Matter?
Why Does It Matter?
Why Does It Matter?

3. #RSAC
Meet Dave!
3
Accountable for Product Security
Cloud-based, self-hosted or installed on
customers’ premise
Part of the products are regulated
Needs to keep the company out of
the news
Got executives to support him
Avatar generated on avatarmaker.com

4. #RSAC
Legal Internal Audit
The Daily Challenges
4
IT Services
CISO
Solution
Management
Hardware
Solutions
Professional
ServicesProduct
Management
Software R&D
Need to secure a single high-risk product. Who’s involved?

5. #RSAC
Mapping The Business Owners
5
Product #1
 Software R&D
 CISO
 Legal
 Product
Management
 Internal Audit
Product #2
 Software R&D
 CISO
 Legal
 Product
Management
 Solution
Management
 Hardware
Solutions
Product #100
 Software R&D
 IT
 CISO
 Legal
 Product
Management
 Solution
Management
 Professional
Services

6. #RSAC
Will I Finish This Mapping Soon?
6
Will I Finish
This Mapping
Soon?

7. #RSAC
Scoping The Accountability

8. #RSAC
Core vs. Extensions
8
Customer #1
Extensions
Customer #N
Extensions
Core/Vanilla
Customer #2
Extensions
?

9. #RSAC
Difficult To Control All Engineering Parties
9
Security
requirements are
documented!
APIs are
documented!
Who cares?
BYOAPI rocks!!
Software R&D
Professional Services
Application Security

10. #RSAC
Resource Diversity & Limitations

11. #RSAC
Distinct Technologies
The trademarks specified above are trademarks or registered trademarks of their respective owners. This slide is
intended for informational purposes only and does not represent any endorsement

12. #RSAC
Diverse Application Security Tools
12
Static Application
Security Testing (SAST)
Dynamic Application
Security Testing (DAST)
Interactive Application
Security Testing (IAST)
Software Composition
Analysis
The trademarks specified above are trademarks or registered trademarks of their respective owners. This slide is
intended for informational purposes only and does not represent any endorsement.

13. #RSAC
Labor Limitations
13
1%-2%
of engineering org size

14. #RSAC
Application Security Maturity
Program
So Simple To Follow Guidelines, Isn’t It?

15. #RSAC
Governance – Easy To Say, Difficult To Control
15
Develop an S-SDLC Enforce the S-SDLC
Provide Technology-Specific Training
Map, Track & Drive Towards
Completion Of Trainings
Define Risk Management & Risk
Acceptance Process
Get Executives To Sign On A Security
Risk
Strategy &
Metrics
Policy &
Compliance
Education &
Guidance

16. #RSAC
Construction – Relatively Difficult
16
ThreatAssessment
Documenting
risks in agile
development
lifecycle
consumes
resources
Consider 3rd
party software
risks
SecurityRequirements
Should security
be involved in
all requirements
sessions?
Who audits the
security
requirements?
SecurityArchitecture
Providing best
practices for
various product
types
Audit the teams
for following
the secure
architecture
guidelines

17. #RSAC
Verification – Roadblocks Ahead!
17
•Get the/a design diagram from engineering teams… lots of teams!!!
•Working with many smart engineering people – they know everything!
Design Review
•Utilizing automation is great if ALL bug tracking, code repo, and build systems are centralized
•Scaling automation for 100 products is nearly impossible (technology & labor wise)
Code Review
•Automation = [sophisticated] vulnerability scanning. Manual work = penetration test!
•$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
Security Testing

18. #RSAC
Deployment – Only Sounds Easy
18
”Shadow”-operated IRT IT-operated IRT
Work w/ every engineering
team to QA hardening
If I define & It doesn’t work,
they’re responsible
Enforce operational security
guide per product.
Vulnerability
Management
Environment
Hardening
Operational
Enablement

19. #RSAC
Perspective On 1 Of 100 Products
19
1.60
2.60
3.00
1.00
2.601.35
1.70
2.10
1.67
1.68
2.35
1.70
0.00
0.50
1.00
1.50
2.00
2.50
3.00
Strategy & Metrics
Policy & Compliance
Education & Guidance
Threat Assessment
Security Requirements
Secure Architecture
Design Analysis
Implementation Review
Security Testing
Issue Management
Environment Hardening
Operational Enablement
Application Security Maturity Overview

20. #RSAC
Perspective On 1 Of 100 Products
20
Additional Considerations
Number of items per
development lifecycle stage
E.g. pending QA, not started, in
dev, etc.
Average time to mitigate a
vulnerability
Prioritized list of outstanding
Epics/US/Bugs

21. #RSAC
Perspective On 100 Products
21

22. #RSAC
Perspective On 100 Products
22
Product names are sanitized

23. #RSAC
Don’t Reinvent The Wheel,
Just Realign It!
(Anthony J. D’Angelo)

24. #RSAC
NCR’s App Sec Team’s Specialties
24
Application
Security Architect
Application
Security Engineer
Application
Security Program
Manager
Application
Security Risk &
Compliance
Manager

25. #RSAC
NCR’s App Sec Team’s Specialties Mapping
25
OpenSAMM Speciality
Domain Activity Security
Architecture
Program
Management
Risk Management
& Compliance
Application
Security
Engineering
Governance Strategy & Metrics V V
Policy & Compliance V
Education & Guidance V V V V
Construction Threat Assessment V
Security Requirements V V V
Secure Architecture V
Verification Design Review V
Code Review V V
Security Testing V
Deployment Vulnerability Mgmt V V
Environment Hardening V
Operational Enablement V

26. #RSAC
Prioritizing Security
26
Internet-
Facing &
Regulated
Internet-
Facing
Internal
Internal
Regulated
>$5M
$500K-
$1M
<$500K
$1M-
$5M
Product Type Financial ImpactStrategy
Investments
&
Commitments

27. #RSAC
Budgeting Labor Correctly – The Formula
27
Product Type % Of R&D
Internet-Facing & Regulated 2%
Internet-Facing 1%
Internal & Regulated 1%
Internal 0.3%
Product Type % Of AppSec
Program Manager 20%
Risk & Compliance 10%
Architecture 23%
Engineering 47%
R&D
Labor
Count
Example
An Internet-facing & regulated product suite that is
developed by an org size of 1000 employees needs:
2% X 1000 = 20 App Sec Team Members, consisting
of 4 PM, 2 R&C, 4.6 Architects and 9.4 Engineers

28. #RSAC
A Lesson Learned
28
Even with an aggressive strategy, hiring
app sec people is a REAL bottleneck!
(Nir Valtman, RSA Conference 2017)

29. #RSAC
Measuring Effectiveness!
29
Ongoing
Escalations asking for security resources by the
engineering teams are good!
Status reports must be balanced
Neither too Green nor Red

30. #RSAC
Measuring Effectiveness!
30
Year Over Year
Overall Application Security Maturity rank increases
Decreased number of security vulnerability reporting
Engineers will always make mistakes
Use 3rd parties to assess it

31. #RSAC
Scaling Out Team’s Capabilities
31
Security Questionnaire For Engaging An App Sec Architect
10 Yes/No Questions

32. #RSAC
Scaling Out Team’s Capabilities
32
Security Questionnaire For Engaging An App Sec Architect
10 Yes/No Questions
Is Data Classified?
Do You Follow The S-SDLC?
Data Encryption?
Handle Sensitive Data
Related To PII/PCI?
Security Automation
Integrated Into Pipeline?
Consumer-Facing Mobile
App?

33. #RSAC
10 Yes/No Questions
Scaling Out Team’s Capabilities
33
Security Questionnaire For Engaging An App Sec Architect
Workflow
Collaboration
Page
File Good
Better
Best

34. #RSAC
Scaling Up Security
34
Application Security Must Fit Into Any Pipeline
Plan Code Build Test Release Deploy Operate
DEV OPS
Continuous Delivery
Continuous Integration
Agile Development

35. #RSAC
Scaling Up Security Using Release Automation
35
Static App Sec Testing
Interactive App Sec
Testing (IAST)
Binary Signing
Code Obfuscation
Dynamic App Sec
Testing (DAST)
Vulnerability Scanning
Dynamic App Sec
Testing (DAST)
Vulnerability Scanning
Runtime App Self
Protection (RASP)
Runtime App Self
Protection (RASP)

36. #RSAC
Scaling Up Security When Lacking Automation
36
Identify Quick Wins
Static App Sec Testing Binary Signing
Code Obfuscation
Dynamic App Sec
Testing (DAST)
Vulnerability Scanning
Even A Long-Term Plan Is A Viable Plan
Penetration Tests
Manual Code Review

37. #RSAC
Finding The Partnerships – Use Cases
37
Partnerships
Customer Needs
Industry Trends
Regulations
Security

38. #RSAC
Additional Tips
38
Securing 100 products takes years.
Start by investing 80% of the resources in 20% of the products.
Reflect your success!
Trending charts of app sec metrics
Integration of tools into the build process
Share product certifications completion
Speak at RSA Conference 

39. #RSAC
39

40. #RSAC
Apply What You Have Learned Today
40
Next week you should:
Generate security engagement questionnaire (10 Yes/No Qs)
Identify security tool implementation quick wins
In the first three months following this presentation you should:
Establish an application security maturity program
Develop a product security strategy based on
— Company’s strategy
— Development methodologies & pipelining tools
— Product Types
Within six months you should:
Hopefully map all products & owners 
Start executing the strategy

41. #RSAC
41
QUESTIONS
QUESTIONS
QUESTIONS
QUESTIONS
QUESTIONS
QUESTIONS
Nir Valtman
Nir.Valtman@ncr.com
@ValtmaNir