This presentation draws from my recent blog post “Journey to Self Hosting” and many more resources for some high-level ideas about cloud solutions. I'll discuss what's good and what's not good about "The Cloud." I’ll provide an overview of the many security issues that entities need to think about when deciding whether to use the cloud or to build in-house infrastructure. Owning the technical expertise isn't always necessary. On the other hand, in-house solutions can provide finer grained customized solutions with potential for greater visibility and control than can cloud offerings that are more generic. I'll also discuss my personal journey and what I've discovered along the way, including how you can make the right decisions based on others’ experiences and learn from their mistakes rather than your own.
If you download a copy, you can access the links which lead to detailed steps on how I carried out this work
##############################################################
Sign Posts: Identify Assets (slide 2)
##############################################################
I've used Bruce Schneier's Sensible Security Model to organise my content into five sections.
You shouldn't just be running through this set of steps once. It needs to be continuous
##############################################################
1: Asset Identification (slide 3)
Threat Modelling
##############################################################
It's worthwhile getting familiar with the threat modelling approaches, resources and templates available.
Just google "Threat Modelling" and take notice of the OWASP & Microsoft results.
Also checkout the BSimm resources
Some threat modelling approaches actually miss this vital first part of Identifying the Assets you're trying to protect.
##############################################################
1: Asset Identification (slide 4)
Burning Books
##############################################################
I've read a bunch of cloud security books by well known authors.
All of them have been far too high level to be of any use to me.
When it comes down to the metal, cloud security is not really any different to most other information security.
The biggest issue I see is the people behind it.
In fact, people are at the root of just about all of our security failures.
##############################################################
1: Asset Identification (slide 5)
Cart Before Horse
##############################################################
No point coming up with security solutions without understanding what your trying to protect.
What are your assets?
What's actually important to you and/or your business?
This will be different for every business.
In many cases it comes down to organisation or client secretes.
##############################################################
1: Asset Identification (slide 6)
Even Banks Can't Get it Right
##############################################################
All the public places we store our details on line are open to similar concerns.
Accounting systems. Even banks.
These are the banks in NZ that use HSTS header
Now if even our banks can't get it right, what hope do we have for cloud providers?
##############################################################
1: Asset Identification (slide 7)
Even Banks Can't Get it Right
##############################################################
AU banks that use the HSTS header
By using a cloud service, you are relinquishing your information.
There will soon be no secrets unless we rethink and start taking better care of our information.
How much of the EULA's that have the right to change at any time, do you actually read when you sign up for a cloud service?
##############################################################
Sign Posts: Identify Risks (slide 8)
##############################################################
##############################################################
2: Identify Risks (slide 9)
Blue cloud
##############################################################
As part of identifying your risks, you need to establish who your threat agents / opponents are.
Other businesses, insiders? Opportunists or targeted attacks.
Adopting the mindsets of your opponents and attackers will help you work out what they're after
& thus what your assets are.
The OWASP Risk Rating Methodology and the Intel Threat Agent Library (TAL)...
are excellent resources for working out your risks.
##############################################################
2: Identify Risks (slide 10)
Risk Equation
##############################################################
Now that we know what we want protected (our assets)
We need to identify the risks to the things that matter to you and your organisation
by applying a rating to every risk that you identify.
##############################################################
2: Identify Risks (slide 11)
Threat Agent Connections
##############################################################
How might your threat agents gain access?
There is a lot of common ground between yourself and your adversaries.
You've got: Competing organisations, (X)employees, contractors, operational/maintenance personnel.
Talk about some of Leannes stories as a cleaner.
##############################################################
2: Identify Risks (slide 12)
Likelihood: Threat Agent Factors
##############################################################
How likely are particular exploits to be carried out?
How technically skilled is each group of threat agents?
How motivated is this group of threat agents to find and exploit this vulnerability?
What resources and opportunities are required for this group of threat agents to find and exploit this vulnerability?
What sort of access can they acquire?
How large is this group of threat agents?
##############################################################
2: Identify Risks (slide 13)
Likelihood: Vulnerability Factors
##############################################################
What about factors related to the vulnerability involved like:
How easy is it for this group of threat agents to discover this vulnerability?
How easy is it for this group of threat agents to actually exploit this vulnerability?
How well known is this vulnerability to this group of threat agents?
How likely is an exploit to be detected?
##############################################################
2: Identify Risks (slide 14)
Impact: Technical Factors
##############################################################
What's the impact likely to be if a particular exploit is executed
How much data could be disclosed and how sensitive is it?
How much data could be corrupted and how damaged is it?
Which services could be lost, how vital are they and how long could they be down for?
Would you be able to trace the threat agents actions to an individual?
##############################################################
2: Identify Risks (slide 15)
Impact: Business Factors
##############################################################
What would the financial damage be to any given exploit?
Would the exploit result in reputation damage that would harm the business?
How much exposure does non-compliance introduce?
How much personally identifiable information could be disclosed?
##############################################################
2: Identify Risks (slide 16)
The Cloud vs In-House 1st
##############################################################
Walk through some potential risks now.
Secrets not safe in the Cloud. Often a false sense of security
--------------- > security, visibility, ownership & control
Trusting others with your data & ultimately your life. Even others that you're not aware of
--------------- You’ve only got you & your workers 2 blame. Get involved, hire honourable & trustworthy people
Limited (at best) visibility into hardening process your CSP takes. Get what you're given.
--------------- Can't cover all potential attack vectors, cover low hanging fruit, work up tree.
You are nothing but a number to your CSP. No empathy.
--------------- You have Influence & control empathy your workers have for you.
--------------- It’s your domain & your clients.
--------------- Personal relationships vs a number.
In many cases, hosting providers can be (and in many cases are)
forced by governments and other agencies to give up your secrets.
Very common place now & you may not even know it’s happened.
--------------- Your decision whether or not to yield if/when pressure is applied to you.
--------------- You are probably a smaller target.
--------------- You’ll know if it happens. React accordingly.
##############################################################
2: Identify Risks (slide 17)
The Cloud vs In-House 2nd
##############################################################
Provider may go out of business. No prepare time.
---------------Hopefully you’ll have strategies in place to protect yours & your clients secrets.
In all the cloud providers I’ve looked at & worked with.
They’ll tell you they take security seriously,
ask for proof: answers leave too much to imagination
Solution often looks like Swiss cheese
---------------It's up to you how seriously you take your security.
---------------You can have as much or as little as you desire.
CSP’s are outsourcing their outsourced services to several providers deep.
They don't even have visibility themselves. Control is lost.
---------------How far do you want to go? You decide where services & data reside.
> distribution = > attack surface. Where is your data?
Where are your VM images running from?
Further distributed on iSCSI targets? Where are targets?
---------------You know where all of your servers are.
What does your physical security look like with your cloud provider?
Make sure you or your technical people understand what the lack of visibility means.
---------------Looks how you want it to look.
##############################################################
2: Identify Risks (slide 18)
The Cloud vs In-House 3rd
##############################################################
What does your CSP know about your domain? Nothing.
If they don't know anything about how you operate, how are they supposed to protect you?
---------------You are the ultimate expert of your own domain.
---------------Only you know exactly what you want protected.
##############################################################
2: Identify Risks (slide 19)
Control Lost
##############################################################
What control do you have that if you're data in the cloud has been compromised you actually know about it
& can invoke your incident response team(s) & procedures?
Pretty much none.
In most cases our CSP's have no responsibility to tell us when our data has been yielded to government organisations
& in many cases other entities.
CSP's are readily giving up your secrets to government organisations and the highest bidders.
In many cases you won't know about it.
##############################################################
2: Identify Risks (slide 20)
What to Fix
##############################################################
What you decide to fix first will be determined by the highest scoring risks.
##############################################################
Sign Posts: Countermeasures (slide 21)
##############################################################
Countermeasures and how well do they mitigate the risks?
##############################################################
3: Countermeasures (slide 22)
Comparison
##############################################################
Staying on top of security will need to be done whether you're on someone else's hardware
that you often have no idea of it's physical location & must trust people
that are trusting other people that are trusting other people you don't know
---------------Applying countermeasures to your own infrastructure is not easy, but simple
##############################################################
3: Countermeasures (slide 23)
AppSensor
##############################################################
Most apps today just take attacks & fall over.
I've heard so many times we want our applications to fail securely when they get bad input
Screw that. We don't want our apps being bullied and failing securely,
we want them to not fail at all in prod, but rather defend themselves.
WAF's detect application generic attacks like basic SQLi & known attack sequences.
WAF’s know more about your applications than NIDS/HIDS, but
only your application can and should know how to protect itself.
AppSensor project defines a conceptual framework & methodology
that offers prescriptive guidance to implement intrusion detection &
automated response into applications.
Creating Attack aware software apps with real-time defences.
> 50 (signature based) detection points.
Provides guidance on how to respond once attack identified.
Possible actions include:
logging out the user,
locking the account or notifying an administrator,
more than a dozen response actions are described.
##############################################################
3: Countermeasures (slide 24)
Crypto
##############################################################
Often commercial encryption software or services have backdoors for the likes of the NSA.
Especially from large vendors.
Use public-domain open source encryption software that has to be compatible with other implementations…
rather than proprietary implementations whose backdoors are far less likely to be discovered.
##############################################################
3: Countermeasures (slide 25)
Files, Drives
##############################################################
Encrypt Your Files with GPG/PGP. Very easy. All platforms.
Encrypt Your Drives
TrueCrypt. Very easy. All platforms.
VeraCrypt is a fork of the TrueCrypt project that has fixed all of the serious security issues & weaknesses discovered so far in the source.
The Open Crypto Audit Project released phase 2 of their cryptanalysis on Feb 18 2015 for TrueCrypt & continue to work on it.
##############################################################
3: Countermeasures (slide 26)
Hardening VPS's 1st
##############################################################
Mention embedded links
Ideally the process of hardening should be done to a clean system before it's opened up to the internet.
I usually do this on a segment with few other nodes on it.
Otherwise you'll have less trust of the state of the system &
you could be benchmarking already compromised components
Create partitions based on their purpose.
Apply the concept of least privilege to each
The Linux FHS is a good starting point.
Make sure passwords are encrypted with an algorithm that will stand up to the types of attacks you anticipate.
There are a handful of files to check & modify for disabling root logins.
Key-pairs, Long passphrases. Appropriate changes to sshd_config file.
AllowUsers.
Specify Host(s).
Consider non default port below 1025 that only root can bind to stop the sshd being swapped.
##############################################################
3: Countermeasures (slide 27)
Hardening VPS's 2nd
##############################################################
Disabling or removing the services you don't need.
Can be surprising how much attack surface area you can remove:
Portmapper, Exim, Rpcbind, Telnet, Ftp, etc
Harden what's left.
Make sure all data & VM images are backed up routinely. Test your backups.
Consider setting up auto updates.
There are many options for off-site logging. Evaluated in depth on my blog.
Attackers cover their tracks.
Real-time off-site logging makes it much harder for them to erase or modify logs.
I have alerts set-up on my off-site facility to notify me of certain log events
& even lack of certain events.
##############################################################
3: Countermeasures (slide 28)
Hardening VPS's 3rd
##############################################################
I've setup and evaluated a good number of intrusion detection/prevention systems.
Tripwire, RkHunter, Chkrootkit, Stealth, Ossec, Unhide
I did a fairly lengthy evaluation of OSSEC & Stealth File Integrity Checker
##############################################################
3: Countermeasures (slide 29)
Firewall rules
##############################################################
Keep your firewall rules to a minimum to reduce confusion and increase legibility.
Both ingress & egress.
##############################################################
3: Countermeasures (slide 30)
Monitoring
##############################################################
Application & System Monitoring Systems:
Internal & external looking in.
I evaluated tools to keep your applications alive and healthy
---Evaluated forever(NodeJS), PM2(NodeJS), Supervisor and Monit.
---Monit does a plethora of tests & checks:
------files, dirs, disks, processes, response times, emergency log rotates.
I use defence in depth here.
using several tools to do similar jobs,
all having different sweet spots that look after the other tools weaker spots.
Init systems "Sysvinit, Upstart, systemd & Runit" all run as PID 1
I've written unit files to keep monitoring daemons running.
If they have to be restarted I'm notified by multiple sources.
##############################################################
3: Countermeasures (slide 31)
Incident Response
##############################################################
Make sure you've established an Incident Response Team.
There are guides on how to do this and what you'll need.
This is one of them.
Also Bruce Schneier's talk on Incident Response (Youtube).
##############################################################
3: Countermeasures (slide 32)
Break Your System
##############################################################
Create Penetration Test plan -> execute -> Don't forget gorilla testing as it's very effective.
Report on findings and provide directions of how to mitigate.
Once you've got your hardening to a state that you're happy with
and have the system under active monitoring, only then should you open it up to the internet.
##############################################################
Sign Posts: Risks that security solution causes (slide 33)
##############################################################
There will be new risks that the mitigation techniques introduce.
What are they?
##############################################################
4: Risks that security solution causes (slide 34)
New Risks
##############################################################
If you penetration test certain areas of your CSP's offering →you'll probably get into trouble.
---------------You decide on your test strategy.
##############################################################
4: Risks that security solution causes (slide 35)
New Risks. Break
##############################################################
---------------Break your system before someone else does... and they will... if you don't.
##############################################################
4: Risks that security solution causes (slide 36)
New Risks. Clock
##############################################################
It takes time to:
---Find skilled workers
---gain expertise
---setup and configure
This time maybe to expensive for you.
Make sure you're informed and carefully consider the alternatives.
##############################################################
4: Risks that security solution causes (slide 37)
New vs Mitigated risks
##############################################################
Are the new risks of a lesser weight than the mitigated risks?
Only you can decide.
If you implement AppSensor, you'll have more code to test.
More code is more code that can go wrong.
Crypto and many other security solutions incur performance penalties.
Many of the points I've raised around VPS hardening require maintenance.
Personally, I'm just not prepared to take short-cuts when it comes to security.
My clients data & identities to me are priceless. I'm not prepared to sacrifice them.
##############################################################
Sign Posts: Costs and trade-offs (slide 38)
##############################################################
How much are you prepared to give up to get the job done?
##############################################################
5: Costs and trade-offs (slide 39)
Establish Value, Loss of Convenience
##############################################################
You need to establish the value of your assets &
weigh the loss of, against cost of security implementation.
There is often a loss of convenience incurred.
You need to be able to measure & be prepared for this.
If it's a product you're trying to get to market, it may take you longer to get it there.
Even though once it's there it's more likely to stay there.
This is why you must have experienced people responsible for carrying out the work.
##############################################################
5: Costs and trade-offs (slide 40)
Staying on Top
##############################################################
Keeping a system secure is a never ending job.
Either you give the job to your CSP, bury your head in the sand &
they will almost certainly fail at it.
You may get away with it for some time,
Or accept that it's hard, they're going to fail and thus take the responsibility yourself.
Cloud offerings are often seen as "Lets just let someone else take care of it",
but surprisingly are often more expensive in monetary terms for medium to large environments.
##############################################################
Resource Compilation (slide 41)
##############################################################
I'm compiling a suite of resources & tools that will help you work through what we’ve just covered:
To assess How Secure/insecure your cloud solution is & how to move forward
To discover how to automate installation, configuration & maintenance with tools such as:
Puppet, Chef, Capistrano & Vagrant
My company BinaryMist is also working on a project that:
Offers a customised security focused hosting facility.
Allows you to plan out your own secure in-house cloud
Address using the likes of ownCloud, OpenStack, Apache CloudStack &
GreenQloud's QStack, a hybrid offering based on CloudStack, an In-house cloud with potential to burst to
GreenQloud's infrastructure.
binarymist
opelab
ishiitaiki20fixer
yayoi_dd
oracle4engineer
41h0_shiho
yuj1osm
kouzoukaikaku
takumanakagame
yumechi
miekobayashi
kinyok
revolveconf
brettharned
scottboms
rasmusluckow
paulrobertlloyd
rocio
jacobian
chriscoyier
tammielis
malarkey
quramy
eitanlees
