Software Security


Published on

Published in: Technology

Software Security

  1. 1. Software Security Guidelines and best practices to Software Security V. 1.7 - 31/03/2007 Roberto Battistoni - Software Security Specialist - rbattistoni[+AT+]
  2. 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. 3. Visionary View Point 3
  4. 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. 5. Software Aspects Usability Maintenability Development Life Cycle SW Privacy Security 5
  6. 6. Academic View Point 6
  7. 7. Who, How, What and When?  Who: Security actors  How: Secure Software DLC (SSDLC)  What: software, processes, people, policy  When: Always 7
  8. 8. Who: Actors Software Security...  ...Analyst  ...Designer  ...Developer  ...Tester  ...Documenter  All that actors are directed from the Software Security  Officer 8 Reference: [M04]
  9. 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. 10. How: security base principles 2/3 10 Reference: [F199-04]
  11. 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. 12. How: Software DLC Waterfall Model (old paradigm) Iterative Model (new paradigm) 12 Reference: [V04]
  13. 13. How: Secure Software DLC 1/3 13 Reference: [M04]
  14. 14. How: Secure Software DLC 2/3 14 Reference: [LH03]
  15. 15. How: Secure Software DLC 3/3 15 Reference: [NIST04]
  16. 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. 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. 18. How: Software Risk Management Software Risk Analysis Software Risk Mgmt. Software Risk Mitigation SDLC SSDLCRisk Management 18
  19. 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. 20. When Always! 20 Reference: [LH03]
  21. 21. Practitioner View Point 21
  22. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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