I have mentioned before (and will continue to) that HITRUST Certification didn't secure the system itself; rather, it codified and proved out the existing security apparatus. However, one could argue that it made the system more secure through the security testing needed throughout the certification.

When it comes to security testing, a lot of technical terms may be flying around that may be unfamiliar, they were for me too, and it's easy to become confused. You may even start to feel like Woody in the famous Woody & Buzz 'Everywhere' Meme with a mixture of confusion, exasperation, and fear.

In this post we will demystify those terms and outline different security testing methodologies and how it could be applicable to your business.

But first, let's talk about the negative in security testing. Cost. There's no way around it, it's going to cost you time and money to do effective testing. You could save some money by testing internally, but if you are reading this post and learning something from it, you should hire a specialist. Even if you came to Vy and said "we'd like you to do this testing for us," we'd decline. Testing isn't our speciality and it's probably not yours. It will be more cost-effective (time, money, risk, etc) in the long run to hire a professional with experience.

Back to the topic at hand.

Below are the four types of security "testing" that were required for HITRUST Certification:

• Penetration Testing
• DAST (Dynamic Application Security Testing)
• SAST (Static Application Security Testing
• Risk Assessment

Let's demystify them...

Penetration Testing

The first type of testing you likely will come across, and in my opinion, the most valuable, is Penetration Testing. Penetration Testing will likely be required annually. Penetration Testing is when a live human, hopefully one who is experienced, will actively try and hack your software. They will do this by using the same tools and practices that real hackers use. This can be completed in two ways:

• Black Box - when the tester does not know the inner workings of your system or have special access.
• White Box - when you give special access/knowledge to the tester that someone outside your organization wouldn't have.

If you are only going to do one form of testing, then you should do White Box Penetration Testing. However, if you do DAST as well, then I am usually a fan of Black Box Penetration Testing. This is because it gives you a real clear idea of real world threats without confusing the hypothetical.

DAST

DAST stands for Dynamic Application Security Testing. This is similar to Penetration Testing with two key differences:

1. It's automated and handled at a higher frequency (say quarterly),
2. It gives access to your system and vulnerabilities found here are usually true vulnerabilities.

However, DAST does not actually test the code, only the application layer. These are not code scans.

SAST

SAST stands for Static Application Security Testing. This is a code scan. Full disclosure, I'm not a big fan of SAST for small operations. I have yet to find a good SAST application unless you are using a well known framework (which I'm against for other reasons), and/or using built-in functions only. I've run into a lot of problems surfacing helpful vulnerabilities because the system wasn't using a framework like Cake or CodeIgniter, it was built with a custom data cleanser, and its security was integrated via the operating system setup. Now you can't ignore SAST if you want your system to be open sourced or don't have control over what system your code resides. But the vast majority of you reading probably aren't concerned with that. Unfortunately, the end result of SAST can be a lot of false positives to wade through. Because of this, I would highly recommend using the same company for SAST that you use for DAST and Penetration Testing. This way they can easily validate which findings are false positives and which need attention.

Risk Assessments

Risk Assessments aren't traditionally technology related, but rather they come more often out of the insurance industry. That being said, they seem to be a favorite tool amongst everyone in InfoSec. Risk Assessments usually take the form of 100-300 question Excel document. Because you could answer these questions any way you want, think of it more of a test of your IT Policy (and its implementation) than of any actual security test. Note, I am not saying you should lie on these assessments. If you have a security issue and use the Risk Assessment as a defense, but you lied on them, that will be extremely bad. But that being said, no actual, meaningful testing usually accompanies this, and it's only as helpful as the effort you put into it.

All four forms of testing will output reports that will rank vulnerabilities that usually follow the CVSS Scoring method (Critical, High, Medium and Low). Unless proven a false positive, Critical and High should be addressed immediately and if possible, you should run the testing again after fixing the vulnerability, for your documentation.

There you have it. Hopefully that brings a bit of clarity. If you're going through HITRUST certification, it helps going through it with a proven system that's been there before. If that's the case, we'd love to talk more with you.