This talk will discuss some key Software Security related activities and highlight some challenges in implementing them in real life (theory vs practice). Some of the topics covered: - Application Security vs Software Security - Project-driven vs Application-driven approaches - From IT Security to Information Security to Software Security (evolution in our field) - Coping with the demand / prioritization - OpenSAMM / BSIMM / Security Touchpoints - Post pentesting - IT stakeholders (Project Managers, Developers, …) vs Software Security Specialists

1. Theory vs Practice in
implementing Software
Security related activities
Simon Blanchet, CISSP, PMP
Head of Application Security /
{Undisclosed} Private Bank
Application Security Forum - 2012
Western Switzerland
7-8 novembre 2012 - Y-Parc / Yverdon-les-Bains
https://www.appsec-forum.ch

2. 2
Agenda
Application Security? / Software Security?
The actors, the stage, the script, …
The theory or “the sky is blue”
The practice or “let’s take the red pill”
The challenges & how to overcome them
Conclusion

3. 3
Bio
I’m Simon Blanchet, CISSP, PMP
Head of Application Security in a Private Bank
Where I’m coming from?
– Computer Science
– Security Software Designer
12+ years of Information System Security
7+ years in Private Banking

4. 4
Bio
I’m Managing an “AppSec” team responsible for
– Security Eng. / Risk Assessment / Security Testing
I love Cryptography, Software (In)Security, …
Fun facts
– Own (too) many books…
– Foodies, Beer, Urban Traveler, Bachata, …
I did this and that
– ASF-WS 2011 “Harmonizing Identity & Privacy…”
– BSIMM Europe Community Conference 2012

5. 5
Agenda – transition milestone…
Application Security? / Software Security?
The actors, the stage, the script, …
The theory or “the sky is blue”
The practice or “let’s take the red pill”
The challenges & how to overcome them
Conclusion

6. 6
Application Security? - Semantics
Application Security – a process?
“protects an organization’s critical data from external threats by
ensuring the security of all of the software used to run the
business. AppSec is the operational solution to the problem of
software risk. AppSec helps identify, fix and prevent security
vulnerabilities in any kind of software application…”i
Software Security – a attribute?
“the ability of software to resist, tolerate, and recover from
events that intentionally threaten its dependability. The main
objective of software security is to build more-robust, higher-
quality, defect-free software that continues to function correctly
under malicious attack”ii

7. 7
Application Security? - Semantics
Pushing to the extreme the definitions (for fun) ;-)
– AppSec: Integrating External Software, Protecting them
from External Threats
– SoftSec: Building Software Internally, Protecting them…
My own take on it / personal definition
– Building “secure” Software
– Securing existing Applications
– Acquiring & Integrating “securely” 3rd party Software
– Evolving “securely” existing Applications

8. 8
IT Security InfoSec AppSec
Once upon a time … ITSec: looking back in 95-05*
Perimeter security: Firewalls
– Erecting fences to keep them (bad guys) out
– ITSec essentially meant protecting the network (networks
segregation, IDS, monitor, alert, …) or installing AV and
keeping them updated…
IT Security Practitioners?
– Telecom background: Network guys
– Operating System background: Admin guys

9. 9
InfoSec Application Security
Obvious fact: attacks are climbing up the OSI stack
Software
Data
App
Host
Network

10. 10
Agenda – transition milestone
Application Security? / Software Security?
The actors, the stage, the script, …
The theory or “the sky is blue”
The practice or “let’s take the red pill”
The challenges & how to overcome them
Conclusion

11. 11
The Actors
Software Manufacturing aka “The Builders”
– Architects (Functional, Software, IT)
– Designers & Developers
Project Management
Security Specialist
– Security Consultants / Engineers / Architects
– Security Testers

12. 12
Actors – Designers & Developers
Have to deal with 3 trends “Trinity of Trouble”iii
making the software security problem bigger
– Connectivity
– Extensibility
– Complexity
Connectivity
Extensibility Complexity

13. 13
Actors – Project Managers
Project Constraint Model (3 key constraints)
– Cost
– Time
– Scope
Cost
Time Scope

14. 14
Actors – Security Specialists
Protect the CIA attributes of the Information
System and its underlying applications & data
– Confidentiality
– Integrity
– Availability Confidenti
ality
Integrity Availability

15. 15
The Stage (1/4)
Software C
Manufacturing
X C
C Project Impact
Security C
Q Managers Specialists
T S I A

16. 16
The Stage (2/4) – PM style
Initiating
Planning
Executing Controlling
Closing

17. 17
The Stage (3/4) – Soft Dev style

18. 18
The Stage (4/4) – AppSec style

19. 19
The Scripts
Software Manufacturing / Project Management
see Security Specialists as:
– Tax to pay
– Threat to Project (impact on time, cost, scope)
– Police officers: control & block
– “Inspecteur des travaux finis”: someone not helping
but criticizing other people's work after it is done

20. 20
The Scripts
Security Specialists see:
– Software Manufacturing (Architects & Developers)
• Security vulnerabilities (flaws / defects) introducers
• Privileging features over overall security / integrity
• Business slave or End-user pleaser
– Project Management
• “Don’t impact my Scope / Time / Cost”
• (Original Scope, Time & Cost estimate) >> Quality + Scope’
• Business slave or End-user pleaser

21. 21
Agenda – transition milestone
Application Security? / Software Security?
The actors, the stage, the script, …
The theory or “the sky is blue”
The practice or “let’s take the red pill”
The challenges & how to overcome them
Conclusion

22. 22
Theory – ISV vs Others
Independent Software Vendor (ISV)
– 1st activity = Software Development
– Revenue ($) = Software
– Methodology = SDLC
– Software is your business
Others (Financial / Banking / …)
– 1st activity != developing software
– Revenue ($) don’t come from SW
– Methodology = Project Management
– Software supports your business processes

23. 23
Theory – ISV (start AppSec)
Step 1 – Take your existing SDLC methodology
Step 2 – Embed security “touchpoints” into it
– Increase the number of them T1 T2 T3
– Increase the deepness of them

24. 24
Theory – Others (start AppSec) 1
Step 1 - ???
Now it gets tricky…
Developing software isn’t you 1st activity
Most likely software supports business processes
Most likely software are being
– Developed, Acquired, Integrated & Modified
… through Projects
Most likely you work on Projects

25. 25
Theory – Others (start AppSec) 2
Let’s try this again…
Naïve approach (in theory)
Project Touch
Software? Sec SDLC
What can go wrong??

26. 26
Theory vs Practice
In Theory … In the “Best World”
– Unlimited resources (time, money, people, …)
– PM, Soft Dev & AppSec resources work “hand in
hand” together toward the same objectives (bonus)
– Covering all the applications
– All projects systematically engage AppSec
Are you ready to take the red pill?
You wanna see how deep the rabbit-hole goes?

27. 27
Agenda – transition milestone
Application Security? / Software Security?
The actors, the stage, the script, …
The theory or “the sky is blue”
The practice or “let’s take the red pill”
The challenges & how to overcome them
Conclusion

28. 28
Practice – Reality = Constraints!
Real world
Limited resources
Must get the most for our bucks (ROI)
People are selfish (no kidding?!)
$$$ is everything
– “If we build this feature in the app we’ll get $$ more”
Time to Market (feature, service, product, …)
People different skills speak different languages

29. 29
Practice – Sounds familiar to you?
Mr. “Pain in the …” Ms. “Not in my Scope” Mr. “I’m smart”
CSRF,
Reflected XSS, Cross- something
Privilege Escalation, Scope Creep
Buffer Overflow, Blah, blah, …
Blah, blah, blah…
Not in my scope
Scope Creep, Deployment
Re-Baseline, Descriptor,
Earned Value, APIs,
Blah, blah, … Library,
Blah, Blah, …
It works, you’re not supposed to do that! WTF! Blah, Blah, …

30. 30
Practice – How to “crash” Theory
– Too many projects touching “software”
• How to keep track on these projects?
• Too many applications to keep track of
• How to keep track on your applications (inventory)?
– Reluctance of PM / SoftDev to engage AppSec team
– How can you perform ARA or Detailed Risk
Assessment if the input artefacts don’t exist?
– What about late engagement?
– What about Software Acquisition?

31. 31
Practice – (New?) Needs
Need to track & enforce AppSec engagements
– Who? / Where?
Need to prioritize
– What? & How?
Need to evaluate risk while acquiring software
– How?

32. 32
Practice – Let’s step back a lil’ bit
What is the primary objective of your AppSec
team?
Making sure that your organization is
– Building Secure Software
– Integrating Securely COTS Software that are Secure
– Modifying legacy Software without impacting the
Security of the whole Information System
Protecting the information assets of the org

33. 33
Practice – Security 101 (data)
Back to the basics… CIA triad
CIA is about Data / Information
We need an Information Classification Scheme!
– Hope you got one…
– Hope you have a process to deal with new “data”
• Own Information Asset Owner
• Classify Repository
Is Information Classification enough??

34. 34
Practice – Security 101 (system)
What about System Classification Scheme?
How to classify systems?
– Based on their priority in term of supporting a
business process owned by the business….
We need
– Business Process owner
– Product / Service owner

35. 35
Practice – System & Business
We need to assess Impact on their business
process(es) if this particular software fails
– Not available
– Data is disclosed
– Data / System is being tampered with
Need for criteria
– if we want to prioritize, we need a methodology…

36. 36
Practice – Toward solution
We need to prioritize AppSec engagement
– Criteria
• Information Classification
• Business Impact if System CIA compromised
We need a project inventory
We need application inventory
We need to enforce & monitor engagement for
the projects / application falling under our scope

37. 37
Agenda – transition milestone
Application Security? / Software Security?
The actors, the stage, the script, …
The theory or “the sky is blue”
The practice or “let’s take the red pill”
The challenges & how to overcome them
Conclusion

38. 38
Challenges - Inventory
Prioritize, Enforce & Monitor Engagements
Know your Applications
Know their “importance” in the eyes of the Business
Owner & underlying Business Processes
Have Incentives for PM & Soft Dev to Engage your
AppSec team & “be friend” with them
Perform ARA when input material isn't available
Software acquisition (pen testing vs making sure the
ISV have a well defined SSF)

39. 39
Challenges – Elements of solution
Prioritizing Engagements
– Know the project portfolio
– Define Engagement criteria with thresholds based on
• Information Classification
• Business Impact Assessment
Enforcing & Monitoring Engagements
– Define tollgates in the Project Management methodology
– Make sure someone is empowered to enforce these tollgates
and escalade

40. 40
Challenges – Elements of solution
Knowing your Applications
– Have an Application Inventory
– Keep the relevant information in it
– Maintain it (have a process to update it)
Knowing their “importance” in the eyes of the Business
Owner & Business Processes they support
– Assess your existing legacy applications by performing some kind of
Business Impact Analysis
– Know and understand the business process they support
– Update your Application Inventory accordingly

41. 41
A Picture is worth a 1000 of words
Project Portfolio App Inventory
Project 1 Application 1
BI
• Business Impact rating
IC
Project 2 Application 2
criteria
• Business impact rating
Project 3
Engagement Application 3
Project 4 • Business impact rating

42. 42
Challenges – Elements of solution
Have Incentives for PM & Soft Dev to Engage your
AppSec team & “be friend” with them
– Have management support to provide feedback on
PM / Soft Dev performance
– Identify the talented (trusted) individuals and teach
them more about Application Security (offensive
security & defensive programming) create satellite

43. 43
Practice – How about this instead?
Mr. “Security Specialist” Ms. “Project Manager” Mr. “Developer”
Risk,
Mitigation, Engage with our
Control, Security Specialist,
Change Request,
Business Lost
I’ll add it to my
Risk Register, Obviously
I’ll initiate a now I know,
Change Request I’ve put these
mitigation in
place.
Oh I get it wow! Look at this, you can use this API. I’ve seen
something similar there, I’ll fix it.

44. 44
Agenda – transition milestone
Application Security? / Software Security?
The actors, the stage, the script, …
The theory or “the sky is blue”
The practice or “let’s take the red pill”
The challenges & how to overcome them
Conclusion

45. 45
Conclusion
Learn about the other actors’ languages & skills
Know & understand business you’re working in
Risk Based approach for AppSec practices
Building bridges between them (PM & Soft Dev)
with you (AppSec)
– Gain their respect Show your skills
– Empower them Use tools

46. 46
Final Thought – Quoting BSIMM’
“If you must create software security types from
scratch, start with developers and teach them
about security and (project management). Do not
attempt to start with network security people and
teach them about software, compilers, SDLCs, bug
tracking, and everything else in the software
universe. No amount of traditional security
knowledge can overcome software cluelessness.”viii

47. 47
Questions?

48. 48
Merci / Thank you!
Contact:
Simon Blanchet
simon.blanchet@gmail.com
http://www.linkedin.com/in/sblanchet
Slides:
http://slideshare.net/ASF-WS/presentations

49. 49
About the author
Simon Blanchet, CISSP, PMP
Simon Blanchet is an Associate Director and Head of Application Security for a Private Bank. He is responsible, with the help of
his team of application security specialists, for ensuring the security of internally developed applications as well as the secure
integration of commercial off-the-shelf applications within the banking information systems. Simon’s team provides internal
security-consulting expertise to project management, business and development staff. He and his team are responsible for all
aspects of application security including risk assessment, application security risk analysis, threat modeling, security testing and
raising awareness about application security best practices.
Simon Blanchet has been professionally working in the fields of Information Systems Security and Security Software Design &
Development for the past 12 years. Simon has written his first lines of code in GW-BASIC on a TRS-80 at the age of 6 and spent
most of his teenage years hooked on North American BBSes when he became fascinated with the so-called “underground
hacking scene”. He started his professional career as a Software Developer and Development Team Leader (cryptographic &
security related software) in Montreal, Canada. Prior to moving into the Swiss Private Banking industry, Simon had the
opportunity to contribute to the first version of the SDK implementing Stefan Brands’ Digital Credential upon which is now built
Microsoft U-Prove. Simon’s career progressively evolved from being a seasoned security software developer to managing
software security, combining a software developer background with a true passion for application security architecture,
software security and software exploitation techniques. Simon likes to solve security related problems at the crossroads of
software development and IT Security.
Simon holds a B.Sc. in Computer Science from Laval University in Canada. He is a Certified Information Systems Security
Professional (CISSP) and a Project Management Professional (PMP).

50. 50
References
i. A CISO's Guide To Application Security - Part 1: Defining AppSec
ii. Software Security: Building Security In, Gary McGraw, 2006
iii. Software Security: The Trinity of Trouble, Gary McGraw, 2006
iv. Software Security Engineering: A Guide for Project Managers
v. Application Security (Wikipedia entry)
vi. CISM Review Manual 2012
vii. Project Management Body of Knowledge (PMBOK Guide)
viii. Build Security In Maturity Model (BSIMM3), p.5 - The Software Security
Group (SSG)