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]

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]

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]

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

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]

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