 Well, hello and welcome again to another OpenShift Commons gathering. This time we have a new OpenShift Commons member, Staff Rocks, that's going to introduce themselves and their, what they do and what they're working on around security and OpenShift. And we are really pleased to have Wei-Lan Dang with us, who's the VP of product from Staff Rocks, as well as a couple other members of the Staff Rocks team in waiting in the chat room. As always, what we're going to do is that Wei-Lan, give his presentation, you can ask questions in the chat, we'll try and answer them, and we'll have some live Q&A on the end of this. So, we also, the recording and the slides will be posted up on the OpenShift Commons blog, and we will make that, make the slides and the resources available from blog.OpenShift.com. So, Wei-Lan, take it away. Great, thank you, Diane. I appreciate the opportunity to speak to the OpenShift community this morning and tell you about Staff Rocks. I'll be covering several topics in today's briefing. So, first, I'll highlight key security considerations when it comes to enterprise adoption of container platforms like OpenShift. Next, I'll provide an overview of how Staff Rocks solves critical security challenges that arise when using containers. And after that, I'll walk through some examples of threat vectors and use cases that Staff Rocks helps enterprise customers with today, including some of the attacks we've seen in those customer environments. And then I'll show a live demo of the product running on the OpenShift platform. I'm happy to take questions along the way, so please feel free to let me know if there are any. I'll start with a brief background on Staff Rocks. We're a security company that focuses on protecting enterprise container environments, and we help enterprises accelerate their ability to benefit from the agility, speed, and scale that containers provide. Our customers are some of the world's largest companies, many who have selected OpenShift as their preferred container platform, and many who are already running containers in production today. These companies span a variety of industries, and they all use Staff Rocks for a comprehensive detection, prevention, and response for their containerized applications. Now, Staff Rocks does this with the industry's only security platform that delivers adaptive threat protection, and the adaptive attribute of our platform is a reference to the adaptive security framework developed by Gartner, but more importantly, it's also a key aspect of our platform being based on several technical breakthroughs. And those breakthroughs span instrumentation, analytics, and machine learning, and automating all of those functions across the entire security life cycle. Our company is just about three years old, we're headquartered in Silicon Valley, and we were founded by two serial entrepreneurs and widely recognized security experts. A quick background on myself, my name is Whaley and Deng. I'm the VP of Product at Staff Rocks, where I'm responsible for product management and product strategy, and I've spent a number of years in product leadership roles at various security and infrastructure companies, both large and small. Previously, I was head of product at a container company called CoreOS, and there I oversaw a portfolio of both open source container technologies such as CoreOS Linux, which is a container optimized operating system, Rocket, which is a container runtime, as well as a number of commercial products related to Kubernetes. Earlier in my career, I led product management for various cloud application and data services at Amazon Web Services and before that at Splunk. My background has primarily focused on distributed systems, and particularly with an emphasis on virtualization both at the server and operating system level, as well as cloud services that span both applications and infrastructure, with a focus on building platforms with high scalability. I also speak and write on container security and work with my team at Staff Rocks to engage our partners like Red Hat, the overall community, as well as the broader cloud data ecosystem. Now, as your organization looks to adopt container technologies like Docker or Kubernetes or increase your usage of them, it's very critical to consider the security challenges they introduce. Because containers are designed to be scalable and portable units that are constantly orchestrated, they create a new type of attack surface that is highly distributed and changes far more rapidly than traditional applications do. And because these containerized workloads are stateless and ephemeral, they create new problems for being able to actually collect the right information as part of proper security analysis or investigation when the containers are coming and going all the time. So, given the dynamic fast-moving attack surface that containers result in, conventional detection techniques really need to be rethought. The ones that rely on signatures and heuristics no longer work. And at the same time, these new application architectures are relatively new still, and they're still quickly evolving. So, the entire range of threat vectors that is going to emerge is really still unknown. Now, later in this presentation, I'll provide some real-world examples of attack patterns that Stack Rocks actually detects on for our customers today. Another challenge is that effective security in this type of environment requires being able to actually detect and understand various indicators of attack and compromise that are spread out across distributed applications. Existing enterprise security infrastructure was not built to address these types of challenges. If you consider traditional security tools, they don't have the visibility or awareness into what containers are doing. They instead rely on approaches like IP-based rules that are less relevant or they utilize architectures that don't extend to the container level. And the amount of container activity in these large-scale environments can also overwhelm the typical security workflows that were never designed to actually analyze data at the speed and volume generated by thousands or tens of thousands of containers. Since containers provide a new layer of abstraction in the stack, and it actually highlights the failure points of traditional security in these new environments. Because with containers, the focus for security ends up needing to shift away from tools that are tied to specific parts of the stack, such as the network, the host, or storage. And in containerized environments, security instead needs to operate differently. It needs to better match the application components it's intended to protect, whether those are containers or microservices architectures or so on. It's the only way it can actually keep up with applications while remaining transparent to what DevOps teams are trying to do. What this means is that security needs to become more workload centric. If you look at the evolution of the stack, security needs to be applied continuously and consistently as part of the connective tissue, so to speak, that glues distributed applications together. I'm going to go into a little bit more detail about how this idea of security focusing on the containerized workload, rather than the underlying infrastructure, can best be put into practice. And it starts by looking at the entire life cycle of containers and breaking it down into some very distinct phases. And these phases span the time when an image gets built to when a container is deployed from that image to when the container is actually running. And each of these phases requires different security controls along the way. And how OpenShift and Stack Rocks fit together are, if you look at the OpenShift platform itself, it provides several security capabilities that enable you to securely build images and deploy containers from those images. In the build phase, best practices require ensuring that your container images are scanned for known vulnerabilities, that trust is established over time. That trust is established over the content of those images and that the ability to push and pull images to and from the container registry and to access the container cluster are appropriately limited. So OpenShift provides a set of capabilities that helps customers with this. It provides vulnerability scanning via atomic scan. It allows you to sign images with GPG keys. It also incorporates robust role-based access controls. And Red Hat has actually been a leader in pushing to get those capabilities integrated into Kubernetes itself. And in the deploy phase, you have to think about hardening and isolation of containers throughout the cluster to appropriately limit upfront what they're supposed to be able to do. And also to ensure that sensitive data is not exposed in the process. Now OpenShift leverages the secrets management that is built into Kubernetes and support was actually recently added and announced to encrypt those secrets at rest in SCD. Kernel level security, on the other hand, can also be applied using mechanisms like SC Linux, which is very commonly used on RHEL systems, as well as SecComp profiles. And projects and network policies within OpenShift can also provide additional isolation between containers. How StackProx complements the security provided in OpenShift is that we primarily focus on security during the run time phase, which is when containers are actually running at scale and dynamically coming and going all the time. This encompasses capabilities such as monitoring and network visibility, intrusion detection, exploit prevention, data protection, and instant response and forensics. If you consider this list of functions, many of them actually need to be re-thought and re-implemented for container environment. And they present very difficult problems when you consider the scale and speed of containers and the fact that most run time attack vectors are very specific to particular applications and what they're doing. And what I mean by that is that a one-size-fits-all approach to security here generally doesn't work. And these are the deep complex problems that we've solved, and our product gives security teams within enterprises the ability to triage, investigate, and understand the root causes of security incidents on their running containers. How our product actually achieves this starts with what we think of as a container-native architecture. StackRocks is made up of a set of integrated security containers that deploy and run alongside your containerized applications. This allows StackRocks to easily fit in with and effectively become built into your container stack. More specifically, it's agnostic to and abstracted from the underlying infrastructure and any other container tooling that you've selected. We integrate with all the leading container platforms, including OpenShift, and as an example of how we're actually agnostic and abstracted from that underlying infrastructure, we have customers who have chosen to deploy OpenShift both on-premises in their data centers as well as on multiple public clouds. We run a container on each host in your cluster to collect signals about container activity and how we approach threat detection is this data is then evaluated for various indicators of attack and compromise and analyze using machine learning-based modeling. From the data we see, we build up a deep understanding of application behaviors and attacker techniques, and these are all correlated across the environment to then identify attacks, policy violations, and other types of threats. I like to spend some time to elaborate on what this means for OpenShift environments more specifically. Our platform is distributed as a set of container images that are used to launch the StackRocks services into your OpenShift cluster. But rather than just providing OpenShift users with a set of Docker images, we build in native integrations with the platform itself. And this level of integration means that bringing up StackRocks in OpenShift is very easy. You can utilize your existing orchestrator toolchain including the OpenShift CLI, familiar OC command syntax, and YAML files to launch and manage StackRocks. We also have a built-in bootstrapping process for all of our services that is completely OpenShift aware. Many of our customers prefer to use private registries, and you can also opt to store the StackRocks images in the OpenShift container registry. Now, once the StackRocks services are running, they're deployed and run in a separate OpenShift project, which allow you to further determine who has the ability to administer StackRocks within your cluster. And additionally, you can configure flexible deployment configurations by placing and running different classes of StackRocks services on specific nodes within your cluster. And you can do that by leveraging node selectors for the specific project that StackRocks runs in. The StackRocks services that are used to identify threat indicators, for instance, these are some of our data analysis and machine learning services. These can run on nodes that are separate from where your containerized applications are actually running. And in this operational model, security can start to be treated as and considered as just another application within your cluster. It runs alongside your containerized applications. It's managed the same way and operationalized the same way in terms of deployments and upgrades. StackRocks is also designed to autoscale up and down based on the data it analyzes. And it operates within any of the existing configurations you set on your OpenShift cluster, including projects and security context constraints. Additionally, StackRocks is able to auto discover containerized OpenShift and Kubernetes services. We monitor and detect threats on the containers that are actually running OpenShift services themselves. And this is very interesting because the orchestrator represents a distinct and separate attack surface that is also critical to safeguard. If you consider what compromise of the orchestrator could result in, it means an attacker could take any number of privilege actions on the cluster itself. And as I walk through the demo later on, I'll show how StackRocks discovers, monitors, and detects on potentially malicious activity taking place in OpenShift containers. What makes StackRocks's approach so unique is that it's built on breakthroughs in three key technical areas. StackRocks itself runs as a set of security microservices, and this allows us to achieve orders of magnitude, better automation, scale, and speed than traditional security tools. And today StackRocks, as an example, today StackRocks can detect and stop a web-based attack with data exfiltration across a set of distributed containers in a matter of seconds. Second, StackRocks uniquely collects data that constitutes what you can think of as a source of truth for container activity, making it possible to spot the most granular indicators of threats as they progress from delivery to malicious action. And third, the platform applies multiple machine learning approaches to quickly process data, augment analysis, and discover patterns that enable you to tune detection to your particular application environment and what containers are doing within that environment. So collectively, these three areas that we focus on enable comprehensive threat protection, which includes detection, prevention, and response that fully adapts to your container environment and the specific applications that are running. And when we talk about adaptive threat protection in the context of StackRocks, that encompasses a set of very unique capabilities. We start by continuously monitoring data at the level of system calls, network traffic, and container events. And this detailed visibility allows us to use machine learning to create high-fidelity threat models. And those threat models are used to discern various indicators of attack and compromise. And some of these indicators or some examples include anomalous processes, suspicious network communications, unusual container commands, or privileged escalation. Users also have the option to configure automated enforcement actions that can be taken based on what StackRocks detects. And these enforcement actions can either be preventive in nature, such as blocking container commands or system calls or responsive, which include things like pausing or quarantining containers for further investigation. And what those capabilities allow, for instance, are it gives security teams a chance to actually evaluate and analyze what's going on within a running container in an isolated setting before the container actually goes away. Otherwise, the information is lost once the container gets killed or gets torn down. And this StackRocks approach is designed to defend against a variety of threat vectors. We've learned very important lessons from the prevalence of cybersecurity attacks and data breaches over the last few years, mainly that hardening and prevention are by themselves not sufficient. Security teams need detection and response capabilities that enable them to mitigate the impact of security instance and to be able to actually respond to them. On the next couple slides, including this one, I'll highlight some attack patterns that enterprises need to be ready for. In this first case that's highlighted on this slide, this was an attack pattern brought to our attention by a large bank. And the attack vector consists of multiple phases that start with code injection and result in data exfiltration. So moving from left to right, the threat starts with attack delivery, and this happens via code injection on a web app service. If you consider the use cases for containers, many organizations are using containers to build a highly scalable web tier. And these containers are susceptible to a variety of different web-based attacks. Indicators that StackRocks would look for in this scenario include malformed content or suspicious or known malicious incoming IP address. Now, after comprising the web app container, the attacker starts to move laterally east-west within the environment. And this can be identified based on anomalous network communication or the use of non-standard ports. Once the attacker lands on a container that is part of an internal brokerage app service, and this is a service that the web app service talks to, he starts to establish persistence, basically embedding himself into the environment. And indicators that can be attributed to this behavior include privilege escalation or sensitive file system accessor changes. The attacker then moves laterally to the DB service, and the DB service in this case is likely ultimately the intended target of this attack vector. Now, if the attacker starts to exfiltrate data from that DB service, then StackRocks detects this based on indicators such as a substantial HTTP payload or suspicious outgoing IP, which may represent command and control communication or something similar. Now, StackRocks first automatically, if you look across these various vectors that have happened as part of this attack pattern, StackRocks first automatically surfaces the different types of indicators that span these different phases. But by themselves, each of these indicators do not actually surface that a much larger problem is at hand. And so what StackRocks uniquely does in this type of scenario is we're able to detect this type of serious attack pattern by understanding how these indicators are actually related to each other across containers within the distributed environment. On this next slide, another attack pattern that we've worked to address, in this case with a U.S. government organization, is one that targets secrets. And again, going from left to right, it begins with a vulnerability exploit. In most cases, we've observed that even if the container platform itself has been hardened, containers that are running still have vulnerabilities. New ones are being discovered all the time. And indicators of this type of exploit may include an attacker launching anomalous processes or communication originating from a particular IP. The attacker then establishes a reverse shell on the web app service. And this could be discovered by StackRocks based on indicators such as anomalous outgoing communication or usage of non-standard ports. Now, after that, the attacker accesses the file system. And these are where secrets may be temporarily stored and may be exposed. And so the attacker extracts those secrets. And in order to detect that, we would look for indicators such as file system access or sensitive data exposure. And the last step involves the attacker initiating a remote procedure call that causes the container to either exceed its resource constraints or run a process that results in the container getting killed or something similar. And in this case, the attacker is actually seeking to get rid of all traces of his activity. This is the equivalent of the crime scene being wiped before the detective arrives. Before I switch over to the demo, I want to highlight some key use cases that OpenShift users look to StackRocks to address. The first is container discovery. After deploying StackRocks, many customers are often surprised to find just how many containers are actually running in their environment that they didn't know about. And so StackRocks makes auditability, behavior profiling, and search-based discovery very easy. We also have customers who are deploying on-premises in the public cloud or moving containers across both and want security to easily span these types of hybrid environments. And so they're looking for what we call cloud workload protection. StackRocks provides a security that's required to scale with infrastructure, particularly cloud infrastructure that is highly dynamic, as a result of being provisioned on demand. And a third use case is tied to the fact that StackRocks services very detailed event context. We have tier three analysts users who focus on investigating container security incidents on a deeper level to identify root causes and use those to adjust policies for better prevention. And this falls under a use case or category that we think of as threat hunting, which is really part of the instant response and forensics process. Let me now switch over to the demo environment. Dan, are you able to see this all right? Absolutely, it looks great. Great. What you're currently seeing here is a view of the StackRocks portal, which provides a web-based user interface and runs as a separate microservice. Right now it's running in a container on OpenShift. And what I've done ahead of time is set up an OpenShift cluster and deployed StackRocks, along with several example applications. This cluster is live. You can see the current time in the upper right. And this is a 10 node cluster that's running 86 containers. StackRocks can be deployed using your existing OpenShift tool chain. And once that's done, the machine learning models are automatically built based on the signals we collect from the containers that have been auto-discovered. So in this setup, the machine learning models have already been built and are now being applied to detect various threats within the environment. Here, I've also previously gone ahead and launched some attacks on a couple applications in the environment, which has resulted in alerts being generated along the left side, as you can see here. Now, when you log into the portal, the first view we're presented with is the overall dashboard. And this gives us a summary of what's going on in the environment. From left to right, you see the navigation menu, the stream of new alerts being generated within the environment. On the top right, metrics on these alerts and the map view. Now, I'm going to minimize this top bar to get a larger view of the map. I'm going to zoom in a bit. And this visualization provides an overall network view of your containerized applications and presents the type of visibility that traditional security tools simply can't. Here we see we have a front-end application and a DNS server application. We can also see that Sacrox has discovered the containers that are running OpenShift services as well, which I'll come back to in a moment. If we click on the front-end application, we can see the list of specific alerts on the left side that are impacting this particular application. We can see, if we look at this popover, we can see that the application is made up of two services, the number of alerts that are outstanding on it, and gain network visibility about the protocol's ports and communications in and out of this particular application. We can actually then drill down into the application and investigate at the service level. And if I zoom in at the service level, you can see that there is a service that was launched from a MySQL image and one that was launched from a Python image. And we can further drill down into the set of five containers that make up this particular service. And we can see that out of these five containers, one is in fact compromised with high severity. We can also see how these containers are actually communicating across the entire environment and with each other. Now, if I go back to the set of applications at the outset, and if I click into, if I drill into the OpenShift grouping, you can see that it's made up of two services. And I can see, what's interesting here is I can see that there are the OpenShift origin services as well as Cockpit, which provides the dashboard UI for the OpenShift cluster. And the containers that make up these services may include the underlying Kubernetes services that handle things like DNS, network proxying and load balancing metrics, and so on. And we're able to monitor activity at the level of these individual containers, which allows us to detect when there's an attack or a policy violation. Going back to the dashboard, this dashboard view allows analysts and security operators to quickly understand what's going on in their OpenShift environment and get a visual overview of all the containers. And we can see on the left side now, looking at the list of alerts, that there are a number of different alerts ranging from policy violations to attacks. And if we take a closer look at this web injection and exfiltration alert, we can see what application is being impacted and when it actually occurred. Now, if we click on this, we get both a summary and detailed context about what stackrocks actually detected. And so we first present to the security operator what happened to this application in English language terms. So if you look at the summary here in this banner, we're telling the security analyst or operator that code was injected on this particular container, which belongs within this service and application, which led to a data leak, which is a very serious problem. Now, on the right side, we provide risk scoring, and we also highlight the machine learning models that were used to detect this attack pattern. We then go into more detail and we break down the alert into different phases that reflect the attack's progression, based on different indicators. In this case, in the first phase where there was code injection, a URL encoding, which was subsequently followed by an outsized HTTP payload. And we discovered these indicators through a number of different vectors, including system level data such as system calls or container level data such as Docker events, and then correlate them using machine learning. By focusing on how these different events relate to each other, we're able to surface the larger issue that an analyst or security operator needs to be focused on. And it's what allows us to reduce the noise, the time and effort that security teams need to spend on responding to security incidents on their containers. These alerts also can be integrated with your existing notification and instant management systems. So these alerts can be sent out to systems like Slack or PagerDuty, ServiceNow, or whatever you might be using, your security might be using in terms of instant management. If we select this code injection event and click event context, then we can see a number of additional details that may be useful from a standpoint of deeper use cases such as threat hunting. Now, if we click and move over to the instance view, instance section, then this provides a list of all alerts that have been generated within the StackRock system. And if I click on this lateral movement alert in particular, then we can observe that in this case we detected on indicators that include anomalous network communication across services that were then followed by anomalous processes being launched. And StackRock also gives you ability to create attack profiles for more complex attack patterns. So if, for example, we wanted to detect on the threat I highlighted earlier that was brought to our attention by the large bank, that involved the code injection that was followed by lateral movement prior to data exfiltration, then that's also easily configured within our system. And then finally, we also can easily search across the cluster to find what we are looking for. So if I go into this search bar and I search for front end, we can quickly retrieve alert services models and other information which allow for rapid discovery at scale. And I forgot to hit enter there, but now we see that these are being surfaced so I can see alerts, I can see services, I can see models all associated with this particular search term front end. And the idea is that at scale, discovering information so that you can do proper analysis and investigation from a security standpoint is critical. And so StackRock makes it easy to actually discover a number of details and lets you drill down quickly to what you're looking for using this search capability. And that's a quick demo of how StackRock's automates the detection of threats in an OpenShift environment and how it gives security teams the visibility analysis and context needed for comprehensive container security. That concludes this morning's briefing. I enjoyed the opportunity to share with all of you about how StackRock's enables enterprises using OpenShift to benefit from comprehensive security with our adaptive threat protection platform. I'd love to hear from you so please feel free to contact me by email on either Twitter or LinkedIn. I'll be at both DrCon Europe next week and the OpenShift Commons gathering in Austin in December ahead of KubeCon. And I would be happy to meet with you and tell you more about StackRock's. And for more information about our product and use cases, please visit our website stackrocks.com. Well, thank you very much, Wayling. This is pretty awesome. It's sort of where security meets machine learning and really takes it to the next level in terms of threat detection. It's really quite impressive. I'd love to learn more, maybe in a future time, about the different machine learning algorithms that you're using to do that and what's under the hood a little bit in terms of that. Because I think that's an interesting application of machine learning that we should have expected someone to come up with a great product offering around it. And this is really going to have to see where we go next with this because the pattern matching and the stuff that we had done in the past was pretty static. And this really gives it another opportunity to learn from the ingresses and the changes that are happening under the hood and finding new patterns in applying them. So this is really interesting stuff. Yes, absolutely, Diane. And we'd love to do a follow-up briefing and go into more detail and meet with folks to talk about how we're actually applying machine learning in a security context for containers. We apply multiple machine learning approaches primarily because we find that there are certain approaches that are better suited to different types of indicators of attack and compromise and particular threat vectors as well. And so this really combination of different machine learning based modeling is actually critical to getting effective detection coverage and being able to be prepared for and address the various types of threats that arise. In containerized environments at large scale. Yeah. This is what we've disbanded. We actually did a briefing earlier this week on TensorFlow and using that and creating machine learning workloads on OpenShift. So this is interesting from the other perspective of using that sort of stuff to detect the security anomalies and alert people to threats. So it's definitely another wonderful machine learning use case. And I think people will be interested in understanding more about the actual technology that's under the hood without giving away any trade secrets or whatever. But I think the use case for machine learning in the cloud and with the amount of data that people are generating is huge. So I look forward to many more conversations. I'm not seeing any questions in the chat. So now's your chance if you have one. Otherwise, I'm going to let you reach out and talk to them. And we'll meet everybody face to face in December at the OpenShift Commons gathering. Great. Thank you very much Diane.