It is very hard to write rules or improve the mapping coverage without either having sample data e.g. shell change because a new log file location or data_type needs to be queried, there is only an addition needed in the configuration file, every rule that is referring to that service, will automatically pull that in and look at the correct places. The idea is that if you the locations for a specific service, e.g. (data_type:("apt\:history\:line" OR "bash\:history\:command") AND "*whoami*") Service: in most cases again the Name of the sourceĬonditions: a set of conditions that will be translatedįor example the following combination of rule / configuration: Logsources : Each logsource has a name and the following sub sections. Within the configuration file, there are the following sections:īackends : set of backends that this configuration is supposed to serve, e.g. For Timesketch, the Sigma configuration is available from Github. There is a set of configuration files provided by the Sigma project on Github. The configuration can be used to create different mappings of Sigma key names to those provided by the backend. Different Sigma configurations can be used for different backends. This is the central configuration file for the Sigma engine. Usually a combination of product and service.ĭetection : one or more selectors, timeframe and conditions (best is to look for already existing rules to get an idea of what is possible)įalsepositives : Description field to explain which events or situations might trigger that rule Logsource : This is used to scope the searches, several combinations are possible and are determined by mapping in the sigma config yaml. Level : Severity level one of “low”, “medium”, “high” or “critical” Reference : URL of a blogpost or other reference documentsĪuthor : it is a good practice to add a name and or email in here to be able to trace back who initially wrote the rule ĭescription : free form text to further explain the context of the rule Some examples for Sigma rules can be found at the Sigma project Github repository. an URL to additional information like a blogpost. Every Sigma rule also specifies some sort of metadata like author, a unique rule identifier (UUID) and references, e.g. Either the system itself is capable of translating the rule in its own language or Sigma can be used to translate it to a language the system supports.Ī Sigma rule is written in YAML and defines the what and the where to look in system logs. The idea behind it is to have a generic specification to define a situation a system wants to detect. Sigma, the " Yara for SIEMs (Security information and event management) " is an “open signature format” (pattern matching rule definition language). This is outlined in MITRE ATT&CK® as Discovery: Discovery - An Information Security Reference That Doesn't Suck. For this example, we will write a Sigma rule to catch recon activity by detecting an installation of zenmap. This article will explain how Sigma rules look like, what the structure of a sigma config looks like and how to write a new Sigma rule and modify the sigma config to get the expected result. Some basic understanding of Sigma is helpful but not mandatory. The target audience for this blogpost are engineers who are familiar with basic concepts of Timesketch and have a running Timesketch instance with running Celery workers.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |