| Sıra | DOSYA ADI | Format | Bağlantı |
|---|---|---|---|
| 01. | Understanding Secure Defects Securely | ppt | Sunumu İndir |
Transkript
Copyright 2007 © The OWASP FoundationPermission is granted to copy, distribute and/or modify this document under the terms of the OWASP License.The OWASP FoundationOWASPhttp://www.owasp.org Embed within SDLCModule (to be combined)Education Project
2OWASPIntroduction
3OWASPPeople / Processes / TechnologyAwarenessTrainingGuidelinesSecure DevelopmentSecure ConfigurationSecurity TestingSecure Code ReviewAutomatedTestingApplicationFirewalls
4OWASPA Few Facts and figuresRef: http://ganssle.com/Inspections.pdf Interesting Statistics – Employing code review IBM Reduces 82% of Defects Before Testing StartsHP Found 80% of Defects Found Were Not Likely To Be Caught in Testing100 Times More Expensive to Fix Security Bug at Production Than Design”– IBM Systems Sciences Institute Promoting People Looking at Code Improvement Earlier in SDLCFix at Right Place; the Source Takes 20% extra time – payoff is order of magnitude more.
5OWASPPeople Awareness and Education
6OWASPGet Buy In! Management support crucial Talk Business:Create ValueControll Risk Create CxO elevator pitches
7OWASPWeb Application Security SDLC Elevator Pitch Between 70% and 90% of web applications have serious vulnerabilities because …the average developer is still not trained well enough.… of the way they came to be. Embedding application security controls into development and deployment willAllow for higher uptime, less TCOPut YOU into risk control
8OWASPDeveloper and administrator trainingGive a man a fish and you feed him for a day;Teach a man to fish and you feed him for a lifetime.Chinese proverb Organize Developer Workshops Not only preach, but provide guidelines tuned to the environment and tools to empower the developers and administrators
9OWASPSecurity Requirements and Abuse Cases
10OWASPSecurity Requirements Security aspects must be part of the requirements The ‘business’ should be informed of certain risks Solid base for next application security controls Define Security Requirements Standards Which controls are necessary When are they necessary (applicability) Why are they necessary (e.g. SEC, SOX, etc.) Easy to use reference for requirements teams Standard method to implement each control Provide reference on how to implement
11OWASPApplication Security Requirements TailoringGet the security requirements and policy rightGeneric set of security requirementsMust include all security mechanismsMust address all common vulnerabilitiesCan be use (or misuse) casesAddress all driving requirements (regulation, standards, best practices, etc.)Tailoring examples…Specify how authentication will workDetail the access control matrix (roles, assets, functions, permissions)Define the input validation rulesChoose error handling logging approach
12OWASPAbuse CasesSource: Templates for Misuse Case Description, Sindre & Opdahl
13OWASPNegative Scenarios are Not New'Suppose it turns and charges us before it falls into the pit'Montignac Caves, Dordogne, France
14OWASPMisuse Cases Guttorm Sindre and Andreas Opdahl, 2000 Actor is a Hostile Agent Bubble is drawn in inverted colours Goal is a Threat to 'Our System‘ Input for Threat ModellingDrive the Car Steal the CarCar Thiefthreatens
15OWASPThreat Modeling
16OWASPWhy Understand the operating environment your application is heading into Identify, analyze and document (and thus hopefully mitigate) threats
17OWASPOverview assets input/output exposure (internal, external, distributed, centralized..) threat types (patterns) impact (who, how, why)
18OWASPIdentifying threats – data flow diagramsdfd, level0 contains the major processes, system boundaries .. interactions with external entities
19OWASPCategorizing and Quantifying Threats Most known: Microsoft stride, dreadspoofing, tampering, repudiation, information disclosure, denial of service, escalation of privilegesdamage potential, reproducibility, exploitability, affected users, discoverability Most important thing is that used models assist in understanding and communicating
20OWASPThreat Modeling Select mitigation strategy and techniques based on identified, documented and rated threats. Benefits:Prevent security design flaws Identify & address greatest risks Increased risk awareness and understanding Mechanism for reaching consensusCost justification and support for needed controlsMeans for communicating results
21OWASPSuccess Factors Obtain management support Involve Business and Technical experts Designate focal points Define procedures Document and maintain result
22OWASPResources http://www.octotrike.org Threat modeling book - swiderski, snyder http://blogs.msdn.com/threatmodeling/
23OWASPSecure Design Guidelines
24OWASPSecure Design Principles (*) Secure the weakest link Practice defence in depth Fail securely Follow the principle of least privilege Compartmentalize Keep it simple Promote privacy Remember that hiding secrets is hard Be reluctant to trust Use your community resources Future proof security design!(*) Building Secure Software, Viega-McGraw
25OWASPSecurity Principles Minimize attack surface area Establish secure defaults Principle of Least privilege Principle of Defense in depth Fail securely Don't trust services Separation of duties Avoid security by obscurity Keep security simple Fix security issues correctly
26OWASPDesign ReviewsBetter to find flaws earlySecurity design reviewsCheck to ensure design meets requirementsAlso check to make sure you didn’t miss a requirementAssemble a teamExperts in the technologySecurity-minded team membersDo a high-level penetration test against the designBe sure to do root cause analysis on any flaws identified
27OWASPSecure Coding Guidelines and Security Code Review
28OWASPSecure Coding Guideline Formalize best practices into secure coding guidelines well documented and enforceable coding standards Tune towards environment OWASP Secure Coding Guide can be reference can be used as a metric to evaluate source code
29OWASPCode Review Security bugs subset of implementation bugs! Static / dynamic analysis tools Requires manual inspection Threat-based Check list driven Benefits: Improves code quality Prevents security bugs Increased developer awareness and understanding
30OWASPTesting for web application security
31OWASPSoftware Vulnerability AnalysisFind flaws in the code earlyMany different techniquesStatic (against source or compiled code) Security focused static analysis tools Peer review process Formal security code reviewDynamic (against running code) Scanning Penetration testingGoalEnsure completeness (across all vulnerability areas)Ensure accuracy (minimize false alarms)
32OWASPApplication Security TestingIdentify security flaws during testingDevelop security test casesBased on requirementsBe sure to include “negative” testsTest all security mechanisms and common vulnerabilitiesFlaws feed into defect tracking and root cause analysis
33OWASPThe OWASP Testing GuideInformation GatheringBusiness Logic TestingAuthentication TestingSession Management TestingData Validation TestingDenial of Service TestingWeb Services TestingAjax TestingPart of an appsec body of knowledge…Testing PrinciplesTesting ProcessCustom Web ApplicationsBlack Box TestingGrey Box TestingRisk and ReportingAppendix: Testing ToolsAppendix: Fuzz Vectors
34OWASPSecure administration and Security within Change Management
35OWASPDeployment ProcessEnsure the application configuration is secureSecurity is increasingly “data-driven”XML files, property files, scripts, databases, directoriesHow do you control and audit this data?Design configuration data for auditPut all configuration data in CMAudit configuration data regularlyDon’t allow configuration changes in the fieldGap Development - Deployment
36OWASPApplication Security Defect Tracking and Metrics“Every security flaw is a process problem”Tracking security defectsFind the source of the problem Bad or missed requirement, design flaw, poor implementation, etc…ISSUE: can you track security defects the same way as other defectsMetricsWhat lifecycle stage are most flaws originating in?What security mechanisms are we having trouble implementing?What security vulnerabilities are we having trouble avoiding?
37OWASPDeployment WebAppSec Controls
38OWASPSoftware security tollgates in the SDLC Requirementsand use casesDesign Test plansCodeTestresultsFieldfeedbackSecurityrequirementsRiskanalysisRisk-basedsecurity testsStaticanalysis(tools)PenetrationtestingDesign ReviewIterative approachCode ReviewRisk = Threat x Vulnerability x CostWhat do we need to test,And how Code review tools
39OWASPWebAppSec Tools
40OWASPTools•Test sites / testing grounds•HTTP proxying / editing•XSS cheat sheet tools•webapp fuzzing•Encoding tools•HTTP general testing HTTP fingerprinting•Browser-based HTTP tampering / editing / replaying•Cookie editing / poisoning•Ajax and XHR scanning•RSS extensions and caching•SQL injection scanning•Threat modeling•FireFox Add-Ons•Bookmarklets•SSL certificate checking / scanning•Honeyclients, Web Application, and Web Proxy honeypots•Footprinting •Web application security malware, backdoors, and evil code•Web application assessment services•Browser-based security fuzzing / checking•PHP static analysis and file inclusion scanning•Web Application Firewall (WAF) and Intrusion Detection (APIDS) rules and resources•Web services enumeration / scanning / fuzzing•Web application non-specific static source-code analysis•Static analysis for C/C++ (CGI, ISAPI, etc) in web applications•Java static analysis, security frameworks, and web application security tools•Microsoft .NET static analysis and security framework tools,•Database security assessment•Browser Defenses•Browser Privacy•Application and protocol fuzzing
41OWASPTools http://www.owasp.org/index.php/Phoenix/Tools Best known OWASP ToolsWebGoatWebScarab Remember:A Fool with a Tool is still a Fool
42OWASPTools – At Best 45% MITRE found that all application security tool vendors’ claims put together cover only 45% of the known vulnerability types (over 600 in CWE) They found very little overlap between tools, so to get 45% you need them all (assuming their claims are true)
43OWASPTechnology Do not develop on islands, but look for organisation wide:Framework Architectures J2EE, .NETSecurity PatternsLeverage PKI, IAM initiativesVulnerability ScannersApplication level firewalls
44OWASPStarting and improving an SDLC
45OWASPOpportunities for Metrics - Secure Development Life Cycle (SDL)Secure questionsduring interviewsConcept DesignsCompleteTest plansCompleteCodeCompleteDeploy PostDeploymentThreatanalysisSecurityReviewTeam membertrainingData mutation& Least PrivTestsReview old defects Check-ins checkedSecure coding guidelinesUse toolsSecurity push/audit= on-goingLearn & RefineExternal reviewSource: MicrosoftWere software assurance activities conducted at each lifecycle phase?
46OWASPHow to Start? No Big Bang approach Trigger can be (bad) result of Web App Pen Test Assure Management buy-in:First business case!Then Bootstrap!
47OWASPBusiness Case For use throughout the lifecycle and the entire software portfolio:Contracting PhaseDevelopment PhaseDeployment/Production PhaseAudit Phase Benefits:Cost savingsRisk measurement and reductionCompliance reporting
48OWASPCost Savings Significantly reduce the costs associated with new and deployed products :A flaw that costs $1 to fix in the design and development phase will cost $100 to correct once it is deployedReduce development time and number of cyclesPatch management costsContractor and vendor costs“Removing only 50 percent of software vulnerabilities before use will reduce patch management and incident response costs by 75 percent.” (John Pescatore, Gartner)
49OWASPRisk measurement and reduction Eliminate vulnerabilities before they become liabilities Manage the risks of serious financial loss, negative publicity, legal liability, loss of contracts, erosion of market share, degraded performance or other serious business impact as a result of a failure in security Set, enforce and report that software assurance thresholds are maintained Measurable reports prove progress internally and for compliance
50OWASPCompliance Reporting Compliance reporting: Comply with legal and regulatory requirements Regularly assess risk, disclose vulnerabilities and weaknesses, and prove progress both internally and for compliance requirements Scope & application Risk assessments are mandatory for most regulations, including application vulnerability detection Example internal control frameworks: CobiT, ISO 17799 Example regulations: Basel II, FISMA (NIST 800-53), DoD 8500.2, Sarbanes-Oxley, FDA, HIPAA …
51OWASPBootStrap! Identify current way of working! Set goals and start with phased approach Compare this with security strategy (can already be set out in a secure development policy) Perform a gap analysis and proceed with process improvement cycles:Tailor to Company Culture!Driven by Risk Management! Introduce Metrics
52OWASPExamples of Application Security MetricsProcess Metrics Is a SDL Process used? Are security gates enforced? Secure application development standards and testing criteria? Security status of a new application at delivery (e.g., % compliance with organizational security standards and application system requirements). Existence of developer support website (FAQ's, Code Fixes, lessons learned, etc.)? % of developers trained, using organizational security best practice technology, architecture and processesManagement Metrics % of applications rated “business-critical” that have been tested. % of applications which business partners, clients, regulators require be “certified”. Average time to correct vulnerabilities (trending). % of flaws by lifecycle phase. % of applications using centralized security services. Business impact of critical security incidents.
53OWASPExamples of Application Security MetricsVulnerability Metrics Number and criticality of vulnerabilities found. Most commonly found vulnerabilities. Reported defect rates based on security testing (per developer/team, per application) Root cause of “Vulnerability Recidivism”. % of code that is re-used from other products/projects* % of code that is third party (e.g., libraries)* Results of source code analysis**: Vulnerability severity by project, by organization Vulnerabilities by category by project, by organization Vulnerability +/- over time by project % of flaws by lifecycle phase (based on when testing occurs)Source: * WebMethods, ** Fortify Software
54OWASPWeb Application Security Roles and Responsibilities
55OWASPGet involved Security Analyst: Get involved early in SDLC. Security is a function of the asset we want to secure, what's it worth?Understanding the information held in the application and the types of users is half the battle. Involve an analyst in the design phase and thereafter. Developer:Embrace secure application development. (Educate)Quality is not just “Does it work” Security is a measure of quality also.
56OWASPGet involved QA: Security vulnerabilities are to be considered bugs, the same way as a functional bug, and tracked in the same manner. Managers: Factor some time into the project plan for security.Consider security as added value in an application.– $1 spent up front saves $10 during development and $100 after release
57OWASPRoles Role of security architect (cross-development projects): ensure security goals are reached during all cycles of the development process create awareness within development teams, business bridge function to \IT Security\ mentor the security engineers and project leaders Role of security engineer (part of project team) SPOC within development team for all security related matters. Search for Champions!
58OWASPRound up
59OWASPWhere to start? Awareness and Training2-hour course: $100-200/seatSeeing the look on the IT VPs’ faces when they get SQL Injection: Priceless Policies and Standards Application Assessments and ReviewsGet some dataStrive to be consistent and uniform Support Development Teams
Understanding Secure Defects Securely
Yıl : 2020
Anahtar Kelimeler
Daha fazla görüntüle