Core Capabilities
Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or
Already have an account? Sign In »
Video Transcription
00:00
with stage set. Let's dive a little deeper into the capabilities of balt and expand on those three pillars.
00:06
The 1st 1 is centralizing secrets storage.
00:09
I'm sure nobody on your team are part of the organization has ever hard coded secrets or passwords or some sort of credentials in their source code.
00:19
Or maybe they've checked it in to a properties file, and that Properties file has gotten into the source code control.
00:26
Possibly. There's a ops team administration team that uses scripts such a Zschau F or answerable or puppet, and they have the keys and the passwords embedded in those scripts, and they put those in source control.
00:42
The bottom line of the whole example is that there's a lot of different ways in different areas and facets that people can put scripts in source control. They can be sending them in emails. They could be pasting him in Azaz note note pads, storing them and notes off on the side of the desk,
01:00
and this all transpire alors into what the Hash Corp cto arm on,
01:04
refers to his secret sprawl. Right? The secrets are just all over the place, and we don't have any good centralized way to manage those secrets. And one of the problems with that is keeping track of where they are. But then ensuring are these secrets being stored
01:22
at rest
01:23
in an encrypted fashion? And when they're being sent between point A and point B, are these secrets also encrypted? So where they encrypted in transit? If your secrets air visible, accessible, locate herbal in plain text that creates a vulnerability and we really want toe
01:40
minimize those vulnerabilities in the security of our applications
01:44
and applications was to rely so heavily on these different kinds of secrets.
01:49
Other benefits of secret storage include improving life Saiful controls and what I mean by that is keeping track of who has access to this, right. If you're putting secrets on Dropbox in a file, you may say, You know what? We're doing a good job to make sure only this team has access
02:07
to that folder that contains the secrets.
02:09
Okay, but, um, then brings other problems when you have developers with their own different set of secrets and they're storing it in a version control system. So it's not sitting over in that dropbox, and how are you ensuring that the access is there.
02:25
So these are the kind of problems that the central a secret storage is hoping to solve.
02:30
And then, of course, needing to revoke access, not everybody is tying into the same identity access system, right? Not every not every version control system. It may have its own set of users, and every Dropbox may have its own separate set of users. So how do I know if somebody leaves the company or if I want
02:47
remove access to the secrets that this particular individuals have
02:52
without having a centralized places is very difficult to do. Renewing old secrets. You want to rotate secrets on on occasion? You want to change passwords, right? You probably have your user name and password. London. Most companies, they're gonna have it. So every 30 days, every 90 days you have to change your normal user credentials.
03:10
But the passwords and user names and other secrets at the system level,
03:15
Sometimes those don't get rotated, and we want to rotate those on a regular basis in the event that a secret gets found. Well, if we're rotating it than that, vulnerability is only exposed for a limited period of time.
03:29
you know, when the Equifax hack is a really famous situation and I don't think a lot of people realize that when all that data of those millions and millions of of us customers all the credit profiles, all the stuff about their banking history that purchasing pastors
03:45
when that was all X field traded from Equifax,
03:50
it took place over the course of 78 days. So just because someone has a secret in their hand for five minutes doesn't mean that it's going to be all the data gets sucked out. In fact, when we're talking massive amounts of data and in data protection, the secret
04:08
is going to be disappeared and rotated on a regular basis.
04:11
They need prolonged access to these systems to really get a hold of a lot of information and to really have a foothold to do damage and and make their way deeper into your systems of your company, hacking your application and so forth. So the rotation in the renewal is really big. And then finally, the audit trail, tracking in who
04:30
is accessing these different secrets,
04:32
not only controlling it, but then, having an audit of Okay, we know John Doe should have access to the secret. Andi. He pulls the secret one today, and then all of sudden, we see this odd behavior where the secrets being pulled 10 times 100 times, right? Having an audit trail can really help you
04:51
debugging and finding anomalies in the behaviors
04:55
and identify potential problems before they get started.
05:00
Dynamic secrets are are an interesting concept that may be very new for you. The your training, attending this training here, up on the screen, I've given an example that I took. There's an engine. ICS has a published project on implementing micro services right and using Engine X for it.
05:20
And and so I took this because I thought it was a good example of a very complex system
05:26
built out of micro services design, where you have different parts and components and the different parts and components are talking to each other. So on the left there's the user right, And then there's a proxy going on, and the proxies is making connections to the reddest cash database. And then there's a
05:42
ah Pages model, and that itself is making connections in communicating with a variety of other services at the top of the user managed service,
05:49
which talks to dynamodb. You have a content service which is talking to a rethink. The B album manager is communicating with my sequel. You have the up loader service resize er service going to an S three bucket, right? All these different parts are talking to each other,
06:05
and what we want to try and do is see how can we minimize these application level insecurities That could happen. So
06:15
these secrets these there's a lot of runtime secrets going on right there. The user manager needs to talk to dynamo Deviant needs to provide good credentials itself to authenticate with dynamodb. Same goes for all the databases. The different services talking to each other should also be performing some
06:30
degree of authentication and authorization to identify who am I and
06:35
and by the person that you should be talking to. Thes are all forms of different sequence secrets, and what you want to be able to do is not only rotate the secrets but individually hand out those secrets
06:48
right? So not everybody is going to be using the same credentials so that let's say, the pages service, For example, when it's talking to the user manager
06:57
service. It is not going to be using the same set of credentials as maybe the proxy is going to use when it's talking to the user managed service similar for content service, album manager and so forth. By having these unique ways of identifying things, if one part of the system gets
07:15
compromised,
07:16
we could just change that secret there. Rotate those credentials on. We don't affect the grander system. It's really about minimizing the disruption, right? And, of course,
07:30
the secrets. When one services authenticating communicating with another service, let's say the album manager is communicating with Thea Plotter.
07:38
The way that it's identifying itself itself should only have limited privileges, right, the principle of least privileges. So album manager may be able to tell upload er to do certain actions that the pages service can't do in this example,
07:55
right? So it's again, we're building security into the design and the way we do things,
08:00
and by limiting the time to live of these different, different secrets that are all being done and having an ongoing rotation process in the event that a secret gets leaked and some bad actor learns okay, I know the user name that the album manager uses,
08:18
and I know the password that he uses when it's communicating with the up loader
08:22
service,
08:24
there's only a certain window of time in which whatever that that person did to get these credentials can actually effectively take any sort of action on.
08:35
And so last but not least, let's talk a little bit more about encryption as a service. So we want to offload burden from developers. Photography is hard going to remove the margin of air, right. We also want to reduce the risk of implementing encryption algorithms incorrectly.
08:50
Uh,
08:52
ideally, we can keep the encryption keys themselves as close to the pocket. It's possible so rather than having symmetric key encryption zor public private key pairs and then handing them off to those different services that then themselves use it, we wanna be ableto store them involved
09:09
and then have vault, retrieve them in memory, performed the appropriate
09:13
calculations to encrypt or decrypt whatever messages and then provide them back. And that reduces an attack vector in the handoff in the management of the keys and the different secrets within the particular services that are now relying on this vaults encryption as a service capabilities
09:33
give you some use cases here of
09:33
this encryption as a service and what it's used for the same. We have a password. It's plain text. We want to make sure that our application uses an H Mac of the password before storing it in the database. So we will never store the plain text version of the password in our underlying user database. So what we can do is
09:52
have our application
09:54
make a call over the vault and say, Here's the plain text. Give me back the H Mac encrypted version off that password itself on, and then I Will it store that actual encrypted password in the database itself.
10:09
There's other sensitive information we want to make. May want to take a very similar approach to, for example, credit card numbers,
10:16
right? So instead of storing the full credit card number and maybe even the cvv codes and other things like that in an unencrypted manner, we want to make sure itself. If you were to get access to the database and you were to look directly at the data stored in that row of that table column
10:33
Ah, you would see nothing but an encrypted value. And then we can create a little mask of source so that we can provide the user and in the user interface, some bearing on. Well, what? What is the value? What is the number of this credit card? This is a very important concept when we're talking about compliance and data storage and encryption of the data.
10:54
So to summarize this video, we dove deeper
10:56
in each of the three pillars of hashtag or vault. We talked about problems of centralized secrets. Storage solves.
11:05
We talked about the power of short lived credentials, the dynamic secrets, especially when we have complex systems that are talking and handing off in authenticating with lots of different moving parts that we went through a few use cases for the encryption as a service capability. So that wraps it up for this model. Look forward to seeing you in the next one
Up Next
Similar Content
