Alert Logic ActiveIntegration APIs

Transcription

1 Alert Logic ActiveIntegration APIs

2 CONTENTS API Integration Reference 6 About Alert Logic ActiveIntegration 6 Working with the API 8 Security 12 Incident API 15 About the Incident API 15 Use cases 15 How to implement 16 Get Incident 17 Get Incident Notes 24 Order API 26 About the Order API 26 Use case: Self-service ordering 26 How to implement 26 Create Order 27 Get Order Status 32 Customer API 35 About the Customer API 35 Use case: Customer account provisioning 35 How to implement 35 Create Customer 36 Get Customer Creation Status 39 Get Customer 40 User API 42 About the User API 42 Use cases 42 How to implement 42 Create User 43 Get Users by Customer 44 Get User 46 Delete User 47 Page 2 of 328

3 Monitoring API 49 About the Monitoring API 49 Use cases 50 How to implement 50 Get Agents by Customer 50 Get Agents by IP Address 53 Get Log Sources 55 Get Log Sources by Customer 58 Get Appliances 60 Get Appliances by Customer 63 Get Hosts 66 Get Hosts by Customer 68 Report API 71 About the Report API 71 Use cases 71 How to implement 71 Get Reports by Customer 72 Get Report Executions 74 Get Report Results 76 Scan API 78 About the Scan API 78 Use cases 78 How to implement 79 Get Scans by Customer 79 Get Scan Executions 81 Get Scan Results 82 Log Manager API 89 About the Log Manager API 90 Use cases 91 How to implement 92 Common Parameters 93 Get Credentials by Criteria 94 Page 3 of 328

4 Get Credentials 98 Delete Credentials 100 Create Host Credentials 102 Update Host Credentials 104 Create AWS Credentials 107 Update AWS Credentials 110 Create IAM Role Credentials 112 Update IAM Role Credentials 115 Get Policies by Criteria 118 Get Policy 125 Delete Policy 130 Create Syslog Policy 132 Update Syslog Policy 135 Create Flat File Policy 137 Update Flat File Policy 143 Create Windows Eventlog Policy 148 Update Windows Eventlog Policy 153 Create S3 Policy 157 Update S3 Policy 162 Get Sources by Criteria 167 Get Source 180 Delete Source 188 Create Flat File Source 190 Update Flat File Source 194 Create AWS Cloudtrail Source 199 Update AWS Cloudtrail Source 203 Create Windows Eventlog Source 206 Update Windows Eventlog Source 211 Update Linux Syslog Source 215 Create AWS S3 Source 219 Update AWS S3 Source 223 Get Appliances by Criteria 227 Page 4 of 328

5 Get Appliance 233 Update Linux-based Appliance 238 Update Windows-based Appliance 242 Threat Manager API 245 About the Threat Manager API 245 Use cases 247 How to implement 247 Common Parameters 248 Get Appliances by Criteria 249 Get Appliance 257 Update Appliance 263 Replace Appliance 267 Get Policies by Criteria 270 Get Policy 276 Create Policy 281 Update Policy 286 Replace Policy 292 Delete Policy 298 Get Protected Hosts by Criteria 299 Get Protected Host 306 Update Protected Host 312 Replace Protected Host 316 Get Keypairs 320 Create Keypair 323 Delete Keypair 327 Page 5 of 328

6 API Integration Reference This section provides information about the Alert Logic ActiveIntegration APIs that is common to all APIs in the set. This section includes the following topics: About Alert Logic ActiveIntegration Provides high level information about the API design and Alert Logic concepts Working with the API Provides information about how to use the API Security Provides information about the authentication and authorization methods that are supported by the API About Alert Logic ActiveIntegration Alert Logic ActiveIntegration is a set of APIs designed to allow simple integration of common Alert Logic functions into your applications and workflows. For example, using the APIs, you can: Automatically deploy security into new cloud instances Integrate with your enterprise helpdesk ticketing system Streamline the ordering and deployment process Include security data in your enterprise portal Identify Alert Logic resources in your deployment You can use Alert Logic ActiveIntegration to perform these functions and more, including some features that are not available in the Alert Logic user interface (UI). Alert Logic ActiveIntegration is a powerful tool. Use the APIs only if you fully understand the potential effects of the commands. This section includes the following topics: Architectural design Alert Logic Customer Hierarchy Architectural design The ActiveIntegration APIs are based on the REST architectural style, using standard HTTP methods and status codes. The APIs are resource-based. Each resource is associated with a URL that identifies a set of objects. An API endpoint is composed of the HTTP method and the URL associated with the resource. The API endpoints produce JSON schema formatted responses. Alert Logic Customer Hierarchy Alert Logic uses a distinct hierarchy to represent and enforce the organizational structure of customers and users in the system. This structure determines a user s authorization for visibility and access to other accounts. The Alert Logic customer hierarchy consists of individual accounts, or nodes, in a hierarchical tree. A node can represent either a customer account or a user account. Under a customer account, user accounts and child customer accounts can exist and can be nested multiple levels. Page 6 of 328

7 The following figure illustrates this structure: As shown in the diagram, the root node for the customer hierarchy is the Alert Logic customer account. Directly beneath the root are the Alert Logic users and customers. When a company becomes an Alert Logic customer, the company receives a customer account. For each customer account, user accounts are defined. User accounts are used to access customer account information and security analysis data, such as appliances, sensors, and incidents. Customers can create child customers of their own, which exist logically under the respective parent customer account. Customers can use these child customer accounts when reselling services to other companies or for internal divisions or departments; this arrangement allows for the specific needs of the customer, such as detailed usage and billing. With the appropriate permissions, a user can access data for his parent customer account and any child customers defined to his parent; a user of a child account does not have access to data for any level above its parent account in the hierarchy. Essentially, a user's access is controlled by two factors: customer relationship and granted permissions. The customer relationship determines what customer accounts a user can access (the user's parent and defined children), and then the permissions determine what data the user is allowed to access. Page 7 of 328

8 Use of permissions does not apply to customer accounts. Customer accounts are used to define relationships only. When you use the API, the API verifies your authentication according to your place in the customer hierarchy (your customer relationships) with each request. The API also enforces your permissions, granting you access to the data for any customer accounts that are children of your parent, as allowed. For more information about permissions, see Authorization. Working with the API This section includes the following topics: Where to access Versioning Requests Responses Using Unix timestamps Where to access Access the Alert Logic ActiveIntegration APIs by using the following base URLs: Base URL Description Use this URL when accessing the US datacenter. Use this URL when accessing the UK datacenter. The Log Manager API and Threat Manager API do not use these base URLs. For more information, see About the Log Manager API and About the Threat Manager API. For interactive use of many of the available APIs, see Versioning The version of an API is indicated in the URL of the request. For example, the following request calls the Incident API v3: /api/incident/v3/incidents When a newer version of an API is available, we recommend that you transition to the latest version as soon as possible. Page 8 of 328

9 Requests Requests include the following elements: HTTP methods Authentication Request header Request parameters HTTP methods The HTTP methods determine the action to take on the resource. Alert Logic ActiveIntegration APIs support the standard GET, POST, PUT and DELETE methods. Authentication To use the Alert Logic ActiveIntegration APIs, you must utilize one of the following security methods with each request: User API key SSL Certificate For details, see Security. Request header The Alert Logic ActiveIntegration APIs use the following request header fields: Accept Most ActiveIntegration APIs produce JSON-formatted responses. For each request, specify the MIME type application/json using the Accept header field. If an API produces responses in formats other than JSON, the supported formats are documented in the API-specific documentation. The following example shows how to include the Accept header field in a curl request: curl curl -kv -H "Accept: application/json" --cert alertlogic-api-certfile.pem " Content-Type POST and PUT requests through the ActiveIntegration APIs use JSON-formatted input. For each POST or PUT request, specify the MIME type application/json using the Content-Type header field. The following example shows how to include the Content-Type header field in a curl request for a POST command: Page 9 of 328

10 curl curl -kv -H "Content-Type: application/json" -H "Accept: application/json" --cert alertlogic-api-certfile.pem -X POST " For information specifying impersonation in the header, see Security. Request parameters The input parameters vary by API. Depending on the API, supported request parameters include URL parameters, POST parameters, and query parameters. For information about supported parameters for each API, see the API-specific documentation. Responses When an API returns a response, the following elements are included: HTTP status codes Response parameters Page 10 of 328

11 HTTP status codes The following table includes the most common HTTP status codes returned by the Alert Logic ActiveIntegration APIs: Status code Response Description 200 OK The request has succeeded. 201 Created The requested resource was successfully created. 202 Accepted The request has been accepted for processing, but the processing has not been completed. 204 No Content The request has succeeded but does not need to return an entity-body. 400 Bad Request The request could not be understood by the server due to a syntax error. You must modify the request before attempting to submit it again. Possible errors include an invalid URL or missing parameters in the call. 401 Unauthorized The request requires user authentication. 403 Forbidden 404 Not Found The server understood the request but refuses to fulfill it. Retry the call with the correct authentication. The request did not process successfully due to a permanent error in the URL. This code often generates when the server cannot find the identifier. To attempt the request again, fix the indicated error. 405 Method Not Allowed The specified method is not allowed for the resource in the request. 406 Not Acceptable 409 Conflict 500 Internal Server Error The resource identified in the request can only generate response data with content characteristics that are unacceptable according to the Accept headers in the request. The request could not be completed due to a conflict with the current state of the resource. The server encountered an unexpected condition that prevented it from fulfilling the request. 501 Not Implemented The server does not support the functionality required to fulfill the request. Response parameters The response parameters vary by API. For information about returned data for each API, see the API-specific documentation. Using Unix timestamps Many request parameters use Unix timestamps. You can specify Unix timestamp values as a single value or as a range. If a range is implied but either boundary is not specified, the default timestamp of seconds is used. For optimal query performance, we recommend that you provide meaningful timestamp values. Using the create_date parameter as an example, the following table provides example request values and their equivalents: Page 11 of 328

12 Query String Equivalent?create_date= create_date == ?create_date= > create_date < ?create_date=> > create_date < ?create_date=>= >= create_date < ?create_date=< > create_date < ?create_date=<= > create_date <= Security The Alert Logic ActiveIntegration APIs use the following methods to secure access to data: Authentication Authorization Authentication Each Alert Logic ActiveIntegration API request must contain information that identifies the requester as a trusted user. The APIs support two types of authentication: User API key authentication SSL certificate authentication User API key authentication This section describes the API key that is used for authenticating a user identity when making requests using the Alert Logic ActiveIntegration APIs; this API key is commonly called the user API key. Alert Logic also uses another type of API key which is used for provisioning assets on behalf of a customer; this API key is commonly called the customer API key, provisioning API key, or unique registration key, and will not work for authenticating a user identity for ActiveIntegration API requests. The user API key is used to verify the identity of the user when making a call to the API. The Alert Logic ActiveIntegration APIs use standard HTTP Basic authentication, where the API key is the user name and the password is blank. Alert Logic assigns a unique API key to a user upon request. You can request a user API key from the Alert Logic ActiveIntegration APIs website: To use an API key, include the API key in the header of the call to the API. The API verifies the API key and accepts or rejects the API key accordingly. Page 12 of 328

13 Alert Logic maintains the right to deny any API key request that does not contain documentation to preauthorize the permissions necessary for the credentials of the customer or the user. Example The following example shows how to include a user API key in a curl request. In this example, the -u option specifies the API key (user name) and password in the format '[50-character_API_key]:[password]'. The password value is blank. curl curl -kv -H "Accept: application/json" -u '01234abcde01234abcde01234abcde01234abcde01234abcde:' " SSL certificate authentication Client-side SSL certificate authentication is based on an extension to the normal SSL/TLS handshake exchange that occurs for HTTP communications. The SSL certificate is used to verify the identity of the user when making a call to the API. To use an SLL certificate, the user provides identification and verification information regarding a certificate in the header of the call to the API and initiates an SSL session. The server verifies this information and accepts or rejects the use of the certificate as credentials for API authentication, based on the validity and prior registration of the certificate with Alert Logic. The Alert Logic ActiveIntegration APIs do not require a client-side SSL certificate but optionally accept one in place of a user API key. After verification, the API accepts this certificate as a fully authenticated identity in the Alert Logic system. Example The following example shows how to include an SSL certificate in a curl request. In this example, the --cert option specifies the SSL certificate. curl curl -kv -H "Accept: application/json" --cert alertlogic-api-certfile.pem " Authorization Authorization determines what data and functions a user has access to. The Alert Logic ActiveIntegration APIs support the following authorization methods: Impersonation support User identity permissions Page 13 of 328

14 Impersonation support Impersonation support provided in the Alert Logic ActiveIntegration APIs lets you act on behalf of a child customer when processing API functions. You may need to "impersonate" another user when you do not have API key information for a child customer; using the impersonation feature, you can use your own API key for authentication and effectively become another user through the API. You can only impersonate another user of the same parent customer or any children allocated to that parent. To use impersonation, include the custom header, X-Alertlogic-Impersonate, with the value of the impersonated user identifier. Additionally, the user making the request must have permission to impersonate. Example The following example shows how to include the X-Alertlogic-Impersonate header in a curl request: curl curl -kv -H "X-Alertlogic-Impersonate: 1234" --cert alertlogic-api-certfile.pem " User identity permissions The Alert Logic ActiveIntegration APIs use the permissions mechanism that exists in the Alert Logic user interface (UI) to control access to the API and its features. To use the API, make sure your user account has the appropriate permissions. The following table describes the permissions that the ActiveIntegration APIs use: Permission API_ACCESS API_IMPERSONATE VIEW_CHILD Description Allows a user identity to access the API resource endpoints. Without this permission, requests are rejected with 403 Forbidden response codes. Allows an authenticated user identity to perform impersonation of another related user identity. Without this permission, requests using impersonation are rejected with 403 Forbidden response codes. Allows a user identity access or impersonation access to child customer information. Page 14 of 328

15 Incident API About the Incident API Use cases How to implement Get Incident Get Incident Notes About the Incident API The Alert Logic ActiveIntegration Incident API retrieves incident information. An incident comprises correlated suspicious events that require action to maintain your security posture, achieve regulatory compliance, or both. Alert Logic generates incidents based on various predefined scenarios. The Incident API also provides the ability to retrieve incident notes, which provide details about the incident and recommended remediation actions. Method Resource Description GET /api/incident/v3/incidents Retrieve the incident data GET /api/incident/v2/notes Retrieve notes for a specific incident Each endpoint in the Incident API has its own version. For this reason, you may use multiple versions of the API simultaneously. The Incident API is available for interactive use on the website. Use cases Ticketing systems The most common use case for the Incident API is for integration with ticketing systems. You can use the GET method to retrieve enough information to easily route tickets to the appropriate team for remediation or blocking action. Audit External audits are commonplace in today s business environment. During audits, auditors often request a list of all the incidents generated during a specific time frame. Efficient and timely delivery of the required data is essential to successfully passing an audit; the Incident API allows you to provide that data with one call to the API. Page 15 of 328

16 Incident filtering Incidents and outbreaks often follow patterns. Identifying those patterns requires you to filter incidents for specific dates and pertinent information such as a threat rating or type. You can identify patterns quickly and build reports and dashboards that give appropriate team members the information needed. Comparing incidents across customers Cyber-attacks often target a broad IP space. If you are a parent customer and find that one of your child customer's incident notes shows an attack, you must do additional analysis to ensure the attack has not spread across multiple customers. How to implement How to use the Incident API for direct tasks To retrieve incidents by the date when the incidents were last modified, use GET incidents, providing the last_ modified_date. To retrieve the incident notes for multiple incidents, use GET notes with customer_id=all_children, which allows you to search all of the child customers for the requested information. List out the individual incident IDs, separated by a comma. How to use the Incident API for ticketing systems Use the following guidelines when integrating Alert Logic incidents with your ticketing systems: Create a polling query using GET incidents to retrieve incidents on a regular basis. To accomplish this, use either the create_date or last_modified_date with an incremented timestamp. We recommend that you build in some time overlap into your queries to avoid the possibility of missing incidents, and then filter out any duplicates. You only receive the incident notes the first time the ticketing system retrieves an incident. If you need to view the description notes again, you must make a second call to the API to refresh the data. How to use the Incident API for an audit To retrieve the total number of incidents created during a particular month, use GET incidents, providing a create_date range that specifies the beginning of the month and the end of the month. How to use the Incident API for incident filtering Search for incidents that occurred over a specific time frame. Use create_date to specify the start and end of the range. Use the field request parameter to narrow response fields to incident_id, summary, and threat_rating to identify patterns quickly. How to use the Incident API to compare incidents across customers Search for incidents that occurred over a specific time frame. Use create_date to specify the start and end of the range. Specify the specific customer IDs or use all_children to include all customers that are accessible to you. Use the limit parameter to limit the number of incidents returned. Filter for a specific time or attack vector. Page 16 of 328

17 Get Incident Retrieve one or more incidents. URL /api/incident/v3/incidents HTTP Method GET Query Parameters Specifies when the incident was created. create_date true* Unix timestamp You can specify a single value or a range. If a range is implied but either boundary not specified, the default timestamp of seconds is used. Specifies the customer accounts to include in the search results. customer_id false positive integer Use a comma-separated list to include multiple IDs. The value all_children includes all customer accounts that the caller can access. Default: Customer ID of the user making the request Specifies the parameters to include in the response. field false Response Parameters Use a comma-separated list to include multiple parameters. Default: All response parameters incident_id true* positive integer Specifies an incident to include in the results. Use a comma-separated list to include multiple incidents. Specifies when the incident was modified last. last_modified_date true* Unix timestamp limit false positive integer You can specify a single value or a range. If a range is implied but either boundary not specified, the default timestamp of seconds is used. Specifies the maximum number of records to include in the response Default: 10 * You must specify at least one of these parameters: create_date, incident_id, or last_modified_date. Page 17 of 328

18 Response Parameters Incident acknowledgment status. acknowledge_ status string Not Acknowledged Acknowledged - In Analysis Acknowledged - No Analysis Required Acknowledged - Completed Analysis acknowledged_by positive integer ID of the user who acknowledged the incident. acknowledged_ date attackers Unix timestamp string When the incident was acknowledged. IPv4 or IPv6 address of the attacker. If there are multiple attackers, a list of IP addresses is provided. This parameter value may be blank if the IP address cannot be determined. Note: The data in this field may change without a corresponding change in the last_modified_date field. begin_date Unix timestamp When the first event occurred. Incident class. class_name string application-attack base defensive-action info-leak misconfiguration pending policy-violation recon suspicious-activity test trojan-activity worm-activity closed_by positive integer ID of the user who closed the incident. closed_date Unix timestamp When the incident was closed. ID of the incident closure type. closed_type positive integer 0: open 1: administratively closed (no review needed) 2: closed without review Page 18 of 328

19 3: closed after review - no threat 4: closed after review - valid threat correlation_end_ date correlation_start_ date Unix timestamp Unix timestamp When event correlation ended. When event correlation started. create_date Unix timestamp When the incident was created. created_by positive integer ID of the user who created the incident. customer_id positive integer ID of the customer the incident belongs to. customer_name string Name of the customer the incident belongs to. description string Oldest, original incident note, which includes the cause of the incident. devices device List of devices and appliances involved in the creation of the incident. end_date Unix timestamp When the last event occurred. event_ids positive integer List of IDs of events that contribute to the incident. evolution_root positive integer ID of the most evolved incident in the evolution tree. evolution_tree evolution _tree Hierarchical representation of the evolution of related incidents where the top of the tree represents the most evolved incident. evolved_to positive integer ID of the incident that the current incident has evolved into. Geolocation information of the attacker's IP address. If there are multiple IP addresses (as identified in the attackers field), geoip geoip geolocation information for each of the IP addresses is provided in a hash, with the IP address as the key. This parameter value is blank when the attacker's IP address is not available. incident_id positive integer ID of the incident. Indicates if a proxy server is detected. is_proxy Boolean true: A proxy is detected. false: A proxy has not been detected. (Note: Although a proxy has not been detected, a proxy may still exist.) last_modified_date Unix timestamp When the incident was modified last. modified_by positive integer ID of the user who modified the incident last. num_evts open positive integer positive integer Number of events during the correlation time frame that match the incident correlation parameters. Indicates if an incident is open. Page 19 of 328

20 0: Closed 1: Open reopen_date Unix timestamp When the incident was reopened. summary string Text summary (name) of the incident. Threat rating for an incident. threat_rating string none low medium high critical vector vector Attack vector information used to logically group incident types. IPv4 or IPv6 address of the victim. If there are multiple victims, a list of IP addresses is provided. victims string This parameter value may be blank if the IP address cannot be determined. Note: The data in this field may change without a corresponding change in the last_modified_date field. device name string Name of the device. sensor_id positive integer ID of the device. device_id string Customer-supplied ID of the device. evolution _tree incident_id positive integer ID of the incident. evolved_from evolution _tree List of incidents that evolved to the current incident. geoip area_code string Area code. city string Full city name. country_code string Two-character ISO country code. Page 20 of 328

21 country_code_3 string Three-character ISO country code. country_name string Full country name. dma_code string Designated market area code. latitude longitude string string postal_code string Postal code. region string Latitude at the center of the most granular location available (postal code, city, region, or country). Longitude at the center of the most granular location available (postal code, city, region, or country). Sub country code of the attacker for this incident. This value is either an ISO code for US and Canada or a FIPS 10-4 code for all other countries. vector type string Base incident name. sub_type string Base incident sub-type. Example The following example requests retrieval of one incident created on or after 2/22/2014 at 9:53pm (UTC) from all customers that the caller can access. The response includes all available response fields by default. Request GET /api/incident/v3/incidents?customer_id=all_children&create_ date=> &limit=1 curl curl -kv -H "Accept: application/json" --cert alertlogic-api-certfile.pem " children&create_date=> &limit=1" The curl request has been formatted to improve readability. Page 21 of 328

22 Response [ "acknowledge_status": "Acknowledged - Completed Analysis", "acknowledged_by": 12345, "acknowledged_date": , "begin_date": , "closed_by": null, "closed_date": null, "closed_type": 0, "correlation_end_date": , "correlation_start_date": , "create_date": , "created_by": 0, "customer_id": 01234, "customer_name": "ABC Company, inc.", "description": "**Attack Detail**: \n**attacker Location:** , Ukraine \n**targeted Server**: \n\nWe have detected a recon attack against your web application using known malicious SQL commands. These attacks are designed to map your database and attempt to steal user and company data. We have not detected any indication of success or progress. If we do the incident will evolve up and be escalated to an Analyst for further review. \n\n**remediation Recommendation:** \nif this is not expected traffic you should block the scanning IP address at your perimeter firewall.\nwhen designing your SQL database and front end application it's best to follow the below procedures to minimize the risk. \n\nsql Primary Defenses:\n \n* Review use of Prepared Statements (Parameterized Queries) \n* Review use of Stored Procedures \n* Escaping all User Supplied Input\n* Avoid disclosing error information \n \n[owasp SQL Injection Cheat Sheet] ( \n", "end_date": , "evolution_root": , "evolution_tree": "evolved_from": [], "incident_id": , "evolved_to": null, "incident_id": , "is_proxy": false, "last_modified_date": , "modified_by": null, "num_evts": 6, "open": 1, "reopen_date": null, "summary": "SQL Injection Recon Attempts from \n", "threat_rating": "Medium", "class_name": "application-attack", "attackers": [ " " ], "victims": [ " " ], "geoip": " ": "country_code": "UA", "country_code3": "UKR", Page 22 of 328

23 ] "country_name": "Ukraine", "region": null, "city": null, "postal_code": null, "latitude": 49, "longitude": 32, "area_code": 0, "dma_code": 0, "vector": "type": "web_attack_recon", "sub_type": "sqli", "devices": [ "device_id": "222222", "sensor_id": 5555, "name": "device-ids-01" ], "event_ids": [ , , , , , , ] Page 23 of 328

24 Get Incident Notes Retrieve incident notes. URL /api/incident/v2/notes HTTP Method GET Query Parameters Specifies the customer accounts to include in the search results. customer_id false positive integer Use a comma-separated list to include multiple IDs. The value all_children includes all customer accounts that the caller can access. Default: Customer ID of the user making the request incident_id true positive integer Specifies an incident to include in the results. Use a comma-separated list to include multiple incidents. Response parameters create_date Unix timestamp When the incident was created. description_text string incident_id positive integer ID of the incident. Incident note, which is entered into the incident by either the system or an analyst. Contents may include the attack details, attacker location, targeted server, or remediation recommendation. Example The following example requests the retrieval of the incident notes for two specific incidents. The incidents can be for any customer that the caller can access. Request GET /api/incident/v2/notes?customer_id=all_children&incident_ id= , Page 24 of 328

25 curl curl -kv -H "Accept: application/json" --cert alertlogic-api-certfile.pem " children&incident_id= , " The curl request has been formatted to improve readability. Response [ "create_date": , "description_text": "**Attack Detail**: \nthe attacking host IP has been observed making multiple login attempts to the Wordpress service on It is very likely that this is an attempt to brute force the Wordpress software login credentials.\n\n**recommended Remediation:** \nif any connections from this address are abnormal we recommend blocking the IP at your perimeter firewall, otherwise ongoing monitoring of this attack will alert you to further needed actions.\n", "incident_id": , "create_date": , "description_text": "**Attack Detail**: \n**attacker Location:** Ukraine \n**targeted Server**: \n\n**Remediation Recommendation:** \n If this is not expected traffic you should block the scanning IP address at your perimeter firewall.\nif this scan was not authorized its is recommended that this host is blocked at your edge firewall. The UNION operator is used to do crosstable queries in an attempt to retrieve sensitive information from the database that can be used for a later attack. While these queries do not appear to immediately indicate that this host is vulnerable to this attack it's best to follow the below procedures to minimize this risk. \n\nsql Primary Defenses:\n \n* Review use of Prepared Statements (Parameterized Queries) \n* Review use of Stored Procedures \n* Escaping all User Supplied Input\n* Avoid disclosing error information \n \nhttps:// \n", "incident_id": ] Page 25 of 328

26 Order API About the Order API Use case: Self-service ordering How to implement Create Order Get Order Status About the Order API The Alert Logic ActiveIntegration Order API lets you submit and track the progress of orders. Method Resource Description POST /api/order/v2 Submit an order for one or more Alert Logic products GET /api/order/v2/[orderid] Retrieve the status of an Alert Logic order Use case: Self-service ordering The Alert Logic ActiveIntegration Order API allows for a seamless workflow designed to incorporate all phases of customer ordering and provisioning. The Order API also lets you integrate the purchasing process into your portal experience. Submission of an order through the Order API generates the customer account, defines users for the account, handles the appliance claiming and provisioning processes, and generates provisioning API keys. The API can also use a call-back mechanism to notify you when the process is complete, providing all the generated data from the order. You can also actively get the status of an order throughout the process. How to implement To create an order for a customer, make a POST request. You can optionally include a callback URL so that the API can notify you upon completion of the provisioning process. To retrieve the status of an existing order, use the GET method, providing the order ID for the specific order in your request. Page 26 of 328

27 Create Order Create an order for one or more Alert Logic products. ActiveIntegration APIs access your live production data. Use caution when creating, modifying or deleting data. Process types for claiming an appliance When you create an order using the Order API, you specify how Alert Logic claims and provisions your appliances. There are two available process types: post and auto. POST claim process When you place an order requesting the post claim type, the API makes a POST to the appliance IP web form to claim the appliance and start provisioning tasks. Your virtual appliance must be publicly accessible from the internet when you make the request. Auto claim process When you place an order requesting the auto claim type, the API attempts to automatically claim your appliance. To accomplish this, Alert Logic uses details provided in the API call about the appliance and the cloud provider (cloud_ metadata) to match the appliance to the order. When this is successful, Alert Logic can automatically claim the appliance and begin provisioning. When you specify the use of auto-claim, Alert Logic automatically claims all future appliances for the customer account. URL /api/order/v2 HTTP Method POST POST Parameters customer_id true* positive integer customer_name true* string skus true skus Specifies the integer identifier for an existing customer. You must specify either the customer_id or the customer_name. Specifies the customer name for the new customer account. You must specify either the customer_id or the customer_name. Specifies a list of appliances to order. You can include a maximum of five items. users false users Specifies a list of new user accounts to be created. Page 27 of 328

28 You can include a maximum of 15 items. Specifies the HTTPS callback URL. The callback must use the HTTPS protocol for transport security. callback false string If a callback URL is specified, the API makes a POST to the specified URL when the job is complete. The POST body format is the same as the response fields in the Get Order Status endpoint. *You must specify either the customer_id or the customer_name. skus sku true string public_ip false string hostname false string Specifies the identifier for the Threat Manager virtual appliance. Alert Logic defines this value. Specifies the public IP address for the new virtual appliance. If this value is provided, the virtual appliance is claimed on behalf of the customer. Specifies the appliance hostname for the new virtual appliance. Default: Auto-generated Specifies the type of process for claiming and provisioning appliances. claim_type false string cloud_metadata Required when claim_ type is set to auto cloud_metadata post: (Default) The API makes a POST to the appliance IP web form to claim and start provisioning appliances. auto: Use the information in cloud_metadata to automatically claim and provision the appliance. Specifies appliance and cloud information for automatically claiming appliances. users first_name true string Specifies the first name for the new user. last_name true string Specifies the last name for the new user. true string Specifies the address for the new user. This parameter is Page 28 of 328

29 also used for the username for the account and must not already exist in the system. cloud_metadata provider true string Specifies the appliance provider. Valid value: amazon account_id true string Specifies the customer's cloud provider account ID. instance_id true string Specifies the virtual appliance ID. region true string Specifies the appliance region, which is required for identifying appliances. This value must be a valid country-region-code. Response Parameters The API returns the requested POST Parameters in the response. In addition to the POST parameters, the following parameter is returned: id positive integer ID of the order request. You can use this value to retrieve the order status. Example - existing customer The following example submits an order for an existing customer. Request POST /api/order/v2 curl curl -kv -H "Content-Type: application/json" -H "Accept: application/json" --cert alertlogic-api-certfile.pem -X POST " Page 29 of 328

30 The curl request has been formatted to improve readability. POST parameters: "customer_id":999, "skus":[ "sku":"abc-def-123", "public_ip":" ", "sku": "abc-def-456", "cloud_metadata": "provider": "amazon", "account_id": " ", "instance_id": "i-b4a6689b", "region": "us-east-1", "claim_type": "auto" ], "callback":" Response "id":"gv2het0fqia", "customer_id":999, "skus":[ "sku":"abc-def-123", "public_ip":" ", "sku": "abc-def-456", "cloud_metadata": "provider": "amazon", "account_id": " ", "instance_id": "i-b4a6689b", "region": "us-east-1", "claim_type": "auto" ], "callback":" Page 30 of 328

31 Example - new customer The following example submits an order for a new customer. Request POST /api/order/v2 curl curl -kv -H "Content-Type: application/json" -H "Accept: application/json" --cert alertlogic-api-certfile.pem -X POST " The curl request has been formatted to improve readability. POST parameters: "customer_name":"company", "skus":[ "sku":"abc-def-123", "public_ip":" ", "sku": "abc-def-456", "cloud_metadata": "provider": "amazon", "account_id": " ", "instance_id": "i-b4a6689b", "region": "us-east-1", "claim_type": "auto" ], "users":[ "first_name":"john", "last_name":"doe", " ":"john.doe@company.com" ], "callback":" Page 31 of 328

32 Response "id":" GV2hET0FQIA", "customer_name":"company", "skus":[ "sku":"abc-def-123", "public_ip":" ", "sku": "abc-def-456", "cloud_metadata": "provider": "amazon", "account_id": " ", "instance_id": "i-b4a6689b", "region": "us-east-1", "claim_type": "auto" ], "users":[ "first_name":"john", "last_name":"doe", ], "callback":" Get Order Status Retrieve the status of an Alert Logic order. URL /api/order/v2/[orderid] HTTP Method GET URL Parameter orderid true string Specifies the order ID. This value is generated when the order is submitted. Page 32 of 328

33 Response Parameters In the response, the API returns the POST parameters from the order request. The following parameters are also returned: Order status. status string processing error finished progress positive integer Percentage complete of the order fulfillment. artifacts artifacts Items created during order fulfillment. artifacts api_key customer_id ui_credentials string positive integer hash Provisioning API key. This key is used for provisioning assets such as appliances and agents on behalf of the customer. Note: You cannot use this key for authentication when using Alert Logic ActiveIntegration APIs. ID for the newly created customer. Use this identifier for any additional orders for the same customer. This field appears for new customer orders only. User name and password for each new user account. If there are multiple new user accounts, the data is provided in a hash with the user name ( address) as they key, as follows: "john.doe@company.com": "foobar123" This field appears for orders with new users only. Example The following example retrieves an order by providing the order ID, which is generated and returned when the order is submitted. Request GET /api/order/v2/gv2het0fqia Page 33 of 328

34 curl curl -kv -H "Accept: application/json" --cert alertlogic-api-certfile.pem " The curl request has been formatted to improve readability. Response "id":"gv2het0fqia", "customer_name":"company", "skus":[ "sku":"abc-def-123", "public_ip":" ", "sku": "abc-def-456", "cloud_metadata": "provider": "amazon", "account_id": " ", "instance_id": "i-b4a6689b", "region": "us-east-1", "claim_type": "auto" ], "users":[ "first_name":"john", "last_name":"doe", ], "callback":" "status":"processing", "progress":70, "artifacts": "api_key": "01234abcde01234abcde01234abcde01234abcde01234abcde", "customer_id": 999, "ui_credentials": "password123" Page 34 of 328

35 Customer API About the Customer API Use case: Customer account provisioning How to implement Create Customer Get Customer Creation Status Get Customer About the Customer API The Alert Logic ActiveIntegration Customer API lets you manage child customers, as follows: Create a child customer account Monitor the status of the account creation process View account information for an existing child customer account Method Resource Description POST /api/customer/v1 Create a child customer account GET /api/customer/v1/status/ [provisioningid] Retrieve the status of a customer creation request GET /api/customer/v1/[customerid] Retrieve an existing customer object For more information about child customer accounts, see Alert Logic Customer Hierarchy. Use case: Customer account provisioning You can use the Customer API to securely provision new child customer accounts and acquire the corresponding customer IDs from within your own application. How to implement To create a child customer, make a POST request that provides a name for the new child customer. You can also optionally provide a callback URL. To determine the status of a customer creation request, use GET customer creation status, providing the provisioning ID that was created as a result of the POST request. To retrieve information on an existing child customer, use GET customer, providing the customer ID of the child customer object. Page 35 of 328

36 Create Customer Create a child customer account. ActiveIntegration APIs access your live production data. Use caution when creating, modifying or deleting data. URL /api/customer/v1/ HTTP Method POST POST Parameters customer_name true string Specifies the customer name for the new child customer account. Specifies the HTTPS callback URL. The callback must use the HTTPS protocol for transport security. callback false string If a callback URL is specified, the API makes a POST to the specified URL when the job is complete. The POST body format is the same as the response parameters in the Get Customer Creation Status endpoint. Response Parameters Status of the customer creation request. status string customer creation initialized completed error failed enqueued successfully ID of the customer creation request. provisioning_id string You can use this identifier to retrieve the status using the GET customer creation status endpoint. customer_name string Customer name in the new child customer account. Page 36 of 328

37 Example - new customer The following example requests the creation of a new customer account. The customer account is a child to the parent of the user making the request. Request POST /api/customer/v1 curl curl -kv -H "Content-Type: application/json" -H "Accept: application/json" --cert alertlogic-api-certfile.pem -X POST " The curl request has been formatted to improve readability. POST parameters: "customer_name": "Child Customer" Response Location: Content-Location: "status": "customer creation initialized successfully", "provisioning_id": "A C BB14-136FAC9940BB", "customer_name": "Child Customer" Example - new customer with callback The following example requests the creation of a new customer account. The customer account is a child to the parent of the user making the request. By including a callback URL in the request, Alert Logic POSTs the results of the request to the URL when the job finishes. Page 37 of 328

38 Request POST /api/customer/v1 curl curl -kv -H "Content-Type: application/json" -H "Accept: application/json" --cert alertlogic-api-certfile.pem -X POST " The curl request has been formatted to improve readability. POST parameters: "customer_name": "Child Customer", "callback": " Response Location: Content-Location: "status": "customer creation initialized successfully", "provisioning_id": "5ACCFE28-50DC-4C57-8A82-33A4ABE0455A", "customer_name": "Child Customer" Callback Response: # Callback Response to Location: Content-Location: "api_key": "01234abcde01234abcde01234abcde01234abcde01234abcde", "customer_id": 4, "customer_name": "Child Customer", "provisioning_id": "5ACCFE28-50DC-4C57-8A82-33A4ABE0455A", "status": "completed" Page 38 of 328

39 Get Customer Creation Status Retrieve the status of a customer creation request. URL /api/customer/v1/status/[provisioningid] HTTP Method GET URL Parameter provisioningid true string Specifies the ID of a customer creation job. Response Parameters api_key string Provisioning API key. This key is used for provisioning assets such as appliances and agents on behalf of the customer. Note: You cannot use this key for authentication when using Alert Logic ActiveIntegration APIs. customer_id positive integer ID of the customer. customer_name string Name of the customer. provisioning_id string ID of a customer creation request. Customer creation request status. status string customer creation initialized completed error failed enqueued successfully Example The following example requests the status of a customer account creation job. The request provides the ID of the customer creation job, which is generated and returned when the creation request is submitted. Request GET /api/customer/v1/status/89246b10-58e aea9-52b45bac8114 Page 39 of 328