mirror of https://github.com/MISP/misp-book
commit
7ae72ee58c
|
@ -51,7 +51,7 @@ MISP can now extend an event (starting from version 2.4.90). This allows users t
|
|||
|
||||
## MISP feeds
|
||||
MISP includes a set of public OSINT feeds in its default configuration. The feeds can be used as a source of correlations for all of your events and attributes without the need to import them directly into your system. The MISP feed system allows for fast correlation but also a for quick comparisons of the feeds against one another.
|
||||
To get started with MISP we advise to enable the CIRCL OSINT feed withing your MISP instance. This feed is generated with the PyMISP [feed-generator](https://github.com/CIRCL/PyMISP/tree/master/examples/feed-generator).
|
||||
To get started with MISP we advise to enable the CIRCL OSINT feed within your MISP instance. This feed is generated with the PyMISP [feed-generator](https://github.com/CIRCL/PyMISP/tree/master/examples/feed-generator).
|
||||
[More](http://www.misp-project.org/feeds/)
|
||||
|
||||
## MISP format
|
||||
|
|
2
USAGE.md
2
USAGE.md
|
@ -212,7 +212,7 @@ canvas needs to be compiled and needs the following dependencies:
|
|||
xcode-select --install
|
||||
# If you have homebrew not installed yet:
|
||||
## /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
|
||||
# For the more adventureous you can install a cask of calibre which gives you access to *ebook-convert*
|
||||
# For the more adventurous you can install a cask of calibre which gives you access to *ebook-convert*
|
||||
## brew cask install calibre
|
||||
brew install pkg-config cairo pango libpng jpeg giflib
|
||||
```
|
||||
|
|
|
@ -766,7 +766,7 @@ Warning: Scheduled tasks come with a lot of caveats and little in regards of cus
|
|||
"""
|
||||
|
||||
The task scheduler is a sub-par component to enable minimal functionality in terms of automating certain MISP tasks.
|
||||
If you have a dedicated and concious MISP Site Admin she can keep an eye on the Scheduler to make sure everything runs smoothly.
|
||||
If you have a dedicated and conscious MISP Site Admin she can keep an eye on the Scheduler to make sure everything runs smoothly.
|
||||
|
||||
For better performance please use a real scheduler like your systems' crontab.
|
||||
As a rule of thumb: If you can click on it, MISP can automate it.
|
||||
|
|
|
@ -665,4 +665,4 @@ Because LDAP and MISP users are paired by e-mail address, it is possible to migr
|
|||
* When a user is disabled in LDAP and also in MISP and then enabled in LDAP, it will be enabled in MISP for next login just when `updateUser` is set to `true`.
|
||||
* Currently it is not possible to log in with both LDAP and local (MISP) accounts.
|
||||
* Admins can change users email address. But when `updateUser` is set to true, when the user will log in again, the e-mail address will be updated from LDAP.
|
||||
* `Security.require_password_confirmation` setting currently doesnt work with LDAP authentication. But on the other hand, since user cannot change e-mail address and password, this setting is not important.
|
||||
* `Security.require_password_confirmation` setting currently does not work with LDAP authentication. But on the other hand, since user cannot change e-mail address and password, this setting is not important.
|
|
@ -84,7 +84,7 @@ curl --header "Authorization: YOUR API KEY " --header "Accept: application/json"
|
|||
|
||||
## Search
|
||||
|
||||
It is possible to search in the database for a list of attributes or events based on a list of criterias.
|
||||
It is possible to search in the database for a list of attributes or events based on a list of criteria.
|
||||
|
||||
To return attributes or events in a desired format, use the following URL and header settings:
|
||||
|
||||
|
@ -144,7 +144,7 @@ Find below a non exhaustive list of parameters that can be used to filter data i
|
|||
- **timestamp**: Restrict the results by the timestamp (last edit). Any event with a timestamp newer than the given timestamp will be returned. In case you are dealing with /attributes as scope, the attribute's timestamp will be used for the lookup. The input can be a timestamp or a short-hand time description (7d or 24h for example). You can also pass a list with two values to set a time range (for example ["14d", "7d"]).
|
||||
- **published**: Set whether published or unpublished events should be returned. Do not set the parameter if you want both.
|
||||
- **enforceWarninglist**: Remove any attributes from the result that would cause a hit on a warninglist entry.
|
||||
- **to_ids**: By default (0) all attributes are returned that match the other filter parameters, irregardless of their to_ids setting. To restrict the returned data set to to_ids only attributes set this parameter to 1. You can only use the special "exclude" setting to only return attributes that have the to_ids flag disabled.
|
||||
- **to_ids**: By default (0) all attributes are returned that match the other filter parameters, regardless of their to_ids setting. To restrict the returned data set to to_ids only attributes set this parameter to 1. You can only use the special "exclude" setting to only return attributes that have the to_ids flag disabled.
|
||||
- **deleted**: Default value 0. If set to 1, only deleted attributes will be returned. If set to [0,1] , both deleted and non-deleted attributes wil be returned.
|
||||
- **includeEventUuid**: Instead of just including the event ID, also include the event UUID in each of the attributes.
|
||||
- **event_timestamp**: Only return attributes from events that have received a modification after the given timestamp. The input can be a timestamp or a short-hand time description (7d or 24h for example). You can also pass a list with two values to set a time range (for example ["14d", "7d"]).
|
||||
|
@ -904,7 +904,7 @@ Do not use this function with GET!
|
|||
- **published**: Set whether published or unpublished events should be returned. Do not set the parameter if you want both.
|
||||
- **timestamp**: ***Deprecated!!!*** (synonym for attribute_timestamp) Restrict the results by the timestamp (last edit). Any attribute with a timestamp newer than the given timestamp will be returned. The input can be a timestamp or a short-hand time description (7d or 24h for example). You can also pass a list with two values to set a time range (for example ["14d", "7d"]).
|
||||
- **enforceWarninglist**: Remove any attributes from the result that would cause a hit on a warninglist entry.
|
||||
- **to_ids**: By default (0) all attributes are returned that match the other filter parameters, irregardless of their to_ids setting. To restrict the returned data set to to_ids only attributes set this parameter to 1. You can only use the special "exclude" setting to only return attributes that have the to_ids flag disabled.
|
||||
- **to_ids**: By default (0) all attributes are returned that match the other filter parameters, regardless of their to_ids setting. To restrict the returned data set to to_ids only attributes set this parameter to 1. You can only use the special "exclude" setting to only return attributes that have the to_ids flag disabled.
|
||||
- **deleted**: Default value 0. If set to 1, only deleted attributes will be returned. If set to [0,1] , both deleted and non-deleted attributes wil be returned.
|
||||
- **includeEventUuid**: Instead of just including the event ID, also include the event UUID in each of the attributes.
|
||||
- **event_timestamp**: Only return attributes from events that have received a modification after the given timestamp. The input can be a timestamp or a short-hand time description (7d or 24h for example). You can also pass a list with two values to set a time range (for example ["14d", "7d"]).
|
||||
|
@ -1230,7 +1230,7 @@ Only the fields POSTed will be updated, the rest is left intact. To view all pos
|
|||
|
||||
### POST admin/users/delete/
|
||||
|
||||
You can also delete users by POSTing to the below URL, but keep in mind that disabling users (by setting the disabled flag via an edit) is always prefered to keep user associations to events intact.
|
||||
You can also delete users by POSTing to the below URL, but keep in mind that disabling users (by setting the disabled flag via an edit) is always preferred to keep user associations to events intact.
|
||||
|
||||
#### Parameters
|
||||
|
||||
|
|
|
@ -159,7 +159,7 @@ Configure a sync user.
|
|||
### Verify Cert
|
||||
This gives you the option to choose if python should validate the certificate of the misp instance. (This allows ease within testing environments)
|
||||
|
||||
`misp_verifycert = False` IT IS RECOMENDED TO USE A VALID SSL CERT IN PRODUCTION AND CHANGE THIS TO TRUE
|
||||
`misp_verifycert = False` IT IS RECOMMENDED TO USE A VALID SSL CERT IN PRODUCTION AND CHANGE THIS TO TRUE
|
||||
|
||||
## Instructions on Reading TiIndicators That Have Been Pushed
|
||||
In the command line, run `python3 script.py -r`
|
||||
|
|
|
@ -18,7 +18,7 @@ Then we get the add event form.
|
|||
|
||||
Let's fill it with the data we already have:
|
||||
* Date: Here we will put the date of the report, so 2016-11-14
|
||||
* Distribution: Depending on the event, we might want it to be more or less spread accross the MISP instances. For this one, since it is a public report, there is no reason to limit the diffusion so "All communities".
|
||||
* Distribution: Depending on the event, we might want it to be more or less spread across the MISP instances. For this one, since it is a public report, there is no reason to limit the diffusion so "All communities".
|
||||
* Threat Level: Self explainatory. Since the ransomware in the report is not using a huge exploit, we can use low, or undefined as we don't really know. we'll go for the latter since it can be edited.
|
||||
* Analysis: Give the current stage of the analysis. Since the report is published, we can assume that the analysis is completed.
|
||||
* Event Info: The event's info is in fact the name or title of the event, so it seems legit to put the title of the report here as well. Since it is public information, we also prefix it with "OSINT".
|
||||
|
@ -113,7 +113,7 @@ We only have the network indicators left, and as said before, we will let MISP d
|
|||
|
||||
![type recognition fail](figures/surprise.png)
|
||||
|
||||
Oh well, that was unexpected. In fact, it is not that surprising regarding the format of the tor address that look more like a filename than like a url but it is still a problem, since we can't change the type nor the category to a more consistant one. This is indeed one of the limitation of freetext import. To solve this issue, we will use a simple trick: we will add a slash at the end of the tor address so it won't be confused for a filename.
|
||||
Oh well, that was unexpected. In fact, it is not that surprising regarding the format of the tor address that look more like a filename than like a url but it is still a problem, since we can't change the type nor the category to a more consistent one. This is indeed one of the limitation of freetext import. To solve this issue, we will use a simple trick: we will add a slash at the end of the tor address so it won't be confused for a filename.
|
||||
|
||||
![freetext import network](figures/free_network2.png)
|
||||
|
||||
|
|
|
@ -34,7 +34,7 @@ for different monitoring tools:
|
|||
- Using [Cacti](https://www.cacti.net/), a blog post with the [instruction](https://www.misp-project.org/2020/08/22/MISP-Monitoring-with-Cacti.html) is available.
|
||||
- Using [Munin](http://munin-monitoring.org/), [misp-monitor](https://github.com/SteveClement/misp-monitor) for instructions.
|
||||
- Using [Nagios](https://www.nagios.org/), [Monitoring MISP with Nagios](https://blog.rootshell.be/2020/08/25/monitoring-misp-with-nagios/)
|
||||
- Using [OpenNMS](https://www.opennms.com/), a blog post with the [instructions](https://www.misp-project.org/2020/08/18/MISP-Monitoring-with-OpenNMS.html) is availabe.
|
||||
- Using [OpenNMS](https://www.opennms.com/), a blog post with the [instructions](https://www.misp-project.org/2020/08/18/MISP-Monitoring-with-OpenNMS.html) is available.
|
||||
- [Live monitoring of MISP usage](https://github.com/MISP/misp-monitoring) via the httpd logs.
|
||||
|
||||
***
|
||||
|
@ -129,7 +129,7 @@ Source: [Getting started with MISP](http://www.vanimpe.eu/2015/05/31/getting-sta
|
|||
MISP can be made more appealing to the eye by adding some graphics.
|
||||
|
||||
As Org.- or Site-admin navigate to *Administration* -> *List organisations* and edit the corresponding organization.
|
||||
Withing this editor you will be able to update the logo.
|
||||
Within this editor you will be able to update the logo.
|
||||
|
||||
Other ways to achieve this, would be:
|
||||
|
||||
|
@ -627,7 +627,7 @@ OR if you were foolish enough to not install in a Python virtualenv:
|
|||
sudo -u www-data misp-modules -l 127.0.0.1 -s &
|
||||
```
|
||||
|
||||
> [warning] Running misp-modules like this will certainly kill it once you quit the session. Make sure it is in your **/etc/rc.local** or some ther init script that gets run on boot.
|
||||
> [warning] Running misp-modules like this will certainly kill it once you quit the session. Make sure it is in your **/etc/rc.local** or some other init script that gets run on boot.
|
||||
|
||||
## Uninstalling MISP
|
||||
|
||||
|
@ -1025,7 +1025,7 @@ sudo sudo systemctl restart apache2
|
|||
|
||||
### What are the required steps after a MISP installation to have a properly running instance?
|
||||
|
||||
- First login with the installation credentials and change the password immediatly (especially if your instance is publicly accessible)
|
||||
- First login with the installation credentials and change the password immediately (especially if your instance is publicly accessible)
|
||||
- Set the base_url to the hostname of your machine (apache virtualhost name)
|
||||
- Create a new organisation which will be the host organisation running the MISP instance
|
||||
- Set the new organisation in `MISP.host_org_id` to replace the default one
|
||||
|
|
|
@ -74,7 +74,7 @@ The __/galaxies__ file contains metatdatas and galaxy structure.
|
|||
The __/clusters__ file contains actual data.
|
||||
|
||||
|
||||
#### The galaxy managment GUI
|
||||
#### The galaxy management GUI
|
||||
|
||||
![GalaxyManagment](./figures/GalaxyManagmentGui.png)
|
||||
|
||||
|
|
|
@ -68,7 +68,7 @@ Sharing groups in MISP are a more granular way to create re-usable distribution
|
|||
|
||||
The most general use-cases for sharing groups are creating re-usable topical subgroups in MISP that share events or for ad-hoc sharing scenarios (such as several organisations involved in a specific incident wanting to work together). Generally sharing groups add a level of complexity for the users involved as well as a performance overhead on the data marked with it.
|
||||
|
||||
As a best-practice recommendation, using traditional distribution methods is prefered unless they cannot cover the given use-case. Also, whilst sharing groups can be assigned to both events and attributes, it is highly recommended to use the special "inherit" distribution setting on attributes whenever the attribute's sharing group would match the event's.
|
||||
As a best-practice recommendation, using traditional distribution methods is preferred unless they cannot cover the given use-case. Also, whilst sharing groups can be assigned to both events and attributes, it is highly recommended to use the special "inherit" distribution setting on attributes whenever the attribute's sharing group would match the event's.
|
||||
|
||||
Sharing groups consist of the following elements, each of which has its own page in the sharing group creator/editor tool (accessed via the Global actions -> List Sharing Groups and Add Sharing Group functionalities):
|
||||
|
||||
|
@ -105,7 +105,7 @@ For users trying to populate an event, after clicking on the populate from templ
|
|||
![Choose the most appropriate template for your event.](figures/template_choice.png)
|
||||
|
||||
Once you have chosen a template, you'll be presented with the actual form contained within. Make sure you fill out as many fields as possible with the mandatory fields - marked by a star in a bracket such as this: (*) - are filled out.
|
||||
Templates are devided into sections, with each section having a title and a description in addition to a series of fields. Each field can be an attribute or a file attachment field. An attribute field has the following components:
|
||||
Templates are divided into sections, with each section having a title and a description in addition to a series of fields. Each field can be an attribute or a file attachment field. An attribute field has the following components:
|
||||
|
||||
![MISP will generate attributes based on the field's settings and the data that you provide.](figures/template_field.png)
|
||||
|
||||
|
@ -481,12 +481,12 @@ The platform is also [RESTfull](http://en.wikipedia.org/wiki/Representational_st
|
|||
Use any HTTP compliant library to perform requests.
|
||||
You can choose which format you would like to use as input/output for the REST calls by specifying the Accept and Content-Type headers.
|
||||
|
||||
The following headers are required if you wish to recieve / push XML data:
|
||||
The following headers are required if you wish to receive / push XML data:
|
||||
**Authorization**: _your authorisation key_
|
||||
**Accept**: _application/xml_
|
||||
**Content-Type**: _application/xml_
|
||||
|
||||
The following headers are required if you wish to recieve / push JSON data:
|
||||
The following headers are required if you wish to receive / push JSON data:
|
||||
**Authorization**: _your authorisation key_
|
||||
**Accept**: _application/json_
|
||||
**Content-Type**: _application/json_
|
||||
|
@ -658,7 +658,7 @@ Content-Type: application/xml
|
|||
</response>
|
||||
```
|
||||
|
||||
The respone from requesting an invalid page
|
||||
The response from requesting an invalid page
|
||||
|
||||
```xml
|
||||
<?xml version = "1.0" encoding = "UTF-8"?>
|
||||
|
|
Loading…
Reference in New Issue