The document discusses security best practices across the software development lifecycle (SDLC). It covers: - The Microsoft Security Development Lifecycle (SDL) methodology which includes activities like threat modeling, security testing, using approved tools and cryptography standards, managing third-party components, and establishing an incident response process. - Static and dynamic application security testing (SAST and DAST) - SAST analyzes source code for vulnerabilities while DAST tests running applications. Both have tradeoffs in terms of when issues are found, expenses to fix, and what types of vulnerabilities are discovered. - DevSecOps practices like integrating security activities into each stage of development through techniques like incremental threat modeling, automated testing, and continuous

1. Magnus Klaaborg Stubman,
Improsec A/S
Irina Kostina,
Microsoft
Security Development Lifecycle methodology & DevSecOps

2. Equifax breach 2017
Equifax's CEO and other executives resigned following a backlash over the hack at the company that
compromised the data of 143 million people
The thieves spent 76 days within Equifax's network before they were detected.
$700 million to settle federal and state investigations
$425 million to directly help consumers affected by the breach
$1.4 billion: Amount Equifax has spent on upgrading its security in the wake of the
incident

3. In contrast with:
SQL Injection : Extracts Starbucks Enterprise Accounting, Financial, Payroll
Database
Bounty : 4000$
https://hackerone.com/reports/531051

4. Development Methodologies
SDLC
Dev Test Deploy to ProductionDev

5. Development Methodologies
SDLC
Dev Test Deploy to ProductionDev
Dev Deploy to ProductionTest Dev Test Dev Test Dev

6. Development Methodologies
SDLC
Dev Test Deploy to ProductionDev
Dev Deploy to ProductionTest Dev Test Dev Test Dev
?

7. Development Methodologies
SDLC
Dev Test Deploy to ProductionDev
Dev Deploy to ProductionTest Dev Test Dev Test Dev
?
?

8. Development Methodologies
SDLC
Dev Test Deploy to ProductionDev
Dev Deploy to ProductionTest Dev Test Dev Test Dev

9. Development Methodologies
SDLC
Dev Test Deploy to ProductionDev
Dev Deploy to Production
Test Test Test

10. Development Methodologies
SDLC
Dev Test Deploy to ProductionDev
Dev Deploy to Production
Test Test Test
Training
Training

11. Development Methodologies
SDLC
Dev Test Deploy to ProductionDevTraining

12. Development Methodologies
SDLC

13. Development Methodologies
SDLC

14. Development Methodologies
SDLC

15. Development Methodologies
SDLC

16. Development Methodologies
SDLC

17. Development Methodologies
SDLC

18. Development Methodologies
SDLC

19. Development Methodologies
SDLC

20. Development Methodologies
SDLC
How easy/hard is it to get rid of the solution?

21. Development Methodologies
SDLC
How easy/hard is it to get rid of the solution?
How easy/hard is it to move the solution?

22. Development Methodologies - summarized
SDLC
• Your mileage may very – one size does not fit all

23. Development Methodologies - summarized
SDLC
• Your mileage may very – one size does not fit all
• Waterfall approach may increase reliability, but reduce predictability

24. Development Methodologies - summarized
SDLC
• Your mileage may very – one size does not fit all
• Waterfall approach may increase reliability, but reduce predictability
• Agile approach may increase predictability, but reduce reliability

25. Development Methodologies - summarized
SDLC
• Your mileage may very – one size does not fit all
• Waterfall approach may increase reliability, but reduce predictability
• Agile approach may increase predictability, but reduce reliability
• Training is a one time cost, and gives value over time

26. Development Methodologies - summarized
SDLC
• Your mileage may very – one size does not fit all
• Waterfall approach may increase reliability, but reduce predictability
• Agile approach may increase predictability, but reduce reliability
• Training is a one time cost, and gives value over time
• Ask yourself:
• What do you need?
• What works in your organization?

27. Internal Quality Assurance (QA)
SDLC
• Definition of Done:
• Implemented according to Standards
• Unit test cases has been written for all functionality
• Documented
• Code reviewed by colleague
• Documentation review by colleague
• dependency-check reports 0 vulnerabilities

32. https://www.exploit-db.com/exploits/18329

33. Security – all or nothing?

34. Security – all or nothing?
• Cost
• Productivity hit
• Security hit
• Horror stories?

35. Security – all or nothing?
• Cost
• Productivity hit
• Security hit
• Horror stories?
• Start over?

36. Security – all or nothing?
• Cost
• Productivity hit
• Security hit
• Horror stories?
• Start over?
• The most important step is the first!
• Get started
• Incremental improvements
• Try, try and try again

37. Segmentation

39. Segmentation / Isolation / Separation

41. Simplicity

44. Simplicity
Silver Bullets
• Complex code
• Hard to read

45. Simplicity
Silver Bullets
• Complex code
• Hard to read
• Hard to review

46. Simplicity
Silver Bullets
• Complex code
• Hard to read
• Hard to review
• Hard to maintain

47. Simplicity
Silver Bullets
• Complex code
• Hard to read
• Hard to review
• Hard to maintain
• Hard to add new features

48. Simplicity
Silver Bullets
• Complex code
• Hard to read
• Hard to review
• Hard to maintain
• Hard to add new features
• Hard to replace/deprecate

49. Simplicity
Silver Bullets
• Complex code
• Hard to read
• Hard to review
• Hard to maintain
• Hard to add new features
• Hard to replace/deprecate
• Lower developer satisfaction

50. Simplicity
Silver Bullets
• Complex code
• Hard to read
• Hard to review
• Hard to maintain
• Hard to add new features
• Hard to replace/deprecate
• Lower developer satisfaction
• Harder to pentest

51. Simplicity
Silver Bullets
• Complex code
• Hard to read
• Hard to review
• Hard to maintain
• Hard to add new features
• Hard to replace/deprecate
• Lower developer satisfaction
• Harder to pentest
Expensive!

53. Security as a Cultural Phenomenon
• Policies, guidelines from management → top-down approach

54. Security as a Cultural Phenomenon
• Policies, guidelines from management → top-down approach
• Security awareness, security trainings → bottom-up approach

55. Security as a Cultural Phenomenon
• Policies, guidelines from management → top-down approach
• Security awareness, security trainings → bottom-up approach
• Code review after pentest → teammeeting, walk through vulnerabilities,
talk about mitigations pros/cons. No finger pointing, only learning.

56. Security as a Cultural Phenomenon
• Policies, guidelines from management → top-down approach
• Security awareness, security trainings → bottom-up approach
• Code review after pentest → teammeeting, walk through vulnerabilities,
talk about mitigations pros/cons. No finger pointing, only learning.
• "What are we doing to prevent this from being abused/exploited?"

57. Security as a Cultural Phenomenon
• OWASP
• "Top 10": https://owasp.org/www-project-top-ten/
• Present one topic each once a week, during a lunchmeeting

58. Security as a Cultural Phenomenon
• OWASP
• "Top 10": https://owasp.org/www-project-top-ten/
• Present one topic each once a week, during a lunchmeeting

59. Security as a Cultural Phenomenon
• OWASP
• "Top 10": https://owasp.org/www-project-top-ten/
• Present one topic each once a week, during a lunchmeeting
• Copenhagen: https://owasp.org/www-chapter-copenhagen/
• Aarhus: https://owasp.org/www-chapter-aarhus/

60. Silver Bullets - summarized
SDLC
• Segmentation
• Simplicity
• Culture

61. Provide Training
Ensure everyone understands
security best practices.
Define Security
Requirements
Continually update security
requirements to reflect
changes in functionality and
to the regulatory and threat
landscape.
Define Metrics and
Compliance Reporting
Identify the minimum acceptable
levels of security quality and how
engineering teams will be held
accountable.
Perform Threat
Modeling
Use threat modeling to
identify security
vulnerabilities, determine
risk, and identify
mitigations.
Establish Design
Requirements
Define standard security
features that all engineers
should use.
Define and Use
Cryptography
Standards
Ensure the right
cryptographic solutions are
used to protect data.
Manage the Security
Risk of Using Third-
Party Components
Keep an inventory of third-
party components and create
a plan to evaluate reported
vulnerabilities.
Use Approved
Tools
Define and publish a list
of approved tools and
their associated security
checks.
Perform Static
Analysis Security
Testing
Analyze source code before
compiling to validate the use
of secure coding policies.
Perform Dynamic
Analysis Security
Testing
Perform run-time
verification of fully compiled
software to test security of
fully integrated and running
code.
Perform
Penetration
Testing
Uncover potential
vulnerabilities resulting
from coding errors,
system configuration
faults, or other
operational deployment
weaknesses.
Establish a Standard
Incident Response
Process
Prepare an Incident Response
Plan to address new threats
that can emerge over time.
Microsoft SDL

62. Provide Training
Ensure everyone understands
security best practices.
Define Security
Requirements
Continually update security
requirements to reflect
changes in functionality and
to the regulatory and threat
landscape.
Define Metrics and
Compliance Reporting
Identify the minimum acceptable
levels of security quality and how
engineering teams will be held
accountable.
Perform Threat
Modeling
Use threat modeling to
identify security
vulnerabilities, determine
risk, and identify
mitigations.
Establish Design
Requirements
Define standard security
features that all engineers
should use.
Define and Use
Cryptography
Standards
Ensure the right
cryptographic solutions are
used to protect data.
Manage the Security
Risk of Using Third-
Party Components
Keep an inventory of third-
party components and create
a plan to evaluate reported
vulnerabilities.
Use Approved
Tools
Define and publish a list
of approved tools and
their associated security
checks.
Perform Static
Analysis Security
Testing
Analyze source code before
compiling to validate the use
of secure coding policies.
Perform Dynamic
Analysis Security
Testing
Perform run-time
verification of fully
compiled software to test
security of fully integrated
and running code.
Perform
Penetration
Testing
Uncover potential
vulnerabilities resulting
from coding errors,
system configuration
faults, or other
operational deployment
weaknesses.
Establish a Standard
Incident Response
Process
Prepare an Incident Response
Plan to address new threats
that can emerge over time.
Microsoft SDL

63. #5 : Threat Modeling

64. Development
Business
requirements
Operations Users
Feedback loop

65. Identify defects as
early as possible
Development
Business
requirements
Operations Users
Feedback loop
Monitor

66. Development
Business
requirements
Operations UsersDevelopment
Business
requirements
Incremental
Threat
Modeling
DAST
Operations Users
Dedicated
Pentesting
Vulnerability
Scanning
Monitoring
Periodic pentesting
Validation
SAST
Fast feedback loop
DevSecOps
Secure Deployment
https://azsk.azurewebsites.net/

67. Static Application Security Testing
https://owasp.org/www-community/Source_Code_Analysis_Tools
https://github.com/features/security
+
• Scales well (only needs the code)
• Finds vulnerabilities earlier in the
process
•Highlights the precise source files, line
numbers, subsections of lines
-
• Many types of security vulnerabilities are
difficult to find automatically
• High numbers of false positives
• Frequently can’t find configuration issues,
since they are not represented in the code
•Difficult to ‘prove’ that an identified security
issue is an actual vulnerability
https://sonarcloud.io/

68. #10: Dynamic Application Security Testing
-
• Not highly scalable
• No code visibility
• Slow scans
+
• Technology independent
• Low false positives
• Identifies configuration
issues
https://docs.microsoft.com/en-us/previous-versions/software-testing/cc162782(v=msdn.10)
https://www.g2.com/categories/dynamic-application-security-testing-dast
https://marketplace.visualstudio.com/search?term=security&target=AzureDevOps&category=All%20categories&sortBy=Relevance

69. SAST DAST
White box security testing
The tester has access to the underlying framework, design, and
implementation.
The application is tested from the inside out.
This type of testing represents the developer approach.
Black box security testing
The tester has no knowledge of the technologies or frameworks that the
application is built on.
The application is tested from the outside in.
This type of testing represents the hacker approach.
Requires source code.
SAST doesn’t require a deployed application. It analyzes the sources code
or binary without executing the application.
Requires a running application
DAST doesn’t require source code or binaries. It analyzes by executing the
application.
Finds vulnerabilities earlier in the SDLC.
The scan can be executed as soon as code is deemed feature-complete.
Finds vulnerabilities toward the end of the SDLC
Vulnerabilities can be discovered after the development cycle is complete.
Less expensive to fix vulnerabilities.
Since vulnerabilities are found earlier in the SDLC, it’s easier and faster to
remediate them. Findings can often be fixed before the code enters the
QA cycle.
More expensive to fix vulnerabilities
Since vulnerabilities are found toward the end of the SDLC, remediation
often gets pushed into the next cycle. Critical vulnerabilities may be fixed
as an emergency release.
Can’t discover run-time and environment-related issues.
Since the tool scans static code, it can’t discover run-time vulnerabilities.
Can discover run-time and environment-related issues
Since the tool uses dynamic analysis on an application, it is able to find
run-time vulnerabilities.
Supports all kinds of software.
Examples include web applications, web services, and thick clients.
Typically scans only apps like web applications and web services.
DAST is not useful for other types of software.

71. Where do I start?
aka.ms/sdlc
Implement
Use the implementers’
resources guides to
create an
implementation plan
that advances your
SDL maturity.
Self-assess
Review the self-
assessment guide to
assess your
organization’s current
SDL maturity level.
Identify
Identify where
your organization
falls on the SDL
Optimization
Maturity Model.

72. Thank you!
Any questions?