DOC PREVIEW
Pitt IS 2620 - Building Security

This preview shows page 1-2-22-23 out of 23 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 23 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 23 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 23 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 23 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 23 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

1IS 2620: Developing Secure SystemsJan 30, 2007Building Security InLecture 2Building Security InLecture 2Software Securityz Renewed interestz “idea of engineering software so that it continues to function correctly under malicious attack”z Existing software is riddled with design flaws and implementation bugsz “any program, no matter how innocuous it seems, can harbor security holes”z (Check the CBI report)2Software Problemz More than half of the vulnerabilities are due to buffer overrunsz Others such as race conditions, design flaws are equally prevalent# vulnerabilities Reported by CERT/CCSoftware securityz It is about z Understanding software-induced security risks and how to manage themz Leveraging software engineering practice,z thinking security early in the software lifecylez Knowing and understanding common problemsz Designing for securityz Subjecting all software artifacts to thorough objective risk analyses and testingz It is a knowledge intensive field3Trinity of troubleBigger problem today .. And growingz Three trendsz Connectivityz Inter networkedz Include SCADA (supervisory control and data acquisition systems)z Automated attacks, botnetsz Extensibilityz Mobile code – functionality evolves incrementallyz Web/Os Extensibilityz Complexityz XP is at least 40 M lines of code z Add to that use of unsafe languages (C/C++)It boils down to …more code, more bugs, more security problems4Security problems in softwarez Defectz implementation and design vulnerabilitiesz Can remain dormantz Bugz An implementation level software problemz Flawz A problem at a deeper levelz Bugs + Flaws z leads to RiskMethod over-riding problems (subclass issues)Compartmentalization problems in designPrivileged block protection failure (DoPrivilege())Error-handling problems (fails open)Type safety confusion errorInsecure audit log designBroken or illogical access control (role-based access control [RBAC] over tiers)Signing too much codeBuffer overflow: stack smashingBuffer overflow: one-stage attacksBuffer overflow: string format attacksRace conditions: TOCTOUUnsafe environment variablesUnsafe system calls (fork(), exec(), system())Incorrect input validation (black list vs. white listFlawBugSolution …Three pillars of security5Pillar I:Applied Risk managementz Architectural risk analysisz Sometimes called threat modeling or security design analysisz Is a best practice and is a touchpointz Risk management frameworkz Considers risk analysis and mitigation as a full life cycle activityPillar II:Software Security Touchpointsz “Software security is not security software”z Software security z is system-wide issues (security mechanisms and design security)z Emergent propertyz Touchpoints in order of effectiveness (based on experience)z Code review (bugs)z Architectural risk analysis (flaws)z These two can be swappedz Penetration testingz Risk-based security testsz Abuse casesz Security requirementsz Security operations6Pillar II: (contd.)z Many organizationz Penetration firstz Is a reactive approachz CR and ARA can be switched however skipping one solves only half of the problemz Big organization may adopt these touchpointssimultaneouslyPillar II: (contd.)Software security best practices applied to various software artifacts7Pillar II: (contd.)Microsoft’s move ..Pillar II: (contd.)System-wideIssueSystem-wideIssueEmergentPropertyEmergentPropertySoftware SecuritySoftware Securityaccount forSecurity MechanismsDesign for SecurityProcess modelsApply Security Touchpoints(Process-Agnostic)Apply Security Touchpoints(Process-Agnostic)iCMMXPRUPCMMI8Pillar III:Knowledgez Involvesz Gathering, encapsulating, and sharing security knowledgez Software security knowledge catalogsz Principlesz Guidelinesz Rulesz Vulnerabilitiesz Exploitsz Attack patternsz Historical risksCan be put into three categoriesPrescriptive knowledgeDiagnostic knowledgeHistorical knowledgePillar III: Knowledge catalogs to s/w artifacts9Risk management framework:Five Stagesz RMF occurs in parallel with SDLC activitiesUnderstand the BusinesscontextUnderstand the BusinesscontextIdentify the Businessand Technical RiskIdentify the Businessand Technical RiskArtifact AnalysisSynthesize andRank the RisksSynthesize andRank the RisksDefine the RiskMitigation StrategyDefine the RiskMitigation StrategyCarry out fixes And validateCarry out fixes And validateBusinessContext12345Measurement and reportingStage 1: Understand Business Contextz Risk managementz Occurs in a business contextz Affected by business motivationz Key activity of an analystz Extract and describe business goals – clearlyz Increasing revenue; reducing dev cost; meeting SLAs; generating high return on investment (ROI)z Set prioritiesz Understand circumstancesz Bottomline – answer the question z who cares?10Stage 2: Identify the business & technical risksz Business risks have impactz Direct financial loss; loss of reputation; violation of customer or regulatory requirements; increase in development costz Severity of risksz Should be capture in financial or project management termsz Key is –z tie technical risks to business contextStage 3: Synthesize and rank the risksz Prioritize the risks alongside the business goalsz Assign risks appropriate weights for resolutionz Risk metricsz Risk likelihoodz Risk impactz Number of risks mitigated over time11Stage 4: Risk Mitigation Strategyz Develop a coherent strategy z For mitigating risksz In cost effective manner; account for Cost Implementation time CompletenessImpact Likelihood of successz A mitigation strategy shouldz Be developed within the business contextz Be based on what the organization can afford, integrate and understandz Must directly identify validation techniques Stage 5: Carry out Fixes and Validatez Execute the chosen mitigation strategyz Rectify the artifactsz Measure completenessz Estimatez Progress, residual risksz Validate that risks have been mitigatedz Testing can be used to demonstratez Develop confidence that unacceptable risk does not remain12RMF - A Multi-loopz Risk management is a continuous processz Five stages may need to be applied many timesz Ordering may be interleaved in different waysz Risk can emerge at any time in SDLC One way – apply in each phase of SDLCz Risk can be found between stagesz Level of applicationz Primary – project levelz Each stage must capture complete projectz SDLC phase levelz Artifact levelz It is important to know that RM isz Cumulativez At times


View Full Document

Pitt IS 2620 - Building Security

Download Building Security
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Building Security and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Building Security 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?