About chrking

Does the email reply from XSOAR need to be strictly a reply to the original email?   If not, using an (email) data collection task for this the simplest and easiest way to achieve this. ... View more

If you try running the mirror manually with the debug commands listed here https://xsoar.pan.dev/docs/integrations/mirroring_integration#debugging like get-modified-remote-data do you get any useful output?   Do you have offenses newer than your configured First fetch timestamp parameter? ... View more

Hmm, when I try with a filter I get similar test output and it works.   I was able to get this error: "Failed converting file. General exception: failed to get artifact file path, invalid file (52)" by manually deleting the referenced files from /var/lib/demisto/artifacts - can you check that directory to make sure the expected files are still there? ... View more

What error are you getting? ConvertFile can handle multiple files of different types with no issues (just tested on my instance), so if there's an issue with what you've got it seems likely it's in the Filter/Transformer section.   I note that your "Where" section seems to be missing an OR before the final entry.   What do you get if you use the Filter/Transformer test panel with context from an incident? ... View more

For nslookup, you can use the GetDomainDNSDetails automation.   For threat vault info you can use the threat vault integration: https://cortex.marketplace.pan.dev/marketplace/details/PaloAltoNetworks_Threat_Vault/ although if you have generic details (URL, IP, file hash etc) you could also query those through multiple sources through the standard url/ip/file commands. ... View more

1) No, it will use the same license as your active server 2) If by "in real time" you mean "continuously in an ongoing basis" then yes. Obviously the data takes time to travel between the active and standby, and it also takes some time to be written to DB on the standby but those should be the only delays. 3) If your active goes offline and you make the standby active without converting the old-active to standby first then the old-active will need to be wiped and manually reconfigured before it can be used again. See https://docs.paloaltonetworks.com/cortex/cortex-xsoar/6-5/cortex-xsoar-admin/disaster-recovery-and-live-backup/configure-the-live-backup-environment/dr-secnario-unrecoverable-active-server-failure for details. ... View more

Live Backup requires manual failover and therefore cannot provide seamless HA. IMHO having a second host on the main site adds nothing to this configuration above and beyond what the secondary site host already adds.   The way I see it you basically have three choices: 1) Live Backup with 1 host at each site, on the understanding that manual failover is required and this will cause some limited downtime when failover is required. Additionally you need to understand that in the event of a break-glass failover (ie, unable to configure the main site to gracefully become standby), you will need to rebuild your main site host. This has the most disadvantages, but also the least hardware requirements and simplest configuration.   2) HA with geographically close secondary site - if your secondary site is sufficiently close that you can realistically expect network round trip times of <= 10ms, you can deploy an HA configuration with an Elastic cluster that spans both sites. You'll need to configure your elastic settings ensure that data is stored on both sites. I would strongly suggest having a skilled elastic search administrator for this, because most of the cross-site redundancy configuration is out-of-scope of the XSOAR documentation.   3) Single site HA, with Elastic backups to your secondary site. If your main site is destroyed you'll be building new servers on the secondary site to get running again (so, relatively long downtime), but there's no latency requirements and this will still provide good protection against single-host hardware failures.   I hope that helps.   ... View more

HA and Live Backup are mutually exclusive. If you use one, you can't use the other. Live Backup is sometimes referred to as "DR" because it is intended to be used for disaster recovery, but disaster recovery is a more general concept and not restricted to any one specific technology or architecture.   Disaster Recovery as a general concept generally has levels depending on what you're trying to protect against. Are you trying to protect against a single server failure? A partial data center outage (eg, one rack, one row, etc)? A complete data center outage? A wide ranging major disaster that destroys all data centers in a geographical region?   HA will protect just fine against a single server failure assuming everything is configured correctly and you have sufficient ES nodes. It could protect against partial data center outages if you're careful about your placement of nodes. For anything further, you'd need to carefully consider the inter-node latency, as excessive latencies will cause performance issues. In this situation, taking ES backups and storing them in geographically dispersed locations would allow you to set up a new environment in another location without losing all of your data. Depending on your requirements that may be a sufficient DR plan as the kinds of wide-ranging disasters that would necessitate this are generally infrequent.   Live Backup doesn't have the same latency requirements so you can deploy the standby server further away without issue, assuming you still have sufficient bandwidth. If you use Live Backup, the standby server essentially *is* your disaster recovery plan - manually fail over to it, update any DNS etc that's required and your DR plan is fulfilled. It's not clear to me why you think you need more than a single Live Backup server to provide DR. ... View more

The problem with sites like these is that they're not intended for bulk use. They generally don't have an API, so any integration you create is going to be fragile and potentially break on any website changes. Using them within your XSOAR may also be against their TOS/EULA/etc. If possible I'd suggesting reaching out to these providers to see if they have a service with an API intended for bulk use that references the same data instead.   For the technical part of your question: Your integration needs to return an indicator result with a score. See https://xsoar.pan.dev/docs/integrations/context-and-outputs#return-ip-reputation for reference. Where you have multiple integrations which return results, the rules described here: https://docs.paloaltonetworks.com/cortex/cortex-xsoar/6-5/cortex-xsoar-admin/manage-indicators/understand-indicators/indicator-reputation will apply. ... View more

Looping through every element of the list is possible with subplaybooks, but likely not the best approach here.   For this kind of a use case, I'd recommend: * Configure a Generic Export Indicators integration instance https://xsoar.pan.dev/docs/reference/integrations/edl * Configure the query on the integration to find IP addresses which match a custom tag and are not expired * To block an IP address, add the custom tag and set the expiry to <current time>+48 hours * Configure the firewall to use the URL of the integration as an EDL.   With this method XSOAR should do the expiry for you without any kind of job and the firewall config is just a once-off EDL setup. ... View more

The systemctl status doesn't have enough information to tell what's wrong. I'd suggest looking for more detailed logs under /var/log/demisto (esp. server.log) for a better idea of what the actual error is. ... View more

Just to clarify: Indicator enrichment and indicator feeds are different things which serve different purposes.   Indicator enrichment queries for information about a specific indicator, and then adds that information to XSOAR. Think of this as a "pull" type method, where specific information is "pulled" on request. XSOAR needs to know what indicator to request in order to do enrichment.   Indicator feeds are just a list of indicators which meet specific criteria for inclusion. Usually the condition is just that they're malicious, but there are exceptions (Cloud provider IP address feeds, top website lists, etc). Think of this as a "push" method - XSOAR just requests "all indicators" or "all new indicators" and the feed sends whatever it deems appropriate, without XSOAR requesting any specific indicator.   Indicator enrichments and feeds are both done through integrations, but the features that the integration needs to implement for each are different, and the way the results are used are usually different.   I'd suggest starting with the marketplace ( https://xsoar.pan.dev/marketplace ) to see if there is already an integration for the sources that you use. If there is not, then you could either create one (see https://xsoar.pan.dev/docs/tutorials/tut-integration-ui ) or you could consider switching to a threat intel provider with a pre-built integration. ... View more