Hi everyone. Thank you for joining me today for this live demonstration of
Guardicore Centra. I'm Garrett Weber the director of
solutions engineering and I'll show you how you can use Guardicore Centra to
accomplish your segmentation and access control needs across your entire IT
environment. Now, before I jump into the user interface first I'd like to take a
few minutes and provide a short overview of what Guardicore Centra is and how it
works. First, Guardicore Centra is a solution for implementing consistent
security policy across your entire environment whether you're looking to
implement its zone based or micro-segmentation or control user and
third-party access to your data center resources Guardicore Centra provides you
with the flexibility to implement these controls using a single solution.
The Guardicore approach is to provide a centralized console that lets you manage
security policy for the entire IT environment. Centra starts by helping
you visualize and understand the traffic flows from each system in the
environment providing you with granular visibility so you can not only
understand which systems are communicating with each other
but also which applications are being used to communicate. Next, Centra guides
you in implementing the right security policies for your needs using the
visibility data we've gathered to assist in making informed decisions about which
traffic should be allowed or blocked. That security policy is centrally
managed in a single policy set and requires no network changes or downtime
to be enforced. There is no changing of IPs on systems or rerouting traffic to
begin enforcing the security policy. Guardicore can take your network as it
is today and start implementing security policy without any of the complex
changes that you would typically encounter in a segmentation project. This
approach works just as well for your greenfield environments as it does for
your brownfield environments so whether you need a solution to implement in your
on-premises data center or your DevOps pipeline within your cloud provider of
choice or both Guardicore Centra's approach will provide flexibility and
consistency across your whole environment. Now, how do we do this?
Instead of using legacy models of creating choke points in the
environment we take a software-based approach we distribute an agent across
the workloads in your environment. That agent performs a collection of
communication flows to and from the workloads and is also the enforcement
point for applying these security policies that are centrally managed in
Centra. The agent runs on both legacy and modern Windows, Linux and Unix systems
going as far back as Windows XP 2000 2003 or Rel 4 and 5 in supporting all the
most recent versions of the common operating systems that organizations run
today. The agent is even supported in containerized environments to provide
protections for your workloads and applications deployed in these
environments. Centra also includes many out-of-the-box integrations with
orchestration CMDB and seam solutions to help simplify the implementation and
long-term maintenance of your project. Okay, now that we're all on the same page
let's take a look at what Centra can do.
Alright, welcome to the Guardicore Centra user interface. The solution starts
with visibility and providing you visual maps of how systems environments and
applications communicate with each other. As applications get as the agent gets
deployed within your environment we start to collect the flow data to and
from the workloads they're deployed on. This spider web begins to organically
create itself so we can start to understand how different systems are
communicating with each other as well as with the rest of the environment.
Let's look at this server here. We can easily start to understand that this system is
receiving inbound communication from a couple web servers over port 27,017 and
it's also communicating with a domain controller for DNS so what we're doing
here is starting to map out which systems are dependent on the server and
which systems the server is dependant on. Now, this view needs to be organized in
order for us to really start to make sense
of it and understand not just how the individual systems communicate by how
the applications in the environments communicate. To organize if this view we
apply to labels. Labels are metadata applied to the system that logically
groups it with other assets in the environment so I can understand that
this system is part of the production environment it's also part of the CRM
application and it's a database server. Now, you may also want other labels to
identify things like the OS type it's an Ubuntu server running in my environment. It also
falls under the CCPA compliance regulation that aims to
monitor for this system as well. When we use labels we can adjust our visual to
give us this cleaner view that we started with. This is the same number of
servers same number of flows organized by the environment that they're a part
of. If I want to understand how systems in my production environment communicate
I can open it up and I can get a view of different production applications. I can
look at the CRM application and I can understand how it communicates with
other parts of the environment and help endpoints connect inbound or the
different DNS and Active Directory servers that it uses for authentication.
I can take a look into the CRM application and understand how the tiers
and the components of these applications communicate with each other and with the
rest of the environment. I can look directly at the database servers and
understand that when the web server connects in it connects separately to
each database server over port 27,017 and more
specifically I can understand that when it connects in it connects to the Mongo
database application. If I did not understand what this application was we
give you some information on the right - the application name, the path that's
running out of, the user that executed it is this a service account running this
application or a system account or an end user that's executed the application.
We also take this hash in compared to the Guardicore Reputation Analysis
Service. This service is a threat feed that is identifying known
malicious processes and communication within your environment so we can take
action and eliminate these applications and these malicious pieces of software
from running before we put policy in place that allows them to continue to
run within the environment. Now, two other notes on the maps. One is maps data is
stored historically so you can go back in time and understand how an
environment and application or an individual server are communicating. You
can do this for 30 days, 45 days, 60 days, 2 weeks, whatever timeframe suits your
needs to look at the application. So, let's take some examples here. Let's say
I'm planning for creating security policy and I want to understand over the
last two weeks how an application communicated. I can adjust my maps and my
views to understand how that application communicated over the last two weeks so
when I'm putting policy in place I can confidently account for historical
traffic flows that have occurred in the environment. Maps are also used by our
customers for things like forensic analysis. I find out that a server has
been compromise. I want to understand everything this server has spoken to in
my environment over the last 45 days so I can start to understand what is my
containment and incident response plan. Maps are also used for migrations.
As customers are migrating between data centers or from a data center to a cloud
provider we can start to map out for them the applications that are moving so
they can understand when they move the application from data center A to AWS or
Azure, they can account for all the necessary dependencies that that
application needs to do its job so when they move it from data center A to that
cloud provider they only have to move it once. The other point on maps is they can
be fully filtered and customized to meet your needs. So you can build customized
maps or filter maps within the view that you're currently looking at to say show
me traffic only over specific ports or maybe traffic only between specific
assets or only with certain applications and processes
involved or by the labels that we've created. It's common for our customers to
build labels around applications and give application owner views of the
environment that are just specific to the applications that they own so that
they can help with assisting in defining security policy for those applications
and give them a view and an understanding of how that application
communicates in order to do so. Now, let's start talking about policy. Most
segmentation providers only provide you with a whitelist approach to policy.
Guardicore provides you with both a whitelist and blacklist approach to
creating policy. So, first let's start with blacklist. Now, a blacklist approach
is defining a rule that says this type of traffic should not be allowed within
my environment and I can do that easily in Guardicore Centra by creating what we
call an override block rule and when I write this rule it can something as
simple as anything classified as a database server, connecting out to the
internet, over any port or protocol should be blocked. Now a few things about
this rule. This rule is applied globally across my environment. Everything
classified as a database server will receive this rule. There's no reason to
manage different rules and different tools in order to accomplish blocking
these database servers from connecting to the internet/ The other part of this
rules, rule is using labels allows us to easily read and understand rules in a
language that makes sense to us so I can easily look at this and understand that
database servers connecting to the internet over any port or protocol will
be blocked. This takes us away from managing security policy by IP addresses
or assets and starting to manage them by these logical groupings and really makes
our rule sets easier to understand, easier to implement and more flexible
for us. Other blacklist rules that we see customers implement are blocking FTP out
of the production environment or blocking telnet across the
entire environment for a compliance regulation or blocking pre-production
systems from communicating with production systems
so preventing development access to production systems in the environment.
Now, these blacklist rules are often leveraged by our customers because they
can globally apply a simple rule to mitigate a specific type of traffic from
occurring in the environment. Customers also use whitelist rules to complement
these blacklist rules and whitelist are more commonly geared towards your micro-
segmentation or zero trust approach to security. So, let's talk about whitelist.
The biggest challenge associated with whitelist is understanding which traffic
flows you should allow in order to block everything that shouldn't be allowed.
Realistically, if you're trying to do this with an application or an asset or
an part of your environment, you're going to get different pieces of
information from different groups within your organization. The application owners
will have some information, the infrastructure team will have some
information, the person who's been part of IT for 30 years will have their own
understanding of how the application communicates and you will try and piece
all this together maybe in the form of a spreadsheet and then translate it into
the appropriate rules in the environment. Most likely, you're gonna get 70% of the
information that you need. You're not going to have a full understanding of
that application to put the appropriate whitelist rule set in place. With Centra
we take the maps and the visuals that we make creating and the data we've been
collecting and we use that data to build whitelist rule sets that allow specific
traffic to occur, traffic that we know has occurred, traffic that we know will
continue to occur and then block everything else. To do this, let's say I'm
the administrator of the CMDB application - I want to prevent inbound
access to the CMDB application and restricted to only the necessary
types of connections that should connect inbound. I also want to control traffic
between the tiers of the CMDB application and control how that
application communicates internally as well. To do this, I can right click move
into edit policy. Now, all the rule sets I could have previously handwritten we're
going to right now but using the visual part of the product instead. So, if I
right-click and ask Guardicore for an app segmentation policy I can begin doing
what's called ring-fencing the application. Ring-fencing is a method of
controlling inbound access to the CMDB application. So when I click that we
created two rules as a baseline to get you started with creating the ring fence
around the application. From here, the job the administrator is to look at these
inbound connections and begin to determine if they should be allowed or
blocked. In my environment, users should use the jump boxes to connect into the
CMDB application so to allow this traffic I right-click and click "Add
allow rules". You'll notice we write the rule for you based on our translation of
the connection. The rules written to say that jump boxes can connect to the CMDB
application over port 80 TCP well only using wget on the source connecting to
nginx running out of user sbin in the CMDB application. Guardicore is the only
solution that will provide you with application level controls and process
level controls regardless of the operating system because the agent
functions as an independent host-based firewall running on the operating system
and gives you the granular ability to control traffic down to the application
in the process level. Okay, now we're creating a whitelist we need to decide
what to do with everything else. Perfect world - we get to block right away but the
reality is most of our customers sit in this alert mode to monitor and tune
policy over a period of time before they actually move to blocking.
So customers will sit in alert mode and receive incidents related to traffic
that violates the flow so you're gaining value out of the product based on
reviewing and triaging those incidents but then using those incidents to tune
your policy set. Maybe there's a flow you missed or we haven't seen before that
needs to be added to the whitelist. We can easily do that from the incident
data. Once we're comfortable that the whitelist is accurate we can move this
rule from alert to block and now publish the policy and begin enforcing traffic
within the environment. Now, let's say next we want to get into micro-
segmentation - so if we right-click and go to micro-segmentation and now we're
looking at the inner workings of the CMDB application you'll notice here
lines are back to being red between the tiers of the application. If I want to
allow this traffic which I should because it's how the application
communicates I right-click and I add the allowed rules. You'll notice the lines
changing from red to green. This is your impact assessment that you're starting
to understand how the policy we're putting in place will impact the flows
of to from and within the application. Now, again, we've written the rules for
you based on our analysis and understanding of the communication flows
over the period of time of your choosing. As we're putting the whitelist in place
we have the same workflow. Everything goes into alert first so we can monitor
and tune the policy and then once we're comfortable we move that from
alert to block and now our rule set can be enforced in a true zero trust, micro-
segmentation approach. Now, lastly, once our rules are in place we're going to
start to receive some incidents. So, when you look at an incident in Guardicore,
you can easily begin to understand which assets are involved. You get a map of the
incident so you can understand the traffic flows that are involved and some
details that summarize the incident for you so you can understand which systems
which policies are in place and what the actual verdict was related to the
traffic flows. So, what we're looking at here is accounting load balancer one
connecting to accounting web two and we see two processes making connection
across over port 8080. One is nginx - this is allowed by
our policy set. nginx is supposed to create this connection. The other is this
rogue attk process so from here what I can understand is the attk process
connecting to tomcat was blocked because of the policy that is in place. What is
significant here is these connections are both over port 8080 so from a layer
four standpoint they appear to be the same connection. Guardicore's ability to
understand the applications that are involved in a connection and control
traffic based on those applications lets you decide that it's okay for only nginx
to make the connection to tomcat on the web server but not for this other rogue
application that has been installed and is running. Other important information
here is timestamp so we can understand - When did this traffic occur? When did it
start? When did the session end? You can also tune policy easily from here so I
can choose to create allow rules off of the incident let's say this connection
should have been allowed I can easily create an allow rule to allow this
connection to occur. Lastly, these incidents can be sent to any ticketing
or SIEM solution of your choosing. Guardicore has various ways of getting
these incidents over to those solutions everything from syslog to email if you
use Slack or other integrations for connecting to those solutions Guardicore
can implement with those as well. Okay, that completes our demonstration of
Guardicore Centra. I'd like to thank you all for your time today.
If you have any questions my email address is on the screen.
Feel free to please reach out to me. Thank you very much.