Welcome to Cash in the Cyber Sheets. I'm your host, James Bowers, and together we'll work with business leaders and industry experts to dive into the misunderstood business of cybersecurity and compliance to learn how to start making money from being secure and compliant. Welcome to Cash in the Cyber Sheets.
Hey everybody welcome back to Cash in the Cyber Sheets. I'm your host, James Bowers, Chief Security and Compliance Architect here at Input Output. Very happy to have you back here with us today as we continue our FTC Safeguards Rule Checklist for Compliance series.
Now we are doing this both as a series on the podcast and have articles on our blog for each of these that we're going through. So very easy to follow along to dive in, get more information. What you'll also want to do, and the link will be in this podcast description, but is grab our FTC Safeguards Rule Checklist for Compliance, which is a checklist of all the FTC Safeguards Rule requirements, and in our series, we're just going straight down the list.
Now we have gone over designating a qualified individual. We've gone over utilizing a risk-based approach, implementing appropriate controls, and today we will go over monitoring, reviewing, and testing controls, which is going to include pin test and vulnerability assessments. What those are, what the difference is, and what you need to do to be FTC Safeguards Rule compliant.
Before we jump in, our shameless plug and ask, please click that subscribe, click that like, follow us whether it's on Apple, Spotify, or YouTube, wherever you're listening to us at. We'd love to also have your comments and hear things that you would like to talk about. With that said, let's go ahead and jump in to today's topic of monitoring, reviewing, and testing controls.
Now, in our previous episodes, we've gone over what the FTC Safeguards Rule is. We've gone over who needs to comply, basically financial institutions, but if you want some extra information there, definitely go back in, and if you click on the link in this article, in this description for the podcast, you'll go to the article that has a lot more information about that, and then that even links to other articles that just focus on some FTC information and who needs to comply, things like that. So, plenty of information on the website.
Not going to get into all that here. The FTC Safeguards Rule checklist, like I said, we've gone through designating a qualified individual. We've already talked about building your WISP using a risk-based approach, and in the past two episodes, we actually broke it up into two, we talked about implementing appropriate controls.
That was more the technical aspect, and there was just a lot to cover there, so broke that up. In today's, we're going to go over regularly monitoring and testing controls. 16 CFR section 314.4, subsection D. I think I'm saying that right, subsection D. In any case, that's where we're at.
So, what that's going to look for, overall, is developing the information security program to where you're able to monitor what's going on in your environment, and not just technically, but also administratively, physically, all of the different types of controls. We want to be able to see what's going on. We want to be able to test all of our key controls.
So, whatever we've put into place, based on our risk assessment, we want to test that those are implemented appropriately, and that they're mitigating or reducing that risk in the way that we expect, and in the best way possible. It also lets us see if, one, are there gaps, and two, are there just general ways that we could make this even better? Are there ways that we could further reduce our risk? And this is where it really starts turning into that cyclical situation of doing the risk assessment, applying controls, reviewing controls, improving, and just continues to go in that circle. Now, a really big part, a big focus of this section, because there's a whole other section of the FTC, which is continual ISP improvement, that's going to be more on general audits, more of the general sharing and development.
But what this section is really focused on is annual penetration testing, and it's actually named as a requirement now, under the FTC safeguards rule. Before, it wasn't. Now, it actually is.
It's actually under section 314.4, subsection D, section 2, section I, where it specifically states you need to do one annual penetration test, and in the very next section, states that you need to do semi-annual vulnerability assessments. So we're going to dive into what a penetration test is, what a vulnerability assessment is and some different ways that you can address these. So penetration testing, a lot of times called pin testing, it may be called, some people may refer to it as social engineering, as web application testing.
It's all penetration testing, just different types. But what a pin test is, what a penetration test is, it's a controlled and authorized attempt to mimic a real world hacker. Authorized is a very big bit of this.
You have to have a signed sheet, for those MSPs out there, you have to have authorization because if you don't, it's an illegal activity. The only thing separating a penetration test from an illegal hack is an authorization from the organization. So make sure you get that if you're an MSP performing.
If you're an organization that's looking for a pin test, really what you're looking is for somebody to attempt to break in. And what they're looking to do is run exploits. They're not just going to look around.
They're actually going to try breaking into systems. They're going to try loading malware. They're going to try exploiting different things in your email servers to see what gets caught, how quickly your teams can respond, and this is going to tie in a lot with your incident response processes.
How quickly can we detect? How much of it was prevented? How quickly are the teams responding and what does that look like? So a penetration test is very good for not only identifying all the technical issues, the different ways that a bad actor, an unauthorized user could get access to your systems and data, but it's also really good for poking the holes in your response processes. Did we have a complete communication breakdown or did everybody know what they needed to do? So that's why a pin test is so important. It's going to simulate real-world attacks.
It's going to use both manual and automated tools. It should be risk-based. So your pin test needs to align with your risk requirements, and this is very, very important.
The reason why is your pin test needs to be appropriately scoped based on the risk of your organization. It is very easy to just go out there and say, I need a pin test, and start getting quotes for 40, 50, 60, $100,000. The cost of penetration tests can just spiral.
However, if you're able to identify a very structured area, the scope, exactly what needs to have a penetration test, you can make it more focused so that it's actionable, actually usable by you and your team. But probably even more importantly, it's much less expensive. And a thing to consider with penetration tests is with a lot of companies that have a lot of SaaS platforms, software as a service, Microsoft, Google, other online platforms, you can't necessarily perform a penetration test on those platforms.
It's not allowed. It's not going to be authorized. So your actual environment where you can have a pin test may be extremely small, and that's where having that appropriate risk assessment, understanding the scope of your information security program, where your data is, where your exposures may lie, is so critical to this part because it's going to help you keep everything from spiraling out of control, both from a project perspective and a cost perspective.
Some different types of pin tests, getting into the different types, there's external, so that's where somebody from the outside tries to break in. There's internal, where somebody has access to the internal network and they just see how crazy can they go, what can they get access to. There's web app API testing, which is testing web applications APIs.
There's social engineering, where that's actually trying to socially engineer somebody to let you in. Taking typically phishing, smishing, those type of exercises to the next level, actually making phone calls, so a lot of different ways you can approach it. But the biggest thing to make sure you're fitting in that FTC safeguards rule definition is that you're performing exploits.
You're actually testing and actually trying out different exploits. You're not just scanning. That's a big differentiation between a pin test and a vulnerability assessment, which is a great segue into talking about vulnerability assessments.
So you need to do two vulnerability assessments per year or have a tool that is continuously monitoring, continuously assessing. Tools like CrowdStrike, BlackPoint, Nessus, Tenable, these are tools that can be set up to where they are constantly 24-7 monitoring your environment and can help satisfy that vulnerability assessment requirement. Or if you don't have tools like that, you can use a standalone tool like Qualys, Nessus, or some others that you perform, say, one-time tests at least twice a year.
And a vulnerability assessment, what that is, different from a penetration test, is they're typically automated scans. They're checking for known vulnerabilities. Imagine if you were walking through a building and pointing out different areas that could potentially be risky.
Hey, that door could be kicked in. Hey, that door is unlocked. These windows don't have blinds on them.
Somebody could crawl through that window. Whereas a penetration test would walk up, kick the door in, and say, this door is not safe. Look how easy I kicked it in.
A vulnerability assessment isn't going to run any exploits. It's only going to passively scan. It's going to provide remediation.
It's going to look at different risk ratings, typically, to identify how risky those vulnerabilities are. And it's a very good idea to typically do an in-depth vulnerability assessment, all of your systems, everything that you're going to look at, tighten that up, and then perform a penetration test. That way you can validate that you've tightened everything up and take it a step further to see, are there any other ways that maybe the vulnerability assessment just didn't identify? So let's look at a little chart here in our article.
But going through a few of the different differences between a PIN test and a vulnerability assessment, the PIN test is going to, again, simulate a real-world attack. It's going to be basically active. A vulnerability assessment is just going to scan to identify vulnerabilities.
It's going to be passive. Typically, PIN tests are both manual and automated, exploit-focused. Vulnerability assessments are mostly automated, typically just scanning.
In the PIN test, you need to do at least annually. In the vulnerability assessment, at least every six months, if you don't have a tool that's doing it 24-7. With your PIN test, again, make sure that it is risk-based to keep that scope appropriately tight so your project and your cost aren't spiraling out of control.
Some other really good tools here, getting away from the PIN test and the vulnerability assessment that can tie into those, though, for helping to meet this requirement of monitoring, reviewing, and testing your controls is continuous monitoring solutions. There are a lot of SIEM solutions, security information and event management tools. There's Microsoft Sentinel.
There is Splunk. There are tons of them out there, BlueMira. You can also utilize MDR, Managed Detection and Response, like CrowdStrike, BlackPoint, or other tools that are constantly looking at the network and taking action.
You can look at vulnerability assessment tools like NodeWare, Tenable, Qualys, to constantly monitor the network. These are all ways that you can get an excellent view and control of your system's networking environment while at the same time meeting those PIN test and vulnerability assessment requirements. You also want to fully integrate this with your risk assessment process.
This shouldn't be, again, having the risk assessment done, put on a shelf, and then doing everything else. They need to match up so you can keep everything appropriately scoped. And you want to make sure to track and report all of your findings, document everything, and keep those documents so you can show progression over time.
And if you ever get audited, you can show where you did your PIN test, where you did your vulnerability assessments, and very importantly, what your actions were based on the findings. This should also tie into all of your incident response procedures and your incident response plan to where as you're identifying things, you want to make sure that most notably, your teams know how to detect and respond, and you know how to communicate. Who's going to do what, who's going to champion, who's going to lead the charge on everything.
Finally, you can't forget about your suppliers. Now, there's a whole section in the FTC that we'll talk about managing your service providers, but it's very important that you're managing the vulnerabilities and any risk with your suppliers, and it should tie into this process. You can reach out to your suppliers to make sure that they're doing their test, that they have, say, PSY-2, ISO 27001, that they comply with NIST frameworks or FedRAMP, but basically that they're doing these things on their side to make sure that your data that you store with them and transmit with them is safe.
That is everything that we have today on monitoring, reviewing, and testing controls. We talked about making sure you do your annual pin test, keeping those appropriately scoped so it's not too expensive and becomes too much of a project, and doing at least semi-annual vulnerability assessments, or if you have a tool that can run those 24-7, even better. If you have any questions, you don't want to go it alone, it seems scary, please feel free to reach out to us.
We're just always happy to help and connect to see how we can help make things easier and more secure for you, and with all of that, thank you very much for listening, and until next time.
Thanks for joining us today. Don't forget, click that subscribe button, leave us a review, and share it with your network. Remember, security and compliance aren't just about avoiding risk. They're about unlocking your business's full potential. So stay secure, stay compliant, and we'll catch you next week on Cash in the Cyber Sheets. Goodbye for now.
