[cdo@sdc-vm ~]$ sudo su sdc
[sudo] password for cdo: <type password for cdo user>
[sdc@sdc-vm ~]$

[sdc@sdc-vm ~]$ /usr/local/cdo/toolkit/sec.sh setup

Please copy the bootstrap data from Setup Secure Event Connector page of Security
                                            Cloud Control: KJHYFuYTFuIGhiJKlKnJHvHfgxTewrtwE
RtyFUiyIOHKNkJbKhvhgyRStwterTyufGUihoJpojP9UOoiUY8VHHGFXREWRtygfhVjhkOuihIuyftyXtfcghvjbkhB=

After the SEC is onboarded, the sec.sh runs a script to check on the health of the SEC. If all the health checks are "green," the health check sends a sample event to the Event Log. The sample event shows up in the Event Log as a policy named "sec-health-check."

If you receive a message that the registration failed or that the SEC onboarding failed, go to Troubleshooting Secure Event connector Onboarding Failures.

• If you installed your SDC on your own virtual machine, continue with Additional Configuration for SDCs and Security Cloud Control Connectors Installed on a VM You Created.

• If you installed your SDC using a Security Cloud Control image, continue to "What to do Next."

When prompted, enter the SEC bootstrap data that you have copied..

Ports to connect to the SDC instance using SSH are not exposed for secuirty reasons.

rm -f /tmp/cert_chain.pem && openssl s_client -showcerts -verify 5 -connect <FQDN>:10125 < /dev/null | awk '/BEGIN CERTIFICATE/,/END CERTIFICATE/{ if(/BEGIN CERTIFICATE/){a++}; out="/tmp/cert_chain.pem"; if(a > 1) print >>out}'

nslookup <FQDN>

DataCenterFW-1> en
Password: *****************
DataCenterFW-1# conf t
DataCenterFW-1(config)# <paste your modified ASA CLIs here and press Enter>
DataCenterFW-1(config)# wr mem
Building configuration...
Cryptochecksum: 6634f35f 4c5137f1 ab0c5cdc 9784bdb6

• If you want to use the tenant selector (or if there’s only one tenant on the VM):

  [sdc@tenant toolkit]$ sdc eventing delete

• If you want to specify the tenant directly in the command arguments:

  [sdc@tenant toolkit]$ sdc eventing delete CDO_{tenant-name} 

The increased cost will be pro-rated based for the term remaining on your existing license. See the Guidelines for Quoting Cisco Defense Orchestrator Products for detailed instructions.

The Alerts and Notifications section displays alerts about the settings that impact event logging, enabling you to take action to resolve any issues. Some of these settings include:

• Sending events to cloud setting is disabled.

• Sending events to the cloud setting is disabled at device level.

• Secure Event Connector becomes unavailable.

• Increase in events ingestion rate.

• Usage Trends: Displays the event logging storage usage for the last 12 months. Hover over a bar to see the data usage for the corresponding month.

• Events per second (EPS) trends: Displays the event ingest rate for the onboarded devices. Customize your events per second trends view for a specific time period or for a specific device to get more granular data. You can filter the data for the last 1 week, 2 weeks, 3 weeks, or 1 month.

  Note	The device drop-down list displays the managed firewall devices that are sending events to the Cisco Security Cloud.

• Utilization by event type trends: Displays event data storage used, in bytes per day, for different event types. Use this widget to monitor storage use by event types and identify surges, if any, or unusual changes in storage use for specific event types. This insight enables you to adjust logging settings for a specific event type and manage storage use.

• Utilization by device type trends: Displays event data storage used, in bytes per day, for each managed device type. Use this widget to monitor storage use by the device type and identify surges, if any, or unusual changes in storage use for a specific type of device.

• Utilization by device trends: Displays event data storage used, in bytes per day, for each security device that sends events to Security Cloud Control. This widget focuses on devices with storage use exceeding the average bytes per second value, showing only the top five devices to improve usability. Use this widget to monitor storage use for each device and identify surges or unusual changes. This insight allows you to adjust logging settings for specific devices and manage storage use effectively.

Use the logging host command to specify the SEC as the syslog server you send messages to. You can send events to any one of the SECs you have onboarded to your tenant.

The logging host command specifies a TCP or UDP port to send events to. See Finding Your Device's TCP, UDP, and NSEL Port Used for Cisco Security Analytics and Logging to determine what ports you should use.

Turn this command into one of two different macros depending on what protocol you use to send syslog events to the SEC:

logging host {{interface_name}} {{SEC_ip_address}} tcp/{{port_number}}

logging host {{interface_name}} {{SEC_ip_address}} udp/{{port)_number}}

(Optional) If you use TCP, you can add this command to your list of commands in your macro. It does not need any parameters.

logging permit-hostdown

Use the logging trap command to specify which syslog messages should be sent to the syslog server:

If you want to define the events sent to the SEC by severity level, turn the command into this macro:

logging trap {{severity_level}}

If you only want to send events to the SEC that are part of a message list, turn the command into this macro:

logging trap {{message_list_name}}

If you chose the logging trap message_list command in the previous step, you need to define the syslogs in your message list. Open Create a Custom Event List so you can read the command descriptions as you create the macro. Start with this command:

And break it down into these variations:

logging list {{message_list_name}} level {{security_level}}

logging list {{message_list_name}} level {{security_level}} class {{message_class}}

logging list {{message_list_name}} message {{syslog_range_or_number}}

In the last variation, the message parameter {{syslog_range_or_number}} could be entered as a single syslog ID, 106023, or a range, 302013-302018. Use one or more of the command variations in as many lines as you like to create your message list. Keep in mind that, in a single macro, all parameters with the same name will use the same value you enter. Security Cloud Control will not run a macro with empty parameters.

logging timestamp

 <166>2018-06-27T12:17:46Z asa : %ASA-6-110002: Failed to locate egress interface for protocol from src interface :src IP/src port to dest IP/dest port

And break it down into these variations:

logging device-id cluster-id

logging device-id context-name

logging device-id hostname

logging device-id ipaddress {{interface_name}} system

logging device-id string {{text_16_char_or_less}}

logging enable

show running-config logging

write memory

After entering every command, you will click Send. Because Security Cloud Control's CLI Interface is a direct connection to the ASA, the command is written to the device's running configuration immediately. For changes to be written to the ASA's startup configuration, you need to issue the write memory command in addition.

When sending syslog events from the ASA to the Cisco cloud, you forward them to the SEC as if it were an external syslog server, and it forwards the messages to the Cisco cloud.

To send syslog messages to the SEC, perform the following steps:

1. Configure the ASA to send messages, using TCP or UDP, to the SEC as if it were a syslog server. The SEC can use an IPv4 or IPv6 addresss. You will be sending events to either a TCP or UDP port. See Finding Your Device's TCP, UDP, and NSEL Port Used for Cisco Security Analytics and Logging to determine what ports you should use.

   Here is an example of the logging host command syntax:

   logging host interface_name SEC_IP_address [[ tcp/port ]|[ udp/port ]]

   Examples:

   
    > logging host mgmt 192.168.1.5 tcp/10125 
   > logging host mgmt 192.168.1.5 udp/10025 
   > logging host mgmt 2002::1:1 tcp/10125 
   > logging host mgmt 2002::1:1 udp/10025 

   • The interface_name argument specifies the ASA interface from which messages are sent to the syslog server. It is a "best practice" to send the syslog messages to the SDC over the same ASA interface already in use for communication with the SDC.

   • The SEC_IP_address argument should contain the IP address of the VM on which the SEC is installed.

   • The tcp/port or udp/port keyword-argument pair specifies that syslog messages should be sent using either TCP protocol and relevant port, or the UDP protocol and relevant port. You can configure the ASA to send data to a syslog server using either UDP or TCP, but not both. The default protocol is UDP if you do not specify a protocol.

     If you specify TCP, the ASA will discover syslog server failures and as a security protection, new connections through the ASA are blocked. To allow new connections regardless of connectivity to a TCP syslog server, see step b. If you specify UDP, the ASA continues to allow new connections whether or not the syslog server is operational. Valid port values

     Note	If you want to send ASA messages to two separate syslog servers, you can run a second logging host command with the appropriate interface, IP address, protocol and port of the other syslog server.

2. (Optional) If you send events to the SEC over TCP, and if either the SEC is down or the log queue on the ASA is full, then new connections are blocked. New connections are allowed again after the syslog server is back up and the log queue is no longer full. To allow new connections regardless of connectivity to a TCP syslog server, disable the feature to block new connections when a TCP-connected syslog server is down using this command:

   logging permit-hostdown

   Example:

    > logging permit-hostdown 

Examples:

> logging trap 3 
> logging trap asa_syslogs_to_cloud 

You can specify the severity level number (1 through 7) or name. For example, if you set the severity level to 3, then the ASA sends syslog messages for severity levels 3, 2, and 1.

The message_list argument is replaced with the name of a custom event list, if you have created one. When specifying a custom event list, you only send the syslog messages that are in that list to the Secure Event Connector. In the example above, asa_syslogs_to_cloud is the name of the event list.

Using a message_list could save you money by tightly defining which syslog messages are sent to the Cisco cloud.

See Create a Custom Event List to create a message_list. See Security Analytics and Logging Event Storage for more information about data ingest and storage costs.

Add the date and time that the syslog message originated on the ASA to the message using the logging timestamp command. The timestamp value is displayed in the SyslogTimestamp field.

Example:

> logging timestamp 

<166>2018-06-27T12:17:46Z asa : %ASA-6-110002: Failed to locate egress interface for protocol from src interface :src IP/src port to dest IP/dest port. 

A device ID is an identifier you can insert in a syslog message that will help you easily distinguish all syslog messages sent from a particular ASA. See Include the Device ID in Non-EMBLEM Format Syslog Messages for instructions.

When an access control rule denies access to a resource, the event is automatically logged. If you also want to log events generated when an access control rule allows access to a resource, you need to turn on logging for the access control rule and configure a severity type. See Log Rule Activity for instructions on how to turn on logging for an individual network access control rule.

At the command prompt, type logging enable. On the ASA, logging is enabled for the entire device, not for individual rules.

Example:

 > logging enable 

At the command prompt, type write memory. On the ASA, logging is enabled for the entire device, not for individual rules.

Example:

> write memory 

The name argument specifies the name of the list. The level level keyword and argument pair specify the severity level. The class message_class keyword-argument pair specify a particular message class. The message start_id [-end_id] keyword-argument pair specify an individual syslog message number or a range of numbers.

• Add syslog messages to the event list based on severity. For example, if you set the severity level to 3, then the ASA sends syslog messages for severity levels 3, 2, and 1.

  Example:

  > logging list asa_syslogs_to_cloud level 3 

• Add syslog messages based on other criteria to the event list:

  Enter the same command as in the previous step, specifying the name of the existing message list and the additional criterion. Enter a new command for each criterion that you want to add to the list. For example, you can specify criteria for syslog messages to be included in the list as the following:

  • Syslog message IDs that fall into the range of 302013-302018.

  • All syslog messages with the critical severity level or higher (emergency, alert, or critical).

  • All HA class syslog messages with the warning severity level or higher (emergency, alert, critical, error, or warning).

    Example:

    > logging list asa_syslogs_to_cloud message 302013-302018 
    > logging list asa_syslogs_to_cloud level critical 
    > logging list asa_syslogs_to_cloud level warning class ha 

    Note	A syslog message is logged if it satisfies any of these conditions. If a syslog message satisfies more than one of the conditions, the message is logged only once.

At the command prompt, type write memory.

Example:

> write memory

Example:

> logging device-id hostname 
> logging device-id context-name 
> logging device-id string Cambridge 

The context-name keyword indicates that the name of the current context should be used as the device ID (applies to multiple context mode only). If you enable the logging device ID for the admin context in multiple context mode, messages that originate in the system execution space use a device ID of system, and messages that originate in the admin context use the name of the admin context as the device ID.

The cluster-id keyword specifies the unique name in the boot configuration of an individual ASA unit in the cluster as the device ID.

The hostname keyword specifies that the hostname of the ASA should be used as the device ID.

The ipaddress interface_name keyword-argument pair specifies that the interface IP address specified as interface_name should be used as the device ID. If you use the ipaddress keyword, the device ID becomes the specified ASA interface IP address, regardless of the interface from which the syslog message is sent. In the cluster environment, the system keyword dictates that the device ID becomes the system IP address on the interface. This keyword provides a single, consistent device ID for all syslog messages that are sent from the device.

The string text keyword-argument pair specifies that the text string should be used as the device ID. The string can include as many as 16 characters.

You cannot use blank spaces or any of the following characters:

• & (ampersand)

• ‘ (single quote)

• " (double quote)

• < (less than)

• > (greater than)

• ? (question mark)

At the command prompt, type write memory.

Example:

  > write memory 

In the output of the example below, global_policy is the name of the global policy.

Example:

> show running-config service-policy

service-policy global_policy global