Announcement

An overview of Turbot Guardrails features & capabilities.

Turbot Guardrails enforces continuous enterprise cloud governance controls.

Turbot Team
3 min. read - Jul 01, 2020
Turbot Guardrails enforces continuous enterprise cloud governance controls.

Disclaimer: Automated Transcript

Hello! In today's session, we are going to be discussing Turbot's governance controls and our features centered around reporting of our out-of-the-box controls as well as our CIS Control frameworks from v7 to each of our cloud providers, Amazon, Azure, and Google.

[00:00:24] For some background before we get started, Turbot is a governance platform. We're a software company that provides out-of-the-box policies that can apply to your Amazon, Azure, Google, operating system and container layers that can prevent your users from taking actions that are unwarranted; it can also detect issues and automatically repair them in real-time. Turbot is a platform that is working behind the scenes, allowing your application teams to have native access to your stack so that they can make changes as they see fit. Turbot will constantly monitor and observe what is happening in the environment by capturing all the event streams. For all the actions that are taking place, Turbot updates its configuration management database or CMDB and analyzes those changes. Then, based on your stated policies, Turbot will take action to alarm or correct any misconfigurations.

[00:01:25] This essentially is allowing application teams to have much more self-service and agility in the environment, as well as the cloud teams are elevated to be much more supportive of the application teams, versus being in every single operational change and having to do manual follow up.

[00:01:49] Essential what Turbot's helping with is shifting large enterprises from that traditional IT governance that was stuck in manual processes and custom scripts or stated control frameworks that were locked into documents or work instructions, Turbot is taking those policies and putting them in as code, automating that type of configuration in real-time. So, it's no longer a request-fulfillment model for central IT to satisfy infrastructure changes, it's now infrastructure as code, allowing application teams to be more empowered to manage their own application stacks. The role of Turbot is to automate a lot of that central governance that was traditionally done with many disparate teams within the organization. It's the real-time event valuation, that automation around your platform and infrastructure-as-service to prevent and correct and give you that full transparency of what's going on at all times: who's taking a change, when is it happening, etc.

[00:02:53] The focus for today is our Governance Controls that Turbot has out-of-the-box and how you can visualize your control adherence within your environment so Turbot has thousands of out-of-the-box policies that are already in place that you can point and click of configure in code, and Turbot presents that back to you in a control adherence so you can see how well you're adhering to your security, compliance, cost, or operational controls. We have many out-of-the box controls that are in place that you can use to visualize your adherence across your organizational hierarchy. But we also have embedded external frameworks in place like CIS Center for Internet Security, which is what we'll be focusing on today. You can visualize your adherence to control frameworks like those as well. And because Turbot is completely extensible, you can build your own policies and controls within Turbot so that you can layer in your own governance, risk, compliance, or GRC framework, or your internal control framework, into Turbot and visualize that in the same light as you would with our own policies and external control frameworks.

[00:04:12] So the benefit here is that Turbot is discovering all the changes that are happening in your stack - so as users are making changes, Turbot is going to discover in real-time what that configuration drift is, it's going to analyze and orient itself around that change, and based on your stated policies it's going to react. It's going to ignore or skip that action because you've stated you don't care about that type of change, or it's going to alarm that it's an issue, or alarm that everything's okay. Or you're going to take the action where Turbot's going to reconfigure any misconfigurations in that environment. So the continuous monitoring of those controls is reported back in real-time visualizations - dashboards that you can filter and slice & dice - so if everything comes in in alarm state, so you can see how the controls are starting to run, to then, maybe they're marked 'okay' immediately, or they're going from 'alarmed' to 'okay' we'll talk through this and showcase it in a demo.

[00:05:25] All these controls are based in a hierarchy so you can type and categorize your controls, visualize them across your clouds and your stacks, then we give you dashboards so you can report on these types of controls so you can graph, filter, sort.

One of the values in Turbot is a consistent definition across your policies, controls, resources, user activity - all this is blended together in our GraphQL background so that you can relate all of these concepts together. You have policies for different conditions to approve Amazon S3 buckets - that can be very similar definitions for Azure Storage Accounts or Google Storage Buckets. And that concept of Approved Controls fits a very similar definition across all three clouds. You also have the ability to just look at containers or storage across your clouds and relate that back to policies for your different controls; it's all blended together regardless of what you're looking at in the environment; you can see the relation back to different types of controls or resources or policies.

[00:06:53] These type of standard control definitions are things like whether the resource is approved or not. "Is this resource allowed to exist?" Well, let's take a look at the conditions. Maybe it needs to be named a certain way, or it only can allow for certain tags, or certain types on configurations are very unique in that circumstance, or identifying what regions are allowed for this type of resource for it to exist - if it lives in a certain region or area that might mark it unapproved. Turbot can then alarm if it's unapproved or take action to remove, stop, or different types of actions depending on the resource.

There are also other types of controls like Active Controls. Active Controls would state whether or not the resource is active or not. If it's inactive, it could be based on age or time-lived, which can be used as a cost control to cleanup environments over a certain duration, or maybe it's from a security standpoint like access keys need to be expired every 90 days. These are all types of controls based on age, last modified, last used, empty, or orphan. The activeness of that resource is also a common control across all of your clouds. Encryption-in-transit, encryption-at-rest, those are very standard controls. How is my data protected so that boundary conditions wrapped around maybe a storage container or bucket or more direct on networking on security groups or gateways or routing? Tagging is another core concept - so tagging and labeling across your environments to make sure that your resources are tagged in a very consistent manner based on the context of the environment. Turbot's CMDB can provide context as to what the configurations are within the environment, pull down information from different data sources, then dynamically tag the resource based on your templates. There are a number of additional standard control definitions across Turbot. There are also unique controls depending on the different type of service. So, an Amazon S3 policy statement would be very different than an Azure or Google Storage, therefore we have different policies that might be unique for that service, but they're common controls you could visualize across all clouds.

[00:09:28] Our reporting capabilities within the console allow you to slice and group and filter based on many different types of categorizations - the example on the screen looks at a summary of Bob's environment - his active controls that are both in 'okay' and 'alarm' state. I'm showcasing within Amazon, Azure, and Google, how many controls I have within 'okay' versus in 'alarm' or 'error'. But I can also summarize that per service - if I double click into this Amazon filter, I can see the controls within S3 or IAM or my overarching account (there are some controls happening at an account level) or I can choose to only see what's happening within CIS definitions.

So here, I double clicked on S3 and I can drill in even further to take a look at controls like encryption, versioning, public access block which is one of the unique ones for Amazon S3 buckets, etc. That same type of view of public access block and encryption etc. within the S3 bucket, when I'm visualizing that in the console, I can also run GraphQL queries. Turbot is a GraphQL API service, and we front it with a console that is really just static web pages talking natively to the API. So anything that I'm doing in the console are really just GraphQL API queries that are happening behind the scenes. We have a number of developer tools, so we are very developer-friendly, we have graphical IDE that's baked into the console as well. So simply, a query that will execute this type of visualization is just as simple as a GraphQL query just to look at my buckets and controls by type and just pull the total, the alarm and the okay, and this is just an example JSON output. Whether you're visualizing the console or you're going to bring this type of information out and feed it into another type of visualization tool, it becomes very flexible and extensible.

[00:11:54] You can also get more advanced. For everything in your environment, Turbot can ensure tagging requirements. So once you start having Turbot tag-or you tag in whatever mechanism you feel is best - Turbot can bring in the tags on those resources and then you can alter your experience within our console or within the API to visualize resources based on that tagging scenario. Here I did a filter for anything tagged Department as the Key and Sales as the Value; I then altered my experience within Turbot to just visualize those types of resources. So, across my entire hierarchy, I'm looking at any resources tagged with Department: Sales, so I have 57 resources, 415 controls across them, I could drill into that within a resource inventory and then start filtering and searching and double-clicking into it. Within that same light, I can also then start going into the controls across that type of filter - so you can see it's extremely flexible to slice & dice and group across to find the information that you're looking for.

[00:13:11] You can get much more granular on that activity of what has happened across those different types of controls. Here I'm looking at an Amazon S3 Bucket Tagging Control. So, if I drilled in all the way even down to a particular bucket, I can see the history of those controls, how they're related to specific policies set, the impact to the resources I'm looking at. Then I can drill into activity history and in this example I can see that Bob updated the bucket and changed one of the Key Value pairs from Department: Sales to Department: Marketing - so he removed Sales and changed it to Marketing - he did this natively in the Amazon console. Turbot then quickly alarmed that the tags weren't set correctly, it updates the tag, updates the CMDB, then marks everything okay - it moves it back from alarm to okay state. With this type of visualization you can get directly into the audit trail and see exactly how user changes are then impacting your controls, how Turbot reacted to it based on your policies, the CMDB gets updated in real-time based on user or Turbot changes, and now everything's okay and it's reporting that verification back. That happens in a quick second loop depending on how your policies are set.

[00:14:35] Those were examples of what we define as out-of-the box as governance controls - our own definitions of how we think about those controls across Amazon, Azure, Google, and all that's generated based on Voice of Customer feedback and we're constantly updating the environment and adding new policies and controls within our ecosystem. But there are also externally defined standards such as CIS Version 7 which is an overarching control framework with about 20 subsections, that makes up an entire control definition. Across that control definition are very specific cloud-provider CIS benchmarks, such as Amazon Version 1.2 or 1.xyz, Azure, Google, etc., operating system controls like RedHat, Ubuntu, Kubernetes, even mobile devices and so forth. It's an extremely vast control framework - and because Turbot mainly focuses on the cloud and operating systems & containers, we bring in these types of CIS Controls.

[00:15:44] We have a hierarchy of controls where you can visualize Version 7 as well as individual cloud-provider benchmarks and see the relationship and be able to group and slice across that environment. So, as an example, if you're looking at CIS Controls Version 7, the networking piece, section 9.2 which is ensuring that only approved ports, protocols and services are running. Well that relationship is very similar down to the Amazon CIS Version 1. So, there's a mapping there to Section 4 of Amazon CIS Version 1 particularly on section 401 and 402 (but in this example I'm only looking at one of them). So here, if I wanted to then change that relationship and just see what Turbot Controls relate to Amazon CIS Controls that relate to CIS Version 7, we have our own controls that map to that as well. All of this is still categorized so that if I were still looking at these control definitions, I can see what resources are being impacted. See image below.

[00:17:17] All of these get mapped out (per above) so when I'm visualizing them in the console, or relating them to the API, I can actually filter and group by different ones. This same concept goes back to the graph we showed earlier, where if I'm looking at a resource, I can see the category of those resources or the policies that affect those resources or the policy groups those resources are in. It's all related within Turbot.

[00:17:43] So when I'm visualizing this back to the control adherence - when I'm looking at CIS Controls Version 7 across Amazon, Azure, Google in my environment, I can see one broader view of Version 7. But I can also change the filter back down to a cloud-provider focus and drill in even further by drilling into the Amazon CIS Controls and see Sections 1-4, I can go even further such as clicking on Section 4 (Networking) and see the four sections underneath that. But if I filtered back to a Control Category, I could see that Section 4 relates back to Section 9 here as well as Section 14 from CIS. You can see how having the freedom to group by these various forms of logic allows you to find the right information you're looking for. And again, very similar to Turbot's Controls, everything can be defined through both the Turbot console as well as the API. So, if I were looking at an Amazon CIS Version 1 report across a specific part of my organization, that query is very straightforward - you can get the same type of reporting simply through an Output from a query.

[00:19:17] I can also slice this across the organizational structure. If I wanted to look at the impact of those controls across my different folder structures or organizational structures, I could visualize that. I could also filter based on the resource type - I could see that these controls I filtered into for CIS - this is the impact across these types of services. Or I can drill in more specifically and look at the actual controls themselves and see a list of controls that I can filter based on certain criteria. I can see the real-time reporting and the impact of the changes that are happening. What's happening to the controls? Are they moving from alarm to okay, if they were okay, are they moving to alarm? I can see all of the changes in the drift.

[00:20:13] As an example: I have a policy in place to reject everything from 0.0 IPB4 and IPB6 and then I have an approve statement that says I might reject everything from 0.0 but I will allow - from my internal cidr ranges - ports 22, 80, and 443. So I have this policy set up on ingress rules which feeds into the logic of Turbot, so when changes are happening here, it caused Turbot to alarm that we have unapproved rules in the security group - so Turbot alarmed but I also had CIS turned on, so CIS also alarmed for adhering to Section 401 of the CIS report. What happens next is Turbot remediates instantly, removing the unapproved ingress rules, then immediately moves the report on CIS Section 401 from Alarm to Okay and updated our internal controls as well.

[00:21:53] I'm now going to switch gears and jump into a demo. We'll move over to the Turbot Console, and in real-time, I'll demonstrate some actions happening within the cloud and how Turbot reacts, so you can see for yourself how it works in real-time, outside of the screenshots. Here, I'm looking at my CIS Controls on Lee's Demo Account - I can see the same type of screens I was showcasing before, which allow me to drill into specific sections such as Section 1 of the CIS Report or perhaps Section 1.07 that states: Ensure IAM password policy require at least one symbol. Here I'm looking at the account password policy and it's showing that I'm green for that particular setting. Since I'm just looking at Lee's Demo Account, there's only one password policy in this Amazon account, but if I were to go up the hierarchy to the Sales Organization, now I'm able to see all of my Amazon accounts in this folder structure and all the account password policies Here I can browse my hierarchy as well as my controls and slice & dice into different sections.

[00:23:19] Now I'll go back down to Lee's account here; I'll go ahead and log into that Amazon account as a superuser. Here I'm just federating in; I'm assuming a role (there are other identity features that Turbot can help you with but for now I'll bypass that). So, I'm going to go into IAM and alter that setting there. I'll go into the account password policy and remove alphanumeric characters or symbols, then click save. As a superuser, I have rights to be able to do this type of action, like change the password complexity of all the console users' passwords.

[00:24:01] One of the things I can visualize in Turbot is how Turbot's going to come in - you can see it's already alarmed - so the recommendation is not met for CIS Section 107, so I can drill in a little further and see this in action. Here, Bob changed the requiring symbols from True to False, and what happened is that Turbot alarmed immediately that Section 107 wasn't being adhered to but also that Turbot's policies for configuring the password policy settings weren't being adhered to as well. So what happened is that I had a control turned on with Turbot out-of-the-box policies as well as CIS, which is why it alarmed on both, and Turbot then took the action to correct that misconfiguration, updated it, moving it from RequireSmybol: false to Requiresymbols: true. Which then verified that everything was okay. I can go right back to the console, do a quick refresh, and visualize that everything's okay now.

[00:25:08] That's just one example, what's very common in this is VPC Security Group Controls. This screen was also a part of the group you saw earlier. Here I have port 222 to an internal address which is approved from my policies, but if I added port 22 to 0.0 and saved - as a superuser I can save that change. That action might be allowed upfront because you might allow for any type of security group change because you don't want to block them or prevent them from managing security groups but you want to ensure that those that are outside of boundaries would automatically be corrected in real time. Turbot will discover that and remediate for you.

[00:26:06] Looking within the Turbot console, looking at this scenario just from a CIS standpoint, I'll go to Networking, this is relating to Section 22, Section 401. Here I can see that Turbot already took action to alarm and then corrected. If I want to just look at the resource history a bit, this is the CMDB entry for that Security Group demo we just showed. You're going to see Bob here added that 0.0, Turbot reacted by saying "that doesn't meet CIS Standards for Section 401, it also doesn't meet Turbot standards for that" - so we revoked the unapproved rules, removed the 0.0, and now everything's okay. By the way, this is all happening within quick second workflow behind the scenes.

[00:27:02] The nice thing about this is that it's not just an Amazon focus or one cloud provider focus, this is for any cloud provider. If I look at other controls such as Azure, drilled into CIS, then looked at my storage section & at Section 301, I can get down to these very granular levels. In this example, this storage account Bob's Demo account, I can see the history was very similar. Bob had a bucket here that he changed from a tagging standpoint and Turbot reacted, closed the loop - these are very similar to other changes in the environment. If I were to look at a more pointed CIS Control, in this case CIS Section 301 was not being adhered to when the bucket was created, it updated the encryption here to enable it, then set it to encryption and the CIS Benchmark was marked green.

[00:28:23] So this is very similar to Security Group rules, it's just for Azure storage accounts. Very similarly on Google, if I were to look at a GCP then drill into CIS, then drill into Section 4, and take a look at a control where I block project wide SSH keys, I can see the history. Just earlier this morning in a demo I ran this where myself, I have changed the blocking project-wide SSH keys was set to true, then I removed that configuration. So very similarly to AWS, Azure, you can see Turbot alarmed on its own policy that I should have block project-wide SSH keys set - I don't - it also shows that I'm not adhering to CIS Section 402. Turbot then enables, sets it back, and everything is okay. It truly doesn't matter what cloud provider you use; Turbot operates with the same types of controls across the environment.

[00:29:40] That concludes today's session. If you are interested in talking more or getting a personalized demo, feel free to reach out to us at turbot.com/connect or connect@turbot.com.