slides

CSCE 522 CSCE 522 Secure Software DevelopmentSecure Software Development

Best PracticesBest Practices

CSCE 522 - Farkas 2

ReadingReading

This lecture: Jan Jürjens, Towards Development of Secure

Systems using UMLsec, http://citeseer.ist.psu.edu/536233.html

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

Design FlawsDesign Flaws

50 % of security problemsNeed: explicitly identifying riskQuantifying impact: tie technology issues

and concerns to businessContinuous risk management

CSCE 522 - Farkas 5

Security Risk AnalysisSecurity Risk Analysis

Risk analysis: identifying and ranking risksRisk management: performing risk analysis

exercises, tracking risk, mitigating risksNeed: understanding of business impact

CSCE 522 - Farkas 6

Risk AnalysisRisk Analysis

Address risk as early as possible in the requirements level

Impact:– Legal and/or regulatory risk– Financial or commercial considerations– Contractual considerations

Requirements: “must-haves,” “important-to-have,” and “nice-but-unnecessary-to-have”

CSCE 522 - Farkas 7

Basic Risk AnalysisBasic Risk Analysis

Tailored for specific vulnerabilitiesHigh-level overviewMeaningful resultsCross-tier analysis – different trust zonesUse of deployment patternDecomposing software on a component-by-

component basis

CSCE 522 - Farkas 8

Risk Analysis PracticeRisk Analysis Practice

Ad-hoc mannerDoes not scale and not repeatable or

consistentDepends on knowledge and expertise of

analystResults are difficult to compare

CSCE 522 - Farkas 9

Attack Resistance AnalysisAttack Resistance Analysis

Information about known attacks, attack patterns, and vulnerabilities – known problems– Identify general flaws: using secure design literature

and checklists– Map attack patterns: based on abuse cases and attack

patterns– Identify risk in the architecture: using checklist– Understand and demonstrate the viability of known

attacks

CSCE 522 - Farkas 10

Ambiguity AnalysisAmbiguity Analysis

Discover new risksParallel activities of team members unify

understanding– Private list of possible flaws– Describe together how the system worked

Need a team of experienced analysts


Weakness AnalysisWeakness Analysis

Understanding the impact of external software dependencies– Middleware– Outside libraries– Distributed code– Services– Physical environment– Etc.







5. Abuse cases


2. Risk Analysis

External Review



2. Risk Analysis




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


Software Vendor AccountabilitySoftware Vendor Accountability

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


Checking for Known Checking for Known VulnerabilitiesVulnerabilities

Need toolPossible attacks and attack typesHow the software behaves if something

goes WRONGWhat motivates an attacker?


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


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


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







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







5. Abuse cases


2. Risk Analysis

External Review



2. Risk Analysis




Software TestingSoftware Testing

Running a program or system with the intent of finding errors

Evaluating capability of the system and determining that its requirements

Physical processes vs. Software Testing purposes

– To improve quality– For Verification & Validation (V&V) – For reliability estimation


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

slides

Documents

risk analysis address

risk analysis exercises

basic risk analysis

risk analysis external

riskbasedsecurity tests

risk analysis practice

security requirements

security testing