Data collected

tCell collects a variety of runtime information from your application. There are two types of data collected, events and metrics. Events represent discrete events or pieces of information. Metrics represent time based counts of different events.

Sanitization

All data is passed through a sanitization filter before being asynchronously sent to the tCell service. No data leaves the application agent without first passing through this sanitization process. Sanitization steps are designed to prevent private data from leaving your network.

Sanitization steps include:

Session IDs (sid): Session tokens are one-way hashed with an optional private key (hmac_key) to form the transmitted sid. This lets tCell associate multiple events from the same user session without knowing anything about the session itself.

Password IDs (passwordId): For agents that support password behavior tracking, passwords for login events are one-way hashed with an optional private key (password_hmac_key), the tcell app id, and the username, and then a small portion of the hash result is used. The net result is that the tCell service can determine if an ip address is trying a variety of passwords or usernames, or is trying the same one repeatedly. Thus, a misconfigured automated agent which always attempts the same username and password is not flagged as an an account takeover attack. However, because of the limited portion of the hash collected, the data is not useful to try to guess the actual password, especially if the private key is used.

Transaction IDs (tid): Generate UUIDs for transaction IDs using no customer or user identifiable data. URI sanitization: URIs are all sanitized by stripping parameter values. For example, the referrer URL http://localhost:8080/WebGoat/login.mvc?error=SomeErrorHere&test=SomeValue will be sanitized to http://localhost:8080/WebGoat/login.mvc?error=&test=

Violation Payload Data

The Violation Payloads options at Policies > App Firewall in the Monitor tab determine where tCell sends violation payload data.

The Send Payload Data to tCell option directs tCell to send full payloads with the event data to the tCell cloud. The payloads can help you better understand the nature of the attack on the application.

However, the payloads may contain personally identifiable information (PII) which, if displayed, could violate your GDPR or other compliance protocols. If you prefer not to send the payloads to the tCell cloud, disable the option. If disabled, all tCell features will continue to work. This feature will apply to form parameters and query parameters in the request (including header, body, and URL).

The Log Payload Data Locally option logs payload data to local logs (tcell.log). If selected, parameters listed in the Exclude sending payloads for parameters table will still be sanitized. Therefore these values will not be sent to local logs.

These options only apply to the sending of payload data ("payload" is one field of an event). With either option enabled or disabled, all other tCell event data will still be sent to the cloud and local logging.

Events

server_agent_details

  • Protection category: Server Details
  • Launch: App server startup
  • Fields
    • user: User account the server process is running as
    • user group: Group the server process is running as
  • Sample 
     
    1
    {"event_type":"server_agent_details",
    2
    "group":"1000",
    3
    "user":"userx"}

server_agent_packages

  • Protection category: Server Details
  • Launch: Class loaded/App Initialization
  • Fields
    • n: Name of package
    • v: Version of package
    • l: License type
  • Sample 
     
    1
    {"event_type":"server_agent_packages",
    2
    "packages": [
    3
    {"v": "0.0.4",
    4
    "n": "tcell-agent"},
    5
    {"v": "1.0.4", "n": "enum34"}

appserver_routes

  • Protection category: App Sensor
  • Launch: Route registered/App Initialization
  • Fields
    • uri: uri with :placeholders for variables
    • method: GET, POST, etc or * for any
    • rid: tCell route id. A hash of route&method
    • destination: Description of where a request was routed, i.e. name of controller, function, etc defined on a per-framework basis
  • Sample 
     
    1
    {"event_type":"appserver_routes",
    2
    "uri":"/user/:id/address",
    3
    "method":"*""rid":1396482959514716287,
    4
    "destination":"com.customer123.controllers.UserAddress"}

app_config_setting

  • Protection Category: Application Config Audit

  • Launch: App Initialization

  • Fields

    • section: "service" or "connector"
    • prefix: service\engine\host\context or service\connector
    • name: field name
    • value: field value
    • package: Server type (Tomcat, etc.)

  • Sample

     
    1
    {"event_type" : "app_config_setting",
    2
    "section" : "context",
    3
    "prefix" : "Tomcat\nTomcat\nlocalhost\n/WebGoat",
    4
    "name" : "timeout",
    5
    "value" : "2880",
    6
    "package" : "Tomcat"}

redirect

  • Protection category: Open Redirect
  • Launch: Http response with a 3xx response code
  • Fields
    • remote_addr: remote ip of the user
    • method: GET, POST, etc
    • to: target redirect domain that violated policy
    • from_domain: domain user started on (HOST)
    • from: Sanitized URI doing the redirect
    • sid: HMAC of session id
    • rid: tCell route id
  • Sample 
     
    1
    {"event_type":"redirect",
    2
    "method":"get",
    3
    "remote_addr":"10.0.2.2",
    4
    "status_code":303,
    5
    "to":"domain.com",
    6
    "from_domain":"the current domain",
    7
    "from":"path redirect came from",
    8
    "sid":"cb38d7630b38d7630b38d7630"}

as

  • Protection Category: App Sensor
  • Launch: Suspicious HTTP request or response payload
  • Fields
    • dp: Name of detection point, i.e. xss, sqli, etc.
    • param: Parameter name with suspicious payload
    • uid: User ID if login enabled and user authenticated
    • loc: Sanitized URI path
    • sess: HMAC of session ID
    • data: parameter type (header, query, etc.)
    • rou: tCell route ID
    • m: HTTP method
    • remote_addr: IP Address of client
  • Sample 
     
    1
    {"event_type":"as",
    2
    "dp":"xss",
    3
    "cnt":1,
    4
    "uid":"james",
    5
    "sid":"sessionhash",
    6
    "loc":"location/url",
    7
    "rou":"32432432",
    8
    "m":"get",
    9
    "data":{"fp":"s\u0026sos"},
    10
    "remote_addr":"3.3.3.3"}

discovery

  • Protection category: Data Exposure
  • Launch: First access to any data source (database table, REST api, etc.)
  • Fields
    • type: database, REST API, etc.
    • db: database name
    • schema: database schema name
    • table: database table name
    • fields: name fields accessed
    • rid: tCell route_id
    • uid: user_id if known
    • q: Query type
  • Sample 
     
    1
    {"event_type":"discovery",
    2
    "type":"db",
    3
    "rid":"2323224",
    4
    "uid":"bob@bob.com",
    5
    "q":"select",
    6
    "db":"redis:4334",
    7
    "schema":"asfdasf",
    8
    "table":"users",
    9
    "fields":["ssn","first_name"],
    10
    "field":"field"}

login

  • Protection category: Login fraud
  • Launch: User login
  • Fields
    • event_name: login-failure, login-success
    • user_agent: HTTP header
    • referrer: HTTP header
    • remote_addr: remote address
    • header_keys: HTTP header names, in order if possible
    • user_id: user that tried to login
    • password_id: hmac of password for the attempt
    • document_uri: uri that was posted to
    • session: HMAC of sessionid
    • user_valid: null, true, false
  • Sample 
     
    1
    {"event_type":"login",
    2
    "event_name":"login-success",
    3
    "user_agent":"Mozilla/5.0 ...",
    4
    "referrer":"http://localhost:3085/users/sign_in",
    5
    "remote_addr":"10.0.2.2",
    6
    "header_keys":["VERSION","HOST","CONNECTION","CACHE_CONTROL","COOKIE"],
    7
    "user_id":"1",
    8
    "password_id":"98ea6e4f",
    9
    "document_uri":"/users/sign_in",
    10
    "session":"e9e80cd52ad521ddb9090ac9ac",
    11
    "user_valid": true}

Metrics

rct

  • Description: Route count table
  • Fields:
    • c: Total requests
    • mx: Maximum Request Time (ms)
    • mn: Minimum Request Time (ms)
    • t: Average Request Time (ms)
  • Sample 
     
    1
    {"event_type": "metrics",
    2
      "rct": {
    3
        "98246921":{ 
    4
          "c": 3,
    5
          "mx": 446,
    6
          "mn": 68,
    7
          "t": 318
    8
      },
    9
        "?": {
    10
          "c": 4,
    11
          "mx": 9,
    12
          "mn": 5,
    13
          "t": 7
    14
        }
    15
    }

sessions

  • Description: Per session metrics for authenticated users
  • Fields
    • ua: A dictionary of user-agents whose value is the ip's they came from
    • uid: User ID for that session
  • Sample 
     
    1
    {"event_type": "metrics",
    2
      "sessions": {
    3
        "hmac_of_session_id_x": [
    4
        {
    5
          "uid": "user_x",
    6
          "track": [
    7
          [
    8
            "Mozilla/5.0 User Agent V1.03",
    9
          [
    10
              "1.1.1.1",
    11
              "1.1.2.2"
    12
              ]
    13
            ]
    14
          ]
    15
        }
    16
      ],
    17
      "hmac_of_session_id_y": [
    18
        { "uid": "user_y",
    19
          "track": [
    20
          [
    21
            "Mozilla/3.0 User Agent V1.03",
    22
            [
    23
              "1.1.3.1"
    24
            ],
    25
            "Chrome 30 User Agent",[
    26
              "1.101.3.4"]
    27
             ] 
    28
          ]
    29
        } 
    30
      ] 
    31
    }