Demystifying Cloud Security Compliance Webinar with Transcript, Deck & Links

With security on everyone's mind, we wanted to bring you this webinar, "Demystifying Cloud Security Compliance", which Bryan Langston, Director of Architecture and Jason James, Director of Security provided earlier this year. Please enjoy the video or read the transcript below, and let us know how we can help!

Cloud Security Compliance Presenters

Bryan Langston - Director of Architecture

Bryan leads the global architecture practice at Mirantis. He and his team consult with companies of all sizes across all industries to design world-class open cloud solutions.

Jason James - Director of Security

Jason has worked in the information security realm for over 20 years. His professional background has ranged from Military to the commercial realm as a Global CISO. He has focused in the GRC areas for most of career, helping companies become and stay compliant.

Agenda

• Navigating a Cloud Security Program
• Security Tools Selection
• File Integrity Monitoring
• Security Baseline
• Elevated Privilege Management
• Event Auditing

Download the Webinar Deck

In the deck you'll get cloud security programs, strategies for file integrity monitoring, cloud security baselines, and more!

Webinar Transcript

Nick:

All right. Good morning. Good afternoon. Good evening, wherever you are. I am Nick from Mirantis. And I want to welcome you to today's webinar Demystifying Cloud Security Compliance. This is a topic that is certainly not light. But fortunately, we have some experts with us today to help us out. Bryan Langston and Jason James, I'm going to ask them to give us a quick one sentence introduction, Bryan, tell us about yourself.

Bryan Langston:

Hi, I'm Bryan Langston. I'm the Director of Architecture within Mirantis’ Professional Services Group. My team works with customers across various industries, designing cloud solutions on prem.

Nick:

Right. Awesome. Thank you. And Jason,

Jason James:

Hi everyone. I'm Jason James, I'm Director of Security for the Professional Services Group. I work closely with Product and Bryan Langston's team.

Nick:

All right, awesome. Let us quickly just kind of go over, Bryan, you want to give us a quick overview of what we're going to talk about?

Bryan Langston:

Sure, yeah, there's several things we want to cover focused around this idea of demystifying cloud compliance. We will talk about the kind of a general framework of an approach that's worked for us and works for many of our customers. We'll talk about some approaches to tool selection. And then we'll use four examples with file integrity management, sorry, monitoring, security, baseline, elevated privilege management and event auditing to kind of prove and illustrate the points that we'll make from the first two bullets.

Nick:

And this is a this is a vendor neutral thing that we're talking about. It's not like, Oh, this is you know, what Mirantis does for you?

Bryan:

This is right, correct. Yeah, yeah, based on real life pain points from many of our customers and kind of lessons learned and observed. And so yeah, there should be something that everybody can get new out of this.

Nick:

Timestamp - 02:17

Okay. So, before we get started, we just kind of want to get sort of a level set on where everybody is. So I'm just going to, we want to do a quick poll here. So the question is, “What are your plans for deploying on premise cloud,” so if you can go ahead and just kind of give us a sense of where you are. That will give us a feel for where we need to go. So we'll just give it about 30 more seconds. See, the responses are starting to come in. In general, looks like you guys have already implemented on premise infrastructure, or are in the process of implementing. Give it a few more seconds. Okay. All right.

Basically looks like half of you or either implementing or are already in production. And very small percentage, only 17% of you have no plans right now. So just about everybody in this boat, which is what we need to know. All right. So moving along. Bryan, I'm gonna ask you to just kind of take us through this. Okay, take it away.

Bryan:

Timestamp - 04:06

All right, thanks. Go to our first slide here, Navigating a Cloud Security Program. So kind of picking up from where the poll data is telling us. One thing that we've seen within branches over the past several years is on prem solutions. Typically follow in kind of a pattern of kicking tires and seeing if various solutions are, are right for you. There's, this initiative of after you've after you've demonstrated that a certain solution, whether it's a platform like OpenStack or Kubernetes, you move into some PoC mode, you validate that you're on the right track with your strategy things are working out. As some of you have indicated, you now have production workloads on your on prem cloud. It's at that point where security starts to become, if it wasn't already, a kind of leading or guiding principle, it becomes one, you now have other stakeholders that have a vested interest in what you're doing on that cloud. And, again, if you weren't already guided towards a specific security framework, you might be asked to, you might be given a specific framework to align with. Some of that guidance is provided some of it's not.

People find themselves in different phases of this, this deployment process, and eventually come up with a challenge of what do I do? How do I think about security? And how do I demonstrate compliance? What we wanted to do with this first set of messages is outline five points that can help frame your thinking about a cloud security program. So that your performance within the program is more effective, and more timewise. So the first point we want to make is aligning with a framework.

You probably all heard of various frameworks. You know, GDPR has been in the news a lot PCI for financial services, FedRAMP for government, government programs, there's a bunch of them. HIPAA, there's many. So one, one thing obviously to do is figure out what framework that you need to align with. And once you do that, one thing that is very helpful to understand is the objective of an auditor. At some point, whether it's an internal audit, or an external audit, someone's going to ask to review what your security program is, and what procedures and tools that you've implemented. Understanding how that auditor comes in, can help minimize a lot of wasted effort, panicking about things that don't matter a whole lot.

If you think about what this picture conveys here, there's construction going on, there's an auditor, an auditor has a checklist, and an auditor looks for evidence of compliance, they really don't care. If you framed a wall with a certain brand or type of saw, they really don't care whether you hit the nail four times, or five times or with a pneumatic, right, they just don't care. They just look for evidence of compliance. So given that they don't come in with a prescribed set of tools to look for. You don't need to bother so much as to which tool because honestly, you might be in the situation where an auditor comes to you, and they say, “All right, tell me how you're satisfying. Control X.” And you mentioned, it's through the use of tool, Y they may or may not have even heard of that tool? And if they haven't heard of it, that's totally okay. Because all they're interested in is if you can you show me evidence of your performance, your execution, your use of that tool, in the satisfying of this control. That can really help eliminate a lot of excess research, it can help eliminate some worry, just by understanding how that how an audit is going to work. Once you understand that, then you can shift to understanding what the burden of proof is for each control. And this can still be a little bit difficult.

Timestamp - 09:09

Depending on where you are in your awareness, and expertise of security, many people we talked to that are very smart technically look at look at the language within security frameworks and really struggle to interpret what does that really asking me? What does that requiring me to do? Is it some really huge initiative that requires a lot of time and effort? Or is it much simpler? So understanding the language to understand what the burden of proof is reach control is extremely helpful. And there are some keywords that are commonly found throughout security frameworks that can help that process. We'll get into some of those a little later.

Distinguishing Cloud Security Policies, from Process and Technologies

Related to that idea is point number four distinguishing policy, from process from technology. A policy is basically an assertion of what you will be delivering, what you will be accomplishing what you will be controlling. And that's different from a process or a procedure, which is intended to give you a chance to outline specifically the how you execute or carry out your policy. Some of the language will point to a technology. And there's certain keywords that can help identify when a technology is being referred to or suggested, versus just a policy or procedure. Those three things, knowing how to filter, a control, a control specification, the language, can really help you narrow down to what the deliverable is.

Then finally, once you have kind of your controls, kind of filtered into these three buckets, it's much easier to complete a RACI (Responsible, Accountable, Consulted, Informed) model, a model that represents who is responsible, who's accountable, who is consulted, who is informed. The responsibility for delivering a policy might be different from the person responsible for delivering the procedure. And that might be different from the person or group that is responsible for the selection of a tool, the architecture of it, the implementation of it, the support of it, there's a lot of different roles and responsibilities and having a well-defined RACI model is invaluable. When there's a security incident, that happens that needs triage and needs forensic analysis. That time is passed where you figure out, who do I talk to? Where do I go? You know, who owns this.

Those five things really form a kind of a framework for thinking about cloud compliance. And again, kind of following those five is helpful to demystifying cloud compliance. So Nick, if we can go to the next slide, we can talk a little bit about tools.

Tool Section Process for Cloud Compliance

Timestamp - 12:23

A common question that we get as we consult with customers around the world in different industries, is, what's the right tool? We consult with the open-source tools we integrate with third party tools, we do integration with homegrown tools. A lot of customers talk to us and they say, “Well, which one should I use? Is there a better one? Which is the right one?” So the answer to all those is really yes. Is open-source the right one? Yes. Is the third party the right one? Yes. So as homegrown, the key thing to remember is that the security framework that you're aligning with doesn't prescribe a tool, you will not find it in that language, it just defines a rule or requirement at a really high level. And how that tool how sorry, how that rule gets implemented, and eventually proven in an audit, that's, it's all up to you. So if there was, if there was supposed to be a more specific criteria in how you select tools, there would be more specific language in the control specs, which there aren't. So the right answer is whichever one works for you. Whatever you have skills for, whatever you have budget for, whatever you understand the best, maybe what you've used in the past. Those are all valid means of justifying what the tool is.

The key, again, coming back to this audit scenario is if you can show that you use that tool that you have selected consistently, to satisfy the control spec, you've got, you know, the peace of mind that you need going into an audit. And that's what you need for good to go.

File Integrity Monitoring

So the next four slides is really what we wanted to use to walk through some of these principles that I've just outlined. One thing that we have found, I mentioned that there's a number of security frameworks that are candidates for implementation in your environments. There's a lot of common language and if it's not common language, that principles the concepts that the language represents are similar. For those that may not have heard of the Cloud Security Alliance (CSA), this is a group that has created the Cloud Controls Matrix (CCM). The Cloud Controls Matrix is a group of security categories and control IDs that have a control spec. And the nice thing about the I'll just refer to it going forward here is the CCM. The nice thing about the CCM is that it's more human readable. It's much more consumable, digestible, understandable than just going into, say, a NIST (National Institute of Standards and Technology) control, or PCI control and going What is this really saying? The CCM, because of it being security related, it's a, it's a cloud, like I said, the CSA Cloud Security Alliance, it's cloud focused. So when we're talking about addressing cloud security, this is a little bit more specific to a cloud use case, which should help you know that part too.

Timestamp - 16:02

You'll find that CCM controls map very well to your nests, and PCIS, and GDP RS and every control every framework that you might need to be concerned with for your own environment. And because there is that clean mapping, if you can satisfy your solution, your procedures, policies, to a CCM matrix, you'll find that you're also satisfying the underlying NIST controls to which this CCM controls map. And that's a pretty neat, handy relationship.

So the first one I want to cover here is file integrity monitoring. You won't find file integrity monitoring language in any of these security frameworks, but it's a concept that's implied due to some of the language. What is file integrity monitoring? It's, you know, this is my definition, it's the activity associated with monitoring changes in an operating system or application software, from unknown baseline. So if you look at the CCM control spec, for AIS, AIS is Application and Interface Security is the fourth ID within that control category. This control says this detects that you have and I won't read it. But I do want to pull out certain keywords, that should trigger your thinking as to how you would come up with file integrity monitoring based on looking at this spec.

If you look at the word confidentiality, this suggests limiting access, right? It's locking a file or directory down its permissions. The next word is integrity. Integrity is about maintaining consistency in IT, staying true to form. If you look at availability, can you make it available, whatever resource if it were to go away, to make something available, you obviously have to know what's missing. And then prevent, this implies some kind of enforcement mechanism or tool. So this would be a trigger that this is not going to be just a process, but involve in some way, a tool in proper disclosure. That would again, refer to the idea of permissions.

Alteration, that's an easy one, it's changed, right? It's something changed, what changed when, by whom? And then destruction? Is something deleted, was something deleted, is a service degraded, has it been discontinued? Right. So these are all kind of the, the conditions, the parameters within which you would say, all right, how do I, you know, what is this all pointing me towards? And you'll notice at the very beginning of this control spec, policies and procedures, so again, that's where you have to declare what policy you are enforcing. And in writing a policy could literally be something as simple as rewarding the policy that you see here on the screen, you might say my company shall establish and maintain, and blah, blah, blah, and finished off the rest. And that's your policy, right? Your procedure would be the steps that you take to implement that policy. And you might point in your procedure, the use of a certain tool. And some of these tools are what you see on the screen here.

Tools for File Integrity Monitoring

Timestamp - 19:35

And there's a lot there's really many, many tools that satisfy this idea of file integrity monitoring. AuditD, and rules are one way to use native Linux tools. You can build some custom rules that monitor the right resources to satisfy this requirement. Wazuh for those that may not be familiar, is really neat Open Source security platform that has a lot of neat integrations and features, file integrity monitoring is one of them. A lot of our customers, you use CloudPassage, another great tool, very comprehensive, robust, it's got a lot of features in it.

But it doesn't have to be a very complex robust tool, they can literally be something as simple as using AuditD and rules. And that's why I put this spectrum in here. You know, how complex you get is all up to you, right? As long as you can defend your selection of that tool and show that you use it consistently that's really all that matters. You might discover later on that you need to be a little more robust in how you're doing file integrity monitoring, but there's nothing wrong with using something as simple or simple as AuditD and some rules.

So I listed some rules here just to kind of seed some thinking for those that may not be familiar with, with the concept of file integrity monitoring. Again, there are many, many, many things to monitor, obviously, some critical system files, system directories, configs, for sudo (superuser do), for SSH, lots of things. And anyway, so that's file integrity monitoring.

Security Baselines for Cloud Governance

So the next slide, please. So security baselines is another critical one, there are probably over 30, I think, NIST controls if you're familiar with NIST, that all mentioned, configuration, in some form. Security baseline, the concept of it is very common. My definition, again, of a security baseline is simply you know, it's a defined configuration state. So, having a well-defined configuration management policy, and the corresponding procedures and, and tools satisfies a lot of other controls, if you can define your configuration management implementation, it's easy enough to just point to it as you get to a control spec, like the one here that I'm referring to, in CCM that covers governance and risk management, or GRM1.

In this one, and again, I'm just going to highlight some of the key words, baseline security requirements shall be established. So basically, you've got to have some rules that govern how you establish and maintain a security baseline. And there's lots of ways to do this, as there are with, with most things and security. We'll talk about a few of these in a second. But the key point here, second key point to pull out of this control is deviations from the baseline must follow change management. And it's pretty straightforward.

Third key point is to reassess compliance, at least annually. You'll find some language and control and security frameworks rather that sometimes specify a frequency. Sometimes they don't, sometimes they just say regularly, I would highly recommend a baseline security review a lot more than just annually, for a lot of reasons. So like I mentioned, there's a lot of ways to establish a security baseline. Again, kind of the, the simplest form might be in the way of writing custom scripts, creating some automation. If your infrastructure is defined in code that's sitting in, say, a Git repo, you might say, Alright, I can intelligently parse that code and extract the settings that go into my cloud deployment. And that's true. Nothing wrong with that, you can set up a process that tracks and manages changes against that baseline. And that would be sufficient.

Timestamp - 24:07

CIS benchmarks is another way. For those that aren't aware of what cis is. CIS stands for the Center for Internet Security. This is a group that maintains literally dozens, I think over 140 or so benchmarks. I found that they don't, the CIS doesn't have a benchmark for everything that goes into a cloud deployment. But they do cover quite a bit, and there's some really big hitters that are covered in CIS.

For example, if you take the Linux benchmark from CIS, there's, again my work account is up to you but a couple hundred checks in there. But these benchmarks are basically best practices defined by a global community of industry experts. These people might be Ceph experts, they might be Kubernetes containers, experts. Sometimes they're companies, there's all different ways of contributing these benchmarks. So if you take a Linux benchmark, from CIS, for example, and you assess your environment against that benchmark that can become your baseline, right? Of 200, you know, benchmarks or checks in the Linux CIS benchmark, how do I stack up? Am I 50%, you know, compliant or aligned? Whatever you are, you might make a statement along the lines, you know, for your environment of, we're 65% compliant with the Linux benchmark. And from there, you could make incremental changes over time to your platform configuration, following your already documented change management process. So that would be one implementation, one way of demonstrating that you are creating that baseline and, and then doing something with it taking action on it.

Timestamp - 26:00

Another way to use CIS benchmarks is through the use of some open-source tools like open SCAP, and the XML based document formats referred to as oval Linux CCBS. These are both XML based formats that help you define what that target state is that you desire. And those documents can be run within the engine that you get with open SCAP. And that can create a very effective way of automating your baseline analysis.

So a best practice that we have seen very effective is just to make a goal of continuous improvement, find some regularity in how you run, how frequently you run these benchmarks, as long as you've got a team that can take action on the outputs. That's key. So several tools for doing security baselines.

Elevated Privilege Management

Next slide, please, Nick. So the next one we want to cover is elevated privilege management. And again, you won't see those three words verbatim in security frameworks, you will see concepts referred to this idea. Again, my definition of it is, “Authentication and tracking use of root permissions.” Basically, there's a little more to that. But at a high level, that's kind of what's implied here.

Timestamp - 27:35

There's a CCM control spec for IVS. It's a mouthful. It's a big control category. But I'll just call it IVS-01 for short. And again, extracting keywords, you need a log management solution. That's pretty clear, unique use, sorry, unique user access accountability, you got to have some way of knowing who's doing what. You'll notice that file integrity is mentioned. So this is just an example of how the FIM solution that I described earlier can be a complement to this concept of elevated privilege management. So you can point to that solution. And say, you know, “we're doing file integrity using FIM.” Done, check. You move on support forensic investigative capabilities, that's a pretty serious requirement. And clearly, this is an area where tool selection is needed. And that'll give you varying levels of effectiveness in supporting forensic analysis. Obviously, not all tools are created equally. Some are going to struggle supporting decent forensic analysis, and others are going to do a really good job of it.

Some companies that we've seen have gotten really creative in the way that that they use monitoring agents and log monitoring to satisfy this control. It's kind of a low effort, low cost, low R&D kind of a thing. Well, to some degree, I shouldn't say low R&D, because there's a lot of overhead that comes with writing your own tooling. But it can be simple. We've seen some pretty simple implementations using open-source tools, combined with some homegrown scripts. But aside from a homegrown plus open-source tool, there's obviously quite a few third-party tools that can satisfy this.

BeyondTrust is a company that's got one. their product is called Endpoint Privilege Management for Unix and Linux. That's a mouthful. But the idea behind that tool, for those that aren't aware already, is to have total visibility to who's doing what across all the nodes in your cloud environment. As you log in and hop around from host to host your command history is known and it's aggregated to make auditing easier. So it's a really cool tool. Guess another point I’ll make about BeyondTrust is they support the idea of integrating with corporate LDAP. And they support two factor authentication, which are another good check marks to check off on your security compliance checklist. So that's elevated privilege management. Really neat tools that can deliver to that control.

Event and Compliance Auditing

And then next slide, Nick will talk about event auditing. And for this use case, I'm going to use an OpenStack environment as the example for the tool. But event auditing is basically addressing the seven W's of audit and compliance which you can read what those what those are. Again, if I look at the CCM control spec, for DSI-01, it's a pretty short and sweet control that just says that, you've got to have a classification for data and objects containing data. Pretty simple.

Timestamp - 31:09

Now, the value that an organization has on data is going to differ from industry to industry and company to company, which is why it doesn't really prescribe anything more specific than this. So again, if I use an OpenStack environment, and I think of data and objects, that context right there might or should trigger the thinking around, “how do I know who is creating OpenStack objects in my cloud?” This could be the same for Kubernetes could be same for containers, right? “How are things being orchestrated, who's orchestrating that? Where's it going?” Those kinds of things.

The idea here is, is to have auditing for events and have a means of classifying the data. The classification of OpenStack data can point to a tool like CADF (Cloud Audit Data Framework). CADF is the cloud audit data framework. It's an open framework that allows for complete visibility to how OpenStack objects are created. So one thing to note here is that this particular control DSI-01, it just mentioned, the need to assign a classification doesn't say anything more is needed, it doesn't suggest that CADF is needed. But, again, because of the CADF tool, if you knew what the CADF tool was, without looking at this control spec, you might be able to kind of take this solution and kind of find the problem. What can I see value in the CADF tool, What problem? Could I solve with this that's related to security. And I'm just proposing, advocating that DSI-01 is a good match. So that's the fourth of the four tools that we wanted to cover, using, again, this process of looking at keywords in generally vague, ambiguous control language, and using those keywords to come up with a proposal of tools and processes that support them.

Summary of Cloud Security Compliance

Timestamp - 33:43

And Nick, if you can go to the next slide. To summarize here, we started off this conversation with this idea that the CSA cloud control matrix helps humanize security language, you can download a copy of it, you can see what those categories are, you can see what the control IDs are, and what the language is. Compare that to NIST, or PCI. And you'll, you'll see what I mean, it's, it's, it's a lot easier to understand. And once you understand that, you know, interpret those controls to your use case, if you look at how financial services is going to look at a control, compared to, you know, pharmaceutical, there's going to be some similarities, but there's also going to be some differences and someone's preference for tool selection is going to, you know, guide them towards maybe a different, different tool that has a different level of complexity and cost. But to the bullet point, you know, the third bullet point here, just implement tools that you can defend. You need peace of mind that you can sit in an audit in front of an auditor. When they ask you, how are you satisfying Ctrl x you can just say I'm using this tool. Here's my processes. The auditor will say great, show me evidence that you last ran this certain tool or shall we how you can find data using this tool. And as long as you can prove that you're golden, just document that process and maintain evidence of that process performance.

Questions and Answers for Demystifying Cloud Security Compliance

Nick:

All right, so now is your chance if you have not yet dropped a question in the questions pane. Now is the time. So let's go ahead and see what we have in terms of questions.

Question 1 - You said you would recommend running a baseline check more frequently than annually, how frequently would you recommend?

Yeah, so for me, like I said, being a global CSO in our past and also auditor, I recommend two things, one I recommended from a quarterly aspect. But then again, what I also recommend is that you look at it of how much change management that you're doing, and how much of that change management updating concept you have, is actually impacting the systems and can cause a vulnerability or a gap in your security aspects. So minimum, for me has always been once a quarter. But like I said, if I've got a project or a program that has come up, and I feel that it's caused, or going to cause me an issue, then I'll go ahead and actually run it sooner.

Question 2 - What is a good security framework to start with?

Jason:

Well, you know, my opinion is what I look at when it comes to food security framework is a couple things. What I look at is understood, you know, the first thing that you should do is understand the business, right? Where your company, how they work, what the goal is, and things of that concept, okay? Because the more you understand your business, the more you can understand how to secure your business, right. So that's what I always look at, because there's so many frameworks out there, that's where a basic start is. From that point, I would say, from that point, I would say, you know, CSA, the Cloud Security Alliance is a really good framework, I like it. Because it takes a lot of the great it takes NIST and PCI, and HIPAA, and it takes a lot of them. And it kind of puts them all together in one package for you. And it also kind of helps keep it very simplistic, right? Because it helps break it down a little bit into layman's terms when it comes to the IDs and stuff like that compared to if you just jumped straight into like NIST or PCI or something like that, right? So that I would say CSA. Cloud Security Alliance, CCM is a good place to start.

Timestamp - 38:25

Bryan:

Excellent. Yeah. And one thing I'll add as, as I've thought of the same question, what you shouldn't assume about the CCM is that you don't if you do CCM, you don't have to do NIST, right. There's not a it's not a I'm doing CCM, and I'm off the hook for these other frameworks. The CCM is kind of like and I just kind of thought it was a minute ago. It's kind of like an API abstraction of these other frameworks, right? If you can deliver to the language in CCM, just know again, like I've said before, that delivering to that to that CCM spec has mappings to these other controls. By delivering on CCM, you're inherently delivering NIST. If your requirement from your security organization in your company is NIST, there's nothing wrong with using CCM as a kind of that abstraction. And then just knowing what controls a NIST that those that obstruction satisfies.

Question 3 - Where can we get the list of standard compliance controls to measure against like the CCM control spec, IVS-01?

Bryan:

Yeah, yeah, that's it. There's a website for that. We can send that, let me see if we can just provide that.

Jason:

Yeah, just real quick what Bryan's pulling that up. So when it comes to the compliance concept for CCM, NIST, or any of them, you know, they offer a lot of great template packages, the actual, you know, organizations themselves, and we can obviously provide links and help you. But like said, CCA, has a great template package for comparison charts that their chart shows, the CCA and then it shows how that control might maps back to NIST and COBIT and HIPAA and the different concepts, right, so they have a good chart, and things like that. PCIM does that also, just, you know, for a high level answer. But like I said, Bryan can, you know, we can also provide some links for that make it easy for you

Bryan:

go to CloudSecurityAlliance.org. From there, you can download the fact that I'm at their website right now. And you'll see the Cloud Controls Matrix listed there referenced there that you can download.

Cloud Controls Matrix (CCM) Version 4

Question 4 - My company has an audit coming up any advice on how to prepare and what to expect?

Timestamp - 41:18

Yeah, so the big thing to do to prepare for an audit, you know, a lot of times is try to have an, try to have an internal meeting with the teams, that you have your network team, your infrastructure, different ones, and you kind of go over, you know, your internal compliance level. Because you should have done an internal gap and different things for your own, you know, compliance, right, of where you stand. So what I always tell my teams is to have a meeting, let's all review the internal gaps and where we stand, let's make sure that we're lining it with any risk and anything that's coming up with GRC (Governance, Risk Management and Compliance). So that way, when the auditor comes up, we'd have a great, you know, answer a feedback for them. So, if there is something we may great, here's how we made it, here's the policy, here's how we handle that. If we do not meet it, we can address it, right, like so we don't ever want to give too much information. But if it is asked, we can address it that way. And if we have a good communication within our teams, we're all on the same concept when it comes to that kind of conversation with an auditor because they will go to different team members. And you want to make sure you're on the same page.

Nick:

And you just said something that seems to be very good advice, which is basically don't give too much information if they don't ask you. Don't tell them.

Bryan:

Yeah, yeah, don’t send your chattiest team member.

Jason:

Yeah, I hate to put it exactly like that. But when I've been an auditor myself, you definitely want to treat it somewhat like a polygraph, which just yes or no answers. And then, you know, and then let them ask you the questions, never divulge too much. Let them ask you the question. A good thing to do that I've done is when they ask you a question repeated it to make sure you understand exactly what their question is. So you can provide exactly that information. And then that way, you're just not opening up too much for yourself.

Nick:

Right. And, you know, we're not, we're not telling anyone to, you know, deceive the auditor in any way or to hide anything. But you know, it can get confusing. If you start, you know, like you say, opening up boxes that don't mean to.

Jason:

Yeah, I mean, you're definitely you're not trying to hide, there's no, I mean, there's no reason to hide anything from an auditor. And most auditors. Like I said, even if you don't have like, let's say there's a compliance that you need to meet, but you don't meet it. A lot of times, I mean, they will sit down with you, and they will just discuss it. Like, “why can't you meet it? Is it a process? Is it something in your product? Or why can't you?” and they’ll make a note of it. Because an audit sometimes is a pass or fail concept, but there's a calculation behind it to, you know, to address everything, so you can still pass it with a bunch of no’s if the whole picture is right. So you want to you want to look at the whole picture of an audit, not just yes or no single and try to stay hidden in a little room.

Question 5 - Would auditors ever help you by telling you that you didn't meet this, that or another thing, and this is what you need to do?

Jason:

Well, depends on the auditor. But yes, I mean, I've had auditors come back and said, “Hey, you didn't meet this, you know, you didn't meet this. And maybe this is the way to address it. Or you might want to look at this industry standard, a best standard or something.” A lot of times it depends on who's doing your audit. Like if you're, you know, if it's obviously if it's an internal audit, they'll probably help you more. If it's one of the big four audit companies they might also help you because what some audit companies do is they also audit you, but then they also give you a checklist of how their companies can help you fix those deficiencies. Right. So, you know, it depends on the type of company that's doing your audit and what the audits for. But yeah, I've definitely had companies go back with a checklist going, “Hey, by the way, here's how we can help you fix those.”

Question 6 - What are some common stumbling blocks for an audit and compliance?

Timestamp - 45:33

Well, the biggest the biggest stumbling blocks is honestly what Bryan addressed in the presentation just now is that the stumbling blocks a lot is interpretation. Right, you got to understand when you read these policies, you know, they're very vague, the way they're wrote, some of them are even high level and very detailed, and you're really more confused. So the stumbling block a lot of time is just taking, you know, taking a step back, and then just trying to decipher the policy.

Right. You know, the compliance itself, because, you know, there's obviously an answer for it somewhere, you know, whether it's working with somebody Google, you know, there's, there's an answer for it. But that's what I've found is a lot of stumbling blocks is, you know, I'll hand a new compliance to, you know, a team, and they look at me, like, I just hit him, you know, in the face or something. And I'm like, well, “you need to read through it, and then we can talk about it”, you know, let's understand what they're asking, let's try to break down the secret code of if it's a policy, or if it's a product, you know, idea and things like that. So that's always been my biggest stumbling block is just, like, like I said, what Bryan just really covered was the implement, you know, how do you interpret what they're saying?

Bryan:

One thing I would add to that is sometimes, I mean, I've seen this case where an organization is asked for evidence of compliance to certain control. And the responses here, here's, here's the tool that I use, and they go “Great, show me the logs, show me, you know, when it was last run”, and then you get the deer in the headlights look. If you're going to have a tool. That's why we've mentioned this at the beginning of the presentation, if you're going to have the tool, you've got to show evidence of performance. You can't, you know, get caught. It's not a victory, just to say I have a tool, you got to have the performance of it.

Jason:

Yeah. Oh, I love it even more to that for Bryan, is that is part of an audit sometimes, like, you know, when you go in, and they might do a checkbox, when do you have a SIEM solution (Security information and event management)? Well, yes, we do. Okay, how can you check the logs? Let me see, let me see an example of the logs. Let me see your process, right. Same as incident response, you have an incident? Okay. Well, you have a policy we do? Well, let's talk about just briefly about how do you have, you know, what is your process? How do you handle like, oh, okay, you know, so there is pieces of that nature, too, that come into play. When it comes to an audit that like, so they might not drill down deep. But the, the idea of an audit is that if you've got something in place, like file integrity management scene, you know, vulnerability scanning, whatever, that you're also using it and you're looking at it right, that's not you can't just have it and then send the logs to a data center. And then you know, don't do anything with them. Right? That's, that's kind of a no, go.

Yeah, I mean, only thing I can say honestly as another feedback is, you know, don't be scared. Take your time, and just work and communicate and address it. You know, what your internal team, like I said, I cannot reiterate enough is communication with your own company. Like I said, being a global CCSO (Certified Cloud Security Officer) and being on boards and committees, and understanding how your company works to apply the correct policies is so important. And because like I said, you can decide to implement a policy that could break the company, and obviously, that's not good for your career. Right?

So you want to definitely understand that piece, and that's where I see a lot of weaknesses. When I'm a guest speaking in conferences is that people just don't talk to the company or understanding what their company does. I mean, you know, they might have an idea, but what's the goal of the company to achieve? Because they like it, and what's their roadmap, even finance, for example, let's say finance is looking at implementing like, you know, a new eight, like SAP or Oracle or something, well, that's going to impact you, when you're, you know, from a cyber aspect and security and everything. So you want to make sure you're in those communications, and you want to be ahead of the game. Right? So if you can get the sooner security can get in any meeting, have a rollout, the better off you'll be. Because you don't want to be the person who gets the email going tomorrow, we're going to roll that Oracle and you weren’t in any part of the design or infrastructure that.

Question 7 - Which security framework applies to telco clouds?

Bryan:

Yeah, good question. Well, there's a, it depends. I'll touch on some of those some of what Jason just mentioned, and I'm sure Jason can add more color as well. You got to look at your business, you've got to look at what data are you holding, depending on what data you're holding, depending on what customer you're serving. That's going to dictate what framework or frameworks you need to apply to, you know, you need to align with. It could be NIST, you might need to, depending on the region of the world, you might need to align with GDPR. If you're a Chinese telco, you might have some Chinese specific security laws to align with. Their it varies. So that's why again, you need to kind of follow what Jason was suggesting, you got to look at your business and understand where are the attack points? And is there a framework who's controls address those attack vectors?

Jason:

Yeah, so just add that to Bryan. I mean, he's 100% on, it definitely divides up. Because whether it's telco or whoever, I mean, you can be a telco company. But the system that you're trying to secure could be HR internal related, versus a customer outbound system. So yeah, you definitely want to understand, again, your environment, and what that solution is doing to meet that proper compliance.

One other thing, are you regulated? If you're regulated, there might be a requirement based on the regulatory body over you, that dictates what security framework you've got to follow. So there's a lot of different factors.

Nick:

Alright, excellent. Well, we are we are almost out of time. And we are out of questions unless anybody wants to throw in. Going once, going twice. So we will give you back four minutes of your day. I want to thank everyone who attended this webinar. And I especially want to thank our panelists today, Jason James, and Bryan Langston, and as always, our super producer, Michelle Yakura, thank you, we could not do this without you. I am Nick Chase, and I want to thank everyone, and you will have the recording. Oh, wait a minute. No, no, no. Last last question. I almost got almost got away with it.

Question 8 - So there's no single framework that applies to telcos and various with geographies, correct?

Jason:

There's not. Because like I said, Every, every telco that I've worked with, which is pretty much globally, it all depends on what that solution is doing. Some had their own internal compliance that they designed as a company like a lot of companies do. But there's not one associated with just telco.

Our customer base we've got, yeah, Telcos in about every geo, and there is not a consistent one that we had a consistent framework that we apply.

Nick:

Right. Excellent. And that will take us out. Thank you all so much for joining us, and we'll see you next time. Thanks a lot.