Jaacostan

Cisco Firepower Threat Defense(FTD) NGFW: An Administrator's Handbook : A 100% practical guide on configuring and managing Cisco FTD using Cisco FMC and FDM. This book is written like a learning course, explained in detail with a lab topology using FTDv and FMCv. This is a 100% practical guide on configuring and managing Cisco Firepower Threat Defense Next Generation Firewall using Cisco Firepower Management Center. I have also covered the standalone firewall introduction and how to use Firepower Device Manager to manage your FTD firewall locally without using FMC. Covers , •How to upgrade ASA firewall to Cisco FTD (Migration and Upgrade) •Configure Cisco Firepower Threat Defense (FTD) Next Generation firewall •Configure Cisco Firepower Management Center (FMC) •Manage and administer the FTD devices using FMC ( Configure interfaces, zones, routing, ACLs, Prefilter policies, NAT, High Availability etc) • FTD local management using Firepower Device Manager (FDM) •Introduction

A Playbook is a set of tasks that will be executed for a specified incident and run like a flow chart. This enable the organization to automate many of the security processes, such as incident response, data collection, investigation, closure etc. You can structure and automate security responses that were previously handled manually and thereby saving time and increasing the efficiency of your Incident Response plan and operations. You can create a new playbook from the Playbook option in the Cortex XSOAR GUI. As i mentioned above, a playbook is a set of tasks and each of the tasks can be classified in to various types based on the function or action. Each types are marked with specific icons. The meaning of those icons are mentioned below. All Playbooks begins with a Section Header, which signifies the title. 1) Standard Automated Task : The arrow and the lightning bolt indicate a standard automated task. No analyst intervention is required for automated tasks.   2) Manual Task : Th

After Installing Palo Alto Cortex XSOAR, it is recommended to perform a post-installation health check. As per Palo Alto documentation, the following tests has to be performed. 1) Check the Docker Sub-system   /docker_images : Verify that either a list of Docker images or an empty list is returned. Can run this command from the playground.  ! py script="demisto.results('hello world')" : Verify that hello world is returned, if not, there may be issues with your docker installation. Can run this command from the playground.      sudo docker info : Check for warnings or errors. 2) Verify Integration Tests Create an instance of each of the following integrations and test each of these integrations by clicking the Test button in the integration instance. You can also optionally run associated commands in the playground. Sample integration installation of ipinfo is shown below.      urlscan.io     ipinfo     PhishTank     OpenPhish     Rasterize Also, run !FailedInstanc

After installing Palo Alto Cortex XSOAR, you might go through the health check. During health check you will go through a serious of integration/instance testing to check the functionalities. In the XSOAR platform, one of the basic tool an analyst will use is urlscan . And you are probably here reading this post because you might also encountered an error while running the URLscan related commands.  So during my testing, i ran the command to check the reputation of my URL and it returned the following error. Scripts returned an error urlscan.io returned an error. Error in API call to URLScan.io [403] - Forbidden: Anonymous API submissions are not permitted by our platform. This is because of the absence of API key in the instance. To fix this, you need to get an API key from urlscan.io and provide the key within the XSOAR urlscan.io instance. You may create a free account in urlscan.io and get the API key for free. Once you have created the API key, copy the key. You need to provide th

An incident in Palo Alto Cortex XSOAR can be created automatically or manually by a Security Analyst. Similarly, all the process mentioned below can be performed manually as well as automatically by initiating the playbook, when a particular condition is met. In order to create an incident automatically by the Cortex XSOAR, you need to configure integrations with your 3rd-party products such as SIEM, ticketing tools, logs servers, network devices, EDR etc to start fetching events. Then you have to determine how the events ingested from those integrations will be classified as incidents. This is known as Classification Mapping. Then you create the pre-processing rules that enable you to perform certain actions on incidents as they are ingested into Cortex XSOAR. The entire process from an incident getting created till to the Closure/Archiving is explained below. The lifecycle of an XSOAR managed incident consists of five phases: Creation Pending investigation Active investigation and re

You can deploy Palo Alto Cortex XSOAR in four ways.  1) On-Premises You can install Cortex XSOAR on a VM or bare-metal servers. In this installation model, the customer provisions, installs, configures, and maintains all aspects of the system while Palo Alto Networks provides support based on licensing. As of now, installation of Cortex XSOAR on CentOS, RedHat Enterprise Linux, Ubuntu, Oracle Linux, Amazon Linux 2, SUSE Linux Enterprise 12, openSUSE, and Fedora is supported.   2) Hosted Cloud In this model, Palo Alto Networks provisions and maintains the customer’s instance of the Cortex XSOAR server, which includes maintaining the OS, performing upgrades, providing high availability. The customer only needs to configure and maintain the Cortex SOAR from an application-layer level. Palo Alto Networks provides application support based on the license purchased. Only the Palo Alto Networks DevOps team has access to the OS. The cloud-hosted option is not a full security-as-a-service offer

As you may all know, the ESXi host comes with an inbuild firewall similar to firewalld in Linux or Windows inbuilt Firewall and the ESXi firewall is enabled by default. You can configure incoming and outgoing firewall connections for a service or a management agent from the vSphere Client or at the command line. But to define a custom firewall port for a service needs to be performed at the command line. This article will help you to create a custom firewall ruleset in ESXi 6.x for any service. Here we take an Example of Syslog . You can refer the below article to know how to configure the syslog in ESXi which leverage the default syslog ports (TCP/UDP 514, 1514) as seen below. https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.esxi.upgrade.doc/GUID-9F67DB52-F469-451F-B6C8-DAE8D95976E7.html -- Important point to remember that once you specify a custom port number in the above config, the logs will not be sent via the port until you create the ESXi custom firewall rule set.