This blog article by AICorespot is a comprehensive guide to determining what variant of security assessment to leverage in a provided scenario, ranging from basic evaluations, bounties, and red team. 

There’s a ton of debate/discourse occurring right now in the information security community with regards to the advantages of penetration testing vs. bug bounties, pentesting vs. vulnerability evaluations, bug bounties or a red team engagement, and the part played by trusted advisors in all of it. 

In our opinion, very few comprehend the variations between these enough to determine which to leverage, and in what scenario. The nicest thing to do would be to blame sales, but the issue is more in-depth than that. 

This is the abridged version. 

A vulnerability assessment is developed to identify as many flaws as feasible in order to make a prioritized listing of remediation items. 

A penetration test is developed to observe if a mature defence can halt an attacker from accomplishing one or more particular objectives. 

A bug bounty is developed to leverage the advantages of a crowd to discover as many vulnerabilities as feasible. 

A red team engagement is developed to continuously evaluate and enhance the effectiveness of an organization’s blue team by emulating real-world attackers. 

A trusted advisor (in the security context) is somebody who are able to inform an organization, on the basis of their maturity and objectives, which approach to take at any provided point in time. 

Maturity matching 

In our perspective, the maturity of the business in question is the most critical factor in the decision of what variant of assessment to leverage, and when. 

What do we imply by maturity? 

• Is the organization patched? 
• Does the organization have a listing of everything it owns, which individuals have access to it, and when that access was finally reviewed? 
• Does it know were its data is and how its safeguarded? 
• Does it know how that data moves around the environment during business procedures? 

If the response to these questions are no, then they’re probably bound to be low maturity.  

Implying, they should cease thinking about hybrid-cloud, crowd-red-team ninja assessments and concentrate on the basics. Make a listing of where your stuff is and get patched. 

However, let’s assume we’re at mid-level maturity – whatever that implies – and we’re prepped to begin performing some security assessments. Where do you begin? 

1. It’s never a bad time to hire a trusted advisor. You ought to perennially have one. Whether they’re internal or external does not make that much of a difference, but you are required to be able to swiftly bring up questions such as these and obtain answers. So, the initial priority is to have somebody who can assist you develop and remain on track with a strategy. 
2. The first variant of security assessment to do, i.e., the assessment variant for lowest-maturity organizations, is the vulnerability assessment. This is as it’s not for evaluating mature defences, per say, but instead providing you a listing of all of the stuff you are required to fix to have a robust defence. It’s a prioritized listing of all the things you ought to rectify, and in which order. That’s to start with. 
3. After you’ve carried out one or additional vulnerability assessments and you’ve rectified everything that’s been identified (that’s a critical part, otherwise you’re wasting a ton of financial resources) it’s time to move on to penetration testing. This is likely ideally done with a trusted vendor or even an internal group (if you have one). You likely don’t have one at that juncture, although, otherwise you would not be in this situation. So a trusted external group is probably best as what is likely to be identified at this stage could be really bad, and very embarrassing. 
4. After you’ve performed tons of vulnerability assessments and tons of pentesting, and you’re now returning back with minimal results whenever you do them, you’re set for the next stage, which can go in several directions. If you wish to continue identifying more vulnerabilities, and the systems you’re evaluating are not overly sensitive (source code reviews, and the systems you’re evaluating are not overly sensitive (source code reviews, private networks, crown jewels, etc. ) then you should begin thinking about performing a bug bounty. A correctly sized and managed crowd can usually identify extra vulnerabilities that can only be caught by “several eyes”, but you wish to be sure that you’re choosing the right things for them to look at, and handling it closely. 
5. Lastly, either after or simultaneously during pentesting, you should begin looking into red team options. Red teams are permanent, ongoing campaigns developed to simulate real-world attackers. Done correctly, they’re the highest maturity evaluation variant as they must stay mostly independent from the business they’re evaluating, must stay very current and sharp, and most consistently evolve their tools and utilities and strategies to remain efficient. The one key for the red team is that its purpose is to enhance the blue team, which is a really differing objective than that of a vulnerability assessment, a penetration test, or a bounty. 

Summary 

1. Hire a trusted advisor (an individual or organization) who can steer your security evaluation efforts throughout your maturity levels. 
2. Begin with vulnerability assessments, and don’t perform any of the other variants of evaluation till you have cleansed up your environment through remediation enough that it’s difficult to identify things. 
3. Then move to penetration testing with a trusted business. 
4. If you’re obtaining no outcomes anymore from trusted advisor pentesting, consider including a bounty program to harness the “many eyes” of a crowd. 
5. Following the vulnerability assessment phase’s completion, when you’re shifting into the pentesting phase, you should feel free to begin looking into red team options as well, if not just because it will take a bit of time to research and identify good options. Red teams are not improved pentests; they’re a differing variant of assessment altogether, with differing objectives. 
6. Remember to have your trusted advisor(s) guidance through this process, there are tons of variables that decide when, and how, to do what. This is just a guideline to get you on the right foot. 

Notes 

1.  Some individuals require a pentest to prove that they are even facing security problems, but just be aware that it’s a very bad scenario to be in. If you have minimal comprehension from administration that they require a forest fire prior to obtaining a budget, you ought to expect a entire ton of drama as you proceed.
2. We would not state that there are no scenarios where you ought to have a crowd look at your most sensitive bits, like source code, private networks, or crown jewel defences, but we would state that you should be really cautious about such decisions as the crowd does not possess trust downsides related with its discovery upsides – at least at this phase of the industry.
3. Penetration testing is not “improved” vulnerability assessment; it’s a completely different thing totally.
4. Red team is not “improved” pentesting, it’s a different thing totally.
5. Bug Bounties are most like vulnerability assessments in that they are developed to identify as many issues as possible. They are an increased maturity version, although, since you wouldn’t want to waste resources on a bug bounty when you have a reduced maturity environment where bugs are simple to identify. You also don’t necessarily wish to set a crowd lose on low-maturity environments owing to possible trust issues, but it might be feasible to leverage vetted, private bounties for this reason. It’s likely ideal to leverage internal or trusted resources to carry out low-maturity vulnerability assessments, and then leverage bounties after maturity is high and you’re having trouble identifying extra issues.
6. The role of trusted advisor is so critical as it assists you contextualize discoveries and prioritize activity on the basis of the objectives of the business. Without this you might do tons of work on the incorrect things, and not minimize as much risk as you could have. There is always too much to rectify for the amount of resources you have; most of the game is determining where to concentrate.