|
|
Name of Your Organization:
Information Risk Management Plc
Web Site:
http://www.irmplc.com
Compatible Capability:
Security Risk Assessment
Capability home page:
http://www.irmplc.com/systems-testing.htm
1) Product Accessibility <CR_2.4>
Provide a short description of how and where your capability is made available to your customers and the public (required):
Technical reports contain information retrieved from the IRM CVE database. Information associated with each vulnerability is displayed, including (among other things) vulnerability description, link to CVE entry, links to vendor information and remediation information.
4) Map Currency Indication <CR_5.1>
Describe how and where your capability indicates the most recent CVE version used to create or update its mappings (required):
Every new IRM report that is generated will, as part of the QA procedures, include a review of the CVE information generated by our database. Where any CVE information has been superceeded an action will be raised to modify the data stored on the database. At least 5 reports are generated each week (an example report can be supplied on request)
5) Map Currency Update Approach <CR_5.2>
Indicate how often you plan on updating the mappings to reflect new CVE versions and describe your approach to keeping reasonably current with CVE versions when mapping them to your repository (recommended):
As explained in CR_5.1 the CVE mappings are reviewed on a weekly basis and can easily be updated with a web-based front-end to our database
6) Map Currency Update Time <CR_5.3>
Describe how and where you explain to your customers the timeframe they should expect an update of your capability's mappings to reflect a newly released CVE version (recommended):
All reports supplied to IRM clients will have up-to-date CVE information, as it is reviewed as part of the QA procedures prior to the report being delivered
7) CVE and Compatibility Documentation<CR_4.1>
Provide a copy, or directions to its location, of where your documentation describes CVE and CVE compatibility for your customers (required):
This is provided in reports in the form of CVE references and a general description of CVE (a current draft of the CVE documentation is shown below).
and
Once the service has been certified as CVE Compatible a section of the IRM website will be dedicated to providing information about CVE and how it relates to our services.
8) Documentation of Finding Elements Using CVE Names <CR_4.2>
Provide a copy, or directions to its location, of where your documentation describes the specific details of how your customers can use CVE names to find the individual security elements within your capability's repository (required):
This is provided in reports in the form of CVE references and a general description of CVE (a current draft of the CVE documentation is shown below).
Once the service has been certified as CVE Compatible a section of the IRM website will be dedicated to providing information about CVE and how it relates to our services.
9) Documentation of Finding CVE Names Using Elements <CR_4.3>
Provide a copy, or directions to its location, of where your documentation describes the process a user would follow to find the CVE names associated with individual security elements within your capability's repository (required):
Every vulnerability identified during the test is displayed on a separate page of the report, which includes details of the vulnerability in addition to the CVE reference and other vendor links to patches and further information (see screenshot below).
10) Documentation Indexing of CVE-Related Material <CR_4.4>
If your documentation includes an index, provide a copy of the items and resources that you have listed under "CVE" in your index. Alternately, provide directions to where these "CVE" items are posted on your web site (recommended):
All reports contain a contents page, which includes embedded links within the document to each vulnerability and to the section that provides and explanation of CVE (similar to those shown in answer to questions 7 & 8 above).
11) Candidates Versus Entries Indication <CR_6.1>
If CVE candidates are supported or used, explain how you indicate that candidates are not accepted CVE entries (required):
This explanation appears along with the CVE description documentation in each report (see example below).
12) Candidates Versus Entries Explanation <CR_6.2>
If CVE candidates are supported or used, explain where and how the difference between candidates and entries is explained to your customers (recommended):
This explanation appears along with the CVE description documentation in each report (see response to question 11 above).
13) Candidate to Entry Promotion <CR_6.3>
If CVE candidates are supported or used, explain your policy for changing candidates into entries within your capability and describe where and how this is communicated to your customers (recommended):
Whenever CVE decides to change the status of a CAN to CVE the status changes in the report reference
14) Candidate and Entry Search Support <CR_6.4>
If CVE candidates are supported or used, explain where and how a customer can find the explanation of your search function's ability to look for candidates and entries by using just the YYYY-NNNN portion of the CVE names (recommended):
CVE candidates can be searched for using the YYYY-NNNN format with the web-based search form
15) Search Support for Promoted Candidates <CR_6.5>
If CVE candidates are supported or used, explain where and how a customer can find the explanation of your search function's support for retrieving the CVE entry for a candidate that is no longer a candidate (recommended):
This explanation appears along with the CVE description documentation in each report.
16) Candidate Mapping Currency Indication <CR_6.6>
If CVE candidates are supported or used, explain where and how you tell your users how up-to-date your candidate information is (recommended):
Candidates and CVE version are part of the documentation explaining CVE within the report.
Type-Specific Capability Questions
Service Questions
23) Service Coverage Determination Using CVE Names <CR_A.3.1>
Give detailed examples and explanations of the different ways that a user can use CVE names to find out which security elements are tested or detected by the service (i.e. by asking, by providing a list, by examining a coverage map, or by some other mechanism) (required):
The report details the tests that were performed and wherever vulnerabilities are discovered CVE numbers are referenced for each.
24) Finding CVE Names in Service Reports Using Elements <CR_A.3.2>
Give detailed examples and explanations of how, for reports that identify individual security elements, the user can determine the associated CVE names for the individual security elements in the report (required):
The report that is sent to the customer includes explicit references to the relevant CVE names.
31) Electronic Document Format Info <CR_B.3.1>
Provide details about the different electronic document formats that you provide and describe how they can be searched for specific CVE-related text (required):
IRM support PDF output for client reports, which is searchable and thus the user can simply search for a specific CVE or CAN in the report.
32) Electronic Document Listing of CVE Names <CR_B.3.2>
If one of the capability's standard electronic documents only lists security elements by their short names or titles provide example documents that demonstrate how the associated CVE names are listed for each individual security element (required):
All reports contain security descriptions and CVE numbers.
33) Electronic Document Element to CVE Name Mapping <CR_B.3.3>
Provide example documents that demonstrate the mapping from the capability's individual elements to the respective CVE name(s) (recommended):
Vulnerabilities are described on separate pages of the report. Each page provides the vulnerability name, a description and the applicable CVE number (if one exists for the vulnerability).
34) Finding Elements Using CVE Names Through the GUI <CR_B.4.1>
Give detailed examples and explanations of how the GUI provides a "find" or "search" function for the user to identify your capability's elements by looking for their associated CVE name(s) (required):
The GUI is web based and users can enter free form text to search for any element within a database record such as vulnerability description, CVE number or candidate number.
35) GUI Element to CVE Name Mapping <CR_B.4.2>
Briefly describe how the associated CVE names are listed for the individual security elements or discuss how the user can use the mapping between CVE entries and the capability's elements, also describe the format of the mapping (required):
The vulnerability name appears together with the CVE number, and thus the mapping between the name and CVE number are clear and evident.
36) GUI Export Electronic Document Format Info <CR_B.4.3>
Provide details about the different electronic document formats that you provide for exporting or accessing CVE-related data and describe how they can be searched for specific CVE-related text (recommended):
The output format is HTML and it details all information pertinent to each vulnerability including description, CVE number, remediation procedures.
37) Statement of Compatibility <CR_2.7>
Have an authorized individual sign and date the following Compatibility Statement (required):
"As an authorized representative of my organization I agree that we will abide by all of the mandatory CVE Compatibility Requirements as well as all of the additional mandatory CVE Compatibility Requirements that are appropriate for our specific type of capability."
Name: Andy Davis
Title: Research and Development Manager
38) Statement of Accuracy <CR_3.4>
Have an authorized individual sign and date the following accuracy Statement (recommended):
"As an authorized representative of my organization and to the best of my knowledge, there are no errors in the mapping between our capability's Repository and the CVE entries our capability identifies."
Name: Andy Davis
Title: Research and Development Manager