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
Information Security Axioms “Security is combination of confidentiality, integrity and availability” [ITSEC91] “Security is a process, not a product!” [Bruce Schneier] “Software Security is not Security Software” [Gary McGraw] “Security is everybody’s problem” “Inside attacks are more powerful than externals”
What is Information Security? The protection of information and its critical elements, including systems and hardware that use, store, and transmit that information Necessary tools: policy, awareness, training, education, technology
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 security recovery planning Legal and regulatory Cryptography compliance Security Architecture & Physical/environmental Design security
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
HOW: Security Base PrinciplesTo respect core principles we need: Identification: “is how a user tells a system who he or she is (for example, by using a username or User ID); Authentication: “is the process of verifying a users claimed identity (for example, by comparing an entered password to the password stored on a system for a given username).”; Authorization: “defines a users rights and permissions on a system. After a user (or process) is authenticated, authorization determines what that user can do on the system.”; Auditing: “an evaluation of an organization, system, process, project or product”.
Business Drivers Security is less expensive to implement if it is planned from the beginning Building security controls into the system, rather than adding them after the system is already built improves system performance Security becomes an enabling factor rather than a barrier to success by reducing the need for expensive reengineering and reprogramming It ensures success of certification and accreditation processes and keeps the project on schedule
HOW: Secure SDLCWaterfall Model (old paradigm) Iterative Model (new paradigm)
Excuses to underestimate security in the SDLC “Weve reviewed the code, and there are no security bugs.” “We know its the default, but the administrator can turn 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….”
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.”
Web Application Security SDLC Elevator PitchBetween 70% and 90% of web applications have serious vulnerabilities because …the average developer is still not trained well enough.Embedding application security controls into development and deployment will Allow for higher uptime, less TCO Put YOU into risk control
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
Software Security Guidelines Security Usability: what to do: security should impact minimally on system usability; why: applications that are too secure are not usable and will not be used; how: all security features have to be balanced with usability factors; Use “least privileges principle”: what to do: every application should be executed with minimum privileges to execute its tasks; why: least privileges principle limits the dangerousness of an application vulnerability exploitation; how: check and set only applications needed privileges;
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;
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;
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?
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 Requirements Analysis and Control Security Assurance Requirements – Continuous Monitoring Analysis Disposition Cost Considerations Security Control Development – Information Preservation Developmental Security Test and – Media Sanitization Evaluation – Hardware and Software Acquisition specifications Disposal
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
Initiation PhaseRisk Assessment Risk assessment is the process of analyzing threats to an information system and known vulnerabilities to determine the likelihood and impact of some anticipated loss. This risk analysis can then be used to design protective security controls that reduce these factors to acceptable levels. Pre-requisite to Risk Assessment is system categorization
Initiation PhaseRisk Assessment Part of a greater process called Risk Management. Risk Management begins with Risk Assessment and then moves into protecting the information system with Risk Mitigation (through security controls) and closes out with Evaluation and Assessment to confirm that the Risk Management process is actually working.
Initiation PhaseVulnerability Identification A vulnerability is a weakness in a system or its protections that could be exercised, creating a breach in the security protection of the system. The goal of this step is to come up with a list of vulnerabilities that could be exercised by potential threat sources. Vulnerabilities can be identified from lists and advisories on common vulnerabilities and also by testing the system.
Initiation PhaseVulnerability lists Databases – NIST National Vulnerability Database Vendor advisories – Google directory of computer security advisories 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
Requirements Analysis Used to identify the systems protection requirements through the use of a formal risk assessment process. Generates essential information needed to complete the system security plan. The risk assessment includes the following: Identification of threats and vulnerabilities The potential impact or magnitude of harm that a loss of confidentiality, integrity, or availability would have on assets, operations, image, reputation should there be a thereat of exploitation Consider potential inheritance of vulnerabilities from other systems
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 this phase of the SDLC progresses
Threat Modeling Understand the operating environment your application is heading into Identify, analyze and document (and thus hopefully mitigate) threats34
Threats Natural threats Criminal Storms Bribery, extortion System intrusion Floods Data compromise Tornadoes Terrorist Hurricanes Bribery, extortion Electrical storms System intrusion Earthquakes Data compromise Slides Information warfare Landslide System disruption Organizational disruption Avalanche Industrial espionage Temperature extremes System intrusion Environmental threats Data compromise Power failures Organizational disruption Human threats Insiders Unintentional System intrusion Data compromise Data compromise Intentional Organizational disruption Hacker/cracker System intrusion Defacement Data compromise
Identifying threats – data flow diagrams contains the major processes, system boundaries .. interactions with external entities36
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
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
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
Design Reviews Better to find flaws early Security design reviews Check to ensure design meets requirements Also check to make sure you didn’t 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
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
The OWASP Testing Guide Part of an appsec body of knowledge…Testing Principles Information GatheringTesting Process Business Logic TestingCustom Web Applications Authentication Testing Black Box Testing Session Management Testing Grey Box Testing Data Validation TestingRisk and Reporting Denial of Service TestingAppendix: Testing Tools Web Services TestingAppendix: Fuzz Vectors Ajax Testing43
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
Operations and MaintenancePhase Establishing a change control process. Continuous Monitoring Application Vulnerability Scanning Penetration Testing
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?
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)