Security Compliance & FedRAMP
For this 13th episode of Access Control Podcast, a podcast providing practical security advice for startups, Developer Relations Engineer at Teleport Ben Arent chats with Hisham Alhakimi. Hisham is a Security Compliance Manager, and has focused his camera on Security, Privacy and Compliance. Hisham worked at both consulting firms, and in-house. For today's episode we’ll keep things high level and get the perspective of a compliance practitioner. Focusing on assurance, the advantages of FedRAMP, barriers, and underlying standard setting bodies and requirements like your NIST, CISA, FISMA.
Key topics on Access Control Podcast: Episode 13 - Security Compliance & FedRAMP
- When done right, security compliance is a business enabler and involves undergoing independent verifications of controls to achieve certifications or reports.
- FedRAMP is a risk management program brought about to promote the adoption of cloud technologies across the federal government.
- Many, but not all, of the FedRAMP requirements tie back to an underlying NIST standard publication.
- FIPS validation is the process of actually taking an algorithm or a module all the way through a validation program using an independent lab.
- The term "FIPS compliant" creates confusion and is not a recognized designation, despite it actually holding some meaning.
- As a concept, shared responsibility is not exclusive to AWS and applies to other cloud service providers because it's very fundamental to how the cloud works.
Expanding your knowledge on Access Control Podcast: Episode 13 - Security Compliance & FedRAMP
Transcript
Ben 00:00:02.316 Welcome to Access Control, a podcast providing practical security advice for startups; advice from people who've been there. Each episode will interview a leader in their field and learn best practices and practical tips for securing your org. For today's episode, I'll be talking to Hisham Alhakimi. Hisham is a security compliance manager and has focused his career on security, privacy, and compliance. Hisham has worked both in consulting firms and in-house. For today's episode, we'll keep things high-level and get a perspective as a compliance practitioner focusing on assurance, the advantages of FedRAMP barriers, and the underlying standards and setting bodies requirements such as NIST, Cesar and FISMA. Since this episode is to deep-dive into compliance, I'll note that Hisham's opinions are that of a practitioner and do not reflect any or past employers. And with all policy and compliance advice, please consult with your in-house counsel before implementing any advice from our free podcast. Hisham, thanks for joining us today.
Hisham 00:01:01.841 Thank you, Ben. Glad to be here.
The need for compliance
Ben 00:01:04.093 So to kick things off, can you explain what compliance is, and why do companies need it?
Hisham 00:01:09.150 Sure. I do security compliance. When done right, it's kind of like a business enabler, right? So it's the undergoing of independent verifications of controls to achieve certifications or reports. Those are tangible outputs that are used to demonstrate to customers that a company is able to meet a certain bar, be it privacy, be it security, public and safety, whatever it might be. Right? That's kind of the end goal of compliance — to give customers confidence in what you're providing. It also boils down to building and maintaining trust. Right? So there's a cost attributed to compliance and a strategic intention. So companies really need to invest. So an ability of a company to achieve and maintain compliance signals, to customers, commitment. Right? Because there is repeated actions involved, there's honest communication and adequate disclosures that need to happen. It's not a one-time thing. And then just one of many duties to the community and stakeholders. Sometimes less-talked about, compliance protects companies from the fines now in litigation, which could lead to reputational damage and a lot of other things that might be detrimental to a company's growth.
Ben 00:02:22.812 Yeah. And I think over the last decade or so, we've seen a lot more that's been very specific to sort of start-ups and the internet industry as it's sort of developed, even going simple as GDPR or European sort of regulations that you have to keep in compliance with.
Hisham 00:02:39.704 Whether it's privacy, user trust, health, non-compliance is really not an option because this can result in significant fines, sanctions, that again can be very detrimental to the company's growth; reputational damage. And in some cases we've seen, it can even lead to a company's destruction. Right? I mean, obviously that's the extreme, but it's all possible. So there's a very real incentive for companies to achieve assurance and take compliance seriously, as it's kind of a byproduct of security, right?
Ben 00:03:14.494 Yeah. So today's episode will deep-dive into FedRAMP. Can you describe what this program is and why companies would go about getting certified?
Getting FedRAMP certified
Hisham 00:03:23.142 Sure. Yeah. So FedRAMP is a risk management program that was brought about to promote the adoption of cloud technologies across the federal government. And the way they plan to do that, and they are doing that, is providing kind of a standardized approach to the security, to the assessment process, and then to monitoring. A primary reason why a company would want to pursue FedRAMP would be because they want to do business with the government. So if they plan to store, process, or transmit federal data and metadata, achieving a federal authorization kind of grants them that authority to operate.
Ben 00:04:03.383 And I think the one thing I've seen is lots of companies that started off as traditional SaaS companies have gone through the federal process to be able to sell the same tool to the government. And sometimes that tool might have some other tweaks or it could be slightly different to kind of obtain compliance.
Hisham 00:04:20.968 I think you bring up a good point because a company achieves a FedRAMP authorization — as a CSP or a [inaudible], you're listed on a broader marketplace with other cloud partners and technology providers. So when you're listed on that marketplace, federal agencies, and other providers, and the general public, really, can view and potentially decide to leverage your offerings. Right? There's this notion of reuse. That's the big advantage of FedRAMP. Another advantage is, again, FedRAMP uses NIST as kind of the underbelly. Right? The policies and procedures are the backbone of FedRAMP. And so the ability to meet FedRAMP inherently means that you're able to meet NIST, and that boosts credibility not only with the public sector, but also within the private sector.
How FedRAMP and NIST relate
Ben 00:05:10.777 And I think I've seen this more with some of our customers, that just general SaaS businesses have looked at FedRAMP as sort of a gold standard for controls they need to go through — which kind of a good way into my segue is like — can you describe the relationship between FedRAMP and the underlying standards from NIST, which is the National Institute of Standards and Technology?
Hisham 00:05:33.034 Yeah. I'll give you kind of an idea of how they relate and how they map. Right? So many, but not all of the FedRAMP requirements kind of tie back to an underlying NIST standard publication or an SP. Right? So the most obvious is NIST RMF, the risk management framework. So that would be 853. Right now, we're on Rev. 5. So that is a catalog of security and privacy controls. The FedRAMP baselines, then, are essentially a tailored selection of those NIST 853 controls, with an additional layer on top of FedRAMP parameters and guidance. So right now, actually, we're in the midst of new draft baselines on Rev. 5 for FedRAMP. So FedRAMP is actually in the process of inviting public comment to review those underlying standards. And then you also have supplemental guidance and discussion that's contained within FedRAMP baselines that might point to other NIST publications, specific to things like incident handling or TLS, or digital Identity and DNS SEC, and a lot more. So they're very intertwined. And then lastly, I would say FedRAMP also produces guides, right, that might be very specific to how they want to enforce the performance management criteria and the escalatory path. So that's another kind of document repository that FedRAMP maintains.
Common barriers to FedRAMP certification
Ben 00:07:00.835 So when someone is going through the certification process, can you describe some of the common barriers that you've seen?
Hisham 00:07:07.334 It's an interesting question because the certification piece is actually only half the battle. On the front end, you deal with the readiness. Right? And then on the back end, you deal with what FedRAMP would call continuous monitoring. And then challenges can pop up at many points along that journey. Just to start out, if the business case is not compelling enough to become FedRAMP-authorized, you might have trouble actually getting prioritized to begin with. And that prioritization is going to happen between you and your leadership team at your company but also with FedRAMP, right? They need to understand and they need to be able to vouch that this is a good cloud service provider to take on.
Hisham 00:07:47.017 And then after prioritization, another barrier that might come up is just getting through the readiness stage. And the readiness — FedRAMP calls it the readiness assessment, or the RAR, you might hear. This requires CSPs to prove a pretty comprehensive set of federal mandates. And then where they don't, where they can't meet those mandates, they need to at least show that there's the ability to remediate them in a reasonable time. And then after that, they need to go through a full-blown assessment process and put together a security package. And of course, after authorization, they need to maintain that authorization and make sure performance managements are right, operation visibility, patching, and things like that. So at any of these points, if the Joint Authorization Board that's responsible for that CSP notices that there is any deficient controls or lack of visibility or something like that, that could lead to escalatory actions that are taken up by FedRAMP. So there's a real investment and critical attention that needs to be paid to ensure that the decision to get FedRAMP-authorized is a good decision that you can sustain.
Ben 00:08:59.523 It's the difference between, I guess, SOC 1 and SOC 2, wherein SOC 2 has to be continuous upkeeping of it and go through an external auditor, whereas SOC 1, I believe, is self-assessed.
Hisham 00:09:13.297 Yeah. So for example, a Type I might just be focused on design. Right? Whereas a Type II SOC report will be focused on the design and the operating and effectiveness of controls. Again, a SOC 1 might be more on the internal controls over financial reporting. And then you have Type I, Type II. For a SOC 2, you have more of a focus on security and trust criteria. Whether it's SOC or PCI, HITRUST or FedRAMP, all these compliance frameworks, it's not just a one-time list because these customers need renewed assurance. Typically, in the case of SOC, for call service providers it's usually semiannually or whatever cadence they agree on. In the case of FedRAMP, once you are authorized, it's an annual reassessment.
Ben 00:09:57.710 As far as your company is concerned, you have to always be making sure that [inaudible] control is keeping up to date with all of the updates coming, as they sort of change as well.
Hisham 00:10:05.407 Yeah. There's multiple teams that need to be spun out, right, to support this; whether it's taking service all the way through authorization, whether it's just documenting the system security plans, whether it's getting kind of into the trenches with engineering teams and the FedRAMP to explain high-level architectures and data flows. There's typically multiple teams that get created to be able to support a FedRAMP authorization. It's not a one-person or two-person show, usually.
Thoughts on build vs. buy
Ben 00:10:39.507 So one thing – when I was introduced to FedRAMP — is that we have a FedRAMP version of our product, which helps obtain certain list requirements. So we have people saying, like, "We need to obtain AC-10 concurrent session control." A couple of years ago, we made this table, listed out the NIST requirements, "This is the features we've done to help obtain that control". And I know the FedRAMP is kind of huge. This is only like a small part of it. But while going through your certification, what's your thoughts on how much you can sort of build in-house v. sort of buy externally to help you on that journey?
Hisham 00:11:12.143 It's a very loaded topic, so I'll try to offer my limited perspective on it and then give you a couple of examples. So I think the decision to build versus buy, first, depends on the nature and breadth of the service offering; the cloud delivery model that they want to pursue, whether it's [inaudible]; and then overall kind of like the business strategy. So for simplicity, if a service provider wants to focus on a very specialized niche product, they might be inclined to outsource a great deal of the IT operations and correlating controls. So it might make a lot of sense to buy third-party capabilities, which from a FedRAMP sense would be considered augmentative to the boundary, especially if those third parties are FedRAMP authorized or compliant. That can be a nice kind of like point-to exercise where you can help meet the spirit of controls. But not only can companies that do that tap into the expertise of those providers, but again, they can certainly inherit certain controls. That type of relationship doesn't always automatically preclude the primary provider from needing a federal authorization. There might still be pressure from customers and from the regulator themselves that the primary provider gets FedRAMP authorized. But again, a lot of it comes down to negotiation and risk discussions with FedRAMP, sometimes, and the assessors.
Ben 00:12:35.146 To sort of summarize, I think in the world of supporting technology, you can't really do everything unless you're a huge company. So probably at some point you'll need to either buy some infrastructure or something else. But I think the Shared Responsibility Model from AWS is kind of a good example in which they're responsible for a certain part, but you're still responsible for a lot of sort of above it. And that's kind of like where examples of giving you controls is a good example.
Hisham 00:12:59.193 Absolutely.
How FIPS Validated and FIPS Compliant differ
Ben 00:13:00.179 And I think another interesting technical difference for our FedRAMP version is that we compile with BoringCrypto, which is a Google project that offers FIPS 140-2 compliant cryptography — which Google, I guess, went through the process to get that cryptographic library certified by the government. And that's the reason why we use it, because it's sort of a blessed cryptographic library, which I thought was kind of a pretty interesting process to go through. Can you describe the difference between something being FIPS validated and FIPS compliant?
Hisham 00:13:33.343 I'm here smiling because it's my favorite topic. And so FIPS validation is the process of actually taking, like you said, an algorithm or a module all the way through a validation program using an independent lab. So it would be either taking it through CAVP or CMVP. That process is a heavy lift. It can take many, many months to complete it. And there's also been well-documented operational bottlenecks and automation challenges that NIST and the government acknowledges. So that's the gold standard. To get FIPS validated is the end game goal, if it makes sense from a business perspective.
Hisham 00:14:12.617 Another commonly-used term: FIPS compliant. The only problem is that term, FIPS compliant, creates a lot of confusion and often gets conflated. From my experience, it's really not a recognized designation, despite it actually holding some meaning, right? FIPS compliant is really a claim. So a company might say they're FIPS compliant, but it's nothing more than a claim to say that their system meets requirements outlined in various publications. I think the more appropriate term is FIPS approved, NIST recommended, or NSA approved. Those are actually designations that actually bear some weight because they suggest that a technology or an algorithm or module uses specific ciphers and modes of operation that NIST recognizes or that NIST considers secure. Those nuances have been a pretty common topic among CSPs, third-party assessors and the government, obviously. I like to think about this topic in terms of FIPS validated versus FIPS approved or NIST recommended, as opposed to using the FIPS compliance.
Ben 00:15:22.417 Yeah, it's a good description. And I think often when we have people coming, it's part of that sort of journey. And we say, "You're also going through these controls." But I think one thing you talked about before we joined and started was there's also the human aspect of, you often have to explain this to people who are reviewing these controls, and technologies can be different. And so if you can point someone to, "Ah, we're using this technology; this is how this thing solves it," it can make that sort of introduction to the problem easier. And I don't know if you could just summarize sort of that education process of going through sort of an audit?
Hisham 00:15:58.536 One thing that's helped me kind of enrich the discussions or negotiations with assessors and the government has been the ability to invoke certain NIST discussions or supplemental guidance. Right? Because that's where the science and the technology meets. And being able to tie the risk to those things is a great tool for you to use with assessors and government. Another thing is just actually trying to — and that's why I say using things like FIPS approved or NIST recommended, those are actually terms that are cited in glossaries within standard publications. Right? And in various publications. Whereas, again, FIPS compliant is just a claim. Another tactic that really helps is just being very, I think, transparent, and working hard to help the reviewers, the [inaudible] reviewers, understand your authorization boundary, whether it's giving them free tutorials or training to understand how they can log into a console or initiate a command using programmatic access through an API, or even taking them through a data center for a tour. Helping them understand how certain services work, or even atypical services might work, is a good way to earn trust with them as you maintain what's usually a long-term relationship.
FISMA and FedRAMP
Ben 00:17:23.575 Right. Makes sense. So FedRAMP was started to make it possible to offer a standardized approach to security authorization for cloud service offerings; but some companies might also encounter FISMA, which is the Federal Information Security Modernization Act. Can you explain what type of company might encounter this act when it comes to the government?
Hisham 00:17:45.709 Yeah. So both FISMA and FedRAMP, they leverage very similar standards. The only differentiating factor between them is how they originate, who they target, and then how they select the controls. Companies that might not be cloud-oriented or that might have a more direct relationship with a single agency might be more inclined towards using a FISMA assessment. FISMA is the law, it's enforceable through some OMB memos, and it uses NIST guidance; whereas FedRAMP, it's a more risk-management program that comes out of a policy that was issued in 2011, which is a cloud-first policy. So while the categorization process of controls between these two are very similar, a FedRAMP assessment actually needs to be performed by a third-party assessment organization, whereas a FISMA assessment can be actually performed directly by an agency. So, again, if a company has more of a direct relationship with an agency and they might not have as much cloud-oriented technologies, they might be more inclined towards the FISMA. Another significant difference, I think, between the two is that FISMA is kind of like a one-to-one authorization process versus a one-to-many in FedRAMP. So a successful FISMA assessment might grant an authority to operate for one organization, whereas a CSP that is assessed through FedRAMP, that authorization can be reused across the government. So I've seen it described before that essentially FedRAMP is kind of FISMA for the cloud, and I think that's a really simplistic way to think about it.
Ben 00:19:30.432 It also sounds like if you have a generic tool, which solves a problem for lots of different government branches, you're probably better to go FedRAMP because once you have it, you can easily sell between Parks and Recs and the NSA, if they have the same problem.
Hisham 00:19:45.414 Yeah. And the funny thing is, with the FedRAMP authorization, you don't even need to pursue a FedRAMP authorization to achieve that reciprocity or that reuse. Even if you achieve an agency authorization for FedRAMP, other agencies can go through their own risk-based decision to leverage that offering. Reuse is actually possible in both authorization paths, whether it's a job authorization or whether it's an agency authorization. And that's obviously sometimes forgotten, I think.
Human controls specific to regions
Ben 00:20:16.077 Okay, that's good to know. So let's say a startup has closed their first large government contract and they might find that the moderate FedRAMP isn't enough. So they start looking at a sort of cloud service provider which is specifically designed for running government workloads. I think one of the most common examples would be the AWS GovCloud. I think, actually, one of the most interesting things about reading the marketing page was that it jumped out to me that customers needed to have — only a US personal green card holder can have access to the root keys. What other controls are involved with these sort of government cloud providers?
Hisham 00:20:52.449 Yeah, I'll give a little context into that requirement too, and then talk a little bit about the other human-driven controls. So kind of the premise behind a GovCloud region or a high-impact region like that is that customers have specific regulatory or compliance requirements. It might be an ITAR requirement, it might be a DoD SRG or a FedRAMP High. End of the day, they want to receive kind of a higher level of guarantee and assurance; not necessarily a higher level of security, because security should be very strong even at the moderate levels. So there are certain logical and physical security controls, like you said around credentialing, for example, or the management of root keys, data center and region designs, and of course other requirements such as the US persons rule, and then finally an actually more expansive control set and control enhancements.
Hisham 00:21:44.804 As far as these resources being restricted to US persons, a lot of that comes down to the screening and vetting requirements as well as contractual customer agreements. So what I mean by that is, as cloud service providers want to preserve a US persons-only environment for customers, they're providing certain guarantees on their end around protecting those sensitive workloads. So it could be totally compromised if there isn't a similar expectation for the users authenticating through special accounts. So that's kind of where you can't just invoke and say, "Shared responsibility. We will wipe our hands clean." It's not necessarily the traditional shared responsibility model, for example, that AWS would, say, apply to a GovCloud account. There's more contractual agreements and expectations — because it's a whole different log-on page, right, for example, to get to a GovCloud or high-impact region.
Hisham 00:22:41.409 And then in terms of other human controls, beyond the US persons requirements, there's a residency requirement as well. So typically, these regions will have support engineers and operators that deal with protected resources. Those such persons will need to reside in the US and be US persons. Now, if they're dealing with more basic use cases and customer calls and might not be directly involved in the protection of resources, you might not have to live or reside in the United States. It really depends on a — per-use case.
Ben 00:23:20.176 But I think if you had, let's say, a database with other sensitive government information in it, the only person could access that has to reside in the US and be either US resident or green card holder.
Hisham 00:23:33.265 Correct. Yeah. For critical actions like that, or to protect resources, or even if just as a member of — a support engineer. Right? You might have to help with escalation sometimes and you might need to, again, access those resources. So those people would need to be US persons and reside in the US.
Ben 00:23:55.397 Yeah. So you could have a ticket desk, which could have frontline maybe in Canada, but if you need to actually touch the account you need to be in the US, sort of hand off the ticket.
Hisham 00:24:04.239 And usually those requests, those support calls, support requests, will kind of get triaged. So as it goes through that first tier, if whoever's receiving that request deems it to be something that relates to protection of the resources and something that requires intervention of a workload or whatever, a storage DB or something related to the networking, then they'll probably escalate it to those vetted or to those cleared engineers.
Ben 00:24:30.755 We talked about moderate FedRAMP and there's high FedRAMP. Can you just sort of describe the difference between the two and why you'd want to pursue one over the other?
Hisham 00:24:37.393 The difference, as I was mentioning, the high-impact zone gives you a little bit more of an expansive set of control enhancements for NIST. It also introduces certain logical and physical differences. So the physical is obviously, the data centers will be restricted; the logical access related to credentialing and who can access it. And again, I would not say that high impact gives you more security. It just provides you more guarantees that you can meet certain underlying requirements, such as ITAR, such as DoD and such as FedRAMP, such as FedRAMP High.
AWS Shared Responsibility Model in the context of security and compliance
Ben 00:25:15.853 I know we talk about shared responsibility, but if you picked GovCloud, does that mean that you have more security compliance handled by AWS? Or is it just the same as running your standard workload in an AWS region?
Hisham 00:25:29.151 Not necessarily. I think shared responsibility — which is not only exclusive to AWS, applies to other cloud service providers — that kind of transcends the impact regions. Right? Because it's very fundamental to how the cloud works. The cloud provider will be responsible for certain things, and the customer will be responsible for certain things. The cloud service provider will be responsible for the physical infrastructure and the hardware that comes with it. They need to make sure that data centers are up and running, the availability zones and edge sites are up and running and resilient. And then they're responsible for providing a software that's there, be it compute, storage and DV, or networking. And the cloud service provider needs to make sure that all of those things are secure. Customer, on the other hand, comes in after selecting a cloud offering. They're responsible for their data, right? They're responsible for their data, how they manage access to that data, how they configure their systems, and then how they implement protections such as encryption.
Ben 00:26:34.056 Yeah. And I think my favorite one is like, the same with credentials. So to get into a data center, you might have to go through biometrics and verify different information. You should do the same for whatever API keys you get or logins for your cloud service provider as well.
Hisham 00:26:49.875 Depending on the high-impact level, I don't think the fundamental security controls change. It might be just a couple of tweaks to logical and physical restrictions. But security needs to be just as rigid to support a moderate [inaudible] commercial customer.
Impact of the Software Bill of Materials (SBOM)
Ben 00:27:07.961 I think also this year, we've seen the current US administration push a few new guidelines for both agencies and people supplying software to the government. I think one of the first ones, which was put in November of last year, was creating the Software Bill of Materials, or SBOM, for critical software. Can you talk about how this is affecting the industry from a compliance perspective?
Hisham 00:27:30.532 It's a great topic. As you said, the EO kind of introduced a lot of provisions that are — it's going to mobilize agencies. It's going to mobilize CSPs and other IT companies. So in terms of the SBOM or the Software Bill of Materials, it's not a new concept. There's always been requests of developers, either through an internal security review or some limited audit, to divulge information about where those components were sourced from using a bill. Right? An SBOM is really just a list of ingredients for a piece of software. Right? And then there's also been an incentive to discover vulnerabilities and malicious code. There's been whole industries that have been built around that that sometimes even the government relies on for their own system alerts and bulletins. But as of 2018, and then now even more so. I think with the EO, the SBOM has been wrapped in a lot of regulation that's kind of enforceable. So I think the criteria packed in the EO kind of enhances the software supply chain with respect to critical software. But it adds also another layer of complexity and body of work for compliance. Because now a purchaser will need to implement mechanisms to verify that their third parties' artifacts and open source libraries are trusted, are authentic or safe. Right? And then they'll need to require a sponsor for the third-party suppliers, track those dependencies, and then kind of start to slowly but surely build and prioritize the right kind of like trusted repositories.
Hisham 00:29:11.292 I think before the EO, vulnerability configuration management, it was always kind of a key component of those programs. But now SBOM has kind of added a lot more scrutiny. If we drill a little bit further into kind of compliance and maybe even use FedRAMP as an example, or NIST, around the same time SBOM was taking off here in the EO, NIST 853 Rev. 5 introduced a whole new supply chain risk control family. That was very interesting, the timing of that. And there's been controls like SR-11, which requires SESPs to implement controls around component authenticity. And then FedRAMP also asked in Rev. 5 to ensure that vendors protect the development pipeline.
Hisham 00:29:59.301 So I think one big topic that's going to impact compliance is this notion of like, how do you independently verify the software components? Vendors can have the best intentions and let you know and give you assurances that their software is secure and built with the right components. But how do you actually verify that that is actually true? And then as a builder of software, finally, I think they will need to secure the build pipelines and protect their artifacts, whether that means using certain build templates or golden paths and images and things like — things to make sure — those are some of the things that companies need to focus on now that SBOM is wrapped in regulation.
Ben 00:30:44.319 It's a huge topic, and I think especially when you look at how — all software is built on other software, so even if you think it's a small dependency, that dependency could have a big graph of other dependencies, which are included some time [crosstalk].
Hisham 00:30:59.724 Absolutely. There will be ripple effects and then new dependencies will develop as there are new patches and upgrades and those software packages are advanced.
Ben 00:31:12.858 Yes. So you're saying in version five of the FedRAMP guidelines, there's more explicit guidelines for this?
Hisham 00:31:20.023 So yeah, in NIST 853 revision five, which was published in late 2020, there was a new control family denoted with SR. So that SR control family was introduced in Rev. 5 and of course, FedRAMP, as they do a tailored selection, they also have pulled that control family into their baseline.
Ben 00:31:42.974 And I think the thing that is interesting about FedRAMP is, this is all great advice that every software company should be striving for, which is sort of interesting that sometimes government regulation doesn't always make that much sense. But I'd say lots — if you read it, lots of FedRAMP actually makes a lot of sense and is something to sort of aim for.
Hisham 00:32:00.834 Absolutely. And that's why when you mentioned, "How do you ensure as a cloud service practitioner that you're successful with the government or with assessors?", I think it's huge to be able to kind of invoke the underlying NIST requirements because that's enforceable. Right? It's very rare that you invoke something like that or you reference something like that and it's not acknowledged by FedRAMP, because the FedRAMP program was built around NIST.
Moving to a zero trust architecture
Ben 00:32:31.808 Another one, I think, that came out at the beginning this year, is move for zero trust architecture, which is similar to sort of Solar Flare and the recent Log4j vulnerabilities. Can you see this changing the roadmaps for federal security and compliance?
Hisham 00:32:46.760 I think it can. Zero trust has always been kind of a big buzzword, and again, not entirely a new concept, but it was re-emphasized in the EO. So it's going to be a deliberate approach by the government to adopt, across the board, a bigger focus on identity and access control, ultimately to manage cyber incidents as well. Right? It was actually introduced almost a decade ago, but it kind of returned to the spotlight because early adopters such as Google and Adobe are really kind of mastering the concept. And then it got more popularity recently with the cyber incidents and things like that, so it's emerged even further. The interesting thing about zero trust is most security practitioners will agree that most data breaches have a connection to compromised privilege credentials. So while the focus on perimeter security, your endpoints, firewalls, your network protections is essential, zero trust kind of revolves around, again, identity and credential-based threats.
Hisham 00:33:55.567 So how will that impact the roadmap for security and compliance? I think it's going to cause agencies and cloud service providers to place more emphasis on programs that support identity and authentication. Practitioners can assume a better baseline around access controls, continuous auditing, and those type of things. And another thing with zero trust is because the word, the name itself, kind of creates sometimes even a negative perception. Like, are we talking about bad employees and bad actors and all these kind of bad user experiences that are associated with zero trust? It's more about creating culture around granting rights based on confidence, the right confidence levels. And that's what zero trust is really about.
Ben 00:34:45.177 And I think it's also splitting how people view the authentication, the authorization. So proving that the person is the person they say they are, then also saying that that person can perform these actions at this time.
Hisham 00:34:57.862 It's like that. It's about implementing the right mechanisms to establish authentication and give people — it's not just as simple as saying least privilege, or need to know. It's deeper than that, I think. And that's why I mentioned things like adaptive security controls and continuous auditing. You don't just grant access once and forget about it. You're going to have to monitor those accounts and make sure that they're trustworthy.
Becoming a Certified Information Systems Auditor (CISA)
Ben 00:35:24.736 That's great. So as we wrap it up, one thing that we've not covered already is your background in accounting. And in my experience, most auditors come from an accounting background. Completing a SOC 2, for example, they would be technically the same person to complete your taxes. Can you talk about your certification as a certified Information Systems auditor?
Hisham 00:35:46.183 Yeah, sure. So I probably won't be doing your taxes. I'll probably direct you towards a tax counselor or CPA. But I think your observation is spot-on in terms of a person that's in IT audit might have — it's common that a person in IT audit has a background in accounting, and that's mostly because of the emphasis on integrated audits, the relevance of IT systems to financial statement processes, and then a lot of shared kind of audit methodologies. Right? So obtaining my CISA certification was something that just made a lot of sense when I was entrenched in information technology audits. It's certainly a preferred certification with the employers and I think gives you a lot of baseline knowledge. But as with anything in certifications, it's only going to be as good as your application of it and how you augment that with practical experience.
Ben 00:36:35.554 What was your sort of transition between sort of the accounting to the tech field and what are some unique challenges that you've encountered?
Hisham 00:36:42.304 As I moved away from pure audit-related roles and then more security, security insurance, and cloud-based technologies, it was sort of a natural realization for me that I needed to uplift my skills through self-study and, of course, practical experience. So I've been very intentional about attaining experience in the cloud service provider industry and software companies. So that means actually applying for certain roles and attaining certain opportunities that came my way, but also just obtaining a few certifications in cloud architecture to understand the principles of cloud technology that make those companies successful. So it's a combination, I think, of pivoting into those industries versus the industries I was in before I joined cloud service, and then also taking some certifications in cloud architecture.
Engineers and developers working successfully with compliance teams
Ben 00:37:32.664 One last question. So we mostly have a developer or security-focused audience, and I'm sure having a meeting with the security compliance manager wouldn't inspire joy for many devs. What are some of your tips for working successfully together?
Hisham 00:37:47.745 So I'll give a few examples and some tips that have worked for me and that I've also gotten feedback from engineers on. So a few practical examples where I've kind of engaged engineers and developers in a compliance function was — I worked with engineers to present penetration test findings on their services and then kind of digging deep into the risk, understanding the impact, whether there's operational requirements or false positives, and then coming down, concluding on a proper remediation. We've also worked with security operations teams to triage, analyze, and effectively communicate cyber incidents. Compliance and assurance folks tend to also write recommendation papers to networking security and infrastructure operations teams, to spark the development of features or the launch of campaigns. When I think of all these, just these few examples and some of my interactions, I think of three things top of mind to ensure a successful collaboration.
Hisham 00:38:50.924 One is the ability to appropriately articulate the customer impact to these engineering teams. That's one thing I think we can all unite on. If we get it right. If we can explain why this matters to the customer, why something needs to be done, then I think the engineers will be more inclined to support what you want to do. Two, the ability to actually minimize the burden of interpretation on that, right? So what I mean by that is the last thing an engineer wants, or a developer, is for you to send them a link to some standard or to drop a long list of requirements and sub-requirements that will literally bore them to death, right? You have to distill that and break that down and interpret it for them. So it's very low-touch. So that's another one. And then three, which is very related to the second point, is providing very crisp communications with them and then some mechanisms for tracking that makes sense; be it, for example, an effective ticketing process. Those three things are just like very simple tips I would give to effectively work with engineers. And then obviously you have to demonstrate sort of knowledge of their service, right? Like if you're going in talking about a specific service or feature, you've got to do your homework and understand that and then you also have to demonstrate to them that you're a subject-matter expert in your field. And I think with all those things, as they come together, engineering and developers will be more compelled to work with you as a partner, not because they have to.
Ben 00:40:26.232 Perfect. I think that's a great way to finish the podcast. Thank you so much for your time today and it was awesome.
Hisham 00:40:34.552 Thank you so much.
Ben 00:40:35.867 This podcast is brought to you by Teleport. Teleport is the easiest, most secure way to access all your infrastructure. The open source Teleport access platforms consolidate connectivity, authentication, authorization and auditing into a single platform. By consolidating all aspects of infrastructure access, Teleport reduces the tax surface area, cuts operational overhead, easily enforces compliance, and improves engineering productivity. Learn more at goteleport.com or find us on GitHub: GitHub.com/gravitational/teleport.
