BSides Sofia 2022: Common security pitfalls in AWS Public cloud for highly regulated industries

Hello everyone, it's a pleasure to be here. Today we will talk more about compliance on Public Cloud and on AWS in particular. Hi, I'm Daniel Rankov, Cloud and DevOps consultant. I'm also leading a team of over 25 people who mainly do projects in all clouds, high compliance projects. I'm also leading the AWS user group in Bulgaria. If anyone wants to be a speaker, please, make an appointment, we'll see each other. Another thing for me is that I started my work with the society. Last year, BWS recognized me as the first and only EWS Community Hero in Bulgaria, which is a program of under 250 people worldwide, which I am very proud of. So, a few

words about regulated industries. Maybe most of us operate in such a way. I want to show how we can achieve, how the public sector can help us to build such a First, something that is crucial to pay attention to. If we use the public cloud, we need to know where we are setting the boundaries. What is our responsibility and what is the responsibility of the public cloud provider? Each public cloud provider defines a so-called shared responsibility model, in which it says what they are responsible for and what we as users of this public cloud are responsible for. This is the Shared Responsibility Model of AWS and if we don't know it, but we use it, I would recommend you to get to know it. What defines it

in general? We can see in the bottom part how they say: "Hey, look, AWS is responsible for data centers, cooling, servers, virtualization, etc." But for everything above, when you use a computer, you want to launch a virtual machine and upgrade it, the operating system itself, you are responsible for the data, to encrypt it, you are responsible. So it is very important, it is crucial to know the shared responsibility model, which the public delivery companies make and deliver for you. Here is a very quick reminder, if we manage the workload on on-premises What are the responsibilities we have? The whole stack, which is on the left, on premises, we are responsible for the data centers, for the physical

security, for the routing, for the bonding of the interfaces, for the racks, when hard disks burn out, we change them and so on. Up, the whole stack, to put a hypervisor, to put the virtual machine on top, to encrypt and do everything. um responsibility is no longer ours, we delegate it, we show how the public cloud vendor does it, but they don't audit us. That is, they reduce the overhead that we otherwise have. If we use a PaaS type system, you see, an even larger part is taken from the public cloud delivery. our responsibilities are much reduced. In the serverless world, when we use containers or Lambda functions in the context of AWS, the responsibilities

are even less. We only answer for the code, we can do code scanning, it is safe, static code analysis and so on, but for the entire infrastructure below, we are not audited. They audit the public cloud, that is, if we have an audit or a security check that we have to pass, which makes it easier for us. This allows us to deliver features as a business faster. We delegate the heavy non-value adding work to someone else. And it is already clear in the SaaS model. Here is a very quick example I would like to give if we have to manage a relational database. If we have to do it in an on-premises data center, we

have feeding, rack of the servers, maintenance, installation of the operating system, install of the database, installation of the database patches, making high availability, scaling and app optimization. If we choose to install a relational database on the public cloud in the form of a virtual machine or infrastructure as a service model, most of these responsibilities remain on the public cloud delivery, which is OK. At the same time, we have a considerable part that we also have to answer for if the next bug appears in the operating system and in our database. We are responsible for patching it. What most public delivery providers offer are managed services. In the case of AWS, there is a relational database service that manages the service from them. If we compare

what they are responsible for, we can focus only on delivering faster, better code. and a better service. They take care of updating the operating system, of patching the database and so on, which makes it much easier for us and takes us away from this non-value adding work, which we may have to do. The second topic, when we want to reach a certain level on the public cloud and on AWS, is to use separate accounts. Maybe we have one, maybe we have several, maybe we have more. And a good idea is to use an AWS account per workload. Maybe we should put one for development, one for production, one for sandbox. There are companies that operate with dozens, there are companies that operate with even thousands

of AWS accounts. There are companies in which each of the microservices works in an AWS account, others make sandbox accounts for each of their employees, so that they can exercise in such an isolated, dedicated account for each of us. In AWS, one account is completely isolated from another AWS account, that is, we have an absolute full independence. between the resources we are releasing. Account structure and always when we create an account structure we have a so-called Organizations account, one that controls the others. And I realize that the graph is a bit smaller here, but I wanted to show you that at the top we have an Organizations account that controls and has the right to

impose security restrictions on each of the other accounts. This is a so-called Organizational account. I will go through some of the services that I recommend to be released in every organizational account. Service Control Policy, SCP as an abbreviation, I see that it is repeated from previous presentations, but this is the model in which we can say in certain accounts that certain services are available, but others are not. Once applying SCP, service control policy to an account, no one in this account, not even the user can get out of this thing. Extremely strong approach. If you want something to not happen in your AWS account, you can put it on SCP. Extremely strong approach. AWS Single Sign-On solves our problem with Identity and Access Management. The

central place is the possibility to integrate it with external identity providers, regardless of the OCT or PINC or Active Directory, we can do it. That is, a central place to manage the whole Identity and Access Management for many of our accounts. AWS CloudTrail is a service that records every API call that occurs to the public cloud and gives us full trackability of who, what, when did it do it. That is, full audit, full tracking. One of the advantages of CloudTrail being launched in the organization is that it is cascading into all accounts and no one can stop it. In other words, in case our AWS account is hacked and we want to know what happened, no one

can delete the logs. We have them and we collect them in one central place, which is great. Access Analyzer is one of the newer services in AWS that allow us to When our users make API calls, X-Axial Analyzer collects them and helps us to make fine-grained access. What is fine-grained access? It monitors what users have done in the past three months, what our users or certain services have done. and then automatically generates a policy that says "I allow only this", because 3 months ago the consumer did nothing else. That is, it allows us to automatically reduce the scope of privileges, which otherwise we could have, by mistake, maybe, made wider. That is, a very strong service. Security Hub,

maybe also a must. I find it. A beautiful dashboard, it works in two models, that is, actually in three modes, we can put it. Automated checks that check once a day a large set of rules. We can put it with the CIS framework, that is, all the rules that come from the Center for Internet Security, or the Foundation of Security Best Practices, which come from Amazon. This is a beautiful dashboard, security hub, We can put it in any account we operate in. It can also be put on an organizational level, so it can collect the information and show where and what is not in order. For example, we have object storage or S3, which is public chain. We have a firewall that allows the 22nd

port to be open to the world and so on. One central place with predefined rules to show it to us. AWS Conformance Pack, and I realize that I'm going to quickly go through these tools, I'll have them in the presentation and of course we don't have time to go into each of them, but just as an idea. AWS Config is a service in which we can write rules, but there are already ready-defined ones from AWS. There are ready-packed rules and as a rule it can be: let's check every day if the virtual machine storage is encrypted. Let's check if the load balancers are available only on HTTPS, without HTTP. In general, we can write down all the rules we want to be checked. Conformance packs are a set

of rules that AWS gives us ready-made and there are ready-made ones regardless of the industry we operate in. We have for PCI DSS if we are in the financial industry, we have in HIPAA if we are in the healthcare industry, etc. I recommend to pay attention if you have to guarantee to the auditor that we are responding to certain rules. Guard duty, intrusion detection system in AWS, it is fully automated. This is something that we just release and it sends us notifications. It is not a prevention system, only detection. And I'm ending with the service review. If you have a fleet of virtual machines that you need to monitor, if you have the latest patches, what is installed on

them, inventory management, if we want to gather in one central place, Systems Manager can do this. It can do many other things, but even more, despite being an AWS service, we can install an agent in our on-premises world. That is, if we have data centers, we can install an agent in the cloud, in AWS, to see which machines, which patches are installed, we can even make policies for automatic updates and patches, which takes away from the very manual work. Great. Another topic. Whenever we create a resource in the public cloud, it results in an API call. No matter if we create a database, a virtual machine, a wall balancer, a security group or whatever, no matter if we do it through the web

console, where we click with the mouse, through the SDK or through the CLI, it results in an API call. Okay, what is it? We can automate it. What is API call? We can invest enough. The easiest thing is to say, hey, what is creating a network layer and a compute layer? API call, I can write scripts. Of course, scripts are not always enough. There are ready tools that do dependency management between services. so that they are created in the right order. The approach is known as infrastructure as code and if we do not use it, I strongly recommend that we pay attention to it. Infrastructure as code, some of the advantages are, of course, security. Our entire infrastructure is described as code, as source code. No

one goes to shake hands, whatever it is. Imagine the power of this thing. We first write the code, we can, why is it safer, we can implement the internal peer review process. We can see that certain security groups or other rules do not keep the policy in our company. And this is even before it reaches production. This is at a higher level while we are writing it. Auditable and traceable, of course, our source code is in version control, Git repository, maybe like that. So we have full traceability, who, when, what has changed, who has approved it, who has reviewed it. Repeatable and consistent allows us to run the same infrastructure with infrastructure as code many times. If we want, in our history back, I have seen

production downtime, maybe you have seen it, due to inconsistency between production, staging, development, etc. Infrastructure as code solves this problem as well. The code, the services are the same everywhere, maybe dev and staging are more downscaled, computers to not pay so much. Documented, of course, everything is as code, so it is documented, can be part of our CI/CD process. So there are already automated tools to check our infrastructure even before we have installed it, even before we have applied it, before a problem has occurred, we can scan it and tell us: "Yes, here you have a problem." And cost-effective. Just as there are tools to check for security in our code, there are already tools

that scan The biggest one is Terraform, which says that the new code you have written will cost an additional $300 per month. That is, again, we create more predictability for our infrastructure, or it will cost less because we are optimizing. And this is even before we have put it into production. Before we have created this infrastructure, we have the information of how much it will cost and how safe it is for our customers. CheckOff is one of the most famous tools, a very good integration with Terraform. For the moment, it is the most proven tool that I use to scan Terraform code and infrastructure code. Another thing that the publishers and delivery companies help us with, and if you pass

through Zodiac, you can sometimes see things that might seem crazy to us, just a control checklist. There is defined by the auditor or the framework what needs to be done, but how this results in the technical implementation is not always one to one, we do not always have direct mapping. Public cloud providers, in the case of AWS, provide a security control mapping matrix for more audit frameworks. In this case, I have shown HIPAA, which is valid in the healthcare industry, but they translate the audit rule to technical implementation, what they think is applied, which takes a lot of time when we want to achieve the same thing. The topic of data, the management of our data, of course, is key. Data residency

and sovereignty. Where is our data located, regardless of whether we have to answer GDPR or California Customer Privacy Act. The public cloud gives us the opportunity to choose in which region of the world to launch our infrastructure, where to find it, the compute power, the storage, where to use it. At the moment, AWS has over 24 regions, with 6 already announced in the world, which are in progress. So we have a choice regarding data, regulation and law and the industry we are in, we have to choose the right location. Another thing that the public cloud helps us with are the so-called referential architectures, ready architectures. If we think that we are the first to want to make PCI DSS

on the public cloud, this is not the case. Many companies have already gone through this process. What they do at AWS is to say: "We will recommend you when you do PCI DSS, when you do HIPAA, when you do other types of workloads, use these templates. We can reuse them directly or we can to review them and to use them in the way we like. Regardless of the domain in which they are located, Security Identity Compliance, Analytics, Big Data, Compute, there are many more ready referential architectures that will help us to deploy the workload in the right way for the compliance framework we need to respond to. Part of the compliance program of AWS, here you see SOL, of course, the standards, HIPAA, and PCI

DSS can be seen somewhere. Department of Defense also, FedRAMP, if you work with companies or clients, you work with the US government, it is also a key thing. We can refer to the clients, just to see the case studies. There are banks that operate entirely on AWS, that is, it is not in a hybrid regime. Almost every business domain has companies operating on AWS entirely. And here, NASDAQ this year will launch its first market on AWS, which is even more impressive as information. Otherwise, yes, a number of services. Robinhood, maybe you are familiar with it too. Okay, and of course, if we want to really build a secure world without the cultural element, without working together, the security people, the people who deliver

or build the software, with development, with operations, it is more difficult if we work only in separate silos. Before we talked about breaking the wall between the dev and ops and this dev-ops culture, we already call it dev-sec-ops. To work more, to break, to literally sit in a bureau together and work, This will lead to faster results and a safer world. In the end, we all have one common goal - safer working software that will serve our clients. I pressed something. And the last thing that may seem complicated here, but I want to mention it. Everything in the public cloud is a matter of API calls. When we have an API call, we can automatically automate our incident response procedures and processes.

Usually, what do we do? We have an incident, let's say a virtual machine, the antivirus has detected that there is a virus. What do we do? Well, if the mode was manual, we would connect to the machine, maybe start viewing, to make a snapshot of this machine, maybe a memory dump. Well, we can automate such a playbook and let it be executed, regardless of the part of botnet, it sends spam, etc. What we can automate is to automatically make a snapshot of this machine, to connect to it, to make a memory dump, to keep this memory dump so we can leave it on the forensics team, to capsulate this machine through a so-called security group, that is to stop incoming and otherwise incoming traffic to it, and to

turn it off afterwards, after we have collected the data for the forensic team. And this can be fully automated. We don't need to wonder what to do in two hours. Again, it's all a matter of API call and the public cloud allows us to make such automated incident responses. To get to know the shared responsibility model that sets the public cloud, to use multi-account strategy, to use more managed services, because this focuses us more on what we help our business to provide more value to our clients, instead of managing servers and doing cabling. Security Hub is a key service for me, Infrastructure, REST Code and working together. Last words from me. AWS has a Reinforced Conference this year.

This year it will be in Boston. If anyone is interested, otherwise, the annual conference "ReInvent" is a very important topic for security. If someone is already working in AWS and we need to manage secure workloads, I highly recommend certification. There is an official study guide, which is from AWS, around AWS security competencies. And yes, I recommend it. I have left most of the resources and the topic, of course, is big, so the list of resources is not small. Yes, tell AWS user group where we talk about security and many other things. If you want to continue the conversation, I am on the line. Thank you.

If there are any questions. Yes.

Good question, I will tell it again with my words. The question is whether we should choose a public cloud supplier. In the case of AWS, we saw this year that the region of North Virginia was broken for a period of time. There were small businesses that were suffering from downtime. Should we use the alternative of multi-cloud suppliers? Did I tell it right? This is more of a business problem, it is not that technical, but the common commonality between all public suppliers is very small. It is very difficult to build a multi-cloud world in which we all have the competencies to monitor the news, to monitor the security advisories, there are companies and not small, Uber, companies with a lot of money that want

to do this, the opposite view is better. Let's choose one public cloud delivery, on which we can be specialists and if it fails after a while, breaks, raises the prices, does something huge, the price for migration from one to another is lower than the price to operate two clouds at the same time. This is in every case. I assume there are different use cases, but this is in the general case. It is more effective to choose one in which we can be professionals. It is very difficult to be professionals on an expert level in two cloud. Working in such a team, building such a team is very difficult. This is the general opinion. This is not my opinion. It comes more from

the enterprise blogs of public cloud suppliers. The topic is wide, of course, around vendor lock-in and the topic is wide. Kubernetes, one might say, yes, it solves everything simultaneously. Kubernetes creates abstraction somewhere, but if we think about the lower layers, storage encryption, load balancing, even the network layer, ESL certificates, the network stack, is not trivial. It is not a solution to make it. Most companies that talk about multi-cloud are the ones that profit from multi-cloud. Hushcorp is one of them. They produce tools that are multi-cloud tools. year-long report, you will see how Multicloud is becoming a bigger adoption. Which is what they want to sell better sheep, which is great. Also Multicloud is strongly dependent on smaller cloud vendors, Oracle. There

is a 1% market share in the latest Gardner reports. Of course, they will need to use multi-cloud. Why? Because this is a way for a smaller public cloud to take more business. The topic is big, but thank you for the question. Yes? Let's say that the services are not very good, but the services, let's say, there are no services that can be used for safe use. Good, we repeat the question for the audience. The question is what do the big delivery companies do in the case of AWS so that it is easier for us to use them and that we should not be experts in everything. Up and down, good paraphrased. What the big delivery companies do There are many

initiatives. Certification is one of them. There are companies that when they start using the public cloud, they think that this is only a technological change, but this is wrong. AWS, Microsoft and Google define their Cloud Adoption Frameworks. The Cloud Adoption Framework talks about six major topics and only one of them is technological. The topic of security is governance, licensing management. The topic of people upskill and whether people can do it. We adopt the cloud, we start using it and from tomorrow things will start to break down. Why? Because our talent, the people we have hired, they can't use it. That is, training, certification, the path is the second big topic. How do we operate long-term, how do we reduce the price, this is the third big

topic. Again, my answer here is long, but public transport companies have a number of investments on the subject. The first is that if we look at the big picture, they see it. They want big businesses to start using it and they make very clear steps on how to address every single pain we may have. How do we do backup and disaster recovery, how is our security increased, how is the documentation better, how do we have higher uptime, how is the trained staff. That is, they do it on the big picture. On the other hand, what is happening is that are making more and more managed services that are easier to use. Whether they will be changed in the UI interface, so that

when we launch virtual machines, they are safe and port 22 is not public. They are doing the same thing. AWS made it extremely difficult for an object storage in S3 to be made public. They made it difficult because, of course, it was not their fault. A client came, they put a number of data, S3 is the biggest data lake in the world, and companies started using it. What happens is that someone by mistake puts it in public. data leak, something that is very bad. Of course, the person who configures it is responsible for the shared responsibility model, but at the same time it harms the entire industry, because the industry says "oh, we use a public car and the data is not leaked there", which

is not the fault of the public car delivery. Therefore, a deep understanding of the model and of course What they do is exactly the same type of tools as security hubs, which give us visibility over the environment. That we have security groups, open ports, non-encrypted storage, load balancers, which are not HTTPS, etc. etc. That is, they make it even more visible. If until years ago it was just "here is your platform to run virtual machines", now there are many rows of tools that will help us. What happens is that when we say that we can let our services in different regions, we must take into account that the regions are not like people and are not born equal, that

is, they are different. Each region has newer and older regions. The older ones are about 5, which are big in our geographical area, like Ireland. They are in the east-west of the coast of the coast, Singapore is another one, where almost all new services go immediately, they are immediately released, they do it in AWS, they go to the largest regions. They are the largest in general, as data centers, as compute power, even as sustainability projects. That is, how energy efficient they are, how much green energy is bought to be used. The smaller regions do not support all services that exist otherwise. This is normal. When Frankfurt is built as a region, or Paris or Milan, the smaller regions The expected compute load to them

is to be more regional, to be used in Milan from Italy. They don't need the huge computers that there is in a larger region. It is not so much about GDPR, but more about data, residence and sovereignty, where our data is. and the banks, and NASA, Department of Defense, Border Control, in the UK they use AWS, and government agencies use AWS, they want their data not to leave the country, very often. That's why they opened the London region. So it's not so much about GDPR as it is about the local... - Yes, this is a technological topic. It can be addressed to AWS. This is great. I don't know if we have time. I would be happy

to drink beer with someone later. No, we have time.

Yes, 99% and 97% of the services. AWS has nearly 200 separate services. For each of them, there is one or two exceptions. This is so. CloudTrail's goal is like the nervous system in AWS. When there is an API call, CloudTrail records it. That is, they should catch everything, everything, everything. And we have made a number of optimizations for all the services I have worked with, there have been some logs that have been lost. That is, I can't think of a service that is not maintained. And exactly based on the event layout, this automation can be done. That is, we accept an event that, let's say, a virtual machine is launched. We can immediately check if the storage is encrypted, if there

are any last patches and so on, when we have the ID of this machine. That is, with a higher percentage, my answer is yes. Thank you again.