Join the Block Party: Healthcare Use Cases for Blockchain

PODCAST TRANSCRIPT

Brian Selfridge : [00:00:16] Hello and welcome to CyberPHIx, the audio resource for information security, privacy and governance for the healthcare industry. I'm your host, Brian Selfridge. In each episode, we will be bringing you pertinent information from thought leaders and healthcare, information, security and privacy. In this episode, we will be speaking to Chris Golden, who is the director of information security for Horizon Blue Cross Blue Shield of New Jersey. I'm excited to speak to Chris today about two topics that are getting the attention of healthcare security leaders. The first is blockchain and related technologies and its use cases specifically for healthcare. The second topic we will cover is enterprise risk management and figuring out how to make sense of the flood of available risk data to drive meaningful risk-based decisions for the business. We would like to hear from you as well. So if you have a specific topic or thought leader you would like to hear from, just drop us a note at [email protected]. That's CYBERPHIX @meditologyservices.com. Now let's get to our interview. 

Brian Selfridge : [00:01:23] Hello and welcome to CyberPHIx, this is Brian Selfridge, your host of the leading podcast for information, security and privacy, specifically for the healthcare industry. I would like to welcome my guest, Chris Golden. Chris is a seasoned thought leader in information security with experience protecting sensitive information for the Department of Defense, Finance, Banking, and Healthcare industries. Chris currently serves as the director of information security for Horizon Blue Cross Blue Shield of New Jersey in healthcare airspace. So, Chris, thank you so much for joining us. We're really excited to have you on CyberPHIx today. 

Chris Golden : [00:01:56] Thanks, Brian. I'm excited to be here, too. Thanks for inviting me. 

Brian Selfridge : [00:01:59] So let's talk about blockchain a little bit. This is one of those favorite industry buzz words that's gotten a lot of attention for good reason. But I've noticed in talking with peers and colleagues and clients and everybody else that there's not a really strong understanding of what blockchain is. I mean, I think there's some rough sketches that folks have in their mind. But just for our listeners just to level set, Chris, could you give us a sense of what is blockchain and what does it do at a very high level? And then we'll talk about how we can use it in healthcare. 

Chris Golden : [00:02:31] Yeah, sure. I think I've seen the same thing as I talk to people. So at a very high level, blockchain is a distributed ledger technology, a DLT. And as you can imagine from the name, a distributed ledger means that there is no central authority that controls that ledger. So if you think about when you go work with your bank probably right now, your bank has got your ledger. If they think that you had money taken out of your account or money put into the account, that's the central authority is telling you that for your account. Where in a distributed ledger environment, everybody has a copy of that ledger and everybody sort of has to agree  that money has come out or that money has been put in or that kind of thing. Blockchain is very specific to Bitcoin if you want to lose friends at a party real quick, point that thought out when someone talks about blockchain is that they're really only talking about what Satoshi Nakamoto and his crew did was create Bitcoin. Of course, nobody has come out yet and said that they are Satoshi. They are the ones that created Bitcoin. But that's where the first blockchain was created, and now it's got a whole bunch of different uses. But it's basically a distributed ledger that everybody sort of agrees on what the correct answers are in terms of what's in your account or what's not in your account. And it could cover anything from Bitcoin, you know, monetary stuff, to art, to things we'll talk about a little bit later, like member IDs that can carry a whole bunch of things. It's done very securely, a lot of different encryption. And basically, once you put something on the blockchain, it is immutable, it does not get taken off the blockchain. So you have to be very careful with your errors, what you're putting on the blockchain. But it's a new technology that has got the potential to disrupt a lot of industries, I think. 

Brian Selfridge : [00:04:05] So how does blockchain impact healthcare? Obviously, maybe not all that much today, but where do you see some potential use cases of the technology for healthcare, healthcare security, healthcare, I.T. or otherwise? 

Chris Golden : [00:04:18] Yeah, so watching the applications in healthcare I think are mainly in the back office world. I don't see a lot of applications, where the doctor themselves are putting information on the blockchain necessarily in the beginning. But that will happen over time. But in the back office stuff like tracking member IDs. Right. That would be something that would be very easy to stick onto a blockchain or a distributed ledger technology that people can check, make sure that the right members got the right status in terms of payment of different dues, so they can actually get healthcare provided to them by the providers. So that's certainly one area where I think is a very easy way to do that. It's not a lot of what we call PHI, personal health information, if it's just a member ID, even though that is one category of PHI. But it would allow a large number of people, providers, payers, the member themselves, to sort of see what's going on with their record as it's moving around the world in terms of them going to see a provider, them getting approved for the treatment, the treatment occurring, some kind of money getting moved around to pay for that kind of stuff. So I think a member ID is certainly a great way that blockchain could help healthcare and healthcare security. And that would prevent obviously a lot of fraud, where someone uses your name and your I.D. to go get treatment that they may have not otherwise paid for. That's a pretty big deal in the healthcare insurance world. 

Chris Golden : [00:05:37] Talking about patient records, the electronic medical record is here to stay. Obviously, a lot of different companies provide that. Most hospitals and providers are using them. So being able to put those records on the blockchain and allow them to be moved around the world again. So as you go from your primary care provider to your specialty care provider, to your surgeon, et cetera, et cetera, that record can flow with you via the blockchain and people can access it with the right access and identity access management kind of protocols in place. So that's another area I think that blockchain can be good in. I sort of touched on payments, you know, show the money flows right now. There's a pretty big disconnect between when you go see a provider, when that provider requests payment from your insurance company, when your insurance company actually pays the provider, et cetera, et cetera. You usually see that in some kind of explanation of benefits or an EOB much later on down the road, and it's usually a month or so later by behind all that, that stuff is moved around the world. If it was on the blockchain, it might happen much quicker. So that would make providers probably very happy. It would probably make insurers probably very happy. Opens up some avenues for fraud. So you've got to be careful of that. But making that payment process sort of the clearing and settling of the payments, I guess is a better way to say it. Much easier. I think that's a block way, a good chance for a blockchain to use it. 

Chris Golden : [00:06:52] And then we touched on the EOB, the explanation of benefits. I think that's another great thing where you put it out there and it says, hey, we show that you went to the doctor to get four stitches from a fall, here was the cost. Here's your copay, here's your deductible, etc, etc. and now it's on the blockchain and everybody can see that. So you can sort of keep track of where are you out on your personal healthcare plans. So you know better where you stand in terms of your deductibles and co-pays. So I think those are some areas that blockchain has the ability to really impact healthcare and the actual providing of healthcare to a member. 

Brian Selfridge : [00:07:23] Does this get us out of the business of tracking Social Security numbers everywhere, several times over? I know that's a big challenge of just how the pervasiveness of SSNs. Does blockchain help with that, or does that just become an attribute somewhere in the blockchain record? 

Chris Golden : [00:07:39] Generally in blockchain security, you don't want to put either, in my case, PHI, private health information, or in the larger case, PII, private identifiable information, personally identifiable information, on the blockchain, because once it's there, it can't be taken off. So if you were to have, let's say, a design flaw or a security glitch that will allow people to see that, now they're getting access to it, and you can't take it off the blockchain. So the best practice is to put that kind of information off the blockchain, maybe in a database somewhere, where an API would call out from the blockchain to get that data and do something with it, may be update it and then come back and say that it was updated in the blockchain. But it's not generally a good idea to put that kind of stuff actually on the chain. So I think maybe a member ID or something like that, if it was generic enough that you really couldn't identify an individual by that simply member I.D. without making that database call. That member ID on the blockchain is probably OK if a bad guy were to get access to it, what are they going to do with it? Not real sure, there's a lot of use cases there for just a randomized member I.D. Now, if they can get into your database and tie that back to the individual person, now we've got a problem. But that's a couple different steps they have to take to not only break the blockchain data to get the member I.D., but then to break into your database to figure out who exactly which person that is. So getting away from social, certainly is the better way to go. A maybe universal national member ID kind of thing might be a way to go, but that would probably just end up replacing the Social Security number and bringing with it all the same problems we saw with Socials. So it could do it, but I think there will have to be some really good thought put into how to do that to sort of get rid of the Socials. 

Brian Selfridge : [00:09:11] You mentioned earlier about the potential for errors or glitches. So there's either data errors, like oops, I put my social or my personal identifiable information on the block. How do I get it back? Or maybe the technology goes on the fritz somehow. I know it's decentralized, but just we'll use our imagination that things could go wrong with it because we're professionals and that's what we do. Are there any sort of potential glitches that you could foresee being a big problem with this technology or ways for us to think about mitigating some of those circumstances? And do we need backup processes? Do we need to have some fallback in the case that the technology just doesn't do what we need it to do? 

Chris Golden : [00:09:55] Sure. So one of the sort of fundamental building blocks of DNA, if you will, of a blockchain or a distributed ledger is the fact that it's distributed. Right. So if you look at the Bitcoin example, there's about 20 million people around the planet that are part of that distributed ledger. And so you would have to update 51% of all those people to break the blockchain trust that currently exists with Bitcoin. That's not a trivial act. That's not something that is really simple to do. And so that kind of system level integrity is really built into the blockchain. So if my version of the distributed ledger on my computer happens to crash because my computer OS crashes or something like that, well, there should be a whole bunch of other people that have the distributed ledger on their computer, and we can easily recover it to my particular system where someone's got a question, maybe they've come to me and I can't answer, we have to send it someone else. But the fact of the ledger is distributed is sort of a fail safe system to allow some of these kind of things to happen. So that's a good thing. 

Chris Golden : [00:10:54] But when you talk about data errors, once you put it on the blockchain, it's immutable, it never comes off. So let's say you were supposed to go to your doctor and you were supposed to pay $30 in deductible and your deductibles total for the year is 500, maybe somebody typed in 3000 instead. Well, how do you change that? It's very difficult to go change that. You'd have to go in and make another entry to the blockchain, basically removing that $3000 addition to your account and then have it corrected to $30 because it is. Once it's on the chain, it doesn't ever come off. And so you have to be very careful with that quality and double checking before you place it on the blockchain. But once it's there, it's pretty secure with the encryption level things, the hashing things we do to make it secure. 

Chris Golden : [00:11:38] And like I said, more than one person sort of owns it, wherein my case, at Horizon, if we've got one database there, and somebody hacks into that database, they've got access to everything. And if they change anything, there's really no way for me to figure that out, maybe until it's too late. But with the distributed ledger, if they make a change, I should see that change because the next version of the chain that comes out, the next block that is added to the blockchain will show that change that mine is different than everybody else's around the planet. So there's sort of a check and balance there to try to keep some of that out. So there certainly are issues in terms of data quality and making sure it's the right data on the right person, et cetera, et cetera. But we face those no matter what system we choose. But in terms of failsafe and disaster recovery kind of stuff, that was one of the building blocks of a distributed ledger was to sort of have so many people own it that no one person could control it. 

Brian Selfridge : [00:12:25] Do you have a sense of how the infrastructure for blockchain is funded and implemented? Is this something where there is some central capability that's built and then everyone sort of builds there or fixes in? And it's a decentralized funding model in a way. I'm just wondering how does this gets built and who builds it and how do we play with it? 

Chris Golden : [00:12:45] Yeah, there are a number of sort of distributed ledger technology brokers out there. I'll just talk on IBM because that's the one I know the best. But IBM's got a distributed ledger that they can modify for almost any industry that wants to use it. They provide all of the infrastructure for how to use it. They provide some of the security controls and encryption and they, of course, allow the user to use their own. So it is a shared security model, sort of like going to the cloud. But that infrastructure is there, and you just basically buy the system like you would a commercial off-the-shelf kind of product. Microsoft Word or something like that. And then you use it. So there are players in the space. In terms of funding it, if you're going to build it yourself, I would say the best course of action is to get a consortium of all the potential stakeholders involved. You know, if it's an insurance company, you would probably need to talk to the providers. You would need to talk to the regulators. You would talk to a whole host of people, the pharmacy companies, et cetera, that would be involved in this and get them to maybe all chip in a little because they can realize the savings. Again, I think mainly on the back end in the business processes, which happens sort of after a member gets seen by a provider. But otherwise, I think it's just part of your budgeting process. So if you decide, hey, I'm going to spend three hundred thousand dollars on blockchain this year, you go to somebody like IBM and go, hey, what does that give me in terms of infrastructure and is it a fast solution, et cetera, et cetera, to do those kind of things. But it should not be a huge expense on most people's part, unless you're going to try to develop it on your own. In which case, I again, I would recommend sort of getting a crew together and doing it as a team versus individually. 

Brian Selfridge : [00:14:16] So healthcare tends to lag behind other industries in its adoption of emerging technology. Not always, right. I mean, sure, there's been some capabilities, analytics, and things we've been out front on. But do you think blockchain has implementation to be likely in the next five years, ten years? How far out are we before you think, and I know that's not a fair question, but what do you think? Are we close to being able to apply some of this? Or is it really still quite a ways away? 

Chris Golden : [00:14:47] No, I think we're closer than farther. You know, the biggest thing that stopped the banking and finance world from jumping on the blockchain bandwagon were their regulators. And it will be the same in the healthcare space. Getting the regulators comfortable with the technology, getting the regulators comfortable with sort of what's going on, how it works, what are the security issues, et cetera, et cetera. Once they get comfortable, I think we can be off and running. It's going to take a while to get there. Right. You mentioned that healthcare tends to sort of lag behind. Most of the healthcare regulators in this space are, you know, providers or insurers, something like that, they're not technologists. And so we've seen more technologists get added to the regulator space in the banking and finance world to address this kind of things. I think you'll see the same thing eventually in healthcare. You're going to see a regulator specifically hired because of their technology background to help do this with the providers and the other regulators that we look with. 

Chris Golden : [00:15:39] One of the bigger things is probably the cost for providers, right? I think most of us have walked into a doctor's office or a dentist's office, and there's a bunch of shelves behind the front desk just full of manila folders of everybody's record. Easy, cheap, not secure, obviously. But it is cheap, you know. So how do you convince them that the cost of moving all that stuff to a blockchain or an electronic medical record kind of environment is worth it? You know, that's going to be another thing: is the cost going to be acceptable to the providers? Now, they're in business, obviously, to make money, as well as provide medical care to patients. But that's going to be something that's going to have to be thought through on how to do that.  

Chris Golden : [00:16:13] If it gets to the point where most of the providers are pushing back on the cost, I think eventually the government will step in with probably an amendment to HIPAA or something like that that says, hey, you have to do this and just eat the cost, or maybe the government will split the cost or subsidize it with you, or something like that if you're a provider and they're telling you, hey, this is the future, you have to have an electronic medical record, and you have to be on the blockchain or something like that. So I think in five years, we'll probably start seeing very good use cases. And I would think it'll probably be, you know, very pervasive in under ten. 

Brian Selfridge : [00:16:43] Well, before we move on to our next topic, any other insights you'd like to share on blockchain and any ups or downs or takeaways you have for our audience? 

Chris Golden : [00:16:53] Yeah. Again, I think, you know, the two big takeaways I would have is, number one, don't put sensitive information on the chain itself. Have that be in a separate database somewhere else. The blockchain can do an API call and reach out and get it if it needs it and modifies it. And the reason for that is something called quantum computing. Quantums coming out. If you listen to IBM, they think they've reached quantum supremacy. Now, I'm not sure I buy the news article, but maybe they are. But this will break the current encryption standards that we are using. So if you put PHI or PII on the chain and you encrypt it, now you can't take it off. Now, quantum breaks that encryption. How are you going to deal with that? So that's one of the things to do is not put the sensitive information actually on the chain, but put all the sort of mechanical back-office stuff that needs to happen to make it efficient on the chain and then have that the real sensitive data somewhere else where we can change encryption fairly quickly if we need it to once quantum sort of hits the commercial space. Yeah, I think that's it.  

Brian Selfridge : [00:17:45] Thank you so much. I know I got caught up quite a bit there on where we're headed, so I'm sure our listeners have as well. So thank you, Chris. That's awesome. 

Brian Selfridge : [00:17:55] So let's talk about our second topic, which is a little bit less in the technology we use and more in the business of conducting and managing enterprise, risk and governance, risk and compliance programs, which I know you've got a ton of experience there as well, among other areas. But I want to start with a question around the type of risk information that we put in front of the business and which types of data will have more of an impact or different ways that you think can be applied. In particular, there's a common debate around the difference between providing quantitative risk data, so it's sort of hard numbers, hard facts, versus qualitative risk data, the high, medium, low-risk gut feel kind of stuff, hopefully not entirely gut feel, but a little bit more educationally hypothesized than the data. Do you tend toward quantitative or qualitative data in your own sort of risk reporting? Do you use one versus the other more than the other or both? Or how do you approach it? 

Chris Golden : [00:19:04] I think most people would answer that question with it's a hybrid and it depends, right. So most people use both quantitative and qualitative data to try to make their arguments. You know, I think most people think that quantitative analysis requires a lot of data and in reality, it doesn't require that much data, it just requires harder thinking, as to what those numbers really mean. And I think most players in the space have enough data to actually use it, but they choose not to because qualitative, frankly, is easy. And it's something that's been done for quite some time. I'm more of a quant guy myself, so I lean towards that because numbers, especially the numbers of cost, is the language that the business speaks. And so to be able to speak that language with them makes decision-making very easy and makes conversations more nuanced. And it allows you to really get to the juxtaposition of the risk, what is the risk here? Are we willing to accept it? If not, what's it going to take to mitigate it? As long as those are in dollars and cents, it's a very easy conversation with the board. So that's where I sort of landed. But I will still use qualitative when it's appropriate. 

Brian Selfridge : [00:20:14] So how do you translate some of the quantitative data into dollars and cents? So just I'll make a silly example, which isn't fair, but we've got X number of vulnerabilities that we've identified on our server environment. How do you make the leap into saying that equates to a million dollars worth of risk or hundred thousand dollars worth of risk or that? Is there a secret sauce or a magic somewhere between? Or what do you rely on to sort of take it and make it into numbers? 

Chris Golden : [00:20:48] Yeah, there's not a secret sauce or anything like that. But there is something that's referred to as FAIR. I'm not sure if you or your listeners are familiar with that, but it stands for factor analysis of information risk. And basically, you run this model that asks you to do a whole bunch of in-depth searching. So we would look at the servers, we would look at whether they're inside the DMZ, outside the DMZ. We would look at the criticality of the business of them staying up. A whole bunch of factors, and you would do this analysis, and the analysis looks at a whole bunch of things. It looks at things like contact frequency. So how often will a bad actor have contact with this particular server let's say. You know, that's going to be one of the factors of a thing. What's our ability to defend that piece of equipment? That's another factor that goes into it. If a bad actor comes in contact, what are the monetary risks involved in replacing it or repairing it or reputational damage, et cetera? There's a number of them that they look at. 

Chris Golden : [00:21:40] But you do this analysis and FAIR, and it would cough up a number, and I'll just make something up. But it would say, you know, I would go to the board and I'd say, board, this particular server's got four hundred thousand risks associated with it or something like that. Right. That we've done our and it's talk to us. The old way of saying it, it would say that maybe ten thousand of those are critical. We've got to fix them within 30 days. Another hundred thousand are PI, we got to fix those within three months, et cetera, et cetera. But now we can say, based on our analysis, we think that, you know, someone is going to get access to that server, based on the vulnerabilities presented once out of every five years, is what we think the frequency of that is going to occur. And if they do, the impact of the organization will be a two million dollar event every time that happens. And so now we're talking. This is tough, right, now they can say, hey, that is well within our risk tolerance. That's a great idea. Keep doing what you doing. Or they can say no. We think once every five years is not enough. We'd like to push it out to once every seven years. What's it going to cost to do that? 

Chris Golden : [00:22:41] And you go back and rerun the analysis with new controls, figure out which one gets you to the once every seven year and then the cost of that control, you go to the board and say if you want to move that, this control is forty thousand dollars that moves the needle from once every five years to once every seven years. And so being able to talk in numbers of cost is a game changer for talking to the board. It is a game changer when you're talking in meetings because people generally do not argue with math. So we throw the analysis up on the screen and walk people through it. And it's not super fancy, it's not multivariate linear regression, it's just sort of multiplication. And people will argue around the edges, but they generally don't argue with the analysis too much to get to the right thing. So it makes meetings much more quick and to the approval you're looking for. It makes more nuanced conversations with the board because you're speaking their language. So we're starting to adopt FAIR. I'm a big believer in it. And I think it's probably going to be the way most companies will be looking at information, risk and cyber risk in the future. 

Brian Selfridge : [00:23:41] Given all the potential options of data that you can put in front of a board, let's say, or a leadership team, you could talk about the risk to servers and vulnerabilities from that lens. You could talk about third-party risk. You could talk about, I'm sure, a number of other control areas. How do you decide what to put in front of those audiences to get the investment? Or do you put it all out there and sort of the sea of information and try to help them make some sense out of it? 

Chris Golden : [00:24:11] So I think the first job, especially as a new person talking to the board or going to a new company and dealing with a new board, I think the first thing you have to do is be an educator. You have to educate the board as to sort of what you're doing in the cyber arena and how it impacts the bottom line. If you can't do that, then you can't have a nuanced conversation. But I think once you've done that, the board should be giving you feedback as to what they're interested in. Their risk appetite for the company should flow down from them to the rest of the company. And so this is what we're willing to tolerate in terms of risk. Here's the money we're willing to devote to mitigate that risk. And then we go figure out as the technical professionals, what sort of the best bang for the buck is to do that kind of stuff. But, you know, I think in a big picture, we're trying to get two things across. I think number one is there's no such thing as zero risk. Right. A lot of boards go, hey, when are we going to get to zero risk? Well we're never going to get to zero risk; it doesn't exist. So making sure that they understand that there is no such thing as zero risk. And understanding that we have to make risk based decisions because we are in a resource-constrained environment. We don't have unlimited money, manpower, time, et cetera, to go fix these things. If I did, we'd have no risk. But again, make sure the board understands those two themes and then you can walk somewhere in the margins between them to get where you need to go. Here's the risk identified. Here are the plans for mitigating that risk. Which one is most appropriate for the appetite of the company at the cost point that the company is looking for? So I think that's how you generally figure out what the board is looking for. Start like that. 

Brian Selfridge : [00:25:44] Do you ever run into any variance of the boards at risk appetite being, let's say, conservative and then dealing with the business unit or a stakeholder group that perhaps is a little more liberal and a little more willing to take on some larger risk? And how do you sort of get everybody at the same level of appetite or is it just the board said so and that's it? 

Chris Golden : [00:26:10] Yeah, it certainly can be that. Here's the the edict from on high. Everybody follow it. But, you know, people are trying to win in a competitive space. Right. And we're trying to enable that competition. We're trying to allow them to take risk and frankly fail without destroying the company, when they do take those risks and fail. But we want them to take the appropriate risks so they can win in their competitive space. And so when the board says, hey, our risk appetite for these kind of things is once every five years and some other business says I'd be more comfortable with once every two years, usually we have to do the math. We'll sit down and walk them through the math, walk them through the FAIR analysis, and go listen to do that, yeah, you'll save X amount of money by not having the controls in place. But look at the costs go through the roof. So if we lower the risk appetite from us, say one every five years to once every two years, we're in the once every five years. Maybe it was a two million dollar event every time it occurred. When we get to the once every two years or three years, now it's a ten million dollar event every time it occurs or something like that. And so, again, once you show the math and do the math for them, they usually get on board pretty quick because they don't want to eat those kind of costs once you show them what the real costs are. 

Brian Selfridge : [00:27:15] So I presume to get that FAIR analysis completed and to crunch those numbers that there's got to be some degree of risk analysis, risk assessment, that feeds into that process. How do you make sure the organization doesn't get fatigued by the volume of audits and assessments and just keeping an eye on the controls and where they are seeking analysis. Is there any strategies you have to make sure you're getting timely information to inform those analysis, but not sort of bogging the business down with assessments and like? 

Chris Golden : [00:27:51] Sure, I think there's two approaches there. One approach I've talked about, do the math for them. We have one office that does our FAIR analysis, so no matter who you are in the company, you can come to that organization and they will do the work for you. And everybody likes free chicken. So that office gets a lot of work, no question about that. The second way is to make sure your auditors are asking fair questions. Right. So if you're going through a SOC 2 or a HITRUST or something like that, you may want to put a little birdie in the ear of the auditor, and say, listen, we're trying to go down the FAIR pathway. We want to be more quantitative in our assessments. You know, can you please ask some questions in your auditing about, or even internal audit, I forgot internal audit. In your auditing, can you ask questions about what's your FAIR analysis of that to make them sort of respond to that from a regulator or audit review kind of level? People are more likely to jump when the auditor says, hey, I've got a question about this, versus when somebody like me in the security team comes and says, hey, I got a question about this. So I think those are the two approaches. Get your auditors sort of on your side to ask those kind of questions or basically just do the work for them. 

Brian Selfridge : [00:28:57] Excellent. Well, I'm going to shift gears on you a little bit into the weeds here. And in some particular areas, we've noted a pretty substantive shift from on premises applications, capabilities, infrastructure. It seems like everything's going out of house now. It was applications and software to service, now it's infrastructure. The service and the entire sort of technology stack seems to be outside of the purview of the owning entity in most cases anymore. Have you had to change the way that you present risk to the business? Do you focus more on third-party risk as opposed to the sort of internal assets and those types of things? Or is it still the same? Can you have that all in that same conversation or do you need to sort of break those out into separate discussions? 

Chris Golden : [00:29:48] I think most people now, they're sort of separate discussions. We're moving from the age of sort of the on-prem data center kind of thing to the cloud environment. And then everybody's trying to outsource as much as they can to just focus on core business things that they do and they do well. In my world, it's simply about talking about the entire ecosystem. Right. Your entire ecosystem includes cloud. It includes your third-parties and of course includes Prem and what you do there. And so being able to move from sort of a very narrow focus on what you are doing inside the four walls of your building to this much greater expanded attack service arena that includes your cloud providers and your third-parties, I think is the best way to do that, because you're responsible at the end of the day for all that area. All that attack server space, you're responsible as a security professional for figuring out how they all integrate, where the sort of the seams are in those things that bad guys could exploit and how they all work together. And so being able to say, OK, here's our entire ecosystem, let's talk about this part of it, which may just be the cloud providers or this part of it, which may just be the third-party security or this part of it, which may be on Prem is certainly a way to go ahead. But everybody needs to know that there's this greater sort of picture involved with the entire ecosystem. So being able to show on a slide or something like that, here's the entire ecosystem. Soup to nuts from a customer or in my case, a patient, all the way through our cloud environment, back on the prem, out to our third-parties who are doing data analytics, et cetera, et cetera. Being able to show that entire ecosystem is key to getting people to buy in and understand that there are things that we have to worry about in those third-parties and in those cloud environments. I think if you have the conversation individually in sort of a siloed manner, you're not going to see the bigger picture. And I think seeing the bigger picture in terms of overall risk to the company, not just individual siloed risks to the company, is far more important. 

Brian Selfridge : [00:31:43] So speaking of showing risk to the organization, maybe we can talk a little bit about some of the tools and software and automation out there in the risk management space, specifically the governance risk and compliance or GRC tool space. Now, I know you've had a ton of experience in this arena. Are these types of tools helping you with the FAIR analysis, for example, or are they able to sort of help with the math, or are there other advantages that you see tools bring that you think are worth organizations taking a hard look at? 

Chris Golden : [00:32:19] Yeah, so  GRC in it by itself is a great program, I think. I think the new name we're starting to see is IRM, Information Risk Management. Part of some of the GRC solutions are changing their names, but it also enables you to do factor analysis, no question about that. But, you know, to have that enterprise wide view of sort of all the risks presented to the company and where they overlap versus a stovepipe view, I think is incredibly valuable. Let me give you an example of, like employee risk. We'll take that, for an example, you know, an individual employee, what's their risk to the company? So maybe we conduct a phishing campaign once a month or once a quarter to our our employees. Is this an employee that frequently clicks on those links and fails the phishing test? We need to capture that somewhere other than just data security. Right. Maybe they aren't necessarily in compliance with some of the compliance policies. OK, we need to note that. But we don't need it to be just in the compliance world. Maybe there are some privacy issues that they have sort of talked up and given wrong information to wrong people. So, again, we need to know that. But it shouldn't just be in the privacy lane. But putting all that into a GRC or IRM allows you to sort of see, wow, that single employee is presenting a tremendous amount of risk across a number of disciplines. 

Chris Golden : [00:33:32] Maybe we should do something about it. And that can be any risk. You know, again, the whole point of a GRC program is to give you that enterprise-wide view of the risk facing the company, sort of remove the stovepipes. So when you go have a nuanced risk discussion with somebody, you can say, look, here's your area, but look at the impact all the other areas of the business that your risk is presenting. And that's a much different conversation than, hey, you're just bringing risk to the company. So I'm in love with GRC or IRM platforms. I think they're eh. Whether they're worth the actual money is a different story, but I like the thought of removing the stovepipes and bringing that enterprise-wide view in so we can very quickly sort of evaluate and try to mitigate risks as they start to bubble up before we forget they sit in a single stovepipe. 

Brian Selfridge : [00:34:16] Are there any drawbacks to GRC tools that you see? I mean, obviously there is some degree of cost in the tools themselves and then the folks to support them at a minimum. Are there any challenges you see with organizations that are considering a GRC that they might want to sort of be aware of or get out in front of? 

Chris Golden : [00:34:33] Yeah, I think obviously cost is going to be a factor for everybody. It always is. You know, once the decision has been made to sort of bring in a GRC solution, then I think there's one big thing that sort of jumps out at me, and that's people accepting responsibility for inputting the data. Right. Somebody's got to input the data. Going back to our sort of employee risk example, somebody from privacy has to say this person failed this privacy thing, that we gave them and input that data into the GRC platform. Somebody from the phishing world has to go in and say, hey, they clicked on a link and they shouldn't have, kind of thing. Typically, they just want to go to the database and make very pretty graphs and are happy to do that. But somebody's got to put that data in there. 

Chris Golden : [00:35:12] So that's typically the place that I see problems with GRC is it's up and running, but nobody's putting data in. So of course, it's not producing any real results. I'd recommend sort of a raci chart, responsible, accountable, coordinated with an informed model that gets sort of blessed at the highest level, you know, by the CEO, et cetera, by the board saying here's going to, who's going to do what, right, and have that sort of that buy-in from the company at a very early date. So people will actually use the tool, put the data in there, and then once the data starts flowing in, that's when the value of the tool becomes apparent. And so, you know, that may take six months. That may take a year for all that data to start getting in there before the tool actually starts producing good results. But once it does, then the buy in becomes much easier. And you see the data input really sort of jump exponentially, as people realize the more data they put in, the more they get out of the system. But that initial, hey, you've got to do this, they just see it as extra work. But in reality, they've probably been putting that data somewhere. Could be SharePoint, could be a different database. Now they just have to put it into the GRC platform, but they see it as more work than they want to do. But once that's sort of been overcome, and they see the advantages the GRC platform gives them for having that data in there, usually that will be overcome. 

Brian Selfridge : [00:36:21] Well as consultants, we certainly love our raci charts and raci matrices as well. So I'm glad you brought that into the mix, the plug for figuring out who's actually going to do this stuff. Chris, so one other question for you on the risk management side of things, maybe more of a broad question, what's one of the things that you think organizations are getting wrong with their risk management programs? You've seen it from a variety of industries. You've seen different processes, technologies, approaches, governments, nongovernments. Where do you think organizations are missing the mark? And maybe one or two key areas you can think of? 

Chris Golden : [00:36:56] Yeah, I would certainly say using a more qualitative approach to risk management than a quantitative approach. And I was just as guilty as everybody else. You know, back in the day, that's all we had. It was a red, green, yellow. It was a heat map. It was a maturity model. And at the end of the day, that really didn't tell us anything. Right. I could even have heat maps where a three on risk and a three on impact on one side of it as a yellow, but a three on risk and a three on impact, on the other side of the map is a green. They just make no sense. And so once you start doing quantitative analysis, you start realizing that that's really the right way to go. Some of these other things, like the red, yellow, green, just tells you nothing. It's not valuable to a decision maker, but telling a decision maker, hey, we think this event is going to happen at a 90 percent confidence rate once every five years. I'm going to do, it's going to be a two million dollar event. That allows decision making to occur, that allows conversations to occur, and frankly, that allows mitigation to be talked about. 

Chris Golden : [00:37:55] And so I think that's probably the biggest thing I've seen over my career. And again, I'm just as guilty as everybody else with sort of having that qualitative mindset, because it was hard to come up with the data. It was hard to do the analysis. But once you've done it a few times, you sort of realize, eh, it's not that hard. It's actually pretty easy, and there are certainly a lot of tools out there to help you do that kind of quantitative analysis. So that would be my biggest takeaway for my career is, man, I wish I'd started that earlier. 

Brian Selfridge : [00:38:20] Excellent. Chris, this has been fantastic. I apologize. We've run upon our time, and I've got some fantastic insights here on blockchain and risk management. So I just really appreciate you taking the time to share this with our listeners today. 

Chris Golden : [00:38:34] It's been my pleasure. Thanks, Brian. 

Brian Selfridge : [00:38:43] Again, I would like to thank our guest, Chris Golden, who serves as the director of information security for Horizon Blue Cross Blue Shield of New Jersey. As always, we would like to have your feedback and hear from you, our listeners. Feel free to drop us a note about what topic you would like to hear about or a thought leader you'd like to hear from. Our email address is [email protected]. Thanks again for joining us for this episode of CyberPHIx. We look forward to having you join us for another episode coming up soon.