The document discusses a presentation given by Bill Burns, Sr. Manager of Networks & Security at Netflix, to the CISO Executive Forum on February 26, 2012 about Netflix's move to scaling operations in the cloud. The presentation covered Netflix's background and engineering-centric culture, the reasons for moving to the cloud including availability, capacity and agility. It also discussed the information security challenges of running in an IaaS cloud, such as confidentiality, integrity, availability and possession/control of systems. The presentation showed how Netflix addressed these challenges through automation, embedded security controls, and tools like the Simian Army that induce failures to test availability.
1. Scaling
the
Cloud
Bill Burns
Sr. Manager, Networks &
Security
CISO Executive Forum
February 26, 2012
Thursday, March 8, 12
2. Agenda
• Netflix Background and Culture
• Why We Moved to the Cloud
• InfoSec Challenges in an IaaS Cloud
• InfoSec Perspective: Running In The Cloud
Thursday, March 8, 12
3. Netflix
Business
(c) 2011 Sandvine
Thursday, March 8, 12
4. Netflix
Business
• 24+ million members globally
(c) 2011 Sandvine
Thursday, March 8, 12
5. Netflix
Business
• 24+ million members globally
• Streaming in 47 countries
(c) 2011 Sandvine
Thursday, March 8, 12
6. Netflix
Business
• 24+ million members globally
• Streaming in 47 countries
• Watch on more than 700
devices
(c) 2011 Sandvine
Thursday, March 8, 12
7. Netflix
Business
• 24+ million members globally
• Streaming in 47 countries
• Watch on more than 700
devices
• 33% of US peak evening
Internet traffic
(c) 2011 Sandvine
Thursday, March 8, 12
8. Background and
Context
• High Performance Culture
• Fail Fast, Learn Fast ... Get Results
• Core Value: “Freedom & Responsibility”
Thursday, March 8, 12
9. Engineering-
Centric Culture
Thursday, March 8, 12
10. Engineering-
Centric Culture
• Sought the Cloud for Availability, Capacity
• ...and also found Agility
Thursday, March 8, 12
11. Engineering-
Centric Culture
• Sought the Cloud for Availability, Capacity
• ...and also found Agility
• DevOps / NoOps means engineering teams own:
• New deployments and upgrades
• Capacity planning & procurement
Thursday, March 8, 12
12. Freedom
&
Responsibility
Thursday, March 8, 12
13. Freedom
&
Responsibility
Thursday, March 8, 12
18. Demand vs Capacity
37x growth in
13 months
DataCenter
Capacity
Thursday, March 8, 12
19. Cloud:
On-
Demand
Capacity
Thursday, March 8, 12
20. Demand
1
Cloud:
On-
Demand
Capacity
1. Demand: Typical pattern
of customer requests rise
& fall over time
Thursday, March 8, 12
21. Demand
1
Cloud:
On-
Demand # Servers
Capacity
2
1. Demand: Typical pattern
of customer requests rise
& fall over time
2. Reaction: System
automatically adds,
removes servers to the
application pool
Thursday, March 8, 12
22. Demand
1
Cloud:
On-
Demand # Servers
Capacity
2
1. Demand: Typical pattern
of customer requests rise
& fall over time
Utilization
2. Reaction: System
automatically adds,
removes servers to the
application pool 3
3. Result: Overall utilization
stays constant
Thursday, March 8, 12
23. InfoSec
Confiden"ality' Challenges
In An IaaS
U"lity' Integrity'
Cloud
Authen"city' Availability'
Possession'
Thursday, March 8, 12
24. InfoSec Challenge
in an IaaS Cloud ::
Confidentiality
Thursday, March 8, 12
25. InfoSec Challenge
in an IaaS Cloud ::
Integrity
Thursday, March 8, 12
26. InfoSec Challenge
in an IaaS Cloud ::
Availability
Thursday, March 8, 12
27. InfoSec Challenge
in an IaaS Cloud ::
Possession/Control
Thursday, March 8, 12
28. InfoSec Challenge
in an IaaS Cloud ::
Authenticity
Thursday, March 8, 12
29. InfoSec Challenge
in an IaaS Cloud ::
Authenticity
Thursday, March 8, 12
30. InfoSec Challenge
in an IaaS Cloud ::
Authenticity
Thursday, March 8, 12
31. InfoSec Challenge
in an IaaS Cloud ::
Authenticity
Thursday, March 8, 12
32. Running In
The Cloud ::
InfoSec
Perspective
Thursday, March 8, 12
33. Running In
The Cloud ::
InfoSec
Perspective
Thursday, March 8, 12
34. Running In
The Cloud ::
InfoSec
Perspective
Thursday, March 8, 12
35. Running In
The Cloud ::
InfoSec
Perspective
Thursday, March 8, 12
36. InfoSec In
The Cloud ::
Harder
Thursday, March 8, 12
37. InfoSec In
The Cloud ::
Harder
1.“You’re host attacked me
yesterday. Please stop!”
Thursday, March 8, 12
38. InfoSec In
The Cloud ::
Harder
1.“You’re host attacked me
yesterday. Please stop!”
2.Dealing with other people’s traffic
at your front door
Thursday, March 8, 12
39. InfoSec In
The Cloud ::
Harder
1.“You’re host attacked me
yesterday. Please stop!”
2.Dealing with other people’s traffic
at your front door
3.Herding ephemeral instances
with vendor applications
Thursday, March 8, 12
40. InfoSec In
The Cloud ::
Harder
1.“You’re host attacked me
yesterday. Please stop!”
2.Dealing with other people’s traffic
at your front door
3.Herding ephemeral instances
with vendor applications
4.Trusting endpoints, infrastructure
Thursday, March 8, 12
41. InfoSec In
The Cloud ::
Harder
1.“You’re host attacked me
yesterday. Please stop!”
2.Dealing with other people’s traffic
at your front door
3.Herding ephemeral instances
with vendor applications
4.Trusting endpoints, infrastructure
5.Key management
Thursday, March 8, 12
43. InfoSec In The
Cloud :: Easier
1.Reacting to business velocity 6.Embedding security controls
2.Detecting instance changes 7.Least privilege enforcement
3.Application ownership,
management 8.Testing/auditing for
conformance
4.Patching, updating
5.Availability, in a failure-prone 9.Consistency, conformity in
environment build and launch
Thursday, March 8, 12
44. Old IT way:
Hand-Crafted
configuration
(C) courtesy: Flikr (piper, viamoi)
Thursday, March 8, 12
45. Old IT way:
Hand-Crafted
configuration
(C) courtesy: Flikr (piper, viamoi)
Thursday, March 8, 12
47. Change
Controls ::
Patching
• Goal: Running instances do not get patched
• Alternative:
• Bake a new AMI for any change
• Launch new instances in parallel
• Kill the old instances
Thursday, March 8, 12
48. Change
Controls ::
Upgrades
• Bake a new AMI for any
change
• Launch new instances
in parallel
• Kill the old instances
Lesson Learned: Make the
secure, consistent
behavior the easier
alternative.
Thursday, March 8, 12
49. Availability ::
Never Launch
One of Anything
(c) Courtesy Flikr - Winton
Thursday, March 8, 12
50. Availability ::
Never Launch
One of Anything
•Chaos Monkey induces failures,
helps us practice recovery
(c) Courtesy Flikr - Winton
Thursday, March 8, 12
51. Availability ::
Never Launch
One of Anything
•Chaos Monkey induces failures,
helps us practice recovery
•Balance across Availability
Zones
(c) Courtesy Flikr - Winton
Thursday, March 8, 12
52. Availability ::
Never Launch
One of Anything
•Chaos Monkey induces failures,
helps us practice recovery
•Balance across Availability
Zones
•Applications automatically
scale-out, regenerate
(c) Courtesy Flikr - Winton
Thursday, March 8, 12
53. Availability ::
Never Launch
One of Anything
•Chaos Monkey induces failures,
helps us practice recovery
•Balance across Availability
Zones
•Applications automatically
scale-out, regenerate
•Conformity Monkey detects
differences, improper settings
(c) Courtesy Flikr - Winton
Thursday, March 8, 12
54. Identity
Challenges ::
Vendors Lagging
Thursday, March 8, 12
55. Identity
Challenges ::
Vendors Lagging
• Cloud instances are ephemeral
• Customers cannot necessarily pick
their IP addresses, ranges
• Instances need to base context on
apps, services, tagging (not IPs)
• Vendors need better support for
ephemeral licensing, stateless
instances, self-config
Thursday, March 8, 12
56. Identity
Challenges ::
Vendors Lagging
• Cloud instances are ephemeral
• Customers cannot necessarily pick
their IP addresses, ranges
• Instances need to base context on
apps, services, tagging (not IPs)
• Vendors need better support for
ephemeral licensing, stateless
instances, self-config
• Machine capacity is no longer a
CapEx friction item.
Thursday, March 8, 12
57. Conformity
&
Consistency
Thursday, March 8, 12
58. Conformity
&
Consistency
Thursday, March 8, 12
59. Automation =
Conformity
&
Consistency
Thursday, March 8, 12
60. Automation =
Conformity
&
Consistency
• All apps, tiers are
Highly Available
• Secure defaults
applied automatically
• Replacement
instances look just like
the originals
Thursday, March 8, 12
61. Automation =
Conformity
&
Consistency
• All apps, tiers are
Highly Available
• Secure defaults
applied automatically
• Replacement
instances look just like
the originals
Thursday, March 8, 12
62. Baked-In
Security
Controls ::
Netflix
Simian Army
• Cloud Ready Dashboard
• Identify and test
common failure modes
• Continuous, aggressive
monitoring, testing
• Mostly opt-In
Thursday, March 8, 12
63. Baked-In
Security
Controls ::
Netflix
Simian Army
• Cloud Ready Dashboard
• Identify and test
common failure modes
• Continuous, aggressive
monitoring, testing
• Mostly opt-In
Thursday, March 8, 12
64. Baked-In
Security
Controls ::
Netflix • Chaos Monkey - Randomly kills instances
Simian Army
• Cloud Ready Dashboard
• Identify and test
common failure modes
• Continuous, aggressive
monitoring, testing
• Mostly opt-In
Thursday, March 8, 12
65. Baked-In
Security
Controls ::
Netflix • Chaos Monkey - Randomly kills instances
Simian Army
• Conformity Monkey - Various policy checks
• Cloud Ready Dashboard
• Identify and test
common failure modes
• Continuous, aggressive
monitoring, testing
• Mostly opt-In
Thursday, March 8, 12
66. Baked-In
Security
Controls ::
Netflix • Chaos Monkey - Randomly kills instances
Simian Army
• Conformity Monkey - Various policy checks
• Cloud Ready Dashboard • Latency Monkey – Induces random latency
• Identify and test
common failure modes
• Continuous, aggressive
monitoring, testing
• Mostly opt-In
Thursday, March 8, 12
67. Baked-In
Security
Controls ::
Netflix • Chaos Monkey - Randomly kills instances
Simian Army
• Conformity Monkey - Various policy checks
• Cloud Ready Dashboard • Latency Monkey – Induces random latency
• Identify and test • Janitor Monkey – Kills orphaned instances
common failure modes
• Continuous, aggressive
monitoring, testing
• Mostly opt-In
Thursday, March 8, 12
68. Baked-In
Security
Controls ::
Netflix • Chaos Monkey - Randomly kills instances
Simian Army
• Conformity Monkey - Various policy checks
• Cloud Ready Dashboard • Latency Monkey – Induces random latency
• Identify and test • Janitor Monkey – Kills orphaned instances
common failure modes
• Continuous, aggressive • Security Monkey – Various security checks
monitoring, testing
• Mostly opt-In
Thursday, March 8, 12
69. Baked-In
Security
Controls ::
Netflix • Chaos Monkey - Randomly kills instances
Simian Army
• Conformity Monkey - Various policy checks
• Cloud Ready Dashboard • Latency Monkey – Induces random latency
• Identify and test • Janitor Monkey – Kills orphaned instances
common failure modes
• Continuous, aggressive • Security Monkey – Various security checks
monitoring, testing
• Exploit Monkey – Vuln Scans / Pen Tests
• Mostly opt-In
Thursday, March 8, 12
71. Embedded
Security
Controls
Thursday, March 8, 12
72. Embedded
Security
Controls
• Controls baked into the “base AMI”
• Controls placed near the data
• Applied as machines die/reborn
Thursday, March 8, 12
73. Embedded
Security
Controls
• Controls baked into the “base AMI”
• Controls placed near the data
• Applied as machines die/reborn
• Security controls are “Data Center
agnostic”
• Provide a “single pane of glass”
awareness
• Span all regions, data centers
Thursday, March 8, 12
75. CISO Forum
Take-Aways
1. The public cloud / IaaS is not just a technology.
2. Cloud IaaS is disruptive to Operations, Engineering, Vendors, Auditors.
3. Your Data is your new perimeter.
4. Design for failures in everything.
5. IaaS providers care about their infrastructure.
6. Public cloud Information Security is still about the basics, but in a new context.
7. There’s still plenty left to resolve, like trusted infrastructure, strong key
management, COTS support.
Thursday, March 8, 12
Why did Netflix migrate to the public Cloud?\nWhich InfoSec controls were harder or easier in the Cloud?\nWhat’s left to solve?\n\nRunning in a public cloud is less about virtualization and more about disrupting how you currently deliver services. Here’s the infosec lens on how Netflix is migrating to the Cloud.\n\nAugments Jason Chan’s “Practical Cloud Security” presentations.\n
I won’t spend a lot of time on background, but it’s important to cover the context so that you understand why we’re doing this.\n\nIn two years we went from “traditional IT” to running one of the largest public cloud infrastructures on Amazon.\n\nWhen I briefed the DoD CyberSecurity Task Force, they were shocked at the rate of our innovation. I thought 2 years was a long time; but they helped put things into perspective.\n\nThese ideas may seem strange to you. But you probably have teams doing this already, or are trying to achieve this, or you will acquire a company that does this now. I assert that many of these design and operations ideas will be the norm for new companies in less than 5 years.\n\n
(doubled subscribers in 2010, moved to cloud)\n3+ billion rev in 2011, S&P 500\n\nQ: Soon every TV sold anywhere in the world will have WiFi and Netflix built in \n\n
(doubled subscribers in 2010, moved to cloud)\n3+ billion rev in 2011, S&P 500\n\nQ: Soon every TV sold anywhere in the world will have WiFi and Netflix built in \n\n
(doubled subscribers in 2010, moved to cloud)\n3+ billion rev in 2011, S&P 500\n\nQ: Soon every TV sold anywhere in the world will have WiFi and Netflix built in \n\n
(doubled subscribers in 2010, moved to cloud)\n3+ billion rev in 2011, S&P 500\n\nQ: Soon every TV sold anywhere in the world will have WiFi and Netflix built in \n\n
(doubled subscribers in 2010, moved to cloud)\n3+ billion rev in 2011, S&P 500\n\nQ: Soon every TV sold anywhere in the world will have WiFi and Netflix built in \n\n
(doubled subscribers in 2010, moved to cloud)\n3+ billion rev in 2011, S&P 500\n\nQ: Soon every TV sold anywhere in the world will have WiFi and Netflix built in \n\n
(doubled subscribers in 2010, moved to cloud)\n3+ billion rev in 2011, S&P 500\n\nQ: Soon every TV sold anywhere in the world will have WiFi and Netflix built in \n\n
(doubled subscribers in 2010, moved to cloud)\n3+ billion rev in 2011, S&P 500\n\nQ: Soon every TV sold anywhere in the world will have WiFi and Netflix built in \n\n
(doubled subscribers in 2010, moved to cloud)\n3+ billion rev in 2011, S&P 500\n\nQ: Soon every TV sold anywhere in the world will have WiFi and Netflix built in \n\n
(doubled subscribers in 2010, moved to cloud)\n3+ billion rev in 2011, S&P 500\n\nQ: Soon every TV sold anywhere in the world will have WiFi and Netflix built in \n\n
(doubled subscribers in 2010, moved to cloud)\n3+ billion rev in 2011, S&P 500\n\nQ: Soon every TV sold anywhere in the world will have WiFi and Netflix built in \n\n
(doubled subscribers in 2010, moved to cloud)\n3+ billion rev in 2011, S&P 500\n\nQ: Soon every TV sold anywhere in the world will have WiFi and Netflix built in \n\n
We’re dev-focused so it was OK for us to build our own.\nDidn’t need to wait for industry to build shims and orchestration tools.\nAlso weren’t multi-CSP concerned at this point, YMMV. We’re also not in a regulated industry, so again YMMV.\n
In other words: the Cloud is not a technology, it’s more than virtualization. It’s a fundamentally different way of thinking about writing applications, providing computing services, and running your business.\n
In other words: the Cloud is not a technology, it’s more than virtualization. It’s a fundamentally different way of thinking about writing applications, providing computing services, and running your business.\n
(No Central architecture review boards, etc)\n(eliminated unnecessary complexity)\nLoosely-coupled, highly-aligned teams\nResponsible people thrive on, are worthy of freedom\nIncrease freedom as we grow, rather than limit it\nNetflix loves killing unnecessary processes\n
(No Central architecture review boards, etc)\n(eliminated unnecessary complexity)\nLoosely-coupled, highly-aligned teams\nResponsible people thrive on, are worthy of freedom\nIncrease freedom as we grow, rather than limit it\nNetflix loves killing unnecessary processes\n
(No Central architecture review boards, etc)\n(eliminated unnecessary complexity)\nLoosely-coupled, highly-aligned teams\nResponsible people thrive on, are worthy of freedom\nIncrease freedom as we grow, rather than limit it\nNetflix loves killing unnecessary processes\n
\n
\n
\n
\n
(doubled subscribers in 2010, moved to cloud)\nExample: Superbowl, Christmas scaling\n\nScale up early, scale down slowly\nprovision for AZ capacity\n\nWe now kill and respawn more Cloud servers every week than we have in our datacenter. It’s approaching a daily rate.\n
(doubled subscribers in 2010, moved to cloud)\nExample: Superbowl, Christmas scaling\n\nScale up early, scale down slowly\nprovision for AZ capacity\n\nWe now kill and respawn more Cloud servers every week than we have in our datacenter. It’s approaching a daily rate.\n
(doubled subscribers in 2010, moved to cloud)\nExample: Superbowl, Christmas scaling\n\nScale up early, scale down slowly\nprovision for AZ capacity\n\nWe now kill and respawn more Cloud servers every week than we have in our datacenter. It’s approaching a daily rate.\n
(doubled subscribers in 2010, moved to cloud)\nExample: Superbowl, Christmas scaling\n\nScale up early, scale down slowly\nprovision for AZ capacity\n\nWe now kill and respawn more Cloud servers every week than we have in our datacenter. It’s approaching a daily rate.\n
(doubled subscribers in 2010, moved to cloud)\nExample: Superbowl, Christmas scaling\n\nScale up early, scale down slowly\nprovision for AZ capacity\n\nWe now kill and respawn more Cloud servers every week than we have in our datacenter. It’s approaching a daily rate.\n
(doubled subscribers in 2010, moved to cloud)\nExample: Superbowl, Christmas scaling\n\nScale up early, scale down slowly\nprovision for AZ capacity\n\nWe now kill and respawn more Cloud servers every week than we have in our datacenter. It’s approaching a daily rate.\n
\n
Goal: Assume Man In The Middle\nCountermeasures / Mindset:\nEnd-to-end encryption\nMutual authentication\nEncrypt storage\nFBI warning\n
Countermeasures / Mindset:\nSegment key management from data usage\nSegment build / run environment\nTest for conformance, integrity\n
ASG for everything\nAWS fleet-wide patch\nApril 2011 outage of a single AZ in US-EAST\n\nCountermeasures / Mindset:\nNever depend on “one” of anything (host, AZ, etc)\nStateless design in running instances\nTest for conformity, alert on non-conformity\n
You can’t protect Software with More Software\nCountermeasures / Mindset:\nStrong key management\nSeparation of keys, data\nHardware key management\n
Hard\nCountermeasures / Mindset:\nSLA, CSP in your Incident Response plan, TEST!\nRely on your other CIAp controls\n
Hard\nCountermeasures / Mindset:\nSLA, CSP in your Incident Response plan, TEST!\nRely on your other CIAp controls\n
Hard\nCountermeasures / Mindset:\nSLA, CSP in your Incident Response plan, TEST!\nRely on your other CIAp controls\n
Hard\nCountermeasures / Mindset:\nSLA, CSP in your Incident Response plan, TEST!\nRely on your other CIAp controls\n
Some lessons learned, some aspirational and in-motion\nIt’s hard work to move your systems, processes, and staff into this new environment\nAt times, it’ll feel chaotic..like you’re herding sheep and they’re running every which way\nBut once you learn the vocabulary and understand this technology, you’ll come to appreciate it. It’s actually very enabling and refreshing.\n
Some lessons learned, some aspirational and in-motion\nIt’s hard work to move your systems, processes, and staff into this new environment\nAt times, it’ll feel chaotic..like you’re herding sheep and they’re running every which way\nBut once you learn the vocabulary and understand this technology, you’ll come to appreciate it. It’s actually very enabling and refreshing.\n
Some lessons learned, some aspirational and in-motion\nIt’s hard work to move your systems, processes, and staff into this new environment\nAt times, it’ll feel chaotic..like you’re herding sheep and they’re running every which way\nBut once you learn the vocabulary and understand this technology, you’ll come to appreciate it. It’s actually very enabling and refreshing.\n
Just like learning a new skill, it’s hard at first. Some things are still hard, but we’re working to make them easier. We’ll have some announcements in this space for everyone’s benefit, very exciting.\n
Just like learning a new skill, it’s hard at first. Some things are still hard, but we’re working to make them easier. We’ll have some announcements in this space for everyone’s benefit, very exciting.\n
Just like learning a new skill, it’s hard at first. Some things are still hard, but we’re working to make them easier. We’ll have some announcements in this space for everyone’s benefit, very exciting.\n
Just like learning a new skill, it’s hard at first. Some things are still hard, but we’re working to make them easier. We’ll have some announcements in this space for everyone’s benefit, very exciting.\n
Just like learning a new skill, it’s hard at first. Some things are still hard, but we’re working to make them easier. We’ll have some announcements in this space for everyone’s benefit, very exciting.\n
Just like learning a new skill, it’s hard at first. Some things are still hard, but we’re working to make them easier. We’ll have some announcements in this space for everyone’s benefit, very exciting.\n
Here’s a sample of what we’ve found to be easier, in our environment.\nWe’ll discuss some of these in more detail.\n
Here’s a sample of what we’ve found to be easier, in our environment.\nWe’ll discuss some of these in more detail.\n
Here’s a sample of what we’ve found to be easier, in our environment.\nWe’ll discuss some of these in more detail.\n
Here’s a sample of what we’ve found to be easier, in our environment.\nWe’ll discuss some of these in more detail.\n
Here’s a sample of what we’ve found to be easier, in our environment.\nWe’ll discuss some of these in more detail.\n
Here’s a sample of what we’ve found to be easier, in our environment.\nWe’ll discuss some of these in more detail.\n
Here’s a sample of what we’ve found to be easier, in our environment.\nWe’ll discuss some of these in more detail.\n
Here’s a sample of what we’ve found to be easier, in our environment.\nWe’ll discuss some of these in more detail.\n
Here’s a sample of what we’ve found to be easier, in our environment.\nWe’ll discuss some of these in more detail.\n
Classic IT: uptime was paramount. Rebooting was something you snickered at the Windows guys about.\n\nYou patched, and tweaked, and documented all your changes.\n\nAnd prayed to God that all those fixes and tweaks worked, and the system actually came back up the next time you restarted it.\n\nEvery instance was unique, a special snowflake.\n
Classic IT: uptime was paramount. Rebooting was something you snickered at the Windows guys about.\n\nYou patched, and tweaked, and documented all your changes.\n\nAnd prayed to God that all those fixes and tweaks worked, and the system actually came back up the next time you restarted it.\n\nEvery instance was unique, a special snowflake.\n
Classic IT: uptime was paramount. Rebooting was something you snickered at the Windows guys about.\n\nYou patched, and tweaked, and documented all your changes.\n\nAnd prayed to God that all those fixes and tweaks worked, and the system actually came back up the next time you restarted it.\n\nEvery instance was unique, a special snowflake.\n
We’ve been moving towards automation for a while now. The paradigm was to make adjustments to instances already running. The best models create “gold standard” images and deploy those.\n\nThe goal is to have every instance look exactly the same, run the same, and behave the same.\n\nWe’re taking a hard stance on this. We got here because of agility, but we have many security wins as a result.\n\n
It sounds heretical. Why patch when you can throw it away and start over?\n
Why bother fixing the configuration when you can deploy the “right” configuration from the start?\n\nThe same behavior for deploying new, for patching, and for upgrades means operations becomes simpler, easy to do/train/monitor.\n
Look at problems as opportunities. Rather than mandate 100% uptime from our CSP, we assumed the environment would be unpredictable. This forced us to build reliability into our applications and infrastructure.\n\nIn other words: the Cloud is not a technology, it’s more than virtualization. It’s a fundamentally different way of thinking about writing applications, providing computing services, and running your business.\n
Look at problems as opportunities. Rather than mandate 100% uptime from our CSP, we assumed the environment would be unpredictable. This forced us to build reliability into our applications and infrastructure.\n\nIn other words: the Cloud is not a technology, it’s more than virtualization. It’s a fundamentally different way of thinking about writing applications, providing computing services, and running your business.\n
Look at problems as opportunities. Rather than mandate 100% uptime from our CSP, we assumed the environment would be unpredictable. This forced us to build reliability into our applications and infrastructure.\n\nIn other words: the Cloud is not a technology, it’s more than virtualization. It’s a fundamentally different way of thinking about writing applications, providing computing services, and running your business.\n
Look at problems as opportunities. Rather than mandate 100% uptime from our CSP, we assumed the environment would be unpredictable. This forced us to build reliability into our applications and infrastructure.\n\nIn other words: the Cloud is not a technology, it’s more than virtualization. It’s a fundamentally different way of thinking about writing applications, providing computing services, and running your business.\n
Look at problems as opportunities. Rather than mandate 100% uptime from our CSP, we assumed the environment would be unpredictable. This forced us to build reliability into our applications and infrastructure.\n\nIn other words: the Cloud is not a technology, it’s more than virtualization. It’s a fundamentally different way of thinking about writing applications, providing computing services, and running your business.\n
\n
\n
Conformity:\nProvisioning: Can easily list every application running, all attributes including owner\nConformity Monkey checks for consistency , detects out-of-spec instances\nInconsistencies create runtime problems, outages, troubleshooting nightmares.\n* Lesson Learned: Identify failure modes, bake these test controls into your infrastructure.\n\nConsistency:\nAutomated software packaging, host build processes\nHands-off launch process; spans hosts, load balancers, security groups, etc.\nInstances are formed into “application groups”\n\n
Conformity:\nProvisioning: Can easily list every application running, all attributes including owner\nConformity Monkey checks for consistency , detects out-of-spec instances\nInconsistencies create runtime problems, outages, troubleshooting nightmares.\n* Lesson Learned: Identify failure modes, bake these test controls into your infrastructure.\n\nConsistency:\nAutomated software packaging, host build processes\nHands-off launch process; spans hosts, load balancers, security groups, etc.\nInstances are formed into “application groups”\n\n
Conformity:\nProvisioning: Can easily list every application running, all attributes including owner\nConformity Monkey checks for consistency , detects out-of-spec instances\nInconsistencies create runtime problems, outages, troubleshooting nightmares.\n* Lesson Learned: Identify failure modes, bake these test controls into your infrastructure.\n\nConsistency:\nAutomated software packaging, host build processes\nHands-off launch process; spans hosts, load balancers, security groups, etc.\nInstances are formed into “application groups”\n\n
All instances have:\n- ASG, SecGrp, ELBs, owners, description, email addr -- almost like a CMDB.\n- everything that doesn’t gets killed by janitor monkey\n-control over my env is straightforward\n\nA few clicks on a web page and about an hour to go from nothing to a very large Cassandra cluster consisting of 288 medium sized instances, with 96 instances in each of three EC2 availability zones in the US-East region.\n\n15 minutes to boot EC2, out of our total of 66 minutes. The rest of the time was taken to boot Linux, start the Apache Tomcat JVM that runs our automation tooling, start the Cassandra JVM and join the "ring" that makes up the Cassandra data store.\n\n For a more typical 12 instance Cassandra cluster the same sequence takes 8 minutes.\n\n
All instances have:\n- ASG, SecGrp, ELBs, owners, description, email addr -- almost like a CMDB.\n- everything that doesn’t gets killed by janitor monkey\n-control over my env is straightforward\n\nA few clicks on a web page and about an hour to go from nothing to a very large Cassandra cluster consisting of 288 medium sized instances, with 96 instances in each of three EC2 availability zones in the US-East region.\n\n15 minutes to boot EC2, out of our total of 66 minutes. The rest of the time was taken to boot Linux, start the Apache Tomcat JVM that runs our automation tooling, start the Cassandra JVM and join the "ring" that makes up the Cassandra data store.\n\n For a more typical 12 instance Cassandra cluster the same sequence takes 8 minutes.\n\n
All instances have:\n- ASG, SecGrp, ELBs, owners, description, email addr -- almost like a CMDB.\n- everything that doesn’t gets killed by janitor monkey\n-control over my env is straightforward\n\nA few clicks on a web page and about an hour to go from nothing to a very large Cassandra cluster consisting of 288 medium sized instances, with 96 instances in each of three EC2 availability zones in the US-East region.\n\n15 minutes to boot EC2, out of our total of 66 minutes. The rest of the time was taken to boot Linux, start the Apache Tomcat JVM that runs our automation tooling, start the Cassandra JVM and join the "ring" that makes up the Cassandra data store.\n\n For a more typical 12 instance Cassandra cluster the same sequence takes 8 minutes.\n\n
some items are aspirational, but we’re working on it.\n\nThese are similar to NIST’s “continuous monitoring” movement.\n
some items are aspirational, but we’re working on it.\n\nThese are similar to NIST’s “continuous monitoring” movement.\n
some items are aspirational, but we’re working on it.\n\nThese are similar to NIST’s “continuous monitoring” movement.\n
some items are aspirational, but we’re working on it.\n\nThese are similar to NIST’s “continuous monitoring” movement.\n
some items are aspirational, but we’re working on it.\n\nThese are similar to NIST’s “continuous monitoring” movement.\n
some items are aspirational, but we’re working on it.\n\nThese are similar to NIST’s “continuous monitoring” movement.\n
some items are aspirational, but we’re working on it.\n\nThese are similar to NIST’s “continuous monitoring” movement.\n
some items are aspirational, but we’re working on it.\n\nThese are similar to NIST’s “continuous monitoring” movement.\n
\n
\n
It’s a completely different way to provide your services. More disruptive than just a new technology.\n Bring your InfoSec expertise and foresight to secure your data in the cloud migration.\n You can embed security controls in your development, infrastructure, business operations.\n The old ways won’t work; embrace the new ones and have better control.\n
It’s a completely different way to provide your services. More disruptive than just a new technology.\n Bring your InfoSec expertise and foresight to secure your data in the cloud migration.\n You can embed security controls in your development, infrastructure, business operations.\n The old ways won’t work; embrace the new ones and have better control.\n
It’s a completely different way to provide your services. More disruptive than just a new technology.\n Bring your InfoSec expertise and foresight to secure your data in the cloud migration.\n You can embed security controls in your development, infrastructure, business operations.\n The old ways won’t work; embrace the new ones and have better control.\n
It’s a completely different way to provide your services. More disruptive than just a new technology.\n Bring your InfoSec expertise and foresight to secure your data in the cloud migration.\n You can embed security controls in your development, infrastructure, business operations.\n The old ways won’t work; embrace the new ones and have better control.\n
It’s a completely different way to provide your services. More disruptive than just a new technology.\n Bring your InfoSec expertise and foresight to secure your data in the cloud migration.\n You can embed security controls in your development, infrastructure, business operations.\n The old ways won’t work; embrace the new ones and have better control.\n
It’s a completely different way to provide your services. More disruptive than just a new technology.\n Bring your InfoSec expertise and foresight to secure your data in the cloud migration.\n You can embed security controls in your development, infrastructure, business operations.\n The old ways won’t work; embrace the new ones and have better control.\n
It’s a completely different way to provide your services. More disruptive than just a new technology.\n Bring your InfoSec expertise and foresight to secure your data in the cloud migration.\n You can embed security controls in your development, infrastructure, business operations.\n The old ways won’t work; embrace the new ones and have better control.\n