CISO's Guide to Making Friends: How to Engage IT for Cybersecurity Initiatives

PODCAST TRANSCRIPT

Brian Selfridge: [00:00:19] Hello. Welcome to The CyberPHIx your audio resource for cybersecurity, privacy, risk, and compliance for the health care industry. I'm your host, Brian Selfridge. In each episode, we bring you pertinent information from thought leaders in health care, cybersecurity, and risk roles. And in this episode, we'll be speaking to David Jones. David is the director of Information Security at RX Benefits Inc., a tech-enabled pharmacy benefits optimization organization. I'll be speaking with David about ways to engage various technical stakeholders in supporting the mission of cybersecurity and getting traction for our security programs. We'll try our best to learn from David how security professionals can make friends, so to speak, with our colleagues, and ultimately reduce the risk for the organization overall. So let's dive into another great conversation with yet another amazing guest, David Jones. Welcome to CyberPHIx, the leading podcast for cybersecurity risk and compliance, specifically for the healthcare industry. I'd like to welcome my guest, David Jones. David is the director of Information Security at RX Benefits Incorporated. RX benefits is the employee benefits industry's leading technology-enabled pharmacy benefits optimizer. The organization offers mid-sized employers and their members an affordable pharmacy benefit solution, combined with a Fortune 100 service experience. So prior to our benefits, David has held multiple leadership roles in security, infrastructure, engineering, and networking for a variety of organizations inside and outside of health care. 

Brian Selfridge: [00:01:50] So I'm excited to be speaking to David today about engaging I.T. and other technical stakeholders to support the cybersecurity mission and initiatives. There's no silver bullet here that engages all stakeholders equally. So I'm looking forward to kind of unpacking these different I.T. roles and how we can best engage with, together with those groups, to reduce cybersecurity risks while advancing I.T. objectives as well overall, of course. So we titled this episode The CISO's Guide to Making Friends, which is an inherently very difficult undertaking, given the fact that we're often the bearers of bad news or can be perceived as adding additional workloads to already overburdened teams. But we'll sort through all of that, and I believe it is possible to make friends. We'll find out if David agrees with me or not, and still at least maybe get some things done in the process. So so David will help us figure out how to sharpen our friendship-making skills, so to speak. So with that, David, thank you so much for taking the time to be a guest on the CyberPHIx today. 

David Jones: [00:02:44] Hey, glad to be here. Looking forward to it. 

Brian Selfridge: [00:02:47] Great. So you've held multiple roles in I.T. infrastructure. I mean, I think it makes you really uniquely positioned to talk to us about this, sometimes both security and infrastructure at the same time, I notice, which is probably a tug and a pull in your own mind in some ways. So I'm excited to explore with you how you think CISOs and security teams, in general, can best engage with I.T and infrastructure teams and vice versa to support each other's objectives as well as the company as a whole. So I guess just a level set with our listeners, what are some of the different technical stakeholder groups that security teams most commonly need to engage with to support the delivery of the security program? 

David Jones: [00:03:23] Yeah, so there's not a lot of areas that I would say security doesn't interact with it. But, you know, primarily you've got your network and your server teams, you've got your development dev ops and product and helpdesk is one that we interact with a good bit as well. 

Brian Selfridge: [00:03:39] It seems like there's sometimes a natural tension. I don't know if that's the right word between cybersecurity functions and technical i.t. Stakeholder teams. Why do you think that is? And maybe what are some of the just the basic techniques you'd recommend for overcoming that kind of natural, natural tension? 

David Jones: [00:03:57] Yeah, I've been pretty fortunate. I think I've had some pretty good relationships in a lot of places where I've worked. A lot of times it really comes down to just at the highest level. Do you have the support you need from the executive leadership to say, this is something we're going to take seriously? But even despite that, you know, I think there's always a matter of priorities is always a matter of, you know, this is a field in general where resources resource contention is a real thing and they've got priorities coming from especially it. They're in every part of the business. So when they're trying to achieve this, this problem, achieve, solve that solution, and then you've got security coming in and saying, hey, we need to do this other thing. And especially if you see that as slowing things down, you've got that conflict a lot of times, you've got some kind of tool overlap and a lot of, you know, they want to do it one-way security to do it another way. And a lot of times our tool and their tool don't necessarily jive. Of course, there's always the old getting in the way and slowing things down. You hear from time to time. 

Brian Selfridge: [00:05:01] Yes. That's the that's probably the least of it. I remember when I was a security officer, someone I think in the interest of, you know, the right their heart was in the right place. But they kind of accused me of killing babies in one way, shape, or form. It was something along the lines of, you know, if you do this, our neonatal system is going to go down and you're going to kill babies. And I was like, let's just walk it back a little bit from that sort of we're here to help. I want to talk a little bit about engaging each technical stakeholder group in a little more detail. And this is really a deep dive in the weeds, but I think those that work in the field understand that there is a difference when you're talking to server admins versus helpdesk, for example, and sort of different types of groups. So I want to kind of dig into that a little bit. Maybe we can start with server admins or engineers or whatever they're called in various organizations. You know, what are some of the typical intersection points between server admins and security teams, and what do they need? What do you need from them and what do they need from you or vice versa? 

David Jones: [00:06:02] Yeah. So I kind of think our main intersection points with those guys. Obviously, you've got the patching and vulnerability management is key with those teams configuration standards just in some cases the security tooling itself and getting into some of the details thereof who owns some of that, you know, just because it's so entwined with a lot of the network core services and then, you know, obviously you're working with that team a lot when it comes to supporting compliance and third-party audits, those kinds of things. 

Brian Selfridge: [00:06:32] Are there any particular common points of conflict? Is it around patching, timing, and schedules, or like what are the times when you just like you butt heads with server admins? What are the things where you have trouble kind of coming to a consensus? 

David Jones: [00:06:46] Yeah, I think patching timing is always one that comes up. There's always a question about what's the right velocity versus the effort you have to put into it, right? There's some, some best practices out there, but at the same time, all patches are not created equal. Sometimes it's a Herculean effort to take some old system and do the things that need to be done. But, you know, typically you've got that I think a lot of the things there just comes down to ownership of a lot of the things. And when you're a small, small, you know, security shop, say, when I kind of think through the journey we've gone through so far, you know, at one point we had seven people in it, and now we've got about a hundred. So when you're one or two people in security, then you've got to rely on that this team to operate a lot of those security tools for you, run the agents, and do those things. As you start getting a little bit bigger, a little more mature, you know, now you want to kind of own your own toolset. So now you kind of have those conversations of, well, who should own this and who should own that? And, you know, patching is something that right now the server guys own and they need to patch their own things. 

David Jones: [00:07:54] Is there a point where that becomes something that security pulls in-house and they kind of own that process a little bit more rather than kind of setting the requirements? So there's, you know, that's 11. of conflict. I think other security initiatives, it's just the matter of we've security's got this list of things we want to get done. But again, I think that the infrastructure server admin operations team is an area that to me says somebody who's been there before traditionally feels like an understaffed group consistently. So when you are kind of having these contention things, when the business wants to do these things and you know, you always hear a lot of especially from your portfolio groups and your business advocate groups that, oh, the business is what really matters, but you've got to be able to do these things too. And a lot of times they kind of get caught in the middle on those. 

Brian Selfridge: [00:08:43] Have you seen where there's sometimes a security subject matter expert kind of embedded with the engineering team, either kind of a server admin that's a security specialist that can kind of be the go-to or maybe be in the fold with that group. Does that type of thing help or is that not really much the case anymore? 

David Jones: [00:09:01] I'm very close to doing something exactly like that. Just, you know, we've done, you know, kind of skipping around and jumping around a little bit. We've done this a little bit with our development teams, but this is not something we've done yet. But we're I'm having that conversation right now. It's hey, we're doing pretty well here, but we'd like to get a little bit extra help on this one specific thing, do you know? So me talking with my peer on the operations side, do you need to add a person for this, or do I need to add a person for this? Can I add a person and sponsored that person to put on your team to handle this? And right now, I think that's the route we're going to go. And I absolutely see the value and benefit of doing that. I don't know how common it is, but when they're trying to make their pitch for the resources they need for all their things, I think it helps if I can sponsor that and even maybe take the budget ownership of I need this person on your team to accomplish these things. 

Brian Selfridge: [00:09:56] I think that's fantastic. Getting, you know, ponying up some cash to help them in their mission and yours as well. I remember that's the first time I made friends with, with my i.t director and one of my early roles and I was like, look, you need this tool, we need that. We need a tool similar to it. I'll cut it in half or I'll, I'll buy it for you, you know, out of my budget. And, and then he was on board for, for then after. Are there opportunities for compromise with server admins? Like a lot of times security comes in hard and strong said you know we've got to patch 48-hour window for criticals. You know, whatever you're five days for, whatever. Is there a time when it makes sense to kind of relax some requirements or have some give on the security side to support the relationship? Or how do you see that that compromise give and take on both sides going, if at all? 

David Jones: [00:10:46] Yeah. To completely not answer your question, I want to say yes and no. Obviously, you know, it's I think part of it, it's just my background of being on both sides before understanding both sides of the conversation pretty well. So when you bring somebody on whose entire career has been security, then they always seem to have an angle of looking at it as this is the way it must be done. If it is not done this way or by these standards, it's wrong. And you've got to be able to peel back from that a little bit. Yes, there are lines in the sand. There are requirements. There are things that absolutely must be done. But with the security of mindset, it's very easy to go a little too far on what you want to do. At the same time, from my leadership position, I want them to be that way. I would rather them ere too far, and then I'm here to pull them back a little bit. And so we've got a pretty good situation now where, you know, the guy that we put over our operations team has some security background as well. So we can take the conflict between his team and my team and then get together and go, okay, what's the right compromise? What's the right level we should have here? And typically the best idea wins. You keep egos out of it, you keep personalities out of it, and you just find the right solution. And, you know, it's it works out well. 

Brian Selfridge: [00:12:07] I love keeping egos out of anything we can. It's like the secret sauce of most relationships and getting things done. 

David Jones: [00:12:14] I'm never attacking you. I'm attacking the idea. Just get that clear from the beginning. 

Brian Selfridge: [00:12:19] So you mentioned we're going to jump around a little bit. So I am going to I'm going to take you up on that. I want to switch and talk a little bit more about a specific type of perhaps server engineer, which is the network folks. The network, I should say network guys. There are some network girls out there, so I want to be sensitive to that. Is there anything different about the way you engage? What are some of the typical intersection points between security and network admins? Is it just VPNs and opening this and closing that or what? Where, where, where do you usually have the most involvement interaction with the network folks? 

David Jones: [00:12:49] Yeah, with the network folks. I usually kind of think of it as, you know, it's your core infrastructure kind of things, your DNS, your GCP firewalls, and then really just the design of the network, the way you're going to segment the network, even being part of those designs. And then I think when you get into DNS, obviously, it gets a little bit deeper now because DNS is a whole lot of protocols around your email now. So whether it's SPF, FD, Kim Dmarc, it's, you know, it's all of those things. And when you're talking about a SAS world and trying to secure those things, it can get hairy. Trying to. You know, work with those guys and understand that everything is both functioning, functioning for the business that's trying to do these new things as well as doing it in the right way. 

Brian Selfridge: [00:13:34] There's always that, like, desire. I always felt like the network folks were like, Let's just make it work. Open it. I want everything to just work. And we're always like, Well, I want it to work, but let's do it with some responsibility. 

David Jones: [00:13:46] From a change management perspective, I mean, the network guys really kind of understand it. You know, they make one speech or one spanning tree change on a switch in their youth and they understand how an unwarranted change can destroy a network at a moment, right? So they kind of understand a little bit more, more so than some of the other teams that slow and steady understand what you're doing. Should. Where's my CIA? Is this an approved change? You know, I think they're much more likely to buy into that than some of the other IT areas just because they see how major a small change can be and how much of an impact it can have on everyone else. 

Brian Selfridge: [00:14:25] So what are some of the common conflicts that you run into? What are the points again where you just have real trouble coming to a consensus? Is it around the speed of a change that you need or the scope and scale of something like a network segmentation of them just saying, yeah, that's too big a challenge, like what are the spots where you just really run up against it with network folks? 

David Jones: [00:14:45] Oh, more recently, it's really wordy. So we're a pretty SAS-heavy company ourselves. So when we go in and we say, Hey, we want to implement this, this dmarc email, SPF, all these different systems, you're not just talking about your exchange server anymore. You're talking about all the different third parties, every service. You may send something on your behalf. And it's I think they're also kind of in that where they get pulled a lot of directions. They're having to support a lot of things that oftentimes they don't know about. You know, before you have kind of a good vendor management system, it's just, hey, this thing can't send email as whatever anymore. I'm like, Well, what is this thing? Where did it come from? And who said that was okay? Right. So, but yeah, you know, traditionally I think of all the, all the conflicts you can have with different areas, I think the network guys pretty well get it for me. I don't have a whole lot of conflict with those guys. 

Brian Selfridge: [00:15:39] Well, that's good. I was going to ask you how to resolve it. But if you if you've got maybe you're in an unfair position of having been in the shoes a lot of these folks and they just sort of respect your position. A lot of I've known a lot of security people that come from maybe in more of an audit background or some other things that that can easily kind of not maybe not have the respect of a network team. Do you know how any recommendations on how one might overcome that if somebody is a little less technical having to engage with these types of network folks so they don't blow smoke at them or. 

David Jones: [00:16:11] Yeah, I think the network folks, there's a lot of specialty spills there. There are a lot of things that it's almost kind of even back to the security guys. They kind of want you to understand what you're asking. So when you just walk up to the network guy and say, hey, I need this to work, well, what is this? Why? Why is this? You know, it's just. I'll try to think through that a little bit better. 

Brian Selfridge: [00:16:32] But the kind of a do your homework, make sure you do the best you can to know what you're talking about for you before you show up. 

David Jones: [00:16:38] Yeah, but at the same time, I want to say that out loud. I know that's a hard ask when you know, you're just the audit guy and you've never understood what a firewall can fake looks like or, you know, being in the iOS and not forgetting to write right mem one time and the damage that does and just a lot of the background there not having that, I think that makes that difficult. But yeah, I think it's just a little, little bit of training. A little bit. You know, it's one reason why I think for a lot of security people that are kind of getting into the field, they'll tell me what training is they get, what certifications should I get? And I throw out some security certifications, but I also throw out something like a network plus like get that base network knowledge. You need to understand what it is you're trying to secure. It's harder to secure it if you don't have that base knowledge. 

Brian Selfridge: [00:17:24] It's fantastic guidance and I think, well, I'll steal that and cite you appropriately for that, that recommendation. I think that's an awesome one. So I want to switch gears a little bit and talk about development. You mentioned them a little bit earlier and sort of dealing with the development team a little bit differently than you would the server admins, for example. So let's talk about that group. Where do you where do you engage? When do they bring you in? When do you bring them in? And how does that go? What are the sort of interactions there? 

David Jones: [00:17:51] Yeah. So as far as interacting with them, it's, you know, getting into their release cycle for their code, understanding, change, control. Obviously, you want to look, look at the code, do the right code, review the dynamic scans, configuring pen test. And sadly a little more recently, a lot of the third-party libraries SCA, your SBOM those kinds of things that obviously no one was thinking about a few years ago. 

Brian Selfridge: [00:18:16] Yeah, that's changed quite a bit. So do you only deal with in-house development teams or do you ever have to engage with vendors or folks that are sort of building stuff on your behalf? Or is it mostly just in-house? 

David Jones: [00:18:29] For us, it's been in-house, what, a little bit we have done, you know, kind of outsourcing. We have been very restrictive. So it's not we're giving you any of the code, any of that. It's connected to our VM infrastructure work on our stuff. Obviously no access to production. So we've been pretty, pretty tight with that thus far. 

Brian Selfridge: [00:18:48] So what's some of the pushback you get from the development teams? Is it that is it the tension of them trying to get something out to production, get to market speed to market kind of thing versus your perceived as slowing things down with these additional checks or hey, you got to get that pen test done or the code review, is that is it mostly around that type of thing or where else do you run into conflict with these groups? 

David Jones: [00:19:11] Yeah. So it's just as you said. Yeah, it's priorities. It's the business with their objectives. It's, you know, trying to, you know, speak, understand the language enough to say, you know, this is a tech debt item and understanding how to get that priority. But you've also got a little bit of of of distrust from a lot of developers about the tools that you're using, whether it be the static analysis or the dynamic analysis. It's just, well, who's this company to say that my code is no good or I've been doing this for 30 years and I know what I'm talking about. I'm like, I'm sure you do. However, let's look at this. But, yeah, it's really those, those two pain points is the priorities and the tools themselves. 

Brian Selfridge: [00:19:50] Now. Has it gotten to a point? I remember years back I'm dating myself here a bit, but you know, a lot of the testing with development was pretty manual. There were some tools out there, but they were more kind of like hacker tools, honestly, that you're you're running SQL injection scans and different things to try to see what's broken these days is it almost entirely is are the tools good enough to really operate on their own? Or do you need to do some manual poking and false positive checks so that you don't get development teams yelling at you for something? That's obviously not a problem. 

David Jones: [00:20:21] Yeah, no, I think you absolutely. It's still more manual. It's not as mature as you'd like it to be at this point still. But there's a lot of and again, it kind of goes back to how I was describing my security guys. I want it to be a little bit overzealous and be like, Hey, this might be a problem. It might not, but it's not going to be good enough to determine 100% yes or no that this one is a problem just yet. So so yeah. So for us, the kind of the way we did that initially, it was just me. It was, okay, here's our new static scanning tool. We're going to use this. And, you know, initially, we get some pushback. And I think one thing that really helps is just getting somebody to kind of be your security champion on that team. So when you've got two developers that are coming back to you saying, oh, this is garbage, there's no way that this is actually this could actually be exploited. And then you have that one developer coming to go, well, actually, if I did this, this and this and put the data in this way, then it actually could. 

David Jones: [00:21:15] And I think that's where it's hard coming in. And this is where, you know, I have the advantages on all the network and server and all that stuff. But when they start talking development, you know, I did some light scripting and development 30 years ago. I'm not I can't speak the language of what they're doing now. So I finally had to bring in a position basically on the team that that that's exactly what they were. It's an application security specialist who has as part of my team but is as embedded as they can get. So they're in their scrum meetings, they're in their reviews that they do. And so that they and they, they've got that coding background so they can take some of the things that pop up. And before we bother any developers, we can go in a little bit and try to sanity check that and see, is this a real issue? Is it not a real issue? All those kinds of fun things. 

Brian Selfridge: [00:22:06] I love this idea of cross-pollinating teams. We talked about embedding some security people into different teams. I've seen it work the other way, too, where I at one point in my career, I hired a server admin that didn't have a ton of security experience enough to be dangerous and brought him into the security fold, made him the security engineer, but he came out of that group, so he ended up being full-time security. But because he had that background with that group, we were able to really get a lot more traction. I wonder if there is there's more of that cross-pollination. Maybe there are people in infrastructure that are kind of tired or burnt out on running through the same paths and on the same hamster wheel for a while, like, Hey, why don't you come do security stuff? We'll bring all your knowledge in and teach us some security things and make you a well-rounded person. Do you think there's something there to that to that direction? 

David Jones: [00:22:51] Absolutely. I think the best people that I've brought into security have kind of come down that path. And it kind of goes back to what I mentioned earlier, where you need to understand the thing you're trying to secure. You know you get somebody just green just out of high school going, you know what, I want to get out of security. And there's a lot of things out there, whether it be the hack, the box or doing this or doing that. And really most of the biggest problems, in my opinion, in security are not being able to go in and break something. It's being able to go in and configure a server to operate the right way to apply the, you know, the baseline security configurations across your enterprise and to understand how to audit that and know where you are. So being able to take people from that background, who's got the right mindset and convert them into security. To me, that's where I've gotten the best people so far. And I understand that when you try to say that out loud, you start hearing a lot about gatekeeping and that's not you don't have to have it experience to get into security. And I've done it both ways, you know, brought somebody in clean off the street. And it's it's difficult at times when they're like, well, what's this port what's this port open for? Like, you know, do you not know what Port 80 is and why that should be closed? And they just don't have that base knowledge, you know. So it's I think in every area. So whether it be development or infrastructure, the person you want securing is somebody who understands it well enough. And then you can train the security on top of that easier than I think just taking the security guy and training them, the infrastructure and the backgrounds that you would want there. 

Brian Selfridge: [00:24:27] I think that's a fantastic point. I think that hits home with the data we're seeing out of the breaches this year, last year being so dependent on misconfigurations, it's not it's no longer that the cloud environment isn't hardened enough to use that basic network security, and those types of things. It's just we just set the wrong flag the wrong way. And that was really the root cause of it. I do want to go one more thing on development before we move off of those. What are some things you think we can do to better grease the tracks, if you will, with the development teams? Is it is it rallying behind a process and methodology, SDLC security process or an OWASP thing or what is it? Does that help or is it just this pure relationship-building stuff? Or what do you think are sort of some of the best ways to really get the engagement between development and security working? 

David Jones: [00:25:12] Well, yes, I think it's all those things. So like I said, we went out and we hired that one person that kind of sits with all their teams. But that's not enough to, you know, when you get enough teams, that's not enough to really influence everything. So on top of that, we've also established here semi recently a security champion. So we've got one security champion on each of our scrum teams as well. And then our application security guy is giving them additional training and we're making sure we go actually we send off training to all of our developers, but we're giving them a little bit deeper OAuth training. We're actually putting together kind of an internal certification program, right? So we'll put some kind of rewards behind that, right? Like, hey, these, this team has all their developers benefits, whatever, certified, right? You know, we're still kind of baking that one out, but I think it's a lot of it is relationship, a lot of it is getting the right tools at the right time. I think being flexible with some of the tools because some of the technologies are keeping up and then some are not. And you just got to be willing to listen. And like you say, you've got those lines in the sand, but obviously they're going to have valuable opinions about the way things should be done as well. So it's just keeping those communication lines open. 

Brian Selfridge: [00:26:25] I want to cover one question that comes up a lot. There's development teams we talked about. There's also DevOps, maybe just the for the listeners. What's the difference between development and DevOps generally? And then we can talk about if there's a material difference in how to manage those groups. 

David Jones: [00:26:39] Yeah. So, so for me, to me, you know, development is really just that that's the all your guys sitting at the keyboard typing in all the code, putting in, you know, making the things do the stuff with the stuff. When you get into DevOps, you really kind of get more into how are you going to deploy this application. How are we packaging this up? What's our full CSDs pipeline? How can we spin up more environments? Is there a way to automate speeding up that environment? So, so yeah. To me, I think Dev, dev and dev ops are very different in the way that we kind of look at them and treat them. And I think we maybe have done it a little bit different here where our DevOps team reports up to our infrastructure team, which I don't know if that's normal or not. I feel like those guys can sit a few different places, but a lot of times they seem to spin out of development more so than operations. 

Brian Selfridge: [00:27:31] Yeah, it's a mixed bag from what I've seen as well. So with that group in particular, is there any what are some of the intersection points or conflict points you have with DevOps that might be different from, like we said, sort of the SDLC development type people? 

David Jones: [00:27:45] Yeah. So Intersection Points really is going to be finding the right place in the CICD pipeline to do the things that you want to do. So, you know, when and where, and how should we be doing the static code scans? At what point should we be checking the security configurations? And even as part of that whole process, just how do we factor in the approvals for the change control processes and all those kinds of things? When you start to get into conflict, this is one that is probably my pain area here. I don't have as many great answers here, but because a lot of the DevOps methodology is, you know, go fast and break things. They want to have the autonomy to go out and find these new tools and do these things and, you know, just throw stuff against the wall, see what sticks kind of set up, which can be difficult. They. They also seem to be a little too loose at times with just, hey, we're going to spend this new application up and. And now, now your whole attack surface reduction project is. Well, wait a second. What is this thing? Where did it come from? And why is it running this old, old TLS version? Right. You know, or whatever it is? So so I think for me, that one is going to be a lot of just defining and figuring out where the guardrails are. I think you want to give them that autonomous bubble to work in, but you've got to have that line that says you can do whatever you want in here, but you can't go past this point until all the right people are involved until we know what the tools are. 

David Jones: [00:29:18] A lot of that gets back into almost like the third party libraries. It's just there's nothing is safe anymore. You've got to have that list of these are all the tools that we're using. This is the right configuration. If I get a news article that tells me there's a giant breach in X, I don't need to go asking people, Hey, are we using X? You know, we need to have that list of these are all the technologies we're currently relying on. But at times they don't seem to want to play. Well, it's, it's I, I worked for I, I support ops, I work for dev. Why are these security guys bothering me? So it's they're trying to balance enough priorities, I think, between ops and dev that having security come in there as well can be a bit frustrating for them. But this is also an area it feels a little bit immature. And I don't mean that by the people, I mean that by some of the tooling. So the tool that worked great for you last year may not be able to support the new languages and the new pipelines and the new tools that they're wanting to fold into their whole processes. So you've got to be a little more nimble with the different tools that you're using to try and keep things secure and configured and all that. 

Brian Selfridge: [00:30:29] What's funny, a lot of the things you said about DevOps, I sort of have heard said about us as security people in prior years, like I'm a pen tester early by trade. And, you know, we were always accused of wanting to break things and go too fast and ask for big, you know, just segment the network no big deal. It's like we often sort of we're trying to go fast on very big and complex problems. So I'll have a little empathy with DevOps on some of those fronts. But let's switch gears again. We're hopping around this is sort of the round-robin of groups we're going to talk about here. So let's let's talk about somebody really kind of different. And that's The Help Desk, because they're going to be less technical in some aspects. No disrespect to help desk folks, but certainly less technical than a server engineer or somebody a little more highly trained in that area. So maybe let's talk about what are some of the intersection points between the help desk and security, whether that's incident response or where do you really spend the most time engaging with those groups? We'll kind of start there. 

David Jones: [00:31:27] Yeah. So we've got asset management is a big one. You do typically the ones that are setting machines up, handing those out, a lot of the secure deployment, you just kind of get to understand their processes and how they are onboarding users and making sure they're turning users and all those fun things. But like you said, instant response. You know, these guys really are your front line between the company and all of it. So they'll typically be the first ones to hear something and just it's kind of an intersection point kind of cheating a little bit. But this has become kind of a training ground for us to bring in some people onto the security teams. 

Brian Selfridge: [00:32:05] Why is that? What is it about their experience that makes them good candidates for security functions? 

David Jones: [00:32:12] It's really you know, it's kind of the whole typical career path. You know, your server admin starts off working on workstations and you can be a little bit loose and you can break things on a workstation. Then one day you kind of get that frame of reference of, okay, I can't go past this line, and now what you're doing on a workstation is safe for you to do on a server or to do on a large application. So it's just I think it's two things. One is getting some of that just basic experience of dealing with a little bit of everything. You're going to get calls about somebody's home router, you're going to get calls about an application, you're going to get problem with hardware. So you get a wide swath of areas to get involved in. And you also get to really just kind of see somebody's troubleshooting mindset. How deep can they understand an issue? How far can they go before they are? Are they single-threaded or are they kind of multithreaded in the way they attack problems? So I think and you're ones that could really see it multiple ways and kind of understand the larger picture are ones that, okay, maybe I start giving this guy some stretch projects from the securities work environment. We could use some help to see if they kind of latch on to it and if they'd be a good one to pull up into the team. 

Brian Selfridge: [00:33:20] Are there points of conflict with the Help Desk? I mean, is it I really need you to jump on that malware ticket when I put it in, it's a pretty big deal, you know, or what is it where you maybe run into some issues from time to time with those types of groups. 

David Jones: [00:33:35] Yeah, yeah. You've got, you've got that as you mentioned, but then you've also got a lot of it's very communication-related. It's when security changes something, whether it be a configuration on a proxy or something about a firewall. The helpdesk hates surprises. So when they get 5 to 10 tickets about something that you just did and they didn't have a heads up in any way. Right. That can cause some contention, like, what are you guys doing? All right, we're going to take all these tickets and throw them to your guys now. So it's really it's just that it's all communication. It's just understanding what tools we're running out. Are we updating an endpoint? Are we changing out the security tool that's touching each endpoint or touching each person and just making sure that they understand what's happening. So if they do start to hear some noise, they kind of know where it's coming from. 

Brian Selfridge: [00:34:23] So very practically, how do you do that? Right. Is this mass email blast to the helpdesk team? Every time you're going to do something, is it change management? Like, how do you make sure that bidirectional communication is happening? I know that's very much in the weeds, but I think that's where some folks struggle to make it happen. 

David Jones: [00:34:40] Yeah, and I think this is one where when we were, you know, whenever I was sitting in one office and kind of could hear each other over the cube walls, it was it was a little bit easier. You know, you could kind of hear what's going on now in this kind of post-COVID world where everybody is everywhere. We have established some things like, you know, we're a big team shop and we used to have different team channels where it was just kind of, you know, help this team over here, security team over there. Now we've got, you know, a group that has our security team, our operations team, our infrastructure team, and our helpdesk team all at the same one. And it's not just the chat channel, it's spit it up a video chat channel that just runs all day long and kind of sits in the background. So obviously when you've got a meeting, you hop out, you can hop back in. It's more of an optional thing than a mandatory, but it's kind of fit that bill of, Hey, we're all kind of sitting in the same room together. Somebody will mention something like, Hey, does anybody know what's up with whatever. And you know, we're all aware. So you're talking there and that's just worked out really well. It's kind of especially now that we started to hire people not in the same state as everybody else, it's really helped to kind of help push the culture out to everybody. Everybody can talk, everybody's there. And I think it's just overcommunicate as much as you can about things that we're about to do to you that you may need to be aware of. 

Brian Selfridge: [00:36:07] Now, does that also help with just general relationship building, or are you guys in that meeting and people are popping up memes and stuff to keep things light? Or is it all business? 

David Jones: [00:36:17] Oh, no, it's as much meme as it is business, but it's not. But yeah, it's at one point I think some of these guys even and it's just kind of gets out of stuff that I deal with too much. But it was, Hey, who wants to do a Dungeons and Dragons night? And I think they did that over teams at one point. So yeah, it does good just to have those relationships because I know when you're just talking email especially, you know, we hire some new people about a year ago and we had a couple of things we wanted somebody to look at. And so we email some of the new guys like, Hey, can you check out the dinner today? We have this security issue with whatever. And the next thing we know, the server has gone off in the middle of the day. We're like, What's going on? Well, the security guy told me this had to be done. No, no, no. You read that email with the wrong intentions that that was a hey I'd like you to look at. So having those people in the same shade or having those actual conversations and talking and understanding somebody's mindset and the way they operate and where they're coming from, you need to have that relational equity there to really be able to read and understand what people really mean. Because just the email, it's too easy to read those things the wrong way. 

Brian Selfridge: [00:37:28] Makes sense and I'm sure pre-COVID and maybe to some extent there's still probably some value to like take a guy to lunch or take a team member, you know, like go and get to know them a little bit outside of work harder to do now than it was, but I think still some value there. I want to talk a little bit about so if we talked about a bunch of different groups here, one of the area that areas I. Think is can be common across them is this whole idea of the audits we have to go through and the concept of audit fatigue, which comes up when you're the security or the compliance people, or just keep asking these same stakeholders for evidence and how do you do this and where is your procedure and what's this and that? So that can be tricky, whether that's for a SOC to audit a high trust certification, PCI. I mean, it could be anything, right? Do you have any recommendations or thoughts on how to how to ease that burden on these teams for for this sort of audit fatigue problem, if that's if it's even possible? 

David Jones: [00:38:21] Yeah, I think the first step is just going to be you have to standardize on something. You need to decide this is what we are going to have and this is what we're going to have available to our clients so that you're hopefully just doing that, that one audit per one main audit per year, so that you've got those artifacts. And, you know, because we're in being in the pharma pharmacy benefit optimizer space, you know, we're working with a lot of companies. And, you know, at one point we're like, well, we're health care. We should be looking at HITRUST. And we, you know, talked to some of the people and they're like, what's the HITRUST, right? Because they're not in the health care space. They just are using us for their benefits. Right? So so they all speak SOC2. So we settled on SOC2 is what we're going to go with. And I think before you can kind of get to a point where you can kind of establish that whole having an audit and package to kind of give to clients, you're reacting to a lot of one-off. It always seems to be about 220 questions, questionnaires, and spreadsheets, and they're all a little different. 

David Jones: [00:39:24] Everybody is a special butterfly. You can't just copy paste the answers from one to the other. So I think we're currently working on getting a true kind of GRC process in place with the GRC tool, so that I'm just asking these questions of my teams once a year. It's not only that, it's here are the things I need to have. How do you track this? So even if our GRC system is pointing to their Confluence page or their JIRA tickets or their folder where they store these network diagrams, it's just trying to make it as easy as we can on those guys and trying to make it a single-threaded. Just it's going to come from this person at this time because yeah, early on the audit fatigue was real. It was just every couple of months it was this big client has all these requests and trying to dig through all that stuff can just really bear down on a team that is already busy and has a lot to do. And some of those can be come in like a train wreck to the productivity of that team. 

Brian Selfridge: [00:40:25] So one other area that I think is is common that seems to come out in this conversation, too, that's common across these groups is the need to have more training, knowledge, awareness, education on of security topics as well as of infrastructure type of capabilities both on security teams and embedded in within it. So in that vein, I noticed you I've I follow you. This is what social media does, right? Follow you on LinkedIn and notice you do that cyber places to be in these different conferences that are out there. Are there any conferences or industry groups in the cybersecurity front that you've found to be better or worse than others? Just if there's The Help Desk admin looking to get some experience or exposure and wants to do a security thing. So just in general, any, any tidbits you could share with the emerging security people of the world? 

David Jones: [00:41:14] Yeah. So I'm a big fan of all the local groups. This is one of the things when I first got into security back in the I shouldn't even say how long ago it was, but, you know, I got my CISSP way back when it's like 20 years old now. And so I'm looking out for where could I get CPEs, right? And that's what kind of opened me up into some of these local groups. And compared to other industries, it's amazing how many people just want to get together and share ideas and bounce things off other people. And it's very much we're all in this together. And that's one of the things that really got me to stick on the security side of the house more than anything else, just how willing people are to help you if you're a student, how willing they are to try and give you guidance on what to do to get there, put in programs. You know, some of these organizations put programs together. So, you know, locally I'm involved heavily with ISSA. I've been with InfraGard for a long time. And, you know, InfraGard here kind of predated I as I say, I saw a local here, you know, trying to support the wisest group that we've got in town. And it's just I think it's each one. The people are a little different. I would say try them all and figure out where your people are and maybe they're in more than one. The only kind of knock I have right now in a lot of organizations is typically it's one or two events a month and then you're away. And, you know, it used to be everybody had a mailing list and you could kind of communicate all the time. 

David Jones: [00:42:45] But now we're so segmented on. You've got your Twitter group. You got your LinkedIn group, you got your discord groups, you got your, you know, some people hanging on to the mailing lists. And it's kind of funny because you kind of see by a generation where they are. I got the graybeards on a mailing list and the young kids on Twitter and I'm like, How do we get all these people talking together? Because there's too much knowledge from one that needs to be passed to the other and questions that need to come up from the other. So I think, you know, locally those groups are great in town. I've tried throwing together a discord. I invite all the groups like, Hey, let's keep this conversation going all month long. This shouldn't just be an occasional thing. When you need help, you need to reach out and get help. So. So yeah, locally, all those groups conference-wise, you know, I'm usually not a big conference guy. I, I'm enough of an introvert that I can be alone in a room of a thousand people. It's kind of how I'd describe RSA for me anyway. But you know, the local conferences, the B-sides are all awesome. That's typically a lot of people at a B-sides wanting to just train people up and show them what they know and bring them up. Um, and of course, I don't know if you're familiar with the Cyber Health Working Group. If you're in health care, that's been a fantastic group that it spun out of. Infragard is now run by NCFTA. But that's been a very good, like-minded group of people. 

Brian Selfridge: [00:44:10] Yeah, I have to. You mentioned CPEs. I have to put a plug-in for those that are listening to this. If you have a CISSP or other cert that requires CPEs to listen to the podcast counts. So put it in there, put it add it as an entry. And for the Davids of the world that are actually being guests on this, you get like double credit for producing a podcast and something for the industry. So don't forget to put that in the list as well. Also, another quick plug like we do these the quarterly or every two months health care security leader roundtables in a couple of different geographies and now mostly virtually. So if anybody that's listening or yourself as well want to join those sessions, those are great because it just cuts through all of the need to have the tech to get the messaging. And we just hone in on a couple of hot-button topics for the group and talk through it. And then sometimes that helps a great deal as well and building the relationships so you can reach out to those people at another time as well. Kind of really helps. So with that, I guess I want to get you back to fighting the good fight on everything that we've talked about today. Are there any other closing thoughts, or insights you might have on just generally working with i.t. Ways to ways to just improve that process or just recap any of the key points from your perspective? 

David Jones: [00:45:23] I would just say it's all about relationships. It's all about understanding where somebody is at any kind of meeting them where they're at. So I don't have any kind of big nuggets of wisdom to just drop. Sorry, but I think. Yeah, just. Dive in. Understand where they're coming from and be open be available. And, you know, as you said, I think it's you can't come in with with the hard line. It's got to be here's where we need to go. Help me. Help you. How can we get there together? 

Brian Selfridge: [00:45:59] See, I think you dropped a ton of nuggets of wisdom, so I'll have to mine them out. I'm sure others got. I got several myself. I'm sure many of the listeners did as well. So really appreciate you taking the time to do this today. So I'd like to thank my guest, David Jones, who's the director of Information Security at RX Benefits, Inc. David, thank you so much for taking the time to join us and sharing these insights with our listeners. It truly is a pay-it-forward kind of thing. 

David Jones: [00:46:22] The best place to do it. 

Brian Selfridge: [00:46:27] Again, I would like to thank my guest, David Jones, who is the director of Information Security at RX Benefits, Inc.. I really appreciated David's insights on finding ways to improve relationships and communication across different teams, both within and outside of security. Getting team members embedded in security and infrastructure and vice versa makes a lot of sense. Getting these large groups and teams meetings together to work together and have fun together. It's just another great suggestion. One of many. I learned a ton from David today, and I hope you did too. As always, we'd like to have your feedback and to hear from you, our listeners. Feel free to drop us a note about what topic you'd like to hear about or a thought leader you might like to hear from. Our email address is [email protected]. Thanks again for joining us for this episode of CyberPHIx, and we look forward to having you join us for the next session coming up soon.