asfws 2012 - theory vs practice in implementing software security related activities par simon...

Theory vs Practice in implementing Software Security related activities

Application Security Forum - 2012Western Switzerland

7-8 novembre 2012 - Y-Parc / Yverdon-les-Bains

https://www.appsec-forum.ch

Simon Blanchet, CISSP, PMP

Head of Application Security /

{Undisclosed} Private Bank

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”

2


� The challenges & how to overcome them

� Conclusion

Bio

� I’m Simon Blanchet, CISSP, PMP

� Head of Application Security in a Private Bank

� Where I’m coming from?

– Computer Science

3

– Computer Science

– Security Software Designer

� 12+ years of Information System Security

� 7+ years in Private Banking

Bio

� I’m Managing an “AppSec” team responsible for

– Security Eng. / Risk Assessment / Security Testing

� I love Cryptography, Software (In)Security, …

� Fun facts

4

� 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

Agenda – transition milestone…





5



� Conclusion

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

6

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

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…

7

– 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

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

8

– 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

InfoSec� Application Security

� Obvious fact: attacks are climbing up the OSI stack

9

Software

Data

App

Host

Network

Agenda – transition milestone





10



� Conclusion

The Actors

� Software Manufacturing aka “The Builders”

– Architects (Functional, Software, IT)

– Designers & Developers

� Project Management

11

� Project Management

� Security Specialist

– Security Consultants / Engineers / Architects

– Security Testers

Actors – Designers & Developers

� Have to deal with 3 trends “Trinity of Trouble”iii

making the software security problem bigger

– Connectivity

– Extensibility

12

– Extensibility

– ComplexityConnectivityConnectivity

ExtensibilityExtensibility ComplexityComplexity

Actors – Project Managers

� Project Constraint Model (3 key constraints)

– Cost

– Time

– Scope

13

– Scope

CostCost

TimeTime ScopeScope

Actors – Security Specialists

� Protect the CIA attributes of the Information

System and its underlying applications & data

– Confidentiality

– Integrity

14

– Integrity

– AvailabilityConfidenti

alityConfidenti

ality

IntegrityIntegrity AvailabilityAvailability

The Stage (1/4)

15

Software Manufacturing

Software Manufacturing

CC

XX CC

Security Specialists

Security Specialists

ImpactImpactProject

ManagersProject

ManagersCC

II AA

CC

TT

QQ

SS

The Stage (2/4) – PM style

16

InitiatingInitiating

PlanningPlanning

ClosingClosing

ControllingControllingExecutingExecuting

The Stage (3/4) – Soft Dev style

17

The Stage (4/4) – AppSec style

18

The Scripts

� Software Manufacturing / Project Management

see Security Specialists as:

– Tax to pay

– Threat to Project (impact on time, cost, scope)

19

– 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

The Scripts

� Security Specialists see:

– Software Manufacturing (Architects & Developers)

• Security vulnerabilities (flaws / defects) introducers

• Privileging features over overall security / integrity

20

• 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



� Conclusion

Theory – ISV vs Others

� Independent Software Vendor (ISV)

– 1st activity = Software Development

– Revenue ($) = Software

– Methodology = SDLC

22

– 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

Theory – ISV (start AppSec)

� Step 1 – Take your existing SDLC methodology

23

� Step 2 – Embed security “touchpoints” into it

– Increase the number of them

– Increase the deepness of them

T1T1 T2T2 T3T3

Theory – Others (start AppSec) 1

� Step 1 - ???

� Now it gets tricky…

� Developing software isn’t you 1st activity

� Most likely software supports business processes

24

� Most likely software supports business processes

� Most likely software are being

– Developed, Acquired, Integrated & Modified

� … through Projects

� Most likely you work on Projects

Theory – Others (start AppSec) 2

� Let’s try this again…

� Naïve approach (in theory)

25

� What can go wrong??

ProjectProject Sec SDLCSec SDLCTouch

Software?

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)

26

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



� Conclusion

Practice – Reality = Constraints!

� Real world

� Limited resources

� Must get the most for our bucks (ROI)

� People are selfish (no kidding?!)

28

� 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

Practice – Sounds familiar to you?

29

Ms. “Not in my Scope”Mr. “Pain in the …” Mr. “I’m smart”

CSRF,

Reflected XSS,

Privilege Escalation,

Buffer Overflow,

Blah, blah, blah…

Cross- something

Scope Creep

Blah, blah, …

Not in my scope

Scope Creep,

Re-Baseline,

Earned Value,

Blah, blah, …

Deployment

Descriptor,

APIs,

Library,

Blah, Blah, …

It works, you’re not supposed to do that! WTF! Blah, Blah, …

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)?

30

• 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?

Practice – (New?) Needs

� Need to track & enforce AppSec engagements

– Who? / Where?

� Need to prioritize

– What? & How?

31

– What? & How?

� Need to evaluate risk while acquiring software

– How?

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

32

– 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

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…

33

– Hope you got one…

– Hope you have a process to deal with new “data”

• Own � Information Asset Owner

• Classify � Repository

� Is Information Classification enough??

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

34

business process owned by the business….

� We need

– Business Process owner

– Product / Service owner

Practice – System & Business

� We need to assess Impact on their business

process(es) if this particular software fails

– Not available

– Data is disclosed

35

– Data is disclosed

– Data / System is being tampered with

� Need for criteria

– if we want to prioritize, we need a methodology…

Practice – Toward solution

� We need to prioritize AppSec engagement

– Criteria

• Information Classification

• Business Impact if System CIA compromised

36

• 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



� Conclusion

Challenges - Inventory

� Prioritize, Enforce & Monitor Engagements

� Know your Applications

� Know their “importance” in the eyes of the Business Owner & underlying Business Processes

38

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)

Challenges – Elements of solution

� Prioritizing Engagements

– Know the project portfolio

– Define Engagement criteria with thresholds based on• Information Classification

39

• 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


� 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

40

� 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

A Picture is worth a 1000 of words

41

Application 1

• Business Impact rating

Application 1

• Business Impact rating

Application 2Application 2

Project 1Project 1

Project 2Project 2

App InventoryProject Portfolio

ICICBIBI

Application 2

• Business impact rating

Application 2


Application 3


Application 3


Project 3Project 3

Project 4Project 4Engagement

criteriacriteria


� 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

42

PM / Soft Dev performance

– Identify the talented (trusted) individuals and teach

them more about Application Security (offensive

security & defensive programming) � create satellite

Practice – How about this instead?

43

Ms. “Project Manager”Mr. “Security Specialist” Mr. “Developer”

Risk,

Mitigation,

Control,

Change Request,

Business Lost

Engage with our

Security Specialist,

I’ll add it to my

Risk Register,

I’ll initiate a

Change Request

Obviously

now I know,

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



� Conclusion

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)

45

� Building bridges between them (PM & Soft Dev)

with you (AppSec)

– Gain their respect � Show your skills

– Empower them � Use tools

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

46

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

Questions?

47

Merci / Thank you!

Contact:

Simon Blanchet

[email protected]

48

[email protected]

http://www.linkedin.com/in/sblanchet

Slides:

http://slideshare.net/ASF-WS/presentations

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.

49

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

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)

50

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)

asfws 2012 - theory vs practice in implementing software security related activities par simon...

Technology

security practitioners

perimeter security

agenda application security

semantics application

actors security specialists

external software

building software

software methodology