Software Security
Guidelines and best practices to
Software Security
V. 1.7 - 31/03/2007
Roberto Battistoni - Software Security Specialist - rbattistoni[+AT+]acm.org

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

Visionary View Point
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 Mc
Graw]
“Security is everybody’s problem”

“Inside attacks are more powerful than

externals”
4

Software Aspects
Usability
Maintenability Development Life
Cycle
SW
Privacy Security
5

Academic View Point
6

Who, How, What and When?
 Who: Security actors
 How: Secure Software DLC (SSDLC)
 What: software, processes, people,
policy
 When: Always
7

Who: Actors
Software Security...

...Analyst

...Designer

...Developer

...Tester

...Documenter

All that actors are directed from the Software Security

Officer
8
Reference: [M04]

How: security base principles 1/3
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 behind an object's
perceived efficiency or elegance.” [Wikipedia]
9
Reference: [F199-04]

How: security base principles 2/3
10
Reference: [F199-04]

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]

How: Software DLC
Waterfall Model (old paradigm) Iterative Model (new paradigm)
12
Reference: [V04]

How: Secure Software DLC 1/3
13
Reference: [M04]

How: Secure Software DLC 2/3
14
Reference: [LH03]

How: Secure Software DLC 3/3
15
Reference: [NIST04]

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]

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]

How: Software Risk Management
Software Risk Analysis
Software Risk Mgmt.
Software Risk Mitigation
SDLC
SSDLCRisk Management
18

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]

When
Always!
20
Reference: [LH03]

Practitioner View Point
21

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]

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]

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

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

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

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]

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]

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]

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]

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]

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]

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

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