A brief discussion on the methods of discovering vulnerabilities in business systems from the perspective of management

Preface

Security vulnerabilities can be said to be the source of all security events in business systems. Vulnerabilities are a broad concept, including both the awareness stream problems caused by security and social engineering, as well as defects in the technical handling of hardware and software.This article mainly discusses the discovery of technical vulnerabilities after the system is put into operation, which includes: first, it does not involve detection and discovery methods before the system is put into operation or version iteration, such as code audit and risk assessment; second, it does not involve non-technical issues such as security and employee awareness.

Vulnerability discovery is a prerequisite for security management work. The comprehensiveness and timeliness of vulnerability discovery largely determine the quality of the entire vulnerability management and security management work. This should be a consensus among security professionals. According to my limited experience in the industry, the ways of vulnerability discovery can be roughly divided into three categories: manual asset matching, vulnerability scanning tools, and penetration testing. The following will elaborate on these one by one.

Manual asset matching

Manual asset matching refers to the case where the conditions for executing the two discovery methods mentioned in this article are not met.Match vulnerabilities based on existing asset information(Mostly based on version, some involving specific functions),Mainly applicable to 0day or vulnerabilities that have been disclosed or erupted in a short period of time, usually released and reported by hardware and software manufacturers, regulatory agencies, or superior units. The former is generally the unit's spontaneous investigation and disposal, but the latter two notifications are mandatory tasks, and even some urgent vulnerabilities require timely feedback and reporting of the affected and disposal situation. If the security team cannot make a quick judgment based on existing asset information, although the asset management work of some enterprises is not the responsibility of the security team, the process may leave a poor impression on senior management, or even be accused of shirking responsibilities.

In fact, assets are the foundation for vulnerability discovery. Vulnerability scanning and penetration testing are all based on asset information (URL, port, IP, domain, etc.), especially for units that have experienced a period of rapid growth and a long construction period, the asset management work is often more or less deficient. The detailed explanation of asset management could be written into another article, and this article will not elaborate further.

Vulnerability scanning tools

Vulnerability scanning tools are diverse, and can be divided into open-source, domestic and foreign commercial (including so-called domestically developed hardware boxes) according to their source attributes. According to their main function and asset object attributes, they can be divided into host scanners, WEB application scanners, etc. According to their architecture, they can be divided into C/S, network proxy, etc. However, in essence, they can be roughly divided into two technical modes: guessing-based matching detection and POC-based verification mechanism, each with its own advantages and disadvantages, and the following are the general characteristics:

1. Guessing-based matching detection of false positives

By remotely detecting the network services and component programs of the asset objects, collecting the returned response data, and making fuzzy judgments based on the known vulnerability features (version, protocol, response features, etc.) in the vulnerability library, if the conditions are met, it is considered to exist a vulnerability. However, many vulnerabilities may not undergo fundamental changes in their response information features after reinforcement or repair, which may cause false positives, and I believe many professionals have been criticized by the client, operation and maintenance, or development due to this.

Guessing-based matching detection and the manual asset matching mentioned above have the same effect, both of which match versions without script verification conditions. The differences are two: one is that the former is semi-automated by the tools maintained and updated by the manufacturer, which usually has a relatively slow update timeliness, but is technically mature and has comprehensive vulnerability information; the other is that the former is not only based on version and asset information but also involves dynamic features such as protocols and response headers.

2. Missing reportsPOCVerification detection

Based on the automated process of verification scripts, through simulating known vulnerability exploitation methods (scripts), the asset objects are automatically attacked (note that it is simulation, which does not have actual harm or actual harm is controllable), and the dynamic changes of the target are analyzed to determine whether the attack is successful. If the attack is successful, it is considered to exist a vulnerability. POC-based verification detection depends on the verification script, and there are countless historical known vulnerabilities, and the coverage of the verification script is not complete, which will cause missing reports.

3. Suggestion for choosing between false positives and missing reports

The vulnerability library for guessing-based matching detection is comprehensive, with false positives. POC-based verification detection is limited by the coverage of the verification script, with missing reports, false positives, and missing reports, which seem to be two extremes.

(1) For units purchasing漏扫 products:

Fortunately, in recent years, some manufacturers have realized the problem, and the updated leak scanning products have reduced their dependence on simple feature judgments such as version comparison, combined with the POC mechanism, which has reduced the false positive rate. Although the scanning speed is relatively slow, both fish and bear's paws can be enjoyed.

In addition, due to the uncontrollable update timeliness of manufacturer scripts, it is recommended to purchase leak scanning products that support custom POC scripts for emergencies, as some manufacturer products claim to support POC functions but are built-in script libraries and do not support customization.

(2) For units purchasing漏扫 services:

It is explicitly required that the service unit use a variety of products based on POC and feature libraries for cross-validation. Vulnerabilities discovered by POC detection are directly delivered to the operation and maintenance, development, and other subsequent processes. Vulnerabilities discovered based on guessing require the party B to screen and duplicate based on IP, port, CVE number, and then transfer to the next process.

Penetration Testing

1. Definition and Introduction

Generally speaking, penetration testing also includes vulnerability scanning, but the former is more inclined to obtain permissions or data on the target, focusing on vertical intrusion rather than just discovering some vulnerabilities. Discovering, combining, and exploiting vulnerabilities are the key methods of penetration testing. Vulnerabilities can be common high-risk disclosed security issues, or unique special business logic processing errors (such as 'shearing the wool').

2. Problems Existing in Practice

In today's increasingly important information security, if the Internet giants don't have a public testing platform, they won't even dare to greet others as the 'public testing' era has arrived. Penetration testers can obtain certain economic benefits just by spending time on the platform. Especially in the past few years, relevant laws and regulations were not yet完善, and vulnerability disclosure platforms were in a state of chaos with unauthorized authorization. Therefore, many legends of becoming rich and buying houses and cars by finding vulnerabilities have spread in the江湖. Most registered users of these platforms are full-time security technical service personnel for the service provider party. The pursuit of profits has given rise to a strange phenomenon: 'work is just a side business, and finding vulnerabilities on the platform is the main business', inIn various penetration assessment service projects, some things are just done to get by, and the report is delivered upon obtaining certain permissions, with penetration testing being reduced to a verification of vulnerability scanning results.

3. Possible Solutions

(1) For the client party:

There are skilled professionals with reliable skills and attitudes among the service providers in the market, but these experts are expensive and relatively scarce resources, which need to be used in more valuable places. At least if I were in the management role of a service provider, I would not want to keep such experts on this project for a long time if the client's requirements for the service content are unclear or even completely unknown. This has nothing to do with morality and quality, and even nothing to do with the client's budget or project size. The pursuit of maximizing profits and the ratio of inputs to outputs is the core task of corporate survival. However, if the client party attaches great importance to security management and can lead the specific work of service providers, for service providers, they must send the highest experts to provide services under the budget allowance to ensure delivery quality, otherwise they may lose this project.

Therefore, the delivery quality of penetration testing or all security service projects is indeed related to the service provider's capabilities, but I personally believe it also depends on the client party's control over service requirements and acceptance standards. It is recommended to consider setting specific expected goals based on the actual system situation, with the completion of services upon achieving the goals, otherwise it will not be successful, and it can also introduce multiple service providers for quality cross-comparison.

(2) For the service provider party:

Establishing a standardized operation process for penetration testing, refining to what tools to use, prioritizing which risks to explore and exploit, ensuring the minimum quality of service, treating the exploration of risks outside the standard process as bonus items, without restricting methods and approaches, leaving a certain space for security technicians, and also conducting a unified quality review of service reports before delivering them to customers, with the review results considered for titles and bonus evaluation systems.