 So today I'll start off by talking about the architecture that we use within our aqua. So the aqua platform works on a concept of containers. Here in the bottom right hand corner you can see a reference to a host. A host would be a machine and that machine could be a bare metals machine. It could be a machine on-prem, it could be in a data center, it could be a VM and it could be a machine in an instance in the cloud. What we do is we deploy a container and that container would be on that host and it would be enforcing controls. The enforcer is, as the name suggests, it allows you to block and enforce policies. You have an ability also to monitor the traffic within the container environment and that's sent to this next container we call the gateway. The gateway really is a misleading name, it's really a buffering mechanism to allow us to scale to very large environments. So you can have up to 1,000 of these enforcers reporting to one single gateway and then all the traffic has moved on to the command center. The command center is the management component of the platform and it's where the UI lives that we'll be seeing in a few moments. And then a connection to the internet. This component by the way can be also deployed as a monitor, sorry, as a container as well. And essentially this is where our vulnerability database lives. We have a group internal to Aqua, we call the cyber intelligence group. They're responsible for collecting all of the information regarding various vulnerabilities. And then what they do is they collect, check, cross-reference and summarize the vulnerabilities and make this available to the command center. On the left-hand side we have different references to different integration points. You can see a reference to the various registries. From our perspective it doesn't matter if they're public or private. You would input the credentials to the platform and we would work with that registry transparently. And then a reference to other integration points CICD tool or CICD tools. We are agnostic to any particular vendor so you could use any vendor that you choose and we can integrate with any CICD tool. And then other integration points like log management, log analytics and SIM tools. The integration points are extensive so there's a long list of integrations like integrations with notification systems, with LDAP systems, with SAML systems and secrets, various vaulting vendors. And then on the top right-hand corner here a reference to what we call CAS container as a service. We have an ability to inject our controls into an environment where you don't have access to the underlying host. So really an ability to inject our security controls into an image. And then of course when you OCRUN or Cube CTL run or Docker run the container we are built into that container. So this would be a solution for environments like AWS, Fargate and Azure's ACI service. I'm going to move on to the actual UI a bit. So here you have the UI. You can see the images basically broken down into their relevant repositories. If we look at any particular repository you can see in this case two images in this particular repository. And this is enforcing a policy. The policies live here. You can see a whole number of different types of policies. We're going to focus in on image assurance and here you can see you can create as many as you want to. So for example if you wanted to create a different policy for the dev environment or the production environment you could do that. And then when you go to the actual policy itself you have a number of different options that you can enforce. So for example we would block any unknown images or what we call unregistered images. And you have a whole bunch of available options that you could add to what's being enforced in the policy. So you could for example blacklist CVEs, you could disallow an image if it is configured to run as the super user. By the way we have not only support Linux containers but also Windows containers. So the reference is to the super user as opposed to root. You have an ability to blacklist packages that you could define which packages are required within an image. You could use NIST standards to define the severity level or the CVE max score that you're prepared to tolerate within your environment. You could utilize the power of SCAP for compliance in needs. You could blacklist open source licenses. You could whitelist images, blacklist images and even define an improved base image. Now not only do we scan for vulnerabilities but we also scan for malware, sensitive data. And we also allow you to custom create checks as well. So this is really allowing you to define anything that you feel is missing from the available options here and enforce it. So up till now really I've talked about the ability to scan I suppose from a registry. Now I'll talk about shifting left and really integrating with the CI CD process. So the example here is an integration with Jenkins. You can of course use any CI CD tool and essentially the integration would be almost exactly the same. If we look at the particular project, actually if we go back there, we can see four projects here. We can see that two have succeeded, one has failed. If we go into this particular project, go to the build history and go to the last build. First thing you'll note is the Aqua Security icon that appears in the column on the left hand side. Of course we have a plugin. You can go to the Jenkins marketplace, download it, install it and then this icon would appear as it does here. And then probably the best way to explain the integration is to see the console output here. And what you can see here is sort of the creation of the base image. And then you can see a call to a container. That container is the Aqua Scanner and what it's doing is it's going to our command center and retrieving a policy and scanning against that policy. And then you can see the various layers being added here. And then you can see a reference to calling the Aqua Container Scanner and once again going to the command center and retrieving the policy and running against it. And you can see the failure notification down here. And to understand why this failed, you can go to the icon and essentially get the information on why this failed and all of the details. So essentially what we do is we can provide all of the output in either JSON format or HTML format and send this to the CI CD tool and basically utilize the CI CD notification capabilities. So up till now I've really talked about scanning. Now I'm moving on to what we call runtime protection. We have an ability to control and learn the behavior of the container. You can see here a reference to the runtime policies. We call them profiles. You can see that there's an ability to... We have an algorithm that would actually learn the behavior of the container and custom create a policy specific for a particular container. Or you can use pre-existing policies. We have a whole bunch of them that live in this section. And then you can create your own new custom policy or let's say you've created something and you feel for whatever reason it's changed. You can use the profiler to relearn it. Or you could have no protection at all. So really you have the different options available to you at your fingertips. And if we look at one of these policies... Let's just take a look. The sort of controls that you have here are... For one, you can set the policy to block. If you're a bit nervous about blocking, you can set it to audit only. So essentially we would only alert. This policy has been set to block. You can see that we learn all of the resources being used by the container. In this case it's the allowed executables. These controls would define user access. What users are allowed to access this particular container. And then you have everything else about the container including network activity. Whether you want to define read-only directories. And here you can see essentially the limits you could define. And again this can be completely automated using our APIs and scripted. Memory usage, CPU usage, processes being used, disk usage. And then we have a clause that allows you to prevent any drift from the original image. If you remember initially I talked about the scanning capabilities and hashing all of the contents of the image. This allows us to actually prevent any changes being made to the container. As it's running. I'm going to move on to the container firewalling capability. So once again this can be scripted and automated. We have again a very similar mechanism to learning the behavior of the actual container inside the container. We have this for networking. Essentially we would learn and then create a rule set. That rule set would govern and control any inbound and outbound traffic and of course you can edit any of these parameters. This is done with an understanding of the container and container entities and principles. So we understand concepts like within the Kubernetes world and the OpenShift world like a namespace, a deployment, a label and of course a container name and ID. So that if this container would go down and be redeployed on a different host with a different IP import of course we can enforce the controls regardless across the entire infrastructure. Lastly I'd like to talk about secrets management. So what we have is we've created an proxy capability between third party vaulting vendors and the container. What we do is we would take a secret and replace it with our string and that string then becomes a pointer to the encrypted value within the vaulting solution. And what we do is we would retrieve it at runtime from the vaulting vendor and inject it into the container at runtime. And what this allows us to do is to control all access to the secret. We have a system of user access controls and then all of the aspects of administering and managing the secrets become very easy. So we have capabilities that allow you to edit for example or change a password on the fly without having to restart the container. So once again not impacting business continuity. With that really I've finished. Thank you very much.