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)