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