JP2006107387A - Method and device for real time security certification for on-line service - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a system capable of warning a user of a new threat as a result of proper security scanning offered by an on-line service. <P>SOLUTION: A security system includes a scan engine 302 periodically and completely scanning a connection component for the on-line service such as a network and a web site. The result of scanning is stored and reported to the service via an alert and the like. The Web site includes an image map clickable by a visitor. An appearance of the image map can be changed according to a predetermined security level of the Web site. (For example, the image map can be made to be invisible.) The visitor can view a web page showing a security status of the Web site by clicking the image map. On the basis of a review on the Web page, the visitor can decide whether the web site is reliable or not and trade is to be operated or not. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to security certification, and more particularly to a method and apparatus for performing real-time third party certification regarding the security status of a website or other online service.

  Although e-commerce has grown rapidly in recent years, problems remain that limit future growth. For example, many consumers who are likely to exchange or provide personal information online will find that the website operator has personal information such as the consumer's name, address, purchase preferences, credit card information, etc. He is hesitant to conduct e-commerce because of concerns that sufficient security measures have not been taken to protect the company.

  FIG. 1 is a high-level block diagram illustrating an example environment of the present invention. As shown in FIG. 1, the environment includes an online service 102 having one or more websites 104 and visitors 106 accessing the online service websites via a network 108 such as the Internet. In FIG. 1, only one service 102 and one visitor 106 are shown for clarity of the present invention. However, it will be apparent to those skilled in the art that there may be tens, hundreds, thousands and / or millions of services 102 and visitors 106 depending on the type of network 108.

  Online service 102 is typically any other Internet or network service that obtains and / or maintains personal or confidential information of electronic commerce operators or consumers. Such services are interested in removing the concerns and resistance that consumers may have about exchanging and sharing personal information with the website 104. Thus, the service 102 may perform its own security scan on the website and use the results to ensure that the consumer's information is safe. For example, such scans may be used by hackers that access website systems to damage websites, steal website visitors, or steal important information about websites and visitors. Designed to detect vulnerabilities to threats.

  A visitor 106 visits or is thinking of visiting a website 104 or other internet service provided by the service 102 via a PC and modem, web kiosk, or other internet access device. Other parties. Visitor 106 is a consumer or other party interested in purchasing goods from, or in any way transacting from, the online shop, service or information base of service 102 (not necessarily an individual consumer). Not possible). Visitors 106 ensure that online services and websites protect personally identifiable information, credit cards, financial, medical or other information with sufficient security measures to protect the privacy and security of information, indirectly May not be intrinsically credible to guarantee visitor safety.

Website 104 includes conventional system components for providing online services to visitors. As will be apparent to those skilled in the art, components of website 104 may include, but are not limited to:
A server such as a computer system that provides a part of the service.
-Network components such as network routers, switches, and hubs.
・ Firewall.
·operating system.
Components and applications related to licensing technology such as web servers, application servers, electronic commerce applications, RDBMS database engines, etc.
Customer description applications such as shopping carts, information systems containing personal information about visitors, and other application components.
Network operating systems and protocols such as SNMP, ICMP, TCP, IP, DHCP, IIOS.

  Recently, attempts have been made to provide security credentials so that visitors 106 can conduct electronic commerce and other transactions with the service 102 with peace of mind. For example, VeriSign (a registered trademark of VeriSign) and TRUSTe allow online services to display stickers (eg, images created by GIF or other image files) on a website when a product is purchased. However, no actual security testing is done on the site. Thus, such a seal does not indicate the true vulnerability of the service 102 to hacking, cracking, worms, Trojan horses, etc. Nor does it provide visitors with a security assessment of the data held on the website 104 or audit the security measures of the service 102.

  For example, VeriSign does not scan a customer's server for security vulnerabilities. In fact, VeriSign uses SSL (secure sockets layer) to ensure the proper installation of VeriSign digital certificates (numeric strings that are public key infrastructure (PKI) encryption technology) and the security of visitor transaction packets. Not even confirmed for use. As noted above, the VeriSign seal does not prove to the visitor 106 that the service 102 is not vulnerable to hacking, cracking, worms, Trojan horses, and the like. Even if the user clicks on the VeriSign seal, VeriSign only displays a web page indicating that service 102 has purchased a VeriSign digital certificate or other product and VeriSign has verified the identity of service 102. .

  Similarly, TRUSTe does not perform security tests on networks and servers that operate electronic commerce systems using seals. If you purchase a TRUSTe seal, TRUSTe will verify that the service's privacy policy meets TRUSTe's requirements, and browses the website to confirm that it appears to comply with the policy. However, it does not check the actual security of the server and network equipment that provides the service 102.

  As another example, attempts have been made to provide third-party certification for online services, such as certification services offered by Qualys (trademark or registered trademark of Qualys, USA). In such third party certification services, www. nessus. Sometimes an open source tool such as that provided by org is used. However, Qualys et al. Do not provide a seal or other means for visitors 106 to access the results of the certification service or to verify the actual security of the service 102. Also, Qualys et al. Do not check for new server vulnerabilities that may occur during an automatic security check of the website 104 used to operate the service 102. For example, scans are only performed periodically or infrequently, but new threats to security such as worms can occur many times a day. At present, it is not possible to alert service 102 about new threats that may occur during a scan by such a third party approach.

  That is, none of the conventional approaches described above is fully reliable, does not properly check for new threats during security scans and alert the service 102, and / or is used directly by the visitor 106 It is not possible.

  The present invention relates to security certifications, and more particularly to providing third party certifications of online service security status.

  The present invention realizes a security certification system that allows a consumer to confirm the actual security status of a website before a user trusts the website and conducts a transaction by uniquely combining a plurality of functions. In one embodiment, the security system includes a scan engine that periodically and completely scans connected components of online services such as networks and websites. The result is stored and reported to the service by an alert or the like. The website includes an “image map” that visitors can click on. By clicking, the visitor can see a web page that shows the security status of the website. Based on the web page review, the visitor can decide whether to trust the website for further transactions.

  According to another embodiment of the present invention, online service components are stored and compared to their recorded characteristics when new vulnerabilities occur. Depending on whether the recorded features match the components of the online service, an alert to the online service can be generated without performing an actual scan.

  In accordance with another embodiment of the present invention, the security certification system maintains one or more online service security meters accessible to visitors. For example, the security certification system can maintain and provide current and / or historical security scores and corresponding graphic indications of one or more online services.

  According to yet another embodiment of the present invention, the appearance of an “image map” for website visitors may appear or disappear as an indication of a website that has exceeded or not exceeded the security audit threshold. , Controlled to change. This is to display an “image map” only when the security audit criteria or security status level is met, and to display a single-dot “clear” image or other alternative image if the security criteria are not met. Made by. The result is a simple but understandable indication of the security status of the visited site due to the appearance of the image map or the absence of the image map.

  The present invention will now be described in detail with reference to the drawings, which are provided by way of illustration of the invention so as to enable those skilled in the art to practice the invention. The drawings and the following embodiments are not intended to limit the scope of the present invention. In addition, when a certain component of the present invention can be partially or completely realized by using a known component, a portion necessary for understanding the present invention in such a known component. Only detailed descriptions of other components of known components are omitted so as not to obscure the present invention. In addition, the present invention includes present and future known equivalents of known components referred to herein by way of example.

  FIG. 2 is a high-level diagram illustrating an example environment of the present invention. As shown in FIG. 2, the online environment further includes a security system 200. Typically, the online service 102 contracts with the security system to provide a third party security certification service for one or more websites 104 that operate, and the result is a simple method, as described in more detail below. Can also be used by the visitor 106.

  Preferably, the system 200 is functionally and physically separated from the online service 102 and is located at a remote location (ie, an IP address on the network 108 that is completely separated from the service 102 and has no relationship). And the system 200 is not controlled by the same operator as the service 102 in any corporate or other manner). That is, system 200 has only the level and type of public and / or network access to service 102 that hackers and other threats have. Such functional, physical, managerial, administrative, and legal separations provide visitors 106 with an independent, information-proven security credibility level that has not previously been available. Can do.

  Security system 200 typically includes components for providing third party security certification services to both online service customers (eg, service 102) and visitors 106. FIG. 3 is a block diagram illustrating in more detail an embodiment of the security system.

  As shown in FIG. 3, the security system 200 of this embodiment includes a scan engine 302, a customer information database 304, an alert engine 306, a report engine 308, and a certification engine 310. It should be noted that the system 200 can include many other known or new components and functions, such as providing system administrator access, providing web server and other network access, and other storage and processing capabilities. However, a more detailed description of such components and functions is omitted so as not to obscure the present invention.

  In one embodiment, the security system 200 is implemented as a Sun computer running on Solaris. In such an embodiment, engines 302, 306, 308 are real-time software processes developed using Java. Solaris, Sun and Java are trademarks or registered trademarks of Sun Microsystems, Inc. Database 304 may be implemented using a database, flat memory, and / or other known equivalents.

  The scan engine 302 remotely acquires and generates information about open ports, available services, network protocols, security exposures, and vulnerabilities that exist on servers and other devices available over the network. Known remote security scanners such as engines (details are available from www.nessus.org) and the like can be included. Accordingly, the scan engine 302 periodically checks the web server and / or network device of the service 102 to find website component configurations and vulnerabilities. The scan engine 302 first scans an open port of a device registered in the customer information database 304. In one embodiment, such as the Nessus open source engine, the scanning process generates a set of XML files that contain all the information collected during the scan. These files are analyzed by the scan engine 302 and stored in the database 304. The record is associated with a customer account number and thus customer registration information.

  As described above, the scan engine 302 stores information about completed scans for open ports, security exposures, vulnerabilities, servers or other network devices, and stores that information for a particular customer (eg, website operator). 102). Customer information database 304 stores information regarding the scans performed for each customer service 102 company, user, website, and website or other device associated with the website. The stored information includes a scan header record that includes the number of vulnerabilities classified by date, start time, duration, and severity level. Also, the stored information is actually executed on open ports, including open sockets on scanned devices, generic services to be executed on those ports, version, network message protocol and other available information. Contains information about services that are available.

    The alert engine 306 is a service that alerts the service 102, a customer of the system 200, of potential or confirmed security vulnerabilities by emailing and / or online reporting of events. Such alerts can be based on device and / or service information discovered at the time of scanning compared to vulnerabilities associated with devices and / or services stored in database 312. According to a further embodiment of the present invention, an alert can be generated by comparing and matching the information on the existing service 102 stored by the previous scan with the information on the newly discovered vulnerability. Newly discovered vulnerabilities can be collected by the system, analyzed as feature records with recorded vulnerabilities, and stored in the database 312. These records include devices or services related to the vulnerability. If a new vulnerability record is entered into the database 312 and the new vulnerability may cause a security issue for the customer's service 102, the alert engine 306 may generate an alert for the service 102. Can do.

  In one embodiment, alert engine 306 includes an email server that maintains an inbox for one or more users of each registration service 102. As alerts are generated, alert engine 306 places them in the inbox and notifies each user according to the priority and threshold associated with each user. The email server of the alert engine 306 has functions to allow the user to access, view and delete email alerts from the inbox. The alert engine 306 can also be configured to send an email to a valid email address. Although e-mail is one of the possible notification methods, other automatic notification methods such as paging, instant messaging, and telephone voice messages can also be used.

  The customer information database 304 includes account information and scan information relating to devices of the service 102 registered in the system 200. A registered service 102 user can, for example, log in and review interactive reports regarding scans included in the system. Report engine 308 generates tables, graphs, and content provided in interactive reports based on information in database 304. In one example, the report engine 308 provides such reports to users and / or administrators of the service 102 using, for example, a web server interface.

  The information in the customer information database 304 and the vulnerability feature database 312 can be initialized manually (for example, through a system administrator) and automatically by various methods. Details of the embodiment will be described below. Further details will be described. Further, the security information in the database 304 need not include only information automatically detected and input by the scan engine 302. In addition to the initialization information provided by the system administrator, other manual inputs can be made to the database 304 by the system administrator of the service 102 or other authorized party. For example, the service 102 may affect the security of the service 102 but cannot be automatically collected via the scan engine 302, such as a security policy of the service, eg, password policy, network architecture, internal and external security policy Hire consultants or other third parties to regularly audit policy enforcement, employee termination policies, and other indications. The database 304 can include fields for such additional information, which are alert engines, report engines, certifications for alert generation, reporting, and security assessment, as described in more detail below. It can also be accessed from the engine. Therefore, this should be considered as an alternative or additional embodiment of the present invention.

    The system 200 may further include a function for enabling the service 102 to notify the system 200 of a false positive. For example, if an alert email is sent about a detected vulnerability and the service 102 determines that the alert is not an actual threat, the service 102 may identify the vulnerability until no vulnerability is found on the device. You can notify the system to ignore it. If a vulnerability identified as a false positive by the service 102 does not appear after a predetermined number of scans or elapsed time, it is not flagged as a false positive and is completely removed as a possible vulnerability. If the vulnerability appears again, the service 102 is alerted again, and the service 102 checks again whether the vulnerability is a false positive and reports it to the system 200.

  The specific method for causing the service 102 to identify the vulnerability can be realized in many ways. For example, the system 200 can have an administrator interface for an administrator to receive and review reply emails from the service 102 and manually update the database. As another example, system 200 (eg, report engine 308) may include a page and associated script (eg, a check that appears adjacent to a reported vulnerability) for a user of service 102 to view and modify a system vulnerability report. A web server interface that provides a script associated with the box).

  The certification engine 310 provides the registered service 102 with security status information to the visitor 106. For example, when the scan engine 302 completes the scanning process and the process results are uploaded, the customer information database 304 is updated with the security status. In one embodiment, the service 102 registered with the system 200 may “image map” (eg, a GIF or other image file with a hyperlink to an associated URL or script) on a web page displayed on the website 104. Place. Clicking on such an “image map” sends an HTTP request to the certification engine 310. The certification engine 310 determines a particular service 102 corresponding to the HTTP request, retrieves the security status of the corresponding service 102 from the database 304, and clicks on a page of information that includes the corresponding service 102 security status. Respond by displaying on.

  In another embodiment, rather than simply displaying the saved security status from the database 304 to the visitor 106, estimating the security status displayed to the visitor 106 to the point in time when requested by the visitor. Can do. Such an up-to-date security status is derived by checking the number of vulnerabilities at a severity level stored in the database 304 for the requested service 102 and giving the service 102 a grace period to resolve the problem. be able to. If sufficient vulnerabilities have existed for a sufficiently long period of time, for example if the unencrypted FTP service has been running on the website 104 for more than 48 hours, the security status of the service 102 is downgraded can do. If the vulnerability is resolved or if the service 102 identifies it as a false positive, the security status is automatically upgraded and the visitor 106 next time provides an image map of the page displayed by the service 104 website 104. Displayed when clicked.

  The security status information can be provided to visitors of the website 104 in a variety of ways besides the image map provided on the page of the website 104 that transitions to a simple evaluation page upon clicking. For example, the certification engine 310 can transition to a detailed security meter page when an image map is clicked, as described in more detail below. As another example, the certification engine 310 can display the latest security status directly on the page instead of an image map, for example, by continuously updating a GIF file accessed by a website. . The teachings according to this embodiment will allow those skilled in the art to devise further alternative means, which should be regarded as further additional or alternative embodiments of the present invention.

  Next, an embodiment of a method realized by the security system 200 according to the security certification of the present invention will be described with reference to the drawings.

  FIG. 4 is a flowchart showing an example of processing steps performed by the scan engine according to an embodiment of the present invention. For ease of explanation, a process for scanning only one registered service 102 will be described, but those skilled in the art will understand that multiple threads can be assigned to multiple services 102, for example. .

  The following example scan engine process is consistent with the GPL licensed Nessus project vulnerability scan engine used to collect security information for remote services 102 in one embodiment of the invention. Full spec details, source code, list of vulnerabilities scanned by Nesus can be found at www. nessus. org's web page, which is hereby incorporated by reference into the present disclosure. However, details of many additional embodiments of the scan engine described below, such as the scheduler approach and the process of storing scan results in a customer information database, are embodiments of the present invention. These and other embodiments of the present invention will become more apparent from the following description.

  At engine startup (step S402), the port scanner creates a worker daemon that interacts with common logs, dumps, and other system files. These daemons request test jobs from worker management processes that can manage queues and run many tests on one or more devices in parallel.

  Typically, the scan engine is invoked for each device registered by the customer service 102 in the customer information database 304 according to the schedule requested for each device. In one example, the customer is given five possible queues to schedule a scan for service 102. For example, immediately or once a day at 1 am, 7 am, 1 pm or 7 pm. Thus, after the engine is invoked for a particular device (step S404), in step S406 it is determined whether a scan for the particular device is currently scheduled. If the scan is not scheduled, the next device is retrieved from the customer information (ie, control returns to step S404). Otherwise, scans for specific devices are queued and run randomly by scan engine daemons and threads set at engine startup. These require the queue to scan for devices. Each scan continues to run until completion or until a timeout due to customer server or network unavailability.

  If scanning of a specific device is started (determined in step S406), the first step is to check which ports are open by scanning all ports on the device, as shown in step S408. Identify what network transport and message protocols are provided on the port and what services are listening on the port. Next, the scan engine adds the open port information to the historical port scan information already stored in the customer information database 304 by the previously performed scan.

    In one embodiment, for a server being tested (eg, a web server associated with website 104), a TCP ping command is used to check if the device is available. For this purpose, the system is www. insure. Nmap, an open source tool managed by org, can be used. Using Nmap, the scan engine establishes a full connection with each port and attempts to interpret the returned data. This data is stored in the database 304. In one example, Nmap is issued using the -n, -p, 1-15000, -sT, -O, -r switches. Dedicated scripts can check ports using, for example, UDP and ICMP services.

  In step S410, the scan engine attempts to find a service running on the discovered open port. The Nessus open source engine includes a program for this. The list of detected services and the list of open ports are stored in the database 304 and can be used in subsequent processing to determine which vulnerability test script (.NASL or .NES file) to run.

  The process proceeds to step S412, and the scan engine selects a vulnerability test to be executed on the server according to the information collected during the port, protocol, and service discovery scan performed on the device. The worker daemon requests a queue test job from the worker management process. This continues until all relevant vulnerability tests have been completed. In embodiments using the Nessus scan engine, positive test results are stored in a file in XML format.

  In step S414, the scan result is analyzed by the scan engine. In an embodiment using Nessus, the process parses information in XML format and uploads it to the database 304. For example, a summary record of the scan of this device is created, and a detailed record of each positive test result associated with the scan of this device is created. All results are associated with the device's master file record registered in the database 304 associated with the customer's corporate account record stored in the database 304. This data can be used to calculate the security status of the service 102 and create an interactive report for inspection by a customer user.

  When step S414 is completed, the process returns to step S404 to scan the next device of the service 102.

  FIG. 5 is a flowchart showing an example of processing steps performed by the alert engine according to an embodiment of the present invention.

  The alert engine enables users of the service 102 who are customers of the system 200 to maintain security by sending alert emails when certain events occur on the site. The security system tracks alerts sent to the user and stores them in the database 304.

  In one embodiment of the alert engine, the engine loops each device of the customer's service 102 intermittently and periodically (eg, determined in step S502 by checking device information in the database 304) and alerts to that device. Determine if you need to send. In one example, an alert is issued under two circumstances. First, an alert can be issued if there is a new alert in the system for a serious or critical vulnerability. This is detected in step S504. If a new vulnerability is input, the process proceeds to step S506, and the recorded feature of the new vulnerability is compared with device information. The recorded features include device information that allows such comparison. For example, if a service includes a device (a brand router) and a new SNMP vulnerability for that particular brand router is entered into the system, the device may be vulnerable to a new threat. If it is found that a new vulnerability may affect the device (determined in step S508), an alert may need to be issued. The process branches to step S512 to determine whether an alert email should be sent.

  An example where a new threat is entered into the system is described in more detail below. For example, the system 200 sends a newly updated vulnerability test script to nessus. It can include a process that periodically requests org. New scripts are automatically downloaded to the test area and they are manually modified to incorporate devices and other tags important to the system. Another process of the system 200 parses the special tag and creates a recorded feature record for each new vulnerability received, which is stored in the database 312. The recorded feature record of the vulnerability is compared with the recorded feature information of all customer devices stored in the customer information database by the alert engine to see if the customer can be exposed to new threats Can be used for In addition, the recorded feature record of the vulnerability includes information to identify the severity of the vulnerability, and this information is used to calculate the security status for the customer as described in more detail below. can do.

  A second example that triggers an alert is when a device scan detects a change in the security status of the device (ie, a security status alert). This is detected in step S510. For example, if the device is a new device detected and tested for the first time in the scan (step S412 in FIG. 4), and the new device is found to be vulnerable, the alert engine 306 Information is detected, and the process branches to step S512. An alert can also be sent when a potential negative change in the security status of the device occurs. For example, if a “critical” level vulnerability is discovered and not resolved within 48 hours, the overall security rating of service 102 changes from “safe” to “active”. Another “final alert” alert is sent within 4 hours of a negative status change. Final alerts are sent on status changes that notify the user of changes.

  In any of these status change events, the process proceeds to step S512 to determine the severity of the threat to security. For example, a particular threat may have one of the levels defined in ascending order of severity (attention, alert, critical, serious). In one example, the levels associated with the vulnerabilities are included in and extracted from the recorded features of the vulnerabilities included in the records in the database 312.

  The processing moves to step S514. In step S514, a loop for each user of service 102 is started. This information is stored in the customer information database 304. Each user (which may include an administrator) can prioritize what alerts are received for which devices. If all users receive the alert, the process returns to step S502 to check the next device of the service 102 in the loop.

  User priorities are loaded in step S516. Next, the priority is compared with the device identifier and the vulnerability severity level calculated in step S512. If the level or type of vulnerability that the user wishes to receive alerts is not, control returns to step S514. Otherwise, the process moves to step S518 and an alert is sent to the user. In one example, this is done by placing an alert email in the user's inbox and sending a message to the user containing a URL indicating the email.

  Note that the threshold determination processing in step S516 should not be performed for certain types of alerts. For example, security status change alerts cannot be suppressed. In this case, each alert is put in an alert receiving box, and an e-mail notifying the number of various alerts received is sent to the user. If there are no vulnerabilities that exceed the user-selected threshold (up to the alert), no alert is sent.

  Note that other types of alert emails can be sent to a specific user or all users of the service 102. For example, an alert is also sent when a scan is complete and can include a brief summary of the scan results along with a device summary report for each device.

  In the following, an example of an alert email system will be described in more detail. For example, the system administrator for each registration service 102 can choose to have the alert emails received or controlled by all users or not controlled by all users. If allowed, each user can choose to receive various alerts. However, it is preferred that the administrator cannot choose not to receive critical or serious level alert emails. Administrators or users can suppress any level of alerts for regular users. The administrator can choose not to receive only alert or attention level alert emails. In the embodiment using email, as described in more detail below, all alerts enter the user's alert inbox and remain in the inbox until the user discards them.

  The summary alert inbox includes all alerts that have not been deleted from the inbox. A check box is provided on the left side of each alert. The administrator can check the box and press the “Delete” button for the selected alert located directly below the check box column of the alert inbox. After that, the screen is refreshed and the checked alerts no longer appear.

  The device alert inbox lists only alerts that apply to certain devices. Again, the administrator can delete the alert. Deleting an alert removes it from the system and does not appear in the summary or device inbox.

  When an alert is deleted, it no longer appears in any inbox. In the alternative, the alert engine includes functionality that allows the user to view deleted alerts by entering a date range. For example, the alert engine may display a “view history” button above each alert inbox with a date range input field. This button can be associated with a CGI that displays a list of all alerts opened during those dates.

  An alert detail display option may be provided to accept two types of alerts in the system. For example, alerts resulting from new “potential” vulnerabilities can cause an alert detail screen to be displayed that includes comprehensive vulnerability description information. Alerts resulting from scanning can provide vulnerability scan results in addition to comprehensive alert information. This is the same as the other alert details page, except that it has an additional field that displays the detailed scan results obtained during the scan that generated the alert.

  Hereinafter, an example of processing executed by the certification engine according to an embodiment of the present invention will be described with reference to FIG.

  In one embodiment of the certification engine, the service 102 registered with the system 200 displays an “image map” (eg, a GIF file with an associated URL) that is displayed on a web page displayed by the website 104. The Thus, a visitor 106 who visits the website sees an “image map”. If you wish to receive a third party certificate of website security, you can click on the image map. In that case (step S602), an HTTP request for the security system 200 is generated by the URL, and the request is received by the certification engine 310 of the system 200 (step S604). The request also includes an IP address that references the website 104 that the visitor 106 was visiting. The IP address is extracted in step S606. The address is compared with the address in the customer information database 304 corresponding to all registered services 102 of the system. If the extracted IP address does not correspond to any of the stored addresses, an unconfirmed screen is displayed to the visitor 106 (step S610), indicating that the service 102 is not a scanned service. Notify visitors.

  If the extracted IP address corresponds to the stored IP address (determined in step S608), the security status information of the related website is searched from the customer information database 304. For example, the number of critical and serious vulnerabilities found on the website 104 and the date and time of discovery are queried using the extracted IP address. Next, the status level of the website is calculated in step S612, and a web page including the status is provided to the visitor 106 for display on the visitor's web browser (step S614).

  An example of calculating the instantaneous security status of the service 102 in step S612 will be described below. First, the system checks whether the service is registered, and if not registered, the status is set to “unprotected”. If the service 102 is registered but does not have the IP address of the registered / approved website 104 (an example of verifying whether the website is registered will be described later), the status is “ Set to “TBD”. If a service has a critical or serious vulnerability that has already been identified, has not changed for more than 48 hours (or other period adjusted in the system configuration file) and is not marked as false positives, The status is set to “active”. If the service has been scanned within the last 72 hours and has no outstanding critical or serious vulnerabilities that occurred before 48 hours, the status is set to “safe”.

  Note that the security status calculated in step S612 may not be based solely on the result of the last scan performed on the service 102. The security status presented to the visitor 106 can be estimated up to the point of visitor's request. Such an up-to-date security status is by checking the number of vulnerabilities above a certain severity level stored in the database 304 for the requested service 102 and giving the service 102 a grace period to resolve the problem. Can lead. If sufficient vulnerabilities exist for a sufficiently long period of time, for example, if a critical or serious vulnerability has been outstanding for more than 48 hours, the security status of the service 102 can be downgraded. If the vulnerability is resolved or is identified as a false positive by the service 102, the security status is automatically upgraded and the visitor 106 provides an image map of the page displayed on the service 104 website 104. Displayed the next time you click.

  In the following, alternatives to the methods and services described above in connection with FIG. 6 will be described. Similar to the certification engine embodiment described above, the service 102 registered in the system 200 can receive an “image map” image (eg, a GIF file with an associated URL) on the server 104 of the security system 200 on the website 104. HTML code is provided for display on the displayed web page. Depending on the current security status of the service 102, an action in the security system 200 displays either a security indication image (ie, a HACKER SAFE image) or a single dot clear GIF image. Thus, a visitor 106 who visits a website can see an “image map” if the website 102 has a security status that meets certain criteria, and if the security status is lower than that criteria, You can't see the image map, or you'll see an alternative image map image. Also, if the visitor 106 wishes to receive additional information regarding the security of the website, the image map can be clicked when the image map becomes visible. If the HTTP code on the website 102 causes an HTTP request to the security system 200, the request is received by the certification engine 310 of the system 200 (step S604). The request includes an IP address that references the website 104 that the visitor 106 was visiting. The IP address is extracted in step S606. The address is then compared with the address in the customer information database 304 corresponding to all registered services 102 of the system. If the extracted IP address does not correspond to any of the stored addresses, a single dot clear GIF image or other alternative image is displayed to the visitor 106 (step S610) and the service 102 Notify visitors that it is not a scanned service.

  If the extracted IP address corresponds to the stored IP address (determined in step S608), the security status information of the related website is searched from the customer information database 304. For example, the number of critical and serious vulnerabilities found on the website 104 and the date and time they were found are queried using the extracted IP address. Next, the status level of the website is calculated in step S612. If the status level satisfies a certain standard, a display image / map image such as a “HACKER SAFE” image is displayed for display on the visitor's web browser. Is provided to the visitor 106 (step S614). On the other hand, if it is calculated in step S612 that the status level of the website is lower than the reference, a “dot” such as a single-dot clear GIF image or other alternative image is displayed for display on the visitor's web browser. An “invisible” image is provided to the visitor 106 (step S614), and the indication image / map image appears to disappear or otherwise changed to indicate that the website does not meet the status level .

  In one embodiment, the security status displayed to the visitor 106 has the shape of a meter that is a dynamic graphic that displays the actual security status according to a security scan (a method similar to that described with reference to FIG. 6). use). One such security meter embodiment is shown in FIG. 9A. As shown in FIG. 9A, the meter 902 is a graphic indicating whether the status evaluation is “low”, “medium”, or “high” corresponding to the above-mentioned “active”, “undecided”, and “safety”. Includes a sign bar that only displays. In addition to indicating a discrete value, it may also indicate a numerical value in a continuous range calculated by a time average over the past two weeks or other periods, where the range is a normalized numerical value such as 0-10 . Another embodiment of a security meter is shown in FIG. 9B. As shown in FIG. 9B, the display is more detailed and includes an overall numerical evaluation 904 and a security meter 906 that is the basis for the overall numerical evaluation. As shown in FIG. 9B, these can include scan frequency, remediation speed, vulnerability frequency, latest scan, percentage of servers tested, and current status.

  Many other features and advantages can be envisioned by generally providing a third party security certification service in accordance with the present invention. In this regard, FIG. 8 is a block diagram illustrating an alternative embodiment of a security system 200 '.

  As shown in FIG. 8, the security system 200 ′ further includes a security website 802. Website 802 responds to public requests for pages over the Internet or other network 108. In response to such a request for a page, website 802 retrieves security status information from customer information database 304 and displays it. The security status information may be for a specific website registered in the system 200 'or for all registered websites. In the preferred embodiment, the displayed status has the shape of a security meter. One possible example is shown in FIG. As shown in FIG. 10, a web page is displayed that includes a list of websites that the visitor is interested in, and an associated meter 1002 indicates their overall security status. Meter 1002 can be on a continuous scale calculated as described above in the embodiment shown in FIGS. 9A and 9B or otherwise. The displayed website can be selected in various ways by the visitor or can be provided automatically.

  In yet another embodiment, the certification engine may include additional functionality to confirm registration of the website 104 of the service 102 to enable a third party certification service for visitors of the website 104. it can. This alternative embodiment is described in further detail with reference to the flowchart of FIG.

  As shown in FIG. 7, a customer whose service 102 is registered with the system 200 logs into the system 200 and the IP address of the website 104 or other online service to make available third party security credentials by the visitor 106. / Device information is input (step S702). At the same time, the service 102 places an “image map” (eg, a GIF file with an associated URL) provided by the system 200 on a page maintained by the registered IP / device 104 and places the image map in the system 200. Provides the URL of the site 104 where the is located. Next, the certification engine proceeds to the URL and determines whether the image map is at a specific position by checking the file name (step S706). If the image map is not at a specific location, the system 200 alerts the service 102 (step S708). In other cases, the registration is confirmed and the information of the service 102 in the database 304 is updated. Thereafter, a visitor 106 visiting the site 104 can obtain a third party security certificate from the system 200 by clicking on the image map.

  Although the invention has been described with reference to particularly preferred embodiments, alterations and modifications in form and detail will be readily apparent to those skilled in the art without departing from the spirit and scope of the invention. For example, it will be apparent to those skilled in the art that the number and order of the processing steps shown in the flow diagram above can be varied. The appended claims are intended to cover such changes and modifications.

FIG. 3 is a high-level block diagram illustrating an example environment of the present invention. FIG. 3 is a high-level diagram illustrating an example environment and embodiments of the present invention. It is a block diagram which shows the embodiment of the security system concerning this invention in detail. It is a flowchart which shows the example of the process step performed by the scan engine which concerns on 1 aspect of this invention. It is a flowchart which shows the example of the processing step performed by the alert engine which concerns on 1 aspect of this invention. It is a flowchart which shows the example of the process step performed by the certification | authentication engine which concerns on 1 aspect of this invention. It is a flowchart which shows the example of the alternative or additional process performed by the certification | authentication engine which concerns on 1 aspect of this invention. FIG. 7 is a block diagram illustrating in detail an alternative example of the security system of the present invention. 9A and 9B show an example of a website security meter displayed to a visitor according to an embodiment of the present invention. 6 illustrates an example of a plurality of website security meters displayed to a visitor according to another embodiment of the present invention.

Claims (26)

A device for proving the security status of an online service,
A database for storing profiles of devices and services including the online service and corresponding vulnerability indications;
A certification engine for certifying over a network to visitors of the online service by displaying an indication of the security status of the online service according to a stored profile;
Have
The appearance of the sign varies according to the level of security calculated for the online service. In claim 1,
The apparatus further comprising a scan engine for detecting the device and a service including the online service. In claim 2,
The scan engine compares the recorded feature of vulnerability with the device and the service to obtain the corresponding vulnerability indication. In claim 1,
The apparatus is located at a location remote from the online service of the network. In claim 4,
The apparatus is located at a location remote from the online service of the network. In claim 1,
The displayed device is displayed in response to a click on an image map displayed by the visitor by the online service. In claim 3,
The apparatus further comprising an alert engine that sends an alert to the online service in response to a comparison made by the scan engine. In claim 7,
The alert engine determines whether new vulnerabilities can affect the online service. In claim 8,
The alert engine detects whether a new vulnerability can potentially affect the online service, and the scan engine performs a new search to detect the device and the service including the online service. An apparatus that makes a determination based on the stored profile information and newly received vulnerability information without need. In claim 1,
The certification engine receives a request for registration of a new online service and registers the new online service in response to a determination that an image map exists at a predetermined URL. In claim 1,
The apparatus, wherein the online service is a website. In claim 10,
The online service is a website. In claim 1,
The apparatus is characterized in that the network is the Internet. A device for proving the security status of one or more online services,
A database for storing profiles of devices and services including the online service and corresponding vulnerability indications;
A graphic of the security status of the selected online service that receives a request for certification over the network from an actual or potential visitor of the selected one online service and depends on the stored profile A security website for marking the visitor;
Have
The apparatus, wherein the appearance of the graphic sign varies depending on the level of security calculated for the selected online service. In claim 14,
The apparatus wherein the graphic indication is a security meter. In claim 14,
The apparatus, wherein the security website provides a graphical indication of the security status of a plurality of the online services in response to the stored profile and a request from the visitor. In claim 14,
The apparatus further comprising a scan engine for detecting the service including the device and the online service. In claim 17,
The scan engine compares the recorded feature of vulnerability with the device and the service to obtain the corresponding vulnerability indication. In claim 14,
The apparatus is located at a location remote from each of the online services of the network. In claim 18,
The apparatus is located at a location remote from each of the online services of the network. A method for proving the security status of an online service,
Detect devices and services including the online service,
Compare the detected devices and services with the recorded characteristics of the vulnerability,
Receiving a request for certification from a visitor of the online service over the network;
According to the result of the comparison stage, the security status of the online service is indicated to the visitor,
Changing the appearance of the sign according to the level of security calculated for the online service. In claim 21,
The method of comparing, wherein the step of comparing includes scanning the online service from a remote address on the network. In claim 21,
And allowing the visitor to make the request by clicking on an image map displayed by the online service. In claim 21,
The method further comprises sending an alert to the online service in response to the comparison made by a scan engine. In claim 24,
Sending the alert includes determining whether new vulnerabilities can affect the online service. In claim 21,
Accept requests for registration of new online services,
Determining whether an image map exists at a predetermined URL in the request;
The method further comprises registering the new online service in response to a determination that an image map exists at the predetermined URL.

Images