This document provides tips for John, the co-founder of a small startup, on improving security within the organization. It recommends that security should be part of the company culture from the start and promoted through regular security awareness training. It also suggests conducting a basic risk analysis to understand the main assets, threats, and vulnerabilities. Additionally, it offers advice on securing the infrastructure, whether on-premises or in the cloud, as well as adopting secure practices throughout the software development lifecycle. The overall message is that security is important for startups to address from the beginning to prevent potential attacks from putting the company out of business.

1. Este documento é propriedade intelectual da PT e fica proibida a sua utilização ou propagação sem expressa autorização escrita
Building a Secure Startup
Nuno Loureiro
SAPO Security Team
07.10.2015
C-Days 2015
nuno@co.sapo.pt

2. 2
Who am I? Timeline
•Dez 2009: Got a dual Masters degree: MSIT-IS from CMU and MSI
from FCUL
• Jan 2010-now(): Founded and lead SAPO’s Security Team
•2012-now(): Head of Security and Fraud at PT Pay (Meo Wallet)
•1997-2002: System and Network administrator,
Programmer, a little of Security, Student, Entrepreneur …
•2002-2008: Web Programmer at SAPO,Technical Lead
of SAPO’s Email Platform

3. 3
Summary
• Security
Awareness
• Steps
to
improve
Security
within
your
organization
• Security
Culture
• Risk
Analysis
• Secure
Infrastructure
• Application
Security

4. 4
Context
Let’s
imagine
John
co-­‐founded
a
small
Startup.
Between
founders
and
employees
there’re
10
people.
They’re
focused
on
a
single
product:
A
collaborative
and
integrated
project
management
platform
Their
Business
Model
is
SaaS.
They’re
on
a
tight
budget.

5. 5
Invest in Security?
We’re
too
small
to
be
an
attractive
target…
Why
should
I
care?
Should
I
invest
in
Security
from
the
beginning?

6. 6
Invest in Security?
The
problem
is…

7. 7
Invest in Security?

8. 8
Invest in Security?

9. 9
Invest in Security?

10. 10
Invest in Security?

11. 11
Invest in Security?

12. 12
Invest in Security?

13. 13
Invest in Security?
IPO?
Fraud
Suicides
Divorces

14. 14
Invest in Security?
You
can
argue
about
the
probability
of
a
successful
attack
but
the
impact
of
just
one
attack
can
put
you
out
of
business…
Conclusion

15. 15
Invest in Security?
Are
you
willing
to
take
that
risk?

16. 16
Steps to improve Security
Tips
to
embrace
Security
in
your
startup

17. 17
Steps to improve Security

18. 18
Security
should
be
part
of
your
culture
• Starts
at
the
C-­‐level
• 2nd-­‐factor
for
VPN,
email
(from
new
devices)
and
critical
operations/
accounts
Steps to improve Security

19. 19
Security
should
be
part
of
your
culture
• Setup
VPN
(e.g.
OpenVPN)
for
remote
accessing
your
infrastructure
• Adopt
“corporate
network
=
home
network”
model,
no
privileged
access
from
corporate
network
to
your
infrastructure
Steps to improve Security

20. 20
Security
should
be
part
of
your
culture
• Use
Full
Disk
Encryption
on
your
laptops
• Use
password
managers
Steps to improve Security
FileVault

21. 21
Security
should
be
part
of
your
culture
• Give
periodic
security-­‐awareness
sessions
(phishing,
do’s
and
don’ts,
…)
• Invest
on
E-­‐mail
security
(to
prevent
malware,
phishing,
etc)
• Don’t
forget
Periodic
updates,
AV,
Firewall,
Screensaver
with
password
• Use
strong
cryptography
on
your
wifi,
VPN,
HTTPS
sites
Steps to improve Security

22. 22
Access your risk
Risk
Analysis
• There
are
many
frameworks
to
perform
Risk
Management:
• ISO27005
• OCTAVE
• NIST
SP
800-­‐37
• There
are
many
frameworks
to
perform
Threat
Modeling:
• Stride
• Dread
• For
the
purpose
of
this
talk
we’ll
do
a
very
basic
approach

23. 23
Risk
Analysis
• What
are
your
main
assets?
• Customer’s
data:
code,
project
ideas,
status
of
development,
business
plan,
employee’s
information,
confidential
information
• Business
Information:
Sales,
business
plan,
list
of
customers,
etc
• Availability
of
the
service
• What
are
the
main
threats
you
want
to
prevent?
• (account,
customer,
business)
Data
breach:
could
lead
to
bankruptcy
• DDoS
attacks:
Availability
is
core
to
our
business;
customer
churn
• What
vehicles
(vulnerabilities)
could
be
used
to
turn
threats
into
successful
attacks?
• Vulnerabilities
in
the
Web
Application
• Vulnerabilities
in
the
systems
• Public
IP
addresses
• Employee
PC
• Employee
• Email
• Physical
access
to
systems
•
(…)
Access your risk

24. 24
Secure your Infrastructure
Infrastructure
Security
Vs
On-­‐Premises
In
the
Cloud

25. 25
Infrastructure
Security:
On-­‐Premises
or
In
the
cloud
• Setup
different
subnets
for
each
one
of
the
layers
of
your
infrastructure
(at
least
one
for
Web
frontend
servers
and
one
for
backend
servers)
• Control
all
traffic
between
the
subnets
with
firewall
ACLs
(also
inbound/outbound)
• If
there’s
traffic
that’s
not
allowed
between
a
frontend
and
a
backend
server
then
have
your
Intrusion
Detection
System
raise
an
alarm
• Use
GRSecurity
if
you
run
Linux,
use
EMET
if
you
run
Windows
• Update
all
your
systems
periodically
• Install
a
Host
Intrusion
Detection
(HIDS),
e.g.
OSSEC
Secure your Infrastructure

26. 26
Infrastructure
Security:
On-­‐Premises
or
In
the
cloud
• If
you
decide
to
go
to
the
cloud:
• Be
careful
with
the
account
with
admin
privileges,
choose
a
strong
and
unique
password
plus
2-­‐FA
or
if
possible
require
VPN
to
access
the
management
console.
• Choose
one
of
the
top
cloud
providers,
where
security
has
been
scrutinized
• Cloud
providers
offer
some
sort
of
network
DDoS
protection
• Can
offer
email
protection
(malware,
spam,
phishing)
too
• You
can
have
a
mixed
solution
(cloud
and
on-­‐premises)
• Weigh
the
Pros
and
Cons
of
each
Secure your Infrastructure

27. 2
Build Secure Software
Adopt
SSDLC
My
advice
from
almost
6
years
of
experience
in
this
area:
• If
you
have
a
security
team,
they
should
be
close
to
developers.
When
developers
go
to
the
security
team
ask
for
advice
on
a
regular
basis
you
know
you
got
it
right.
• Training
developers
on
Secure
Programming
really
works
• Introducing
security
early
in
the
project
saves
everyone
time
at
the
end
• Do
Pentesting
before
going
live
and
periodically
(at
least
1x
year)

28. 28
Build Secure Software
Take
into
consideration
OWASP
TOP10

29. 29
Build Secure Software

30. 30
Build Secure Software
• A
significant
part
of
Data
Leaks
today
are
due
to
SQLi
vulnerabilities
• If
you
use
Prepared
Statements
when
writing
your
SQL
queries,
say
bye-­‐bye
to
SQLi
• Encrypt
your
sensitive
data
before
storing
it
in
the
database
(do
not
store
the
encryption
key
there!)
• There’s
no
excuse
these
days
for
introducing
new
SQLi
vulnerabilities
in
code

31. 31
Build Secure Software

32. 32
Build Secure Software
Some
advice:
• Use
HTTPS
• Hash
the
password
before
storage
(hint:
HMAC)
• If
authentication
fails
don’t
say
that
it’s
the
username
that
does
not
exist
or
that
it’s
the
password
that
is
wrong,
give
a
generic
message
instead
• Re-­‐authentication
should
be
required
before
any
application-­‐
specific
sensitive
operations
are
permitted,
such
as
for
changing
the
password
Authentication
et
al.

33. 33
Build Secure Software
Some
advice:
• Do
you
allow
“a
single
account
tested
against
all
possible
passwords”?
(vertical
bruteforcing)
• What
about
“all
accounts
tested
with
the
same
password
e.g.
123456”?
(horizontal
bruteforcing)
• Use
an
outbound
channel
for
account
recovery
and
apply
the
same
security
controls
as
for
authentication
(like
when
storing
the
recovery
token,
throttling,
re-­‐authentication
for
changing
the
recovery
elements,
etc)
• Avoid
using
security
questions
for
account
recovery
Authentication
et
al.

34. 34
Build Secure Software
Always
check
if
the
user
is
authorized
to
access
the
required
object!

35. 35

36. Este documento é propriedade intelectual da PT e fica proibida
a sua utilização ou propagação sem expressa autorização escrita.
SAPO Security Team
The
END
Nuno
Loureiro
nuno@co.sapo.pt