Your SlideShare is downloading. ×
  • Like
Software Security
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply
Published

 

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,952
On SlideShare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
133
Comments
0
Likes
4

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Software Security Guidelines and best practices to Software Security V. 1.7 - 31/03/2007 Roberto Battistoni - Software Security Specialist - rbattistoni[+AT+]acm.org
  • 2. Goals Introducing Software Security;  Explaining Security in SDLC (Software  Development Life Cycle); Proposing Software Security Guidelines;  Proposing Good- and showing Bad-practices for  Secure Software DLC. 2
  • 3. Visionary View Point 3
  • 4. 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 Mc Graw] “Security is everybody’s problem”  “Inside attacks are more powerful than  externals” 4
  • 5. Software Aspects Usability Maintenability Development Life Cycle SW Privacy Security 5
  • 6. Academic View Point 6
  • 7. Who, How, What and When?  Who: Security actors  How: Secure Software DLC (SSDLC)  What: software, processes, people, policy  When: Always 7
  • 8. Who: Actors Software Security...  ...Analyst  ...Designer  ...Developer  ...Tester  ...Documenter  All that actors are directed from the Software Security  Officer 8 Reference: [M04]
  • 9. How: security base principles 1/3 security core principles Confidentiality: quot;Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information…quot; A loss of confidentiality is the unauthorized disclosure of Information. [F199-04] Integrity: quot;Guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity…quot; A loss of integrity is the unauthorized modification or destruction of information. [F199-04] Availability: quot;Ensuring timely and reliable access to and use of information…quot; 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 behind an object's perceived efficiency or elegance.” [Wikipedia] 9 Reference: [F199-04]
  • 10. How: security base principles 2/3 10 Reference: [F199-04]
  • 11. How: security base principles 3/3 security core activities 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”. 11 Reference: [Wikipedia]
  • 12. How: Software DLC Waterfall Model (old paradigm) Iterative Model (new paradigm) 12 Reference: [V04]
  • 13. How: Secure Software DLC 1/3 13 Reference: [M04]
  • 14. How: Secure Software DLC 2/3 14 Reference: [LH03]
  • 15. How: Secure Software DLC 3/3 15 Reference: [NIST04]
  • 16. How: SSDLC phases Adopting a SDLC iterative model Start  Analysis: security requirements, risk analysis, threat  identification, threat impact probability, abuse cases and UML 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!  16 Reference: [M04], [NIST04], [LH03], [GW03]
  • 17. 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;  17 Reference: [M04], [NIST04], [LH03], [GW03], [CA06]
  • 18. How: Software Risk Management Software Risk Analysis Software Risk Mgmt. Software Risk Mitigation SDLC SSDLCRisk Management 18
  • 19. What Processes, Policies and Software: must be viewed  and analysed under a security perspective too; Informatics People: computer technicians have to  know what is “Software Security” and have to respect few but essential points; 19 Reference: [LH03]
  • 20. When Always! 20 Reference: [LH03]
  • 21. Practitioner View Point 21
  • 22. Excuses to underestimate security in SDLC 1/2 “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.”  22 Reference: [LH03]
  • 23. Excuses to underestimate security in SDLC 2/2 “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….”  23 Reference: [LH03]
  • 24. Software Security Guidelines 1/3 Security Usability: ● what to do: security should impact minimally on system usability; ● why: secure applications not usable 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; ● 24
  • 25. Software Security Guidelines 2/3 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; 25
  • 26. Software Security Guidelines 3/3 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; ● 26 (*) 1/2/3/4 Factor Authentication
  • 27. Good practices 1/3 Good practices to improve software security Input Validation:  fields length and buffers bound checking  validate input not only on client-side but on server-side  environment too; use “preparedStatement()” in Java and similar functions in other  languages to avoid SQL Injection attacks; possibly use high level virtualized languages such Java, C#;  low level languages like C and C++ are more exposed to buffer overflow exploits; 27 Reference: [GW03]
  • 28. Good practices 2/3 Good practices to improve software security Confidentiality  Use Public Key Cryptography to do effective encryption;  Encrypt and sign passwords with PGP, GnuPG, RSA or other  encryption tools; store them in a secure place; Zero memory stored passwords after the use;  Use a well known encryption algorithm: security is granted by  the key and the well-known algorithm; Use well known secure protocols to implement channel  encryption; Obfuscate your interpreted code from VM as JVM or .NET CLR;  Create secure temporary files;  28 Reference: [GW03]
  • 29. Good practices 3/3 Good practices to improve software security Integrity  Use strength passwords but not too complex: every password  must be at least eight characters length (upper and lower case, number and special characters); passwords haven't to be too complex to avoid user writing down passwords everywhere! Identification & Authentication have to be done over encrypted  channels; Adopt well known access control policy: DAC, MAC or RBAC;  Do not use applets or ActiveX in Web application: user could be  constrained to activete ActiveX or Applet execution in the Web Browser exposing the browser to malicious components. 29 Reference: [GW03]
  • 30. Good practices 3/3 Good practices to improve software security Activities  Documenting security policies adopted by your software;  Plan periodic independent reviews;  Use Checklists to do security tests;  Comment your code, this can help the security reviewer and  tester; 30 Reference: [GW03]
  • 31. Bad practices 1/2 Write passwords everywhere or say them to everyone:  Social Engineering is very diffuse; memorize your passwords or  encrypt them; Create administration backdoor in your applications:  create an “administrator” user with high privileges instead;  “Security through obscurity”:  use well known security algorithm and secure keys;  “Retrofit” security:  secure your software with SSDLC;  Use demo Certificates (X.509):  build your own Certification Authority (CA) and emit your certificates.  31 Reference: [GW03]
  • 32. Bad practices 2/2 Think that software security is network security! Many security problems  become from OS C/C++ programming buffer overflow problems:  look at SSDLC Think that third party software is secure:   it isn't true, check them; Think that random functions are true Random!:   Random is only in nature; in a computer world all functions are pseudo- random; “Hard-code” password in your software:   use asymmetric cryptography; Don't check “cut & paste” code:   analyse the code first! Think that attackers come from the outside:   Most attack activities are inside in the enterprise; 32 Reference: [GW03]
  • 33. Remarks This is only a guide to remember some  aspects of Software Security. It is not very important to remember all  security problems, but it is very important to respect security guidelines and best practices. 33
  • 34. 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) 34