The Cloud is NOT just someone else's computer

1. Cloud Security Strategy
Overview
Wednesday, July 18, 2018

2. 2
The Cloud Is Someone Else’s
Computer

3. 3
Like A Highway is Someone
Else’s Driveway

4. 4
Of Course Datacenters Vary

5. 5
But Trying to Replicate Internal
Processes Misses the Point

6. 6
Controls That Are Useful on One
Have Less Value on the Other

7. 7
Enforcing legacy processes is
counter productive
Multiplying resources (or people)
doesn’t help it makes things worse
If the control is needed it
MUST be automated

8. 8
Effective Cloud Controls
• The point is the cloud is always changing
– Cloud Control Strategy Must deal with that
– Cloud Controls MUST be continually developed
• Must be Automated
• Must be Specific to the Use
• Must be Integrated
• Should be Dynamically Configurable
• Should be simple, granular, fractal

9. 9
Cloud Security Journey Map
Inherent Encryption – Ante Nothing without this
Data Tagging (Micro-services)
Safe Data Anywhere
Federation
Passwords Optional, FinTech Integrations, secure
SaaS/ASP Connections, B2B convenience, First step for
Cloud IaaS services
Any Customer
Any Data
Any Cloud
Micro Segmentation
Automated Cloud
Infrastructure, Contain the Bad
Non-Persistence
No more patching !!!
Hacks Decay
Secure Scaling
Transient Secrets
Faster Developer
Integrations
Integration possible to:
Machine Learning
NLP Capabilities
Agents/Assistants
External API Dev

10. 10
Important Cloud Security Concepts
1. Inherent Encryption – TLS based encryption is used for all in transit
communications. All data at rest is encrypted at a minimum by the
environment.
2. Transient Secrets – Keys and secrets used to provide access and
sometimes to encrypt data are vaulted and frequently changed
3. Federation – All access between cloud environments are authenticated
and able to be tied back to the requestor and the mechanism to do so is
cryptographically enforced
4. Micro-segmentation – By default environments built in the cloud do not
have access to each other. Specific access patterns using Federation
usually to oauth protected API’s is used. Other access such as network
access must be specifically configured and is usually unnecessary.
5. Non Persistence (Elastic) – Operating System based entities in the cloud
should not exist perpetually. Ideally they only exist for a few hours before
being rebuilt from scratch.
6. Data Tagging (Micro Services) – Most cloud environments tag every
piece of data created, changed and stored with information keys that can
be used to identify owners, transactions and access permissions

11. 11
Micro-Segmentation/Containerization
Identity Services
Key Vault
Remote
Storage
oauth/oidc
protected
API’s
Internal Directories
Internal
Db’s and
Services
Micro-Segmented Container

12. 12
Governance in the Cloud becomes the Development Effort
• Create Patterns that are Secure for their specific use case
• Develop Code to Implement these Patterns
• Implement and automate these patterns
• Approve a Pipline not an application
• Developers to use these patterns freely
• If the developers are in an “Approved” Pipeline their oversight requirements are minimal
• Work With the Developers to Expand the use cases automated in the pipeline and to create
new patterns
• If a Pipeline isn’t or cannot use these patterns then Legacy control reviews MUST still be
used for that pipeline

13. 13
Appendix