Test 1 Review
-
Upload
softwarecentral -
Category
Documents
-
view
656 -
download
2
description
Transcript of 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
CSCE 548 - Farkas 11
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
CSCE 548 - Farkas 12
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
CSCE 548 - Farkas 13
Risk Acceptance
Certification How well the system meet the security
requirements (technical)
Accreditation Management’s approval of automated system
(administrative)
CSCE 548 - Farkas 14
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)
CSCE 548 - Farkas 15
Software Security Touchpoints
CSCE 548 - Farkas 16
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 548 - Farkas 17
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
CSCE 548 - Farkas 18
Best PracticesBest Practices
Earlier the betterChange “operational” view to secure
softwareBest practices: expounded by experts and
adopted by practitioners
CSCE 548 - Farkas 19
Who Should Care?Who Should Care?
DevelopersArchitectsOther buildersOperations people
Do not start with security people.Start with software people.
CSCE 548 - Farkas 20
Architectural Risk AnalysisArchitectural Risk Analysis
CSCE 548 - Farkas 21
Design FlawsDesign Flaws
50 % of security problemsNeed: explicitly identifying riskQuantifying impact: tie technology issues
and concerns to businessContinuous risk management
CSCE 548 - Farkas 22
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 548 - Farkas 23
Security Risk AnalysisSecurity Risk Analysis
Learn about the target of analysisDiscuss security issuesDetermine probability of compromisePerform impact analysisRank risksDevelop mitigation strategyReport findings
CSCE 548 - Farkas 24
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
CSCE 548 - Farkas 25
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”
CSCE 548 - Farkas 26
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 548 - Farkas 27
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
CSCE 548 - Farkas 28
Weakness AnalysisWeakness Analysis
Understanding the impact of external software dependencies– Middleware– Outside libraries– Distributed code– Services– Physical environment– Etc.
CSCE 548 - Farkas 29
Use CasesUse CasesMisuse CasesMisuse Cases
CSCE 548 - Farkas 30
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
CSCE 548 - Farkas 31
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
CSCE 548 - Farkas 32
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 548 - Farkas 33
Penetration TestingPenetration Testing
CSCE 548 - Farkas 34
CSCE 548 - Farkas 35
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)
CSCE 548 - Farkas 36
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
CSCE 548 - Farkas 37
Penetration Testing TodayPenetration Testing Today
Often performedApplied to finished productsOutside in approachLate SDLC activityLimitation: too little, too late
CSCE 548 - Farkas 38
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
CSCE 548 - Farkas 39
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
CSCE 548 - Farkas 40
Risk-Based Security TestingRisk-Based Security Testing
CSCE 548 - Farkas 41
Quality AssuranceQuality Assurance
External quality: correctness, reliability, usability, integrity
Interior (engineering) quality: efficiency, testability, documentation, structure
Future (adaptability) quality: flexibility, reusability, maintainability
CSCE 548 - Farkas 42
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
CSCE 548 - Farkas 43
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
CSCE 548 - Farkas 44
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.
CSCE 548 - Farkas 45
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)
CSCE 548 - Farkas 46
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
CSCE 548 - Farkas 47
Risk-Based TestingRisk-Based Testing
Identify risksCreate tests to address identified risksSecurity testing vs. penetration testing
– Level of approach– Timing of testing
CSCE 548 - Farkas 48
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
CSCE 548 - Farkas 49
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
CSCE 548 - Farkas 50
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
CSCE 548 - Farkas 51
Security OperationsSecurity Operations
CSCE 548 - Farkas 52
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
CSCE 548 - Farkas 53
Deployment and OperationsDeployment and Operations
Configuration and customization of software application’s deployment environment
Activities: – Network-component-level– Operating system-level – Application-level
CSCE 548 - Farkas 54
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
CSCE 548 - Farkas 55
Independence in Independence in Multiversion ProgrammingMultiversion Programming
CSCE 548 - Farkas 56
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
CSCE 548 - Farkas 57
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
CSCE 548 - Farkas 58
DifficultiesDifficulties
How to isolate versionsHow to design voting algorithms
CSCE 548 - Farkas 59
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
CSCE 548 - Farkas 60
Is the assumption TRUE?
CSCE 548 - Farkas 61
False?False?
People tend to make the same mistakesCommon design faultsCommon Failure Mode Analysis
– Mechanical systems– Software system
CSCE 548 - Farkas 62
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
CSCE 548 - Farkas 63
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
CSCE 548 - Farkas 64
VotingVoting
Individual software versions may have low reliability
Run multiple versions and vote on “correct” answer
Additional cost: voting processs
CSCE 548 - Farkas 65
Common Assumption:
Low probability of common mode failures
(identical, incorrect output generated from the same input)
CSCE 548 - Farkas 66
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