1 1 00:00:00,000 --> 00:00:02,580 FAAS and Serverless. 2 2 00:00:02,580 --> 00:00:03,870 When I talk about FAAS 3 3 00:00:03,870 --> 00:00:06,690 I'm talking about function as a service. 4 4 00:00:06,690 --> 00:00:10,110 Now, function as a service is a really cool new technology 5 5 00:00:10,110 --> 00:00:12,120 and it is really one of these newer technologies 6 6 00:00:12,120 --> 00:00:14,760 that we're using inside the cloud computing world. 7 7 00:00:14,760 --> 00:00:16,500 A lot of traditionalists don't like the idea 8 8 00:00:16,500 --> 00:00:17,400 of function as a service 9 9 00:00:17,400 --> 00:00:19,560 because there are some risks involved with it 10 10 00:00:19,560 --> 00:00:21,510 which we'll talk about as we go through this lesson. 11 11 00:00:21,510 --> 00:00:23,310 But I do want you to be aware of this concept 12 12 00:00:23,310 --> 00:00:25,710 because as an analyst, I personally think 13 13 00:00:25,710 --> 00:00:28,440 function as a service is a large part of the future 14 14 00:00:28,440 --> 00:00:30,000 and we're going to have to learn how to use these things 15 15 00:00:30,000 --> 00:00:31,770 and how to be able to analyze them 16 16 00:00:31,770 --> 00:00:33,810 for security as we move forward. 17 17 00:00:33,810 --> 00:00:36,660 Now, when I talk about function as a service or FAAS, 18 18 00:00:36,660 --> 00:00:38,130 what exactly is that? 19 19 00:00:38,130 --> 00:00:39,660 Well, it's a cloud service model 20 20 00:00:39,660 --> 00:00:42,060 that supports Serverless software architecture 21 21 00:00:42,060 --> 00:00:45,060 by provisioning runtime containers in which code is executed 22 22 00:00:45,060 --> 00:00:47,058 in a particular programming language. 23 23 00:00:47,058 --> 00:00:49,800 Now, that's a really long way of saying 24 24 00:00:49,800 --> 00:00:52,860 we are going to be able to run things and make applications 25 25 00:00:52,860 --> 00:00:55,440 without actually having our own servers. 26 26 00:00:55,440 --> 00:00:57,090 Now, that sounds pretty cool, right? 27 27 00:00:57,090 --> 00:00:59,010 Because now I don't know about you 28 28 00:00:59,010 --> 00:01:01,560 but I've been a system administrator for a long time, 29 29 00:01:01,560 --> 00:01:03,030 about 20 years, 30 30 00:01:03,030 --> 00:01:05,910 and the idea of having to run all my own servers 31 31 00:01:05,910 --> 00:01:08,640 and be able to run my own patches and do the updates 32 32 00:01:08,640 --> 00:01:10,920 and do all the testing and do all that stuff 33 33 00:01:10,920 --> 00:01:13,140 just to be able to run a simple integration program 34 34 00:01:13,140 --> 00:01:15,830 like the one I talked about between Fresh Desk and Udemy, 35 35 00:01:15,830 --> 00:01:17,314 to be able to make tickets go back and forth 36 36 00:01:17,314 --> 00:01:19,260 sounds like a lot of work. 37 37 00:01:19,260 --> 00:01:21,150 And so function as a service eliminates 38 38 00:01:21,150 --> 00:01:22,140 the need for me to do that. 39 39 00:01:22,140 --> 00:01:24,840 Instead, I can write the code in something like Python 40 40 00:01:24,840 --> 00:01:27,060 and then run it in this environment. 41 41 00:01:27,060 --> 00:01:28,530 Now, when we talk about Serverless 42 42 00:01:28,530 --> 00:01:30,630 you notice that keyword in this definition. 43 43 00:01:30,630 --> 00:01:32,610 Serverless is a software architecture 44 44 00:01:32,610 --> 00:01:35,580 that runs functions within virtualized runtime containers 45 45 00:01:35,580 --> 00:01:39,240 in a cloud rather than on dedicated server instances. 46 46 00:01:39,240 --> 00:01:41,250 So when you deal with Serverless, 47 47 00:01:41,250 --> 00:01:44,040 everything in Serverless is developed as a function 48 48 00:01:44,040 --> 00:01:45,570 or a microservice. 49 49 00:01:45,570 --> 00:01:47,700 Remember, we talked about microservices all the way back 50 50 00:01:47,700 --> 00:01:49,140 in the beginning of this section. 51 51 00:01:49,140 --> 00:01:51,090 What did we say about microservices? 52 52 00:01:51,090 --> 00:01:53,382 We want to be able to give it an input and get an output 53 53 00:01:53,382 --> 00:01:56,970 and the service should do one thing and only one thing. 54 54 00:01:56,970 --> 00:01:58,740 So you can design it, build it 55 55 00:01:58,740 --> 00:02:01,024 and test it completely independently. 56 56 00:02:01,024 --> 00:02:03,840 Now, who is using things like Serverless 57 57 00:02:03,840 --> 00:02:05,580 and function as a service? 58 58 00:02:05,580 --> 00:02:06,750 Do you know any big examples 59 59 00:02:06,750 --> 00:02:08,940 or big companies out there doing this now? 60 60 00:02:08,940 --> 00:02:11,543 Well, one of the biggest ones out there is Netflix. 61 61 00:02:11,543 --> 00:02:12,420 That's right. 62 62 00:02:12,420 --> 00:02:14,550 If you've watched any Netflix recently 63 63 00:02:14,550 --> 00:02:16,620 you've been actually using Serverless. 64 64 00:02:16,620 --> 00:02:20,250 Netflix delivers over 10 billion hours of video 65 65 00:02:20,250 --> 00:02:23,700 to 125 million customers every quarter, 66 66 00:02:23,700 --> 00:02:25,830 and they do this using Serverless. 67 67 00:02:25,830 --> 00:02:27,390 They do this because they're able to serve 68 68 00:02:27,390 --> 00:02:30,480 that large of an audience by using a wide range of highly 69 69 00:02:30,480 --> 00:02:33,420 complex infrastructure that relies on AWS, 70 70 00:02:33,420 --> 00:02:36,990 specifically its Serverless capability known as Lambda. 71 71 00:02:36,990 --> 00:02:39,930 Now, all of this is done using this AWS Lambda 72 72 00:02:39,930 --> 00:02:41,760 which is a Serverless environment. 73 73 00:02:41,760 --> 00:02:45,780 Essentially, Amazon runs all these underlying servers 74 74 00:02:45,780 --> 00:02:48,060 and Netflix doesn't have to worry about 'em at all. 75 75 00:02:48,060 --> 00:02:49,770 All Netflix needs to do is know that 76 76 00:02:49,770 --> 00:02:51,930 when they give them code that's written in Python 77 77 00:02:51,930 --> 00:02:54,030 or some other language, Lambda can run it, 78 78 00:02:54,030 --> 00:02:55,650 and they don't care about what that looks like 79 79 00:02:55,650 --> 00:02:57,030 underneath that. 80 80 00:02:57,030 --> 00:02:59,160 Now we're going to talk more about how this actually works, 81 81 00:02:59,160 --> 00:03:02,070 but Netflix is using this AWS Lambda 82 82 00:03:02,070 --> 00:03:04,770 to essentially build this rule-based self-managing 83 83 00:03:04,770 --> 00:03:07,050 infrastructure that replaces a lot of the old 84 84 00:03:07,050 --> 00:03:09,210 inefficient processes and it helps them reduce 85 85 00:03:09,210 --> 00:03:11,730 the rate of errors and save them lots of time 86 86 00:03:11,730 --> 00:03:13,140 and lots of money. 87 87 00:03:13,140 --> 00:03:14,849 One of the great things about doing Serverless 88 88 00:03:14,849 --> 00:03:17,280 is that it eliminates the need to manage physical 89 89 00:03:17,280 --> 00:03:18,810 or virtual servers. 90 90 00:03:18,810 --> 00:03:20,880 Instead, you just get the service you need 91 91 00:03:20,880 --> 00:03:23,460 which is something that can run some kind of a language. 92 92 00:03:23,460 --> 00:03:25,680 For instance, mine runs Python. 93 93 00:03:25,680 --> 00:03:26,640 Now, when you do this 94 94 00:03:26,640 --> 00:03:28,860 you're not paying for these servers all the time either. 95 95 00:03:28,860 --> 00:03:30,900 You're only paying when they're executing. 96 96 00:03:30,900 --> 00:03:33,240 So my particular automation only runs 97 97 00:03:33,240 --> 00:03:35,520 once every couple hours, and when it does that, 98 98 00:03:35,520 --> 00:03:38,310 it runs for maybe three to 30 seconds. 99 99 00:03:38,310 --> 00:03:39,990 When I get a bill, it's for that three 100 100 00:03:39,990 --> 00:03:43,320 to 30 second increment four times a day or six times a day, 101 101 00:03:43,320 --> 00:03:45,420 or 12 times a day, or however often I do it. 102 102 00:03:45,420 --> 00:03:46,998 And so the bill for this for us 103 103 00:03:46,998 --> 00:03:48,960 is less than a dollar a month. 104 104 00:03:48,960 --> 00:03:51,210 It is super cheap to use these things. 105 105 00:03:51,210 --> 00:03:53,580 Now, Netflix's bill is a lot more money, 106 106 00:03:53,580 --> 00:03:55,110 but again you're only paying for the time 107 107 00:03:55,110 --> 00:03:57,180 that you're actually using processing. 108 108 00:03:57,180 --> 00:03:58,920 And so this is a really great way to do things 109 109 00:03:58,920 --> 00:04:00,930 and it can save you a lot of money. 110 110 00:04:00,930 --> 00:04:02,670 Now, what are some real big benefits here? 111 111 00:04:02,670 --> 00:04:05,580 Well, for one, there's no patching 'cause there's no server. 112 112 00:04:05,580 --> 00:04:07,230 Two, there's no administration. 113 113 00:04:07,230 --> 00:04:08,580 You don't have to administer a server 114 114 00:04:08,580 --> 00:04:10,170 because it doesn't exist. 115 115 00:04:10,170 --> 00:04:12,180 And three, there's no file system monitoring 116 116 00:04:12,180 --> 00:04:14,010 because again there's no server. 117 117 00:04:14,010 --> 00:04:15,750 You're just running code. 118 118 00:04:15,750 --> 00:04:17,550 Now, the underlying architecture here 119 119 00:04:17,550 --> 00:04:19,620 is going to be managed by your cloud service provider. 120 120 00:04:19,620 --> 00:04:21,630 So if you're using AWS Lambda, 121 121 00:04:21,630 --> 00:04:23,400 it's Jeff Bezos and his team at Amazon 122 122 00:04:23,400 --> 00:04:25,350 who has to worry about the underlying architecture. 123 123 00:04:25,350 --> 00:04:27,540 They pay for the network, they pay for the service, 124 124 00:04:27,540 --> 00:04:28,770 they pay for the operating system, 125 125 00:04:28,770 --> 00:04:31,118 they pay for the patching, they pay for all the security 126 126 00:04:31,118 --> 00:04:33,180 and you just get to run your code. 127 127 00:04:33,180 --> 00:04:35,670 That's the benefit of using something like Serverless. 128 128 00:04:35,670 --> 00:04:37,200 Now, what is your job though 129 129 00:04:37,200 --> 00:04:38,520 as a cybersecurity professional? 130 130 00:04:38,520 --> 00:04:42,210 Because if we don't have to patch and we don't have to scan 131 131 00:04:42,210 --> 00:04:45,840 and we don't have to operate in admin, what are we going to do? 132 132 00:04:45,840 --> 00:04:47,580 Well, that's a really good question. 133 133 00:04:47,580 --> 00:04:49,590 Our job here as cybersecurity analysts 134 134 00:04:49,590 --> 00:04:51,870 inside of this world of function as a service 135 135 00:04:51,870 --> 00:04:52,703 and Serverless, 136 136 00:04:52,703 --> 00:04:55,260 is to ensure that the clients accessing the services 137 137 00:04:55,260 --> 00:04:57,060 have not been compromised. 138 138 00:04:57,060 --> 00:04:59,610 Now, I'm not talking here about your end user's workstation. 139 139 00:04:59,610 --> 00:05:02,220 If you're Netflix, it's not your job to make sure 140 140 00:05:02,220 --> 00:05:05,010 that my home computer is properly patched and updated 141 141 00:05:05,010 --> 00:05:06,660 before I connect to your service. 142 142 00:05:06,660 --> 00:05:08,250 Instead, I'm more concerned 143 143 00:05:08,250 --> 00:05:09,630 with your developer's workstations 144 144 00:05:09,630 --> 00:05:11,430 and their accounts because they're the ones 145 145 00:05:11,430 --> 00:05:12,960 who are going to update the application code 146 146 00:05:12,960 --> 00:05:15,090 that's creating these functions and services. 147 147 00:05:15,090 --> 00:05:17,400 So if I'm a programmer for Netflix, 148 148 00:05:17,400 --> 00:05:19,380 then you as a cyber security analyst need to make sure 149 149 00:05:19,380 --> 00:05:22,050 that my workstation is properly secured, 150 150 00:05:22,050 --> 00:05:23,936 that my credentials are properly secured, 151 151 00:05:23,936 --> 00:05:26,820 that I write my code in a very secure way. 152 152 00:05:26,820 --> 00:05:29,280 So a lot of our job as cybersecurity professionals 153 153 00:05:29,280 --> 00:05:32,130 starts moving from the infrastructure side of things 154 154 00:05:32,130 --> 00:05:34,590 into more of the code analysis side of things. 155 155 00:05:34,590 --> 00:05:36,960 And that's why cybersecurity is such a broad field 156 156 00:05:36,960 --> 00:05:38,940 because there's all these different areas 157 157 00:05:38,940 --> 00:05:39,840 and that doesn't mean 158 158 00:05:39,840 --> 00:05:41,310 that we're going to be Serverless tomorrow, 159 159 00:05:41,310 --> 00:05:43,470 that all infrastructure's going to go away, because guess what? 160 160 00:05:43,470 --> 00:05:45,900 Amazon still has the underlying servers 161 161 00:05:45,900 --> 00:05:48,540 and so there is going to be some role for people to work at 162 162 00:05:48,540 --> 00:05:50,760 Amazon and Google and Microsoft 163 163 00:05:50,760 --> 00:05:52,260 to be able to run their programs 164 164 00:05:52,260 --> 00:05:54,450 and make sure they're being done securely. 165 165 00:05:54,450 --> 00:05:57,360 But when we talk about working for a company like Netflix, 166 166 00:05:57,360 --> 00:05:59,640 their cybersecurity folks are much more focused 167 167 00:05:59,640 --> 00:06:01,800 on looking at the code that their developers are making 168 168 00:06:01,800 --> 00:06:02,940 to make sure it's secure, 169 169 00:06:02,940 --> 00:06:04,680 to make sure their authentication systems are good, 170 170 00:06:04,680 --> 00:06:08,040 their authorization systems are good, and things like that. 171 171 00:06:08,040 --> 00:06:10,890 So when it comes up to the idea of function as a service 172 172 00:06:10,890 --> 00:06:12,967 and Serverless, we really have to ask the question, 173 173 00:06:12,967 --> 00:06:15,360 "Is it safe or is it risky?" 174 174 00:06:15,360 --> 00:06:18,420 Well, with Serverless it does have some considerable risks 175 175 00:06:18,420 --> 00:06:19,710 that you have to consider. 176 176 00:06:19,710 --> 00:06:21,810 There are use cases and best practices 177 177 00:06:21,810 --> 00:06:23,850 when you're dealing with traditional infrastructure, 178 178 00:06:23,850 --> 00:06:25,530 but Serverless and function as a service 179 179 00:06:25,530 --> 00:06:27,120 is still relatively new. 180 180 00:06:27,120 --> 00:06:29,700 So you're kind of in uncharted territory here 181 181 00:06:29,700 --> 00:06:31,350 and being a bit of an adventurer, 182 182 00:06:31,350 --> 00:06:33,810 that in itself makes it a bit more risky 183 183 00:06:33,810 --> 00:06:36,210 because we don't know the long-term implications of that. 184 184 00:06:36,210 --> 00:06:37,890 We don't know all the best cases 185 185 00:06:37,890 --> 00:06:39,870 and the best practices to use. 186 186 00:06:39,870 --> 00:06:41,550 Now, another thing that's risky about this 187 187 00:06:41,550 --> 00:06:42,720 is that you're fully dependent 188 188 00:06:42,720 --> 00:06:44,190 on the underlying service provider. 189 189 00:06:44,190 --> 00:06:45,960 So I keep saying Amazon is an example, 190 190 00:06:45,960 --> 00:06:49,770 but Amazon is responsible for the dependency, the redundancy 191 191 00:06:49,770 --> 00:06:52,530 and a lot of the security that underpin your services 192 192 00:06:52,530 --> 00:06:54,330 and you're basically wishing all that away 193 193 00:06:54,330 --> 00:06:56,250 and hoping they do a good job. 194 194 00:06:56,250 --> 00:06:58,500 Now, that is one of those things that is a little bit more 195 195 00:06:58,500 --> 00:07:01,260 risky because again, they haven't been doing this 196 196 00:07:01,260 --> 00:07:03,300 for a long, long, long time. 197 197 00:07:03,300 --> 00:07:05,790 They're good at what they do, and they do the best they can 198 198 00:07:05,790 --> 00:07:06,780 to make sure everything's secure. 199 199 00:07:06,780 --> 00:07:09,480 But is it a hundred percent secure and reliable? 200 200 00:07:09,480 --> 00:07:11,190 Well, maybe, maybe not. 201 201 00:07:11,190 --> 00:07:12,660 Is it better than what you could do yourself? 202 202 00:07:12,660 --> 00:07:14,910 Well, maybe, maybe not. That depends. 203 203 00:07:14,910 --> 00:07:16,710 Now, these are decisions that the CIO 204 204 00:07:16,710 --> 00:07:18,120 and the CSO are going to make 205 205 00:07:18,120 --> 00:07:20,160 and then you as an analyst are going to have to fall in line 206 206 00:07:20,160 --> 00:07:22,140 and work through those decisions, right? 207 207 00:07:22,140 --> 00:07:24,090 Because again, these are servers that you can't see, 208 208 00:07:24,090 --> 00:07:26,190 you can't touch because you don't own them. 209 209 00:07:26,190 --> 00:07:28,230 Amazon owns them. Microsoft owns them. 210 210 00:07:28,230 --> 00:07:29,490 Google owns them, right? 211 211 00:07:29,490 --> 00:07:30,930 You only have access to the code 212 212 00:07:30,930 --> 00:07:32,760 that you're running on top of them. 213 213 00:07:32,760 --> 00:07:35,040 Now, if you do decide to start working with Serverless 214 214 00:07:35,040 --> 00:07:35,873 I want you to remember 215 215 00:07:35,873 --> 00:07:38,310 that Serverless depends on orchestration. 216 216 00:07:38,310 --> 00:07:40,440 It's all about automation and orchestration 217 217 00:07:40,440 --> 00:07:41,880 and being able to spin up 218 218 00:07:41,880 --> 00:07:44,670 and spin down resources very, very quickly. 219 219 00:07:44,670 --> 00:07:46,170 Now, a lot of that is done for you 220 220 00:07:46,170 --> 00:07:48,000 by the underlying services, but again, 221 221 00:07:48,000 --> 00:07:49,814 your code might need to take that into account 222 222 00:07:49,814 --> 00:07:51,630 as you're making those actions. 223 223 00:07:51,630 --> 00:07:53,730 Because if you're going to be using application logs 224 224 00:07:53,730 --> 00:07:56,250 just to be able to process an action or read or write things 225 225 00:07:56,250 --> 00:07:58,950 to a database, or read or write a log transaction 226 226 00:07:58,950 --> 00:08:01,440 or copy a file and deliver it to a user, 227 227 00:08:01,440 --> 00:08:03,660 all of these are things that require automation 228 228 00:08:03,660 --> 00:08:05,850 and connection between these different services 229 229 00:08:05,850 --> 00:08:08,040 that you're dealing with inside of this Serverless 230 230 00:08:08,040 --> 00:08:09,993 or function as a service perspective.