1. Ron ClementCISSP,MCSE,CCNA,CCAI,Security+

2. Information Security & the SDLC Information Security Principles Secure Software Development Life Cycle Touch points Risk Management Security Requirements Software Security Guidelines Threat Modeling Security Design Code Reviews Disposition Conclusion 3. Information Security Axioms Security is combination of confidentiality,integrity and availability [ITSEC91] Security is a process, not a product! [BruceSchneier] Software Security is not Security Software [GaryMcGraw] Security is everybodys problem Inside attacks are more powerful than externals 4. What is Information Security? The protection of information and its critical elements,including systems and hardware that use, store, andtransmit that information Necessary tools: policy, awareness, training, education,technology 5. Information Security DomainsA successful organization should have multiple layers of security inplace: Access control Operations security Network security Business continuity Risk management planning and disaster Applications securityrecovery planning Legal and regulatory Cryptographycompliance Security Architecture & Physical/environmentalDesign security 6. Security Core PrinciplesConfidentiality: "Preserving authorized restrictions on informationaccess and disclosure, including means for protecting personal privacyand proprietary information" A loss of confidentiality is theunauthorized disclosure of Information. [F199-04]Integrity: "Guarding against improper information modification ordestruction, and includes ensuring information non-repudiation andauthenticity" A loss of integrity is the unauthorized modification ordestruction of information. [F199-04]Availability: "Ensuring timely and reliable access to and use ofinformation" A loss of availability is the disruption of access to or use ofinformation or an information system. [F199-04]Usability: is a term used to denote the ease with which people canemploy a particular tool or other human-made object in order toachieve a particular goal. Usability can also refer to the methods ofmeasuring usability and the study of the principles 7. HOW: Security Base Principles 8. HOW: Security Base PrinciplesTo respect core principles we need: Identification: is how a user tells a system who he or sheis (for example, by using a username or User ID); Authentication: is the process of verifying a usersclaimed identity (for example, by comparing an enteredpassword to the password stored on a system for a givenusername).; Authorization: defines a users rights and permissions ona system. After a user (or process) is authenticated,authorization determines what that user can do on thesystem.; Auditing: an evaluation of an organization, system,process, project or product. 9. Business Drivers Security is less expensive to implement if it isplanned from the beginning Building security controls into the system, ratherthan adding them after the system is already builtimproves system performance Security becomes an enabling factor rather than abarrier to success by reducing the need for expensivereengineering and reprogramming It ensures success of certification and accreditationprocesses and keeps the project on schedule 10. HOW: Secure SDLCWaterfall Model (old paradigm) Iterative Model (new paradigm) 11. HOW: Secure SDLC 12. HOW: Secure SDLC 13. How: Secure SDLC 14. HOW: SSDLC Phases Start Analysis: security requirements, risk analysis, threat identification, threat impact probability, abuse cases and UML (unified modeling language) for software security, usability guidelines, traditional SDLC analysis; Design: risk analysis, UML for Software Security, usability guidelines, traditional SDLC design; Development: secure coding, risk based security tests, static analysis, traditional SDLC development; Test: risk analysis, penetration test (black- or white-box approach), risk mitigation, traditional SDLC test; Maintenance: risk analysis, penetration test, traditional SDLC maintenance. Back to start! 15. How: SSDLC tools and methodologies Software Security Tools: Analysis and Design: SecureUML, UMLSec; Static Analysis tools: FindBugs, OWASP CLASP, SLAM, Blast , RATS; Security Methodologies: Cigital Risk Analysis Methodology; OSSTMM - Open Source Security Testing Methodology Manual; OWASP Testing guide; 16. Software Risk ManagementSoftware Risk Software Risk AnalysisManagementSoftware Risk Mitigation 17. Excuses to underestimate security in the SDLC Weve reviewed the code, and there are no securitybugs.We know its the default, but the administrator canturn it off.If we dont run as administrator, stuff breaks. But well slip the schedule.Its not exploitable.But thats the way weve always done it.If only we had better tools. 18. Excuses to underestimate security in the SDLC No one will do that! Why would anyone do that? Weve never been attacked. Were secure, we use cryptography. Were secure, we use ACLs. Were secure, we use a firewall. 19. Web Application Security SDLC Elevator PitchBetween 70% and 90% of web applications have serious vulnerabilities becausethe average developer is still not trained well enough.Embedding application security controls into development and deployment willAllow for higher uptime, less TCOPut YOU into risk control 20. Major Vulnerabilities in theApplication Space A1 Injection A2 Cross Site Scripting (XSS) A3 Broken Authentication and Session Management A4 Insecure Direct Object References A5 Cross Site Request Forgery (CSRF) A6 Security Misconfiguration (NEW) A7 Failure to Restrict URL Access A8 Unvalidated Redirects and Forwards (NEW) A9 Insecure Cryptographic Storage A10 Insufficient Transport Layer ProtectionOWASP Top 10 - 2010 21. Software Security Guidelines Security Usability: what to do: security should impact minimally on systemusability; why: applications that are too secure are not usable andwill not be used; how: all security features have to be balanced withusability factors; Use least privileges principle: what to do: every application should be executed withminimum privileges to execute its tasks; why: least privileges principle limits the dangerousness ofan application vulnerability exploitation; how: check and set only applications needed privileges; 22. Software Security Guidelines Confidentiality: what to do: personal information must be protected; why: unauthorized users should not access to confidential information; how: data and channel encryption; Identification, Authorization and Authentication guidelines; Integrity: what to do: protect application data from corruption activities; why: data is the highest value asset in Information Systems; how: use good access control policy and respect Identification, Identification, Authorization and Authentication guidelines; Availability: what to do: ensure applications are always available for the users tasks and goals; why: mission critical application have to be always available; how: try to disconnect resources as network, peripherals, etc. and test applications; Identification, Authorization and Authentication guidelines; 23. Software Security Guidelines Identification & Authentication: what to do: identify and authenticate users or system to implement access control policies; why: identification and authentication are needed for the Authentication phase; how: something you: Know (1F*); Have (2F*); Are (3F*); Do (4F*); Authorization: what to do: authorize a user to use only objects he or she should use; why: authorization is needed for the Integrity of data and systems; how: adopt well-known access control policy as MAC, RBAC, DAC; Auditing & Logging: what to do: monitor applications activities; why: logs are useful to track activities and to detect errors and flaws; how: ensure auditing aspects are activated on the system; 24. Security Requirements to consider...Internally or externally hosted?Web-facing?Data Classification?Non-Public Information? (NPI)Data Flow?Third Party Access?Third Party Reviews? SAS-70?Related Entity Access?Legal /Regulatory Requirements? (PCI, GLBA, SOX,SEC, OCC, etc)Public Access?Virtualization / Cloud Computing?Downstream Liability?Backup Requirements?Data offsite/Offshore/International? 25. Security Tasks In the SDLC Initiation Implementation Needs Determination Inspection and Acceptance Security Categorization System Integration Risk Assessment Certification & Accreditation Development/Acquisition Operations & Maintenance Risk Assessment Configuration Management Security Functional RequirementsAnalysis and Control Security Assurance Requirements Continuous MonitoringAnalysis Disposition Cost Considerations Security Control Development Information Preservation Developmental Security Test and Media SanitizationEvaluation Hardware and Software Acquisition specificationsDisposal 26. Initiation Phase 27. Initiation PhaseSystem Categorization System Description Need, purpose and mission Functional requirements Policy and architecture Network topology Information flow Security controls (either planned or already implemented) Physical and environmental security Boundary analysis and interconnections Component inventory Hardware Software External interfaces to other systems Data People 28. Initiation PhaseRisk Assessment Risk assessment is the process of analyzing threats toan information system and known vulnerabilities todetermine the likelihood and impact of someanticipated loss. This risk analysis can then be used todesign protective security controls that reduce thesefactors to acceptable levels. Pre-requisite to Risk Assessment is systemcategorization 29. Initiation PhaseRisk Assessment Part of a greater process called Risk Management. Risk Management begins with Risk Assessment andthen moves into protecting the information systemwith Risk Mitigation (through security controls) andcloses out with Evaluation and Assessment to confirmthat the Risk Management process is actually working. 30. Initiation PhaseVulnerability Identification A vulnerability is a weakness in a system or itsprotections that could be exercised, creating a breachin the security protection of the system. The goal ofthis step is to come up with a list of vulnerabilities thatcould be exercised by potential threat sources. Vulnerabilities can be identified from lists andadvisories on common vulnerabilities and also bytesting the system. 31. Initiation PhaseVulnerability lists Databases NIST National Vulnerability Database Vendor advisories Google directory of computer securityadvisories and patches CIRT lists and bulletins US-CERT SANS Top 20 SANS Internet Storm CenterSystem testing Vulnerability scanning Penetration testing Security controls assessment Previous risk assessment documentation 32. Requirements Analysis Used to identify the systems protection requirementsthrough the use of a formal risk assessment process. Generates essential information needed to complete thesystem security plan. The risk assessment includes the following: Identification of threats and vulnerabilities The potential impact or magnitude of harm that a loss ofconfidentiality, integrity, or availability would have on assets,operations, image, reputation should there be a thereat ofexploitation Consider potential inheritance of vulnerabilities from othersystems 33. Security Functional Requirements Analysis Analysis should include laws and regulations such as: Privacy act PCI SOX GLBA Other regulations More than one risk assessment may be required as thisphase of the SDLC progresses 34. Threat Modeling Understand the operating environment your application is heading into Identify, analyze and document (and thus hopefully mitigate) threats34 35. Threats Natural threats Criminal Storms Bribery, extortion System intrusion Floods Data compromise Tornadoes Terrorist Hurricanes Bribery, extortion Electrical storms System intrusion EarthquakesData compromise Slides Information warfare Landslide System disruption Organizational disruption Avalanche Industrial espionage Temperature extremes System intrusion Environmental threatsData compromise Power failuresOrganizational disruption Human threats Insiders Unintentional System intrusion Data compromiseData compromise Intentional Organizational disruption Hacker/cracker System intrusion Defacement Data compromise 36. Identifying threats data flow diagrams contains the major processes, system boundaries .. interactions with external entities36 37. Categorizing and Quantifying Threats Most known: Microsoft stride, dread spoofing, tampering, repudiation, information disclosure, denial of service, escalation of privileges damage potential, reproducibility, exploitability, affected users, discoverability37 38. Threat 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 consensus Cost justification and support for needed controls Means for communicating results38 39. Secure 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-McGraw39 40. Design Reviews Better to find flaws early Security design reviews Check to ensure design meets requirements Also check to make sure you didnt miss a requirement Assemble a team Experts in the technology Security-minded team members Do a high-level penetration test against the design Be sure to do root cause analysis on any flaws identified40 41. Secure 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 code41 42. Code 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 understanding42 43. The OWASP Testing Guide Part of an appsec body of knowledgeTesting PrinciplesInformation GatheringTesting Process Business Logic TestingCustom Web Applications Authentication Testing Black Box TestingSession Management Testing Grey Box Testing Data Validation TestingRisk and ReportingDenial of Service TestingAppendix: Testing Tools Web Services TestingAppendix: Fuzz VectorsAjax Testing43 44. Application Security Principles Minimize attack surface area Establish secure defaults Principle of Least privilege Principle of Defense in depth Fail securely Dont trust services Separation of duties Avoid security by obscurity Keep security simple Fix security issues correctly44 45. Operations and MaintenancePhase Establishing a change control process. Continuous Monitoring Application Vulnerability Scanning Penetration Testing 46. Disposal Phase Without correctly finishing up, all the previous defensive measures can be wasted. The following steps are taken to ensure correct disposal: Information preservation Media Sanitization Hardware and software disposal How is equipment/software retired? 47. Review/Conclusion Information Security Principles Secure Software Development Life Cycle Touch points Risk Management Security Requirements Software Security Guidelines Threat Modeling Security Design Code Reviews Disposition 48. References[AHM04] A. Anton, P. Hope, G. McGraw, Misuse and Abuses Cases: Getting Past the Positive, IEEESecurity & Privacy, March 2004;[CA06] Curphey, Araujo, Web Application Security Assessment Tools, IEEE Security and Privacyarchive, Volume 4 , Issue 4 (July 2006)[CM04] B. Chess, G. McGraw, Static Analysis for Security, IEEE Security & Privacy, December2004;[ITSEC91] Information Technology Security Evaluation Criteria, Commission EuropeanCommunities, 1991;[F199-04] Federal Information Processing Standard (fips) 199, Standards for securitycategorization of federal information and information systems, 2004[GW03] M.G. Graff, K.R. van Wyk, Secure Coding: Principles & Practices, OReillyPub, 2003;[LH03] D. Le Blanc, M. Howard, Writing secure code 2, Microsoft Press, 2003;[M04] G. McGraw, Software Security, IEEE Security & Privacy, February 2004;[MP04] G. McGraw, B. Potter, Software Security Testing, IEEE Security & Privacy, May 2004;[MV04] G. McGraw, D. Verdon, Risk Analysis in Software Design, IEEE Security & Privacy, April2004;[NIST04] NIST, Security Considerations in the Information SDLC, SP 800-64 Rev. 1, 2004;[V04] Vaclav Rajlich, Changing the paradigm of software engineering,Communications of theACM archive,Volume 49 , Issue 8 (August 2006)