This document provides an overview of key areas to focus on for security when using AWS cloud infrastructure: automation, IAM, network design, encryption, auditing, and continuous integration. It emphasizes that automation is critical for security and infrastructure should be defined as code. For IAM, it recommends using a directory service and restricting use of the root account. For network design, it suggests using VPCs and monitoring traffic. It also provides checklists for each area to help ensure security best practices are followed.

1. AWS Security
Essentials
Aaron Bedra
Chief Scientist, Jemurai
@abedra
keybase.io/abedra

2. Cloud infrastructure
providers offer some
incredible benefits

3. There are loads of
reasons to take the leap

4. But there are a lot of
misconceptions about
how to approach it

5. This talk will focus on
AWS, but the concepts
apply to all providers

6. It’s easy to get caught up
in mirroring your legacy
datacenter

7. Just say no to lift and
shift!!!

8. But you have to realize
that this is not a
traditional DC

9. And you shouldn’t
treat it that way

10. There are aspects
you want to keep

11. And some you want
to throw away

12. To get security right in
the cloud requires
change

13. Key Areas
Automation
IAM
Network Design
Encryption
Auditing
Continuous Integration

14. Automation

16. This is a critical step

17. There’s no excuse for
ignoring automation

18. The platforms are
built for it

19. Humans clicking buttons
is what causes security
issues

20. And what causes
blockers, slow down, and
frustration

21. If you desire to move to the cloud
and wish to continue clicking
buttons, stay where you are

22. You shouldn’t be logging
into the AWS console

23. In fact, page the security
team when it happens

24. Or just disable console
access entirely*

25. Getting your infrastructure
configuration into code is
step 1

26. It allows for review,
analysis, and audit

27. It creates a culture
around describing
systems as data

28. The cloud is an
abstraction, talk about it
as one

29. It creates a place where simple
code review is the only blocker
between you and the end result

30. Automation Checklist
All infrastructure is recorded as code
All infrastructure changes are made by an automated tool
Console logins are restricted to a handful of
administrators
Teams are educated and empowered to make necessary
changes via automation

31. IAM

32. Get a grip on users
and permissions

33. I’ve seen some
things..

34. A mistake here could
provide control over
everything

35. How do we get to a
good place?

36. Use a directory!

37. If you already have a
directory, replicate it into
AWS

38. Avoid keeping multiple
systems of record for
user accounts

39. This solves on-boarding
and off-boarding issues

40. And ensures that
changes propagate
without additional work

41. If you don’t have a directory,
make sure you setup strong
account requirements

42. The root account

43. Don’t use it

44. Page security when it
is used

45. There are only a handful
of things you should use
the root account for

46. http://docs.aws.amazon.com/
general/latest/gr/aws_tasks-
that-require-root.html

47. Use of the root account
isn’t acceptable if it’s not
on that list

48. The only permission IAM
accounts should have is
assume role

49. Security Token Service
should be the gateway to
everything

50. This reduces the direct
exposure of credentials

51. And forces people to
think about the roles they
need to perform a task

52. IAM Checklist
Root account has MFA enabled
Root account has no access keys*
Users have no permissions outside of the ability to use STS to assume
roles*
Directories are replicated into AWS and used as the system of record
MFA is enabled for all human users
MFA is required to access privileged roles
Users are trained and provided tools to make role assumption seamless
Users have no inline policies

53. Network Design

54. Network design is
situation dependent

55. But there are a few
things that matter

56. Create a boundary

57. VPC should be that
boundary

58. Isolate environments
and scope with VPCs

59. Monitor what comes
in and out of the VPC

60. Be conscious about
entry points!

61. There should only be
one way in

62. VPN or Bastion hosts

63. Make sure not to expose
management of all
machines directly

64. Use tools to report on
external footprint

65. Network Design Checklist
Everything is deployed inside a VPC
Flow logs are enabled and monitored
Everything that can has a security group attached
Any security group that allows access from 0.0.0.0/0 has
a detailed description and justification
Remote access is only allowed via a bastion host or
internal interface

66. Encryption

68. We can all acknowledge
that this is difficult

69. But we can make choices
that reduce effort and the
chance for mistakes

70. KMS

71. This is your new
default

72. All your keys should
originate from KMS

73. Any AWS service you use
that stores data should
have a kms key attached

74. resource "aws_db_instance" "default" {
allocated_storage = 10
storage_type = "gp2"
engine = "mysql"
engine_version = "5.6.17"
instance_class = "db.t1.micro"
name = "mydb"
username = "foo"
password = "bar"
db_subnet_group_name = "my_database_subnet_group"
parameter_group_name = “default.mysql5.6"
}

75. resource "aws_db_instance" "default" {
allocated_storage = 10
storage_type = "gp2"
engine = "mysql"
engine_version = "5.6.17"
instance_class = "db.t1.micro"
name = "mydb"
username = "foo"
password = "bar"
db_subnet_group_name = "my_database_subnet_group"
parameter_group_name = “default.mysql5.6"
kms_key_id = “${aws_kms_key.foo.key_id}”
}

76. Start with AWS services
encrypted using KMS

77. Encryption Checklist
All Master or Key Encryption Keys are stored using KMS
All KMS keys have the rotation option enabled
All AWS services utilized that store data should use KMS
Data encryption keys are generated using kms master
keys and stored encrypted

78. Auditing

79. How do you know things
are configured correctly?

80. Scout2

81. Scout2 audits all
configurations across all
regions

82. It produces a report
of dangerous issues

84. Run this tool on your
infrastructure and see
what you find

85. You will likely be
surprised

86. Take some time to
discuss and correct
these issues

87. This helps with audit
of configuration

88. But what about user
activity?

89. CloudTrail/
CloudWatch

90. These tools are
invaluable

91. They are an absolute
must for anyone taking
security seriously

92. Enable CloudTrail for
all active regions

93. Use CloudWatch to
establish alerts on big
ticket concerns

94. Or better yet, use a third
party that can do this for
you

95. You don’t have to
manage everything on
your own

97. Alert Event Examples
Root account login
Root account key usage
New user created
User added to administrative roles
Too many KMS decrypt events

98. Auditing Checklist
Configuration analysis is performed at least daily, if not for
every change
CloudTrail is enabled for all active regions
CloudWatch metrics and alarms are implemented for
major violation cases
Guard Duty?

99. Continuous
Integration

100. How do I automate it?

101. Because your infrastructure
is in code, you can hook
audit into the CI pipeline

102. Now you can block or
rollback changes based
on audit findings

103. You can also institute a
seamless sign-off policy
that lives in code hosting

106. CI Checklist
All infrastructure changes trigger configuration audits
Critical issues found in CI trigger immediate response
Use the CI pipeline to create a sign-off process that
allows teams to move faster

107. The benefits of being on
provider like AWS are
massive

108. If there is still fear of
shifting, please look
again!

109. Healthcare, Finance,
Government, etc. are
there already

110. Questions?