- [Lynn] Amazon has provided guidance
around design of security for solutions
and that guidance falls under five pillars.
They are: identity and access management,
detective controls,
infrastructure protection,
data protection,
and incident response.
Diving a little bit deeper into the first design principle,
strong identity foundation.
What does that include?
It includes a design which focuses on providing
least privilege to not only your users,
but also your services.
For example, EC2 instances.
It provides for separation of duties.
An example of that would be certain users
could perform administrative tasks on EC2 instances
while others would perform administrative tasks on data,
such as RDS instances.
Centralized management of key services, such as billing,
and reducing reliance on long-term credentials,
particularly key pairs
that are associated with user accounts.
The next pillar is traceability,
which is also called detective controls.
This includes monitoring, alerting,
and auditing on key activities if possible in real time.
An example of that would be administrative logins.
Another aspect would be monitor, alert,
and audit configuration changes, again ideally in real time,
and this would be instances of key services and servers
such as EC2 and RDS.
And the third aspect is automate responses to alarms.
So if you have, for example, a Kinesis Stream,
get into an overflow state to get an immediate alarm,
ideally with a remediated action.
The next section is around layered security
and automation of security best practices.
They're really two aspects of a similar design concept.
In layered security, you want to secure the entire system,
not just the outer layers,
and gosh, this is something that I see done incorrectly,
unfortunately more frequently than not.
What that means is don't just secure
at the edge of your system,
typically at the boundary of the VPC,
but also within your system.
For example, how do your internal EC2 instances
communicate with your database instances?
Another way to say that is applying defense in depth,
so defense across your system
and multiple layers of defense for key services,
such as authentication management.
As I mentioned, you want to apply this to as many layers
as it makes business sense of your solution.
Understanding more about automating security best practices,
you want to use software-based
security mechanisms that scale.
So what's an example of that?
A software-based firewall
such as a security group in AWS VPC.
You want to create overall secure architectures
that are well-documented and testable.
In some cases,
I've worked with external security validation teams
and they really provide a high level of security
in validation of the architecture.
And you want to use version-controlled configuration templates
for key services and servers.
The next design principle is to protect your data.
I like to say that data is a business currency.
It's key to protect your data both in transit and at rest.
You want to use data encryption
and appropriate key management for your data,
which will often include both files
and non-relational and relational data.
If possible, you want to reduce human access to your data
because that could potentially reduce the risk or loss
or the modification of that data.
Finally, you want to audit the data activities
around key data, and you want to define automated responses.
An example of that would be
if you had an authentication store
where you stored your user information.
You'd want to audit if someone created a new user
or modified the permissions of an existing user.
And finally, you want to prepare for security events.
Gosh, if I had one to emphasize it would be this one.
This is the section that I see, unfortunately,
many of my customers really only addressing
after they've had a security event.
I've actually been called in several cases
after some really unfortunate security situations
and it's just absolute best practice
to prepare for security events.
What does that mean?
You want to design and test an incident management process.
So for example, if you are breached
and your data is compromised, what will your response be?
You want to actually run incident response simulations.
These can be either announced or unannounced.
You also can engage
with external third-party security testers,
often called pen testers,
to validate and verify your responses to security events.
Finally, you want to use tools and automation
to respond to defined incidents.
Very importantly, you want to have written
security response policies that you test
in advance of security events occurring.
(upbeat music)