Session Information:

It Ain't Done 'Til It's Automated: Security at the Speed of DevOps

Companies are rapidly migrating applications and workloads to the cloud. For many this is a Software as a Service for a first option, with migration to public cloud second, and only if necessary will workloads be deployed inside of the legacy data center. This is further complicated by the desire to accelerate the development lifecycle allowing devops to drive the IT migration. InfoSec is playing catchup to the business and devops constant acceleration.

In this session, you will learn strategies and best practices for allowing SecOps to keep up with the Speed of DevOps, as well as fundamental security knowledge applicable for any workload migration to any cloud provider.

Session Transcript:

Hi. Good morning, Good evening, Good afternoon. Thanks for joining me. My name is Greg Pepper, and I'm a security architect here at Checkpoints.

Across the 15 plus, I've been here at Checkpoint in 20 years that I've been in the IT industry.

This transformation into cloud and this desire to move faster, it's something that has really revolutionized all of IT, rocked InfoSec world.

And our friends, within the DevOps world, which are driving our cars faster than ever, are pushing our organization to the brain.

However, I would state that security has just as much ability and shared responsibility to keep up with DevOps.

Allowing SEC ops to move at the speed of DevOps.

And that's part of what we're going to talk about here today, is how can we help your organization migrate the cloud securely.

Along the way, there are many changes that are happening within the organization.

Virtual machines are lifting and moving into public cloud.

applications, we're trying to see built on premise, or being rebuilt in entirely new ways, Cloud Native Ways even. We're no longer the traditional confines of a web tier an app to your database running on different physical and virtual machines, the common construct for deployment.

These cloud native workloads may be entirely server less.

We're now they're using platform as a service and function as a service, and the database as a service no longer own the responsibility of the virtual machines.

However, you still owns the responsibility for security, right?

And when we look at that shared responsibility, a little bit later on, irrespective of software as a service, platform, as a service function, as a service, infrastructure, as a service, your private cloud as a service.

All of them require the same level of security, but how do you secure those cloud native workloads?

It's different when you no longer own the network, security controls, and the infrastructure, right?

We have to have a new approach for providing commun capabilities to monitor for access identity, threat mitigation, data usage, logging and monitoring, et cetera.

What we're gonna do is share some of these best practices that checkpoint learn 25 years plus we've been business as a leader in the space.

But in the last 5 to 10 in particular, on how do we enable security, to keep up with DevOps?

How do we enable security to be an enabler to this migration in the cloud, and allow SEC ops to keep up with DevOps?

Now, as we move into the public cloud, cloud means many things to many people.

For some of us, we've made substantial investments in our traditional data centers to bring that more software defined experience.

And whether that's investments in SDN technologies like v.m-ware NSX, or Cisco ACI, are bringing new Technics Flow or some other OpenStack neutron based solution into our physical environments.

But we're still not having a full cloud experience with integrated automation and orchestration, right?

We've been provisioning additional tools from commercial or open source or other vendors to help us automate and orchestrate the traditional networking and security and computing and storage configurations.

Now, as we move into this middle column into.

Hi. Good morning, Good evening. Good afternoon. Thanks for joining me.

My name is Greg Pepper and I'm a security architect here at Checkpoints Technology.

Across the 15, plus, I've been here, checkpoint in 20 years that I've been in the IT industry.

This transformation into cloud and this desire to move faster is something that has really revolutionized all of IT, rocked InfoSec's world.

And our friends, within the DevOps world, which are driving our cars faster than ever, are pushing our organization to the brain.

However, I would state that security has just as much ability and shared responsibility to keep up with DevOps.

Allowing SEC ops to move at the speed of DevOps.

And that's part of what we're going to talk about here today, is, how can we help your organization migrate to the cloud securely?

Along the way, there are many changes that are happening within the organization.

Virtual machines are lifting and moving into public cloud.

applications.

we're trying to see built on premise, or being rebuilt in entirely new ways, Cloud Native Ways even. We're no longer the traditional confines of a web tier an app to your database running on different physical and virtual machines, the common construct for deployment.

These cloud native workloads may be entirely server less.

We're now they're using platform as a service and function, as a service, and a database as a service.

You no longer own the responsibility of the virtual machines.

However, you still owns the responsibility for security, right?

And when we look at that shared responsibility, a little bit later on, irrespective of software as a service, platform, as a service function, as a service, infrastructure, as a service, your private cloud as a service.

All of them require the same load security, But how do you secure those cloud native workloads?

It's different, no longer own, the network, security controls, and the infrastructure, right?

We have to have a new approach for providing commun capabilities to monitor for access identity, threat mitigation, data usage, logging and monitoring, et cetera.

What we're going to do is share some of these best practices, that checkpoint is learn 25 years plus we've been business as a leader in the space.

What are the last 5 to 10 in particular, and how do we enable security to keep up with DevOps?

How do we enable security to be an enabler to this migration in the cloud, and allow SEC ops to keep up with DevOps?

Now, as we move into the public cloud, cloud means many things to many people.

For some of us, we've made substantial investments in our traditional data centers to bring that more software defined experience.

Whether that's investments in SDN technologies like v.m-ware NSX, or Cisco ACI, or bringing new tenants flow or some other OpenStack neutron based solution into our physical environments.

But we're still not having a full cloud experience with integrated automation and orchestration, Right?

We've been provisioning additional tools from commercial or open source or other vendors to help us automate and orchestrate the traditional networking and security and computing and storage configurations.

As we move into this middle column, into our public cloud, our infrastructure as a service, well, Microsoft, Google, Amazon, Oracle, Ali Cloud, and others have built a single unified portal.

A single set of APIs, a common control plane for the entirety of that virtualized data center.

So, what was previously isolated?

Separated at both, layer 1 through 7, and 8, 9, and 10, within our physical data centers, has now been broken apart into a single combined cloud platform.

And this creates unique challenges, especially around shared responsibility, because the users that I'm getting access rights within the cloud often have access rights to everything.

As we'll see here a little bit later on, it's the identity and access management of some of these services that becomes as critical or more critical, then the traditional network permanent firewall.

And we know we've been the firewall guys for 25 years. This is our wheelhouse.

The funny thing is, is that more and more of our customers are realizing that, hey, why do I have to be in the business of managing the application anyway?

Can't we just ship this off to a software as a solution?

Whether it's our Office 365: are Salesforce or Dropbox At Workday, or ServiceNow, or G Suite, or maybe even the security technology itself, is it as a service?

I've got the firewall as a service, my secure Access Services edge.

Maybe you're using your Sim as a service, as an example, or your firewall manager as a service.

The key, though, is that all of these different software defined workloads, whether they're sasse, I, as has faz, public Cloud private Cloud, we have the shared responsibility to protect them.

Now, I'm going to talk and tell a very simple story about how all of our data centers started very simple, and it become very complicated.

Now, when we think back to the three little pigs, one of the simplest stories of all right, we built these data centers, we built our straw, we built our word, we built our hardened environments, are bricks, maybe this was our development and our staging and our production environments.

And in the beginning, we had one common set of development, staging, QA, and production workloads to protect.

And we had these huge quarterly releases. And then we had months repairs.

The business, Was ready to roll out the latest iteration of our website, our ERP, our medical record system, our student information systems.

Whatever those critical business workloads that you've managed using your physical data centers, you built them, you cared for them, and you wanted to protect each and every one of them.

But let's be honest, the level of strength and security that you've invested in production was not often the same that made it into stage, and often is ever built into. The development environments development vines are quick.

They're weaker, they're easy to stand up and easier to tear down, and they're very easily blown over when the big bad wolf car.

Now, what started as a very simple architecture with free environments for our businesses to manage and maintain as multiply, be lifted, and shifted and move them into the cloud.

We're deploying them faster than ever.

Maybe now we've taken that one data center that we had, and we've multiplied it into cloud provider times multiple geographic regions, or maybe via design for business continuity and disaster recovery.

I took that application that was previously my one data center only.

And I'm now deploying it in Amazon and Azure and Rackspace, and Google and IBM to distribute my rescue, my work load, and my billing, right?

And what used to be months, and quarters in pairs, now weeks to prepare because they're now starting to automate and orchestrate these workloads faster than ever, Then the developers and DevOps said, we can do this even faster.

We can do weekly builds.

The bad guys now are coming in days, hours, weeks, minutes. We're deploying new workloads at a rapid rate, which is a good thing.

But are these houses being built according to code, and compliance, and best practice, and they are going, Will they withstand the big bad wolf when a big bad wolf comes and blows that house down.

Now, the crazy thing is, is that when we look one step further round the corner, we're now building these application workloads in an entirely serverless way.

We're using these cloud native capabilities, Right? We're using Lambda functions, we're using their content delivery network, Their DNS services, their load balancing service, their database service, the storage as a service.

The Artificial Intelligence is a service, and on, and on and on, and these bills, which were happening daily, are happening every minute. They're continuously happening.

The automation and orchestration of our CI CD pipeline is taking you always very formerly is simple development, staging, and production environment, and multiplying this at an exponential proportion.

Now, as the information security practitioner, responsible for keeping a business out of the news for the wrong reasons and up and running for the right reasons, this is the challenge that we face: is even if you're 5 or 10 people in a garage, you might have hundreds or thousands of functions in the Cloud.

Or if you're a large bank or healthcare or government organization.

You are consuming all of this at a pace faster than ever.

Are you determining, do I still need to run this workload at my data center?

If not, can I move it to Cloud or better Yet, Can I consume it as a software as a service first and decommission the legacy workloads.

Now, depending upon your organization, the technology and the layers, 8, 9, and 10, that being the people, the politics and the money, will help you determine, wasn't all your workloads are going to live in your physical data centers.

Whether or not you're going to lift and shift those workloads and move them into the public cloud.

Or, am I going to just the comment and migrate to a software as a service altogether?

Now, add to this, the recent changes to our technology business, global health care climate.

We used to be a majority of our employees might come to a headquarters location or branch office, and maybe a portion of the organization was virtual or work at home.

Well, now, a majority of our users are remote, worked from home, and that may be the new norm for a much longer period of time.

The amount of users which were previously in the headquarters directly connected to the data center, it's much less than it ever has.

And those branch offices, which previously connected through expensive NPLS lines or complicated VPNs.

Well, they're just going out the Internet to talk to my software as a service.

And all my applications are running in the Cloud.

Well, maybe I need a software defined wide area network to help manage connectivity to the Branch Office in the Cloud and the data center.

That's an entirely new set of software defined technologies that our customers are evaluating, and consuming, and deploying.

But regardless of where we are, alongs evolution and migration, that shared responsibility for security always exists.

Now, as we can imagine, in the beginning, when we had bare metal and we owned all of our assets, we had all of the control into our data centers, we determine who can physically access them. We manage the software that went on it at the bios in the operating system and the application.

Then we started to virtualize these things and we've had massively large scale number, viana sprawl, right?

And then we've realized, wow, we can use this mainframe like technology around containers and rather than having to have a dedicated virtual machine that's gigabytes in size, I can run containers, that's megabytes in size.

Right now, we went from having a couple of pods of dedicated standalone containers to having multiple pods that are automated and orchestrated, And we continue to move faster as we move along the horizontal axis.

But, as we move more and more into the public cloud, as you move more and more to someone else's computer, has someone likes to refer to it as, we lose some of the control.

Now, losing control is not always a bad thing, because we lose some responsibility.

However, we're responsible for our data, and our information, and our identity across the board.

When you combine a lot of the shared responsibility models, this is want to happen to pull out of ... Security Magazine here.

But the key thing to understand is, you have a shared responsibility across every member of the X and Y axis on this.

And even where we have those blue dots, where the cloud provider is responsible for the physical or the host infrastructure control, right?

You still have a dual shared responsibility in every one of these scenarios, one, you have the shared responsibility to use all of the built-in security from those providers.

If I'm using fast pass, I, as my on premise, all of the vendors have security options.

There's dozens, hundreds, thousands, of security settings that you have responsibility for.

Did we turn them on?

Are they managed according to best practice?

Are they meeting governance and compliance?

But equally, you have this shared responsibility to bring security with you.

Now we're one of many vendors that offer security solutions for several full and serverless for cloud access security brokers, network virtual appliances, and cloud marketplaces, traditional network security and endpoint security, serverless and secured Access services Edge.

Right? These are many categories in which we are one of many vendors out there, but you, as the end user, have the shared responsibility.

You won't have to turn on all of the built-in controls.

Use them. There are good There, are minimum.

Your best practice.

However, you have the shared responsibility to bring security with you.

You have the opportunity to choose a vendor like checkpoint or one of our competitors, or an open source solution as an example, to augment the built-in controls.

to enhance the security at the Lambda function, to enhance the security at The Virtual Network edge, to enhance the security within the hypervisor, and definitely within our traditional on premise.

Now, as we've seen, our modern application workload has been turned on its head.

What we used to do in the past with a traditional router, firewall, load balancer, web tier middleware, database server, with v-lans and routing and switching and service and storage omi.

We're now building a cloud native ways.

We're using containers services for the automation and orchestration deployment of those container pods.

We're just owning the code and no longer the Apache infrastructure and the app intelligence plugged into it.

We're using cloud, native software, defined capabilities for DNS and load balancing.

Then we're consuming our database and our storage as a service.

And we're paying per transaction. We're paying pennies and micro pennies per function.

But shavings may compile.

And collectively, just because we've built it in a cloud native way, doesn't mean is one secured out of the box. Again, we're going to turn on the security. We're going to add to it the additive security later.

Now, when you think about the challenges of the security model for maintaining posture, visibility inside the workload, some type of controls, an audit around the network, and then collecting the logs and the analytics along the way.

Well, the same challenges exist in IaaS PaaS.

Faz says, my legacy environment as well, right? How do we gain that level of visibility?

A firewall is one of many tools.

It is not the only tool, right?

And now that we've built these things in a cloud native way, or even in a nice way, there is no one perimeter.

We could spin up Internet gateways on demand, build an entirely new v-net in VPC, with a pointing click of a few seconds.

And before you know it, whether it's through Ms.

Configuration, Sloppiness, re-use of overly permissive settings as an example.

Very quickly, our workloads can get replicated at massively large scale, whether we want it or not, and whether we know it or not.

There on top of that, there were now using a whole bunch of new software, some of it's commercially delivered, some of it's open source, Right.

And as we've seen here, if I'm pulling in a module into my code, or my container, that has a known vulnerability, or has embedded access keys, or default credentials.

And I'm deploying them in these ways, without locking down the code and the configuration, we're increasing our attack surface, right? And we can sit here and say, oh, it was my Cloud responsible.

It was my cloud provider sponsor ability, was my software as a service responsibility, because, if and when the breach happens in their root cause analysis, right, in our incident response does a lot of cleanup with our customers, helping them to understand what went wrong, how can we have detected it faster, how can we respond faster? What do we do to prevent it down the road?

And how we've been prepared when it happens again, mitigate, and remediate the situation, right? And there's no one product, or process, or person that's going to come in and address every one of these town.

But there are things we can think about and do to help us address some of the security challenges as we move into cloud.

So, let's think about this security model, and how do we want to turn it on his head.

What does the same token do, exactly what we've done for the last 25 plus years?

When we think about the fundamentals, of having continuous security, it has visibility that has preventive capabilities that offers governance and can work across workloads. Well, this is what we're all trying to achieve.

We're checkpoint and trying to achieve this. We've been building many of our newest applications, not in our traditional way where we package inside some software, and you deploy it on premise, but as our own software as a service.

So for us as a SaaS provider, deliverer of security solutions, security is the utmost importance and for us learning how to maintain visibility cloud native.

Learning how to have mitigation and threat prevention capabilities, Maintaining governance and compliance is just as important as it is for us, as it is for you.

So what are some of the security considerations?

Well, in some way, they're exactly the same as what it was before.

Right? When we think about that firewall.

While we used to have it checkpoints, or Cisco or Juniper firewall at the age or whatever other competitors, we deploy these cloud native workloads.

Well, they're sitting behind your network perimeter.

They're out there in the Internet with some basic access control lists, and the configuration management for this now is only an API click away.

They're constantly being deployed and redeployed and changing IPs and fully qualified domain names.

Are you going to change a firewall every single time that DevOps is deploying new code level infrastructure?

Probably not. You spend a lot of time making firewall changes. And, as the firewall guys, we know, nobody wants to make firewall change.

Now, when we think about the code itself, the infrastructure, the code, is covering so many elements of the deployments.

It's got the vignette in the VPC. It's rolling out the virtual machines. It's bootstrapping the configurations of the firewalls.

It's potentially living in its own software repository, where it's being checked in and checked out and is continuously being automated and orchestrated for deployment on demand.

Now, when we think about visibility, right? In the old days, we had an audit trail on our compute. In our hypervisor, our network, our security is very easy to go find the information we're looking for easier, not very easy.

Today, in Cloud, everything is now being consolidated into a single control.

When we think about things like the combination of VPC Flow Logs and Cloud Trail Events are the audit trail within Azure when their network security logs, right? We're stitching together a multitude of information about network activity, application activity, administrative activity.

We have more information than ever.

And identifying what's important and what's noise is become a bigger challenge than ever.

More compute, more servers, more server less, more logs, more audits, alright? There's more things for us to constantly monitor.

And this acceleration to DevOps is micro builds.

It's great, but also now is creating this additional layer of monitoring. There's more code to check and is more bills to analyze.

There's more tests to run more automation and incident response.

They now have more technologies than ever that I'm trying to weave into this intricate platform.

As we mentioned, a lot of these control planes are moving into the cloud.

The identity and access management roles within the cloud are more critical than ever.

In our traditional physical world, it has separation of technologies.

So the people that were the v.m-ware administrators didn't log into the routers and switches, maybe that people logged into the firewalls, They didn't necessarily have full access into routing and switching, Right. And potentially, the load balancers maybe managed by a different team and the SSL certificates, and the web server configuration, and on, and on, and on.

We had an actual separation of duties in the cloud.

All of those duties combined into a common set of APIs, a common framework, and through identity and access management, we create the role based access controls, But understanding the least privilege model.

In an identity world, it's a lot harder than it used to be.

All right. There's thousands of identity and access management roles in the cloud. Do you know which ones are needed by net ops, SEC ops, DevOps, cloud, into teams?

Many of our customers don't.

What we've seen time and time again is that a combination of overly permissive access roles, weak security credentials, or stolen harvested credentials, or access keys, that were maybe uploaded automatically in a pipeline but weren't secured and protected, allows people to gain access to your environments, allows them to use your automation and your orchestration against you.

I'll show you a quick story.

We're one of our customers, inadvertently through their CI CD pipeline, uploaded some access keys into Git Hub.

And these access keys had rowed level permission across the entire human subscription.

Well, Pakistan listen information and use it for their benefit.

They didn't take down the applications, quite the opposite.

They use their environment for their own personal gain.

They deploy their own bitcoin miners, as an autoscale group within the customer subscriptions, and ultimately, ITT didn't know what was going on.

They really weren't watching.

They didn't have least privilege identified. And the fact that this autoscale group that was deployed continuously growing for the next 30 days, it really didn't catch anyone's eye.

But, you know who caught it?

The accountants, the finance teams.

The Amazon bill showed up next month with an extra zero on the end.

Because the bad guys were doing Bitcoin mining in the customer subscriptions, because they had very weak identity and access management and access keys and automation and orchestration around security identification.

And they were not implementing at least privileged solution.

Now, as I mentioned in the beginning, there is not a single product, a single process or even a single person who's going to be able to come in and magically deliver an ultimate security solution.

All right.

We are one of many vendors who have security solutions that integrate well with others.

And we do some things well and we do some things not well.

There are things entering, checkpoints, wheelhouse and other things that are not going to be in our wheelhouse.

But the key for you is to choose technology partners that play nicely together.

It's the interoperability between a vendor that makes you best of breed.

It's not about buying a single holistic security solution from one vendor that says, I've got everything you need by my Enterprise agreement and you're going to be securing your everything.

Right. However, understanding, what are the right technology products, or the people, and what are the processes to integrate them, and allow you not to just think about a single workload, a single project, a single problem, and a single product.

But a holistic solution might cover multiple workloads in multiple platforms.

Alright, so does that vendor work in Amazon and Azure Google?

Right, doesn't have both server falling serverless support.

Can I have firewall only, or can I add additional capabilities on top of it?

Now, traditionally, when I have a question, I go to Google for the answer.

And when Google doesn't, give me the answer in the first few clicks, especially with an IT question.

Well, I gotta Gardiner, we look at what Gardner has to say about the fundamental solution building blocks, right, this is a model that they've shared with customers for years.

Now, this model about minimum, foundational security that every one of us need to our core workload protection to our workload protection, as we move up the stack, it is less critical to deploy those technologies, but it is relevant to the security of the workload.

So if I was in Department of Defense, if I was the IRS, Well, my workloads are a lot more critical.

If I am Local K through 12 school district, that doesn't mean my workflows are not critical.

But the amount of time, effort and money I might invest to secure. My nations taxing, critical, cyber defense systems might be less than my local student information systems.

Now, working from bottom up, as we moved into cloud, a lot of the things in the basic hardening and configuration and vulnerability management may or may not be handled by your cloud provider.

As we talked in the beginning as it relates to the shared responsibility model.

How much ownership and responsibility for each of these is gonna vary based upon whether you're using software as a service, platform as a service, infrastructure as a service, or if you've built it yourself?

Now, when we work up from bottom, let's be Honest, Sark clouds have some basic network firewalls.

They have access control lists. They have some logging, they can do some segmentation.

But the key here is in each one of these cloud providers, they provide the basic integration.

And every step along the way you can bring a vender with you.

You have that option to share the responsibility and where are the places that I want to augment.

I'm sorry, augment and enhance the cloud native capabilities.

with a third party strength.

Now let's start from the bonus period and work your way up.

When you think about the posture management, as you lift and shift and move a workload, whether it's server fault or serverless, configured according to best practice, regulatory compliance, and other benchmarks that I follow.

So this might be of my eyes. This can be of my serverless functions.

This could be a, my containers, whether I'm using them as a service or building containers in my own traditional environments, or maybe even have that pasture management to look at the containers as they're being built and packaged and deployed as well.

Now, in that second layer, is around the network security itself.

And, it's one of my colleagues, like to say, Greg, there is no cloud, there's only someone else's computer.

And, even though we're using server less, it's still software on hardware, talking through network to users and devices.

And there's network security along the way.

It could just be basic access controllers.

You might choose to deploy various services endpoints to route traffic for v-net into VPC, putting a third party network virtual appliance to have traditional network security with IDS and IPS and Proxy and Data Loss Prevention.

Again, different workloads require different level of protections.

That's up for you to decide not for us to decide.

In the third layer of this model, we talked about workload and runtime protection.

So, this might be adding, additionally, security in the operating system, Embedding it within the web server, itself, acting as an ingress or egress proxy at the container layer.

And this may also now start to involve API level of integration.

Whether we're implementing our own schema validation, we've got web application firewalls to have dynamic learning.

There are many different technologies along the way that we've implemented in the past, present, and future, to specifically, look within the, the web tiers and the application tiers in the database tiers.

And now, we're adding them as a container layer, as well.

Along the way, every one of these technologies are generating logs and audits, and forensics that we're now stitching together to help identify attacks in real-time.

Allowing us tech to what has happened and enable a response, whether that's a manual response, whether that's an automated response, We have to generate the information, create a digital breadcrumbs. So we can have the forensic analysis. And hopefully now we're using more technology, and machine learning, and artificial intelligence. And you're not just sending analysts to comb through endless amounts of logs and alerts.

Right.

We need the technology power to provide this threat detection using the ....

Intelligence are the systems behind us, and use the power of automation and orchestration to help increase the efficacy, and the timeliness of our threat detection and, ultimately, response.

Then, lastly, And I hear this from people all the time, Well, I'm running serverless.

No, I'm here, right? You know, malware is not going to take over my application.

Applications are vulnerable to the traditional attacks, and that's true, but there's new attacks.

There's new ways in which bad actors out there are using the cloud against you.

For reconnaissance, Discovery, brute force attacking, and ultimately embedding themselves in your code, and embedding themselves in your pipeline, and using the power to go fast as a vehicle for them to go fast, as well.

Now, I'm going to take one moment here as you can around into the last 15 minutes of our session today, and really focus in a combination of the pasture management and the network security.

It's the most foundational for all of us and it's relevant in every one of our environments.

Now, if we think about the beginning, right? We had router, we had firewall, we had load balancers, and it doesn't matter if was checkpoint or Cisco is F five or if it's Citrix, right? Or whether you're running Windows or Linux as an example or Oracle or SQL Server, my-s.q.l..

The point being is, we had this traditional architecture in the physical world, and it started to migrate to cloud, and even those things looked a little bit the same, they're actually starting to be a lot different.

And as I like to joke, though, it's 90% the same, things are 10% different, and if you and me, and we don't understand that 10%, we're 100% stirrup, because when we move it into Amazon or Azure, or Google, and we're now starting to use cloud load balancers, cloud firewalls, cloud native routing, and VPN and autoscaling, and DNS in virtualization, as an example.

Well, our customers and our employees are taking advantage, this ability to do this on demand much faster.

Right? I'm talking to some large banks in America that have hundreds of subscriptions and minutes and VPCs.

Right now, the customer is born in the Cloud, where they have 40 different environments.

Are all automated and orchestrated deployed, tested, and then deleted and redeployed dozens of times a day?

And finding the people who know how to use these platforms and know how to use the technologies that know how to seek API first, automate first and not point and click isn't razors. And we're sitting on today.

Because what we've seen is not us reporting this Gartner and many other people out there, that most of the breaches that have happened in recent years and this is not exclusive to cloud, but highlighted in cloud, are often due to miss configurations.

A poorly configured firewall makes a great router.

A poorly configured IAM role makes a great security breach. And even those things look the same.

They're different.

All right, and now that we're handing the elements of configuration management for cloud native, built into the API, built into the cloud provider.

Do we really want the developers owning all of the elements of the security?

Developers in DevOps have a shared responsibility along with SEC ops to build.

Whenever the workload is, whether we're building it in our own private cloud on a v.m-ware or KVM or hyper V base hypervisor, and we're implementing virtual firewalls embedded in that hypervisor.

Right now v.m-ware NSX, Nutanix Flows and there are many other vendors that have software defined solutions in the hypervisor.

But it allows you to selectively steer a north-south flow into a software defined gateway.

And no longer have to route it through that one big firewall, or the one legacy load balancer, as an example.

And these software based solutions can not just send into one instance, but they can scale it across multiple instances, and they can replicate it on demand with automation or orchestration.

Giving you a development environment, staging, production, that have never heard of one another, but have the necessary security controls, and are dynamically mapped to each and every one of those phases.

Now, as we can imagine, and we've seen, going, we own all the infrastructure, the compute, the storage, the network, the hypervisor, the software defined this, the routers, the switches, right, So a lot of moving parts and pieces, right, it has his own costs and complications, as well.

Yeah, these software defined networks have evolved over time.

They become much better at utilizing the software defined network to automate and orchestrate the deployment segmentations, and not just bridge within the hypervisor, a crossover to the physical as well.

Not that Cisco ACI, and NSX T are the only solutions in this space.

But at some point, the software in the hypervisor talks to a network, right?

The overlay in the underlay have to come together, right? And this is in your data center, or this isn't Amazon's data center.

They're not just using commercial products, like HCI and Intersex to do so.

But, they're creating a variety of different subnets within logical networks, that are isolated from one another, and can be automated and orchestrated deployed on domain.

And in these environments, you have a little bit more control, and how we blend hardware and software together.

The key here is, is that, using this software defined data center, we enable a north-south flow. We enable an east to West Flow.

We determined from his own Ex, his own, why I want firewall load bouncer, wef, SSL inspection, proxies, DLP, threat mitigation, and on and on and on.

Now, this environment, which has traditionally been very physical, right, my v.m-ware server is my Cisco UCS, my HP, my down my IBM as we lift and shift and move these things into the public marketplace.

As I mentioned, you have the option and bring venders along with you, this could be checkpoint in the marketplace. This can be one of our competitors in the marketplace.

And this is not limited to firewall only, but for waste and load balancers and other technologies, as well.

And, you can work in conjunction with the software defined data center to deploy these highly available, highly elastic, automated, and orchestrated wings.

Writing, create these swim lanes that allow you to have inspection, layer 4 through 7 inspection that complements augments and enhances the cloud native in addition to the capabilities that are built into the cloud itself. Now, this is a diagram from one of our blueprints in our best practices of how we create a front end zone to north-south activity.

We create a back end zone, to West Security, And that can be deployed, not just in Azure, as I'm showing you this environment, but the same blueprint: we can apply within X W S, employed in Google, Oracle, ali cloud, and others, API integrations are different. The best practices of the same.

Now, as we've seen, and we talked about it earlier, on, we're no longer just building these applications in traditional ways, glyph virtual machines Legacy Separation of Web Tiers, Application Tiers, and Database. These things are running now entirely serverless functions.

And within our containers, it's allowing us to now use less compute resources and deploy in a much faster rate.

Additional layers of automation and orchestration and elasticity and potentially deploy it as a service.

Deploy it in your own Kubernetes environment, whether it's in your v-net, some VPCs or you deploy your niche traditional on premise, right?

Because containers are not technology that are exclusive to public cloud, containers as a service or a function of public cloud.

But regardless of which one of these design methodologies that you're choosing, every one of them has the ability to be fully automated in our stream. And every one of these environments, we're all trying to move faster.

But how do we enable you to move faster?

Because it's not about moving fast or staying secure. Those days are behind us. We must move faster, And we must stay more secure. As we mentioned, there is no one product or process, that will take care of all of those functions.

What the recipe for automation, or orchestration really revolves around three key pillars.

First and foremost, we must continuously monitor our assets.

It sounds simple, but we have to be watching what's going on because the moment we take our eyes off of it, the dogs are barking, like, we heard up above, and I apologize for the noise there.

The second key thing for an automated security solution is something that builds in automated remediation.

It allows you not to just monitor and detect an alert, what's going on, but fix things, and it automated and orchestrated away, and not just shift them in production, once they've been deployed in. My vulnerability Assessments have detected the issues.

But, how do we enable security along DevOps to shift left, and allow us to now plug into that pipeline, and identify the risks and the vulnerabilities prior to the deployments.

So, if you think about a traditional CI CD pipeline, and I don't care which tool you're using for, whether Jenkins or otherwise, people are checking in code.

Right, it could come from a visual basic application, it could come from my Visual Studio, But when I check it into that repository, that automation or orchestration engine is starting to do a bunch of stuff.

It's building the apps.

Running a series of tests is do sing it into staging, is running more tests where we've got to go live or move into production.

But along the way, if we're moving forth legacy security artifacts, well, it's great that DevOps got to build and it passed the regression tests, and we went live in five minutes.

But it's good, if we went out there with shared access keys, access keys that we knew were compromised, if we're deploying what they're getting, access roles that don't aligned to best practices privilege were using libraries that have known reville vulnerabilities because the infrastructure's code that's plugging into this, right, is coming from many different places.

Right, we're using the native Azure arm templates or cloud formation template.

So we're building those YAML scripts to roll this infrastructure out, or maybe we're using Git Hub as a code repo.

And we're building our artifacts, using Ansible. Terraform as an example.

And these are not the only vendors that are out there, but rather than waiting until the artifacts have been deployed in the public cloud, rather than waiting till we have their virtual machines live with a public IP address. And it has been attached to the internet gateway. And now the whole world can see that port 4, 4, 3. I'm running a legacy version of Apache and SSL.

It has vulnerabilities that has known compromises, and oh, by the way, as a joke, the poorly configured firewall makes a great router. We've opened up that security group to the world.

So when we plug into the CI CD pipeline with a security mentality, well, what are we trying to look for?

First and foremost, we want to look inside that infrastructure as code because it contains so many bits of information about the configuration of the virtual machines, the route tables, the load balancers, networks as an example, and it might live in a cloud formation template or arm template.

It might live in YAML.

It's really just jaison, right? We're parsing the JSON and we're looking for pieces of information that are embedded in it.

Right? We're also looking within the code as may be put into that Lambda function, as an example.

We're looking inside the identity and Access Management roles that are needed, so not only deploy the application, but for the application to run.

Does this Lambda function need a full IAM role for S three across all operations and all services?

Does this Lambda function need full access to RDS to query all table spaces?

wherein we think about those access keys, the access keys that we use to access the tools, the access keys that are shared for the application layer to communicate with one another.

The access keys that we're using for SSH or RDP access into the virtual machines.

Am I using the same ones in my development and staging and ax production?

Are they the same access keys I left in my Dropbox and OneDrive accidentally?

Or how about some of the default credentials that are embedded in these applications?

Right, I've deployed this WordPress or post, graphs or my-s.q.l., or do they have an admin interface is turned on by default.

Because they have weak credentials by default.

I just run a database, It has my-s.q.l., my-s.q.l. as a username, password.

And lastly, am I using applications impact containers that have known vulnerable libraries?

Because when we look at these new artifacts, right, it's no longer about scanning an operating system application.

Well, maybe I need to scan the container or I need to scan the serverless function.

And we shared a lot of information along the way.

I hope you took a little bit from this, and that one SEC ops can keep up with DevOps, right?

We have the know-how, we have the capabilities, we have the tools and technology, don't exist to speed to go, don't resist.

Understand, and we have to be sure. Thank you Elliot Slow and steady wins the race, but we have to enable ourselves to go fast and go securely, so don't give up and go home.

I'm just saying that security can shift left along with you, that you can automate and orchestrate the deployment of security, the configuration of security, and have you security shift left as part of the process.

Thanks, for joining us today.

I hope you learned a little bit from our lesson today, and for those of you want to find me online, you can follow me at pepper underscore Greg on Twitter or reach out to me directly via old-school snail mail e-mail, ... pepper at checkpoint dot com.

Thanks for your time, and make it a great day.