Webinar Transcript
Chuck Minguez
So thank you everybody for joining us today. My name is Chuck Minguez. I’m the Digital Marketing Specialist at ONE 2 ONE.
And we’re very excited to have Jim Peterson with us again today from ConnectWise. Jim is going to be talking about all things API and how and what to look for and how to protect API third-party connections. And so without any further ado Jim I’ll turn it over to you.
Jim Peterson
All right thanks a lot Chuck. Welcome everybody. Great to meet you.
As Chuck said I’m Jim Peterson from ConnectWise. If you haven’t heard of ConnectWise it’s not surprising. We work mostly with IT service providers trying to provide security solutions and education to the small to mid-sized market.
So great to meet everyone. If you’ve seen one of our videos before you’ll see a similar format because we do like to recap a little bit of the conversation. Anytime we get a chance to talk about protecting environments we want to kind of set the stage on what’s going on in the world today.
We have some changes over the last one. So hopefully it’s interesting. We’ll get to APIs.
It’ll be a little shorter session than normal but we’ll have lots of time for questions at the end. So real quick cybersecurity what is it? We talk about it all the time.
And legacy version of this would say hey we’re trying to protect systems from digital attack. But in reality what we’re trying to do is protect people and information from the business from being released. We’re also trying to protect the business’s revenue its reputation.
Its ability to produce its products whether it’s a product or service. We’re just trying to keep everything moving forward and not let the bad actors have our information. And to do that we have a couple challenges in our world.
And they come around people process and technology. We think of a holistic solution. We typically talk about this in reverse.
We leverage technology as the wall against the bad actors to try and stop them from coming in our environment. And as you can see there’s lots of different little action or little items in there depending on what your business specifically needs. But that technology when it’s deployed is in great shape.
We have to have process behind that to make sure it’s maintained it’s updated and we know what to do when something happens. So building solid processes whether that’s an incident response plan or even just down to how we manage MDR alerts as they come in managed detection and response. That is gotta be careful on our acronyms.
We throw them around way too much.
Chuck Minguez
We could probably do a webinar on that. Yeah just- On the acronyms right?
Jim Peterson
Yeah it’d be perfect. Do a prize at the end for people that know the most. But how we’re handling the technology is that process side.
And then it comes to the people. And when we look at people we’re gonna say hey how do they run and create the processes to maintain and respond to the technology? And that’s gonna come in cybersecurity data protection assessments and vulnerability management.
All of these are continual efforts. And if you haven’t heard the term data protection we’re using that now over backups or even BCDR because what we’re trying to say is we need the data to be recoverable in the timeframe and in the situation that the business needs. Too often we set up a BCDR solution that just matches perfectly with the business requirements and we have no room for error.
So we have to think about it in a little bit bigger picture. So in assessments we’re doing those all the time constantly to make sure nothing new gets in the environment and then that vulnerability side making sure that we find vulnerabilities in our environment so we can remove the vulnerabilities through patching or through retirement of equipment. Really quickly because we go over this every time just a couple of terms that we’re gonna use in this conversation attack event incident and breach.
Attack there’s millions of them going on all the time. We are being attacked either by our email address or our IP address or our computers that are online. We’re being attacked all the time.
Most of the time the vast majority of percentage of attacks are blocked by our technology and process and people. But if something bypasses technology we would either call that an event or an incident. Now the only difference between these two is an event is automatically cured through other technology.
So as an example I’m tired on a Friday night. A bad actor is learning a little bit more about me learning that I work with Chuck and they send me a fake email from fake Chuck and I get tired and I click on it. Well if another piece of technology steps in blocks the attack and automatically cures the system it’s an event.
If a person has to get involved to cure and return the system to working order it’s an incident. So it’s just that little difference there but it’s a big deal. And the last one is that breach and it’s a word we never use unless we’re told we have to use it and it means the bad actors got to your sensitive data or data at all.
So just kind of understanding these terms because if we throw them out there we want to make sure we’re using the right one. Now here’s where a little changes come in. For a long time we talked about the bad actors as being either solo hackers nation states or organized crime.
Well what we’re finding in the latest reports from about cybersecurity incidents and breaches is that the end user percentage of attacks are going up. Now these are people in our organization and the biggest challenge with people in our organization is we’re typically not watching them for bad activities. And this could be malicious or unintentional but at the end of the day end users are responsible for about 25% of information leaving the organization.
Now this is different than falling for a scam clicking a link. This is actually releasing the information themselves. So we have to start watching a little bit more internally to make sure we’re protecting our organization.
This is going to come into that conversation around APIs as well. Nation states are a real small percentage because they’re typically going after other nation states or large organizations for intellectual property or trade secrets. Our adversary for the most part is organized crime.
And these organized crime syndicates while they have very cool logos they’re very dangerous. And these are large entities. They have HR departments they have recruiting firms they have bonus structures they have a large subset of employees basically right?
They get paid to attack our organizations and they get paid in three ways ransom extortion and data sale. Just real quickly ransom means we paid somebody to return our system to its working order. Extortion means we paid somebody to not release our data and then data sale really has nothing to do with us.
They steal it and they sell it online. Now what we’re seeing in today’s world right now as a common attack point is a combination of ransom and extortion which the industry is calling ransom but it’s really two steps. They go in and they try to encrypt the environment but our technology process of people has gotten pretty good and we can often defend against that.
But before they get to that point they steal the data. And I’ll say our industry in general doesn’t do a good job of seeing that. So they’ll say well I failed at the ransom so now I’m going to say we’re going to release that data if you don’t pay us X dollars.
So it’s kind of the common combination in today’s world. And no surprising how do they get in right? There’s typically two ways they get in.
Environmental access which means there’s a vulnerability in software and hardware. And this is the old school style of attack. We just attacked the firewall until we got through and got access to the system or other areas right?
And then there’s obviously the human element. Now if we look at some of these percentages credentials are actually going down. This is because we’re adopting more and more MFA in our world.
Phishing is going down because we’re really hyper vigilant on security awareness training and we’re having really good software eliminate a lot of emails before they get to the inbox. And vulnerabilities are going up. Now this doesn’t mean there’s more attacks on the vulnerabilities it’s just they’re being more successful in comparison to the other things.
But that social engineering at the bottom really encompasses a lot of these style of attacks because I may leverage social engineering to get your credentials and then phish you right? So it’s not just one thing it’s just that primary access. And that human element makes about 68% of all incidents and breaches that are involved.
Now this used to be 80%. And the only reason it’s went down is we’ve excluded privileged misuse meaning that’s something we would originally have called a human element but they’re shifting that over more to the environmental side dropping this number down. But we’re still as people if you look even over to the left unpatched systems and misconfigured systems right?
These are still people-based things. So we know that human element’s pretty high. Just to give you an idea and let me step back.
One of the reasons we always go through this is we can tie this to everything. If we think of an API which I’ll get into in just a minute but anytime we’re connecting things together we have to be very sure that we’ve protected that channel and that the right people are accessing the information that we want them to access. And with the human element misconfiguration unpatched systems all these vulnerabilities out there want to make sure we’re being very very skeptical anytime we’ve said yes I’m going to let you see some data.
So one way to look at this right? If we think of a specific attack we’ll go through a couple from here. An environment attack and this could be looked at on the API side as well.
Let’s just say you have anything going through your firewall. Now a few years ago maybe more than a few now Chuck I guess but we would have maybe pushed terminal services if you’ve heard that or remote desktop RDP different protocols out through the firewall so people can access systems inside from anywhere in the world. We do it differently today but this could be a camera system.
This could be anything that we can remotely access that’s sitting in our network but we can access it from the internet. It’s going to have some open ports we would say on the address assigned to it. Well we do our best to try and hide that but in general bad actors can see that it’s open and they’ll attack.
And you’ll be surprised at how easy it is to attack these things right? On a terminal services it may be just a standard RDP vulnerability. There’s brute force there’s denial of service there’s a lot of general ways to attack things that are exposed to the internet.
And the worst and best I guess the easiest is good credentials. We use a camera system as a good example. I put my camera system in I expose it to the internet so that I can access it wherever I’m at in the world to see the cameras but I never change the default username and password.
Bad actors even Chuck and I both… Yeah right good yeah. We even know those common passwords so if we see it I’m like hey I could probably log into that I’m not gonna but just understand that they’ll find a way.
And once they breach that security and get on that system that’s when the real work comes in. That’s where the scripting comes in to elevate access find the information and obviously steal the data. So you’d be surprised how easy this process is.
And when we think of APIs which again we’ll get to in just a second sorry we’re exposing something a lot of times so we’ve got to make sure we’re putting the right security in place. Now from the personal side and all this ties together right? Think about the social engineering.
If you’re still like me you want to let everybody know when you’re going out of the office. You know what? Let people know.
And I have Microsoft 365 and SharePoint and I have MFA enabled. We’ll talk about Mike in this scenario right? Sets that out-of-office message just so we could let everybody know.
Well one way or another the bad actor finds out that Mike’s gonna be out of the office starting Friday for a week. So he knows I’m gonna start attacking Mike socially. I’m gonna try and send him an email password reset at 515 on that Friday when he’s going out of town and that’s my attack right?
Yep. And it looks real. It’s in his email.
Like oh well I’ll just click this real quick and I’ll just reset my password. And when I do that I’m giving the bad actor credentials and my MFA token. Now Mike still has no idea what’s going on because it still reset his password.
Man-in-the-middle attack just happened and that bad actor captured all that information. So now that bad actor can log directly into the site elevate access and steal that data just like before. So just a couple examples of how these things happen.
And you may say I would never fall for that right? Because I expect the email to look like this. I expect it to be extremely obvious.
And Chuck if we were looking at this we’d say hey it’s got a bad email address. Dear customer would never say that. Sincerely the online team.
We know that but that’s not how they look today. This is how they look today. They’re crafted through AI excellent grammar.
They make sense. And while we call this phishing this is truly social engineering because it’s attacking people who leverage CVS which a lot of us do and just kind of giving you a general statement. Hey we’re offering some training as part of our system.
Check it out. And it’s gonna trick a lot of people. So they’re craftier than we think and a lot of times we don’t give them credit for how good they really are.
So into the main topic right? What is an API? Application Program Interface which does nothing to describe what it actually is unless you know right?
So we’ll say APIs are the interconnection between two pieces of software that allow communication to happen. So I was trying to think and Chuck and I were talking a little bit earlier on this of a common one. If you use a scheduling system for your email like Calendly as an example right?
That system had to be authenticated with your Office 365 most of the time or it could be your Google account as well so that it could read the information find out when your calendar is free and then also push things into your calendar so that it shows up if I schedule an appointment. That’s a generic API right? And there’s hundreds of them out there that we may or may not use we may use on a general basis and we don’t even know.
So in real life right? We try to describe this as simply as we can. If we think of a waiter right?
In real life a waiter acts like an API because we have the customer out in the dining room who knows they want a specific thing. Well the waiter will come out and communicate with them to find out what they want. And then the waiter goes back and communicates to the kitchen on what they want and so that’s how the customer notifies the kitchen and the kitchen makes the right thing for the customer.
So in a technical world we look at it a little differently. I’m online and let’s say I want to figure out I have to fly to San Antonio tonight and that is a true story I have to fly to San Antonio tonight. But when I did that I had to search multiple airlines.
Well I may use Google Flights as my example. If you’re not familiar with it www.google.com/flights it can tell you a lot of information. It’s a great place to start for some brainstorming.
Chuck Minguez
Very nice I’m gonna look that up later today.
Jim Peterson
Yeah it’s one of the better ones. I love it I use it all the time. We use a specific product called Navon which I won’t dig into too much but at the end of the day Google Flights that specific search has to access information from multiple airlines at the same time to find out the date you’re trying to leave the time you’re trying to leave the date you’re trying to return time you’re trying to return the cities to and from all that information.
Even regional cities if there’s airports close to the one that you’re at that maybe have better flight times. So it has to have these communication paths to all of the vendors so they can understand all of the options. These are all APIs right?
So multiple connections. So basically Delta has to trust Google and Google has to trust Delta. And then we as the customer have to trust everybody.
So we can get a lot of bad information in there.
Chuck Minguez
Yeah I was just gonna say some of these are just multiple avenues then for possibilities for attack.
Jim Peterson
Oh yeah and we think of these large organizations and in general we’re like you know what they probably are thinking about this stuff so I don’t have to which is generally true. That inherent trust. Yeah that’s a really good point and I should have written that one down as one of our challenges is that inherent trust.
We believe them so we don’t worry about it as much. But if we think of this whole scenario here and the trust that needs to happen the customer’s actually booking something and in the end they’re gonna put credit card information in they’re gonna put personal information in maybe their TSA known traveler number all these pieces birth dates all that personal identifiable information into the system. It’s gonna then push it to Delta so or United or American or whoever your carrier is.
And in that whole communication path we have to make sure that it is safe because bad actors would love to get in the middle of that and steal all that information and really wreak havoc in your day put you in the wrong seat put you on the wrong flight and really really mess with your world. So there are some common challenges when we talk about APIs. One is and we’re gonna drop this down to our level and so when I say our level I mean the day-to-day users of some of these APIs and I’ll use Calendly as an example.
When I authorize Calendly to access my system I don’t want Calendly itself to know my specific meeting who I’m meeting with what the topic is what the location is I just want them to look at free-busy. Basically am I free that time or am I busy that time? I don’t need them or want them to see the data because they number one don’t need to know it and it might be confidential.
If I don’t program it properly it can access multiple pieces of information and then we think of read versus write access. So we gotta make sure we’re being very careful anytime we leverage an API or connect software together that we’re really paying attention to the level of access they’ll have to the new system or the old system I guess I should say. So what it can see make sure we’re really reading that description to understand what it can do for you.
Next is that modification what can it change? Because at the end of the day like to use this Calendly example or even our Google Flights example I need to be able to book a seat on that flight or I need to be able to book a meeting with Chuck but I also don’t want to push too much information or be able to change other things. I don’t want to overwrite a meeting he already has just because I could have the ability to do that and with an API I could write the code to overwrite that information as long as Chuck accepts it it would do that.
So we have to be careful what it can modify. The big one right? Those first two are I guess they’re all big ones right?
Because we don’t want it to see too much. We don’t want it to change too much. And then we have that tunnel.
And if we think of your virtual private network that we probably still use today to access sensitive information or get to your office and read data run applications and we talk a lot about the encryption levels the authentication of that channel. APIs have to do that with every connection every single time to make sure that is completely encrypted because if I got in the middle of that API just like our social engineering if I get in the middle of the attack I can see everything. So we want to make sure that nobody can ever get in the middle of our API calls.
That would be very dangerous and again they would be able to capture all that information and change it. And that last piece is access. And this is the hardest one to understand because we’re trusting and we use Calendly as our example we’re trusting that Calendly is only going to see what they need to see only change what they need to change and it’s going to be a secure connection all the time.
What we will probably never know is which employees at Calendly have access to the code and have access to troubleshoot the API. So in smaller organizations a lot of times we’ll do business to business connections and this could be in our QuickBooks in our ERP in our ordering system and we know that our team that has access to the code and the connection we want to make sure we understand on the other side who has access to the code and connection. We’ll dig into how to fix this or how to protect it in just a second.
These are really the big four. What can it see? What can it change?
Is the connection secure between the two? And who has access to change anything? A bad example which we don’t like to talk about is I’m on the other end of an API between our ConnectWise and one-to-one and I’m like you know what?
I’m going to modify the code a little bit so I can see a little more. And if you trust me too much Chuck I could start seeing that data right? So you want to be able to restrict that connection as well.
So thinking about this from the protection side right? There’s a couple ways we want to protect those APIs because this is looking at the most sensitive information a lot of times. First and this is the hardest part of any API is the vendor or client assessment.
Now this is assuming that I’m either using an API to connect to a vendor somebody we pay for things or to a client somebody who pays us for things. And just like I said if we’re in the middle of that we have APIs on both ends. And again this could be if we have an ERP system and we’re trying to do just-in-time ordering for materials.
So the system will order the materials. They may connect directly into some of our suppliers. Always great feels great to do these things because we’re taking a lot of labor and work out of it.
We’re making it automated. But we want to make sure those vendors especially if they’ve written their own API kind of challenge number one that we can do an assessment on their security what’s included with the API what it’s doing and then we have to validate that on our end. And most small businesses aren’t prepared in all honesty to do these type of assessments.
Chuck Minguez
Yeah exactly.
Jim Peterson
Yeah it’s challenging. So one thing we would say is anytime someone says hey let’s just connect our systems together we have to get with somebody that can do this assessment for you. Like one-to-one who can come in and say that hey here’s a challenge.
They’re right they have full right to do it anyway. Before yeah exactly yeah. Yep yeah.
Next area and this is kind of on that secure side make sure that it’s leveraging current encryption and authentication methodologies right? Some of these have been APIs and Jackie probably knows that were written in the late 90s early 2000s right? Using 56-bit encryption or something like that and they haven’t changed with the times.
So I would ask for the data sheet to make sure that the encryption mechanisms the authentication mechanisms are all current for the time. And if you’re watching this a year from now it could have changed. So make sure we’re constantly updating this when we put an API in that we’re doing at least annual reviews of the vendor client assessment and the security assessment to make sure nothing has changed.
It’s okay call out. Yep. Read write.
Again we’re just looking off that back end. What can it read? What can it write?
Down to the specific field that it can read or write right? Anytime we have PII or we think of the medical field or the defense field we definitely don’t want it to even read things that it shouldn’t be reading. So being extremely specific on what any API ever has access to.
This is where we mess up a lot in all reality especially when we’re doing a small connection meaning we’re just doing a small business-to-business connection software-to-software connection that we are creating to try and make our life easier. We open it. It’s just like assigning administrative rights to a computer to solve a problem right?
We shouldn’t do that. We gotta make sure we solve the problem with the technology not with the rights. So understanding specifically what fields and what information and then testing that to make sure it’s not getting more information than you expect.
And Chuck if vendor and client assessments were hard right monitoring APIs might even be a little bit of a step up on that. How do you monitor something that may be persistent? You know?
And so we wanna monitor it for suspicious behavior changes in activities. And this can happen a couple different ways. Number one they’re all gonna be logged.
All the information’s gonna be logged. You can take those logs push them into a security information event manager or SIEM and have it try to find any suspicious behavior or changes in activity. You can also use things like API gateways.
And that is completely designed to monitor all incoming APIs to your organization for suspicious behavior or changes in activity. You can also throttle the access. So if someone were to change an API and start pulling off a lot of data that it would trigger number one and it would slow down that stream so it could not send a lot of data in a quick timeframe.
So it gives you time to basically go shut that one down. Or you can also set it to automatically shut down if it hits these specific thresholds. So an API gateway is a great way to if we don’t know how to monitor which most of us don’t I am not a monitoring person.
I can do the assessment but I’m not the one to do the monitoring right? I’m going to trust my API gateway to help me with that. So a lot about APIs real quick right?
We said a couple of things and I’m just going to roll back here a couple of things to think about. With the APIs you currently have and any ones that you’re going to be going into engagement with in the future at any time what does it get to see? What does it get to do?
Is it protected? And who can make changes? If we just ask those four simple questions we’re really going to be pretty far down the road of the vendor-client assessment.
There’s still more things from a technological perspective that we need to understand but it’s going to answer the first few questions and at least do some due diligence on that client or vendor side. It’s going to solve some security challenges obviously that rewrite challenge and then monitoring is a little bit separate. We would always recommend some sort of API gateway because it’s actually watching for these real-life problems.
So if you want to be protected in the long run not just in the short run again we’ve made a few changes to this overall conversation of what is really good in cybersecurity. This has always been six but I’ve actually taken one out and added one in since our last conversation Chuck and it’s that assessment side of things. So one of the challenges we have is that people will deploy technology and trust the technology without processing people behind it to do the job.
So we need continual assessments and we talk typically on three levels when we say assessment. We talk network we talk security and we talk vulnerability. And while they all sound the same they’re doing a little bit different activity.
Different things yep. Yeah so network is saying what’s on the network? What can I see?
What’s here? And so anything that changes quarter over quarter month over month whether you’re doing these monthly or in real time all the time we can then address those things and make sure they’re supposed to be there. That’s number one.
Security is going to say what gaps do we have? What’s deployed today? What should our organization have at our industry at our size at our you know for even our goals right?
And where are our gaps there so we can start building a plan around that? And vulnerabilities are closer to the network side. Vulnerabilities are going to say I see everything out there.
Here’s the seven things that are unpatched that you need to fix immediately because it’s a high risk to your organization. Vulnerability is looking at the actual systems and the problems those systems could potentially have. Patching is kind of a common one right?
A big one. Yeah if you have a firewall you know basically a firewall protects the internet from your internal network right? It goes in the front.
Most people have heard that term. But if that is unpatched you know you’re going to have vulnerabilities over time that can put the internal network at risk. So it’s going to say either patch or replace one of the two but it’s a problem.
But then we have our incident response plan it’s our number two. And what we’re going to say there is know who to call if something happens because when something happens hopefully it doesn’t happen to you but when it happens it’s a scary time right? We are making typically not the best decisions in that moment because we’re scared for our business we’re scared for our people we may be scared for our own position especially for owners.
And we want a clear set of rules to follow.
Chuck Minguez
So that just- Imagine how much better you would feel having that plan in place if something does happen right? Versus just a complete freak out trying to fix everything.
Jim Peterson
Yeah and that’s a great point because that’s one thing people do all the time is they try to fix it. And they may be destroying all the forensic evidence that tells you you only had an incident you didn’t have a breach. So or they only accessed these files which were non-PI and non-sensitive so we don’t have to report it.
So a lot of times we’ll say hey what’s IRP step number one? Isolate right? Unplug everything.
Then call your cybersecurity insurance provider call your response team call one-to-one notify our team so there’ll be a specific plan so that we know exactly what to do. And then we can run tabletops of that to find gaps as we go. So again those first two are more of a process that’s run and it’ll make you prepared and understand where your risks are.
Then we just get into the tools. And we would typically say managed detection response on the endpoint which when we say endpoint we’re talking about laptops desktops servers even in many cases things that have operating systems that can access the internet. We want a managed solution on there that detects and responds to threats that are known and unknown.
A lot of times we used to call this antivirus which would do a good job of stopping known issues but we need to elevate that solution to make sure we’re stopping the unknown ones as well. And then we have the two cheapest most effective solutions for security in the world multi-factor authentication and security awareness training. If I can really make you prove who you are with that secondary authentication and I can teach you to be very skeptical of anything that comes into your world I can dramatically reduce that risk of the human element being the problem.
I can make it so breaking my authentication is very challenging. We take that from the 45%-ish of challenges down to single digits. And then that security awareness training just improves that even more because I know how to raise my hand if something happens.
And obviously that last one we should probably call this data protection now instead of BCDR but making sure you can recover your environment and you never hand that over to the bad actors. You never give them the authority to be the ones restoring your environment. Right so the six foundational core cybersecurity requirements.
So wrapping it up hopefully we’ve talked a little bit about APIs. I know this was a shorter one but just know everyone’s a target. And again whether it’s an API whether it’s an email whether it’s a login whether it’s an email that comes in they’re targeting you all the time.
They’re trying to find a way to get past your security so that they can access your environment. APIs are awesome. They really allow us to work faster in an environment search deeper know more connect systems together.
It is fantastic what they can do to help improve the world. But they are inherently unfortunately dangerous. It’s like a QR code.
So we talk about QR codes all the time from the security side and QR codes by themselves are not dangerous. What’s dangerous is you don’t know where it’s taking you most of the time. You just click it because it’s a little graph.
That inherent trust again. Inherent trust I love that. Yes perfect.
It’s gonna take me where I wanna go. Yep I’ll get you to that menu site here in just a second just capturing a little information in between. Yeah so just understand that there’s some risk there.
And if we can focus on what it can see what it can do how secure it is and who has access to it we can really reduce that risk and put us in better shape.
Chuck Minguez
Fantastic.
Jim Peterson
And that’s it for today on APIs. Hopefully that was helpful.
Chuck Minguez
Jim very helpful. Two things. One I wanted to say I love the analogy of the waiter.
Oh awesome. I’m gonna start using that. Because some conversations we have with folks who may not necessarily know what the API is what it does I think that’s a really really fantastic way of explaining it to folks who may not be working in the IT department but are interacting with APIs probably more than they think they are.
So I’m gonna start using that. And then I had a question for you too. So when you were talking about the human element and the numbers going down you had mentioned that there was unintentional sharing of information.
Jim Peterson
Yeah the privileged misuse.
Chuck Minguez
Yeah. Do you have an example that you could share with us?
Jim Peterson
Yeah yeah. So let’s say that I have the ability to access the PII in an organization. And through my privilege I’ve misused my own privilege and now I have access to that data when I wasn’t supposed to in the environment.
Medical is where this comes in a lot. As a nurse I may have access to all the files and I could actually create a breach technically by looking at the wrong patient’s records. I mean it’s a little bit it’s a little blown out of proportion but I could also look at all the patient’s records.
So I’m using my privilege to misuse the system to access data.
Chuck Minguez
Thank you appreciate you sharing that. You got it. And then I just wanted to open it up.
Let’s see if there’s any questions. Anyone on the line wanna ask a question or throw something in the chat? Now’s a good time to do that.
And if not we’ll wish everybody a happy rest of the week. And Jim again always love having you on appreciate it. And people that may be tuning in later ONE 2 ONE does offer the assessments that Jim was talking about.
We’d be more than happy to have a discussion with you and walk you through the process of what that looks like and have a conversation. So please don’t hesitate to reach out. All right well Jim thank you so much.
I hope you have a wonderful 4th of July coming up and we’ll be chatting soon.
Jim Peterson
All right thanks Chuck.
Chuck Minguez
Thanks everybody. Yep bye-bye.
Jim Peterson
Bye.