1.
Software Security in
Practice
Matteo Meucci CEO Minded Security
AIEA Turin – 30-10-2015

2.
Agenda
I Part) Introduction to Software Security
1.1 Scenario
1.2 What is the state of the Information Security today?
1.3 The main targets of the cyber attacks
II Part) How OWASP can support Enterprises
2.1 Web Application Security: the OWASP Guides today
2.2 How to use the testing guide in your processes
III part) A structured approach to software security
 3.1 OWASP Guidelines and tools in SDLC
3.2 Outsourcing Governance
3.3 SAMM: the assessment to evaluate your Software Development LifeCycle
 3.4 Case-Study: how Companies are approaching the Governance of Software Security

3.
Informatics Engineer (since 2001)
Research
• OWASP contributor (since 2002)
• OWASP-Italy Chair (since 2005)
• OWASP Testing Guide Lead (since 2006)
Work
• 14+ years on Information Security focusing on Software Security
• CEO @ Minded Security – The Software Security Company (since 2007)
3
Who am I?

4.
1. INTRODUCTION TO SOFTWARE
SECURITY
1.1 SCENARIO

5.
InfoSec scenario: software is the key point
Users
Cyber criminals
Companies
Governments
Software

6.
Is your Google mail secure?
• Yes!
• No!
• I don’t know

7.
What is Secure Software?
It’s secure! Looks at the
lock, down on the right!
It’s secure! It’s Google!
Sure! The news said
that is unbreakable!

8.
Software Security Principles
• The Vulnerabilities in the software development
process are expected.
• The control of the security bugs and flaws in the
software should be considered as part of the
process of software development.
• Vulnerability management (fixing process) is the
most important step of the process of software
security.

9.
1.2 WHAT IS THE STATE OF THE
INFORMATION SECURITY TODAY?

10.
2014 Attacks
In 2014, 5 out of 6 companies have been the victim of cyber attacks (+ 40% over 2013, Symantec
report 2014)
30.000 websites are hacked every day to distribute malware (SOPHOS - Security Threat Report 2012)
2014 important security breaches (DBIR 2015):

11.
What is the state of the security today?
Attackers Are Moving Faster, Defenses Are Not
With Heartbleed, attackers moved in to exploit these vulnerabilities much faster than
vendors could create and roll out patches. In 2014, it took 204 days, 22 days, and 53
days, for vendors to provide a patch for the top three most exploited zero-day
vulnerabilities.
Attackers Are Streamlining and Upgrading Their Techniques,
While Companies Struggle to Fight Old Tactics
Attackers making each attack more selective by infecting legitimate websites, monitoring
site visitors and targeting only the companies they wanted to attack.
Also Small and Medium sized organizations are under attacks
Last year, 60 percent of all targeted attacks struck small- and medium-sized
organizations. These organizations often have fewer resources to invest in security, and
many are still not adopting basic best practices like blocking executable files and
screensaver email attachments.

12.
1.3 THE MAIN TARGETS OF THE CYBER
ATTACKS

13.
Target of data breach: what vector attacks are more
used today?
•Web Applications: access to the DB to stole Credit card or
personal user information. Attack vettor: SQL injection, XSS
•Crimeware: Five out of every six large companies were targeted
with spear-phishing attacks in 2014, a 40 percent increase over
the previous year. Attack vector: email, fake sites
•Cyber espionage: Governments use cyber espionage to take the
control of humans, systems, trade secrets. Attack vector: 0day
•DoS: botnet are used to perform distributed attack to sites do
deny the services to legitamate users. Attack vector: malware

14.
Attacks to Companies
• Companies are attacked on the web applications
and on their personnel (email, fake sites,
malware, mobile)
• The top three industries affected are the same as
previous years: Public, Information, and
Financial Services. (Verizon)
• In 60% of cases, attackers are able to compromise
an organization within minutes. (Verizon)
• The time of reaction it is really slow today
14

15.
2. HOW OWASP CAN SUPPORT THE
ENTERPRISES
2.1 THE OWASP GUIDES TODAY

16.
OWASP has ~140 Projects
• PROTECT - These are tools and documents that can be used
to guard against security-related design and implementation
flaws.
• DETECT - These are tools and documents that can be used to
find security-related design and implementation flaws.
• LIFE CYCLE - These are tools and documents that can be used
to add security-related activities into the Software
Development Life Cycle (SDLC).

17.
Developer Guide
• The First OWASP ‘Guide’
• Complements
OWASP Top 10
• 310p Book (on wiki too)
• Many contributors
• Apps and web services
• Most platforms
• Examples are J2EE, ASP.NET, and PHP
• Unfortunately Outdated
• Project Leader and Editor
 Andrew van der Stock,
vanderaj@owasp.org

18.
Code Review Guide
• Most comprehensive open
source secure code review
guide on the web
• Years of development effort
• Version 1.1 produced during
2008
• Numerous contributors
• Version 2.0 effort launched in
2012
• Project Leader and Editor
 Eoin Keary, eoin.keary@owasp.org
www.owasp.org/index.php/Code_Review_Guide

19.
Code Review Guide
public void findUser()
{
boolean showResult = false;
String username =
this.request.getParameter("username");
...
this.context.put("username", username);
this.context.put("showResult", showResult);
}

20.
Testing Guide
www.owasp.org/index.php/Testing_Guide
• Most comprehensive open source
secure testing guide on the web
• Years of development effort
• Version 4.0 produced in 2014
• Hundred of contributors
• Project Leader and Editor
• Matteo Meucci, Andrew Muller
 matteo.meucci@owasp.org,
andrew.muller@owasp.org

21.
Testing Guide
http://127.0.0.1:8080/Jforum-
new/jforum.page?action=findUser&module=pm&username=
%22%3E%3Cscript%3Ealert%28123%29%3C/script%3E%3
C%22

22.
The OWASP Testing Guide: Community
driven for all the Enterprises

23.
The state of the art of the Web
Application Penetration Testing

24.
Fight with the same weapons (knowledge)

25.
 July 14, 2004
"OWASP Web Application
Penetration Checklist", V1.0
 December 25, 2006
"OWASP Testing Guide", V2.0
 December 16, 2008
"OWASP Testing Guide", V3.0
 September 17, 2014
"OWASP Testing Guide", V 4.0
Citations:
• NIST SP800-115 “Technical Guide to
Information Security Testing and Assessment”
• Gary McGraw (CTO Cigital) says: “In my
opinion it is the strongest piece of Intellectual
Property in the OWASP portfolio” – OWASP
Podcast by Jim Manico
• NSA’s "Guidelines for Implementation of
REST“
• Official (ISC)2 Guide to the CSSLP - Page: 70,
365
• Many books, blogs and websites
Testing Guide History
Note: use the Guide only on your local applications or be sure to have an NDA in place with the owner of the
application before test it.

26.
2.2 HOW TO USE THE TESTING
GUIDE IN YOUR PROCESSES

27.
How to use the methodology
Web Application
Source Code
public void findUser()
{ boolean showResult = false;
String username =
this.request.getParameter("us
ername");
...
this.context.put("username",
ESAPI.encoder().encodeForHT
MLAttribute(username));
this.context.put("showResult",
showResult);
}
Methodology Report
Fixing Methodology Retest Report

28.
Common misunderstanding

29.
Example of unstructured approach:
Ministry of Informatics

30.
Actors
User: who uses the
software
Ministry of
Informatics:
who buys the
software
Development
teams
(internal/external):
who develops the
software

31.
Press conference for the launch of the service
Now you can take
advantage of a new
service on the portal of the
Ministry of Informatics
Fantastic!! Compliments!!

32.
The day after…

33.
Users access to the portal…
John Black – 12/12/1970 – JBlack@company.com
Josh White - 10/09/1982 – White@bank.com
Paul Red– 09/02/1960 – Paul@bank.com

34.
Users access to the portal…
Oh oh...I find a
problem...

35.
Some days after…

36.
The reactions…
Ohh..how it was
possible? Fault of the
developers!
but it is impossible !?
We followed all your
instructions
If you do not ask for security, no one will develop secure software
Use the Testing Guide as common framework

37.
An year after…another security breach
but it is impossible!?
We adopt the OWASP
Testing Guide!
Web Application Penetration testing is not enough!
If you do not design a correct vulnerability fixing process you will
not solve the vulnerabilities of your application
Ohh..how it was
possible? Fault of the
developers!

38.
3. A STRUCTURED APPROACH
TO SOFTWARE SECURITY

39.
3.1 OWASP GUIDELINES AND
TOOLS IN YOUR SDLC

40.
The Importance to use all the OWASP resources
into your SDLC
If you do not ask for security, no one will develop secure software
Use the OWASP Software Contract Annex to regulate your
outsourcer contracts
If you do not know the application threats, you will develop unsecure software
Use the OWASP Top 10 for General Awareness
Use the CISO Guide for Management’s Awareness
Vulnerabilities in the software development process are expected
Use the OWASP Building Guide and ESAPI to write more secure
software
Use the OWASP Secure Code Review Guide to review the code
Use the OWASP Testing Guide to review to test your application

41.
The Importance to use all the OWASP resources
into your SDLC
The fixing process is the most important step of the process of software
security
Retest your application after a bug fixing or a new release
to be sure that the right implementations are in place
How can I manage the Software Security Governance?
Use the OWASP SAMM to assess your maturity and to
build an Application Security Program to manage the
SDLC

42.
42
OWASP Guidelines in the SAMM model
Governance Construction Verification Deployment
42

43.
3.2 OUTSOURCING
GOVERNANCE

44.
Secure SDLC
Costs relating the fixing in the phases of SDLC
Source: Official (ISC)2 Guide to CSSLP (2011)

45.
Source: Official (ISC)2 Guide to CSSLP (2012)
SDLC Stakeholders

46.
Secure SDLC
Fasi SDLC Secure Software processes
Define Secure Software Requirements
Design Secure Software Design
Develop Secure Software Implementation
Deploy Secure Software Testing &
Acceptance
Maintain Secure Software Deployment &
Maintenance

47.
Roles and responsabilities
4
7
Define Design Develop Deploy Maintain
Risk
Assessment
Secure
Design
Design
Review
Software
Acceptance
Web Intrusion
Monitoring
Secure
Requirements
Threat
Modeling
Secure
Development
Secure
Installation
Change
Management
Secure
Architecture
SCR and
WAPT
Hardening
Fixing
Business Analyst
Security Manager
Business Analyst
AppSec Specialist
Business Analyst
Software Architect,
AppSec Specialist
Security Manager
Application Owner
Software Architect
Security Manager
Security Manager
Developer
AppSec Specialist
Developer
Security Manager
App Owner
Sistemista
Sistemista
AppSec Specialist
Sec Manager
App Owner
Develper

48.
Development
Team
Code Review
Team
Application Testing
Team
Outsourcing
Contratto di
sviluppo
(Fornitore) (Committente)
Contratto di
sviluppo

49.
Collaudo software
Source:
• OWASP Secure Software Development
Contract Annex
• Capability Maturity Model v1.1
• ISO/IEC 27006:2007 (Information
technology — Security techniques —
Requirements for bodies providing
audit and certification of information
security management systems )

50.
Filosofia del documento
(a) Le decisioni sulla sicurezza saranno basate sui rischi. Le decisioni saranno
effettuate congiuntamente da cliente e sviluppo
(b) Le attività di sicurezza saranno bilanciate. Distribuite in modo uniforme nell'intero
ciclo di vita dello sviluppo software.
(c) L’Attività di sicurezza sarà integrata. Tutte le attività e la documentazione saranno
integrate nel ciclo di vita del software per gli sviluppatori e non tenuto separato
dal resto del progetto.
(d) Le vulnerabilità sono attese. Tutto il software presenta dei bug. Si cercherà
di identificare le vulnerabilità più presto possibile nel ciclo di vita del sw.
(e) Le vulnerabilità saranno condivise. Tutte le informazioni relative alla
sicurezza saranno condivise tra il Cliente e Sviluppo immediatamente e
completamente.

51.
Principi fondamentali
Prima di acquisire il software da un outsourcer è importante verificare che
soddisfi i requisiti di:
– Compliance, Qualità, Funzionalità e Sicurezza
– I requisiti di sicurezza devono essere validati e i controlli di sicurezza
verificati internamente o da una terza parte tramite security testing
(V&V).
– Il software non deve essere rilasciato fino a che non sia stato
certificato e accreditato che il rischio residuo è al livello appropriato
(C&A).

52.
Modello di Software Acceptance
Sviluppo Cliente
Secure
Software
Development
Contract
1. Security
Requirements
2. Librerie e
framework
3. Security
Review
4. Assurance
5. Acceptance
Secure
Software
Development
Contract

53.
(1) Security Requirements area
• Validation and Encoding.
• Authentication and Session Management.
• Access Control.
• Error Handling.
• Logging.
• Connections to External Systems.
• Encryption.
• Availability
• Secure Configuration.
• Specific Vulnerabilities. “OWASP Top Ten Most Critical Web Application
Vulnerabilities.”

54.
(1) Esempio di security Requirements
ID
Requisito
Data Validation-003 – UTILIZZARE I PREPARED STATEMENT
Descriz. L’applicazione è soggetta a vulnerabilità di SQL Injection quando usa l’input fornito
dall’utente senza validarlo per fare delle query sul database (ad esempio la ricerca
dell’utente in fase di login oppure quando si usa una funzione di ricerca fornita
dall’applicazione).
È necessario fare uso solo di Prepared Statement evitando l’uso di concatenazioni di
stringhe. LìuUtilizzo di concatenazione di stringhe per costruire la query da ingresso
arbitrario non renderà il PreparedStatement sicuro. Per esempio:
PreparedStatement = "SELECT * FROM utenti WHERE Nome = '" + username + "',";
Se un attaccante inserisce: 'O '1' = '1
Nel campo nome utente, il PreparedStatement sarà vulnerabile a SQL injection, dal
momento che tale query verrà eseguita sul database come
SELECT * FROM utenti WHERE Nome ='' OR '1 '= '1';
Quindi, se si utilizza invece:
PreparedStatement = "SELECT * FROM utenti WHERE nome =?";
preparedStatement.setString (1, userName);
....

55.
(1) Esempio di checklist

56.
(2) Librerie, framework e prodotti
• Disclosure. Lo sviluppo deve indicare tutti i software di terze parti usati
nel software, incluse tutte le librerie, strutture, componenti, e altri
prodotti, siacommerciale, gratuito, open-source o closed-source (si può
decidere in fase di design quali librerie e framework debba utilizzare
l’outsourcer).
• Evaluation. Lo sviluppo dovrà fare ogni ragionevole sforzo per assicurare
che il software di terze parti soddisfi tutti i termini di questo accordo ed
è sicuro come il codice personalizzato sviluppato nell'ambito dell’accordo.

57.
(3) Security Review
Right to Review.
Il cliente ha il diritto di rivedere il codice a proprie spese in ogni momento fino a 60 giorni
dalla consegna. Lo sviluppo si impegna a fornire un supporto ragionevole del team di
revisione, fornendo il codice sorgente e l'accesso ad ambienti di test.
Review Coverage.
Il Security Review comprende tutti gli aspetti del software fornito, incluso il
codice personalizzato,componenti, prodotti e configurazione del sistema.
Scope of Review.
Come minimo, la revisione riguarda tutti i requisiti di sicurezza e le vulnerabilità comuni. La
revisione può includere una combinazione di scansione di vulnerabilità, PT , l'analisi statica
del codice sorgente e il code Review di esperti.
Issues Discovered.
I problemi di sicurezza scoperti verranno segnalati e devono essere fixati prima di procedere
ai prossimi passi.

58.
(3) Security Review
• In questa fase viene effettuato il processo di Validate & Verify secondo il
modello CMMI v.1.1:
– Validate
• Si verifica che il software si comporti secondo il disegn e i requisiti stabiliti.
• Si validano i security requirements concordati (checklist).
– Verify dei controlli implementati al fine di evitare possibili vulnerabilità
• Secure Code Review
• Penetration Testing

59.
(4) Assurance
(a) Certification Package.
Lo sviluppo fornirà un "pacchetto di certificazione" costituito dalla documentazione
relativa alla protezione creata durante il processo di sviluppo. Il pacchetto dovrebbe
stabilire che i requisiti di sicurezza, progettazione, implementazione e risultati di test
siano stati compilati.
(b) Autocertificazione.
Lo sviluppo certifica che il software soddisfi i requisiti di sicurezza, tutte le attività di
sicurezza sono stati effettuate, e tutti i problemi legati alla sicurezza sono stati
documentati e risolti.
(c) Nessun codice dannoso.
Lo sviluppo garantisce che il software non deve contenere alcun codice dannoso, come
virus, worm, backdoor, malware.

60.
(5) Acceptance
• Considerazioni generali
•Tutti i requisiti funzionali e di sicurezza sono
stati completati come da contratto?
Criteri di
completezza
•Esiste un processo per gestire le richieste di
cambiamento?
Change
Management
•Il rischio residuo di acceptance e le eccezioni
alle policy sono entro i limiti stabiliti?
Accettazione del
rischio ed
exception policy
•Tutta la documentazione è disponibile?
Documentazione
del software

61.
(5) Acceptance
In questa fase si esegue il processo di Certification & Accreditation (C&A) secondo il
CMM v1.1
– Il software non può essere considerato accettato fino a quando il pacchetto
di certificazione è completo e tutte le questioni relative alla sicurezza sono
state risolte:
• Documentazione completa.
• Fixing e Retest effettuati oppure valutazione che il rischio residuo è al
livello appropriato.

62.
Security issue management and acceptance
Sviluppo Cliente
Secure
Software
Development
Contract
1. Security
Requirements
2. Librerie e
framework
3. Security
Review
4. Assurance
5. Acceptance
Secure
Software
Development
Contract

63.
FALSI MITI
Comuni reazioni da parte dei fornitori:
(1) Non vi preoccupate sviluppiamo utilizzando lo standard OWASP
(2) Broken Authentication Session Hijacking, Liferay offre una serie di feature
di sicurezza per la gestione dell’autenticazione e anche per altre possibili
security issues
(3) Cross Site Scripting: JSF ha una serie di feature di sicurezza anti XSS
(4) Broken Access Control: garantito dall’applicazione che andremo a
sviluppare

64.
3.3 SAMM: THE ASSESSMENT
TO EVALUATE YOUR SOFTWARE
DEVELOPMENT LIFECYCLE

65.
SAMM goals
• SAMM allows a Company to:
– Measure and improve software security best
practices
– Focus on security risk to make effective use of
security resources
– Find vulnerabilities earlier in the development
process
– Design a Roadmap to manage the software
security in your projects

66.
OWASP SAMM: objectives
The SAMM’s goals are:
Evaluate an organization’s existing software security
practices
Build a balanced software security assurance program
in well-defined iterations
Demonstrate concrete improvements to a security
assurance program
Define and measure security-related activities
throughout an organization

67.
OWASP SAMM: 4 Business functions
Define Design Develop Deploy Maintain
Governance Construction Verification Deployment
Software development
management activities
and organisation-wide
business processes
Goal definition and
software creation
processes
Checking, evaluation
and testing of
software development
artifacts
Software release
management and
normal operational
management

68.
OWASP SAMM: 12 Security Practices

69.
Governance
• Strategy & Metrics involves the overall strategic
direction of the software assurance program and
instrumentation of processes and activities to collect
metrics about an organization’s security posture.
• Policy & Compliance involves setting up a security
and compliance control and audit framework
throughout an organization to achieve increased
assurance in software under construction and in
operation.
• Education & Guidance involves increasing security
knowledge amongst personnel in software
development through training and guidance on
security topics relevant to individual job functions.
6
9
Governance
Strategy & Metrics
Policy & Compliance
Education & Guidance

70.
Construction
• Threat Assessment involves accurately identifying
and characterizing potential attacks upon an
organization’s software in order to better
understand the risks and facilitate risk
management.
• Security Requirements involves promoting the
inclusion of security-related requirements during
the software development process in order to
specify correct functionality from inception.
• Secure Architecture involves bolstering the design
process with activities to promote secure-by-
default designs and control over technologies and
frameworks upon which software is built.
7
0
Construction
Threat Assessment
Security Requirements
Secure Architecture

71.
Verification
• Design Review involves inspection of the
artifacts created from the design process to
ensure provision of adequate security
mechanisms and adherence to an
organization’s expectations for security.
• Code Review involves assessment of an
organization’s source code to aid
vulnerability discovery and related
mitigation activities as well as establish a
baseline for secure coding expectations
• Security Testing involves testing the
organization’s software in its runtime
environment in order to both discover
vulnerabilities and establish a minimum
standard for software releases.
7
1
Verification
Design Review
Code Review
Security Testing

72.
Deployment
• Vulnerability Management involves
establishing consistent processes for
managing internal and external vulnerability
reports to limit exposure and gather data to
enhance the security assurance program.
• Environment Hardening involves
implementing controls for the operating
environment surrounding an organization’s
software to bolster the security posture of
applications that have been deployed.
• Operational Enablement involves identifying
and capturing security-relevant information
needed by an operator to properly configure,
deploy, and run an organization’s software.
Deployment
Vulnerability
Management
Environment
Hardening
Operational
Enablement

73.
73
SAMM activities
1. Conduct the first
assessment
2. Create a score card
3. Create a Software
Security Program
1. Metrics
2. Road map
4. Implement the objectives
of the roadmap and
conduct a new
assessment

74.
Step 0: SAMM Startup
• Give a presentation of SAMM model and objectives
to all the people involved in the assessment in the
Company
• Collect the name and functions of the people
involved in the assessment with the SAMM sponsor
(Roles and responsability)

75.
Step 1: conduct the assessment

76.
Step 2: evaluate the assessment

77.
Step 3: create the scorecard

78.
Step 4: create the roadmap
• For each Security Practice write down the Activities
to implement
• Evaluate the benifts and the efforts for the
organization necessary to improve each Security
Practice.

79.
Step 4: create the roadmap

80.
Step 5: Magic quadrant for the actions

81.
Step 6: scorecard with roadmap

82.
Step 7: write the report

83.
3.4 CASE-STUDY: HOW
COMPANIES ARE APPROACHING
THE GOVERNANCE OF
SOFTWARE SECURITY

84.
What Italian Companies are doing today
Area: Governance Activities Participants
Strategy and Metrics
Conduct periodic industry wide cost
comparisons, collect metrics for
historic security spend (% project),
past spending.
10%
Policy and Compliance
Identify and monitor external
compliance drivers, build and maintain
compliance guidelines.
80%
Education and
Guidance
Training courses for Developers,
Analysts, Auditors and Workshop for
Management.
55%
Source: Minded Security – Results of 12 assessments from 2012 to 2015

85.
What Italian Companies are doing today (2)
Area: Construction Activities Participants
Secure Architecture
Build the document for the Governance of
the development outsourcing process.
30%
Security Requirements
Develop: “Building Secure applications
guidelines”.
60%
Secure Design
Apply the methodology of threat modeling
to the projects evaluated with medium to
high risk in the definition phase of the
project and the specific
10%
Source: Minded Security – Results of 12 assessments from 2012 to 2015

86.
What Italian Companies are doing today (3)
Area: Verification Activities Participants
Design Review
Identify software attack surface, Analyze
design against known security
requirements, Inspect for complete
provision of security mechanisms.
20%
Code Review
Conduct Manual Secure Code Review for
critical applications
30%
Security Testing
Conduct penetration testing on software
releases with fixing support.
75%
Source: Minded Security – Results of 12 assessments from 2012 to 2015

87.
What Italian Companies are doing today (4)
Area: Deployment Activities Participants
Vulnerability
Management
Create information security response
team(s) for the application security,
Establish consistent incident response
process, Conduct root cause analysis for
application security incidents.
20%
Environment Hardening
Develop Hardening procedures for all your
technologies, Implement a fixing process
to be sure to patch all the issues identified
during the security assessment.
60%
Operational Enablement
Request support for fixing all the
vulnerabilities identified during the Secure
Code Review and Penetration Testing
activities.
40%
Source: Minded Security – Results of 12 assessments from 2012 to 2015

88.
Companies Worldwide: BSIMM 6

89.
Key point to implement a Software Security
Program (SSP)
Carrying out the activities of a SSP without commitment of the
Companies is very unlikely
• Identify and work with Software Security Group (SSG): The internal group charged with
carrying out and facilitating the SSP.
• Identify and promote Satellite groups in your Company: a group of interested and
engaged developers, architects, software managers, testers, who have a natural affinity
for software security.
A strong SSG is fundamental to carry on the software security initiative.

90.
Key point to have a mature Software Security
Program (SSP)
A fast fixing process is the key to have a mature SSP
• Satellite architects: should fix flaws asap
• Satellite developers: should fix bugs asap
• Satellite tester: should test if the remediations are strong enough asap.
A strong satellite is the key of a mature software security initiative.

91.
Next steps?
Companies will:
• Hire Information Security managers.
• Hire Talents skill on Application Security in your organizations.
• Implement Software Security Governance.
• Provide ongoing education and training: guidelines and company
policies for protecting sensitive data on personal and corporate
devices.
• Prepare for the worst: Incident management crises.

92.
QUESTIONS?
WWW.MINDEDSECURITY.COM
MATTEO.MEUCCI@MINDEDSECURITY.COM
THANKS!

93.
REFERENCES
• OWASP: http://www.owasp.org
•https://www.owasp.org/index.php/OWASP_WASC_Web_Hacking_Incide
nts_Database_Project
• Rapporto CLUSIT 2015
• Enisa European Threat Landscape 2014
• Symantec Internet-security-threat-report-volume-20-2015
• Verizon rp_data-breach-investigation-report-2015
•Ponemon Institure Report 2015
• OWASP SAMM: http://www.opensamm.org
• BSIMM v6: http://www.bsimm.com