The document outlines the principles of information security and the secure software development life cycle (SDLC), emphasizing the importance of risk management, security requirements, and guidelines in software development. It discusses core security principles like confidentiality, integrity, and availability, as well as the necessity of embedding security throughout the SDLC phases including analysis, design, development, testing, and maintenance. The document also highlights various tools and methodologies for software security, common vulnerabilities, and the significance of continuous monitoring and proper disposal practices.

1. Ron Clement
CISSP,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!” [Bruce
Schneier]
 “Software Security is not Security Software” [Gary
McGraw]
 “Security is everybody’s 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, and
transmit that information
 Necessary tools: policy, awareness, training, education,
technology

5. Information Security Domains
A successful organization should have multiple layers of security in
place:
 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

6. Security Core Principles
Confidentiality: "Preserving authorized restrictions on information
access and disclosure, including means for protecting personal privacy
and proprietary information…" A loss of confidentiality is the
unauthorized disclosure of Information. [F199-04]
Integrity: "Guarding against improper information modification or
destruction, and includes ensuring information non-repudiation and
authenticity…" A loss of integrity is the unauthorized modification or
destruction of information. [F199-04]
Availability: "Ensuring timely and reliable access to and use of
information…" A loss of availability is the disruption of access to or use of
information or an information system. [F199-04]
Usability: “is a term used to denote the ease with which people can
employ a particular tool or other human-made object in order to
achieve a particular goal. Usability can also refer to the methods of
measuring usability and the study of the principles

7. HOW: Security Base Principles

8. HOW: Security Base Principles
To 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 user's
claimed identity (for example, by comparing an entered
password to the password stored on a system for a given
username).”;
 Authorization: “defines a user's 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”.

9. 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

10. HOW: Secure SDLC
Waterfall 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 Management
Software Risk Software Risk Analysis
Management Software Risk Mitigation

17. Excuses to underestimate security in the SDLC
 “We've reviewed the code, and there are no security
bugs.”
 “We know it's the default, but the administrator can
turn it off.”
 “If we don't run as administrator, stuff breaks.”
 “But we'll slip the schedule.”
 “It's not exploitable.”
 “But that's the way we've 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?”
 “We've never been attacked.”
 “We're secure, we use cryptography.”
 “We're secure, we use ACLs.”
 “We're secure, we use a firewall.”

19. 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

20. Major Vulnerabilities in the
Application 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 Protection
OWASP Top 10 - 2010

21. 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;

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

26. Initiation Phase

27. Initiation Phase
System 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 Phase
Risk 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

29. Initiation Phase
Risk 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.

30. Initiation Phase
Vulnerability 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.

31. Initiation Phase
Vulnerability 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 Center
System testing
 Vulnerability scanning
 Penetration testing
 Security controls assessment
 Previous risk assessment documentation

32. 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

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 this
phase of the SDLC progresses

34. Threat Modeling
 Understand the operating environment your
application is heading into
 Identify, analyze and document (and thus hopefully
mitigate) threats
34

35. 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

36. Identifying threats – data flow diagrams
 contains the major processes, system boundaries
 .. interactions with external entities
36

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, discoverability
37

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 results
38

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-McGraw
39

40. 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 identified
40

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 code
41

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 understanding
42

43. 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 Testing
43

44. Application Security 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
44

45. Operations and Maintenance
Phase
 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”, IEEE
Security & Privacy, March 2004;
[CA06] Curphey, Araujo, “Web Application Security Assessment Tools”, IEEE Security and Privacy
archive, Volume 4 , Issue 4 (July 2006)
[CM04] B. Chess, G. McGraw, “Static Analysis for Security”, IEEE Security & Privacy, December
2004;
[ITSEC91] “Information Technology Security Evaluation Criteria”, Commission European
Communities, 1991;
[F199-04] Federal Information Processing Standard (fips) 199, “Standards for security
categorization of federal information and information systems”, 2004
[GW03] M.G. Graff, K.R. van Wyk, “Secure Coding: Principles & Practices”, O'ReillyPub, 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, April
2004;
[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 the
ACM archive,Volume 49 , Issue 8 (August 2006)