1

00:00:12,110  -->  00:00:18,449
Welcome back to Backspace Academy. AWS CloudTrail it doesn't have a broad set

2

00:00:18,449  -->  00:00:24,990
of features like other AWS services but
what it does is extremely important and

3

00:00:24,990  -->  00:00:30,240
it may well be your last line of defense
in the event that your infrastructure is

4

00:00:30,240  -->  00:00:34,920
breached.
Now imagine you've had your email

5

00:00:34,920  -->  00:00:40,200
account compromised and an attacker has
got hold of your username and password

6

00:00:40,200  -->  00:00:45,360
from something like an email phishing
attack or something like that. In that

7

00:00:45,360  -->  00:00:50,160
situation it doesn't matter how good
your Linux firewall is, your security

8

00:00:50,160  -->  00:00:55,350
groups, your network access control lists,
all of that sort of thing, it's not going

9

00:00:55,350  -->  00:01:00,629
to really help in that situation because
your attacker has access with valid

10

00:01:00,629  -->  00:01:06,150
credentials and, in that situation you
need to identify that an attack is

11

00:01:06,150  -->  00:01:11,340
occurring from within your
infrastructure, not from outside of your

12

00:01:11,340  -->  00:01:17,810
infrastructure, and that is where Cloudtrail comes in to help you identify

13

00:01:17,810  -->  00:01:26,520
unusual activity from inside of your
accoun. Cloudtrail it provides a record

14

00:01:26,520  -->  00:01:33,450
of AWS API calls to your AWS account. So
if you've got multiple AWS users that

15

00:01:33,450  -->  00:01:39,060
you've setup IAM users, what it will do is
it will record all of the interactions

16

00:01:39,060  -->  00:01:45,570
between that user and your AWS account
by recording all of those API calls that

17

00:01:45,570  -->  00:01:51,090
are made. The record will consist of the
actual user the timestamp that the API

18

00:01:51,090  -->  00:01:56,729
call was made, the actual API call it
could be a call to the ec2 service or s3

19

00:01:56,729  -->  00:02:00,299
service whatever that is,
the resources involved it could be a

20

00:02:00,299  -->  00:02:06,469
bucket or an ec2 instance or whatever
and, the region that the call was made to.

21

00:02:06,469  -->  00:02:11,970
Now as we explained previously this is
really important from a security

22

00:02:11,970  -->  00:02:15,360
perspective
especially if you have an attack that

23

00:02:15,360  -->  00:02:20,970
occurs from within your account. So if
someone has valid credentials that

24

00:02:20,970  -->  00:02:25,800
they've somehow acquired or stolen or
whatever and they have access to your

25

00:02:25,800  -->  00:02:31,260
account and they're inside of your AWS
account. So it allows you to record

26

00:02:31,260  -->  00:02:38,069
what's going on there and be alerted to
situations that may be unusual. It can be

27

00:02:38,069  -->  00:02:42,750
used for compliance to standards by
making sure that you record all of the

28

00:02:42,750  -->  00:02:48,239
interaction between your users and your
account and recording that and archiving

29

00:02:48,239  -->  00:02:53,880
that if needed. It's also very good for
troubleshooting your infrastructure, for

30

00:02:53,880  -->  00:02:59,819
example you may find a situation where a
individual user has difficulty, so you

31

00:02:59,819  -->  00:03:05,069
can go through your cloudtrail logs and
see what API calls that that user is

32

00:03:05,069  -->  00:03:10,280
making and, why that individual user is
having problems with your infrastructure.

33

00:03:10,280  -->  00:03:16,980
The cloud trail records are saved to
Amazon S3 in JSON format and they're

34

00:03:16,980  -->  00:03:24,060
encrypted using s3 server-side
encryption. Cloudtrail can also be

35

00:03:24,060  -->  00:03:28,070
integrated with Cloudwatch logs and by
doing that you'll be able to see

36

00:03:28,070  -->  00:03:34,200
activity inside of your account with
these API calls in the cloud watch

37

00:03:34,200  -->  00:03:39,030
console and you can also have alarms
setup, they can trigger a message or

38

00:03:39,030  -->  00:03:43,739
maybe even trigger a Lambda function or
something like that, some sort of quick

39

00:03:43,739  -->  00:03:48,600
interaction.You can also have it
integrated with SNS and you do that

40

00:03:48,600  -->  00:03:56,100
using the console or using the CLI
create trail command. Now because the

41

00:03:56,100  -->  00:04:02,549
Cloudtrail records are saved to Amazon
s3, you can set up an s3 event

42

00:04:02,549  -->  00:04:08,160
that can also trigger an AWS Lambda
function and so that Lambda function may

43

00:04:08,160  -->  00:04:14,150
analyze what that record entry is and
just see whether that is worth alerting

44

00:04:14,150  -->  00:04:19,489
your administrator or whatever if there
is an issue.

45

00:04:20,079  -->  00:04:25,819
OK, a picture tells a thousand words. On
the left there we've got all of the

46

00:04:25,819  -->  00:04:33,020
different ways that our users can
interact with our AWS account. So they

47

00:04:33,020  -->  00:04:37,940
could use the AWS management
console and by doing that the AWS

48

00:04:37,940  -->  00:04:43,669
management console application will then
send an API call to AWS to do something

49

00:04:43,669  -->  00:04:49,490
to an AWS service, that could be IAM, it
could be Amazon S3, it could be EC2,

50

00:04:49,490  -->  00:04:57,110
could be DynamoDB, could be any one of a number
of different services or, the user could

51

00:04:57,110  -->  00:05:02,449
use an application that is running one
of the many software development kits

52

00:05:02,449  -->  00:05:07,490
and that again would be sending API
calls in or, the user could be using the

53

00:05:07,490  -->  00:05:11,659
AWS command line interface as well but
any one of those three different

54

00:05:11,659  -->  00:05:17,539
techniques will allow the user to
interact with your AWS account using

55

00:05:17,539  -->  00:05:22,060
these API calls.
Now those API calls will be picked up by Cloudtrail

56

00:05:22,060  -->  00:05:28,550
and Cloudtrail will record
basic information about that API call

57

00:05:28,550  -->  00:05:35,360
and it will store that as a record in a
Cloudtrail log and so those Cloudtrail

58

00:05:35,360  -->  00:05:42,590
logs will be stored in a designated s3
bucket that you define and, you can also

59

00:05:42,590  -->  00:05:47,449
integrate an SNS topic with those cloudtrail logs so when they come in it can

60

00:05:47,449  -->  00:05:53,630
alert you with an SNS topic. You can also
integrate it with cloudwatch logs and

61

00:05:53,630  -->  00:05:57,740
by doing that you've got all of those
features of cloudwatch then as well and

62

00:05:57,740  -->  00:06:03,169
so that will allow you to integrate a
cloudwatch alarm or you could or even

63

00:06:03,169  -->  00:06:08,539
have your cloudwatch logs sent over to a
Kinesis stream as well for live

64

00:06:08,539  -->  00:06:16,669
monitoring of that cloudtrail log. Now
when you open up a cloudtrail log it

65

00:06:16,669  -->  00:06:22,130
will consist of a whole heap of JSON
records. So here we've got an example of

66

00:06:22,130  -->  00:06:26,060
what one of those records for an
individual API call looks like. So we've

67

00:06:26,060  -->  00:06:31,789
got an IAM user who is not multi-factor
authenticated, who is logged into the

68

00:06:31,789  -->  00:06:35,740
account.
They've gone to the ec2 service and

69

00:06:35,740  -->  00:06:40,360
they've created a new key pair for an
ec2 server. Now this is something that

70

00:06:40,360  -->  00:06:44,110
you may want to be alerted to. You may
not want people that are not MFA

71

00:06:44,110  -->  00:06:49,439
authenticated to be able to create new
encryption key pairs.

72

00:06:51,270  -->  00:06:56,800
Now as we've seen in the previous slides
CloudTrail can integrate with some

73

00:06:56,800  -->  00:07:02,620
other services. It can integrate with
S3 events to trigger some reactive

74

00:07:02,620  -->  00:07:06,880
action to be taken it can integrate with
CloudWatch logs and then integrate

75

00:07:06,880  -->  00:07:10,690
with Kinesis streams. So there's a whole
range of different things that you can

76

00:07:10,690  -->  00:07:17,530
create yourself to be proactive to
actually analyze and react to this

77

00:07:17,530  -->  00:07:21,610
CloudTrail information but, there is
also

78

00:07:21,610  -->  00:07:26,650
CloudTrail Insights which is an out-of-the-box
service provided by AWS. What that will do is

79

00:07:26,650  -->  00:07:33,070
it will track your normal patterns
of API call volume. Now that can take up

80

00:07:33,070  -->  00:07:37,900
to 36 hours for the first time to get
that history that it needs to to see

81

00:07:37,900  -->  00:07:41,650
what your normal pattern is. So you just need
to take that into consideration

82

00:07:41,650  -->  00:07:45,880
when you first create this cloudtrail
insight. You're not going to be able to

83

00:07:45,880  -->  00:07:52,360
take advantage of it until that 36 hours
of normal pattern time has been has been

84

00:07:52,360  -->  00:07:59,890
put in, and that will then generate an
insight event if any of the volume is

85

00:07:59,890  -->  00:08:05,800
outside of those normal patterns. So if
your infrastructure has been attacked

86

00:08:05,800  -->  00:08:09,580
from within
using credentials then if there's a high

87

00:08:09,580  -->  00:08:14,890
volume for certain types of activity
that is not normally the pattern then

88

00:08:14,890  -->  00:08:21,250
that will trigger a insight event and
that event will be recorded as a log

89

00:08:21,250  -->  00:08:27,880
entry and that again will be stored in
Amazon S3 and so those events insights

90

00:08:27,880  -->  00:08:33,039
events can be viewed in the cloudtrail
console as a graph in a similar way that

91

00:08:33,039  -->  00:08:38,650
you can view alarms in the cloudwatch
console, and that event history which is

92

00:08:38,650  -->  00:08:44,140
sent to Amazon s3 and stored in Amazon
s3, that can be used to trigger an s3 event

93

00:08:44,140  -->  00:08:50,410
but it can also be used to send
those record information, all those event

94

00:08:50,410  -->  00:08:54,760
information to be sent over to cloudwatch logs, from there you've got all of

95

00:08:54,760  -->  00:09:01,510
the features that are available of cloudwatch as well. Ok so here is what a

96

00:09:01,510  -->  00:09:06,990
Cloudtrial insights event graph looks like.
So what you've got there is some normal

97

00:09:06,990  -->  00:09:14,790
activity there in blue, and all of a
sudden it spikes and around about 13:35

98

00:09:14,790  -->  00:09:19,320
it's spiked up there and that is unusual
and it's marked in red and so that has

99

00:09:19,320  -->  00:09:23,910
triggered an insight event. So if you
want to have more information about that

100

00:09:23,910  -->  00:09:28,800
you can scroll down and go and expand
the insights event record to see exactly

101

00:09:28,800  -->  00:09:33,500
what occurred. Then you can also go into
the s3 bucket have a look in there and

102

00:09:33,500  -->  00:09:38,130
by doing that that's going to allow you
to get some better information about

103

00:09:38,130  -->  00:09:44,190
what's causing this spike in demand. Okay
so that brings us to the end of a pretty

104

00:09:44,190  -->  00:09:48,990
short lecture but a very important one
on cloudtrail I hope you enjoyed it and

105

00:09:48,990  -->  00:09:52,880
I look forward to seeing you in the next
one