Information Security and the SDLC

Ron ClementCISSP,MCSE,CCNA,CCAI,Security+

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 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)

HOW: Secure SDLC

How: Secure SDLC

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!

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;

Software Risk Management Software Risk Software Risk Analysis Management Software Risk Mitigation

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 PitchBetween 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 Phase

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

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

The OWASP Testing Guide Part of an appsec body of knowledge…Testing Principles Information GatheringTesting Process Business Logic TestingCustom Web Applications Authentication Testing Black Box Testing Session Management Testing Grey Box Testing Data Validation TestingRisk and Reporting Denial of Service TestingAppendix: Testing Tools Web Services TestingAppendix: 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?

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

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)

Information Security and the SDLC

by BDPA Charlotte - Information Technology Thought Leaders

Accessibility

Categories

Upload Details

Usage Rights

Statistics

Information Security and the SDLC Presentation Transcript