CSCE 522 Secure Software Development Best Practices - PowerPoint PPT Presentation

Loading...

PPT – CSCE 522 Secure Software Development Best Practices PowerPoint presentation | free to download - id: 78d75c-MWRiY



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

CSCE 522 Secure Software Development Best Practices

Description:

CSCE 522 Secure Software Development Best Practices CSCE 522 - Farkas * Reading This lecture: Pfleeger Chapter 3.1 G. McGraw, Software [In]security: Software Security ... – PowerPoint PPT presentation

Number of Views:14
Avg rating:3.0/5.0
Slides: 31
Provided by: FARKAS3
Learn more at: http://cse.sc.edu
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: CSCE 522 Secure Software Development Best Practices


1
CSCE 522 Secure Software DevelopmentBest
Practices
2
Reading
  • This lecture
  • Pfleeger Chapter 3.1
  • G. McGraw, Software Insecurity Software
    Security Zombies, 07/2011, http//www.informit.com
    /articles/article.aspx?p1739924

3
How to address software security?
  • Do not address at all
  • Ad-hoc evaluation
  • Add security features after the fact
  • Identify security vulnerabilities
  • Test security level
  • Incorporate security throughout of SDLC

CSCE 522 - Farkas
3
4
Checking for Known Vulnerabilities
  • Need tool
  • Possible attacks and attack types
  • How the software behaves if something goes WRONG
  • What motivates an attacker?

5
Three Pillars of Software Security
  • Risk Management Business case
  • Software Security Touchpoints Best practices
  • Knowledge Tools

CSCE 522 - Farkas
5
6
Risk Management
  • How much effort to invest in security
  • Consequences of security breaches
  • Acceptable-level of security
  • Tracking and mitigating risk throughout the full
    SDLC

CSCE 522 - Farkas
6
7
Knowledge
  • Gathering, encapsulating, and sharing security
    knowledge
  • Knowledge categories
  • Prescriptive knowledge
  • Diagnostic knowledge
  • Historical knowledge
  • Applied along the SDLC

CSCE 522 - Farkas
7
8
Touchpoints
  • System-wide activity from design to testing and
    feedback
  • Touchpoints
  • Code review
  • Architectural risk analysis
  • Penetration testing
  • Risk-based security testing
  • Abuse cases
  • Security requirements
  • Security operations

CSCE 522 - Farkas
8
9
Application of Touchpoints
External Review
3. Penetration Testing
1. Code Review (Tools)
6. Security Requirements
4. Risk-Based Security Tests
2. Risk Analysis
7. Security Operations
5. Abuse cases
2. Risk Analysis
Requirement and Use cases
Architecture and Design
Test Plans
Code
Tests and Test Results
Feedback from the Field
10
Software Vendor Accountability
  • Proper implementation of security features
  • Looking for known security flaws
  • Passing third party validation
  • Source code analysis

11
Application of Touchpoints
External Review
3. Penetration Testing
1. Code Review (Tools)
6. Security Requirements
4. Risk-Based Security Tests
2. Risk Analysis
7. Security Operations
5. Abuse cases
2. Risk Analysis
Requirement and Use cases
Architecture and Design
Test Plans
Code
Tests and Test Results
Feedback from the Field
12
Misuse Cases
  • Software development making software do
    something
  • Describe features and functions
  • Everything goes right
  • Need security, performance, reliability
  • Service level agreement legal binding
  • How to model non-normative behavior in use cases?
  • Think like a bad guy

13
Misuse Cases
  • Extends use case diagrams
  • Represent actions the system should prevent
  • Represent together
  • Desired functionalities
  • Undesired actions
  • Security emergent property ? must be built in
    from the ground up
  • Making explicit trade offs

14
Misuse Cases
  • Analyze system design and requirements
  • Assumptions
  • Failure of assumptions
  • Attack patterns
  • Software that is used also going to be attacked
  • What can a bad guy do and how to react to
    malicious use

15
Misuse Case Development
  • Team work software developers and security
    experts
  • Identifying and documenting threats
  • Creating anti-requirements how the system can be
    abused
  • Creating attack model
  • Select attack pattern relevant to the system
  • Include anyone who can gain access to the system

16
Application of Touchpoints
External Review
3. Penetration Testing
1. Code Review (Tools)
6. Security Requirements
4. Risk-Based Security Tests
2. Risk Analysis
7. Security Operations
5. Abuse cases
2. Risk Analysis
Requirement and Use cases
Architecture and Design
Test Plans
Code
Tests and Test Results
Feedback from the Field
17
Software Testing
  • Application fulfills functional requirements
  • Dynamic, functional tests late in the SDLC
  • Contextual information

18
Security Testing
  • Test finding flaws in software can be exploited
    by attackers
  • Quality, reliability and security are tightly
    coupled
  • Software behavior testing
  • Need risk-based approach using system
    architecture information and attackers model

19
Security Testing
  • Look for unexpected but intentional misuse of the
    system
  • Must test for all potential misuse types using
  • Architectural risk analysis results
  • Abuse cases
  • Verify that
  • All intended security features work (white hat)
  • Intentional attacks cannot compromise the system
    (black hat)

20
Penetration Testing
  • Testing for negative what must not exist in the
    system
  • Difficult how to prove non-existence
  • If penetration testing does not find errors than
  • Can conclude that under the given circumstances
    no security faults occurred
  • Little assurance that application is immune to
    attacks
  • Feel-good exercise

21
Penetration Testing Today
  • Often performed
  • Applied to finished products
  • Outside ? in approach
  • Late SDLC activity
  • Limitation too little, too late

22
Late-Lifecycle Testing
  • Limitations
  • Design and coding errors are too late to discover
  • Higher cost than earlier designs-level detection
  • Options to remedy discovered flaws are
    constrained by both time and budget
  • Advantages evaluate the system in its final
    operating environment

23
Success of Penetration Testing
  • Depends on skill, knowledge, and experience of
    the tester
  • Important! Result interpretation
  • Disadvantages of penetration testing
  • Often used as an excuse to declare victory and go
    home
  • Everyone looks good after negative testing
    results

24
Behavior in the Presence of Malicious Attack
  • What happens when the software fails?
  • Safety critical systems
  • Track risk over time
  • Security relative to
  • Information and services protected
  • Skills and resources of adversaries
  • Cost of protection
  • System vulnerabilities

25
Malicious Input
  • Software takes input
  • Trust input?
  • Malformed or malicious input may lead to security
    compromise
  • What is the input?
  • Data vs. control
  • Attacker toolkit

26
Traditional Software Development
  • No information security consideration
  • Highly distributed among business units
  • Lack of understanding of technical security risks

27
Dont stand so close to me
  • Best Practices
  • Manageable number of simple activities
  • Should be applied throughout the software
    development process
  • Problem
  • Software developers lack of security domain
    knowledge ? limited to functional security
  • Information security professionals lack of
    understanding software ? limited to reactive
    security techniques

28
Vulnerability Monitoring
  • Identify security weaknesses
  • Methods
  • Automated tools
  • Human walk-through
  • Surveillance
  • Audit
  • Background checks

29
Red Team
  • Organized group of people attempting to penetrate
    the security safeguards of the system.
  • Assess the security of the system ? future
    improvement
  • Requested or permitted by the owner to perform
    the assessment
  • Wide coverage computer systems, physical
    resources, programming languages, operational
    practices, etc.

30
Next Class
  • Malicious code
About PowerShow.com