The Aptible Update Webinar Series is a quarterly presentation that covers recent features and changes to the Enclave container orchestration platform and Gridiron security management tool.
We hosted our Q3 Update Webinar on July 25, 2017. In it, we covered:
- Enclave. New options for app deployment, Container Recovery, database self-service management, and upgrades to our CLI.
- Gridiron. A walkthrough of creating compliance documentation including policies and procedures using Gridiron.
We provided a brief recap of this webinar on our blog.
Chas Ballew: Welcome everyone. Thanks for joining us. This webinar is part of the Aptible Update Webinar Series. It’s a quarterly presentation that covers recent features and changes to the Enclave deployment platform and the Gridiron security management products. Our goal at Aptible is to make the best tools for developers to build security into your architecture and your organizations. So we make two products. [00:02:30] Enclave, which many of you who are attending use. It’s an AWS based docker container orchestration platform and development teams use it to deploy apps and databases into secure, isolated environments. We also make a tool called Gridiron, which is, think of it like a missing QuickBooks for security management. Development teams use it to build a compliance program, manage security activities, keep security data organized, and generate [00:03:00] compliance deliverables for audits and assessments. Things like that.
So, today, we’re going to hear from the team leads for Enclave and Gridiron. We’re going to hear from Thomas Orozco, who will talk about Enclave. Then we’ll hear from Skylar Anderson, who will talk about Gridiron and what’s new there. During the webinar, use the Q&A tool in Zoom here to ask questions. Frank Macreery, our CTO, will help moderate and ensure that everybody’s questions get answered. [00:03:30] Either we’ll answer them during the talk itself, or we have Q&A breaks built in and at the end, too.
Logistics: this is being recorded. We’ll post it on YouTube, with a transcript, and slides. We’ll put that all on our blog. And we’ll send you a follow-up email afterwards with links to all of those. With that said, I think we’re ready to get started and I’ll turn it over to Thomas, with Enclave.
Thomas Orozco: [00:04:00] Hi. Thank you, Chas.
So let’s jump right in and talk about what’s new in Enclave.
As Chas mentioned Enclave is designed to be the best place for you to deploy your apps, if they are regulated or sensitive projects. That kind of means two things. One of them is, it has to have a strong compliance perspective. The other one is it also has [00:04:30] to be a best in class type option platform. Last quarter we focused on the former, and this quarter we focused on the latter, which is the loss capabilities. We’re going to be covering these throughout this session on Enclave.
Before we do that, though, we’d like to talk a little bit about another project, that is related to Enclave, which is called Supercronic. Supercronic is a new project that we launched. It’s a new Aptible open-source project. [00:05:00] What it does, it tries to really make it easy for you, it solves the pain points of running cron in containerized environments. Which is something maybe some of you can relate with if you’ve ever had difficulty using cron. Maybe what happened, you tried to run an app, and cron showed up and purged the environment, and all your configuration was gone. Or maybe you had your output that you wanted to see, but cron sent it somewhere else. [00:05:30] Maybe your log fail, at best, or dev fail, at worst. And finally, if your cron tab is invalid, cron doesn’t tell you anything, it just doesn’t run your stuff. If your cron jobs are failing, cron doesn’t tell you anything it just lets them fail in silence. It tries to send you an email but usually that’s not going to work. So that’s what’s bad about cron.
But what’s good about Supercronic is that its really a simple drop-in replacement you can use. You can just take it, drop it where you would normally be using [00:06:00] cron, and it does the right thing out of the box. It’s going to leave your environment variables alone, so your configuration will be there. It’s going to pass the job output all the way to stderr so that you can see it. But also if your cron tab is invalid it will fail, if your jobs are failing it will fail, it will tell you. If your jobs are timing out, taking too long to run it will tell you as well.
We actually helped a few customers that were having difficulty using cron, cron [00:06:30] was giving them a hard time. So what they had to say that was notable is that it works. Speaking of cron and containers actually is a pretty big deal. It does indeed work. The bottom line is, if you have any cron needs in containers, you might want to check it out. The way it works is really simple. You just take a cron tab, point Supercronic at the cron tab and then it just works. So you can get this from our github, we also posted about this on our blog. It’s also going to be [00:07:00] in the recap for this webinar. There’s going to be a bunch of places where you can find it. Don’t worry if you can’t copy that link right now, but really we encourage you to give it a shot. I think you’ll be pleasantly surprised. We actually moved over a bunch of our own apps to it to make our lives a little easier as well.
That being said, let’s move back to the product that a large number of you are probably using and want to hear about today, that is Enclave. We’re going [00:07:30] to cover three topics by Enclave today. Apps, databases, and CLI.
For Apps, we’re going to start with this. For apps, we’ll have three items. Apps is going to be where we have the most changes, which relate to, respectively, availability, deployments, and endpoints. So, we’re going to talk about these. First of all, lets start with availability.
So the big deal for availability of apps [00:08:00] on Enclave this quarter is called Container Recovery. Container Recovery basically what is says on the [inaudible 00:08:08]. If your containers crash, it restarts them so that they’re recovered. If your app exits for any reason, Container Recovery will kick it back up. If you look at the example on the slide, I have this app that’s exiting. After five seconds it just writes and then exits. Well, if you shift that to Enclave, it’s not really going to exit, [00:08:30] it’s going to get restarted periodically by Container Recovery. There’s some amount of throttling, so if your app really isn’t booting at some point we’ll continue trying every two minutes, but this should save you if you have your Ruby apps tech failed, for some reason. That’s unexpected but also very unfortunate. With Container Recovery it will just jump right back up. At worst, you missed one or two web requests, as opposed to getting paged when Pingdom realizes your app is down.
[00:09:00] What’s even nicer about this is when you’re already using it you don’t have to do anything to take advantage of this feature. Just like a similar feature that we introduced, I think, about six months ago, which was Memory Management. Container Recovery doesn’t require you to do anything. It just works. It’s automatically enabled for all of your apps. Even if you haven’t done anything for your app to be compatible. Maybe your app is leaving behind a bunch [00:09:30] of .pit files and if you try to dock or restart it, it fails, that’s okay. Container Recovery will take care of all of this. It will clean up your container before restarting it so that if your container booted in the first place, you’re pretty much guaranteed that Container Recovery will be able to recover it for you.
That was the big picture for availability, but its not what’s the biggest for Apps this quarter. Arguably the biggest change is going to be this one, which is around deployment. [00:10:00] What we produced this quarter is called Direct Docker Image Deploy, which again, does pretty much what it says. It’s going to let you deploy directly from a docker image. There’s also a series of other changes that we introduced along with it, which you can see listed here. Like Procfiles are now optional in Enclave and you can now synchronize your deployments and config changes on Enclave. So let’s go through these. Starting with, of course, Direct Docker Image Deploy.
[00:10:30] As I mentioned, what this does, is you can use to deploy directly from a docker image you have on Enclave. You don’t need Procfile, you don’t need anything, you just need your docker image. This has a number of benefits. It means that if you already have docker images, you can reuse them. It also means that you get full control over your build process. Before we introduced this, if you wanted to deploy in Enclave, you had to build your [00:11:00] app on Enclave. That means if you wanted to have a specific docker environment around it, maybe you were using some docker features that we didn’t support yet, that might not work. Now that’s the case, it always works because you get to build things your way. Then you just push them and we run them.
So, the way this works, locally in the CI environment, maybe you’re using Gitlab to build these things. Regardless of how you build your image [00:11:30] or how it comes to be built, you just build your image then you push it to a registry. That’s the first step. Then you use this new CLI command, which is called Aptible Deploy. You just point us at your docker image, really telling Enclave, “I want to deploy that docker image to my app.” What happens next, is we’re going to take the docker image, pull it from your registry, make a copy on our end, just in case your registry goes down in the future, the scraper’s still [00:12:00] able to restart your app and everything. So we made the copy then we distribute that copy to your resources. To like our instances on Enclave to deploy your app. So it’s going to be really seamless, and more importantly there’s nothing specific to Enclave about this except for the command you use to tell us to deploy. The docker image itself can be built in anywhere you want.
[00:12:30] One thing I should mention about this though, some of you may recognize this feature as something we introduced about nine months ago. Historically we had support for this, but you had to provide gits for us with a Procfile to tell us what services you wanted to run. There’s a number of downsides, and some users even mentioned that to us. That it’s not super convenient, especially when they want to reuse their app it’s not great. So what we did now, is [00:13:00] instead of requiring you to push a Procfile using git, we’re just going to take your image and look at the CMD, which is something your docker image itself defines, which is very stuck out in docker and we’ll just use that to define the service. That being said, if you want to continue providing a Procfile, we’re not taking that away. It essentially becomes an option. If you want to use it you can, if you don’t want to you don’t have to. You really get the flexibility to decide exactly what you [00:13:30] want. Whether you want a Procfile, whether you want aptible.yml or if you just want you base docker image and just shift tab.
That being said, I imaging Procfiles are going away. No longer necessary, but that also applies if you’re not using Direct Docker Image Deploy. So that means that if you’re building your app on Enclave, you no longer need a Procfile either. You just push your app and use a CMD in it as [00:14:00] well. That is, really just put the CMD instruction in your docker file. What’s nice about this is that if you’re already using the docker file somewhere else, maybe locally, or maybe you’re pushing the docker file to your Kubernetes, or Docker Swarm. Maybe your docker can push locally. Regardless of where you want to use it, you get the convenience of being able to use the same artifact, the same docker file anywhere. Rather, than needing the docker file everywhere and the Procfile on Enclave. [00:14:30] So that’s a new flexibility for you, which again applies to Direct Docker Image Deploy, obviously, but also to regular Docker File Deploy.
[inaudible 00:14:38] Aptible Deploy is like the gift that keeps on giving. A new change that we introduced with this feature is that you can now synchronize deploys and config changes. If you haven’t felt the need for that before, this might feel very specific. But it turns out this was something that was [00:15:00] requested quite a bit by a number of customers. And the reason for this is, right now its not super convenient without this change. As of several months ago it wasn’t super convenient to deploy new code and make config changes at the same time. Because, changing config or deploying code, all of these things require you to relaunch all of your containers on Enclave and that takes time. So what you were doing before was you do this three [00:15:30] step process, where you do config:set so that it adds the new value then it restarts your app, then you’re good. Then you’re happy with that. Then you need the new code so you need the git push and that deploys the new code. So, again, you’re happy about that, but its not done yet. You need to remove some old config as well, maybe. So you have a third deployment to remove the config.
Now the problem with this is, I mean, it works, but there’s two problems. The first one is it’s a little slow. You do three deploys when you really just wanted one. [00:16:00] And second, it’s also a little risky because between steps one and two you have old code and new config, maybe these don’t work really well together. So you have to put in extra efforts to figure out how you’re going to make that all work and account for that in your deployments. Now the good news is, with this change its much easier. Now, you can actually do all of this as a single deploy using the Aptible Deploy command. [00:16:30] The other implication is that it’s going to be three times as fast because rather than doing three deploys, you just do one.
The way this works is you first push your code to Enclave, but you don’t push it to the rest of branch. You just push it to some other branch. The domain actually doesn’t matter at all. Really, the idea is you just push that code to us, and you make it available and you just say, “I’m going to use this later on.” Once that code is available, [00:17:00] then you can do Aptible Deploy and tell us, “this is, by the way, the code I pushed earlier, I’d like to ship it now, and also I would like to change my configuration.” What’s good about this is that we deploy your new code and your new configuration variables as a single unit, so all of the changes happen at once. You don’t have to be worried about different versions running in parallel. You have to think about this at all and this also going to be much, much faster. [00:17:30] Pretty much a side effect of that Aptible Deploy change we introduced but for some customers this should be welcome news as well. And with that, I will look at the last section on Apps, which is Endpoints.
So here we have a number of changes as well, which pretty much extend to making them more flexible, pretty much giving you more options with your Endpoints. These are respectively [00:18:00] TCP and TLS Endpoints. As the name implies they are endpoints that accept traffic that is TCP or TLS. For the existing endpoints, that is HTTPS endpoints, we now have the container ports that you can configure. I’ll go into more detail because that’s probably a bit abstract. And, finally, idle timeouts are now configurable.
So, lets talk about this. TCP and TLS endpoints first. [00:18:30] Essentially, its tricky. When you were deploying on Enclave, the only way to expose your app was to use a HTTPS endpoints. The way this works, they accept HTTP traffic, and that’s the only thing they’ll accept. But maybe you need to accept something else. Maybe you need to accept TCP or TLS traffic. That’s where these new endpoints come it. They’re going to help you accept traffic that’s not HTTP. That is, run apps that are not web apps. And these [00:19:00] cases for this will include, if you’re in Health Care things like running Mirth Connect listeners for HL7 data. That’s the main use case, we have a number of customers doing that already. Or things like IOT apps.
That being said, that’s a lot of end point types. Its probably useful to just review all of these. Briefly just go over them and the differences between these endpoints that we have. The HTTPS endpoints is the one we’ve had forever pretty much. [00:19:30] That endpoint is a combination of a low band server and a reverse proxy. The way it works is, the Internet is going to send you traffic. The only thing it’s going to accept is HTTP and HTTPS traffic. So, of course it’s going to accept that traffic on the stem.ports. Meaning, ports 80 and 443. The way it works is on port 80 we accept plain HTTP and on port 443 we just terminate HTTPS. As far as your app itself [00:20:00] is concerned, the only thing it ever sees is HTTP, because termination happens at the endpoint level. So, if you have the web app, that’s great because we take care of everything. We take care of availability, we take care of configuring SSL. Enclave really takes care of practically everything you need. You just need to accept HTTP traffic and just handle that. So, that is convenient.
That’s convenient, of course, but the problem is if [00:20:30] your app wants to expose something that’s not HTTP, that’s not going to work. So this is where TCP endpoints come in. This new flavor of endpoints. These are essentially just a path though part of the traffic you receive to your container. So your container is free to expose whatever protocol it wants on whatever ports it wants and the endpoint is just going to expose that and just accept that traffic and forward it all to your container. Now, the downside of this is, you’re no longer encrypting your traffic unless the TCP traffic [00:21:00] that you happen to be sending is encrypted. By default, in this case, you don’t have any encryption.
So, this is where TLS endpoints come in. Which, I mean, obviously superior in the sense that TLC endpoints, essentially what they do is accept TLS traffic. So, encrypted traffic, and they just pass it along to your container as just plain TCP traffic, which, essentially gives you the best of both worlds. You get flexibility, but you also don’t have to configure SSL and [00:21:30] configure TLS at all in the first place. I should mention that these also work with our Manage HTTPS offering, that is like, certificates that we provision for you via Let’s Encrypt. So that’s another layer of convenience for you.
So this is exciting, it is interesting. If you have apps where you may feel you may want to use this, currently these endpoints are probably better. So, if you’d like to add one, feel free to contact support and [00:22:00] we’ll set that up for you. We just need to create the endpoint for you. Afterwards it will show up in your dashboard and everything just like a regular HTTPS endpoint. So, soon, this configuration will be coming to the dashboard as well, currently its just only on the back end for probably just a few more weeks. So, if you have a pressing need to run TCP or TLS apps, the best way to do that right [00:22:30] now is to just ask support and we’ll set you up with this.
Speaking of app endpoints. The other change I mentioned is on HTTPS endpoints that let you configure their port. As you see on the slide I had before, HTTPS endpoints, they just send traffic to just the one port on your container. Historically we’ve chosen a default for you, which is the lowest port in alphabetical order, which [00:23:00] can be a little unpredictable. The news now, is that you just get to pick whichever one you want to expose yourself. By default, we’ll just pick the lowest port and continue to send traffic there. But, if you want you can configure that differently and just say, “Actually, at that endpoint use a different port.” And Enclave will set that up for you.
The use case for this is, maybe you want to use a port that is not the one Enclave is picking [00:23:30] for you. In that case, this will work. But for other use cases, like maybe you have a container that needs to expose multiple ports in the first place, like maybe you have a port for web and then one for web sockets. In this case you could have two end points, each for routing traffic to a different port on your container and this will work for you. Maybe some other use cases will include things like a management TPI that you’re running on a different port and so on. So again, you get all the flexibility.
[00:24:00] And finally the [inaudible 00:24:04] for endpoints in a configurable idle timeout. So, this one is a very specific feature, but maybe something you have needed in the past. The way endpoints work on Enclave is if your connection goes quiet for a while, it will be closed. So if it goes quiet for 60 seconds, be default it will be closed. The downside of this is that if you have things such as load pulling, or just [00:24:30] requests that are very slow, that can be too low. That can end up breaking connections that you legitimately wanted to keep alive. So this is what the change in two weeks is. Now, you get the flexibility to configure that yourself via a variable that’s called Idle Timeout, which can take pretty much any variable up to about 40 minutes. If you have long waiting connections you can just hit Idle Timeout in seconds to configure that to whatever you want, to whatever works best for your app. [00:25:00] Of course, that’s all optional, we’ll continue using the default for that. If you don’t need this, you don’t have to configure it. Cause, of course, we don’t want to overwhelm our users with too many options.
And that about wraps it up for Apps, so if we have any questions we can probably take a few now.
Frank Macreery: We do have a few, Thomas. Starting with a couple questions about Supercronic. So, the first [00:25:30] question, that asks if it’s going to be possible to use Supercronic as a replacement for the background or the crontastic that runs in the elastic search log stash SQ3 backup app?
Thomas Orozco: That’s a good question. We were actually planning to update that dock Yu-Repo to the new Supercronic instead. That may have already been done. I’m not sure.
Frank Macreery: I think it actually has. Yeah, I think Alex recently did that, so.
Thomas Orozco: [00:26:00] So the Yu-Repo has been updated to use Supercronic, so you can pretty much use that Use the updated code that going to use Supercronic. What’s going to come next there, by the way, is that we also plan to expose this using Aptible Deploy, which is going to make it even easier for you to deploy this repo. You won’t need to make your own code or anything, you’ll just be able to deploy it directly. So, if cleaning the repo and updating it is not something you have time for right now, be [00:26:30] sure to check back in maybe a month or so, and hopefully the repo should then be using Aptible Deploy so it will be like a one minute thing for you get updated to the latest version.
Frank Macreery: Great, thanks.
Also, a second question about Supercronic.
I’m currently using Whenever to generate the cron tab for my app. Can Supercronic be use with Whenever, should it? Is Supercronic a [00:27:00] replacement for Whenever?
Thomas Orozco: Yeah, they can actually be used together. Whenever is a good way to generate cron tabs, and Supercronic is a good way execute them. So they work very well together. If you just run Whenever without any arguments it will just generate a cron tab, so just write that to a file and point Supercronic at it. I think we have docs on this that we are in the process of updating as well.
Frank Macreery: Great, thanks.
So moving on, to [00:27:30] Aptible Deploy and Direct Docker Image Deploy.
So the first question. Darcy asks, “Is it possible to use a different branch for any type of deploy or is it only applicable when a configuration variable needs to be changed?” Basically, is there any restriction on deploying from a separate branch other than the remote master?
Thomas Orozco: No, you can use Aptible Deploy to deploy from a separate branch if you want. [00:28:00] One thing I want to mention is that you may want to do this to have a staging branch and so on. In this case, what you actually want to do is, you can have multiple branches on your side, and multiple apps on Enclave. And use them as different remotes and just push to each of their masters. So you can use Aptible Deploy to deploy on a branch at any time, but it sounds like what you’re actually trying to do is to have different branches of your app live on different apps on Enclave. In which case what you need is multiple remotes, not multiple [00:28:30] branches.
Frank Macreery: So another question about Direct Docker Image Deploy is: “What’s the process for moving from a git push based deploy currently to moving to hosting it on private registry and using Direct Docker Image Deploy, roughly.”
Thomas Orozco: So the first step is going to be for you to figure out a strategy to build your image and host it somewhere. Maybe on [00:29:00] Quay, maybe on the Docker Hub. That’s all on your end. Enclave doesn’t really care about what you do there. That’s the first thing you do. And once you have that, you just run Aptible Deploy and point it at your app. It will actually overwrite the existing repo.
The one caveat is that it may, depending on how you want to configure it, maybe you want to continue using the Procfile, maybe you don’t. So what I invite you to do there, is to look at the docs [00:29:30] that we have. We actually do cover migrating and the various options you may want to pick. So, essentially the bottom line is, you’re going to need to put your image somewhere and run Aptible Deploy, but then what you do next, what arguments you use though Aptible Deploy are going to depend on whether you want a companion git repository or not, so review the docs to see what you want to use there.
Frank Macreery: Thanks very much Thomas. That’s it for right now, so you can just [00:30:00] go ahead and go on. But if anyone else has questions that they think of later, feel free to drop them in.
Thomas Orozco: Alright. So the next topic we have is going to be Databases. It’s going to be a slightly shorter topic. Which is good, cause I think we’re running a little bit late on the Enclave side. So, for databases we have three changes. The first one is the same one as, perhaps, Container Recovery. It’s also going to work for databases. The next one is [00:30:30] self-service scaling, which was probably the biggest feature, one of the most anticipated features that we shipped this quarter. And finally, database endpoints.
So, Container Recovery, briefly, essentially, if your database crashes, which doesn’t happen very often. Databases tend to be more stable than apps. Mostly through the architecture of the database itself. But, if the database itself crashes, then, historically what happened is the Enclave SRE team get paged [00:31:00] and we have to look into it. But that involves a human, so it’s going to take several minutes to recover your database. With Container Recovery, that process is now entirely automated, so rather than taking minutes, it just takes seconds to recover, which is going to be much faster, obviously.
So, as I mentioned, databases, the biggest feature is, of course, Self-service scaling. So Self-service scaling pretty much [00:31:30] gained us what you think it does. It means you can resize and scale your database at any time. And perhaps, just an importantly, there’s minimal downtime on Enclave. So that lets you update the RAM footprint of your container, or the Disk, and it’s a convenient way to, if you have even more traffic than you’re anticipating all of a sudden, it can be pretty fast to resize. Or more [inaudible 00:31:55] speaking as your traffic evolves, then it gets bigger, [00:32:00] this gives you flexibility to extend your database to follow.
A few things to keep in mind. RAM can be increased or decreased, you can do that whenever you want. However, large RAM updates may take a little while to complete. The reason for this being that we need to launch resources. We need to launch instances. If you’re provisioning a 60 gig database container, we don’t have that capacity on standby in your private TPC. So in that case it will take a little while. That being said, the downtime will [00:32:30] be made minimal. As I mentioned, usually in the order of one minute, occasionally up to two minutes but never more.
Disk updates, a little less flexible. First, you can’t decrease the disk. That’s because once you have the disk, especially since its encrypted we don’t actually know where the data is. Well, we know where it is, its on the disk, but we don’t know which sectors on the disk, so we can’t just decide to shrink the disk back. And anyway the BIOS would not let us do that. [00:33:00] So for this you can only shrink up, well resize up. Another caveat, is this can happen, at most, once a day. So, if you feel the need to resize, don’t go and just add one gig or two. If you anticipate you’ll need to resize later on, it’s probably a good idea to give you some head room because you can only do that once a day. That being said, if you get really stuck, we have ways to let you resize multiple times a day but it will be much [00:33:30] slower and involve a lot more downtime. Which is why we, out of the box, only let you do that once a day. Because, as I mentioned that’s the only way we can guarantee minimal downtime. And finally, disk and RAM, of course, can be resized at the same time.
This is something you can do in the dashboard. There’s a resize button, just tick that. Or you can do it via the CLI just using the applicable DV restart command.
[00:34:00] And finally for databases, we introduced database endpoints this quarter. Database endpoints, what they let you do is to let you expose your database through the public Internets with endpoints. So if you have partners, like heath care partners. Maybe something like Segments that needs access to your database that is possible. So the way they work, really, is the endpoint essentially punches hole into your VPC through which traffic to your database will be allowed to go through.
[00:34:30] One thing I want to mention about these, is just like apps, database endpoints support IP filtering. That is, restricting traffic through specific sources. So its usually a good idea to use this to ensure that not everyone on the Internet can access your app. So, these endpoints will let you ensure that only particular integration partners are granted access to your database, so that anyone else on the Internet will [00:35:00] not be allowed to access your database. Which, from a security perspective, is pretty much a very good idea.
Do we have any questions on databases? Obviously, we don’t have as much content there.
Frank Macreery: We do. So the only question so far is, “How does one know when to scale up the RAM for a database container?”
Thomas Orozco: Sure, that’s a good question. We provide metrics for your databases in the dashboard, so [00:35:30] that’s a good place to start. If you see that your RAM usage is getting close, it’s generally a good idea to scale up. One tip there, would be to look at the split, if you split RAM between caches and RSS. If RSS is getting close to the limit, it’s probably a good time to resize. Caches are important in order to improve the performance of your database. So, if all your RAM is being used by RSS, you can’t get the advantage of caching. So, depending on your database, for hooking a parser [inaudible 00:35:59] for example, you [00:36:00] probably want to target using at least half of your allocation for caches. So, if your RSS usage is above half of your container size, you probably ought to resize a little bit. Having said that, of course, it depends on your database itself, but these are usually good guidelines. So take a look there. And, of course, if you’re unsure you can always ask us. Ask the support team and we can, of course help answer these questions.
Frank Macreery: Great. Thanks, Thomas.
Thomas Orozco: [00:36:30] All right. And, finally, we have a few CLI changes. I’ll wrap this up a little faster to leave some time for Skylar to go over Gridiron.
The changes we introduced here are essentially around making it a little easier to script with the CLI. So for aptible ssh, what this means is two things. First, all the output from aptible ssh will be routed to the right channels on the client side, so that means that you’re no longer going to be having any [00:37:00] debugging outputs coming from the platform showing up in your aptible ssh output. Instead, this all will be going into stderr, and the stdout will be reserved for actual output running from the command you executed. Probably, just as importantly, aptible ssh is now guaranteed to exit. It’s the same exit code as the command that you ran. So, if the command that you’re running fails, aptible ssh locally will fail as well, so that ensures better script ability.
Finally, the [00:37:30] one last change, which is to the Windows CLI. So we’re now introducing a .exe entry point for the Windows CLI. So, if you’re not using Windows this is probably going to sound a little abstract or maybe a little not so useful. But, if you are using Windows it will probably be a welcome change. The main difference this creates, is it’s a little easier to call the CLI either from an actual other batch script or just like from an [inaudible 00:37:55] and so on. Is going to ensure that you don’t get noisy problems coming from Windows when you’re trying [00:38:00] to interrupt the batch file and so on. Overall, it just makes the experience of using the CLI in Windows cleaner and pretty much what you expect.
And that’s it for CLI, and more importantly speaking, that’s it for Enclave. Did we have any final questions, Frank?
Frank Macreery: Yeah, one last question. Which, I’ll just fielding because it’s interesting, technically. John asks, “Will Aptible CLI, or the Aptible tool belt support Yubikeys [00:38:30] for two factor authentication?”
Thomas Orozco: Yeah, that’s a good question. We’d like to. We actually have, maybe actually have a branch of it that some of us, that’s what I personally use to actually authenticate using the ClI. The downside of it, is most of the actual libraries that can be used to interact with the Yuibikey, the Yubico provides one, but it’s not as reliable, not by a long shot. Not as reliable as what you’d get in Google [00:39:00] Chrome. So, occasionally will crash. If you have multiple keys plugged in, it’s pretty much guaranteed to crash. Essentially, right now, the user experience isn’t exactly where we want it to be. So, we’re not entirely comfortable shipping that. That being said, it’s indeed something that we want to do eventually. Maybe, expose it behind a flag so that, if you know what you’re getting into you can use it in the app. If that’s something that you’d be interested in, feel free to open a support ticket. We can probably talk about it, between porting to you we could probably also share the POC code [00:39:30] that you could use to work with it.
Chas Ballew: Okay. Awesome. Thank you Thomas, very much. And now we’ll turn it over to Skylar, for Gridiron.
Skylar Anderson: Thanks, Chas. Again, my name is Skylar Anderson. I’m the lead front end engineer at Aptible, and I work mostly on Gridiron. If you followed the past couple webinars, we’ve done some high-level talks about Gridiron. [00:40:00] The data structure kind of underlying Gridiron, and more generally what it is.
Gridiron’s a tool that makes it easy to manage your information security system and all the artifacts and deliverables that you export out of it.
Today, I’m going to do things a little different. I’m really excited to share what Gridiron looks like, and walk through an actual implementation of the security managements system with the Gridiron tool.
But, to start, just quickly, about the implementation. It takes place in about four steps. So, [00:40:30] if you were to upgrade, if you’re an Enclave customer, or you’re a stand-alone Gridiron customer interested. The first step of the implementation is a hands-on, guided process, with somebody at Aptible.
During this hands-on process, you’ll actually be, number one, be trained on best practices of managing an information security management system. But, then, more specifically how you can apply the tool, or the product and the tools within the product to make it easier [00:41:00] to manage your security program. Also in that tour, you’ll determine a set of baseline controls. And that’s something you can refer back to, to track your progress over time and know that you’re always improving. Also in that tour, you will generate your initial set of reporting and documentation out of Gridiron. We’ll walk you through doing that and tell you what some of the things mean and how you can act on some of that reporting and documentation. And finally, we’ll show you the continuous updating features [00:41:30] of Gridiron. I want to highlight that all the documents and deliverables that you’ll generate out of Gridiron are live documents. They’re not static. They’ll change and adapt over time as your organization and in your workforce and your tech stack changes. Gridiron will respond to those changes and continuously rebuild your documents.
So, I’ll just get right into the demo then. But to start, I just want to jump ahead a little and show two examples of some of the deliverables that you’ll get out of Gridiron. [00:42:00] The first, here is a sample Risk Assessment. Your Risk Assessment at it’s most basic level is kind of a catalog of risks that we’ve determined to be relevant to you. But behind each of those risks is a number of other components that are mapped together and combine to quantify what we call the risk level for each of these risks. Those components are things like vulnerabilities. These are specific things specific to your organization that might have enabled [00:42:30] certain risks or make them more severe. But then also, security controls and how you’re mitigating those vulnerabilities. I’ll get into detail on how these are set up and what that means in a second.
The other type of document that you can expect to generate is a Policies and Procedures document that you see here. It can store anything from basic roster information and rules and responsibilities to how you manage encryption keys, what your secure software development life cycle is like, and even generating actual actionable plans, like your business [00:43:00] continuity plan, and your incident response plan. Summarizing all the information you need to know about your security management system to actually respond to incidents. Whether it’s a disaster or just a particular incident. We help generate those plans for you and then keep them up-to-date with your actual security management system.
So, stepping back to the implementation. When you have your one on one call with Aptible, after you have your initial security officer training. [00:43:30] We’ll actually take you through this tool. We call this Security Program Design, or SPD. That’s the term we use for this wizard that you see here. This wizard will walk you through all the steps to setting up your initial baseline security program. The first step here is very basic, textual information about your organization, not much structured data. So we’ll just skip through that.
The next step, we’ll learn more about your workforce and locations. So this stage here [00:44:00] is a little long, because we’re actually generating a lot of background information about the number of roles, and responsibilities and I’ll show those in a second. We’ll skip through this step and just say we’re a remote work force. This is where it starts to get really interesting. Where you build out the actual workforce and tell the security system about your team. This is primarily broken up into two parts. The first, you see here is the designations. These are specialized individuals that have unique responsibilities that they need to [00:44:30] perform within your security management system. So, things like a Security Officer, and your Privacy Officer. These are reflected immediately in that roles page that I showed in your Policies and Procedures. Then, more generally, you’ll get up a number of teams. These are groups of users that need to be able to respond and perform specific responsibilities in your security management system. We also make it easy to quickly batch invite a number of users. But also, if you’re already an Enclave user and you hold an Enclave account, [00:45:00] we’re using the same auth API, so all your users are already available to you and you’ll be able to just quickly add them.
Finally, you’ll want to add contact info to each of these members so when building those rosters, if you are in incident response mode and you need to contact somebody, we help you build that roster of contacts, and we also prioritize by the number of designations a user holds. It’d probably be important to add my phone number here.
[00:45:30] So, next, we get into apps and databases. This is where it gets really cool and interesting. It’s where you can actually tell us about the apps and databases that you have, how they’re deployed, what sort of data they store, how you’re storing that data, and then what sort of systems they depend on. This particular account is also an Enclave customer, so we actually make it a little easier to just import some apps and databases from Enclave. So we have an auth API, and just a regular resources API. So we can go ahead [00:46:00] and import those. What this is doing is it’s copying over some data from Enclave and creating a profile in Gridiron about that app. The profile consists of, we can see here, some sensitivity and criticality and impact metrics. But it also starts to build a tree of dependencies for this app so we can understand the systems required just to run. In this case, democorp-api and democorp-auth. I’ll do the same in imports in databases. The procedures the same, I just click import, and its [00:46:30] copying this over into Gridiron.
So, I can see on the right already that we’ve indicated a couple dependencies. I know because I imported these from Enclave that the primary host provider for these apps is the Enclave App Layer. Same with the databases, it’s the Enclave Database Layer. If we were to add new apps, we could actually indicate more interesting dependencies.
But first I want to show you what it’s like [00:47:00] to add a new app. So we’ll add an iOS app. The first choice after the name is actually the type of the app. That’s really interesting because it allows us to generate a baseline risk assessment based of the type of that app. So, the vulnerabilities relevant to this app is probably going to be different based on the type. An iOS app has a different risk profile than a web API, for example. So, we’ll create an iOS app. The type is also used to filter the systems available. [00:47:30] So we know it’s an iOS app, you can’t deploy an iOS app on Enclave, but you can deploy it to the Apple App Store. You can also select a number of dependencies for this iOS app. So, for example, maybe it needs to retrieve PDF files storing patient data in S3. It logs the paper trail and it reads from our democorp-api and our democorp-auth app. Once I save that, I start to get a really interesting view into the dependency [00:48:00] tree of my information systems. We’ll see in just a sec.
So now I see I have an iOS app added. I can see the systems that it depends on, but more interestingly I can see now, for democorp-api and auth that I have dependents. Meaning that I have another system that actually depends on this. This is useful for at-a-glance being able to see some of the most critical systems in your architecture to know the number of [00:48:30] dependents system has, you can prioritize that in the case of disaster recovery or incident response. So, even expanding on this example a little bit, its probably very likely that api depends on auth. So if auth is used to store and authenticate users, api is probably reading tokens from there so we’ll go ahead and set up that relationship as well. So we’ll add an app dependency for auth and save that. So that’s moving that criticality of auth up so because we now have a new dependent here and I can see that reflected. [00:49:00] This is used in generating your Incident Response and Business Continuity plans. We can bump that priority up and create a prioritized list of systems that you would need to respond to, in order, based off how critical it is combined with the number of dependents.
Then next step is actually setting up the actual information systems that are hosting those apps and databases. Again, you’re applying some of the same values, the criticalities and impacts. [00:49:30] You can see, again, the dependents here. So we have a strong dependence on the Enclave App Layer, the Apple App Store, we’re using S3 for our iOS app and then logging the paper trail.
Also, for each of these systems, there’s some unique features. Number one, a lot of the data levels are actually bubbled up from the dependents. So we know we have a number of components that rely on this, they have a certain sensitivity level. We’re able to compute that just [00:50:00] based off the dependent components. Basically, we have a separate tool that we show at the end that helps orchestrate the cadence of you performing your security reviews. We’ll build the list of systems that need reviewed and then have a set of defaults for items within each system that you should be reviewing, and you can add your own review items here. We’ll remind you each month, or at a given interval when you should actually complete these reviews. Common things to review are audit log activity, [00:50:30] or the users in the system, make sure that everybody that has permissions is still a member of your team.
From there, you get into your Saas systems, these are third party providers that you’d like to include in the scope of your information security management system. They can be tools that help you respond to an incident, so Pingdom, or PagerDuty. Pingdom to let you know that your app might be down, or PagerDuty to alert your team if there’s an incident. You can include those here. They could also [00:51:00] include APIs that your app depends on, that you might be sending sensitive data to and you want to acknowledge that these apps exist in the scope of your system and configure those. You just click configure. You can indicate the use of this. You can define the criticality. Also, the type of the data and just click save. Now its included into the scope of your security management system.
Stepping through, next, sort of what we call predisposing conditions. [00:51:30] These are basically facts about your organization written in plain English. Things like, bring your own device. Do you allow your employees to bring their own laptops to work? By indicating yes, marking this as relevant, what you’re doing is exposing a number of vulnerabilities that we’ve cataloged on our end. We don’t show them to you here, necessarily, but a number of new vulnerabilities in your Risk Assessment will now be relevant to you. And this could lead to an increase in risk level for a number of risks.
On the other end of that, is the next step, which is the security [00:52:00] controls. These are the things you’ll have in place, that will actually mitigate the vulnerabilities that are now relevant to you based off your predisposing conditions. Again, these are asked in very plain English. So if, for example, if you’re performing background checks, that mitigates a number of vulnerabilities. So, by enabling it, not only will you reduce the risk level of a number of risks, we actually help catalog what your actual policy is for doing background checks and this is used to customize the actual output [00:52:30] of your Policies and Procedures document. That’s true for all of these controls. They’re all very clean and written in plain English, and then are articulated back to you in the form of actual policies in your policies and procedures document.
So, after you’ve defined your security controls, you actually see little tab pop down from the top. What’s happening is we’re rebuilding your Risk Assessment and your Policies and Procedures based off those answers. [00:53:00] So, I can click back in to view my current Risk Assessment. I can see, at a glance, the most relevant threats. I can click on risk model and see more deeply what all of them are, prioritized by risk level. I can see what vulnerabilities are relevant to me that are creating these risks, and for any one of them I can click into it and actually see the related controls. I can see the related threat events, and use this to prioritize. Either for my engineering team, or if it’s an administrative control. Things we would need to implement if we wanted [00:53:30] to mitigate this specific vulnerability. In this example, requiring encryption arrest is a control that we should have implemented. This also generated a new Policies and Procedures document. Once I’ve reviewed both of these documents, I can actually approve them. This’ll assign initial version, I can summarize the changes and sign off on it to be delivered to my workforce. That’ll be used as the baseline for all workforce basic HIPAA training. Our workforce will always have access to this policies [00:54:00] and procedures document.
Once users are added into your Aptible account, and you have Gridiron they’ll automatically be queued up and assigned basic training. You can actually always monitor the status of that training from the workforce training dashboard. As these users are getting invites, this is a fresh account, just set up, but invites in the background are being sent to their email. They’ll click through and actually be presented with in-dashboard training and I can do a quick example of what that looks like here. [00:54:30] So this is an example of our basic HIPAA training and you can actually step through and read this. Many of your employees that are added to Aptible will be automatically assigned.
Also, I wanted to share the security reviews tool. Again, this a tool that orchestrates the cadence of completing security reviews based on the systems you’ve told us about. This changes and is dynamic to the actual configuration of your security management program so at any time you can come in and complete a review and see the items that we’ve queued [00:55:00] up. This review is due August 25th, and I need to review these items and sign off on that. This is the dashboard that encompasses all the things I’ve just shown. We have some other tools that are really interesting I don’t have time to show, but Contract Management helps you store all your BAAs in the same place. Incident Response is a tool that helps you use your Aptible team in Workforce to orchestrate a response to an actual incident. And then a number of [00:55:30] configuration options that I briefly touched on. We’re expanding this constantly, whether that’s adding new actual functionality or adding new components to our library.
That concludes the demo. I was really excited to be able to show it to you, and if anybody has any questions. Oh, sorry, I’m going to talk about pricing quickly. Pricing starts at 2,499 a month, paid annually. If you’re interested in more, if you want a personalized demo, just contact Shah at aptible.com. [00:56:00] That concludes the demo. Does anybody have any questions?
Frank Macreery: Thanks a ton Skylar, that was great. Yeah, the one question we’ve got so far is, “What types of training courses are available on Gridiron today?”
Chas Ballew: I can answer that. There is a security awareness for your entire workforce. There is Secure Software Development for developers, and then there is Admin Training for Gridiron. And those are not protocol [00:56:30] specific. And then, for example, if you’re using a HIPAA protocol, there’s supplementary courses. There’s a HIPAA specific Security and Privacy Awareness course, there’s a HIPAA specific course around HIPAA Requirements for developers. There’s a HIPAA specific Security Officer training module. And then there are additional, there’s Incident Response and Business Continuity training right now as well. [00:57:00] Any other questions we want to answer now?
Frank Macreery: Yeah, so, a couple others. So one is, “What areas of the administrative side of compliance or of HIPPA are not covered by Gridiron?”
Chas Ballew: I can answer that as well. Right now Gridiron supports a Business Associate protocol for HIPAA. If you are [00:57:30] a covered entity and you have more detailed privacy policies and privacy management needs, Gridiron doesn’t currently support those. We’re planning on adding that in, in the next, in the coming weeks and months. So, Covered Entity needs under HIPAA.
Frank Macreery: Great. One last question. “The policies that get generated by Gridiron, what is the frequency with which those [00:58:00] are updated?”
Skylar Anderson: I’ll answer that. Your policies are generated in one of two ways. Again, its only the draft policies that are ever updated. Once you approve a document its frozen in time and stays that way. You always have a running draft, and that draft is ingesting all the changes to your security program. Those changes can come from one to two ways. Using the tool I just showed and actually changing your system configuration, and your security controls and those things. But also from the Aptible side, as we make [00:58:30] adjustments, and we add new tools and build out our library. We’ll adjust your policies accordingly to support that. You’ll only see it in the draft. When you’re ready to approve that, you can approve it and then that will be finalized as the current. So, it’s always changing. We publish changes routinely, but it’s changing every time you make a change to your program as well.
Frank Macreery: Awesome. Well, thanks very much Skylar. [00:59:00] Chas, I’ll hand it back to you.
Chas Ballew: Okay, thanks everybody for joining us. Again, we have recorded this, we’ll post links to video and slides on our blog and we’ll send you a follow up email.
Let me share it here, the next webinar will be on October 25th, in the Fall. Same time, 11:00 AM Pacific, 2:00 PM Eastern. You can register for the next one using this link: bit.ly, and just Aptible [00:59:30] update webinar separated by dashes. I’ll drop a link in the chat as well right now.
So, again, thank you all for joining. If you have any questions, just let us know, Support at aptible.com. Otherwise, we’ll see you next time.
Defense in Brief
Sign up to get the best in security and compliance delivered monthly.
From the Blog
Meltdown and Spectre are Critical Vulnerabilities for Cloud Infrastructure. Here’s How the Aptible Security Team Responded
Meltdown is a critically important vulnerability for any PaaS provider. This post details why that's the case, how Aptible responded to Meltdown and, more broadly, how Enclave is architected to protect against these sort of vulnerabilities by default.Read more
Recap: Aptible October 2017 Quarterly Product Update Webinar
Quick recap of Aptible's October quarterly product update and all that's new with Enclave and Gridiron.Read more