View
2.269
Download
0
Category
Tags:
Preview:
Citation preview
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.
3
Visionary View Point
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”
5
Software Aspects
Development Life Cycle
SecurityPrivacy
Maintenability
Usability
SW
6
Academic View Point
7
Who, How, What and When?
Who: Security actors
How: Secure Software DLC (SSDLC)
What: software, processes, people, policy
When: Always
8
Who: Actors
Software Security... ...Analyst ...Designer ...Developer ...Tester ...Documenter
All that actors are directed from the Software Security Officer
Reference: [M04]
9
How: security base principles 1/3
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 behind an object's perceived efficiency or elegance.” [Wikipedia]
Reference: [F199-04]
security core principles
10
How: security base principles 2/3
Reference: [F199-04]
11
How: security base principles 3/3
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”.
Reference: [Wikipedia]
security core activities
12
How: Software DLC
Waterfall Model (old paradigm) Iterative Model (new paradigm)
Reference: [V04]
13
How: Secure Software DLC 1/3
Reference: [M04]
14
How: Secure Software DLC 2/3
Reference: [LH03]
15
How: Secure Software DLC 3/3
Reference: [NIST04]
16
How: SSDLC phasesAdopting 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!
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;
Reference: [M04], [NIST04], [LH03], [GW03], [CA06]
18
How: Software Risk Management
Software Risk Mgmt. Software Risk Analysis
Software Risk Mitigation
SDLC
SSDLCRisk Management
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;
Reference: [LH03]
20
When
Always!
Reference: [LH03]
21
Practitioner View Point
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.”
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….”
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;
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;
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;
(*) 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;
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;
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.
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;
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.
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;
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.
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)
Recommended