As part of the export process you will be asked to input "scope". In LogScale's package system, a scope is essentially a namespace that allows multiple parties to create a package with the same name while avoiding naming collisions. If for instance you create a packages called accesslog-parsers it would be namespaced under your registry scope (essentially username), allowing for packages to be named:

tomcat/accesslog-parsers
nginx/accesslog-parsers
dilbert/accesslog-parsers

$schema: https://schemas.humio.com/manifest/v2.0.0
name: nginx/nginx # <scope>/<name>
description: |
  This is a brief description of the package. One or two lines.
author:
  name: Thomas Anagrius
  email: thomas@humio.com
logoUrl: data:image/png;base64,...
contributors:
  - Peter Johnson <john@example.com>
  - John Doe <john@example.com>

The logoUrl should be a base64 encoded version of the logo for the package (usually technology logo).

(this should be the name of the package but may include a couple of extra words if it help provide a meaningful title, must be less than 40 characters)

Underneath the title there should be a description of what it does and why. Focus on what log sources does it apply to, what data does it use and what does it show from that data. Make it really clear as to what the purpose of the package is.You can include links to external websites as long as they are directly relevant and help explain the package or add context. You can include links to LogScale's documentation library to explain concepts and provide technical details or helpful tips.

List which of below are included. (you can include a description of each component if you wish but limited to 100 characters each. All packages need to include the required parsers. This may change in the future but for now a working parser must be included (it can be subject to dependencies as listed in the dependencies section below).

Use Case: (list all that apply from the selection of DevOps, SecOps, ITOps, IoT/OT)

Technology Vendor: (list of vendors supported by package) e.g. AWS (Amazon Web Services) or Cisco.

Dependencies:

Installation:

Instructions on how to ingest the data and how to install and use the package. Must include any required configuration in external systems such as log sources as well as explaining any optional configurations or choices that need to be made. These should be summary instructions with a link to the LogScale documentation library and the specific integration step by step instructions.

If your package is a collection of template files for a specific technology, a short description is usually enough.

If your package is an application, it should also explain:

The README cannot currently contain images or HTML tags. We plan on easing this restriction to allow images that have been vetted by LogScale and hosted on servers hosted by LogScale.

## Corelight Threat Hunting Guide

This package contains alerts and saved searches that use Zeek (aka
Bro) data from Corelight network sensors. The package contains around
60 different alerts/searches that are useful when threat hunting
within Corelight data to detect potentially suspicious activity. This
package is intended to accompany the [Corelight Threat Hunting
Guide](https://www3.corelight.com/corelights-introductory-guide-to-threat-hunting-with-zeek-bro-logs).

The guide provides an excellent introduction to threat hunting with
Corelight data and is aligned to the Mitre ATT&CK framework
(v6). Corelight provides a rich source of logs for threat hunters and
is capable of detecting a large range of attacker tactics and
techniques. The name of each alert/search includes the relevant Mitre
ATT&CK tactic and techniques (as names and references codes). When
threat hunters are reading the Corelight guide they can search the
LogScale package based on tactic and technique names or numbers to
find the relevant LogScale searches/alerts and simply click to run
those searches.

The Corelight Threat Hunting Guide explains what to look for, this
package shows you how.  For more information on how Corelight can
provide valuable data for your security operations please visit
www.corelight.com

## Package Contents
- Parser for Corelight JSON data
- Saved Searches
- Alerts (with no action defined)

## Use Case
- SecOps

## Technology Vendor
Corelight

## Support
Supported by LogScale and Corelight. https://support.humio.com/ and support@corelight.com

## Dependencies
> The parser included assumes data is sent from Corelight in JSON format.

The package uses logs from the following log files from Corelight (all
suffixed with .log): `conn`, `dce_rpc`, `dnp3`, `dns`, `files`,
`http`, `kerberos`, `modes`, `notice`, `rdp`, `smb_files`,
`smb_mapping`, `smtp`, `ssh`, `ssl`, `weird`. Please make sure all
these log types are sent to LogScale as otherwise some of the
searches/alerts may not work.

## Installation

The preferred option for sending logs from Corelight to LogScale is to
choose 'Export to Splunk HEC' (available under the Sensor-> Export
menu in the Corelight management interface). For 'HEC URI', enter your
LogScale service URL appended with `/api/v1/ingest/hec`
(e.g. `https://cloud.humio.com/api/v1/ingest/hec`) For further
information on using the LogScale HEC see [the
documentation](https://docs.humio.com/docs/ingesting-data/data-shippers/hec/).

Installing the package will automatically deploy the `corelight-json`
parser, saved searches, and alerts directly into the repository you
install the package into.

You will need to link the parser to an ingest token within LogScale.

If you have already installed the `corelight-json` parser as part of
the `corelight/sensor` package then you can use this existing parser
as it is identical to the `corelight-json` parser in this
package.