Security test system

Abstract

To support a manual detailed check by a user to determine whether a vulnerability in an application automatically detected by a method such as DAST is a correct detection or a mis-detection, and provide a countermeasure.SOLUTION: A system includes: an inspection execution part 11 which inspects a target Website 3 for vulnerability, records information related to a detected vulnerability as an inspection result 13, and presents it to a user; and an interactive processing part 12 which accepts a question related to a targeted vulnerability specified by the user, create an answer using LLM4, and responds. The interactive processing part 12 inputs detailed information related to the target vulnerability to LLM4.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to an application testing technique, and more particularly to a technique that is effective when applied to a security testing system that checks for vulnerabilities in Web applications. [Background technology]

[0002] Web applications are premised on using a network, and from a security perspective, it is extremely important to inspect and test for vulnerabilities. There are a variety of tools and services available for inspecting web applications for vulnerabilities, and these are being investigated and developed on a daily basis.

[0003] Web application security testing methods can be broadly divided into SAST (Static Application Security Testing) and DAST (Dynamic Application Security Testing). While SAST statically analyzes source code, etc., DAST sends simulated attack (inspection) requests from an attacker's perspective to a running application, and determines whether there are any vulnerabilities based on changes in the application's behavior (response).

[0004] As an example of a technology related to security testing using such a method, JP 2023-545625 A (Patent Document 1) describes a method for triaging software vulnerabilities by using methods such as SAST and DAST to scan software to detect potential vulnerability issues, generating an electronic document report listing these issues, extracting features for each potential vulnerability issue from the electronic document report, determining a vector based on the extracted features and a token determined based on the source code of the potential vulnerability issue, selecting a vulnerability scoring method based on the vector, and determining a vulnerability accuracy score. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Special Publication No. 2023-545625 Summary of the Invention [Problem to be solved by the invention]

[0006] According to conventional techniques, it is possible to scan software for vulnerabilities using methods such as SAST and DAST, quantify the degree of vulnerability (possibility of attack), identify the most relevant vulnerabilities, and propose solutions.

[0007] On the other hand, when using DAST as a security testing method, DAST is a black-box method that performs simulated attacks from the outside on a running application to determine whether or not it has vulnerabilities. This makes it difficult to fully understand the internal processing of the application at the time of the attack, which can lead to errors in vulnerability detection. In particular, systems that automatically perform inspections and diagnosis, such as security test systems, are more likely to have false positives than manual inspections and diagnosis. Therefore, users must manually examine automatically detected vulnerabilities to determine whether they are true positives or false positives.

[0008] In this case, a user with knowledge of application vulnerabilities can focus on the appropriate information from the detailed information related to the automatically detected vulnerability and conduct a detailed examination with high accuracy. On the other hand, a user without knowledge of vulnerabilities may not know what to focus on to make a judgment and may not be able to conduct a detailed examination appropriately. Furthermore, even when a vulnerability is correctly detected, there may be cases where it is not possible to determine, for example, how to specifically modify the source code.

[0009] Therefore, the object of this invention is to provide a security testing system that supports users in manually examining application vulnerabilities automatically detected by techniques such as DAST to determine whether the detection is correct or incorrect, and to present countermeasures to the user.

[0010] The above and other objects and novel features of the present invention will become apparent from the description of this specification and the accompanying drawings. [Means for solving the problem]

[0011] Among the inventions disclosed in this application, the outline of representative inventions will be briefly explained as follows.

[0012] A security test system that is a representative embodiment of the present invention is a security test system that checks for security vulnerabilities in a Web application, and includes an inspection execution unit that checks for vulnerabilities in the Web application, records information related to the detected vulnerabilities as inspection results, and presents the results to a user, and an interaction processing unit that accepts questions related to target vulnerabilities specified by the user in the inspection results and creates and responds to the questions using an LLM (large-scale language model), and the interaction processing unit inputs detailed information related to the target vulnerabilities to the LLM. [Effects of the Invention]

[0013] The effects obtained by the representative inventions disclosed in this application can be briefly explained as follows.

[0014] In other words, according to a representative embodiment of the present invention, in a website vulnerability inspection system, it is possible to support users in manually examining vulnerabilities automatically detected by techniques such as DAST to determine whether the detection was correct or incorrect, and to present countermeasures to the user. [Brief explanation of the drawings]

[0015] [Figure 1]1 is a diagram showing an overview of a configuration example of a security test system according to an embodiment of the present invention. [Figure 2] 1 is a flowchart outlining an example of a vulnerability inspection process flow according to an embodiment of the present invention. [Figure 3] FIG. 1 is a diagram showing an outline of an example of vulnerability testing according to an embodiment of the present invention. [Figure 4] 1A and 1B are diagrams showing an outline of an example of a vulnerability test pattern in an embodiment of the present invention. [Figure 5] FIG. 10 is a diagram outlining an example of a prompt for inputting detailed vulnerability information into an LLM in one embodiment of the present invention. [Figure 6] FIG. 10 is a diagram outlining an example of a prompt for an LLM to determine information required for a response in one embodiment of the present invention. [Figure 7] FIG. 10 is a diagram outlining an example of a prompt that causes an LLM to create an answer in one embodiment of the present invention. [Figure 8] 10(a) to 10(c) are diagrams outlining examples of replies on a chat screen according to an embodiment of the present invention. [Figure 9] FIG. 2 is a diagram showing an outline of an example of a data configuration of an inspection result according to an embodiment of the present invention. [Figure 10] FIG. 2 is a diagram illustrating an example of a data configuration of a vulnerability master according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0016] Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. In all drawings used to explain the embodiments, the same parts are generally designated by the same reference numerals, and repeated explanations will be omitted. However, parts that have been designated and explained in one drawing may be referred to by the same reference numerals in the explanation of other drawings, although they will not be shown again.

[0017] <Summary> As mentioned above, DAST website security testing is a black-box approach in which simulated attack requests are sent externally to a running application and the presence or absence of vulnerabilities is determined based on the response from the application. This makes it difficult to fully understand the internal processing of the application during an attack, which can lead to errors in vulnerability detection. In particular, systems that automatically perform inspections and diagnosis, such as security testing systems, are more likely to produce false positives than manual inspections and diagnosis. Therefore, users must manually examine automatically detected vulnerabilities to determine whether they are true positives or false positives.

[0018] As will be described later, when conducting a detailed examination, the information that should be focused on varies depending on the type of vulnerability and the inspection pattern. For example, there are cases where the original request (before tampering) to the application should be focused on, and there are cases where the response to the request after tampering should be focused on. There are also cases where the difference between the response to the original request and the response to the request after tampering should be focused on. In such cases, a user with knowledge of vulnerabilities can focus on the appropriate information from the detailed information related to the automatically detected vulnerability and conduct a detailed examination with high accuracy. On the other hand, a user without knowledge of vulnerabilities may not know what to focus on to make a judgment, and may not be able to conduct an appropriate examination. Furthermore, even when a vulnerability is correctly detected, there may be cases where it is not possible to determine the specific measures to be taken, such as how to modify the source code.

[0019] Furthermore, DAST is merely a black-box inspection method for applications, and does not rely on an understanding of the application's internal structure. Therefore, when users conduct a detailed inspection, providing knowledge about the various technical elements that make up the application (e.g., source code, framework settings, etc.) can improve the accuracy of determining whether or not a false positive has occurred. However, with systems that automatically perform inspections and diagnosis, such as security testing systems, it is not possible to obtain internal information that would be useful for detailed inspections from outside the application. Therefore, this information must be provided separately by the application's administrator, developer, etc.

[0020] Therefore, a security testing system according to one embodiment of the present invention uses a chatbot to interactively accept and answer questions from users about the detailed examination and countermeasures for vulnerabilities automatically detected in target applications using techniques such as DAST. The system improves the accuracy of the answers by determining in advance the information required for the answer and providing answers based on the information provided by the user. Furthermore, by using generative AI (Artificial Intelligence) and LLMs (Large Language Models) (hereinafter collectively referred to as "LLMs") to collect the above information and answer questions, the system can achieve judgments about vulnerabilities equivalent to those made by knowledgeable users.

[0021] <System configuration> 1 is a diagram showing an overview of an example of the configuration of a security test system according to one embodiment of the present invention. The security test system 1 is configured to include, for example, server devices and virtual servers constructed on a cloud computing service, and is accessed by a user terminal 2, such as a personal computer (PC), via a network such as the Internet, a virtual private network (VPN), or a local area network (LAN), all of which are not shown, using a web browser or dedicated application, all of which are not shown.

[0022] The security test system 1 realizes various functions related to the implementation of security tests by, for example, using a central processing unit (CPU) (not shown) to execute middleware such as an operating system (OS), a database management system (DBMS), and a web server program, which are loaded onto memory from a storage device such as a hard disk drive (HDD) or solid state drive (SSD), and software running on the OS and DBMS. The security test system 1 includes various units, such as a test execution unit 11 and an interaction processing unit 12, which are implemented by software. The security test system 1 also includes various data stores, such as a test result storage unit 13 and a vulnerability master storage unit 14, which are implemented as a database, file table, etc.

[0023] The test execution unit 11 has a function of testing each web page in the target website 3, which is the test target, for vulnerabilities using the DAST method. That is, for each target web page, when sending a request to the target website 3, it sends a pseudo-attack request by, for example, entering invalid values into a form. Then, it analyzes the response from the target website 3 to determine whether or not there is a vulnerability, and records the determination result in the test result 13.

[0024] The dialogue processing unit 12 has a function of interactively accepting and answering questions from users regarding the examination and countermeasures for vulnerabilities detected by the inspection execution unit 11 in a chatbot format via the user terminal 2. In this embodiment, the questions are interactively accepted and answered in a chatbot format, but the user interface for questions and answers is not limited to this. When answering, the information required for the answer is determined using an external or internal LLM 4, and the LLM 4 generates an answer based on the content of this information provided by the user. Details of the processing by the dialogue processing unit 12 will be described later.

[0025] <Processing flow> 2 is a flowchart outlining an example of the process flow for vulnerability testing in an embodiment of the present invention. First, the testing execution unit 11 tests the target website 3 for vulnerabilities using DAST. The test begins with starting a first loop process that repeats all URLs (Uniform Resource Locators) to be tested on the target website 3 (S01). The URLs to be tested are obtained and listed in advance, for example, by automatically crawling the target website 3 and analyzing the links in each web page. In the first loop process, a scenario is played back in which an original (before tampering) request is sent to the target URL (S02).

[0026] 3 is a diagram outlining an example of vulnerability testing in an embodiment of the present invention. Here, the diagram shows that, as an original (before tampering) scenario, a request as shown in the diagram below is sent via HTTP (Hyper Text Transfer Protocol) to the target URLs to be processed, which are enclosed by dashed lines in the list of target URLs to be tested, and the response shown in the diagram is obtained.

[0027] Returning to Figure 2, a second loop process is then started, which repeats all of the preset test patterns (S03). In the second loop process, a scenario is played back in which a request tampered with according to the test pattern to be processed is sent to the URL to be processed (S04). Then, based on the response from the web page related to the URL to be processed, it is determined whether a vulnerability has been detected (S05), and the process moves on to the next test pattern (S06).

[0028] FIG. 4 is a diagram outlining an example of a vulnerability testing pattern in one embodiment of the present invention. FIG. 4(a) shows an example of a tampered request and a corresponding response in one testing pattern for testing for SQL (Structured Query Language) injection. In SQL injection, a request is tampered with by embedding a malicious SQL statement in the request. In the example of FIG. 4(a), the portion of the request surrounded by a dashed line indicates that it has been tampered with from the original request shown in the example of FIG. 3 above, and also indicates that the content of the response to this request is identical to the response shown in the example of FIG. 3 above. In the case of this testing pattern, if there is no difference between the response to the original request and the response to the tampered request, it is determined that an SQL injection vulnerability has been detected.

[0029] On the other hand, Figure 4(b) shows an example of a tampered request and the response in one of the test patterns for testing cross-site scripting. Cross-site scripting involves tampering with a request to embed malicious script into the target website 3, which is then executed when accessed by a third party. In the example of Figure 4(b), the part enclosed by the dashed line in the request indicates that it has been tampered with from the original request shown in the example of Figure 3 above, and also indicates that there is a difference in the content of the response to this request between the response shown in the example of Figure 3 above, as indicated by the part enclosed by the dashed line. In the case of this test pattern, for example, <script>タグがレスポンスにも反射された場合に、クロスサイトスクリプティングの脆弱性を検知したと判断する。

[0030] このように、検査パターンによって、オリジナルのリクエストおよびレスポンスと、攻撃に係るリクエストおよびレスポンスとの間に差分がない場合に脆弱性を検知したとする場合もあれば、差分がある場合に脆弱性ありと検知する場合もある。また、差分の有無に関わらずレスポンスの内容に基づいて判断する場合もある。このように、検査パターン毎に着目すべき情報が異なることから、本実施の形態では、後述するように、検査パターン(脆弱性)毎にどのようなロジックで脆弱性の有無を検知·判断するのかに係る情報を事前にLLM4に入力しておく。

[0031] 図2に戻り、すべての検査パターンについてステップS04~S05の処理を行って第2のループ処理が終了すると、第1のループ処理において次の検査対象のURLの処理に移る(S07)。そして、すべての検査対象のURLについてステップS02~S06の処理を行って第1のループ処理が終了すると、対象Webサイト3に係る検査結果を対話処理部12によりユーザ端末2に表示する(S08)。例えば、検知した各脆弱性をリスト表示し、リストからユーザにより選択された脆弱性について、詳細画面にて検査パターン、URL、Webページ内のパラメータ等を表示する。さらに、詳細画面に、例えば「相談する」等のボタンを表示し、ユーザがこれを押下することで、チャット画面を介して対象の脆弱性についての質問を受け付けることができるようにする。

[0032] その後、ユーザが「相談する」等のボタンを押下してチャット画面を起動したか否かを判定する(S09)。チャット画面が起動されずに検査結果の画面がユーザによりクローズされる等した場合は(ステップS09でNo)、検査処理を終了する。一方、ユーザによりチャット画面が起動された場合は(ステップS09でYes)、まず、対話処理部12により、対象の脆弱性についての詳細情報をLLM4に入力·指示する(S10)。

[0033] 図5は、本発明の一実施の形態における脆弱性の詳細情報をLLM4に入力するプロンプトの例について概要を示した図である。ここでは、図示するような脆弱性詳細情報入力プロンプトを生成してLLM4に入力することで、対象の脆弱性(図5の例ではSQLインジェクション)について、脆弱性の概要、どのようなロジックで検知するのか、誤検知か否かの判定を行う方法等、必要な情報を脆弱性マスタ14から取得して予めLLM4にインプットしておく。なお、図5の例に示された情報の項目は必要最低限のものであり、これらの他に脆弱性毎に必要な情報の項目が追加され得ることは言うまでもない。この脆弱性詳細情報入力プロンプトでは、応答を出力しないよう指示することで、そのまま次の処理に移る。

[0034] 図2に戻り、次の処理では、チャット画面を介してユーザからの質問の入力を受け付ける(S11)。質問の入力を受け付けると、対話処理部12では、当該質問に回答するために必要な情報をLLM4に判断させ(S12)、必要と判断された情報に基づいて、質問に対する回答をLLM4に作成させ(S13)、得られた回答をチャット画面においてシステムからの回答としてユーザに表示する(S14)。

[0035] 図6は、本発明の一実施の形態におけるステップS12で回答に必要な情報をLLMに判断させるためのプロンプトの例について概要を示した図である。ここでは、上段の図に示すような回答必要情報判断プロンプトを生成してLLM4に入力することで、LLM4からの出力として、下段の図に示すような、ユーザからの質問に回答するために必要な情報を得る。

[0036] 図6の例に示す回答必要情報判断プロンプトでは、対象の脆弱性とユーザからの質問の内容に加えて、回答のために入手可能な情報のキー(図6の例では、改ざん値(tamperedValue)、オリジナルのリクエスト(originalRequest)、オリジナルのレスポンス(originalResponse)、改ざん時のリクエスト(tamperedRequest)、改ざん時のレスポンス(tamperedResponse)の5種類)と、JSON(JavaScript Object Notation)形式で出力される回答に含まれるデータ項目を指示している。このプロンプトに対し、図6の例では、LLM4からのJSON形式の出力において、質問への回答に必要な情報(required)として、上記の5種類のキーすべてが必要であるという出力がされたことを示している。

[0037] なお、図6の例に示す回答必要情報判断プロンプトでは、回答のために入手可能な情報におけるリクエストとレスポンスとして、それぞれ、オリジナル(正常通信時)と改ざん時(攻撃時)の2種類を指定しているが、脆弱性によっては、1つの攻撃で複数の改ざんを行う場合があるため、改ざん時については2種類以上のリクエストとレスポンスが指定される場合もある。また、図6の例に示された回答のために入手可能な情報は一例であり、これらの他に入手可能な情報の項目が追加され得ることは言うまでもない。

[0038] 図7は、本発明の一実施の形態におけるステップS13で回答をLLM4に作成させるプロンプトの例について概要を示した図である。ここでは、上段の図に示すような回答作成プロンプトを生成してLLM4に入力することで、LLM4からの出力として、下段の図に示すようなユーザからの質問に対する回答を得る。

[0039] 図7の例に示す回答作成プロンプトでは、対象の脆弱性とユーザからの質問の内容に加えて、ステップS12で取得した回答のために必要な情報(図7の例では、改ざん値、オリジナルのリクエスト、オリジナルのレスポンス、改ざん時のリクエスト、および改ざん時のレスポンスそれぞれの実際の内容)と、JSON形式での出力に含める項目を指示している。回答のために必要な情報の実際の内容は、例えば、検査結果13から取得することができる。なお、LLM4に入力することができる情報量(トークン数)には上限があるため、入力する情報量が多くなる場合は、例えば、入力するリクエストとレスポンスの実際の内容について、不要な部分を切り詰めたり、分割して入力したりすることで、LLM4の制限を回避する。

[0040] 図8は、本発明の一実施の形態におけるステップS14でのチャット画面での回答の例について概要を示した図である。図8(a)は、1回のやり取りで終了する場合の例を示している。ここでは、検知された脆弱性が誤検知かどうか教えてほしいというユーザからの質問に対して、LLM4がステップS13で作成した誤検知の可能性が高いとの終局的な回答を提示してやり取りを終了していることを示している。

[0041] 一方、図8(b)は、ユーザからの追加の情報提供が必要な場合の例を示している。ここでは、図8(a)と同様に、検知された脆弱性が誤検知かどうかというユーザからの質問に対して、LLM4がステップS13で回答を作成したものの、誤検知か否かを判定するためにはさらに追加の情報が必要であるとしてユーザに確認を求めている。そして、ユーザから入力された追加情報に基づいて誤検知の可能性が高いとの終局的な回答を提示していることを示している。このように、LLM4を利用することで、対話的にやり取りを重ねてユーザから追加の情報を取得しながら、質問に対して回答していくことができる。

[0042] また、図8(c)は、検知された脆弱性に対して、ユーザに対象Webサイト3のコードの修正方法を提示する場合の例を示している。ここでは、どのようにコードを修正すべきか、というユーザからの質問に対して、回答するためにはさらに追加の情報(図中の例では現在のソースコードや技術情報)が必要であるとしてユーザに入力を求めている。そして、ユーザから入力された追加情報に基づいて、どのようにコードを修正すべきかを回答していることを示している。

[0043] なお、ユーザからの質問としては、例えば、「この脆弱性を検知した理由を説明してください」「この脆弱性が誤検知かどうか確認してください」「この脆弱性が存在するかを確認するには何をすべきか教えてください」などのように、検知された脆弱性の精査に係る質問が想定される。この場合、対話処理部13およびLLM4では、例えば、上述のステップS10で入力した脆弱性の詳細情報や、脆弱性マスタ14に蓄積されている情報に基づいて回答を作成することができる。

[0044] また、例えば、「SQLインジェクションについて説明してください」「クロスサイトスクリプティングを放置するとどのような危険性があるか教えてください」などのように、脆弱性一般についての質問も想定される。この場合、対話処理部13およびLLM4では、例えば、脆弱性マスタ14に蓄積されている情報に基づいて回答を作成することができる。

[0045] また、例えば、「どのようにコードを修正すべきか教えてください」などのように、対象Webサイト3の修正方法についての質問も想定される。この場合、対話処理部13およびLLM4では、例えば上述したように、ユーザに対して該当箇所のソースコードや技術情報(利用言語やライブラリ等)の入力を求め、入力された情報と脆弱性マスタ14に蓄積されている情報に基づいて回答を作成することができる。

[0046] なお、ユーザからの質問については、例えば、上記のような質問内容をユーザがチャット画面を通して自由に入力できるようにしてもよいし、想定される質問を予めテンプレートとして用意しておき、その中からユーザが選択して質問するようにしてもよい。

[0047] 図2に戻り、対話処理部13では、図8の例に示したようなチャット画面でのユーザとのやり取りが終了したか否か(例えば、ユーザがチャット画面をクローズしたか否か)を判定し(S15)、終了していない場合は(ステップS15でNo)、ステップS11に戻って、チャット画面でのユーザからの入力の受け付けを継続する。一方、チャット画面でのユーザとのやり取りが終了した場合は(ステップS15でYes)、検査処理を終了する。

[0048] なお、図2の例に示した一連の処理において、網掛けがされている処理(ステップS10、S12、S13)は、LLM4を利用した処理であることを示している。

[0049] <データ構成>図9は、本発明の一実施の形態における検査結果13のデータ構成の例について概要を示した図である。検査結果13は、検査実施部11による対象Webサイト3に対する検査毎に結果に係る情報を保持するテーブルであり、例えば、検査に係る項目として、検査ID、URLパラメータID、検査パターンID、および検査ステータスなどの各項目を有し、検査対象URLパラメータに係る項目として、URLパラメータID、URL、およびパラメータなどの各項目を有する。また、リクエストに係る項目として、リクエストID、URLパラメータID、オリジナルフラグ、検知脆弱性ID、改ざん値、リクエストヘッダ、およびリクエストボディなどの各項目を有し、レスポンスに係る項目として、レスポンスID、リクエストID、レスポンスヘッダ、およびレスポンスボディなどの各項目を有する。

[0050] 検査に係る項目において、検査IDの項目は、対象の検査を一意に特定するIDの情報を保持する。URLパラメータIDおよび検査パターンIDの各項目は、それぞれ、対象の検査において用いられたURLパラメータおよび検査パターンを一意に特定するIDの情報を保持する。検知ステータスの項目は、対象の検査において脆弱性が検知されたか否かを示す情報を保持する。

[0051] 検査対象URLパラメータに係る項目において、URLパラメータIDの項目は、対象の検査において用いられたURLパラメータを一意に特定するIDの情報を保持する。URLおよびパラメータの各項目は、それぞれ、検査の対象のURLの情報および指定するパラメータの情報を保持する。

[0052] リクエストに係る項目において、リクエストIDおよびURLパラメータIDの各項目は、それぞれ、対象の検査におけるリクエストおよび用いられたURLパラメータを一意に特定するIDの情報を保持する。オリジナルフラグの項目は、対象のリクエストが改ざんしていないオリジナルのものか否かを示すフラグ(オリジナルの場合True)の情報を保持する。検知脆弱性IDおよび改ざん値の各項目は、いずれも上記のオリジナルフラグの値がFalse(改ざんしたリクエスト)の場合にのみ値が設定される項目であり、それぞれ、対象の検査において検知された脆弱性を一意に特定するIDの情報および対象のリクエストにおいて改ざんした値の情報を保持する。リクエストヘッダおよびリクエストボディの各項目は、それぞれ、対象のリクエストにおけるヘッダおよびボディの内容に係る情報を保持する。

[0053] レスポンスに係る項目において、レスポンスIDおよびリクエストIDの各項目は、それぞれ、対象の検査におけるレスポンスおよびリクエストを一意に特定するIDの情報を保持する。レスポンスヘッダおよびレスポンスボディの各項目は、それぞれ、対象のレスポンスにおけるヘッダおよびボディの内容に係る情報を保持する。

[0054] 図10は、本発明の一実施の形態における脆弱性マスタ14のデータ構成の例について概要を示した図である。脆弱性マスタ14は、既知の脆弱性に係るマスタ情報を保持するテーブルであり、例えば、脆弱性に係る項目として、脆弱性ID、脆弱性名、詳細解説、リスク解説、精査方法解説、および検知内部ロジックなどの各項目を有し、検査パターンに係る項目として、検査パターンID、脆弱性ID、および検知理由などの各項目を有する。

[0055] 脆弱性に係る項目において、脆弱性IDの項目は、対象の脆弱性を一意に特定するIDの情報を保持する。脆弱性名の項目は、対象の脆弱性の名称の情報を保持する。詳細解説、リスク解説、および精査方法解説の各項目は、それぞれ、対象の脆弱性の詳細内容、想定されるリスク、および対象の脆弱性に真に該当するか否かを精査する方法について説明するテキスト等の情報を保持する。検知内部ロジックの項目は、対象の脆弱性を検知するために用いる内部ロジックの内容に係る情報を保持する。

[0056] 検査パターンに係る項目において、検査パターンIDおよび脆弱性IDの各項目は、それぞれ、対象の脆弱性を検査するための検査パターンおよび対象の脆弱性を一意に特定するIDの情報を保持する。検知理由の項目は、対象の検査パターンにより対象の脆弱性を検知した場合の検知理由を説明するテキスト等の情報を保持する。

[0057] 以上に説明したように、本発明の一実施の形態であるセキュリティテストシステム1によれば、対象Webサイト3についてDAST等の手法により自動的に検知した脆弱性について、これに対する精査や対応策についてのユーザからの質問を、チャットボット形式で対話的に受け付けて回答することができる。そして、回答に際し、回答のために必要な情報を事前に判断し、これらの情報についてユーザから提供を受けた内容に基づいて回答することで、回答の精度を向上させることができる。さらに、上記のような情報の収集や質問への回答にLLM4を利用することで、脆弱性について知見のあるユーザと同等の判断を実現することができる。

[0058] 以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。また、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記の実施の形態の構成の一部について、他の構成の追加·削除·置換をすることが可能である。

[0059] また、上記の各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば、集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリやハードディスク、SSD等の記録装置、またはICカード、SDカード、DVD等の記録媒体に置くことができる。

[0060] また、上記の各図において、制御線や情報線は説明上必要と考えられるものを示しており、必ずしも実装上の全ての制御線や情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。

産業上の利用可能性

[0061] 本発明は、Webアプリケーションの脆弱性の有無を検査するセキュリティテストシステムに利用可能である。

符号の説明

[0062] 1…セキュリティテストシステム、2…ユーザ端末、3…対象Webサイト、4…LLM、11…検査実施部、12…対話処理部、13…検査結果、14…脆弱性マスタ< / script>

Claims

1. A security test system for inspecting whether or not a web application has security vulnerabilities, an inspection execution unit that inspects the web application for vulnerabilities, records information on the detected vulnerabilities as inspection results, and presents the information to a user; a dialogue processing unit that receives a question related to a target vulnerability designated by a user in the inspection result and creates and responds to the question using an LLM (Large Scale Language Model), The dialogue processing unit inputs detailed information related to the target vulnerability to the LLM.

2. 2. The security test system according to claim 1, A security testing system in which the dialogue processing unit inputs a first prompt including the detailed information related to the target vulnerability to the LLM, inputs a second prompt to the LLM to determine the necessary answer information required to answer the question from the user, obtains the content related to the necessary answer information output from the LLM from the test results, inputs a third prompt to the LLM to answer the question from the user, and presents the content output from the LLM to the user as the answer.

3. 2. The security test system according to claim 1, The dialogue processing unit acquires the detailed information related to the target vulnerability from a vulnerability master that stores detailed information related to known vulnerabilities in advance.

4. 3. The security test system according to claim 2, A security testing system in which the first prompt includes, as the detailed information related to the target vulnerability, at least the name of the target vulnerability, explanatory information about an overview of the target vulnerability, logic for detecting the target vulnerability, and information related to a method for determining whether the detection of the target vulnerability is a false positive.

5. 3. The security test system according to claim 2, A security test system in which the information requiring a response includes at least one of a request to the web application and a response to the request, a tampered request to the web application and a response to the request, and a value of the tampered request.

6. 2. The security test system according to claim 1, The dialogue processing unit accepts the question based on a question selected by a user from a preset question template.

Images