Presenter:
Transcript:
Have a special guest, Ivonne Fernandez, who's working with Cyber Solution Architect. She has over a decade of experience in IT security, specializing in secure solutions across various domains. She focuses on AWS services and is dedicated to solving complex security challenges while staying current with industry trends. Could you please give her around a hand? Flowers.
Thank you. My presentation has a lot of diagrams, and I'm not sure if you will be able to see then in the back. So I'll really encourage you to move to the front and the presentation and go into leaks. Publish data at dawn probably of this week in my LinkedIn profile, so feel free to download it. Glad you're here and thank you for letting me talk today.
We will be talking about cell trust as a strategy. I'm trying to bring a couple of samples from the architectural standpoint of how that can be apply. And I'll tell you why I select this CSR as the zero trust model. To do my presentation I will encourage you to do questions. And then I'm plenty to have probably 35 minutes of my section so I can leave like ten minutes for questions at the end.
And how many of you have built a strategy before? Great. The reason what I put this slide here is because it's very important to understand what are the security roles and responsibilities as part of our strategy. And I on purpose, highlight the security architect role, because what I'm presenting today is from the lens of an architect. So I don't trust will mean different things based on the role that you are.
But today my presentation is from the lens of an architect. So this is me in 2000 dealing with simple security. But those days we only worry about viruses. So we have a simple, antivirus. We wore security firewalls, we deal with PCs, few laptops. Remote access was limited. It was simple, right? An intrusion detection system was something that I was studying.
Evolving. Back in those days, internet was also coming out.
However, this is what we are dealing today. The environment is more complex because we have people working from everywhere that wants to access data anywhere. But we are also dealing with tons of hundreds of SaaS applications and probably how many of you have the three cloud providers AWS, Azure, and GCP in your environments, right? So to make things more complicated.
Before I continue, I want to create I want to show you this report. This report was put out by Cloud Security Alliance in 2022. And it's talking about the 11 threats that we see in cloud computing. If you notice and I'm sorry this is too small. That's what I'm saying, that if you guys can move to the front, but the first four, are basically identity, weak identity and access management, weak APIs, misconfigurations and then a lack of cloud strategy.
Last month they posted a report again. And now misconfiguration is top one. But they haven't changed a lot. What this report is telling us is that who is responsibility in this case you think that is a cloud provider or is us? Us? This is our responsibility. And I predicted that misconfiguration was number one. And sure enough, that's what we come with.
This report last month is hard because we have if you look at AWS they have more than 230 services. Right. Do we know all of them? Do we know how to configure that? The answer is no. Even inside of AWS these people have their specialties. You have database specialists. You have identity management specialists. Oh by the way, that report is very good in terms of telling you all the cases that they analyze and also giving you the threat modeling, points and the cloud metrics for access control.
So I really encourage you to read that report. It's really good. Now under before you start strategy, you need to understand what is the motivation of your company to move to zero trust. Before you start, you should a trust journey. You can. You always have limitations in terms of resources and money. You need to focus on what are the drivers.
So I put here a couple of them for the company that I currently work. They want to go to the IPO, and they mean that a lot of compliance and regulations are coming up. So this is the reason why they want to go right. So understanding all these challenges is important. Before you start this this journey. Now there are different kind of definitions for certain trust model.
And I only mentioned here. So NIS 802 or 7 is is a framework that is very generic that can be used across all industries. We have the D of D or defense of I'm sorry, Department of Defense, which is basically used a lot in the US, especially for the Defense Department. But you will find us some other companies like that framework as well.
National security Agency. However, I'll be focusing on Cisa, which is the Cybersecurity Infrastructure Security Agency. And you'll see why in a minute. So let's start with understanding what is zero trust. Zero trust is basically a model. It's an a strategy. Is it help? It helps, define the next generation of capabilities you want to enable in your architecture.
A lot of other vendors will tell you, oh, by my product line, you are zero trust. No. It's zero. Trust is not technology.
To understand zero trust. We need to go back to this tenet. And when we talk about strategy, they are going to be important. So when we started talking about some bridge, if you as an architect start helping you organization, architecting things from that point of view, understanding that is just time one they will be bridge, your mind will change and the way we do things.
And I have an example later to show you how you could do that. Then the other is never. Trolls always verify. Believe it or not, we say, oh yeah, we don't have to be worried about insiders in our organizations. You never know. So you have to treat outsiders and insider threats as 5,050% and in this case, equally. And then when we talk about, less privilege, this is a very fun one because especially in AWS, how many of you are seeing identity and access management on AWS and how many of you consider that in your organization?
The permissions that all these developers have is less privilege. Just raise your hand. What I have seen most of the time is, oh yeah, he needs the permission, but because he needs to access that and I couldn't figure out permissions like even left this person. I mean, I'm in role. So over provisioning and over permissions is it's kind of common.
Okay. So let's go back to CSA roles. So these are zero. Trust is based on NSA. Oh they got the best. They got the best of the pillars from NSA and D.O.D.. And this is the reason why I choose, this model for my presentation. So we have five pillars. We have identity, we have devices, we have network applications and data.
This are the five things that we need to work on. Which one do you think that is the most important one in your opinion? Identity will be one. But what is what is the reason why we want to provide really good identity? What are we trying to protect the data. So understanding data is also important. You can say oh I'm going to protect every team.
You need to think about what data is that you really want to protect. Because you don't want to design controls around data that doesn't matter for the business, right? Okay. All these five pillars.
Had three foundations that we need to have. We need to have visibility. Meaning do we have locks and a way to analyze those locks. And we'll talk about that in, in in the presentation. You have to start thinking about automation and orchestration. What that really means is can we detect and response and remediate from the from automation standpoint.
Right. And the last one is governance and compliance. If you look at the D.O.D., framework, they don't have governance and compliance. So this is why I choose this one in my opinion, is the one that has, like more complete picture of what we need to have in our architectures. Okay. Let's talk about strategy. Here we have CSA Central's maturity model in.
Use this for two things. You have different levels in your organization across identity and all the pillars. If you are building a strategy. First of all you need to understand what is your current state. So if you go against this and I say, well, yeah, we use passwords and we have simple MFA, what am I right? The next step will be where do I want to go?
What's the, future state? Oh yeah. We want to go to the V, the optimal. Well, what that really means. So this maturity model help you create your roadmap in terms of where you are, where did you want to be. And that will help you with your gap analysis, right? What are the things that we need to work on.
D zero trust capabilities. And I apologize for this being a small but as I said, you will have all the links where you could go and grab all this information that I put together. They also have their levels. So you could either use CSA or DoD, or you can use a combination of both to help you determine where is what, where are you, what is your current state and where do you want to go?
Here is we're doing your gap analysis, and this is what I was talking about. If we assume bridge when we are architecting things, which for me, this is an exercise that I do for a company, they have credit card data everywhere. And when I ask the owner, oh well, yeah, we need that for analysis. I'll say, okay, let me ask you questions.
What happens if you get rich? What is your fine for each great car that you're saving? So after doing that exercise, I assume a bridge class is what we came with. We say, okay, let's limit the amount of credit card data. We're just going to hold it for the period of time that the customer is doing transactions with us.
Once the customer finished, we will delete it to let us implement tokenization so we are not responsible for I mean, I'm sorry, from the PCI standpoint, compliant, the payment processor, we'll do all the PCI compliance. We just have to be worry about those tokens, right. But what happen if those tokens are stole? What do you think?
In my opinion, not them. Because at least they have a way to go and translate those tokens to real credit card data. Then I'll have to be worry and.
Because they were recording all the calls and the users were put in, sorry, the consultants were put in that information. We wanted to start recording, and then we decided that all the data will be encrypted before that data is outlawed. It to the S3 buckets. So see how your mind change after you start thinking we're going to be bridge no matter what, you start thinking and designing in a different way.
But let's talk about the first pillar, which is trust is identity pillar, which I agree with you. Identity is one of the most important things because if you look at from the data breaches perspective, this is where we're getting a lot of a lot of track. Right. And it's changing in the past we're talking about only users.
Now we're talking about all these services that are non-human, that we also have to secure and believe. Now secret manager secrets manager is one of the hardest because we don't have control over okay. So this is bear with me. This is the, set up to cross reference architecture in terms of AWS. But if you notice at the bottom we have governance risk and compliance.
We we saw that in CSat right at the top we have orchestration which is basically your CI CD pipeline. On the right we have observability. We're going to be looking at what things you should be logging and looking at. So when we start talking about identity we are talking about AWS accounts. And we are talking about identity and AWS identity and access management.
But from the perspective of governments, you still have to do a AWS account managing and managing that access. In some of those cases that are outside in blue, you might need to use tools, third party vendor tools to help you with that. So let's start with the perspective of accounts. Go to a multi-account strategy. And the reason why you want to do this is because you want to limit the blast radius.
How many of you have seen your company having DEP and prod mix in the same account?
Okay, don't tell me, but I have seen it a lot. So the idea is that when you start crafting your strategy, create multiple accounts for different reasons, and keep your prod and your DEP environment separately for your applications, in part because you want to eliminate the blast radius. If one of your accounts get compromised, compromise the rest. And so more into that, do you want to select one of those accounts to be the managing account?
Because the next thing that you want to do is use AWS organizations to start organizing those accounts in organizational units. And you might want to use Control tower to help you from that standpoint. I will see it in a minute from the standpoint of provisioning accounts in a automated way. While we call the vending machine. So the beauty of having those organizational units is that now I can put something called service control policies.
This are my guardrails that I can put on AWS to start determining what can be done and cannot be done in those accounts. Here's an example. If my environment is fully control, I want to I want to put service control policies. What services can be available? Do I one for instance to use Cassandra? Maybe not because the company hasn't approved that database yet.
So that's one example. Another example could be I don't want anybody to spin accounts in a different region. I want to put that control policy and say only these two regions are allowed to spend resources. Sometimes I did, and I have done it by accident spending something. And I didn't realize that is in Ohio. Right. But sometimes, even for compliance, you don't want anything outside of you at all.
Right? So talking about control Tower, notice the concept of vending machine. And this architecture. You're still leveraging AWS organizations. You probably want to leverage AWS CloudFormation to programmatically control the creation of accounts in a systematic manner. With all the governance in place and compliance that you want in those accounts, not necessarily. You could use AWS CloudFormation. I've seen companies using Terraform or what's the other one?
Pulumi. Okay, this is what I was talking about. Here's an example of a service control policy where I could say, hey, don't allow this, someone to stop an EC2 instance if they don't have, for instance, MFA enabled, you could do you can be very creative with the kind of service control policies that you want to put in place.
In the long term, you want to move from long term credentials to short term credentials. And this is what I meant. In the past, we used to have 3 or 4 accounts, and you probably start using identity and access management and create local accounts for users and probably start using, cross accounts roles so people can assume one role from the other.
You don't have to over these. And imagine if you have 200 accounts, that'll be a nightmare to manage. So what we would like to do is to move to a federated way to do this. So use Identity Center. Now you have your accounts, you have your organizational units. Now you use Identity Center to create users and create those groups and determine what kind of roles those groups can ask you.
So you are using this from the central standpoint.
Now in terms of real life in your companies, from identity and access management, you may have other tools, right. You may have sale point to do identity and access management lifecycles. So this is a tool that might be connected with your HR system and detect when a new user is on board. And you will use this tool probably to do role based access, certifications.
Hey, you are a manager every three months because you are handling a system. You need to certify that these users still need permissions in their. And so then we have an authentication management tool could be Okta which the role will be authenticating those users in a SSL manner and will handle all the MFA portion because we want an advanced MFA.
And then you might have to have a tool for time to manage all the privilege access management, maybe something like Beyond Trust. Oh, by the way, I'm not selling any of this. This is just to give you an example from the identity and access management perspective of what you should be having. Again, depends also on your organization. If you are small, you need all this, right?
Okay. I use Okta for the sample. As I said I'm not selling that. But just for the example of showing how you can have your HR, this thing connecting to Okta, what, and you still have domain controllers. You may want Okta to have all the groups or those groups are coming from an active Directory. Depends on how you architect things, but those are being synchronized through Saml and scheme over AWS.
So you can have a centralized identity and access management.
Here is remember what I was telling you, that we want to move from long term credentials to shorter credentials. Here's an idea of something that I'm working on right now. And this is I want the developers to connect to AWS using my SSL octane a token. And from that, talking they can connect to the database. Is that long term or short term credentials?
Short term? The beauty of this is that they are not only authenticating against AWS, the time to get in against Okta, and also because I'm using multifactor authentication and even, how many of you know, do wikis.
So if you have YubiKey, which is a hardware kind of pass key, but it's a physical hardware connected to a PC that can give me sounds certain that that user that is connecting is the user that it is. So this is where any of these tools can help you put more controls to improve the security. Anyway, the other concept that we are moving into is jazzing time, less privileged access.
So I picked up Okta in this example. But I believe Cyber Ark will work in the same thing. The idea here is that production environments should be locked, right? If I need to do something in prod, I should be requesting that access and that access should be give it to me temporarily, maybe for an hour or 2 or 3, I don't know.
Depends on what I'm going to do there. And once I'm done, I don't have access to that anymore. And I put the link in there because this is one of the cases that is that AWS is polishing. But just to give you an idea now, I told you use doesn't have anything about device pillar. Here's where you if you are going to be working on endpoint protection and mobile device management, you will need to look for tools outside of A.W. as there is not really a lot for that.
Now let's talk about the network. When we start talking about network, here is something important to understand. In AWS, there are three kind of applications that you can build. You can build applications based on VPCs. In that case, your responsibility is to secure your virtual machines. Your VPC is your security groups. All the resources, pools, APIs because believe it or not, then we're going to talk about this.
Everything on AWS or any cloud provider can be accessed by night by an API. And the second case is serverless. You might have applications that are using Lambda functions where everything is serverless, that are specific case. My responsibility is API and misconfiguration. Make sure that those services are not misconfigured. All right. And the third kind is where you have the mix of both.
In that case apply both cases you have to secure everything.
Now when we start talking about network we are talking about VPCs. Imagine there are VPC is your virtual data center right where you still have to define new routes. You still have defined your subnets. You still have to define how things are going to be connected. Is that going to now going to be public or is going to be private?
And the idea is that, okay, you have one account, try to have one VPC for account. I think it's a mistake. Right here is a VPC per application. Because you can have multiple VPCs inside of your account. I need to fix that. The idea here is that you start having a standard for resource. So here look I have a private subnet for my load balancer.
I have a private. So for my EC2 instance and I have a private subnet for my database. Why. Because oops did I go now. Like the next thing that I need to do is have security groups. So I'll put security groups for resources. And I can limit what can connect with what using those security groups. In this case, I don't want the load balancer to talk to my database directly.
So when you start segmenting this using, success and security groups, it gives you that granularity. Naxals is a concept where you basically are putting, a kind of firewall, but you are doing additional level security groups are done at the resource level. Understanding the difference is important too. Most of the time you see companies using security groups, because if I want if I open a port, I bound port.
The traffic that is leaving now is able to come back. That doesn't happen with Naxals. So you need to understand the difference between both of them. In a very high control environment you use both, right? But you still have to be careful when you design those.
Now we are talking about VPCs and we are saying, hey, the idea. So you have VPC per application. So here is an example. I have a remote working environment. One VPC have my domain controllers. Another VPC has my work spaces. Right. So I still having tried to separate that, but how they communicate basically with VPC peering. Then you say wait a minute, what if I have 200 VPCs?
That will be a like a nightmare trying to control what who can talk to what? So the here is when you have more complicated environments, you want to use AWS Transit Gateway. And what is Transit Gateway is managing all those routes who can talk to what you have in a more centralized way. Again, you have to be careful because if this is more configure, then you are allowed traffic to go places where it shouldn't be.
Right? But do you have that choice? This is a very important, concept that I didn't know. Did you know what happen when you request the access to an S3 bucket? You are charged. True, but that's going out of to the internet. That traffic is traversing the internet to come back to AWS. Do we want that? No. What we want is to use a VPC endpoint where I say, wait a minute, I need to talk to my S3 bucket, but I want the traffic to be local.
I don't want to go out and come back. So you should be using VPC endpoints for S3 bucket there. Data v anywhere is serverless S3 buckets, databases SQS is an S. So here is an example of an application that needs to talk to microservices and I using a VPC endpoint. But notice that at the other end I need to use an AWS API gateway endpoint.
So for VPC endpoint I need an endpoint that I will support that on the other end.
Privatelink is kind of a VPC endpoint, but this is for other services that doesn't support or doesn't have that VPC endpoint. Here is for an X. And in this example we have a load balancer. But here I'm controlling where the traffic is going and I keep it private. All right let's talk about application security application and workloads. And this moving okay.
The reference architecture now is tired of being more complex because from the DevOps standpoint and this is where I data an enhancement. We need to be sure that we embed security when we are doing this CI CD pipeline. And that is not happening in most cases today. We want to scan before we deploy, and if things go wrong, they need to go back.
I see a lot of companies you in the company I work for struggling is still in this. They do it after right and manually. You probably can do static scans. You probably do a lot of this stuff before they deploy. But the idea is to be part of it. The idea is to integrate all that security in place.
Okay. When we talk about application security, I want to create this awareness. Everything in the cloud is API reachable. So how can I ask is that most of the time we see the console I AWS console. But that's not the only way I can access that using the SDK. So for that specific case, I need a I need a key and a client secret for that API key.
Right. Do we have you? Similarly we need to have visibility on where are those keys creating how these keys secrets are being stored and what kind of privileges. Because based on how do you create on the roles of those keys, you could do a lot of stuff. And then that can be through SDK or in the worst cases, in theory, I can do this with placement.
I don't have to be an expert if I can find APIs that I can play with. Diagnose security enough. So from the perspective of, you as a security architect or architect in general, it's important to have reference architectures for your people. I just put this one in here because this is a typical API application, API application, any serverless.
But that doesn't necessarily mean that this is the only you you want. You want to go back to your environment, understand how they are architecture, how they are building those applications, are they using microservices and try to understand all the components and see what kind of security you need to put in place? For instance, secret manager, this is one of the things that I have seen in organizations.
That is a nightmare. Where are they keeping secrets and how those secrets are being accessed? Who has access to those secrets? Are they being rotated? Are they encrypted? Right. So in, in in this specific sample. If you are building APIs, you will like to have one point of entry. And that point entry might be managed by API gateway.
It necessarily mean that you have to have a AWS API gateway. There are many other vendors based on the architecture that you are analyzing. You want to make sure that the access point is just one, and from there you are protecting those APIs behind it. And the other one is that I want to create. If you go online and look for the always top ten, there are four APIs as well.
Okay. And from the observability standpoint, you need to make sure that you may have this CloudTrail to log on all your API access and you want to have. We'll talk about CloudWatch later, but you want to make sure that these services are in each account. So you will have visibility. Of course that cost money. I can hear that.
Yeah. From the application authentication standpoint, this is something that I see that is kind of complex. Understanding how your organization is building these applications. Customer facing where you are managing the customer identity and access management. And here the proliferation of open ID and open authorization protocol is really high. But do everybody really understand what are the best practices to architect these kind of applications?
This one of the things that is is really hard. Like, when we talk about users authenticating, what kind of applications are native, are mobile and web. And based on those applications there are standards. So how that exchange of tokens should be happening. And sometimes you will find that that's they are not using the best practices. And again when you call your APIs, you should be parsing what they call an access token.
And JS also best practices. What information should be traded on this tokens. Because these tokens are public meaning like kind of sold at any time. One of the misconfigurations that I see a lot is that I do token and access token. Sometimes they have too much sensitive information. Yeah, information. So let's say something that you can inspect in your applications.
But that's our whole world open ID and OAuth protocols. They are big in their on from.
This is another architecture where you can use AB0 or you can use AWS Cognito, whatever identity provider you want for you customer application. Again, it is another way to do it, but at the end all of them are using IDPs for authenticating your customers. You need to understand how this is done from the data perspective. We are talking about certificates, key management.
We have been talking about encryption. I don't think that this has changed. So this is how the whole picture of you architecture looks like. And again I'll, I'll, I'll share this with you. But we should be doing vulnerability management. We need to be doing application management from the observability standpoint. We need to be able to monitor our infrastructure.
We be able to have event logging. And we're going to start talking about I know, you know, chat up to protect data and transit and rest. I want to spend a lot of time here. But here is where you want to start thinking about how you are going to connect, have logs in all the accounts and how those logs should go to an account that is read only because you really don't want your adversary, or to go and delete those logs.
And from there you need to figure out how to connect them. Not sending to your, even manage them. I put some more logic in here, but that necessarily means that this is just understand whatever told you companies choosing how you can connect that to your AWS accounts. From when we start talking about the tact and response, we will like to move to this.
We want to do automation as much as we can. So in this specific case, we got an EC2 instance as compromised. And because I have VPC flow logs enable and I have a AWS CloudTrail and I have my Amazon GuardDuty detecting that something is wrong, I can create, an automation process with, Amazon Bridge to indicate a Lambda function, that something needs to be there.
And go ahead and change the security group for instance, in this case. So I can isolate that EC2 instance. So this is just an example of how can you start doing that automation. One more thing. This is something that I think I found very useful is that you can install mirroring and you have VPC mirroring where you kind of star, capturing those log.
