test 1 review

CSCE 548 CSCE 548 Secure Software Secure Software

DevelopmentDevelopment

Test 1 -- ReviewTest 1 -- Review

CSCE 548 - Farkas 2

ReadingReading Test 1

– McGraw: Software Security: Chapters 1 -- 9– Software reliability, John C. Knight, Nancy G. Leveson, An

Experimental Evaluation Of The Assumption Of Independence In Multi-Version Programming, http://citeseer.ist.psu.edu/knight86experimental.html

– B. Littlewood, P. Popov, L. Strigini, "Modelling software design diversity - a review", ACM Computing Surveys, Vol. 33, No. 2, June 2001, pp. 177-208, http://portal.acm.org/citation.cfm?doid=384192.384195

CSCE 548 - Farkas 3

Test 1Test 1

Closed bookFrom reading materials on previous slide1 hour and 15 minutesNo multiple choice questions

CSCE 548 - Farkas 4

Software Security Software Security

NOT security software!Engineering software so that it continues to

function correctly under malicious attack– Functional requirements– Non-functional requirements (e.g., security)

CSCE 548 - Farkas 5

Why Software?Why Software?

Increased complexity of software productIncreased connectivityIncreased extensibility

Increased risk of security violations!

CSCE 548 - Farkas 6

Security ProblemsSecurity Problems

Defects: implementation and design vulnerabilities Bug: implementation-level vulnerabilities (Low-

level or mid-level)– Static analysis tool

Flaw: subtle, not so easy to detect problems– Manual analysis– Automated tools (for some but not design level)

Risk: probability x impact

CSCE 548 - Farkas 7

Application vs. Software SecurityApplication vs. Software Security

Usually refers to security after the software is built– Adding more code does not

make a faulty software correct– Sandboxing – Network-centric approach

Application security testing: badness-ometer

Deep Trouble

Who Knows

CSCE 548 - Farkas 8

Three Pillars of Software SecurityThree Pillars of Software Security

Risk ManagementSoftware Security TouchpointsKnowledge

CSCE 548 - Farkas 9

Risk ManagementRisk Management

CSCE 548 - Farkas 10

Risk AssessmentRisk Assessment

RISKRISK

Threats

Vulnerabilities Consequences


Risk Management Framework(Business Context)

Understand BusinessContext

Identify Business and Technical Risks

Synthesize and RankRisks

Define RiskMitigation Strategy

Carry Out Fixesand Validate

Measurement and Reporting


Assets-Threat Model (1)

Threats compromise assets

Threats have a probability of occurrence and severity of effect

Assets have values

Assets are vulnerable to threats

Threats Assets


Risk Acceptance

Certification How well the system meet the security

requirements (technical)

Accreditation Management’s approval of automated system

(administrative)


Building It SecureBuilding It Secure

1960s: US Department of Defense (DoD) risk of unsecured information systems

1970s: – 1977: DoD Computer Security Initiative– US Government and private concerns – National Bureau of Standards (NBS – now NIST)

Responsible for standards for acquisition and use of federal computing systems

Federal Information Processing Standards (FIPS PUBs)


Software Security Touchpoints


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


When to Apply Security? When to Apply Security? Economical consideration: early is better Effectiveness of touchpoints:

– Economics– Which software artifacts are available– Which tools are available– Cultural changes

Bad: reactive strategy need: secure development

See slides of Kromholz: Assurance – A Case for the V-Model, https://syst.eui.upm.es/conference/sv03/papers/V-Chart%20200309Kromholz08.ppt


Best PracticesBest Practices

Earlier the betterChange “operational” view to secure

softwareBest practices: expounded by experts and

adopted by practitioners


Who Should Care?Who Should Care?

DevelopersArchitectsOther buildersOperations people

Do not start with security people.Start with software people.


Architectural Risk AnalysisArchitectural Risk Analysis


Design FlawsDesign Flaws

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

and concerns to businessContinuous risk management


Security Risk AnalysisSecurity Risk Analysis

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

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


Security Risk AnalysisSecurity Risk Analysis

Learn about the target of analysisDiscuss security issuesDetermine probability of compromisePerform impact analysisRank risksDevelop mitigation strategyReport findings


Knowledge RequirementsKnowledge Requirements

Three basic steps:– Attack resistance analysis

Attack patterns and exploit graphs

– Ambiguity analysis Knowledge of design principles

– Weakness analysis Knowledge of security issues

Forest-level view: What does the software do?– Critical components and interaction between them– Identify risk related to flaws


Modern Risk AnalysisModern Risk 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”


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


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.


Use CasesUse CasesMisuse CasesMisuse Cases


SecureUMLSecureUML

Model-driven software development integrated with security

Advantages: – Security is integrated during software design, using

high-level of abstraction– Modeling information can be used to detect design

errors and verify correctness

Limitations: need precise semantics of modeling language for security assurance


SecureUMLSecureUML

Defines vocabulary for annotating UML-based models with access control information

Metamodel: abstract syntax of the language UML Profile: notation to enhance UML class

model Host language: an other modeling language that

uses SecureUML SecureUML dialect: SecureUML specifications

are refined in the host language – E.g., syntactic elements of the modeling language are

transformed into constructs of the target platform


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


Penetration TestingPenetration Testing


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


Risk-Based Security TestingRisk-Based Security Testing


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


Risk-Based TestingRisk-Based Testing

Identify risksCreate tests to address identified risksSecurity testing vs. penetration testing

– Level of approach– Timing of testing


Security TestingSecurity Testing

Can be applied before the product is completed

Different levels of testing (e.g., component/unit level vs. system level)

Testing environmentDetailed


Who Should Perform the Test?Who Should Perform the Test?

Standard testing organizations– Functional testing

Software security professionals– Risk-based security testing– Important: expertise and experience


How to Test?How to Test?

White box analysis– Understanding and analyzing source code and design– Very effective finding programming errors– Can be supported by automated static analyzer– Disadvantage: high rate of false positives

Black box analysis– Analyze a running program– Probe the program with various input (malicious input)– No need for any code – can be tested remotely


Security OperationsSecurity Operations


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


SANS: Secure Programming SANS: Secure Programming Skills AssessmentSkills Assessment

Aims to improve secure programming skills and knowledge

Allow employers to rate their programmers Allow buyers of software and systems vendors to

measure skills of developers Allow programmers to identify their gaps in secure

programming knowledge Allow employers to evaluate job candidates and

potential consultants Provide incentive for universities to include secure

coding in their curricula


Independence in Independence in Multiversion ProgrammingMultiversion Programming


Multi-Version ProgrammingMulti-Version Programming

N-version programmingGoal: increase fault toleranceSeparate, independent development of

multiple versions of a softwareVersions executed parallel

– Identical input Identical output ?– Majority vote


Separate DevelopmentSeparate Development

At which point of software development?– Common form of system requirements document– Voting on intermediate data

Rammamoorthy et al. – Independent specifications in a formal specification

language – Mathematical techniques to compare specifications

Kelly and Avizienis– Separate specifications written by the same person– 3 different specification languages


DifficultiesDifficulties

How to isolate versionsHow to design voting algorithms


Advantages of N-VersioningAdvantages of N-Versioning

Improve reliability Assumption: N different versions will fail

independently Outcome: probability of two or more versions

failing on the same input is small

If the assumption is true, the reliability of the system could be higher than

the reliability of the individual components


Is the assumption TRUE?


False?False?

People tend to make the same mistakesCommon design faultsCommon Failure Mode Analysis

– Mechanical systems– Software system


How to Achieve Reliability?How to Achieve Reliability?

Need independence– Even small probabilities of coincident errors

cause substantial reduction in reliability– Overestimate reliability

Crucial systems– Aircrafts– Nuclear reactors– Railways


Testing of Critical Software Testing of Critical Software SystemsSystems

Dual programming:– Producing two versions of the software– Executing them on large number of test cases– Output is assumed to be correct if both versions

agree– No manual or independent evaluation of correct

output – expensive to do so– Assumption: unlikely that two versions contain

identical faults for large number of test cases


VotingVoting

Individual software versions may have low reliability

Run multiple versions and vote on “correct” answer

Additional cost: voting processs


Common Assumption:

Low probability of common mode failures

(identical, incorrect output generated from the same input)


IndependenceIndependence

Assumed and not tested– Two versions were assumed to be correct if the two

outputs for the test cases agree

Test for common errors but not for independence– Kelly and Avizienis: 21 related and 1 common fault –

nuclear reactor project– Taylor: common faults in European practical systems

Need evaluation/testing of independence

test 1 review

Documents

security software

level risk

risk analysis exercises

architectural risk analysis

security people

risk analysis external

risk quantifying impact

software people