Reputation Model Version 1.8 Release Notes

Summary:

Based on the provided text and context, here's a breakdown of the information presented in an easy-to-understand format: ### Country List with IDs 1. **Country Name (ID)** - Hungary (specific ID not mentioned) - Iceland (specific ID not mentioned) - ... (additional countries listed here, truncated for brevity) 2. **Type List Descriptions** - 1: Botnet - 2: Malware - 3: Misuse and Abuse - 4: Network Worm - 5: P2P (Peer-to-Peer) - 6: Phishing - 7: Spam - 8: Spyware - 9: Web Application Attackers ### Dictionary Entry in XML Format for "source" Tag - **Worm** (ID="0") is categorized under "Miscellaneous". - The main entry includes a list of sources or categories: - Esoft (ID="1") - SANS (ID="2") - Malware Domain List (ID="3") - ThreatLinQ (ID="4") - Sunbelt (ID="5") - DVLabs (ID="6") - EmergingThreats (ID="7") - MultipleSource (ID="128") ### Summary of the Information: - The text provides a list of country names along with their ID numbers. - It also lists various types or categories, each associated with an ID number and brief description. - A dictionary entry in XML format is described for the "source" tag, where specific IDs are assigned to different sources like worm, malware, etc., categorized under miscellaneous. - The list of sources can be selected multiple values as indicated by "allowmultiplevalues="true". This information appears to be part of a larger database or system that manages data related to countries and cybersecurity threats.

Details:

The document titled "Reputation Security Monitor" is a method for acquiring reputation intelligence data from the TippingPoint security cloud service. It was developed by Wei Lu and Michael Klobe, with Hewlett-Packard Development Company, L.P., as the publisher. The initial version of this document was released on January 19th, 2012 (version 1.0), and since then, it has undergone several updates, each addressing specific improvements or clarifications. The project's primary purpose is to provide a comprehensive method for obtaining reputation intelligence data from the TippingPoint security cloud service. The document version history reveals that there have been multiple iterations with successive revisions aimed at improving clarity and functionality. Version 1.7 included updates related to licensing details, and new fields like "MultipleSource" in source metadata and "Unknown" in geo metadata were added. The distribution list includes various individuals within the company who are responsible for either approving or being informed about this document. The approval process was managed through emails such as ofer.shezaf@hp.com, simran.brar@hp.com, jeff.baltazar@hp.com, klobe@hp.com, and joanna.burkey@hp.com. These individuals were informed or granted the authority to review and provide feedback on the document as it evolved through its various versions. The version history of the document shows that each update was prepared by Wei Lu, with descriptions focusing on improving specific aspects such as clarifying error codes for service data, updating licensing details, adding new fields like "Autopass" fields and trial expiration logic, among other changes. These updates reflect the ongoing effort to refine the method for acquiring reputation intelligence from TippingPoint's security cloud service, ensuring it remains relevant and functional in a dynamic technological environment. The document titled "ReputationSM_V1.8.doc" outlines a comprehensive guide for acquiring, maintaining, and terminating the Reputation Intelligence Service provided by HP Enterprise Security Products' (ESP) ArcSight Extended Security Manager (ESM). Key features include explicit guidelines on full and delta package returns, clarification of processing order, addition of lastContactDate in status reporting, auto-termination of trial licenses after 60 days, and detailed error codes for termination, reactivation, and status queries. The document also introduces a new schema specifically for the status call and relaxes required XML element ordering to accommodate error conditions. The table of contents is structured around sections detailing service activation, renewal, key management, security considerations, service information retrieval, reputation data handling, architectural considerations, termination, reenabling, and status querying. Each section includes specific protocols, response formats in XML, version numbers for data and metadata, and error codes. The document also clarifies the behavior of duplicate activations with auto-termination logic and explicitly notes that authorization for termination, reactivation, and status queries is not covered within this documentation. The text discusses a security correlation engine called ReputationSM, which is an add-on service designed to enhance the assessment of enterprise IT security risk by considering the reputation of network devices and services accessed by users. This service relies on TippingPoint DVLab's research for gathering reputation intelligence, utilizing ArcSight ESM's Connector technology to receive and analyze this data. The ReputationSM allows IT and security managers to assess risks more accurately and take appropriate actions based on the generated reputation views. The document provides a detailed overview of how to acquire the ReputationSM service from TippingPoint's intelligence cloud, detailing the RESTful web service through which ArcSight ESM can obtain this information. It also covers distributed environment use options and offers guidance for implementing the service using Java-based APIs. The Reputation Intelligence Service, acquired through standard HP software license procedures, involves submitting a purchase order for ReputationSM software and downloading it from the HP software e-delivery portal. Acquire a service activation key from the same portal and install the software to input this key. Upon acceptance of the activation key by the software, the service is activated, enabling retrieval of reputation intelligence data (RID) from service servers. The service activation process involves contacting service servers with the user's activation key to initiate the interface defined as follows: The resource (URI) for the activation form is https://SERVER.hp.com/TMC/repSMAuthenticate, accessed via POST method. It requires the ReputationSM host information including OS name, version, hardware architecture, and a unique 32-character Host Client ID provided by the software itself, while users need to fill in only the activation key. The activation form is an XML structure containing detailed host information and the activation key. Upon receiving this form, service servers perform operations such as validating the activation key with AutoPass key validation tool and checking the issue date for trial keys (not exceeding 61 days from the current time). For permanent keys, it's assumed they won't expire. The process involves ensuring the order number in the key is active, extracting customer and order information from the key using a validation tool, validating this information with the service server's user activation database. A unique RS-Key is then created to store relevant data including the activation form, extracted key information, and the RS-Key itself in the user activation database. The response includes an XML structure indicating success or failure along with the RS-Key. Upon receiving a positive confirmation, the ReputationSM software securely stores the host client ID (HCID) and the RS-Key for future use. This document outlines several issues related to activation failures and handling duplicate activations in a system, along with details about service renewal. **Activation Failures:** 1. **Expired Activation Key**: Activation fails because the key has expired. The expiration date is provided (YYYY-MM-DDThh:mm:ssZ). 2. **Terminated Service**: Activation fails because the service has been terminated. The termination date is given (YYYY-MM-DDThh:mm:ssZ). 3. **Invalid Host Info**: Activation fails due to invalid host information. 4. **Malformed XML Request**: The request failed because the XML was not properly parsed by the server, indicating a malformed request. 5. **Unexpected Server Error**: The request failed due to an unexpected error on the server side. **Handling Duplicated Activations:**

• If an activation key is used multiple times for the same HCID (unique identifier), the same RS-Key should be returned each time, unless the activation key is a trial license which expires after 60 days regardless of usage. Clients must securely store the RS-Key and not repeatedly activate to retrieve it.

• For duplicated activations with unique keys referencing the same order number:

• A trial license can be converted to a permanent license but not vice versa. Both conversions will succeed, though a trial key may behave like a permanent one under this scenario.

**Service Renewal:**

• The reputation intelligence service is cloud-based and requires renewal if the previously activated service has expired. No specific procedures for renewal are detailed in the provided text.

In summary, the document covers failure scenarios during activation, strategies to handle duplicate activations, and the process of renewing a service subscription. The article discusses the software maintenance and support process for ReputationSM users, emphasizing the importance of generating and validating keys during the service activation process. 1. Service Activation Process: The process involves creating two types of keys - Service Activation Key and Reputation Service Key. These keys are generated by HP's AutoPass system using software such as HP Software AutoPass for generation and validation purposes. Neither the ReputationSM users nor the software itself need to install or integrate with any related AutoPass software, although it will embed customer information, order information, and service entitlement details. 2. Service Activation Key: a. This key is generated by HP's e-delivery system specifically for AutoPass use. b. The integration of the Service Web Application with AutoPass is crucial for this process. c. It includes data points such as "Entitlement Order Number," "SKU_NUMBER," "SKU_DESCRIPTION," and specific FeatureIDs: <10504>

for trial licenses, <10505>

for permanent licenses, and <10506>

which covers both license types. d. The key also includes the IssueDate (date of AutoPass key generation) and ClusterInfo (combination of Entitlement Order Number and Registered License Owner Email). e. If certain feature IDs are not present in the key, activation will fail with error code 1. f. Additional data such as order number and current date of successful activation is stored within the service server. This information is crucial for future use in reenablement or termination calls. In summary, this process focuses on generating and validating keys to activate services seamlessly without direct involvement from ReputationSM users or software. The key details provided are essential for proper validation and authorization of the reputation service. The activation of HP software involves integrating the AutoPass library with a web application and validating the AutoPass key through this integration. This process ensures that the issue date of the key is less than 61 days old, regardless of whether it's a trial or permanent key. Additionally, the order number in the key must not be currently terminated; if terminated, reenabling the order will allow activation to proceed without needing a second activation for existing installations. Once all validations are passed, the key is considered successful and returns a Reputation Service Key (RS-Key), which serves as an authentication key for the ReputationSM software to retrieve reputation intelligence data. The RS-Key contains specific information such as Host Client ID, a 32 character unique identifier, and service entitlement. It can be encrypted using either the service server's private key or a secret key known only to the service server. The validation of the Reputation Service Key depends on how it was generated: if it was created by encrypting service-related information with the service server's private key, then its validation will use the service server's public key to decrypt and verify the key value. If the service key is based on a cryptographic string, the method of validation may vary accordingly. The article outlines a process for activating a software product to access reputation intelligence services. Here's a summary of the key points: 1. **Service Activation Process**: This involves using a secret key that must be consistent across authentication and authorization processes. The design aims to mitigate security risks such as unauthorized use, hacking attempts, and fraudulent activities by providing mechanisms for user authentication and fraud detection. 2. **Security Considerations**: The process includes accessing the HP software e-delivery system, purchasing the service with an activation key, installing the software with a reputation service key. This setup not only authenticates users but also prevents potential fraud through various security measures. 3. **Receiving Reputation Intelligence Service**: After activating the software, it is ready to retrieve data from reputation service servers via two interfaces:

• **Service Information Request & Response**: The ReputationSM software sends a request for information using specific URIs and methods (POST), including details like the version number of the most recent RID downloaded, the version number of metadata, and reputation host information. This data is transmitted in an XML format that includes OS name, version, hardware architecture, and host client ID.

• **Data Updates**: The service servers update data sets frequently (four times a day or every six hours), each with its own unique version number and associated metadata version.

In summary, the article describes a comprehensive process for activating software to retrieve reputation intelligence services, emphasizing security measures and the methodological approach to requesting and receiving updated information from service servers. The process involves starting with a version number for RID and metadata set to 1.0.0.0 if nothing has been downloaded yet. If an update requires a newer protocol version, such as 1.1.0.0 or 2.0.0.0, legacy versions should still function correctly due to backward compatibility. Sending 0.0.0.0 is treated the same as 1.0.0.0 for historical reasons. To minimize data usage, delta versions of RID are provided, which show changes from a full version. The service servers maintain at least a week's worth of these delta versions to ensure recent updates are available. The request must include the host client ID and reputation service key as part of HTTPS secure cookies for authentication and authorization purposes. These cookies are not automatically set by web browsers but must be explicitly added by ReputationSM software before sending the request to the service server. Before delivering the XML response, the application performs validation functions using the RS-Key from the cookie against a back-end user database. The provided text outlines a process for retrieving service information via an API call, which includes validating the termination date of the service. If the termination date is non-null and refers to a past date, the request fails with a return code of 4. Upon successful validation, the system sends back an XML response containing detailed service information as per the specified schema. The schema for this XML response comprises elements such as "serviceInfo", which encapsulates various attributes like status (integer), message (string), dataVersion (string), metaVersion (string), dataType (enumerated string values: full, delta, none), dataPath (string, optional), dataSize (positive integer, optional), dataBlocks (positive integer, optional), and dataBlockPath (array of objects with blockNumber attribute). Additionally, there are elements for metaPath (string) and metaSize (positive integer). This schema ensures comprehensive description of the service information being returned. Table 2 provides a definition of XML elements used to convey service information, specifically related to responses from a service server. The key elements and their definitions are as follows: 1. **status**: A positive integer indicating the status code of the response, which could be a success or error code. 2. **message**: A string containing the response message, which may include error messages. The content is wrapped in an XML-standard CDATA block to ensure proper handling of any strings that contain special characters not recognized by XML. 3. **dataVersion**: A string representing the version number of the reputation data pointed to by either `dataPath` or `dataBlockPath`. It helps identify which specific set of reputation data is being referenced. 4. **metaVersion**: Similar to `dataVersion`, but pertains to metadata associated with the data, specifically indicated by the `metaPath` element. 5. **dataType**: A string that can take one of three values: "full" (indicating a complete set of reputation data), "delta" (indicating updates needed to bring the client up-to-date from a specific version), or "none". This depends on whether there are any changes between the requested RID version and the latest stored version. 6. **dataPath**: Specifies a web link used by ReputationSM to retrieve the correct set of reputation data, which is compressed using gzip if included in the request headers. The validity of this link is limited to 10 minutes after receiving the response from the service server. These elements are crucial for understanding and processing responses from API calls that involve reputation data, ensuring clear communication between clients and servers about the type and content of data being exchanged. The provided text outlines two main aspects related to data handling and retrieval in a software system called ReputationSM. 1. Data Size Specification: It begins with specifying the total size of the gzip-compressed data set, which is indicated by the variable `dataSize`. This value should be a positive integer representing the size in bytes. If there's no associated data (`dataPath` is empty), then this information will not be present. 2. Data Retrieval and Partitioning: The text details how to retrieve or handle the data based on whether it comes as "full" or "delta".

• For a "full" dataset, `dataBlocks` is specified as a positive integer. This indicates the number of parts (blocks) into which the complete dataset pointed by `dataPath` has been divided. The software can choose to retrieve these blocks sequentially or in parallel depending on its capabilities and settings. Each block must be reassembled according to the order indicated by `blockNumber` before processing, ensuring that all parts together match the original data set referenced by `dataPath`.

• In case of "delta" data, `dataBlocks` indicates the number of incremental datasets needed to complete the entire dataset. The software can download these delta sets in parallel but must process them one after another according to the order defined by `blockNumber`. Delta packages may include commands like "update", "remove", and "add", emphasizing the importance of maintaining a correct order for proper processing.

3. Data Path Specification: `dataBlockPath` is provided as a string, which specifies the web links that ReputationSM needs to use in order to retrieve each segment of the gzip-compressed reputation data. These segments are parts of potentially larger datasets and their retrieval paths are crucial for the smooth operation of the software's data handling processes. Overall, this text provides detailed guidance on how to manage and interact with compressed data within ReputationSM, emphasizing both its size and the specific methods used to retrieve or update it based on whether the data is complete or requires incremental updates. The provided text describes a set of data related to reputation metadata, which includes information about the web link (`metaPath`) and its size in bytes (`metaSize`). This metadata is used for retrieving reputation intelligence data from TMC (TippingPoint Management Center) via a specified URL. The `metaPath` provides the endpoint where the reputation metadata can be retrieved, with a validity of 10 minutes starting from when the response is returned by TMC. If there are no changes since the last retrieval, this field may be empty. The data pointed to by `metaPath` is always compressed (gzip) regardless of any Accept-Encoding headers in the request. The `metaSize` specifies the size of the compressed metadata file, expressed in bytes. This value will only be present if there is a valid `metaPath`. An example XML schema for this data structure is provided at the end of the text. The provided XML snippet and accompanying table describe the response structure and status codes for a service information request, detailing success and failure scenarios based on various conditions encountered during the request process. Here's a breakdown of the content: 1. **XML Structure**:

• The XML is structured with elements under the root `` tag, including `status`, `message`, `dataVersion`, `metaVersion`, `dataType`, `dataBlocks`, and paths to specific data blocks (`dataBlockPath`), along with a meta path and size.

2. **Status Codes**:

• **0 (OK)**: The request was successful.

• **1 (Invalid service key or key not found in db)**: The service key is invalid or not present in the database.

• **2 (Invalid Host Info or HCID/RS-Key mismatch)**: The provided Host Information or HCID/RS-Key combination is incorrect.

• **3 (Invalid version number)**: The requested version number does not exist in the database.

• **4 (Terminated license)**: The service has been terminated due to a license issue.

• **5 (Expiration warning)**: The service will expire soon, but the feature is not implemented yet and thus not applicable.

• **6 (Missing value from XML)**: A required value is missing in the XML request.

• **7 (Failure to parse request XML)**: The XML request is malformed or incorrectly formatted.

• **8 (Unexpected error on server)**: An unexpected error occurred on the server side during the request processing.

• **10 (Parse error in version)**: There's an issue with the version tag in the request.

3. **Table Details**:

• The table provides detailed definitions and corresponding messages for each status code, helping to interpret why a service information request might have failed based on the returned status code and message.

4. **Notes**:

• Codes 9 and 5 are noted as no longer used or not implemented yet, which implies they were likely deprecated or never fully introduced in the system.

This documentation is crucial for understanding how to interpret service responses and troubleshoot issues based on specific error codes and messages provided by the server. The article outlines a system for managing versions of software, particularly in the context of interpretation intelligence (RID) and metadata. It introduces a versioning scheme with major#.minor#.update#.patch# components. Major# increments only when there is a change to the RID schema, which should be infrequent. Similarly, the major# in metadata increments with changes to its schema. Minor# increments for API interpretation changes, also expected to be rare. Both major# and minor# are incremented independently across RID and metadata. Metadata updates less frequently than RID, so its version number is smaller. The update# and patch# versions increase with each new full or delta package release. If the update# remains the same, the difference in patch# numbers between two versions of reputation intelligence data indicates the total number of delta data sets needed to update from a lower to higher patch# version. While recognizing the importance of version numbers for understanding APIs, the article suggests treating them as simple strings for practical usage by callers. The provided algorithm details how a service server responds based on the presented version number: it returns "none" if the versions match, provides deltas if all necessary deltas are available, and resorts to full packages only as a last resort or when specifically requested. If dataVersion from the …/repSMDBInfo request cannot be parsed, this indicates an issue that might affect how version numbers are handled in practical applications. The process outlined involves several steps for handling package updates based on version numbers and error management. Here's a summary of the key points: a. Identify the highest full package (F) and delta package (X) matching the major and minor version of dataVersion. If dataVersion starts with 0.0, use 1.0 as the major version for identification. b. If no match is found, return error 3. c. If the update and patch portions of dataVersion are both 0.0, return the full package (F). d. If there are no matching delta packages but a full package exists, return that full package unless it matches the current version exactly. In such a case, return none. e. Retrieve the highest published delta package (X) if available and compare its update and patch versions with those in dataVersion. Return error 3 if the update or patch version is greater than what exists. f. If no matching deltas are found but the full package matches exactly, return none. Otherwise, return all relevant deltas up to and including X. g. If a specific version (a.b.c.d) is not present on the service server, return the highest available full package (F). h. Compile a list of all delta packages starting from c.d in dataVersion up to and including X, and if this list is empty, return none. Otherwise, return all deltas in the list. On the other hand, if the dataType is "delta," ReputationSM software must request each delta data set one by one until all specified delta data sets are received. To do this, the software uses a specific interface to request RID (Request for Information Disclosure) through HTTPS links. The first link is used for downloading the entire RID package if dataType is "full," which includes either the complete RID or the latest delta compared to the previous complete RID. If dataType is "delta" and dataBlocks is 1, it downloads the full delta of RID. The second link is used to request specific blocks of the RID package; this link appears in the service information response XML only when dataBlocks is greater than 1. For a "full" dataType, each block corresponds to an individual part of the full RID. If dataType is "delta," these links point to cumulative delta RIDs needed to update from the previous version. Each delta RID is specified by its block number. All web links in the service information XML have a 10-minute lifespan, which means that within this time frame, ReputationSM software must complete downloading any related files. This method of block-based request allows for asynchronous retrieval of RID or updates without altering local version numbers until all necessary blocks are fetched. The software is responsible for deciding when and how to use these retrievals and ensuring it gathers all the required blocks before updating the local reputation intelligence data. This is a description of the XML schema for a Reputation Intelligence Data (RID) response, which includes types and structures for different kinds of data entries such as IPv4, IPv6, and FQDN. The RID response uses XML format with specific type definitions like action_value, ipv4_entry_type, ipv6_entry_type, and fqdn_entry_type. These types include attributes like cidr (CIDR notation for IP addresses), score, creationDate, updateDate, type, source, and geo, which are used to describe the properties of each entry. The schema also specifies that some attributes are required (use="required") while others are optional (use="optional"). This XML Schema Definition (XSD) outlines a structure for representing reputation intelligence data in responses, focusing on entries for IPv4, IPv6, and FQDNs. The schema includes complex types named `ipv4_type`, `ipv6_type`, and `fqdn_type` which contain sequences of specific entry elements (`ipv4_entry`, `ipv6_entry`, and `fqdn_entry`). Each type has optional attributes such as "action" and mandatory IDs like "type", "source", and "geo". The schema further defines a root element, `reputationData`, which can include these types of entries optionally. Tables 4 and 5 provide definitions for different types of reputation data entries in an XML format. Here's a summary based on the provided information:

• **ipv4_entry**: This table defines attributes for IPv4 address entries, including type, source, geo (country code), cidr (IPv4 address in CIDR form), score, creationDate, and updateDate. The score is an integer where higher scores indicate better reputation.

• **ipv6_entry**: Similar to ipv4_entry but for IPv6 addresses. It includes type, source, geo (country code), cidr (IPv6 address in CIDR form), score, creationDate, and updateDate. The score is an integer where higher scores indicate worse reputation.

• **fqdn_entry**: This table defines attributes for Fully Qualified Domain Name (FQDN) entries, including type, source, geo (country code), dName (the FQDN itself), isHost (indicating whether the dName is a hostname or not), and score. The score is an integer that reflects the reputation of the domain name.

Each entry includes attributes for specifying the type of data source, geographical location, address format, creation and update dates, and the reputation score based on the context provided in each table. The table provides definitions and explanations for various attributes within the Reputation Entry Block XML format used in reputation intelligence data. These include attributes such as `ipv4`, `ipv6`, `fqdn`, `action`, `creationDate`, and `updateDate`.

• **Ipv4**: Contains an `action` attribute which can be "add", "update", or "remove". This specifies whether the entry should be added, updated, or removed from the local reputation database. It is only used for delta data sets and not complete datasets.

• **Ipv6**: Similar to `ipv4`, it has an `action` attribute for adding, updating, or removing entries but applies specifically to IPv6 data.

• **Fqdn**: Represents Fully Qualified Domain Names (FQDNs). The difference between the XML definitions for complete and delta sets is that a complete set does not include the `action` attribute. For "update" and "remove" actions, specific keys like `` in `ipv4_entry` and `ipv6_entry`, or `` in `fqdn_entry`, are used to identify entries for updating or removing reputation data.

• **CreationDate**: A string indicating the date and time when the data was acquired, formatted as "YYYY-MM-DDThh:mm:ssZ".

• **UpdateDate**: Indicates the latest date and time in UTC when the data was updated, also formatted as "YYYY-MM-DDThh:mm:ssZ".

This table is crucial for understanding how to parse and handle reputation data from XML files, whether they are complete sets or delta updates. This text outlines a process for retrieving reputation intelligence data, specifically focusing on IPv6 entries and FQDN (Fully Qualified Domain Name) entries. The process involves requesting information from a service, which is then divided into two steps: requesting service information and requesting service data. Key architecture considerations include supporting content delivery networks like Akamai. The text also mentions that if the request for reputation intelligence data fails or times out, a standard HTTP response code will be returned to indicate an error condition. The process involves requesting service information first, which allows for the use of CDN paths and supports one-time retrieval paths for enhanced security. Lastly, it discusses terminating the reputation intelligence service by issuing a service termination request to the service provider. The document outlines the functionality and usage restrictions for a service provided by servers, specifically designed for use by service administration personnel and systems. To access this function, strong authentication and authorization mechanisms are required, with details not specified in the documentation but expected to be handled through existing mechanisms provided by the service server. The service has specific termination procedures: 1. Initial release policy states that once activated, the service remains enabled until an explicit termination call is executed for permanent licenses. Trial licenses will be disabled 60 days after activation. 2. Termination cannot be reversed; the system should not allow reactivation if terminated. 3. To terminate a service, use a POST request to the URI "https://SERVER.hp.com/TMC/repSMTerminate" with an XML termination form containing the order number. The server will validate this against its user activation database and disable corresponding reputation service keys. It then sets the termination date to now (or leaves it unchanged if already in the past) before sending back an acknowledgement response. 4.1.1 provides a sample XML format for the TerminationForm, including the Key element holding the order number. The document describes an acknowledgment system for termination requests made to a service server. If a termination request succeeds, the acknowledgement code is zero; otherwise, it is non-zero. The message accompanying the code provides details about why the termination failed (e.g., if the key was invalid or missing values in the XML request). Table 6 lists various codes and their definitions along with corresponding messages:

• Code 0: "Termination succeeded" - Message "OK".

• Code 1: "Termination failed due to invalid key or key not found in db" - Message "Invalid order number".

• Code 4: "Request failed due to missing value from XML" - Message "Missing value in request XML: variableName".

• Code 5: "Request failed due to failure to parse request XML" - Message "Malformed XML request".

• Code 6: "Request failed due to unexpected error on server" - Message "Unexpected server error".

• Code 7: "Request failed due to invalid credentials" - Message "Authorization Failed".

The document then moves on to discuss reenabling the reputation intelligence service after a successful termination. It explains that this should only be done by service administration personnel using strong authentication and authorization, with details about how to request reenabling the service being similar to the initial activation but using the same order number for the terminated service. Once successfully reenabled, existing installations can resume operations without needing further activation. The provided text describes an interface for reenabling services, where the server receives and processes a form containing an "Order number" using a POST method. The XML format of this form is as follows: ```xml Order number ``` Upon receiving the reenabling request, the server performs several operations: 1. It validates the order number against the service server's user activation database to ensure it is a permanent license and not associated with any trial keys. 2. If all keys linked to the order number are permanent, their statuses are updated for immediate activation. 3. The server responds with an XML acknowledgement: ```xml Acknowledgement Code Acknowledgement messages ``` 4. If the reenabling is successful, the Acknowledgement Code will be 0 (OK). Otherwise, it will have a non-zero code indicating an error:

• Code 1 means invalid order number or key not found in the database.

• Code 3 indicates that the order contains a trial license and cannot be renewed.

Error messages are included in the AcknowledgementMsg field of the response XML. The text outlines a process for retrieving service status information from a server, specifically related to a reputation intelligence service provided by HP. The service has two key dates, termination and expiration, which can be retrieved using an activation key via a specific URI with POST method. The request involves sending an XML formatted as follows: ```xml Order number ``` Upon receiving the status request, the server performs several operations including checking all previous activations using the order number and returns details such as whether it's a trial or permanent license, activation date, termination date if applicable, last successful database call execution time, and the issue date of the original Autopass key. The response is acknowledged in XML format with information about the service status. The provided XML schema defines an `serviceStatus` element with a complex type that includes various nested elements such as `status`, `message`, and `orderNumber`. It also contains nested `service` elements, each having detailed information including `issueDate`, `activationDate`, optional `terminationDate` and `lastContactDate`, along with `licenseType` which can be either "PERMANENT" or "TRIAL". Additionally, there are nested `HostInfo` elements containing details about the operating system (`OS`), version (`Version`), architecture (`Arch`), and a unique identifier (`HCID`). This schema is structured to provide comprehensive information regarding service status, including various dates and types related to licensing and hardware. The response message includes several key pieces of information about a service, including the order number, activation date, issue date, termination date, last contact date, license type, and details about the specific instance of RepSM (a software module) used in the service. Here's a breakdown of each piece of information: 1. **Order Number**: This is a unique string identifier for the order associated with the service. 2. **Activation Date**: A date in ISO 8601 format that represents when the first successful call to authenticate the service was made, typically through an endpoint like .../repSMAuthenticate. 3. **Issue Date**: Also in ISO 8601 format, this is the date when the Autopass key most recently used for a successful activation was issued. 4. **Termination Date**: An optional date that indicates when the service will terminate or cease to be active. If not present or empty, it means no termination calls have been successfully executed. The service remains active until this specified date if it's in the future. 5. **Last Contact Date**: Another ISO 8601 date representing the most recent time either an authentication call ( .../repSMAuthenticate) or a database information call ( .../repSMDBInfo) was made for the service. 6. **License Type**: A string indicating whether the license is "TRIAL" (a limited-time trial version) or "PERMANENT" (an indefinitely valid license). 7. **Host Info**: Contains detailed XML data about the specific instance of RepSM that has been activated, including information about the operating system (OS), its version, hardware architecture, and a host client ID (HCID). The provided sample XML snippet shows an example of how this structured information might be presented in a response message. Each service listed under `` includes all these details encapsulated within their respective tags. This document outlines the structure and status codes of a service information request system. It includes details about the license type, host information, and defines various error status codes with their corresponding messages. The service information response can either succeed or fail based on different conditions such as missing values in XML, malformed XML requests, unexpected server errors, or invalid credentials. The possible status codes are defined clearly in a table which includes the code itself, its definition, and the message that accompanies it. For instance:

• Code 0 indicates "OK" for successful request completion.

• Codes 6, 7, and 8 correspond to specific error conditions like missing values or unexpected server errors with respective messages.

• Code 10 signifies an authorization failure due to invalid credentials.

Additionally, there's a section dedicated to reputation metadata which includes mappings of IDs across types, sources, and geos along with their definitions as per the Reputation Entry Block XML Definitions table. The data is categorized into LIST tags based on type (geo, type, source) where feedid, name, localid, and allowmultiplevalues attributes provide further classification details. In summary, this document provides a standardized way to handle service information requests with clear guidelines for interpreting the success or failure of these requests along with detailed metadata about reputation entries. This XML document is a dictionary containing information about various geolocations, which are regions or countries. The list includes detailed names for many countries such as Afghanistan, Aland Islands, Albania, Algeria, and so on. Additionally, it contains an entry labeled "Anonymous Proxy" under the id value 1, indicating that this specific IP address belongs to a category of being potentially part of a botnet or malware distribution. The document also includes entries for locations like Asia/Pacific Region, Australia, Austria, Azerbaijan, and more. This passage lists the names of various countries, including:

• Keeling Islands

• Colombia

• Comoros

• Congo

• The Democratic Republic of Congo

• Cook Islands

• Costa Rica

• Côte d'Ivoire (Ivory Coast)

• Croatia

• Cuba

• Cyprus

• Czech Republic

• Denmark

• Djibouti

• Dominica

• Dominican Republic

• Ecuador

• Egypt

• El Salvador

• Equatorial Guinea

• Eritrea

• Estonia

• Ethiopia

• Europe

• Falkland Islands (Malvinas)

• Faroe Islands

• Fiji

• Finland

• France

• French Guiana

• French Polynesia

• French Southern Territories

• Gabon

• Gambia

• Georgia

• Germany

• Ghana

• Gibraltar

• Greece

• Greenland

• Grenada

• Guadeloupe

• Guam

• Guatemala

• Guernsey

• Guinea

• Guinea-Bissau

• Guyana

• Haiti

• Heard Island and McDonald Islands

• Holy See (Vatican City State)

• Honduras

• Hong Kong

• Hungary

• Iceland

This is a list of country names, each associated with a unique ID number. The countries listed include India, Indonesia, Iran, Iraq, Ireland, the Isle of Man, Israel, Italy, Jamaica, Japan, Jersey, Jordan, Kazakhstan, Kenya, Kiribati, North Korea, South Korea, Kuwait, Kyrgyzstan, Laos, Latvia, Lebanon, Lesotho, Liberia, Libya, Liechtenstein, Lithuania, Luxembourg, Macao, Macedonia (FYROM), Madagascar, Malawi, Malaysia, Maldives, Mali, Malta, Marshall Islands, Martinique, Mauritania, Mauritius, Mayotte, Mexico, Micronesia, Moldova, Monaco, Mongolia, Montenegro, Montserrat, Morocco, Mozambique, Myanmar, Namibia, Nauru, Nepal. This list includes countries from various regions around the world. Some of these countries are Netherlands, Netherlands Antilles, New Caledonia, New Zealand, Nicaragua, Niger, Nigeria, Niue, Norfolk Island, Northern Mariana Islands, Norway, Oman, Pakistan, Palau, Palestinian Territory, Panama, Papua New Guinea, Paraguay, Peru, Philippines, Pitcairn, Poland, Portugal, Puerto Rico, Qatar, Reunion, Romania, Russian Federation, Rwanda, Saint Barthelemy, Saint Helena, Saint Kitts and Nevis, Saint Lucia, Saint Martin, Saint Pierre and Miquelon, Saint Vincent and the Grenadines, Samoa, San Marino, Sao Tome and Principe, Saudi Arabia, Senegal, Serbia, Seychelles, Sierra Leone, Singapore, Slovakia, Slovenia, Solomon Islands, Somalia, South Africa, and South Georgia and the South Sandwich Islands. This text appears to be a list of country names and identifiers, as well as types or categories. The first part lists countries with their respective IDs, while the second part provides different types or classifications identified by numbers and their descriptions. Here's a summary of each section: 1. **Country List**:

• This is a series of entries where each entry includes a country name followed by an ID number. The list covers various countries around the world, including Spain, Sri Lanka, Sudan, Suriname, Svalbard and Jan Mayen, Swaziland, Sweden, Switzerland, Syrian Arab Republic, Taiwan, Tajikistan, Tanzania, United Republic of, Thailand, Timor-Leste, Togo, Tokelau, Tonga, Trinidad and Tobago, Tunisia, Turkey, Turkmenistan, Turks and Caicos Islands, Tuvalu, Uganda, Ukraine, United Arab Emirates, United Kingdom, United States, United States Minor Outlying Islands, Uruguay, Uzbekistan, Vanuatu, Venezuela, Vietnam, Virgin Islands, British, Virgin Islands, U.S., Wallis and Futuna, Western Sahara, Yemen, Zambia, and Zimbabwe.

2. **Type List**:

• This section lists different types or categories identified by numbers from 1 to 9, each with a brief description:

• Botnet

• Malware

• Misuse and Abuse

• Network Worm

• P2P (Peer-to-Peer)

• Phishing

• Spam

• Spyware

• Web Application Attackers

These lists might be part of a larger data structure or database, possibly used for categorization, identification, or mapping purposes across various applications or systems. The text provided contains a dictionary entry in XML format. This entry is for the tag "source" which allows multiple values to be selected. Here's what it says:

• **Worm**: According to this context, the term "worm" appears as a value ID with no specific name attached to it (id="0"). It falls under the category of "Miscellaneous".

• The main part of the entry is under the tag "LIST", which allows multiple values. This list includes:

• **Esoft** (value id="1")

• **SANS** (value id="2")

• **Malware Domain List** (value id="3")

• **ThreatLinQ** (value id="4")

• **Sunbelt** (value id="5")

• **DVLabs** (value id="6")

• **EmergingThreats** (value id="7")

• **MultipleSource** (value id="128")

This dictionary entry seems to be defining the possible sources or categories for some data, possibly related to malware or cybersecurity. The "source" list can accommodate multiple selections as indicated by "allowmultiplevalues="true".

Disclaimer:

The content in this post is for informational and educational purposes only. It may reference technologies, configurations, or products that are outdated or no longer supported. If there are any comments or feedback, kindly leave a message and will be responded.