ERP061 - Your Security Framework Sucks

I think the number one thing that should always be considered is what what is the business objective that we're trying to uh to secure. Um securing data without the the business goals in mind. Uh will will introduce that friction almost immediately. Welcome to Evolved Radio where we explore the evolution of business and technology. I'm your host Todd Kane. Today on the podcast, I'm chatting with Gabriel Gumps, CIO of Spirion. Gabe had an early passion for technology and focused on the security field. Gabe has a deep experience as a security practitioner. In the interview, we discuss where people tend to go wrong when implementing a security framework. We discuss some of the industry frameworks and how they can be leveraged for your own needs. We also touch on the necessary balance between security policies and user friction. I hope you enjoy this thought-provoking discussion with an innovative leader in the security and privacy space. If you haven't already, please subscribe to the podcast so you get every new episode. Also, if you wouldn't mind, please leave a rating and review in your podcast app. This helps others find the show so we can reach more of the community. Now, on with the show. Joining me on the podcast today is Gabriel Gumps. Welcome, Gabe. Hey, thanks for having me. Uh, so to kick things off, if you'd like to give us a bit of your background, maybe how you got into IT and specifically the security field. Absolutely. So I come from a bit of an engineering background and found my way to IT as uh as kind of a an intersection of that. So a little bit of a programming background, although I was not a an actual programmer by trade. Um but you know, studied some programming and things of that nature in school. And uh I started my IT career actually on the networking side of things. So I began in uh in network operations, uh building internets, intranets and some WANs, etc. Um and had been uh interested in the security side of things throughout that part of my career. And then began studying and uh and learning some of the the the details of of uh the the security craft if you would. Um so you know, we're we're dating back now over 20 years. And yeah, I guess it's a little over 20 years. That seems about right. Um, you know, started taking some some formal courses through some of the uh the the certificate programs that were out there, you know, the sands and things of that nature to build on things that that uh I'd also learned as part of, you know, my more formal schooling, etc. And it's spent a lot of time also um uh in the scene if you would. So there was a very healthy community of Infosec uh folks running around the New York area at the time. The Alt 2600 group was still fairly active. Um my my local uh New York Linux user group was fairly active as well too, probably is these days and there were a lot of folks that were equally interested in security. Um and then I got my first uh I got my first kind of start in the security um as an actual paid gig uh through some consulting work. Very cool. Alt 2600, that's legendary. It is I guess it is legendary at this point. Yes. It's uh legendary and and absolutely carbon dating at this point. That's great. I appreciate the background. Um, so I in our previous discussion, you had an expression about uh building your your own uh security stack and the sort of the working title for for this podcast is your security framework sucks. So you want to give us your expression around that philosophy? Well, I got a couple. I let's see, I think I know which one you're referring to there. So a security framework goes as someone who's who's equally taken their hand at crafting one. Um, yeah, they all suck and uh and everyone has one. Um, but rolling your own framework is like rolling your own crypto. One one of the reasons why you don't do it, probably the most important reasons, although there are a number of them, is that there are a lot of tried and tested uh frameworks out there. No need to recreate the wheel. Now adapting those to your circumstances, your business models, I think is the more important part of that exercise. versus attempting to look at all the ones out there, coming to the same assessment I did, which is none of them are great, um and then attempting to roll your own because that's almost guaranteed to be um a fool's endeavor as well. Uh especially when you've got frameworks, um tried and tested like the ones that uh you know, from the Nist uh the Nist corporation, etc. So, rolling your own is uh is both a bad idea and they all stink. Yeah. Okay. So we've got Nist, CIS, SOC. Any of the whole list of the others. Is there anyone that you tend to lean on or prefer in in sort of the general circumstance for let's say, you know, the the typical audience being SMB to mid-size. And I think the obvious answer is as well, it depends. But do you have a sort of a a framework that is either the best place to start or if you uh maybe fits better into that SMB and mid-size group? So in the SMB and mid-size group, I find that you're going to have a lot more kind of hands on by one individual wearing multiple hats kind of thing. versus the the ability to discreetly separate and and segment duties, responsibilities across different departments, etc. Um, so, a framework like the the Nist uh data data security framework, I find lends itself well to that in so much that it's very practical and prescribed, right? So there there are very described and prescribed methods for what you need to do to secure data in your environment. Which is ultimately what you're looking to do. Um and at the SMB level, I find it's it's even more important, not so not so much that it's less important at other levels. But at the SMB level, you're probably going to be outsourcing some of your network security, um overhead administration, etc. Maybe maybe some type of MSSP or something of that sort. Um, it really kind of depends on where you are in that maturity and life cycle. But uh that Nist framework does get very prescriptive in here are the things that you need to do in order to achieve these outcomes kind of thing. versus uh CIS, I I I think is useful, but I don't know how well it applies at the SMB level. I'd be talking out of turn if I if I tried to make that assessment. Um I need someone who's actually tried it at that level to actually weigh in, but my gut tells me that it probably requires a bit more bending and uh and and flexing than than you might find useful. Yeah, it's it's interesting. I I kind of feel the same like the the experience that I have with Nist and CIS. Nist is a a good sort of uh uh road map, but it it lacks in sort of specific implementation. So people hear about Nist and then they go and collect it and they're like, okay, well, here's a 40-page document that I could read through that's basically just a white paper talking about the things that you should do to have uh proper security. Uh or you can have, you know, um an Excel spreadsheet with a list of things, but it isn't really directive, it's it's sort of uh lacks a little of the implementation, I find. Whereas CIS is uh almost too deep down into the implementation and demonstrating work, it feels much more of a compliance framework for the security to audit and check that things have already been done. Uh so I I I feel like there's sort of somewhere in the middle that is is the happy medium. Uh potentially leaning on some parties or uh like a third party or a consulting group that sort of has a better operational framework for for Nist is probably a a good place to start as well. Agreed, thoroughly agreed. Um, and that's why I think I said data data security, but the Nist privacy framework, that one in particular, which was just updated in January of this year, does get a little bit more into the implementation details. Which is very necessary at that level. because you're not going to have a bunch of SMEs around subject matter experts that is that you can, you know, just kind of shoot an email over to or hit them on slack and ask questions. It's a lot of hands on kind of doing on your own, so. You need the implementation details. Yeah, where would you sort of draw the line between those two things? Right, because you you have a a podcast as well, privacy please, and imagine you focus much more on on the privacy side of of security and and the use and and implementation of that. But data and security, I think is where people tend to think about the importance of security. Do you have sort of some thoughts on the division between those and where the overlap is? I was just say it's more overlap than there is division. And in fact, on the podcast, we focus on the intersection of the two versus the discrete privacy versus security. Uh it's it's it's all on the intersection of the two. And that is the areas where you cannot have privacy without security, but you can't have security without privacy. And so we do we do discuss some of the the the details of what it means to be able to achieve those those two aims. Um where I draw the line if you would, uh usually ends again kind of at the implementation. So there is the I have secured, I have implemented controls to secure data. So let's let's just let's just get real tactical for a second. Let's say I have a database with customer information. And that information, let's just say it's, you know, it's order fulfillment information. So it's names, addresses, credit card numbers, you know, things I need to fulfill orders for customers. And so I will do I will implement all the the proper controls to ensure that that information is safe. So it can only be accessed by the correct individuals within your organization. Um so, you know, only those that need to be able to see that information to fulfill the order. Maybe no one, maybe that just that happens automatically between an order fulfillment system as well. Uh I'll, you know, make sure you you have those systems um hardened and that they're always patched, you know, just the basics, the absolute basics in security controls. You use controls like I mentioned as well. Then you your network controls, that system should only be able to communicate with other systems that are part of the that that delivery of service, etc. Um for the most part, I will have handled most of my security obligations. If I implemented my least privileged access as well, um to the appropriate data sets, uh then I will also achieve some level of privacy, right? So, so that not everyone in the organization is able to see it. But I still equally have some additional privacy um considerations. Is this information that I use to market to individuals? Is information that I share with uh let's say, you know, maybe I've got some data analytic folks in house um or maybe I outsource some things to to data scientists so that I can understand more of my customers buying behaviors. Do I start running a foul of privacy at that point and what controls do I need to complement my security controls in order to uh to provide both layers of those things? Um, and I think security professionals are inherently understanding of of privacy. Um, although it was not something that uh was discreetly practiced across the board if you would, if if I can throw out some generic statements there. Yeah, okay. Uh so moving to sort of the security evolution. Um, the, you know, security is getting to be a bit slippery at this point, especially with the push to work from home now, uh rather than containing and securing a localized network with maybe some VPN access on a on a on a minority basis. The majority is now either VPN or uh some type of remote desktop or VDI scenario with everyone working from home. Which uh obviously increases the the the the um the the footprint for what you're trying to secure. Any thoughts on sort of how security and the need for security and the implementation of security controls is changing with the expansion of the network? How it's changing? I think you you've highlighted one of the the primary ways it's changing. Is that uh those boundaries have become even further eroded if that was at all possible. You know, we've been talking about boundaries um having been eroded for for a while now with the introduction and adoption of of cloud uh platforms and SAS applications. I think where you're seeing the biggest change is now equally on the data side of that. All of that data is now living, residing, being created and used at all of those little tendrils that extend outwards from the boundaries. Not to over simplify or or uh or take away from what it requires to to secure those boundaries. But I I I do see that as as uh a little pale in comparison to securing the data in those environments, right? Um we've seen some really great advancements in the network security side of the world in the form of uh you know, SASE, SAS, um solutions to to kind of try and redraw boundaries if you would around all of these disparate technologies that are all part of our ecosystems. Um we don't see similar things at the moment for data security. And so, you know, kind of the approach that that we we've been taking is first getting a handle on where all that data is so we can then discreetly apply the right controls to it. And I think that's where the biggest challenge is right now is it was hard enough understanding what information you had to to uh to secure and where it was inside of your environment. Now your environments have multiplied because right to the point you just made, now every single person working from home is a discrete environment in themselves. So what information do I have there that I that requires security? Because much like you would if that boundary was smaller, you still don't want to apply just one control to all of the data, right? That would not that just logically doesn't make sense, right? Like is it is it the right thing to do, will it will it create additional friction in the way those users um behave and share information because if it does, they will find a way around it. They'll simply disconnect from the VPN and email it through their private emails, etc. Right? So you you you can't if you just apply that one big mallet of just going to VPN all the things and encrypt all the things. As that introduces friction into the user's uh work environment, they they will find ways around it. And it's that much easier to find ways around when they're at home, isn't it? It's easy enough for me to wormhole something from one machine to another, USB, you know, drive copy, whatever the case is. So you've you've got to start putting boundaries around the data itself. Which which I think is a a significantly greater challenge. Um but again, I I I I hesitate to uh to downplay the the larger efforts required around this entire shift to work from home. Right. One of the elements that I've seen sort of a rise of discussions about and and some some uh sort of mental exercises at this point is uh is around the zero trust model. Where effectively nothing within the network or the people or the data trust each other until those connections are verified. So it doesn't matter where those connections come from, everything is untrusted. Um you do you see that is sort of a better approach to this uh or so that you're you're kind of assuming nothing about who is allowed to touch what and who is allowed to access what locations? I see it as again another complimentary approach, I I argue a necessary one. Um we'd always thrown around the phrase, you know, secure or uh what's the phrase I'm looking for here? Trust but verify, right? Trust but verify inherently suggests a zero trust model, right? Um or maybe it's maybe maybe it did maybe because you lead with trust and then verify that uh that that may have been the exact opposite of zero trust depending on how you interpret that phrase. I've always kind of saw it more as a, yeah, I will accept that connection and then test whether or not it is uh it is one that should be allowed, etc. I think zero trust is a mandatory and necessary way to go again, especially as all of the interconnections break down. Um you can no longer just assume that trust is grant should be granted based on boundaries or or known entities, etc. Um especially considering that we operate under the the model that uh things are are compromised, right? Um systems are are easily compromised from an end user perspective. And uh and so zero trust really adds to that. And when I talked talked about, you know, SASE secure access service edge. Um they were designed with zero trust models um by uh by default. And and again, I think I see we we see some great success there. And it call back to Nist, I think Nist also released their zero trust framework. Was it earlier this year? I think it was earlier this year that that uh that hit the wire also. That's great. I'll uh I'll link to that because I think um that that will be a much more sort of prevalent um implementation that people will need to start to consider as well. So, I just want to point out, it wasn't even that long ago. Okay. When was it, sorry? August 2020. And it's uh 800-207. Okay, perfect. We'll link to that. Um, you mentioned earlier the the the friction point between security and users. Um, do you want to expand on that around uh from a framework and implementation standpoint, things that you should consider in order to limit the friction while you're trying to establish or reimplement security controls? I think the number one thing that should always be considered is what what is the business objective that we're trying to uh to secure. Um securing data without the the business goals in mind. Uh will will introduce that friction almost immediately. So again, if I go back to my order fulfillment uh use case. If if the data that I need to secure and the networks I need to secure are in line with being able to intake orders, process them and uh and store that data securely. Then I need to make sure that what I'm not doing is introducing a number of security controls that will interrupt that flow. Whether those be things that are say, you know, manual controls that someone has to step in and actually perform some type of uh some type of release control, if you would, some type of manual flow controls. Manual flow controls in security do not work well when you're trying to do things like automate uh order processing, for example. Um and and that's exactly the type of of considerations that need to be taken into place when looking to reduce that friction. Um it's very different to introduce uh manual flow controls if you would. into say my sending of an email where I may be stopped and prompted to to acknowledge that there's sensitive data in an email. Because I'm already in a manual workflow of typing an email and hitting send, etc. Introducing a small negligible uh flow control in there if you would, is quite different than introducing a similar one into an order fulfillment process. And so it really is just understanding what that business workflow is and where it is appropriate to introduce um controls that are heavy heavier in terms of flow flow interruption versus not. Um and again, making sure that they are the appropriate control for the appropriate outcome. If what you're trying to achieve is data security. then you're going to want to ensure that those controls are geared towards that where you are securing access to the data, the data itself, um and the flow of that data. versus equally introducing data privacy, which will also require that you introduce controls that restrict who can can uh access the data and how the data is processed. Both of those things again go hand in hand with the business process that you're trying to enable while securing. Okay. Uh one that maybe comes to mind uh as particularly relevant around uh sort of maybe it's manual, uh but it's a it's a necessary process would be uh two-factor authentication. Um I to me, like my my motto over the last uh sort of year and a half has been 2FA all things, just like if it's available, enable it, right? Um, but you know, a lot of users kind of rightfully push back that they get this 2FA fatigue, especially like if the organization is not send up some type of single sign on uh uh uh platform and basically everything that they touch through the course of the day, they have to stop, probably pick up their phone or a UB key or something like that to to try and uh uh verify that they are who they are trying to access this. Is this I assume that this is just sort of a necessary evil or are there better ways to go about this when you're you're sort of having these things that directly prompt or or or slow down the user as they're trying to get something done? I believe that we may still be in the necessary evil part of the evolution. There is definitely a maturity currently underway to eliminate passwords. Right. But eliminating passwords doesn't mean eliminating secrets. Yeah, it simply means eliminating the you have to enter in um, you know, some esoteric number of characters and letters, etc. Uh and then also be prompted by things. A secret elimination can certainly reduce friction in the 2FA process also. Um not secret elimination, but password elimination can can reduce it. So that if what you have are simply two secrets that need to be validated, um that can be a bit quicker. I think I I don't know why we would want to get away from 2FA in any other in any other sense, quite honestly. The the challenge there is whether or not we can eliminate the the very manual um passwords as a secret and replace them with what you mentioned UB key, for example. So, you know, if I if I have a a UB key and my phone, then that becomes two secrets that I have to have. I have to have my phone, I have to have my UB key. If I touch them together, there there goes the things. Um, you know, something to that end. There's uh there's been a significant push in the security world largely championed by Microsoft these days to uh to get rid of passwords. Yay. Yeah, and uh and and and move towards different types of secrets. If we can if we can go ahead and give Nist yet another shout out this year because they've been busy in 2020. I think they're the only ones getting real work done in 2020. Um they updated their digital identity guidelines. Um uh is it a framework? I think it's more of um, yeah, it's just a guidelines paper, right? Um and that one was 863B, don't ask me why I know that number off the top of my head, but I do. Um and that one updated from I guess about two years ago, adds a lot of new, very practical um uh implementation mechanisms that that we can introduce into our systems to that end. Yeah, I like the um the push from Microsoft to to eliminate passwords. I've I've uh uh sort of been cheering that that uh that philosophy on. Especially with sort of a lot of the modern authentication technologies that we have. I mean, like I've got a an Apple device, so face ID is excellent. You know, it it it it just pops up, authorizes me based on my face, you know, you can even tell if I'm looking at the at the screen or not, which is fantastic. And, you know, most computers in modern day have some type of camera either embedded in them or people will have a camera attached to them. So I think the more of the biometrics uh style approach to this, I think is is going to be a better future that that ensures uh sort of an appropriate level of security, but minimizing the friction for the user. Right. And that's exactly what what the the goal is. And no one would argue that biometrics are are foolproof and or, you know, hack hack proof. But neither are passwords. Quite frankly. Yeah. Yeah, so if if the if the outcome is relative same levels of security with lower friction and incre maybe even increased security because you can now have multi-factors of authentication, then that seems like a sane way to go. Yeah. Okay. Cool. So we'll we'll look to wrap up here, Gabe. We appreciate your your time and your input. Um, if people sort of are are questioning whether or not their their security framework sucks, what would be uh sort of the the initial place to send them, what should they look up just, you know, go go to Nist and try to do it on your own or or look for for some outsource third party? What would be your suggestion to someone wanting to take action against this and improve their security framework? I think the first action is to kind of step up to the mirror and ask, have I, have I looked at this security framework through the lens of my business, not just through the lens of everyone else that created it. And how how does how does my business uh achieve its stated goals and outcomes while implementing these things? Um, but I would equally then turn to uh to some of the if as a first stop, um some of the the the communities that are built around the implementation of these frameworks, um whether it's the ISSA or or ISC squared or where there are other professionals that have um kind of hands on experience in implementing those frameworks. And more importantly, in adapting them to their environments and learning from from how they've approached it as well. Uh absolutely worth its weight in gold to to understand and know the frameworks. but you have to make them your own. Yeah. No, I think that's really important advice. Because people will often sort of try to jam themselves through a square hole. Not recognizing like, maybe not all of these are equally important, uh, you know, to to implement 80% of this is going to be better than just sort of like muscling your way through it and and just sort of looking around going, you guys think we're secure? I think we're secure. We're probably good, right? I that would be the second half of advice is do not approach frameworks as an end goal. It is not a finish line once once said framework is implemented. Now I am secure. Which is why maturity frameworks uh kind of rub me the wrong way sometimes too, right? It's like, ah, I am now mature. It is it is time for me to to what? I I don't know what happens after that. I've never been mature. Yeah, no, that's an important one. It's uh it's a perpetual process. You know, you're never done with security, it's uh you're safer than you were, but you're you're always working at it. I think that's a really, really important message. Uh, great. Uh so Gabe, any um any uh call to action or closing comments uh before and also you can call out any socials where people can find you if they'd like to connect and and uh and know more. Yeah, for sure. So if folks want to connect and know more, you can certainly find uh Spirion at spirion.com. Um you can find us on on uh social at the same at Spirion. You can find myself at Gabriel Gums on Twitter and on LinkedIn. Um stop on by and check out the privacy please podcast, that's privacy please podcast uh.buzzsprout.com. Um find that on Twitter and social and all the places as well too. Um come check us out and we can talk a little bit more security and privacy shop. Cool. I'll link to everything in the show notes. So, thanks Gabe. Have a great one. Thanks, you too. Cheers.