Update [EDR rule] definition
Relative path: /v2/edr-rules/{ruleUuid}:updateDefinition
If the rule_definition is invalid, an error 400 BAD REQUEST is returned.
Request body
Display Schema instead of an Example or vice-versa
Type |
Required |
Example |
Schema |
---|---|---|---|
application/json |
No |
{ "xmlDefinition": "string" } |
{
"$ref": "EdrRulesUpdateEdrRuleDefinitionBody",
"xmlDefinition": {
"type": "string",
"description": "Definition of the rule in XML language. Specification of the format is at https://help.eset.com/ei_rules/latest/en-US/. XML definition must be valid according to this specification for [EDR rule] to be valid."
}
} |
Parameters in path
Name |
Type |
Required |
Description |
---|---|---|---|
ruleUuid |
string |
Yes |
Reference to the [EDR rule] whose definition is about to be updated. type: EdrRule |
Responses
Display Schema instead of an Example or vice-versa
Code |
Description |
Example |
Schema |
---|---|---|---|
200 |
A successful response. |
{ "rule": { "displayName": "string", "enabled": true, "scopes": [ { "deviceUuid": "string", "deviceGroupUuid": "string" } ], "severityLevel": "SEVERITY_LEVEL_UNSPECIFIED", "severityScore": 0, "xmlDefinition": "string", "uuid": "string", "authorUuid": "string", "editorUuid": "string" } } |
{ "$ref": "v2UpdateEdrRuleDefinitionResponse", "rule": { "$ref": "v2EdrRule", "description": "[EDR rule] where actions are executed based on the criteria. [EDR rule] defines one or more actions executed as a result of suspicious activity.", "displayName": { "type": "string", "description": "User friendly name of the [rule]. The value is derived from the description/name value in xml_definition.", "readOnly": true }, "enabled": { "type": "boolean", "description": "If enabled, the rule is used for matching." }, "scopes": [ { "$ref": "v2EdrRuleScope", "description": "Scope for which the rule (exclusion) is applicable.", "deviceUuid": { "type": "string", "description": "Reference to the device for which the rule is applicable. type: device_management.v1.Device" }, "deviceGroupUuid": { "type": "string", "description": "Reference to the device_group for which the rule is applicable. type: device_management.v1.DeviceGroup" } } ], "severityLevel": { "$ref": "dotnodwell_known_typesv1SeverityLevel", "type": "string", "description": "Severity levels abstracted to cover all the possible GUIs. Vocabulary is leaving interpretation of severity level completely to API client. This approach is inevitable on SIEM level as there are many contributing sources. Keeping the local names for severity levels never fits all the GUIs. SEVERITY_LEVEL_UNSPECIFIED: fallback SEVERITY_LEVEL_DIAGNOSTIC: In some GUIs known Debug SEVERITY_LEVEL_INFORMATIONAL: In some GUIs known as Info or Information SEVERITY_LEVEL_LOW: In some GUIs known Warning SEVERITY_LEVEL_MEDIUM: In some GUIs known as Error or Threat SEVERITY_LEVEL_HIGH: In some GUIs known as Critical", "default": "SEVERITY_LEVEL_UNSPECIFIED", "enum": [ "SEVERITY_LEVEL_UNSPECIFIED", "SEVERITY_LEVEL_DIAGNOSTIC", "SEVERITY_LEVEL_INFORMATIONAL", "SEVERITY_LEVEL_LOW", "SEVERITY_LEVEL_MEDIUM", "SEVERITY_LEVEL_HIGH" ] }, "severityScore": { "type": "integer", "description": "Integer representation of severity level to be comparable in queries. For example 'severity_score > 10'. The value is derived from the severity_score value in xml_definition. Severity score is a number from 1 to 100 mapped to severity level as follows: 1 - 49 = LOW 50 - 59 = MEDIUM (a.k.a. Warning) 60 - 100 = HIGH (a.k.a Threat)", "format": "int64", "readOnly": true }, "xmlDefinition": { "type": "string", "description": "Definition of the rule in XML language. Specification of the format is at https://help.eset.com/ei_rules/latest/en-US/. XML definition must be valid according to this specification for [EDR rule] to be valid." }, "uuid": { "type": "string", "description": "Unique identifier of the entity. Must be collision free - two identifiers created anywhere in the world must not collide within entity parent scope. Unless a member of aggregate, the entity scope is always global. Although most of the times compliant with RFC 4122: A Universally Unique IDentifier (UUID) URN Namespace, do not rely on it being a RFC UUID. Treat it as an opaque identifier. RFC UUID can be recognized by being formatted according to template xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx, as explained on wikipedia. UUID is used for referencing an entity, even across domains. Example: '123e4567-e89b-12d3-a456-426614174000'", "readOnly": true }, "authorUuid": { "type": "string", "description": "Principal responsible for the first revision of the entity. It might be identification of user.", "readOnly": true }, "editorUuid": { "type": "string", "description": "Principal responsible for the revision of the entity. It might be identification of user. Every revision might heave different editor. For non-revisioned entities editor denotes author of the last revision. For just-created entities author and editor are the same.", "readOnly": true } } } |
default |
An unexpected error response. |
{ "code": 0, "message": "string", "details": [ { "@type": "string" } ] } |
{ "$ref": "rpcStatus", "code": { "type": "integer", "format": "int32" }, "message": { "type": "string" }, "details": [ { "$ref": "protobufAny", "@type": { "type": "string" } } ] } |
202 |
Response took too long and the request was cached. |
null |
[] |