LogRhythm supports only the Pro versions of Nexpose, up to and including Nexpose 6. Nexpose community versions are not supported. The following prerequisites apply to the Nexpose server and the connection between Nexpose and LogRhythm System Monitor being used for collection. The System Monitor collecting Nexpose data references a local configuration file and uses state tracking to maintain the last log read from the scanner.
To ensure the collection performs as expected, perform the following before you start to configure collection:.
Configure LogRhythm's Nexpose interface by modifying nexpose. The file contains the following settings:. The password to send for connecting to the Nexpose API. A command line window will appear during the installation, but you will not need to interact with it.
DO NOT close this window. You should now have the Security Console with a local Scan Engine installed. Sites What is a site? Scan Engines Scan Engines. Scan Templates Selecting a scan template.
Scan Credentials Configuring scan credentials. Alerts and Schedules Setting up scan alerts. Dynamic Discovery Managing dynamic discovery of assets. Creating a logon for Web site form authentication. Tune Tune. Writing vulnerability checks. Set maximum scan duration per device. Users and Authentication Managing users and authentication.
Manage Managing the Security Console. Resources Resources. The GET operation invoked on a collection resource indicates a request to retrieve all, or some, of the entities contained within the collection. This also includes the optional capability to filter or search resources during the request.
The response from a collection listing is a paginated document. See hypermedia links for more information. The POST is a non-idempotent operation that allows for the creation of a new resource when the resource identifier is not provided by the system during the creation operation i.
The content of the POST request is sent in the request body. The POST to a collection resource can also be used to interact with asynchronous resources. The PUT is an idempotent operation that either performs a create with user-supplied identity, or a full replace or update of a resource by a known identifier. The response to a PUT operation to create an entity is a Created with a valid Location header field set to the URI that can be used to access to the newly created resource.
PUT on a collection resource replaces all values in the collection. The typical response to a PUT operation that updates an entity is hypermedia links, which may link to related resources caused by the side-effects of the changes performed. The DELETE is an idempotent operation that physically deletes a resource, or removes an association between resources.
The typical response to a DELETE operation is hypermedia links, which may link to related resources caused by the side-effects of the changes performed. Retrieves the details of a specific resource by its identifier.
The details retrieved can be controlled through property selection and property views. The content of the resource is returned within the body of the response in the acceptable media type. Allows for and idempotent "full update" complete replacement on a specific resource.
If the resource does not exist, it will be created; if it does exist, it is completely overwritten. The content of the PUT request is sent in the request body. The identifier of the resource is specified within the URL not the request body. Performs a non-idempotent creation of a new resource. The POST of an instance resource most commonly occurs with the use of nested resources e.
This varies by endpoint. PATCH is a non-idempotent operation that enforces an atomic mutation of a resource. Only the properties specified in the request are to be overwritten on the resource it is applied to. If a property is missing, it is assumed to not have changed. Permanently removes the individual resource from the system. If the resource is an association between resources, only the association is removed, not the resources themselves. The following formats are supported as input:.
Pagination is supported on certain collection resources using a combination of two query parameters, page and size. As these are control parameters, they are prefixed with the underscore character. The page parameter dictates the zero-based index of the page to retrieve, and the size indicates the size of the page. Sorting is supported on paginated resources with the sort query parameter s. The sort query parameter s supports identifying a single or multi-property sort with a single or multi-direction output.
The format of the parameter is:. With single-order sorting, all properties are sorted in the same direction. To sort the results with varying orders by property, multiple sort parameters are passed.
The response statuses , and need special consideration for security purposes. As necessary, error statuses and messages may be obscured to strengthen security and prevent information exposure. The following is a guideline for privileged resource response statuses:. Dates or times are returned as strings in the ISO 'extended' format.
When a date and time is returned instant the value is converted to UTC. In some resources a Content data type is used. This allows for multiple formats of representation to be returned within resource, specifically "html" and "text".
The "text" property returns a flattened representation suitable for output in textual displays. The resources property is an array of the resources being retrieved from the endpoint, each which should contain at minimum a "self" relation hypermedia link.
The page property outlines the details of the current page and total possible pages. The object for the page includes the following properties:. The last property of the paged response is the links array, which contains all available hypermedia links.
For paginated responses, the "self", "next", "previous", "first", and "last" links are returned. The "self" link must always be returned and should contain a link to allow the client to replicate the original request against the collection resource in an identical manner to that in which it was invoked.
The "next" and "previous" links are present if either or both there exists a previous or next page, respectively. The "next" and "previous" links have hrefs that allow "natural movement" to the next page, that is all parameters required to move the next page are provided in the link.
The "first" and "last" links provide references to the first and last pages respectively. Paginated requests do not provide a "stateful cursor" to the client, nor does it need to provide a read consistent view. The "depth" of the response of a resource can be configured using a "view".
All endpoints supports two views that can tune the extent of the information returned in the resource. The supported views are summary and details the default. View are specified using a query parameter, in this format:. Any error responses can provide a response body with a message to the client indicating more information if applicable to aid debugging of the error.
All 40x and 50x responses will return an error response in the body. The format of the response is as follows:. The status property is the same as the HTTP status returned in the response, to ease client parsing. The message property is a localized message in the request client's locale if applicable that articulates the nature of the error.
The last property is the links property. This may contain additional hypermedia links to troubleshoot. Multiple resources make use of search criteria to match assets. Search criteria is an array of search filters. Each search filter has a generic format of:.
Every filter defines two required properties field and operator. The field is the name of an asset property that is being filtered on. The operator is a type and property-specific operating performed on the filtered property.
0コメント