CompTIA CYSA+ CS0-002 – Service-Oriented Architecture part 3

6. Scripting (OBJ 3.4)

Scripting. In this lesson we’re going to talk about scripting because it is so important to be able to automate things. Now, when it comes to automation, one of the best places to use automation is within the cloud. Now, when you use cloud automation this is the completion of cloud related administrative tasks without human intervention. Now essentially this allows us to do lots and lots of things without even being awake or noticing that is happening. We let the computers do it for us. Now, when we deal with cloud automation this can occur through the graphical user interface, through the command line or through APIs like we just talked about. Now let me give you a good example of this. Here is a script. This simple script is less than 50 lines of code. Now you don’t have to read the whole script but if you want to pause the video and look at it, feel free.

Now this script, what is it doing? It’s going to go through and find every cloud instance in your AWS region. In this case it’s set up for the US East One region. Now this is going to be any instance that’s owned by your company and label as production within this environment. Then it’s going to take a snapshot of them. Now that doesn’t sound like a real big deal, right? If I only have one instance in the cloud this isn’t really helping me that much because I could log in, I could take my own snapshot and move on. But let’s think if you were a large company, let’s say you work for the US government for instance. They have hundreds and thousands of cloud instances sitting in that region. And so they can do this script and set up so that once a day it will go through and take snapshots for them. Thousands of instances all at once.

This means no people have to think about it. There’s no manual labor and it’s being done every single time because the code will run and do it seamlessly every single time. That’s the benefit of doing automation. Now, when it comes to cloud automation, this is really important because if we don’t have cloud automation and scripting we can’t actually do things like rapid elasticity. Because if I have to go and turn on a server myself and then install the software and then deploy it, that takes away all the benefits of this cloud elasticity. And so scripting is inherently necessary anytime you want to do orchestration and be able to do cloud automation. Now, what can you do with scripting? I just showed you a very simple script to be able to take a snapshot. But you can do so much more.

Scripting can be used to provision resources, add accounts, assign permissions and perform many other tasks including backup, recovery and scaling. It can provision, it can deprovision, it can do all sorts of stuff. It all depends on how creative you want to be and how you want to create your scripts. Now, when you create your script, you have to include several different elements. For instance, you have to have the parameters. What will that script take as input? You have to have the logic statements, what things are going to alter the flow of the execution? These are the if then else do, while all those things all come down to logic, then we have validation. We have to be able to validate input that’s coming in, that we’re going to get through the script and make sure it’s good. And then if we have something bad, we need to handle those errors, doing proper error handling.

And at the end of this we also need to do unit testing. Because if I create a script, I need to make sure I test it and it works flawlessly. Because if I’m going to spin something up and tell it to do it against 1000 instances, if I do it wrong on one, that’s kind of bad. But if I do it wrong on a thousand things, that’s really bad. It takes me a long time to clean that up. Now, when you’re creating scripting, you have to do it in a language. And there are lots of different languages you can use. For instance, you can write your scripts in JavaScript, Python, Ruby, Go, and there are numerous other ones out there. Now, which one should you use? Well, that depends on you and your use case. For me, Python is by far my favorite language. Most of the automation I do is written in Python. It’s easy to learn. It’s extremely useful for scripting as a system administrator, or as a cybersecurity analyst or as a penetration tester.

If you continue upward in the field of cybersecurity, I would recommend that you take at least a basic Python course so you can learn how to use it in the real world to make your job easier in the long run. Now for the exam, one quick tip. You do not need to know how to create scripts. That is not within the objectives of this exam. But if you do decide to move on to the Pentest Plus curriculum and that certification after CISA, be prepared to learn some basic scripting on that exam. You do need to know python ruby PowerShell and bash. You don’t have to be an expert, but you do need to be able to read those scripts and understand what they’re doing. Because as a Pen tester or a cyber Security security analyst, you will be analyzing scripts often and sometimes even writing your own.

7. Workflow Orchestration (OBJ 3.4)

Workflow orchestration. In this lesson, we’re going to start talking about orchestration, because orchestration is the automation of multiple steps in a deployment process. Now, when you take a process, you have to first break it down into its component parts. You need to understand what that workflow looks like. So if I start at the green dot and I want to get to the red dot, what things do I do to get there? What are those if and then and else statements? What are the different actions that go through? Let’s take an example. Let’s say you wanted to orchestrate adding a new virtual machine to a load balance cluster. Now this process might include lots of different things. You’re going to have to provision the VM, you have to configure the VM, you have to add it to a load balance cluster, and you need to configure that load balance cluster weight distribution to consider the fact that you added this new virtual machine as part of that cluster.

When you do all these things, there might be 4510, 1520 steps, maybe 100 steps, but you can do all of this through orchestration. And then you can automate it so you can run those things without having to do each of those steps yourself. Now, when you talk about orchestration, I want you to think about it this way. Orchestration is the automation of automations. Now, what does that mean? Well, each of those blocks in that flowchart I just showed you could be its own step. And that step may be one action, or it could be 50 actions. For instance, I have a flowchart and a path that talks about when you buy a course. Everything that happens from the time you buy the course to the time you start taking the course. And there’s a lot of things that happen because we have to create an account for you.

We have to reset your password, we need to add the course to your account. There’s all these different steps. And so each of those isn’t just one step either. Some of those have multiple actions inside of it. For instance, since when you buy the course, we have to send you a receipt. We have to log that inside of our purchase system, we have to make sure we accounted for the taxes that we have to pay on that. We have to account for the fact that we need to create an account for that and all those different things. And so if we can think logically about what is the sequence, then we can automate that sequence. And then if we take lots of different sequences and put them all together in one big automation, that is the orchestration piece. Now, when we talk about cloud computing, one of the biggest benefits in cloud computing is rapid elasticity.

When you go to my website, if there’s one person going to my website, we have one cloud server up. If we have ten people, we might have two cloud servers up. If we have 100 people, we might have five cloud servers up. If we have 100,000 people, we might have, I don’t know, 1000 or 2000 servers up. And what happens is this rapid Elasticity, it does this all on its own. It rapidly adds new servers, adds the configurations, configures them, copies the data, and then puts them into the cloud as well as part of our load balance cluster. All of that happens with automation. And this all happens because of the orchestration we’ve created. Now, when you start talking about orchestration, there’s really three types of orchestration. The first one is Resource Orchestration.

This is to provision and allocate resources within a cloud environment or other solution. When you talk about workload orchestration, this is for the management of applications and other cloud workloads that need to be performed and basically looking at the components to create the product you need. The third one that we have is what’s known as Service Orchestration. This is going to be used to deploy services into cloud environments. Notice the differences here. Resources is like an EC two instance in Amazon. You’re going to start up a new server, new VM. If you’re dealing with workload orchestration, this is about managing apps and other things that are working together. And then we talk about service orchestration, this is working on those services themselves.

Now, when it comes to orchestration, I want you to remember, you don’t have to be locked into one vendor. Everything you do doesn’t have to sit there on Amazon, or on Azure or on Google Cloud. You can pick one, two, three, or multiple. It really depends on you. And if you do this, there is some platforms out there that are known as third party orchestration platforms. These allow you to work on your product and your orchestration across multiple vendors and allows you to prevent this vendor lock in. Now, as we talk about orchestration, there is a handful of tools that you need to be aware of. Now, for the exam, the tools I’m going to mention in this lesson, you don’t have to memorize them all. You should just be able to associate what the tool is and basically what it does. But nobody is asking you to actually know how to use these tools.

At least not for this exam. So let’s talk about some of these. The first one we have is what’s known as Chef. Now, Chef is a way to automate configuration, deployments and the management of applications. And it does this using what they call cookbooks. And this basically tells you how everything should be configured. There’s lots of different recipes you can create and you can basically take these different services that are written inside of Ruby and put them together using Chef. Chef has the ability to work with lots of virtual machines as well as physical machines, containers and other cloud instances. When we talk about puppet. Puppet is very similar to Chef, but it requires the installation of a master server and then client agents in the different targeted nodes be able to do its orchestration. Puppet, unlike Chef, doesn’t really rely on as much programming, so you really don’t have to know Ruby. But you do need to understand some more traditional operations.

So Puppet is pretty popular, especially with some of the older school folks. The next one we have is ansible ansible. Unlike chef or puppet, doesn’t use user agents. Instead, everything is done using what’s called YAML, yet another markup language. These are different configuration files or Playbooks, and it allows the master to connect to the client machines over SSH to configure them. The next one we have is Docker, and you’ve probably heard of this one before. It’s an open platform for developing, shipping, running, and deploying applications using container based virtualization. When we talked earlier about virtualization in containers, docker is a good example of that container based system. Now, another one we have is what’s known as Kubernetes. Now, Kubernetes provides an abstraction layer for managing these containers.

So if you take Docker and you have all those containers, and you need to be able to manage them using scripts or other tasks reliably, you can use something like Kubernetes to do that. And then the last one we have is GitHub. Now, GitHub is basically just a service that a lot of developers use to share their code. If you’re programming and creating scripts, you can actually put those on GitHub. And if you’re looking for some kind of an automation, chances are somebody’s already built it. So if you’re thinking about how to orchestrate some kind of a new cloud service, you should first check on GitHub and see if other people in their public repositories have made that code available. If they have, you could take that as your starting point and then modify it for your own use. Case.

8. FAAS and Serverless (OBJ 1.6)

FAS and serverless. When I talk about FAS, I’m talking about function as a service. Now, function as a service is a really cool new technology and it is really one of these newer technologies that we’re using inside the cloud computing world. A lot of traditionalists don’t like the idea of function as a service because there are some risks involved with it, which we’ll talk about as we go through this lesson. But I do want you to be aware of this concept because as an analyst, personally think function as a service is a large part of the future and we’re going to have to learn how to use these things and how to be able to analyze them for security as we move forward. Now, when I talk about function as a service or FAS, what exactly is that? Well, it’s a cloud service model that supports Serverless software architecture by provisioning runtime containers in which code is executed in a particular programming language.

Now, that’s a really long way of saying we are going to be able to run things and make applications without actually having our own servers. Now that sounds pretty cool, right? Because now I don’t know about you, but I’ve been a system administrator for a long time, about 20 years. And the idea of having to run all my own servers and be able to run my own patches and do the updates and do all the testing and do all that stuff, just to be able to run a simple integration program like the one I talked about between Fresh Desk and Udemy, be able to make tickets, go back and forth. Sounds like a lot of work. And so function as a service eliminates the need for me to do that. Instead, I can write the code in something like Python and then run it in this environment. Now, when we talk about Serverless, you notice that keyword in this definition, serverless is a software architecture that runs functions within virtualized runtime containers in a cloud rather than on dedicated server instances.

So when you deal with Serverless, everything in Serverless is developed as a function or a micro service. Remember we talked about microservices all the way back in the beginning of this section. What do we say about microservices? We want to be able to give it an input and get an output. And the service should do one thing and only one thing so you can design it, build it and test it completely independently. Now, who is using things like Serverless and Function as a service? Do you know any big examples or big companies out there doing this now? Well, one of the biggest ones out there is Netflix. That’s right. If you’ve watched any Netflix recently, you’ve been actually using Serverless. Netflix delivers over 10 billion hour of video to 125,000,000 customers every quarter and they do this using Serverless.

They do this because they’re able to serve that large of an audience by using a wide range of highly complex infrastructure that relies on AWS, specifically its serverless capability known as Lambda. Now, all of this is done using this AWS Lambda, which is a serverless environment. Essentially, Amazon runs all these underlying servers and Netflix doesn’t have to worry about them at all. All Netflix needs to do is know that when they give them code that’s written in Python or some other language, lambda can run it and they don’t care about what that looks like underneath that. Now, we’re going to talk more about how this actually works, but Netflix is using this AWS Lambda to essentially build this rule based, self managing infrastructure that replaces a lot of the old inefficient processes and it helps them reduce the rate of errors and save them lots of time and lots of money.

One of the great things about doing Serverless is that it eliminates the need to manage physical or virtual servers. Instead, you just get the service you need, which is something that can run some kind of a language. For instance, mine runs Python. Now, when you do this, you’re not paying for these servers all the time either. You’re only paying when they’re executing. So my particular automation only runs once every couple of hours, and when it does that, it runs for maybe three to 30 seconds. When I get a bill, it’s for that three to 32nd increment four times a day, or six times a day, or twelve times a day, or however often I do it. And so the bill for this, for us, is less than one dollars a month. It is super cheap to use these things. Now, Netflix’s bill is a lot more money, but again, you’re only paying for the time that you’re actually using processing.

And so this is a really great way to do things and it can save you a lot of money. Now, what are some real big benefits here? Well, for one, there’s no patching because there’s no server. Two, there’s no administration. You don’t have to administer a server because it doesn’t exist. And three, there’s no file system monitoring because again, there’s no server. You’re just running code. Now, the underlying architecture here is going to be managed by your cloud service provider.So if you’re using AWS Lambda, it’s Jeff Bezos and his team at Amazon who has to worry about the underlying architecture. They pay for the network, they pay for the servers, they pay for the operating system, they pay for the patching, they pay for all the security, and you just get to run your code. That’s the benefit of using something like Server. Serverless. Now, what is your job though, as a cybersecurity professional? Because if we don’t have to patch and we don’t have to scan, and we don’t have to operate in admin, what are we going to do? Well, that’s a really good question.

Our job here as cybersecurity analysts inside of this world of function as a service and serverless is to ensure that the clients accessing the services have not been compromised. Now, I’m not talking here about your end users workstation. If you’re Netflix, it’s not your job to make sure that my home computer is properly patched and updated before I connect to your service. Instead, I’m more concerned with your developers workstations and their accounts because they’re the ones who are going to update the application code that’s creating these functions and services. So if I’m a programmer for Netflix, then you as a cybersecurity analyst need to make sure that my workstation is properly secured, that my credentials are properly secured, that I write my code in a very secure way.

So a lot of our job as cybersecurity professionals starts moving from the infrastructure side of things into more of the code analysis side of things. And that’s why cybersecurity is such a broad field because there’s all these different areas and that doesn’t mean that we’re going to be serverless tomorrow, that all infrastructure is going to go away because guess what? Amazon still has the underlying servers and so there is going to be some role for people to work at Amazon and Google and Microsoft to be able to run their programs and make sure they’re being done securely. But when we talk about working for a company like Netflix, their cybersecurity folks are much more focused on looking at the code that their developers are making to make sure it’s secure, to make sure their authentication systems are good, their authorization systems are good, and things like that.

So when it comes up to the idea of function as a service and serverless, we really have to ask the question, is it safe or is it risky? Well, with serverless it does have some considerable risk that you have to consider. There are use cases and best practices when you’re dealing with traditional infrastructure. But serverless and function as a service is still relatively new. So you’re kind of in uncharted territory here and being a bit of an adventurer, that in itself makes it a bit more risky because we don’t know the long term implications of that. We don’t know all the best cases and the best practices to use. Now another thing that’s risky about this is that you’re fully dependent on the underlying service provider. So I keep saying Amazon as an example, but Amazon is responsible for the dependency, the redundancy, and a lot of the security that underpin your services.

And you’re basically wishing all that away and hoping they do a good job. Now that is one of the things that is a little bit more risky because again, they haven’t been doing this for a long, long, long time. They’re good at what they do and they do the best they can to make sure everything is secure. But is it 100% secure and reliable? Well, maybe, maybe not. Is it better than what you could do yourself? Well, maybe, maybe not. That depends. And so these are risk decisions you have to make as an executive over time. And your cybersecurity analysts are going to have to fall in line and deal with the decisions you make at that CIO CSO level. Now, these are decisions that the CIO and the CSO are going to make and then you as an analyst are going to have to fall in line in and work through those decisions, right? Because again, these are servers that you can’t see, you can’t touch, because you don’t own them. Amazon owns them, microsoft owns them, google owns them.

Right? You only have access to the code that you’re running on top of them. Now, if you do decide to start working with serverless, I want you to remember that serverless depends on orchestration. It’s all about automation and orchestration and being able to spin up and spin down resources very, very quickly. Now a lot of that is done for you by the underlying services, but again, your code might need to take that into account as you’re making those actions. Because if you’re going to be using application logic to be able to process an action or read or write things to a database or read or write a log transaction or copy a file and deliver it to a user. All of these are things that require automation and connection between these different services that you’re dealing with inside of the serverless or function as a service perspective.