Well-Architected = Risk Managed.
This series of questions came across my desk this morning. Interestingly,
it took me back nearly 10 years when I first started in cloud security. I’ve
been in information security for nearly 20 years, and I believe much of the
strategy and definition – the construct – of the secure environment is still
the same.
How would you define a well-architected cloud?
A well-architected cloud provides assurance, or the grounds
for confidence that the integrity, availability, confidentiality, and
accountability have been adequately met. “Adequately met” includes (1)
functionality that performs correctly, (2) sufficient protection against
unintentional errors by users or software, and (3) sufficient resistance to
intentional penetration or by-pass. This is a close paraphrase of the
definition of assurance from NIST SP 800-27.
What are the elements that go into a well-architected cloud?
There are three elements covering the technical
implementation of a well-architected cloud. The technical controls of best
practices, regulations, and standards based on CIS, NIST, PCI DSS, and others
can be summed up into configuration,
solutions, and design. The configuration of
every application and endpoint must be configured to reduce the probability and
impact of intentional and unintentional action. Hardening guides address many
of these issues for the network, compute, storage, and virtualization components.
System solutions provide additional insight, accountability, or control over
the security and compliance of the environment. Examples include firewalls,
identity and access management, and systems monitoring. Finally, given that each
one of the individual components is secured as much as possible and
additional solutions provide you the insight, accountability, and control over
your environment, your last consideration is the environment design. This can
include separating trusted and untrusted zones, implementing a DMZ, providing secure multi-tenancy, etc.
What's the best way to achieve a well-architected cloud?
Identify the business objectives, dataflow, and preferred
user interactions before building the system. Decide how subjects will interact
with data objects and what controls will be in place across the reference
monitor that controls authentication and authorization. The security model of
the most trusted systems in the world depends upon strong access controls. This
only works if you understand who has access to critical data and how to protect
it using secure configurations, solutions, and design. Bottom line. Plan for it. The military has a
saying, “Prior Planning Prevents Poor Performance.”
What should IT never do when constructing a cloud architecture?
Assume that you can do a direct lift and shift into the
cloud. The intent of the controls have not changed, and neither have your
objectives. However, the implementation, visibility, and tools available significantly change. Take the time to understand the platform you are
moving your data into and how that platform functions versus how you have
handled your data in the past on premises.
What are the cloud architecture pitfalls that IT might fall into?
Again. Never assume you can do a direct lift and shift into the
cloud. Never embark on a journey without a known destination and plans for how
to get there. Start with a comprehensive set of security requirements inclusive
of configurations, solutions, and design principles that must be met.
Is there anything else you would like to add?
Is there anything else you would like to add?
Cloud environments bring tremendous opportunity, as long as
you can maintain visibility and manage risk across the entire environment. That's been a consistent message on this blog since its inception in 2011. Manage Your Risk.
