KR20070117074A - Method and system for selfdiagnose of preservation in information network - Google Patents

Abstract

A method and a system for performing a self-diagnosis of security management in an IT network are provided to automatically request a checkup and automatically report a checkup result and countermeasures by checking a PC, to select a checkup mode of a server and the PC by each IP(Internet Protocol), and to check IT equipment. It is checked whether a checkup request for the security management is received from a user, or a request for status management is received from a system manager or a business section(203). The vulnerability checkup is executed and the checkup result is informed/confirmed if the request is received from the user(211). A self-diagnosis status and a vulnerability status of each business section are managed if the request is received from the system manager/CERT(Computer Emergency Response Team) or the business section(215).

Description

Self-diagnostic method and system of security management in information and communication network {Method and System for Selfdiagnose of Preservation in Information Network}

1 is a self-security management system diagram according to the present invention

2 is a flowchart illustrating self security management according to an embodiment of the present invention.

3 is a flowchart specifically illustrating a user checking request process of FIG. 2.

4 is a flowchart specifically illustrating a vulnerability checking execution process of FIG. 2.

FIG. 5 is a flowchart specifically illustrating a check result notification process of FIG. 2.

6 is a flowchart specifically illustrating a check result checking process of FIG. 2.

FIG. 7 is a flowchart specifically illustrating status management and registration / inquiry of the system administrator / CERT personnel of FIG. 2.

8 is a flow chart for the inspection and vulnerability status management of the business unit / department security manager of FIG.

9 is a flowchart specifically showing real-time check management in the self-diagnosis status management of FIG.

FIG. 10 is a flowchart specifically illustrating a real-time vulnerability status in the self-diagnosis status management of FIG. 7.

FIG. 11 is a flowchart specifically showing the status of each user / department in the self-diagnosis status management of FIG.

FIG. 12 is a detailed flowchart illustrating total daily / monthly statistics in the self-diagnosis status management of FIG.

FIG. 13 is a flowchart specifically illustrating registering a vulnerability analysis and action method in the vulnerability management of FIG. 7; FIG.

FIG. 14 is a flowchart specifically illustrating vulnerability registration management for each administrator in the vulnerability management of FIG. 7; FIG.

FIG. 15 is a flowchart specifically showing another administrator's vulnerability registration status inquiry in the vulnerability management of FIG.

FIG. 16 is a flowchart specifically illustrating vulnerability exception processing in the vulnerability management of FIG.

FIG. 17 is a flowchart specifically illustrating a master vulnerability DB synchronization in the vulnerability management of FIG. 7; FIG.

FIG. 18 is a flowchart specifically illustrating a system / business unit / department manager registration in general management of FIG. 7; FIG.

FIG. 19 is a flowchart specifically illustrating an IP providing method designation when a check is requested in the general management of FIG. 7; FIG.

FIG. 20 is a flowchart specifically showing real-time check status by day / month in the corresponding business unit / department check status management in step 815 of FIG.

FIG. 21 is a flowchart specifically illustrating the inspection status by user / department by day / month in the corresponding business unit / department inspection status management in step 815 of FIG.

FIG. 22 is a flowchart illustrating a detailed state chart of each department in the corresponding business unit / department inspection status management in step 815 of FIG. 8.

FIG. 23 is a flowchart specifically showing the current status of each vulnerability level in business unit / department vulnerability status management in step 815 of FIG.

24 is a flowchart specifically illustrating a re-examination of a vulnerable IP in business unit / department vulnerability status management in step 815 of FIG.

FIG. 25 illustrates user authentication for use of the self-diagnostic web server 105 of FIG. 1 in step 303 of FIG.

FIG. 26 is an exemplary view showing a portal site for PC / server self-diagnosis connection in step 301 of FIG.

FIG. 27 is an exemplary diagram illustrating information of a check request date and time, a target IP, a check policy, a check status, a vulnerability status, and a result mail status in a check status for each day in step 307 of FIG.

FIG. 28 is an exemplary view illustrating an example in which IPs managed / used by a requester are listed in steps 309 to 313 of FIG. 3, and an inspection policy is selected according to a system use purpose for each IP.

29 is an exemplary view showing an automatic check state in steps 403 to 405 of FIG.

FIG. 30 is an exemplary view showing a state of a check result mail in a vulnerability check result in steps 509 to 513 of FIG.

FIG. 31 is a diagram for checking an overview of system vulnerabilities of the vulnerability check in step 603 of FIG. 6, and an example diagram for confirming details through a site link when there is a vulnerability.

32 is an exemplary diagram illustrating an example of providing a detailed description of the vulnerability and a guide for checking the vulnerability details in step 612 of FIG. 6.

33 is an exemplary view showing the current status of the access department / department security manager access log in step 701 of FIG.

34 is an exemplary diagram showing a state of real-time check management in the self-diagnosis status management of FIG. 9;

FIG. 35 is an exemplary diagram illustrating checking of vulnerability check result for each user of self-diagnosis status management of FIG.

36 is an exemplary diagram illustrating a real-time vulnerability status in the real-time vulnerability status of FIG. 10.

37 is an exemplary view for checking the details of a vulnerability in the real-time vulnerability status of FIG.

FIG. 38 is an exemplary view showing the status inquiry by user of all workplaces in the user status of FIG. 11; FIG.

39 is an exemplary diagram for checking a check result in a user status of FIG. 11;

40 is an exemplary view showing the current status by department of the entire workplace in the current status by department of FIG.

FIG. 41 is an exemplary view illustrating a check result inquiry in a current state of each department of FIG. 11; FIG.

FIG. 42 is an exemplary view showing the inspection status by day of all workplaces in the daily statistics of FIG. 12.

43 is an exemplary view of querying the check result in the total daily statistics of FIG. 12.

FIG. 44 is an exemplary view of querying monthly usage status of all workplaces in the monthly statistics of FIG. 12.

45 is an exemplary view showing a vulnerability action method registration of the vulnerability management of FIG.

FIG. 46 is an eclipse showing registration of a vulnerability measure method of FIG.

47 is an exemplary view showing the current state of the overall vulnerability measures method of FIG.

48 is an exemplary view showing a vulnerability action method registration of FIG. 15

49 is an exemplary diagram illustrating vulnerability code registration excluded from the checking policy of FIG. 16.

50 is an exemplary diagram illustrating synchronization of a check module vulnerability state and a self-diagnosis vulnerability state of FIG. 17.

FIG. 51 is a diagram illustrating a system and security manager account management of FIG. 18. FIG.

FIG. 52 is a diagram illustrating interworking relationship with IP lookup system of FIG. 19; FIG.

FIG. 53 is an exemplary view illustrating the use status of a real-time self-diagnosis system from the security department's self-diagnosis usage status inquiry by the date of FIG. 20.

FIG. 54 is an exemplary view showing a real-time self-diagnosis use status from a system usage status inquiry for each user of the security manager of FIG. 20;

FIG. 55 is an exemplary diagram showing real-time self-diagnosis usage status of each department by date from the system administrator status inquiry of the corresponding security department of FIG. 20; FIG.

FIG. 56 is an exemplary diagram showing monthly usage status of the corresponding security manpower / department of the security manager of FIG. 21; FIG.

FIG. 57 is an exemplary diagram illustrating a real-time self-diagnosis status of each user from an inquiry of a system usage status of each user of the security manager management of FIG. 21;

FIG. 58 is an exemplary diagram showing real-time self-diagnosis usage status of each department from the system administrator status inquiry by the corresponding security department per month in FIG.

FIG. 59 is an exemplary diagram showing usage status of each department from inquiry of the system usage status chart by the corresponding management department per month in FIG. 22.

The present invention relates to a security management method and system for an information communication network, and in particular, an information communication network that notifies a result of a vulnerability check and a method of countermeasure by checking a vulnerability from a vulnerability check command in an information communication (PC, server) network. The present invention relates to a method and a system for self-diagnosis in security management.

In general, computer environments such as PCs and servers connected to the Internet have recently emerged as important issues such as network security such as Firewall and IDS, server (UNIX, NT) security, and PC security. Therefore, security support service company diagnoses client's firewall / IDS log analysis and server vulnerability through security consulting, diagnosis, solution provision, remote management service, etc., and defends DOS (Denial Of Service) through Router Based IDS, Web trend analysis and PC virus prevention system are being established. The customer's security matters such as illegal intrusion situation and DOS attack signs are monitored in real time by the control center, and the customer can immediately check all monitoring data through the web. This security system analyzes the situation immediately by the network computer emergency response team (CERT) and system CERT in case of a security situation, and simultaneously performs reverse tracking to prevent illegal intrusions and prevent customer damage in advance. It is.

In recent years, Internet services have emerged as the most important business as users can be easily serviced through the Internet, whether they have been physically serviced before. On the other hand, with the explosive development of electronic commerce, the information security environment is changing rapidly as IT technology becomes complex and diversely complex. Changes in the information security environment will lead to the rapid development of IT (PC, server) networks and the increasing dependence on IT, as well as the weaknesses of IT infrastructure. However, the security vulnerabilities in the end result in considerable damage and loss to individuals or companies when the user's security awareness and knowledge do not grow with the continuous increase of threats to the IT infrastructure, and when it is not prevented.

Conventionally, due to the passive and manual security system, each department / department or full inspection must be done from time to time. Therefore, CERT's work is increased to provide unproductive elements. There was no problem.

Accordingly, an object of the present invention is to provide a method for automatically notifying a request for inspection, a requested automatic inspection result, and an action method in the inspection of a personal PC.

Another object of the present invention is to provide a method for selecting an inspection method for a server and a PC for each IP.

Another object of the present invention is to provide a method for checking the IT equipment (DB, Web server, network equipment, etc.).

Still another object of the present invention is to provide a method for registering a method of action from a CERT / security officer and analyzing the status.

The present invention for performing the above object is the process of providing the self-diagnostic web server (Scan Manager) receives the IP information about the IP applied for the inspection,

When the self-diagnosis web server (Scan Manager) instructs the inspection agent (Scan Agent) to receive the IP information, selecting the inspection method of the PC or server and performing the inspection according to the inspection plan;

And storing the checked result in the scan manager, filtering the unnecessary exceptions of the checked items, and notifying the user.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. In the following description, only parts necessary for understanding the operation according to the present invention will be described, it should be noted that the description of other parts will be omitted so as not to distract from the gist of the present invention.

In order to implement the present invention, the main engine is composed of a check program for checking vulnerabilities, a scan manager (self-diagnostic web server), and a scan agent (check system). The vulnerability can be checked remotely. The Scan Manager is a self-diagnostic web server that provides Scan results to users by single mail and communicates with the Scan Agent. The scan agent receives a check request information from the scan manager with a check system (PC) to drive a check program.

1 is a self-security management system according to the present invention,

For the present invention, the IP management server 101, the security total web server 103, the self-diagnosis web server 105, the inspection system 107 is connected to the internal network (Network) 100, the operation and management There are user A, B terminal (109, 110) as a PC terminal, there is a user window server 113 to support the user's window, and developed for the manager system 115 and development management for user operation management to a PC terminal There is a development management server 112 for management, these are also connected to the in-house network (100).

In order to check at any one of the user A and B terminals 109 and 110 for the vulnerability check of the present invention, the self-diagnosis web server 105 is first connected through the security total web server 103. If the connection is successful, the user A and B terminals 109 and 110 are provided with an IP that requires the check and the check provided from the IP management server 101 to the connected result.

For example, the user A terminal 109 should select a check method for the servers and PCs connected to the company network 100. When the user A terminal 109 selects a PC or a server from the IP information and makes a diagnosis request, the self-diagnosis web server 105 controls the inspection system 107 to be connected to the internal network 100 and selected user terminals. In other words, the PC and the servers are diagnosed. The diagnosis result of the check system 107 is stored in the self-diagnosis web server 105. The self-diagnosis web server 105 stores the diagnosis result by e-mail, but the vulnerability and the countermeasure are transmitted together.

2 is a flowchart illustrating self security management according to an embodiment of the present invention.

A first step of checking whether there is a request for user inspection or a request for status management of a system administrator or a business unit,

A second step of notifying and confirming the result by executing a vulnerability check if there is a user check request in the first step;

In the first process, if there is a request for the current state management of the system manager / CERT or the business unit, the third process includes managing the self-diagnosis state and the vulnerability and managing the check state and the vulnerability of the business unit.

3 is a flowchart specifically illustrating a user checking request process of FIG. 2.

4 is a flowchart specifically illustrating a vulnerability check execution process of FIG. 2.

FIG. 5 is a flowchart specifically illustrating a check result notification process of FIG. 2.

6 is a flowchart specifically illustrating a check result checking process of FIG. 2.

FIG. 7 is a flowchart illustrating in detail the status management and registration / retrieval of the system administrator / CERT personnel of FIG. 2.

FIG. 8 is a flowchart for checking and managing vulnerability status of a division / department security manager of FIG. 2.

FIG. 9 is a flowchart specifically illustrating real-time check management in the self-diagnosis status management of FIG. 7.

FIG. 10 is a flowchart specifically showing a real-time vulnerability status in the self-diagnosis status management of FIG. 7.

FIG. 11 is a flowchart specifically illustrating the status of each user / department in the self-diagnosis status management of FIG. 7.

FIG. 12 is a detailed flowchart illustrating total daily / monthly statistics in the self-diagnosis status management of FIG. 7.

FIG. 13 is a flowchart specifically illustrating a method for registering a vulnerability analysis and a countermeasure in the vulnerability management of FIG. 7.

FIG. 14 is a flowchart specifically illustrating vulnerability registration management for each administrator in vulnerability management of FIG. 7.

FIG. 15 is a flowchart specifically illustrating another administrator's vulnerability registration status inquiry in the vulnerability management of FIG. 7.

FIG. 16 is a flowchart specifically illustrating vulnerability exception processing in the vulnerability management of FIG. 7.

FIG. 17 is a flowchart specifically illustrating a master vulnerability DB synchronization in the vulnerability management of FIG. 7.

FIG. 18 is a flowchart specifically illustrating a system / business unit / department manager registration in general management of FIG. 7.

FIG. 19 is a flowchart specifically illustrating an IP providing scheme designation when a check is requested in the general management of FIG. 7.

FIG. 20 is a flowchart specifically showing a real-time check status for each day / month in the corresponding business unit / department check status management in step 815 of FIG. 8.

FIG. 21 is a flowchart specifically showing the inspection status by user / department by day / month in the corresponding business unit / department inspection status management of step 815 of FIG. 8.

FIG. 22 is a flowchart illustrating a detailed state chart of each department in the corresponding business unit / department inspection status management of step 815 of FIG. 8.

FIG. 23 is a flowchart specifically showing the status of each vulnerability level on a daily / monthly basis in the department / department vulnerability status management of step 815 of FIG. 8.

FIG. 24 is a flowchart specifically illustrating a re-examination of a vulnerable IP in business unit / department vulnerability status management of step 815 of FIG. 8.

25 to 59 are views showing a state shown while performing FIG. 24 to FIG.

Therefore, a specific embodiment of the present invention will be described in detail with reference to FIGS. 1 to 59.

User check request

In the standby state of step 201 of FIG. 2, the self-diagnosis web server 105 checks in step 203 whether there is a user inspection request. The user check request in step 203 determines that there is a check request in any one of the user A and B terminals 109 and 110 of FIG. 1 and executes FIG. 3. When the user A terminal 109 checks, if the user attempts to access the secure total web server 103 as shown in FIGS. I receive a request. In step 303, for authentication, an authentication page is displayed for inputting information for authentication, and when information is input, the authentication page is checked for a match and completes authentication. In step 305, it is checked whether the authenticated user is a general user. If it is not the general user, the process is processed as a security manager in step 331. If it is not the general user in step 305, the check history (date and time of request, target IP, check policy, check status, vulnerability status, result mail status) as shown in Figure 27 in step 307. If there is a vulnerability check request for self-diagnosis in step 309 by reporting the daily check history, in step 311, the IP management server 101 selects the IP with the IP importer as shown in FIG. 28. That is, as shown in FIG. 28, when the inspection policies are classified into PCs and servers according to the application purpose of each IP, five out of seven targets are PCs, and two are to be inspected servers. The separated information is stored in step 315, which is stored in a user name, department, email address, phone number, and IP checking method (PC or server). However, in order to display the inspection result for each IP in FIG. 28, when the line with the vulnerability is clicked in step 317, the vulnerability occurrence status can be checked from the inspection result information. Vulnerability 12/3 is a "high" vulnerability in the inspection target system. You will notice that there are 12, and 3 "medium" vulnerabilities. To display the check result for each IP in step (317), display the vulnerability exception, the check result information, and the action guide in step (319). If the exception is not handled in step 323, if the vulnerability is found in step 323, the vulnerabilities found in the system are vulnerable to hacking, the system IP address to be checked, and the vulnerability guide. If you click the detailed view in the (327) process, the contents of the vulnerability explaining the effect of the vulnerability from the vulnerability master on the system, the vulnerability action / detailed action guide, the vulnerability removal / action method, and references for links to domestic and international vulnerability management sites. Guide them through the site. As described above, a vulnerability check of the next step (207) is performed from a user check request.

Vulnerability Check

The vulnerability check in step 207 can be described in detail with reference to FIG. 4. If a diagnosis request is made from the user terminal PC, the self-diagnosis web server 105 checks in step 401. The self-diagnosis web server 105 requests inspection in step 403 to the inspection system 107. The check system 107 checks whether there is a check request from the self-diagnosis web server 105 in step 403 as shown in FIG. 29, and checks the request in step 411. If there is a request in step 403, a checklist file is generated as checklist files in step 405, and in step 407, a check is executed by a vulnerability check module (program; sscmd.exe), but the termination is completed. Run until confirmed. If the vulnerability check module (program; sscmd.exe) terminates in step 409, the process may be checked again according to whether there is a re-check request in step 411. When the vulnerability check module (program; sscmd.exe) is executed in the check system 107, an option for generating a log file is specified, and a self-diagnosis client is obtained by bringing the IP list of each server or PC that requested the check specified in step 405. Run vulnerability check on the server. In practice, more than 200 IPs can be checked in parallel at the same time and created as a file. The file of the result of the check is transmitted to the self-diagnosis web server 105. The result notification of the check is performed in step 209.

Notification of inspection result

The inspection result notification in the process 209 of FIG. 2 is specifically described in FIG. 5 as notifying the self-diagnosis web server 105 of the inspection result of the inspection system 107. The inspection system 107 confirms the inspection progress state from the inspection request information in step 501. In step 501, it is checked in step 503 whether the check is completed from the result of checking the check progress status. If it is not confirmed whether the check is completed, the process waits for 2 seconds in step 515. If the check is completed, the vulnerability is counted from the check request information, the check result, and the exception process in step 505. Here, the number of vulnerabilities is counted after excluding exceptions by IP. If the vulnerability count value is greater than "0" in step 507, as shown in the beginning of FIG. 30, the htm file for transmission is generated in the mail "Vulnerable" in step 509, and marked as "vulnerable" at the same time. Clicking "Available" above will link to the results confirmation page. If the vulnerability count value is less than "0" in step 507, the htm file for transmission is generated in an e-mail of 'no vulnerability' in step 511 and the vulnerability is marked as 'none'. Mail files generated in steps 509 and 511 are periodically generated in a mailer folder in step 513 and are automatically transmitted to the self-diagnosis web server 105. The file transmitted to the self-diagnosis web server 105 checks the result of the inspection by sending an e-mail to the user A and B terminals in step 211 of FIG. 2.

Check result check

The check result check is to be confirmed by the self-diagnosis web server 105 as a user A or B terminal (109, 110) as shown in FIG. The check result mail transmitted from the self-diagnosis web server 105 is read from the user A terminals 109 and 110 in step 600, and it is checked whether the result mail is received in step 601. If the user A or B terminal (109,110) receives the result mail in step (601), it is checked whether there is a vulnerability in step (603) as shown in FIG. If there is a vulnerability in step (603), click 'Yes' in the mail content in step (605), and receive "IP, request time, user authentication information" in (607), and integrate it for checking the result in step (609). Display the authentication as a page and check whether the integrated authentication is to be performed. If it is necessary to go through the integrated authentication process (611), after the integrated authentication to go through the verification process, if not integrated authentication, as shown in Figure 31, 32, refer to the action guide in the process (612) to find the action guide for each IP vulnerability If you click 'Details' in step 613 on the display screen, the detailed guide for each IP vulnerability is found and displayed on the screen by referring to the detailed guide in step 615. Therefore, the vulnerable check requester can take prompt action by receiving the check result by e-mail like the countermeasure in case there is a vulnerability.

System Manager / CERT Status Management and Registration / Inquiry

However, unlike the case in which the user has been notified of the inspection result by requesting the vulnerability as described above, in step (213) or (217) of FIG. 2, the division manager / department security manager of the security management system of the present invention manages the current state of the vulnerability. And self-diagnostic management and vulnerability management by the administrator or CERT personnel of the security management system.

First, in the system 115 used by the system administrator / CERT personnel, the self-diagnosis web server 105 is checked through the secure total web server 103 during the current state management and registration / retrieval through the connection in step 213. In step (215), the administrator / CERT personnel of the security management system perform self-diagnosis management and vulnerability management. This will be described in detail with reference to FIG. 7.

In the system 115 used by the system administrator / CERT agent, the self-diagnosis web server 105 is accessed through the security total web server 103 at the time of status management and registration / inquiry. Is done in The administrator system 115 enters an ID and password PWD and performs authentication in step 705. If the authentication fails in step 705, the process is executed again from step 701. If encryption authentication is performed, the connection is established. In step 709, the first access is confirmed. If it is the first connection, the ID and password are newly generated in step 711, and then executed again from step 701. However, the first connection requires self-diagnostic management, vulnerability management, and general management in the process (713). The self-diagnosis management includes real-time inspection management, real-time vulnerability status, user status, department status, total daily statistics, total monthly statistics. Vulnerability management includes vulnerability analysis and action method registration, vulnerability registration management by administrator (real name system), other There are administrator vulnerability registration status inquiry, vulnerability exception handling, master vulnerability DB synchronization, and general management designates IP providing method when system / business division / department administrator registration and inspection request are made.

In the self-diagnosis status management, real-time check management is performed as shown in FIG. 9. The real-time management according to the check request information is as shown in FIG. 34. If a year, month, and date are input on the check date, the vulnerability check result for each user is displayed as shown in FIG. Therefore, in step (903), the current status is inquired according to the inspection request request from the inspection request request in the database. The result of the inquiry consists of the request time, IP, check method (policy), name, company number, division / department and progress status, phone number in the process 905 in real time. In the real-time screen of step 905, in step 907, 909, and 911, click IP, progress 'complete', and enter a request time and IP. From the input of the request time and the IP, the inspection result is queried with reference to the inspection result, the action guide, and the exception processing in step 917, and in step 919, the vulnerability list of the corresponding IP is displayed on the screen for confirmation. If the user clicks the detail view on the screen, the detailed guide is guided by referring to the detailed guide in step 927. When the exception registration and exception deletion buttons are clicked on the vulnerability list, the exception is handled in step 929. When the vulnerability code is clicked on the screen of the vulnerability list, it appears as a screen for registering the action method in step 926, and the information about the vulnerability code and the action method is stored in the action guide in step 930. When the process proceeds to the next progress state in step 913, the request time and IP are transmitted to the check request information and reset in step 931. When the batch request part is clicked in step 915, the request time and IP are reset in the check request information in step 931.

In the self-diagnosis status management, real-time vulnerability status management is performed as shown in FIG. 11. In the process (10b), the year, month, and date are inputted, and the database (DB) checks the check request information, check result, and exception processing (10c). In the process, as shown in FIG. 36, the number of vulnerabilities, a request time, an IP, a check method, a name, a division / department, and a phone number are displayed on the screen. From the real-time vulnerability status screen configuration of FIG. 36, click 'Print' in the process (10e) of FIG. 37 to print the current contents in the process (10g), click the line with the vulnerability in the process (10d), request date and IP If you enter, (10f), the database DB checks the inspection request, inspection result, and exception handling. After the inquiry is completed, if the corresponding information is checked for each vulnerability level in step (10h) and clicks print in (10i), the current content is printed in step (10j).

In the self-diagnosis status management, the status management by user / department is performed by FIG. 11, and the inspection status by user or department may be managed in step (11a). As shown in FIGS. 38 and 39, in the case of user (11b), inquiries of the number of checks for each user are inputted by inputting the year, month, day, and user name from the DB from the check request information. The inquiry result is displayed in the current status screen on a daily / month basis of the total number of checks, name, department, mail, total number of users & IP number in step (11c). If printing is clicked on the displayed screen, the current screen is printed in step 11f. In the displayed screen, click on the corresponding line in step 11e, and enter the request date and the number, and if the number of checks is checked from the check request information, the number of checks and the vulnerabilities are output. If it is confirmed that the above vulnerability exists, it is checked in step (11h) and the vulnerability of the corresponding IP is checked in step (11i).

In the case of the department in (11a), as shown in the beginning of FIG. 40, when the department / user is checked in the database from the inspection request information by inputting the department name of the year / month / day in the process (11j), the entire inspection is performed in the process (11k). The number, name, department, mail, phone, total number of users & IP is displayed on the screen by department / user.If you click on the Excel save section in step (11l), the current contents are displayed in Excel. If you click on the print section in step (11n), the current contents are printed in step (11o), and if you click the corresponding line in step (11p) and enter the request date and number, as shown in the start of FIG. By checking the check count from the request information, the check count and vulnerability details are displayed. If there is a vulnerability, the vulnerability of the IP is checked in (11s). In the self-diagnosis status management, the current status management for each statistical user can be described in detail with reference to the flowchart of FIG. 12 and FIGS. 42, 43 and 44. In step (12a), check whether the usage statistics are daily or monthly statistics. If the daily statistics, in step 12b, the total number of users is counted from the check request information in step 12b, and in step 12c, the total number of users, the total number of check IPs, name, number, department, e-mail address, and phone number are output. As shown in FIG. 42, if each corresponding line is clicked in step 12d in step 12d of the screen configuration and inputs a request date and number 4, the time-based check is performed in step 12e as shown in FIG. 43 from the check request information. It consists of the status and IP inspection policy screen. If the usage statistics are monthly statistics in step (12a), as shown in the start of FIG. 44, the total number of users, total check IPs, The name, department, e-mail address, and phone number are displayed on the screen. In the configuration screen, if you click the Excel storage location in step (12j), the current contents are saved in Excel in step (12k), and if you click each corresponding line in step (12j) and enter the request date and number, (12l) ), The monthly inspection status and IP inspection policy are composed of screens.

The vulnerability management of FIG. 7 consists of vulnerability analysis and action method registration, vulnerability registration management for each administrator (real name), inquiry of other administrator vulnerability registration status, vulnerability exception processing, and master vulnerability DB synchronization process.

The vulnerability analysis and action registration method is performed as shown in FIG. 13. In step 13a, the entire vulnerability is read from the vulnerability master, and in step 13b, it is checked whether it is a pre-registration method or an unregistered action method or checks whether an exception is handled. . If it is the previously registered measures, if the vulnerability code is clicked in step (13c) and the detailed guide is retrieved from the detailed guide in step (13d) as shown in FIG. 45, the detailed guide content is analyzed and displayed on the screen in step (13e). . If the user clicks the Action Guide registration button in the process (13f) on the screen displayed in the process (13e), as shown in FIG. 46, the registered action guide is inquired and the action guide content correction is displayed on the screen in the process (13h). Save the level's modified action guide. If the exception is handled in step (13b), click the recycle bin image in step (13i), and enter the vulnerability code. In step (13j), the exception handling registration screen is displayed. do. In the process of (13b), the unregistered countermeasure is clicked on the vulnerability code in the process (13k), and the detailed guide is analyzed and the detailed guide content analysis screen is displayed in the process (13m). If the action guide registration button is clicked on the content analysis screen, the action guide content is displayed as a registration screen in step 13o to store the corrected action at the user level.

The vulnerability registration management (real name system) for each administrator is performed as shown in FIG. 14. The process (14a) only retrieves the actions I have registered from the Action Guide. If the vulnerability code is from the search result, the corrective action is corrected. At this time, if the vulnerability code is clicked in (14c), it is inquired from the detailed guide provided by the system in (14d). If the detailed guide content appears in the analysis screen from step (14e) from the inquiry, if the action guide registration button is clicked in step (14f) from the screen, the action guide registered in advance from the action guide is inquired and the action guide is displayed in step (14h). The content modification screen is displayed and the revised action guide at the user level is saved.

The other administrator vulnerability registration status inquiry is made as shown in FIG. 15. Inquiry of the registered action method from the Action Guide in (15a), and if it is a self-registration in (15b), confirms whether it is modified or deleted in (15c). If the modification is made in the process (15c), if the vulnerability code is clicked in the process (15d) and inquired in the process (15e), the detailed guide content analysis screen is displayed in the process (15f) as shown in the example of FIG. In step 15g, if the action guide registration button is clicked from the screen, the action guide content correction screen appears in step 15i as shown in the example of FIG. 48 from the action guide in step 15h. However, if the exception is deleted in (15c), if you input the vulnerability code by clicking the trash can image in (15j), the vulnerability is deleted by asking whether to delete the vulnerability in the exception process in (15l).

The vulnerability exception processing is performed as shown in FIG. Inquiry refers to exception handling of self-registration in step (16a), and if it is a self-registration in step (16b), it confirms whether it is corrected or deleted in step (16c). If the modification is made in step (16c), the exception code is checked in step (16e) by clicking the vulnerability code in step (16d). If the above inquiry is made, the exception processing registration reason modification is displayed on the screen in step 16f as shown in the example of FIG. If the save button is clicked in step (16g) from the screen, the exception handling reason, grade, and modifier information are stored. However, if the exception is deleted in step (16c), click the trash bin image in step (16k) to enter the vulnerability code, and if you delete in step (16l) in the exception processing, delete the vulnerability code. If it is not registered in step (16b) above, click the vulnerability code in step (16h), and if the reason from exception handling is retrieved in step (16i), check the exception handler in step (16j) as in the example of FIG. Screen is displayed.

The master vulnerability DB synchronization process is performed in FIG.

Vulnerabilities in the Inspection System (Clean PC) 107 New vulnerabilities are regularly updated in the MDB file via the Internet, and in the MDB Vulnerability in the Self-Diagnostic Web Server 105 (Clean PC) (107). ) Copy the file about once a day and save it to local DB. The local MDB file read from the vulnerability MDB of the self-diagnostic web server 105 and the DB query of the vulnerability master are configured as shown in the example of FIG. 50 with the newly updated vulnerability confirmation screen in step (17a), and (17b). Click New Update Date. If you compare the vulnerability code in (17c) and update the vulnerability master table in (17d), and if it does not exist, insert the vulnerability master table in (17e) and update the vulnerability update date, vulnerability code, Vulnerability details, vulnerability details guide, and ratings are stored.

In the general management of FIG. 7, a system / business unit / department manager designates an IP providing method when requesting registration and inspection. In the general management, the system / business unit / department manager registration is executed as shown in FIG. 18, and the designation of an IP provision method is performed as shown in FIG. 19. The system / business unit / department manager registration is performed by referring to the user management in step 18a, and the entire registrant is configured as a screen in step 18b as shown in FIG. If you click ID or Beautiful in (18c), you confirm whether it is user modification in (18f). If the user is modified, the inquiry is made in (18g). Clicking the Modify button on the user modification screen in step (18h) through the inquiry (18i) updates the name, department, mail, telephone, rating, and authorization classification. If the new registration button in step 18d is clicked from the entire registrant screen in step 18b, the new user registration is displayed as a screen in step 18j. If the save button of the screen is clicked, the level is checked in step 18l. If the level is a system administrator, insert ID, null password, number 4, name, department, mail ID, phone, level, authorization classification.If the security manager is ID, random password, number, name, department, mail ID, phone, Insert a class accreditation category. If the password and the password are clicked in step 18e from the entire registrant screen in step 18b, the user is asked whether or not to delete the user's password. In step 18n, the null password is inserted.

When the check is requested, the IP provision method is performed as shown in FIG. 19.

In step 19a, check whether the IP providing method is a user local IP, an external IP management system, or self-diagnostic registration management IP information. If the IP providing method is a user local IP, in step 19b, the sentence is automatically stored by providing an IP to the user system currently connected to the self-diagnosis web server 105. If the external IP management system (19d) in the process of receiving an IP from a separate IP management server 101 is updated to specify the IP MAN character. If the self-diagnostic registration management IP information (19c) is updated in a manner to provide the IP management information in the self-diagnosis web server 105 to store the local (Local) character. In step 19d, the IP status is queried from the IP information for each user, and as shown in FIG. 52, the user IP registration and status are displayed on the screen in step 19e. In the display screen, if the IP is deleted in step 19f, the DEL button for each line is clicked in step 19g to delete the number 4 and the IP. If the IP is registered, enter the number, mail ID, business unit, department, officer, real user, IP, etc. in step (19h) and click the registration button. Then, IP information for each user is stored.

Inspection by department / department security managers and vulnerability management

 In the process of 217 of FIG. 2, if the inspection of the division / department security manager is performed and the vulnerability status management is performed, the division inspection status and the vulnerability management are performed in step 219. Operation 219 may be described in detail with reference to FIG. 8, and the integrated authentication is performed in operation 801. If the integrated authentication is not executed, the process guides the access after the integrated authentication in step 805. If the integrated authentication is confirmed in step 803 confirms that the security administrator. If it is not the security manager, the process is handled as a general user in step 807, and if it is a security manager, in step 809, the self-diagnosis for self-diagnosis is selected for the management of the current status of the division / department and the status of the inspection of the division / department. From the above self-diagnosis selection, if the division / department vulnerability status management is performed in step 811, the real-time check status, daily check status, daily department check status, monthly full check status, monthly user status Maintain monthly status charts by department. In the process of (813), if the department / department inspection status management is performed, the daily vulnerability level status of the (816) process, the current status of the monthly vulnerability level of the process, and the vulnerable IP re-check of the (817) process are managed.

In the process 815, the daily real-time check status, daily user check status, daily department check status, monthly total check status, monthly user status, monthly department status chart, daily real-time check status is shown in FIGS. Run together.

For real-time check by day / month, it is checked whether the real-time or user or department check is performed in the process of FIG. 20 (20a). In the real-time check, the request information is searched from the check request information in step 20b, and as shown in FIG. 53, the number of vulnerabilities, the request time, the status, the IP, the check classification, the name, and the department are output in step 20d. The configuration screen is updated every minute in the course of (20c), and the corresponding lines are stored in (20e, 20f, 20g) in the process of (20e, 20f, 20g) in the process of (20e, 20f, 20g). In the process (20g), if the request time from the vulnerable click is input, Ip is input, and the check result is checked in the process (20j), the contents of the vulnerability are output and confirmed in the process (20k).

If the user in step 20 (a) of FIG. 20 makes an inquiry from the check request information in step (21l) of FIG. 21, as shown in FIG. 54, the total number of checks, name, department, mail, telephone, and total in step (21m) Displays the number of users & IPs on the screen. In the configured screen, if printing is clicked in step 21o, printing is performed, and each request is clicked in step 21p to input request date and number in step 21q as shown in FIG. If you check the number of checks from the information and the result of the check, the number of checks and the vulnerability are displayed.

In the process of (21a), if the inquiry number of department / user is checked from the inspection request information in process (21s), as shown in FIG. 55, the total number of inspection, name, department, mail, telephone, and total in process (t) as shown in FIG. The number of user & IP is composed and displayed on the screen. In the displayed screen, when the Excel save and print process is clicked in the process (21u, 21w), the corresponding function is executed, and the request date and number are inputted by clicking each corresponding line as shown in FIG. 56, and checked in the process (21y). When the number is queried, the number of checks and the vulnerabilities are output as shown in FIG. 58, and if there is a vulnerability in the process (21z), the vulnerability of the corresponding IP is confirmed.

When the department status chart is harmonized by month-department in the process of (22a), as shown in FIG. 59 in the process of (22b), the total user, the total number of inspection requests, and the total number of inspection IPs are configured as a department usage statistics graph screen. If you click the graph of each department in the above configured screen, input year / month, department name, and query the inspection statistics for each department / user in the process (22d), the total user, total inspection IP number, name, department, Compose e-mail and phone on the screen.

If the business unit / department check status management in the process (813) of FIG. 8 manages the daily vulnerability level of the process (816), the current status of the monthly vulnerability rating, the management of each vulnerability level during the vulnerability reoccurrence IP management of the process (817) Referring to FIG. 23 in detail,

The status of vulnerability level by day / month checks whether the vulnerability level is to be daily or monthly in (23a). In case of daily unit, input the year / month / day, handling level, user or department or IP to check the total user, total checking IP number, vulnerability level, vulnerability number, IP, Compose the screen for each vulnerability level that shows the name and department. If Excel is clicked in step 23f from the vulnerability level screen, the current contents are saved in Excel in step 23i. If you click on print in step (23g), the current contents are printed in step (23j), click the vulnerability line in step (23h), enter year / month / day, IP, and check the check result in step (23k) Then, IP, user, department, inspection time, grade, vulnerability information is printed and the vulnerability of the relevant IP is confirmed. Click Print to print the current contents. However, in the above (23a), the monthly unit inputs year / month, vulnerability level, user or department or IP, and in step (23e), the total user, total check IP number, vulnerability level, number of vulnerability, IP, name, department are inputted. Organize by the grades indicated. If you click Save Excel in step 23n, the current screen is saved as Excel.If you click Print in step 23o, the current content is printed.Click the vulnerability line in step 23p. If you input the date / month and the IP address (23s) and check the test result, IP, user, department, test time, grade, and vulnerability information are displayed in the process (23t) to check the vulnerability of the IP. Click on Print in step 23u to print the current contents.

Vulnerability generation IP re-check management of the process (817) of Figure 8 will be described in detail with reference to FIG. In the process of (24a), enter the period, vulnerability level, and search for request and result from the check request information and check result information. From the results of the inquiry, the screens for the "high", "medium" and "low" period-generated IP list screens are constructed from (24b) and (24c), and the target of rechecking all or selected IPs is performed in (24d). Specify the inspection method of IP and enter the security manager, e-mail address, recheck date, IP list, and inspection method to request re-check.

As described above, in the detailed description of the present invention has been described with respect to specific embodiments, various modifications are possible without departing from the scope of the invention. Therefore, the scope of the present invention should not be limited to the described embodiments, but should be determined not only by the claims below, but also by the equivalents of the claims.

As described above, the present invention automatically notifies the inspection request and the requested automatic inspection result and the method of action in the inspection of the personal PC, and can select the inspection method for the IP server and the PC, and the IT equipment (DB, Web server). , Network equipment, etc.), and can register the measures from the CERT / security officer and facilitate the status analysis.

Claims (13)

       In the security management method, A first step of checking whether there is a request for checking the user of the security management or whether there is a request for the current status management of a system administrator or a business unit; A second step of notifying and confirming the result by executing a vulnerability check if there is a user check request in the first step; And a third step of managing the self-diagnosis status and the vulnerability of the division and managing the inspection status and the vulnerability of the division when there is a request for the status management of the system manager / CERT or the division in the first process. The method of claim 1, User check request in the second step The process of accessing the self-diagnosis site for integrated authentication Checking whether the general or security user is identified from the integrated authentication of the above process; In the case of the general user, the process of confirming the inspection request by checking the inspection history for each day; The process of classifying the PC or server to obtain the IP when the inspection request, and storing the inspection request information, If it is not the above check request, the process of displaying vulnerability exception, check result information, and action guide if it indicates the check result by IP; In the above process, if the exception is handled, the method is not displayed, and if it is an exception, the contents and action guides for each vulnerability are guided, and the detailed view for each vulnerability in the detailed view is configured. The method of claim 1, Vulnerability check execution of the second step is to check the check request from the self-diagnostic server and to check whether there is a request, If there is no check request in the process, the request for a predetermined time unit, Generating a checklist of the requested IPs, executing a vulnerability check module and confirming termination when the check request is made; If it is terminated in the process, characterized in that it comprises a process of checking whether there is a re-check request. The method of claim 1, If the check result is notified, checking the progress of the check from the check request information to confirm whether the check is completed; In the above process, if the progress check is not completed, the process waits for a predetermined time and counts the vulnerability when the check is completed. Generating and displaying an e-mail as a result of the check as there is no vulnerability if the count amount is within a predetermined value; If the amount of the count exceeds a certain number in the process, there is a vulnerability, characterized in that it consists of the process of generating and displaying the mail as a result of the check and automatically sending the mail regularly. The method of claim 1, Checking the inspection result is a process of receiving and reading the inspection result mail and confirming whether the reception result mail has been received. Checking whether there is a vulnerability from receiving the result message; If there is a vulnerability in the above process, the process of performing integrated authentication for checking the result by taking over the IP, request time, and user authentication information by selecting from the contents of the mail; The process of guiding whether or not to confirm the integrated authentication for the result; If the result is not integrated authentication, display the action guide for each IP vulnerability on the screen and view in detail the detailed guide for each vulnerability of the IP on the screen; If the vulnerability is not present, the method comprises the step of accessing the self-diagnosis site to the end of the mail check. The method of claim 1, Access to a web server dedicated to self-diagnosis management, enter ID / password and perform encryption authentication when there is access by system administrator / CERT personnel; If the authentication is successful, if the first connection is displayed on the screen to create a new ID and password, if not the first connection, characterized in that the process of self-diagnostic status management, vulnerability management, general management. The method of claim 6, Self-diagnosis status management is the process of managing the real-time check and vulnerability status, The process of managing the status by user / department, The method consists of managing the whole daily / monthly statistics. The method of claim 6, Vulnerability management involves the process of registering vulnerability analysis and countermeasures, Administering vulnerability registration for each administrator, This method consists of querying the status of other administrator's vulnerabilities, and processing the vulnerability exception processing and synchronizing the master vulnerability database. The method of claim 6, General management includes the process of registering the system / business division / department management site, The method characterized by consisting of the process of specifying the IP providing method when requesting inspection. The method of claim 1, If you are a security manager by conducting integrated authentication when you are a division manager or department security manager, If the self-diagnosis in the above process is characterized in that the self-diagnosis site consists of the process of managing the current status of the division / department and the department / department vulnerability status management. The method of claim 10, The department / department inspection status management consists of managing the daily real-time inspection status, daily user inspection status, daily department inspection status, monthly total inspection status, monthly user status, and monthly department status chart. The method of claim 10, If the business unit / department vulnerability status management in the above process, characterized in that consisting of the process of re-checking the current status of the vulnerability level and the vulnerability IP by day / month. In the security management method, Receiving IP information on the IP applied for the security check; Selecting the inspection method for each PC or server according to the received IP information and performing the inspection according to the inspection plan of the PC or server; And storing the result of the check and notifying the user or security officer / CERT after filtering out unnecessary exceptions of the user.

Images