Cisco Secure Access - Cloud Firewall

Overview

Cloud firewall logs show traffic that has been handled by Secure Access cloud-delivered firewall.

Vendor: Cisco
Supported environment: Cloud
Detection based on: Telemetry

Warning

Important note - This format is currently in beta. We highly value your feedback to improve its performance.

Configure

This section will guide you through configuring Cisco Secure Access to forward logs to Sekoia.io using a Cisco-managed Amazon S3 bucket.

Prerequisites

Full Admin user role in Cisco Secure Access. For more information, see the Manage Accounts documentation.
Access to Sekoia.io Intakes and Playbook pages with write permissions.

Step 1 — Configure the Cisco-Managed S3 Bucket

Cisco Secure Access can export your logs to a Cisco-managed Amazon S3 bucket. Cisco configures all managed buckets to use Amazon Server-Side Encryption with S3-Managed Keys (SSE-S3, AES-256). Access is provided via AWS IAM credentials.

In the Cisco Secure Access dashboard, navigate to Admin > Log Management.
Click Set up cloud storage and select Cisco.
Select a Region — choose the region closest to you to minimize latency when downloading logs.

Warning

The selected region cannot be changed later without deleting your current settings and starting over. Not all AWS regions are available.
Select a Retention Duration — choose 7, 14, or 30 days.

Note

Beyond the selected time period, all data is purged and cannot be retrieved. A shorter duration is recommended if your ingestion cycle is frequent.
Click Save. Cisco Secure Access activates log export to the S3 bucket. When activation is complete, the Amazon S3 Summary page appears.
Copy the Access Key and Secret Key and store them in a safe place.

Warning

The Access Key and Secret Key are displayed only once. If you lose them, you must regenerate them by rotating the keys in Cisco Secure Access.
Click Done.

Step 2 — Create the Intake

Configure Your Intake

This section will guide you through creating the intake object in Sekoia, which provides a unique identifier called the "Intake key." The Intake key is essential for later configuration, as it references the Community, Entity, and Parser (Intake Format) used when receiving raw events on Sekoia.

Go to the Sekoia Intake page.
Click on the + New Intake button at the top right of the page.
Search for your Intake by the product name in the search bar.
Give it a Name and associate it with an Entity (and a Community if using multi-tenant mode).
Click on Create.

Note

For more details on how to use the Intake page and to find the Intake key you just created, refer to this documentation.

Step 3 — Configure the Connector

Configure Your Playbook

This section will assist you in pulling remote logs from Sekoia and sending them to the intake you previously created.

Go to the Sekoia playbook page.
Click on the + New playbook button at the top right of the page.
Select Create a playbook from scratch, and click Next.
Give it a Name and a Description, and click Next.
Choose a trigger from the list by searching for the name of the product, and click Create.
A new Playbook page will be displayed. Click on the module in the center of the page, then click on the Configure icon.
On the right panel, click on the Configuration tab.
Select an existing Trigger Configuration (from the account menu) or create a new one by clicking on + Create new configuration.
Configure the Trigger based on the Actions Library (for instance, see here for AWS modules), then click Save.
Click on Save at the top right of the playbook page.
Activate the playbook by clicking on the "On / Off" toggle button at the top right corner of the page.

When selecting the trigger, choose Fetch new logs on S3 (without SQS).

Before configuring the connector, retrieve the Data path from the Cisco Secure Access Amazon S3 Summary page. It looks like this:

s3://cisco-managed-eu-central-1/1234567_a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0

From this path:

the bucket name is the first segment after s3:// — here, cisco-managed-eu-central-1.
the base prefix is the second segment — here, 1234567_a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0. Cisco stores each log type in a dedicated subfolder under this prefix.

In the connector configuration, set the following fields:

AWS Region (aws_region_name): the region you selected when configuring the S3 bucket in Cisco Secure Access (for example, eu-central-1).
AWS Access Key (aws_access_key): the Access Key copied from the Cisco Secure Access Amazon S3 Summary page.
AWS Secret Access Key (aws_secret_access_key): the Secret Key copied from the Cisco Secure Access Amazon S3 Summary page.
Bucket (bucket): the bucket name extracted from the Data path (for example, cisco-managed-eu-central-1).
Prefix filter (prefix_filter): the base prefix followed by the subfolder matching the log type you want to collect. Since the bucket holds several log types, this filter ensures the connector only ingests the logs for this intake.
Intake key (intake_key): the intake key generated when you created the intake in Step 2.

Cisco Secure Access stores each log type in a dedicated subfolder under the base prefix. Set the Prefix filter to <base_prefix>/<subfolder>, using the subfolder that matches the intake you are configuring:

Intake	Subfolder	Example prefix filter
Cisco Secure Access - DNS	`dnslogs`	`1234567_a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0/dnslogs`
Cisco Secure Access - Web	`proxylogs`	`1234567_a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0/proxylogs`
Cisco Secure Access - Cloud Firewall	`firewalllogs`	`1234567_a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0/firewalllogs`
Cisco Secure Access - IPS	`intrusionlogs`	`1234567_a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0/intrusionlogs`
Cisco Secure Access - File Events	`fileeventlogs`	`1234567_a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0/fileeventlogs`

Note

Replace 1234567_a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0 with the base prefix extracted from your own Cisco Secure Access Data path.

Event Categories

The following table lists the data source offered by this integration.

Data Source	Description
`Network device logs`	None

In details, the following table denotes the type of events produced by this integration.

Name	Values
Kind	``
Category	`network`
Type	`connection`

Transformed Events Samples after Ingestion

This section demonstrates how the raw logs will be transformed by our parsers. It shows the extracted fields that will be available for use in the built-in detection rules and hunting activities in the events page. Understanding these transformations is essential for analysts to create effective detection mechanisms with custom detection rules and to leverage the full potential of the collected data.

test_cloud_firewall.json

{
    "message": "\"2024-06-14 18:59:57\",\"[211039844]\",\"Passive Monitor\",\"CDFW Tunnel Device\",\"OUTBOUND\",\"1\",\"84\",\"1.1.1.1\",\"60951\",\"3.3.3.3\",\"443\",\"ams1.edc\",\"12\",\"ALLOW\",\"example.com,apple.com\",\"44,66\",\"1718391597\",\"1718391597\",\"3\",\"3\",\"1108\",\"755\",\"39-42\",\"\",\"\",\"\",\"\",\"\",\"\",\"[]\",\"\",\"\",\"\",\"REDACTED\",\"2.2.2.2\",\"TRUE\",\"8dd4e2a7c2dba7d1\",\"\",\"\"",
    "event": {
        "action": "allow",
        "category": [
            "network"
        ],
        "dataset": "cloud-firewall",
        "end": "2024-06-14T18:59:57Z",
        "outcome": [
            "success"
        ],
        "type": [
            "connection"
        ]
    },
    "@timestamp": "2024-06-14T18:59:57Z",
    "cisco_secure_access": {
        "firewall": {
            "casi_category_ids": [],
            "content_category_ids": [
                ""
            ],
            "content_category_list_ids": [
                ""
            ],
            "data_center": "ams1.edc",
            "destination_list_ids": [
                "44",
                "66"
            ],
            "egress": true,
            "egress_ip": "2.2.2.2",
            "event_correlation_id": "8dd4e2a7c2dba7d1",
            "fqdns": [
                "apple.com",
                "example.com"
            ],
            "fw_event_id": "39-42",
            "identities": [
                "Passive Monitor"
            ],
            "identity_type": "CDFW Tunnel Device",
            "origin_ids": [
                "211039844"
            ],
            "packet_size": 84,
            "protocol": "1",
            "start_time": "2024-06-14T18:59:57.000000Z"
        }
    },
    "destination": {
        "address": "example.com",
        "bytes": 755,
        "domain": "example.com",
        "ip": "3.3.3.3",
        "packets": 3,
        "port": 443,
        "registered_domain": "example.com",
        "top_level_domain": "com"
    },
    "network": {
        "direction": "outbound"
    },
    "observer": {
        "product": "Secure Access",
        "type": "firewall",
        "vendor": "Cisco"
    },
    "organization": {
        "id": "REDACTED"
    },
    "related": {
        "hosts": [
            "example.com"
        ],
        "ip": [
            "1.1.1.1",
            "3.3.3.3"
        ]
    },
    "rule": {
        "id": "12"
    },
    "source": {
        "address": "1.1.1.1",
        "bytes": 1108,
        "ip": "1.1.1.1",
        "packets": 3,
        "port": 60951
    }
}

Extracted Fields

The following table lists the fields that are extracted, normalized under the ECS format, analyzed and indexed by the parser. It should be noted that infered fields are not listed.

Name	Type	Description
`@timestamp`	`date`	Date/time when the event originated.
`cisco_secure_access.firewall.app_id`	`keyword`	The unique application ID identified for the current session.
`cisco_secure_access.firewall.casi_category_ids`	`keyword`	Name of the Application category to which the App ID belongs.
`cisco_secure_access.firewall.content_category_ids`	`keyword`	ID of one or more content categories matched by the rule.
`cisco_secure_access.firewall.content_category_list_ids`	`keyword`	ID of one or more content category lists that include categories matched by the rule.
`cisco_secure_access.firewall.data_center`	`keyword`	The name of the data center that processed the user-generated traffic.
`cisco_secure_access.firewall.destination_list_ids`	`keyword`	The destination list IDs that Secure Access applied in the rule.
`cisco_secure_access.firewall.destination_sgt_origin_id`	`keyword`	The Security Group Tag (SGT) ID associated with the destination resource. This identifies the security group classification of the traffic destination.
`cisco_secure_access.firewall.egress`	`boolean`	TRUE indicates that the egress IP was a reserved IP.
`cisco_secure_access.firewall.egress_ip`	`ip`	The public IP address assigned to a session as it exits the Secure Access ZTA infrastructure en route to the destination application.
`cisco_secure_access.firewall.event_correlation_id`	`keyword`	A unique identifier generated for each network request, the Event Correlation ID stitches together all related events across various security services (Firewall, SWG, ZTNA) to provide a unified, end-to-end view of a single traffic flow.
`cisco_secure_access.firewall.fqdns`	`keyword`	The fully qualified domain names (FQDNs) that match the request.
`cisco_secure_access.firewall.fw_block_reason`	`keyword`	The specific reason why the firewall blocked the traffic.
`cisco_secure_access.firewall.fw_event_id`	`keyword`	The ID of the firewall event. Populated only for traffic handled by Cisco Secure Firewall.
`cisco_secure_access.firewall.identities`	`keyword`	The names of the network tunnel.
`cisco_secure_access.firewall.identity_type`	`keyword`	The type of identity that made the request.
`cisco_secure_access.firewall.origin_ids`	`keyword`	The unique identity of the network tunnel.
`cisco_secure_access.firewall.packet_size`	`long`	The size in bytes of the packet sent to the CDFW.
`cisco_secure_access.firewall.posture_id`	`keyword`	The unique ID of the endpoint posture profile.
`cisco_secure_access.firewall.private_app_group_id`	`keyword`	The unique ID of the private resource group ID that the private resource belongs to.
`cisco_secure_access.firewall.private_flow`	`boolean`	TRUE if Secure Access applied a private access rule to the user-generated traffic, and FALSE if Secure Access applied an internet access rule.
`cisco_secure_access.firewall.protocol`	`keyword`	The actual protocol of the traffic. Valid values are: TCP, UDP, or ICMP.
`cisco_secure_access.firewall.start_time`	`date`	The timestamp when the first packet of the session was received in UTC in seconds. Populated only for traffic handled by Cisco Secure Firewall.
`cisco_secure_access.firewall.traffic_source`	`keyword`	The source of the user-generated traffic.
`cloud.region`	`keyword`	Region in which this host, resource, or service is located.
`destination.bytes`	`long`	Bytes sent from the destination to the source.
`destination.domain`	`keyword`	The domain name of the destination.
`destination.geo.country_iso_code`	`keyword`	Country ISO code.
`destination.ip`	`ip`	IP address of the destination.
`destination.packets`	`long`	Packets sent from the destination to the source.
`destination.port`	`long`	Port of the destination.
`event.action`	`keyword`	The action captured by the event.
`event.category`	`keyword`	Event category. The second categorization field in the hierarchy.
`event.dataset`	`keyword`	Name of the dataset.
`event.end`	`date`	event.end contains the date when the event ended or when the activity was last observed.
`event.type`	`keyword`	Event type. The third categorization field in the hierarchy.
`network.direction`	`keyword`	Direction of the network traffic.
`network.transport`	`keyword`	Protocol Name corresponding to the field `iana_number`.
`observer.product`	`keyword`	The product name of the observer.
`observer.type`	`keyword`	The type of the observer the data is coming from.
`observer.vendor`	`keyword`	Vendor name of the observer.
`organization.id`	`keyword`	Unique identifier for the organization.
`rule.id`	`keyword`	Rule ID
`source.bytes`	`long`	Bytes sent from the source to the destination.
`source.ip`	`ip`	IP address of the source.
`source.packets`	`long`	Packets sent from the source to the destination.
`source.port`	`long`	Port of the source.

For more information on the Intake Format, please find the code of the Parser, Smart Descriptions, and Supported Events here.

Detection section

The following section provides information for those who wish to learn more about the detection capabilities enabled by collecting this intake. It includes details about the built-in rule catalog, event categories, and ECS fields extracted from raw events. This is essential for users aiming to create custom detection rules, perform hunting activities, or pivot in the events page.

The following Sekoia.io built-in rules match the intake Cisco Secure Access - Cloud Firewall. This documentation is updated automatically and is based solely on the fields used by the intake which are checked against our rules. This means that some rules will be listed but might not be relevant with the intake.

SEKOIA.IO x Cisco Secure Access - Cloud Firewall on ATT&CK Navigator

Burp Suite Tool Detected

Burp Suite is a cybersecurity tool. When used as a proxy service, its purpose is to intercept packets and modify them to send them to the server. Burp Collaborator is a network service that Burp Suite uses to help discover many kinds of vulnerabilities (vulnerabilities scanner).

Effort: intermediate

Correlation Potential DNS Tunnel

Detects domain name which is longer than 62 characters and requested at least 50 times in a 10 minutes range time. Long domain names are distinctive of DNS tunnels.

Effort: advanced

Cryptomining

Detection of domain names potentially related to cryptomining activities.

Effort: master

Dynamic DNS Contacted

Detect communication with dynamic dns domain. This kind of domain is often used by attackers. This rule can trigger false positive in non-controlled environment because dynamic dns is not always malicious.

Effort: master

EvilProxy Phishing Domain

Detects subdomains potentially generated by the EvilProxy adversary-in-the-middle phishing platform. Inspect the other subdomains of the domain to identify the landing page, and determine if the user submitted credentials. This rule has a small percentage of false positives on legitimate domains.

Effort: intermediate

Exfiltration Domain

Detects traffic toward a domain flagged as a possible exfiltration vector.

Effort: master

Internet Scanner

Detects known scanner IP addresses. Alert is only raised when the scan hits an opened port, on TCP or UDP. This could be a very noisy rule, so be careful to check your detection perimeter before activation.

Effort: master

Internet Scanner Target

Detects known scanner IP addresses. Alert is only raised when the scan hits an opened port, on TCP or UDP and group by target address. This could be a very noisy rule, so be careful to check your detection perimeter before activation.

Effort: master

Potential DNS Tunnel

Detects domain name which is longer than 62 characters. Long domain names are distinctive of DNS tunnels.

Effort: advanced

Remote Access Tool Domain

Detects traffic toward a domain flagged as a Remote Administration Tool (RAT).

Effort: master

Remote Monitoring and Management Software - AnyDesk

Detect artifacts related to the installation or execution of the Remote Monitoring and Management tool AnyDesk.

Effort: master

Remote Monitoring and Management Software - Atera

Detect artifacts related to the installation or execution of the Remote Monitoring and Management tool Atera.

Effort: master

SEKOIA.IO Intelligence Feed

Detect threats based on indicators of compromise (IOCs) collected by SEKOIA's Threat and Detection Research team.

Effort: elementary

Sekoia.io Activity Logs Rule Deactivation Bulk

Detects a massive rule deactivation observed threw Sekoia.io activity logs.

Effort: master

Sekoia.io EICAR Detection

Detects observables in Sekoia.io CTI tagged as EICAR, which are fake samples meant to test detection.

Effort: master

Suspicious TOR Gateway

Detects suspicious TOR gateways. Gateways are often used by the victim to pay and decrypt the encrypted files without installing TOR. Tor intercepts the network traffic from one or more apps on user’s computer, usually the user web browser, and shuffles it through a number of randomly-chosen computers before passing it on to its destination. This disguises user location, and makes it harder for servers to pick him/her out on repeat visits, or to tie together separate visits to different sites, this making tracking and surveillance more difficult. Before a network packet starts its journey, user’s computer chooses a random list of relays and repeatedly encrypts the data in multiple layers, like an onion. Each relay knows only enough to strip off the outermost layer of encryption, before passing what’s left on to the next relay in the list.

Effort: advanced

TOR Usage

Detects TOR usage, based on the IP address and the destination port (filtered on NTP). TOR is short for The Onion Router, and it gets its name from how it works. TOR intercepts the network traffic from one or more apps on user’s computer, usually the user web browser, and shuffles it through a number of randomly-chosen computers before passing it on to its destination. This disguises user location, and makes it harder for servers to pick him/her out on repeat visits, or to tie together separate visits to different sites, this making tracking and surveillance more difficult. Before a network packet starts its journey, user’s computer chooses a random list of relays and repeatedly encrypts the data in multiple layers, like an onion. Each relay knows only enough to strip off the outermost layer of encryption, before passing what’s left on to the next relay in the list.

Effort: master

TOR Usage Generic Rule

Detects TOR usage globally, whether the IP is a destination or source. TOR is short for The Onion Router, and it gets its name from how it works. TOR intercepts the network traffic from one or more apps on user’s computer, usually the user web browser, and shuffles it through a number of randomly-chosen computers before passing it on to its destination. This disguises user location, and makes it harder for servers to pick him/her out on repeat visits, or to tie together separate visits to different sites, this making tracking and surveillance more difficult. Before a network packet starts its journey, user’s computer chooses a random list of relays and repeatedly encrypts the data in multiple layers, like an onion. Each relay knows only enough to strip off the outermost layer of encryption, before passing what’s left on to the next relay in the list.

Effort: master

Telegram Bot API Request

Detects suspicious DNS queries to api.telegram.org used by Telegram Bots of any kind

Effort: advanced