CSCE 522 Secure Software Development Best Practices

CSCE 522 CSCE 522 Secure Software DevelopmentSecure Software Development

Best PracticesBest Practices

CSCE 522 - Farkas 2

ReadingReading

This lecture: Pfleeger Chapter 3.1 G. McGraw, Software [In]security: Software

Security Zombies, 07/2011, http://www.informit.com/articles/article.aspx?p=1739924

CSCE 522 - Farkas 3

Application of TouchpointsApplication of Touchpoints

Requirement and Use cases

Architecture and Design

Test Plans Code Tests andTest Results

Feedback fromthe Field

5. Abuse cases

6. Security Requirements

2. Risk Analysis

External Review

4. Risk-Based Security Tests

1. Code Review(Tools)

2. Risk Analysis

3. Penetration Testing

7. Security Operations

CSCE 522 - Farkas 4

Misuse CasesMisuse CasesSoftware 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

CSCE 522 - Farkas 5

Software Vendor AccountabilitySoftware Vendor Accountability

Proper implementation of security featuresLooking for known security flawsPassing third party validationSource code analysis

CSCE 522 - Farkas 6

Checking for Known Checking for Known VulnerabilitiesVulnerabilities

Need toolPossible attacks and attack typesHow the software behaves if something

goes WRONGWhat motivates an attacker?

CSCE 522 - Farkas 7

Misuse CasesMisuse Cases

Extends use case diagramsRepresent actions the system should preventRepresent together

– Desired functionalities– Undesired actions

Security: emergent property must be built in from the ground up

Making explicit trade offs

CSCE 522 - Farkas 8

Misuse CasesMisuse 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

CSCE 522 - Farkas 9

Misuse Case DevelopmentMisuse 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

CSCE 522 - Farkas 10






5. Abuse cases


2. Risk Analysis

External Review



2. Risk Analysis




Software TestingSoftware Testing

Application fulfills functional requirementsDynamic, functional tests late in the SDLCContextual information


Security TestingSecurity TestingLook for unexpected but intentional misuse of the

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


Penetration TestingPenetration 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


Penetration Testing TodayPenetration Testing Today

Often performedApplied to finished productsOutside in approachLate SDLC activityLimitation: too little, too late


Late-Lifecycle TestingLate-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


Success of Penetration TestingSuccess of Penetration Testing

Depends on skill, knowledge, and experience of the tester

Important! Result interpretationDisadvantages of penetration testing:

– Often used as an excuse to declare victory and go home

– Everyone looks good after negative testing results


Quality AssuranceQuality Assurance

External quality: correctness, reliability, usability, integrity

Interior (engineering) quality: efficiency, testability, documentation, structure

Future (adaptability) quality: flexibility, reusability, maintainability


Correctness TestingCorrectness Testing

Black box: – Test data are derived from the specified

functional requirements without regard to the final program structure

– Data-driven, input/output driven, or requirements-based

– Functional testing – No implementation details of the code are

considered


Correctness TestingCorrectness Testing

White box:– Software under test are visible to the tester – Testing plans: based on the details of the

software implementation – Test cases: derived from the program structure – glass-box testing, logic-driven testing, or

design-based testing


Performance TestingPerformance TestingGoal: bottleneck identification, performance

comparison and evaluation, etc.Explicit or implicit requirements"Performance bugs" – design problems Test: usage, throughput, stimulus-response

time, queue lengths, etc. Resources to be tested: network bandwidth

requirements, CPU cycles, disk space, disk access operations, memory usage, etc.


Reliability TestingReliability Testing

Probability of failure-free operation of a system

Dependable software: it does not fail in unexpected or catastrophic ways

Difficult to test(see later lecture on software reliability)


Security TestingSecurity 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 attacker’s model


Behavior in the Presence of Behavior in the Presence of Malicious AttackMalicious Attack

What happens when the software fails?– Safety critical systems

Track risk over timeSecurity relative to

– Information and services protected– Skills and resources of adversaries– Cost of protection

System vulnerabilities


Malicious InputMalicious Input

Software: takes inputTrust input?

– Malformed or malicious input may lead to security compromise

– What is the input? Data vs. control

Attacker toolkit







5. Abuse cases


2. Risk Analysis

External Review



2. Risk Analysis




Traditional Software Traditional Software DevelopmentDevelopment

No information security considerationHighly distributed among business unitsLack of understanding of technical security

risks


Don’t stand so close to me Don’t 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


Deployment and OperationsDeployment and Operations

Configuration and customization of software application’s deployment environment

Activities: – Network-component-level– Operating system-level – Application-level


Deployment and OperationsDeployment and Operations

Configuration and customization of software application’s deployment environment

Fine tuning security functionalityEvaluate entire system’s security propertiesApply additional security capabilities if

needed


Who are the attackers?Who are the attackers?

Amateurs: regular users, who exploit the vulnerabilities of the computer system– Motivation: easy access to vulnerable resources

Crackers: attempt to access computing facilities for which they do not have the authorization– Motivation: enjoy challenge, curiosity

Career criminals: professionals who understand the computer system and its vulnerabilities– Motivation: personal gain (e.g., financial)


Attacker’s KnowledgeAttacker’s Knowledge

Insider– Understand organizational data, architecture,

procedures, etc.– May understand software application– Physical access

Outsider– May not understand organizational information– May have software specific expertise– Use of tools and other resources


Vulnerability MonitoringVulnerability Monitoring

Identify security weaknessesMethods:

– Automated tools– Human walk-through– Surveillance – Audit– Background checks


System Security VulnerabilitySystem Security Vulnerability

Software installation– Default values– Configurations and settings

Monitoring usage– Changes and new resources– Regular updates

Tools– Look for known vulnerabilities


Red TeamRed 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.


Next ClassNext Class

Malicious code

Documents

CSCE 522 Secure Software Development Best Practices