Cloud Security and Compliance Best Practices

WEBVTT
00:00:00.000 --> 00:00:03.140
Welcome to Compliance Pointers, where we take
00:00:03.140 --> 00:00:06.080
an in -depth look into the latest news, trends,
00:00:06.259 --> 00:00:08.919
and challenges surrounding information security,
00:00:09.339 --> 00:00:12.539
privacy, and marketing compliance. Let's dive
00:00:12.539 --> 00:00:16.480
in with your host, Jordan Eisner. All right.
00:00:16.500 --> 00:00:18.820
Here we are, another episode of Compliance Pointers.
00:00:19.359 --> 00:00:22.839
Welcome back to everybody, and welcome back especially
00:00:22.839 --> 00:00:25.820
to you, Alec Harrell. How are you doing, man?
00:00:26.440 --> 00:00:29.230
I'm doing good. Second time on. Second time.
00:00:29.449 --> 00:00:33.369
Okay. Yep. Second time in four years of employment
00:00:33.369 --> 00:00:36.090
as you just shared with me before this Coming
00:00:36.090 --> 00:00:38.289
up on your for your anniversary, but I don't
00:00:38.289 --> 00:00:40.829
think we've been doing the podcast for four years
00:00:40.829 --> 00:00:43.630
Maybe three though. So we're gonna need to keep
00:00:43.630 --> 00:00:49.670
get that rate of Guest appearances on the podcast
00:00:49.670 --> 00:00:54.009
a little higher than you know one every two years
00:00:54.009 --> 00:00:57.789
Sounds good with me. Yeah. Yeah, mainly because
00:00:59.049 --> 00:01:03.469
Like myself you hail from middle, Georgia making
00:01:03.469 --> 00:01:07.250
and I think the world could use more of that.
00:01:07.250 --> 00:01:10.170
Don't you think? I do. I do. Good place to be
00:01:10.170 --> 00:01:12.829
from. I mean, let's see. Who do we share that
00:01:12.829 --> 00:01:16.590
in common with little Richard Otis Redding? Almond
00:01:16.590 --> 00:01:21.030
Brothers Alvin Brothers. Yes, there you go. That's
00:01:21.030 --> 00:01:26.750
about it. As far as I know, yes, Kareem Jackson.
00:01:27.120 --> 00:01:30.900
who played for the Texans and the Broncos. He
00:01:30.900 --> 00:01:34.680
was a pro bowler. Okay. Okay. Yeah. Yeah. I played
00:01:34.680 --> 00:01:37.099
AAU basketball with Kareem Jackson. He went by
00:01:37.099 --> 00:01:42.420
Coco back then. Probably still does, but yeah,
00:01:42.420 --> 00:01:46.019
he played at Westside. Okay. Good basketball
00:01:46.019 --> 00:01:49.439
school. Yeah. Yeah. He was a good basketball
00:01:49.439 --> 00:01:50.980
player, but he's better at football, obviously.
00:01:51.200 --> 00:01:54.439
That's why he played in the NFL. I wonder if
00:01:54.439 --> 00:01:56.870
he would remember me. Probably not. He's probably
00:01:56.870 --> 00:02:04.250
listening. Oh, that's guaranteed. All right.
00:02:04.370 --> 00:02:07.950
Well, today we've got Alec on because he's a
00:02:07.950 --> 00:02:10.030
security consultant on our cybersecurity team
00:02:10.030 --> 00:02:13.009
here. In fact, Alec's worn a few different hats
00:02:13.009 --> 00:02:15.150
at compliance point. He came up on our health
00:02:15.150 --> 00:02:18.469
care group initially working on high trust and
00:02:18.469 --> 00:02:20.789
HIPAA security initiatives and then was poached.
00:02:20.919 --> 00:02:24.539
by our cyber group, started helping support virtual
00:02:24.539 --> 00:02:27.219
CISO engagements and other types of cybersecurity
00:02:27.219 --> 00:02:29.740
security assessments. You started in healthcare
00:02:29.740 --> 00:02:32.560
because you had a past background in healthcare
00:02:32.560 --> 00:02:37.000
and have, dabble is probably not the right word.
00:02:37.240 --> 00:02:39.979
It's much more than that in cloud security. So
00:02:39.979 --> 00:02:43.159
we wanted to talk today about cloud security,
00:02:43.659 --> 00:02:48.930
how a lack. thereof can compromise security initiatives,
00:02:49.430 --> 00:02:51.250
obviously, or security posture, but also compliance
00:02:51.250 --> 00:02:53.870
initiatives around security and privacy. And
00:02:53.870 --> 00:02:55.370
so who better to speak to that than somebody
00:02:55.370 --> 00:02:59.229
that more than dabbles in cloud security has
00:02:59.229 --> 00:03:02.050
worked in frameworks such as high trust or around
00:03:02.050 --> 00:03:04.090
compliance regulations like HIPAA and is actively
00:03:04.090 --> 00:03:06.409
guiding organizations through cybersecurity.
00:03:06.960 --> 00:03:10.039
maturity and posture in that way. So we'll lean
00:03:10.039 --> 00:03:12.659
on you for that and that expertise here. And
00:03:12.659 --> 00:03:14.879
I think we just got a couple quick questions.
00:03:15.240 --> 00:03:17.199
This is meant to be a quick podcast today to
00:03:17.199 --> 00:03:19.800
just talk about cloud security. I think there's
00:03:19.800 --> 00:03:22.379
many depths we could go into, but just a high
00:03:22.379 --> 00:03:26.759
level overview, I would say, of common misconfigurations
00:03:26.759 --> 00:03:30.800
to start. And then how can that jeopardize posture
00:03:30.800 --> 00:03:37.340
and compliance alignment? Yeah. Alec, anything
00:03:37.340 --> 00:03:39.419
you want to add on that or do you want to just
00:03:39.419 --> 00:03:42.060
dive straight into the questions? Let's dive
00:03:42.060 --> 00:03:45.419
in. Okay. So the first one, as I alluded to,
00:03:45.680 --> 00:03:49.699
is what are the most common cloud security misconfigurations
00:03:49.699 --> 00:03:52.699
that you see? And maybe we'll add a why on top
00:03:52.699 --> 00:03:56.539
of that. All right. I would say to start with
00:03:56.539 --> 00:03:59.500
would be publicly accessible storage and really
00:03:59.500 --> 00:04:02.800
inadvertent publicly accessible storage. This
00:04:02.800 --> 00:04:06.449
is when we store data in the cloud, but for whatever
00:04:06.449 --> 00:04:09.110
reason it becomes public inadvertently. This
00:04:09.110 --> 00:04:12.469
could be because DevOps is prioritizing speed
00:04:12.469 --> 00:04:15.969
over security, or this could be some automations
00:04:15.969 --> 00:04:18.069
that we didn't know accidentally make something
00:04:18.069 --> 00:04:23.250
public. That would be the first one. All right.
00:04:23.430 --> 00:04:26.149
That's number two. Number two. Three and four.
00:04:26.269 --> 00:04:28.009
No, I'm just kidding. How many you got there?
00:04:28.689 --> 00:04:31.910
I got three I want to talk about today. The next
00:04:31.910 --> 00:04:34.129
one would be insufficient logging and monitoring.
00:04:34.890 --> 00:04:38.569
Lots of organizations have ways to monitor activity
00:04:38.569 --> 00:04:41.689
in the Cloud, log events and things like that,
00:04:42.069 --> 00:04:45.149
but they're underutilized either because we don't
00:04:45.149 --> 00:04:48.410
have the resources to triage those events or,
00:04:48.750 --> 00:04:50.910
hey, we bought something, we're an enterprise
00:04:50.910 --> 00:04:53.370
organization, we bought it, we secured it, and
00:04:53.370 --> 00:04:56.009
then we never configured it properly. So you
00:04:56.009 --> 00:04:59.209
see that a lot. Then lastly, I would say would
00:04:59.209 --> 00:05:02.610
be authentication weaknesses. So these are going
00:05:02.610 --> 00:05:05.610
to be, wide ranging, but it could be as simple
00:05:05.610 --> 00:05:08.269
as, hey, our password complexity requirements
00:05:08.269 --> 00:05:11.529
are not stringent enough, or we don't use MFA
00:05:11.529 --> 00:05:15.850
everywhere that it's supported, or we have applications
00:05:15.850 --> 00:05:18.949
that don't support MFA, and that still does happen
00:05:18.949 --> 00:05:24.569
here in 2026. Or it could be something more technical
00:05:24.569 --> 00:05:28.110
than that. Maybe we don't do session management
00:05:28.110 --> 00:05:30.769
very well, and so we authenticate in the beginning
00:05:30.769 --> 00:05:34.370
of a session. the time to live doesn't expire
00:05:34.370 --> 00:05:38.949
after somebody logs off or some technical vulnerability
00:05:38.949 --> 00:05:42.310
within the authentication chain. Those would
00:05:42.310 --> 00:05:45.689
be the top three that I see here in consulting
00:05:45.689 --> 00:05:48.670
initiatives, really the biggest one being publicly
00:05:48.670 --> 00:05:53.930
accessible storage. Maybe you said it, but just
00:05:53.930 --> 00:05:57.250
reiterating the event that you did, why do you
00:05:57.250 --> 00:06:01.800
think publicly accessible storage? Is the number
00:06:01.800 --> 00:06:06.899
one issue in such a common issue? Well, because
00:06:06.899 --> 00:06:08.819
there's many ways that it can come about. It
00:06:08.819 --> 00:06:12.060
can be human error, miscellaneous, right? And
00:06:12.060 --> 00:06:13.959
we see that with the Verizon data breach report.
00:06:14.040 --> 00:06:16.920
Every year, misconfigurations and miscellaneous
00:06:16.920 --> 00:06:20.540
issues are within the top two or three. So again,
00:06:20.639 --> 00:06:23.779
it could be an engineer that just accidentally
00:06:23.779 --> 00:06:27.560
made something public or maybe made it public
00:06:27.560 --> 00:06:29.879
during testing, but. never went back and made
00:06:29.879 --> 00:06:32.740
something private. Or it could be technical automation
00:06:32.740 --> 00:06:35.399
that nowadays there's infrastructure as code
00:06:35.399 --> 00:06:37.720
and we can automate a lot of our cloud deployments
00:06:37.720 --> 00:06:40.759
and it gets lost in some of these templates,
00:06:41.139 --> 00:06:43.899
what type of changes maybe we're doing. And so
00:06:43.899 --> 00:06:46.360
again, something becomes public, it's not supposed
00:06:46.360 --> 00:06:51.360
to be public. I see. So one kind of dips into
00:06:51.360 --> 00:06:53.759
two a little bit then, because two, I know you
00:06:53.759 --> 00:06:56.980
said specifically around logging, but you also
00:06:56.980 --> 00:07:00.300
talked more fundamentally about certain capabilities
00:07:00.300 --> 00:07:03.120
within systems or tools or applications that
00:07:03.120 --> 00:07:05.519
these businesses are using, but they're not taking
00:07:05.519 --> 00:07:07.560
advantage of those or they've not configured
00:07:07.560 --> 00:07:10.019
them correctly. And so it seems like that is
00:07:10.019 --> 00:07:11.680
also a little bit of the issue with the public
00:07:11.680 --> 00:07:17.420
facing or access to data from a public standpoint
00:07:17.420 --> 00:07:20.639
where it shouldn't be. Yeah, a lot of this has
00:07:20.639 --> 00:07:23.560
to do with access controls, right? It's data
00:07:23.560 --> 00:07:28.199
and access to systems and services that We maybe
00:07:28.199 --> 00:07:31.220
think we have control over and we have an idea
00:07:31.220 --> 00:07:35.560
of who needs access But the reality is that we
00:07:35.560 --> 00:07:38.839
don't have control over that So yeah, a lot of
00:07:38.839 --> 00:07:41.579
these all three of them I would say have some
00:07:41.579 --> 00:07:44.480
tenant and access control and proper access controls
00:07:44.480 --> 00:07:51.019
so with the authentication and the access control.
00:07:52.459 --> 00:07:56.540
So I think it's common sense, the more sensitive,
00:07:57.560 --> 00:08:01.019
the data that you can access within an organization
00:08:01.019 --> 00:08:04.699
are more confidential, the more authentications,
00:08:04.920 --> 00:08:08.000
not more, but the more scrutiny that there should
00:08:08.000 --> 00:08:10.560
be authentication in place, multi -factor authentication
00:08:10.560 --> 00:08:13.560
around access of that sort of data, logging and
00:08:13.560 --> 00:08:16.740
credentials. What do you do in instances where
00:08:17.050 --> 00:08:20.209
It's not an access control issue, but it's a
00:08:20.209 --> 00:08:22.850
technical issue with application or that's being
00:08:22.850 --> 00:08:25.110
used and it doesn't offer multi -factor authentication.
00:08:25.889 --> 00:08:27.730
What do you tell businesses? Do you accept that
00:08:27.730 --> 00:08:31.649
risk? Is there something you can do technically
00:08:31.649 --> 00:08:34.149
where you can only access it through first doing
00:08:34.149 --> 00:08:36.450
multi -factor authentication and something else
00:08:36.450 --> 00:08:40.309
and then get to it? How's that? Yeah, I would
00:08:40.309 --> 00:08:44.529
say first off, if we can't support multi -factor
00:08:44.529 --> 00:08:48.929
through our own internally implemented application
00:08:48.929 --> 00:08:51.809
or developed application, then trying to use
00:08:51.809 --> 00:08:55.370
a third party identity provider, something like
00:08:55.370 --> 00:08:59.090
an Okta, or being able to tie to Active Directory
00:08:59.090 --> 00:09:01.710
to give us that second factor, even if the way
00:09:01.710 --> 00:09:04.269
that we've developed the application can't support
00:09:04.269 --> 00:09:06.529
multi -factor within the application itself.
00:09:07.370 --> 00:09:11.889
That would be one way to go. But these authentication
00:09:11.889 --> 00:09:15.039
weaknesses that I'm talking about, a lot of them
00:09:15.039 --> 00:09:19.299
have to do with the way that we design authentication.
00:09:20.440 --> 00:09:24.139
Another example might be, yes, we have multi
00:09:24.139 --> 00:09:26.740
-factor. We have a username and password and
00:09:26.740 --> 00:09:30.220
then we have a token right or something that
00:09:30.220 --> 00:09:33.840
is a second factor on our device. But let's say
00:09:33.840 --> 00:09:38.000
our password recovery procedures are not very
00:09:38.000 --> 00:09:40.700
good and so we essentially ask people where they're
00:09:40.700 --> 00:09:44.200
born. And that's a way that you can recover without
00:09:44.200 --> 00:09:46.519
having that second factor that you and I would
00:09:46.519 --> 00:09:48.659
know that we were born in middle Georgia. So
00:09:48.659 --> 00:09:51.779
we would be able to get into the recovery procedure.
00:09:51.779 --> 00:09:54.659
And even though we've implemented MFA, now we
00:09:54.659 --> 00:09:56.919
have a weakness in the chain of authentication.
00:09:58.440 --> 00:10:01.019
Yeah, I'm actually a little bit of a poser in
00:10:01.019 --> 00:10:03.919
that regard, though, because I wasn't born there.
00:10:04.519 --> 00:10:07.779
I was born in Arkansas, of all places, Little
00:10:07.779 --> 00:10:11.289
Rock, Arkansas. And then and then we hopped to
00:10:11.289 --> 00:10:16.850
st. Louis for I Guess several years Didn't come
00:10:16.850 --> 00:10:21.190
to middle, Georgia until 96 So, I don't know
00:10:21.190 --> 00:10:24.590
but it but you know Finished elementary school
00:10:24.590 --> 00:10:26.610
there middle school high school. That's your
00:10:26.610 --> 00:10:29.009
qualifiers where I'm from, right? I think so,
00:10:29.090 --> 00:10:30.830
right? You would have been what seven or eight
00:10:30.830 --> 00:10:34.429
at the time? So yeah, I would I would think so.
00:10:34.870 --> 00:10:40.159
Yeah The roots Yes, I mean, it's certainly not
00:10:40.159 --> 00:10:42.539
Arkansas. I don't think I've been to Arkansas
00:10:42.539 --> 00:10:46.440
since I was, you know, a baby. I would not have
00:10:46.440 --> 00:10:48.379
guessed that. So if I was trying to hack into
00:10:48.379 --> 00:10:51.500
your password recovery, I would not have guessed
00:10:51.500 --> 00:10:56.600
Arkansas or Little Rock. Yeah, Little Rock. OK,
00:10:57.019 --> 00:11:02.840
so you. You tipped into a little bit what we
00:11:02.840 --> 00:11:06.400
would advise around some of those. configurations
00:11:06.400 --> 00:11:08.860
any any other color you want to add on that around
00:11:08.860 --> 00:11:11.980
those three top areas and what we recommend companies
00:11:11.980 --> 00:11:13.960
do first and foremost around those or is it maybe
00:11:13.960 --> 00:11:17.879
not that simple um it's not that simple but i
00:11:17.879 --> 00:11:20.980
really think we should focus on the compliance
00:11:20.980 --> 00:11:24.379
implications of of these right yes yes yes good
00:11:24.379 --> 00:11:27.759
point keep me on track yeah that's your job right
00:11:27.759 --> 00:11:33.419
you're the host but you know A lot of these can
00:11:33.419 --> 00:11:37.259
result in a data breach, whether we've got EPHI
00:11:37.259 --> 00:11:41.039
that is now publicly accessible. And so there's
00:11:41.039 --> 00:11:43.720
a HIPAA violation we're going against, making
00:11:43.720 --> 00:11:47.019
sure that workforce members have appropriate
00:11:47.019 --> 00:11:50.299
access to EPHI. Now that's public, right? So
00:11:50.299 --> 00:11:53.000
that's a reportable breach. There's going to
00:11:53.000 --> 00:11:57.639
be an investigation, potential fines, brand reputational
00:11:57.639 --> 00:12:02.539
damage. Same thing for organizations that have
00:12:02.539 --> 00:12:04.960
to comply with PCI and cardholder data and keeping
00:12:04.960 --> 00:12:07.419
that specific type of data from being publicly
00:12:07.419 --> 00:12:10.000
accessible. Requirement seven and a little bit
00:12:10.000 --> 00:12:14.240
of requirement eight within PCI DSS focuses on
00:12:14.240 --> 00:12:17.679
access control. There's compliance implications
00:12:17.679 --> 00:12:21.039
from a regulatory standpoint if you have that
00:12:21.039 --> 00:12:25.679
type of regulated data. But there's also implications
00:12:25.679 --> 00:12:30.129
on Attestations, accreditations, and assurances
00:12:30.129 --> 00:12:32.830
that you have, and maybe contractual obligations.
00:12:33.509 --> 00:12:35.950
Let's say you're contractually obligated to maintain
00:12:35.950 --> 00:12:39.370
a high -trust certification. Well, making some
00:12:39.370 --> 00:12:43.690
of these cloud misconfigurations happen, or once
00:12:43.690 --> 00:12:46.669
they happen, you can potentially fail an audit,
00:12:46.730 --> 00:12:50.549
and now you're within breach of contract. There's
00:12:50.549 --> 00:12:53.470
wide -ranging, I would say, implications based
00:12:53.470 --> 00:12:56.759
on the type of data. Are you in a regulated industry
00:12:56.759 --> 00:12:59.940
or not? And then what type of contractual obligations
00:12:59.940 --> 00:13:05.580
and compliance certifications do you have? Yeah,
00:13:06.419 --> 00:13:10.659
helpful. So what can businesses do then to ensure
00:13:10.659 --> 00:13:13.480
that they are using cloud services securely?
00:13:14.980 --> 00:13:17.399
The first and foremost thing, and it's not exactly
00:13:17.399 --> 00:13:20.460
cutting edge, but you got to have a set of information
00:13:20.460 --> 00:13:23.440
security policies. You have to inform your workforce
00:13:23.440 --> 00:13:26.299
what management intent for information security
00:13:26.299 --> 00:13:29.539
is and what are the requirements around acceptable
00:13:29.539 --> 00:13:33.659
use of assets, network security, access control,
00:13:34.179 --> 00:13:36.480
third -party risk management, all these types
00:13:36.480 --> 00:13:38.580
of things. Without policies, we can't hold the
00:13:38.580 --> 00:13:42.820
workforce accountable. We can't comply with some
00:13:42.820 --> 00:13:46.559
of these compliance regulations. Really, the
00:13:46.559 --> 00:13:48.240
second part of that is making sure that your
00:13:48.240 --> 00:13:51.850
policies Align to the framework or regulation
00:13:51.850 --> 00:13:55.649
that affects your organization. So if you're
00:13:55.649 --> 00:13:58.649
an ISO shop, you need to have policies that reflect
00:13:58.649 --> 00:14:03.509
the ISO controls, whether it be 27 ,001 or whatever,
00:14:03.629 --> 00:14:05.590
but you need to make sure that those controls
00:14:05.590 --> 00:14:07.990
are present in your policies and the workforce
00:14:07.990 --> 00:14:12.070
knows how they apply to certain topics. Again,
00:14:12.370 --> 00:14:15.509
acceptable use, network security, things of that
00:14:15.509 --> 00:14:20.129
nature. And then I would say, understanding the
00:14:20.129 --> 00:14:23.409
shared responsibility model or matrix for the
00:14:23.409 --> 00:14:27.169
cloud service provider, this often gets lost
00:14:27.169 --> 00:14:30.429
because we think, oh, well, that's AWS' problem
00:14:30.429 --> 00:14:33.110
or that's Microsoft's problem. But generally
00:14:33.110 --> 00:14:37.029
speaking, AWS, Microsoft, Google Cloud, they're
00:14:37.029 --> 00:14:39.289
going to be responsible for the security of the
00:14:39.289 --> 00:14:41.309
cloud, and you're going to be responsible for
00:14:41.309 --> 00:14:43.769
security in the cloud. What data do you put in
00:14:43.769 --> 00:14:47.299
the cloud? Who do you give access to? certain
00:14:47.299 --> 00:14:49.919
types of services and data. So understanding
00:14:49.919 --> 00:14:52.539
that and how it affects the services within the
00:14:52.539 --> 00:14:57.000
cloud provider that you use is very big. Again,
00:14:57.000 --> 00:15:00.000
not cutting edge, but a lot of organizations
00:15:00.000 --> 00:15:03.840
fall flat in this area. Yeah, I was watching
00:15:03.840 --> 00:15:07.580
actually. I see so I know is on a podcast and
00:15:07.580 --> 00:15:09.679
I just saw clipped on LinkedIn and he was talking
00:15:09.679 --> 00:15:13.460
about. How he's built a security program from
00:15:13.460 --> 00:15:19.279
scratch. And he's inherited one. and improved
00:15:19.279 --> 00:15:24.460
it. He said building from scratch was easier,
00:15:25.379 --> 00:15:29.159
but what he really learned from it was you can't
00:15:29.159 --> 00:15:32.580
do it fast. What he meant by that was you have
00:15:32.580 --> 00:15:35.559
to ensure alignment with the business, and business
00:15:35.559 --> 00:15:38.559
objectives, and awareness, and training, and
00:15:38.559 --> 00:15:42.600
basically, A cohesive understanding like why
00:15:42.600 --> 00:15:44.259
we're doing this. So you get the buy in around
00:15:44.259 --> 00:15:46.179
the controls and the system and the setup and
00:15:46.179 --> 00:15:48.240
you're sure right configuration things are right
00:15:48.240 --> 00:15:52.139
in line with the goal. Otherwise, you don't get
00:15:52.139 --> 00:15:54.259
the adoption you need. You don't get the control
00:15:54.259 --> 00:15:58.700
owners. Supporting the initiative and that contaminant.
00:15:58.740 --> 00:16:00.940
So I think that's the fundamental thing there
00:16:00.940 --> 00:16:03.899
that you kind of. Covered and then gave more
00:16:03.899 --> 00:16:07.360
specifics. Yeah, this must have been a pretty
00:16:07.360 --> 00:16:10.480
smart CISO because yeah, if you don't have adoption,
00:16:10.480 --> 00:16:13.559
if you don't publish your requirements, if you
00:16:13.559 --> 00:16:16.080
don't have buy -in, it's not going to be done.
00:16:16.080 --> 00:16:18.799
It's going to be met with resistance. And you're
00:16:18.799 --> 00:16:20.960
right, security is designed to help the business
00:16:20.960 --> 00:16:24.279
function, reduce risk while helping the business
00:16:24.279 --> 00:16:27.240
function. It's no different than, you know, sales
00:16:27.240 --> 00:16:31.019
or HR. If these types of departments are adversarial
00:16:31.019 --> 00:16:33.480
in nature, then you're not going to get adoption.
00:16:33.600 --> 00:16:36.100
You're not going to get buy -in. Ultimately,
00:16:36.259 --> 00:16:38.360
the business is going to suffer because of that.
00:16:39.360 --> 00:16:42.120
There you go. I think it's a good part to end
00:16:42.120 --> 00:16:44.919
on. Well put, Alec. Thanks for joining us again.
00:16:45.039 --> 00:16:49.399
We'll get you on once more sometime before two
00:16:49.399 --> 00:16:52.919
years from now. Okay. Yeah. Sounds good to me.
00:16:53.500 --> 00:16:55.460
All right, man. Stay safe out there in Texas.
00:16:55.799 --> 00:16:59.940
Glad that the ice has cleared up. And for all
00:16:59.940 --> 00:17:02.120
the listeners, thank you again for tuning in.
00:17:02.539 --> 00:17:04.400
If you want more information like this, make
00:17:04.400 --> 00:17:06.880
sure you subscribe to Compliance Pointers, sponsored
00:17:06.880 --> 00:17:10.299
by Compliance Point. And if you have questions
00:17:10.299 --> 00:17:12.660
about what we covered today or anything in the
00:17:12.660 --> 00:17:14.660
information security, privacy, or compliance
00:17:14.660 --> 00:17:17.500
realm, please don't hesitate to reach out. You
00:17:17.500 --> 00:17:19.940
can find us at CompliancePoint .com, or you can
00:17:19.940 --> 00:17:22.119
email us directly at ConnectedCompliancePoint
00:17:22.119 --> 00:17:24.319
.com. Until next time, thanks everybody.