2. Project Specification
MISP, Malware Information Sharing Platform and Threat Sharing, is an open
source software solution for collecting, storing, distributing and sharing cyber se-
curity indicators and threats about cyber security incidents analysis and malware
analysis [1][2][3]. Previously to the work described it this report the MISP login
capabilities were limited, with the default being the basic user and password based
authentication. One of the main objectives of the project was to enhance MISP
with Single Sign-On capabilities in order to make use of CERN’s centralized login
system.
Furthermore, one important functionality of the MISP platform is allowing
Indicators of Compromise (IoCs) to be exported in a format that an Intrusion
Detection System (IDS) can digest. The primary IDS used at CERN is Bro [4][5].
Until now MISP did not have the ability to export IoCs natively for Bro. Therefore
a second objective of the project was to enhance the export capabilities of MISP
by allowing it to export IoCs in the native format used by the Bro intelligence
framework.
IoCs are organized in "Events", which can contain one or more "Attribute".
These attributes are the actual IoC, meaning that is there were the specific in-
formation is stored (e.g. the IP address of an attacker). Moreover, events can be
tagged with the default tags included in MISP or with custom ones added by the
administrators. In addition, events correlations are detected by MISP and shown
in the web interface. Two events are understood as related if they have a matching
attribute (e.g. an IP address present in two events).
The deployment of a MISP instance may be tedious due to the many dependen-
cies required and the fact that it does not come packaged. Instead the installation
of various MISP versions is managed by Git [6] version tags. In this scope the ob-
jective was to develop a Puppet module that handles dependencies, installation,
configurations and services management; and a Puppet manifest which makes use
of it and other needed modules in order to successfully deploy a MISP instance.
1
3. Abstract
MISP is a Malware Information Sharing Platform that allows cybersecurity spe-
cialists to be up-to-date on security threat indicators (or Indicators of Compromise;
IoC) by means of sharing their own and being able to access others’. Sharing and
having access to these indicators can be really helpful and key to a fast and effec-
tive detection of attacks. This is due to similar organisations being targeted by
the same attacker, in the same or different campaigns.
However, these IoCs have to be used, not only shared. Therefore, MISP pro-
vides the capability to automate the process of exporting them into an IDS or
other systems, currently MISP supports Snort, Suricata, STIX and OpenIOC for-
mats. Moreover MISP also provides the possibility of synchronizing the IoCs of
two MISP instances.
The main goal of the project was to enhance the MISP platform to be used
more effectively and reliably at CERN by means of deploying and accessing the
platform itself and exporting the IoCs to the IDS used at CERN. The deployment
will be automated by using the Puppet configuration management platform, and
the development of two new features: the login capabilities will be extended in
order to support the Single Sing-On system at CERN by adding a plugin to the
platform, and the export service will be enhanced with support for the format used
by the Bro intelligence framework.
2
4. Acknowledgments
I want to thank CERN for giving me the opportunity to be part of the Summer
Student Programme. The Computer Security Team for allowing me in and treating
me as equal, for the time they invested in me, the countless things they taught me
and being always willing to help.
I want to specially thank to Liviu Valsan and Vincent Brillault, the Masters
of Puppet, for their help, master classes, time and above all patience. They have
been the mentors everybody would like to have, once again, thank you.
3
6. 1 Introduction
1.1 MISP Project
MISP is an Open Source project that was started in 2011 as a personal project
of Christophe Vandeplas and became a NATO sponsored project in 2013. Later
on, in 2013 it changed to be maintained by CIRCL [7] and its nowadays mainly
developed by Andras Iklody and a vast community on GitHub [3].
MISP is a platform that allows organisations to store, correlate and share their
indicators of compromise, therefore creating an alliance against cyber threats and
the attackers behind them. An IoC, or Indicator of Compromise, is a simple piece
of information that allows to identify, with a high degree of confidence or certainty,
that something (e.g. email attachment) is a security threat.
MISP provides many features that makes the use of IOCs in a highly useful and
efficient manner. Among those features are the use of customizable taxonomies
to classify and tag events, the support for many import and export formats and
synchronization with other MISP instances. In addition its modularised fashion
makes it easy to contribute and enhance its capabilities.
5
7. 2 Implementation
MISP is implemented in PHP and Python. The web interface and its built-in
APIs are written in PHP, while the PyMISP API is built in Python. MISP needs
to store the data related to users, organisations, IoCs and others. Therefore, it
makes use of a database to persist the mentioned information (currently MySQL
and PostgreSQL are supported).
Among others, the import and export data tasks and the synchronization with
other MISP instances are jobs that can be resource consuming, therefore they are
run as background jobs. In order to do so MISP makes use of the CakeResque
framework [8], which allows the use of queues for background jobs from PHP
applications. This framework persist the queues and workers data to a Redis in-
memory database.
2.1 MISP Login System
As it has been explained before, MISP only provides basic authentication via the
conventional user-password system. This presents the inconvenience of having to
maintain and manage a database of users and their permissions explicitly for MISP,
which might be a tedious, making it error prone. Therefore, the idea is to enable
MISP to make use of the Single Sing-On authentication mechanism. It is worth
mentioning that there are third party plugins that could be added to MISP that
enable other authentication mechanisms such as certificate based or Kerberos [9]
authentication via Apache.
2.1.1 Single Sign-On
In many environments it is desirable for users to maintain their login accross
diferent applocations potentially running on different domains (i.e. A user logs
in domainA.cern.ch and then logs in into domainB.cern.ch without introducing
any information because the credentials would have already been checked). This
capability could be enabled by storing a cookie in the user’s browser. However,
browsers usually enforce the same origin policy, which means that cookies will
only be readable by the original domain and therefore domainB will not be able
to read domainA’s set cookie.
6
8. Single Sign-On is an mechanism that allows the authentication, meaning the
validation of credentials, to happen once across different applications. It solves
the same origin policy problem by setting a central authentication domain (e.g.
auth.cern.ch) which will process the login of the user, store a cookie and then
redirect to the appropriate website along with the needed login information.
CERN uses Shibboleth [10] as a Single Sign-On (SSO) system. It consists of 3
components:
• Resource is a piece of restricted access content (e.g. website).
• Service Provider (SP) is the part of the system that performs the SSO
process for the user on the requested resource.
• Identity Provider (IdP) is the part of the system that authenticates the
user.
The authentication process that is followed is: First the user requests a resource
(1), if he already has an active session then he is directed to the resource, if not
it is redirected to the SP(2). The SP issues an authentication request to the IdP
(3) who issues the appropriate response (4). If the user is authenticated the SP
sets a session on the user and redirects him to the requested resource along with
the user information needed(5). If the user is not authenticated, the access to the
resource is denied.
Resource SP
5
IdP
4
1 2 3
Figure 1: Single Sign-On process
2.1.2 How the plugin works
The plugin extends the BaseAuthenticate class defined in Controller/Compo-
nent/Auth of the CakePHP[12] framework and implements the authenticate func-
tion by calling the overridden function getUser. The login authentication process
performed is the following:
7
9. At first the existence of the sso_disable GET parameter is checked and in case
it is present with a value of true the SSO authentication will return false in order
to bypass the SSO based authentication system and fall back to the default MISP
user and password based authentication. It should be noted that only the SSO
based authentication is being skipped in this case and the whole login falls back
to the next authentication method. This could be used by administrators to log
in with a specific local MISP account rather than their SSO identity and therefore
have a better control over login rights. This can also be used as an alternative
login in case the SSO IdP fails.
The next step is to load from the configuration file the names of the different
SSO related variables and look for them in the server variables (i.e. mail, organ-
isation and group). The first one to be checked is the one containing the user’s
email address. In case such a server variable exists a user matching that email
address is searched for in the database. The next step is to check for the existence
of the organisation in the database and register it if it does not exists. Note that
the organisation will be register as an external organisation so it will not be, for
example, possible for it to be the host organisation of the MISP instance. The host
organisation of the MISP instance needs to be set up during the initial deployment
of the MISP platform.
The next step is to obtain the role of the user by matching the list of returned
groups from the SP against the group-to-role map. If there is no match the login
will fail denying the access to the user. It can be the case that the user’s role has
changed due to a change in its group membership, in this case the role would be
updated in the database (note that deleting the old SSO cookie might be needed
for the changes to be effective). CERN uses E-groups [11] (or "egroups") it the
technology used at CERN to manage groups. Egroups can be used to manage
mailing lists, or as in this case, to manage the authorization of users and their
permissions.
It is also possible that the user did not exist in the database, in this case a
new user would be registered in the database with the organisation and role given,
the password field would be set to a random string of 40 characters (the length
constraint is imposed by the database schema). Therefore in case of having the
need to use the user and password based authentication system, the password
would need to be reset by an administrator.
The entire process can be easily understood from the flowchart in Figure 2:
8
10. Login
"sso_disable"
flag set to true
Return false
Email variable
Look up user
Organisation variable
Look up organisation
Use default
organisation
Organisation exists
Register
organisation
Group to role matchedUser exists
Organisation
changed
Update user organisation
Role changed Return user
Update user role
Generate random password Register new user
yes
no
present
absent
absent
present
no
yes
no
yes
yes
no
yes
no
yes
no
Figure 2: MISP SSO plugin process
9
11. 2.1.3 How to use the plugin
The plugin has been implemented following the schema used for MISP pluggable
features and in general the one used for any CakePHP based application. There-
fore, in order to configure it the user needs to edit the config.php file, which is usu-
ally located under app/Config/ and takes its default values from config.default.php.
The configuration works as follows:
In the configuration file the ’ShibbAuth.ApacheShibb’ package must be added
to the ’Security’ array. It can be the case that there is another authentication
method already established, in that case it will just need to be added to the list.
Please note that these methods will be tried sequentially, meaning that the second
one will only be used if the first one fails, in consequence the Apache Shibboleth
method would need to be the first one in the list. An example of the code is the
following:
’ Security ’ =>
array (
’ l e v e l ’ => ’medium ’ ,
’ s a l t ’ => ’YOUR_SALT’ ,
’ cipherSeed ’ => ’YOUR_CIPHER_SEED’ ,
’ auth ’ => array ( ’ ShibbAuth . ApacheShibb ’ ) ,
) ,
Then the Apache Shibboleth configuration element has to be added, or simply
uncommented from the config.default.php file, and its values configured. The code
would go as follows:
’ ApacheShibbAuth ’ =>
array (
’ MailTag ’ => ’EMAIL_TAG’ ,
’OrgTag ’ => ’FEDERATION_TAG’ ,
’GroupTag ’ => ’GROUP_TAG’ ,
’ GroupSeparator ’ => ’ ; ’ ,
’ GroupRoleMatching ’ => array (
’ egroup_three ’ => 3 ,
’ egroup_two ’ => 2 ,
’ egroup_one ’ => 1 ,
) ,
’ DefaultOrg ’ => ’DEFAULT_ORG’ ,
) ,
10
12. As it can be seen the configuration takes several parameters. The tags (Mail-
Tag, OrgTag and GroupTag are used to extract values from server variables pop-
ulated from the SSO SP, in this case Shibboleth. The GroupSeparator is the
character that separates the groups in the string given by the SSO SP, by default
it is a semicolon ";" so the returned value for the GroupTag variable would be
"egroup1;egroup2;egroup2-1;egroup3". In the GroupRoleMatching array the group-
to-role map is defined, meaning which group coresponds to which role. When
configuring it take into account that rights go in an inversely proportional order,
meaning the lower the number the higher the role (i.e. number 1 is role Admin,
number 2 is Org. Admin and number 3 is User) although customized roles can be
added to MISP and they will have a higher number independently of its rights.
The DefaultOrg is the default organisation name given to a user if no organisation
value is returned by the SSO SP.
In addition, to enable the plugin the user has to only uncomment one line in
the boostrap.php file:
CakePlugin : : load ( ’ ShibbAuth ’ ) ;
This file is usually located under app/Config/ inside the MISP installation
directory, its default values are established in bootstrap.default.php.
Please note that the plugin has been developed to be as generic as possible,
nevertheless, it might need to be slightly changed in order to be compatible with
other SSO technologies than Shibboleth.
In addition, it is worth mentioning that even though the Single Sign-On mech-
anism is strictly related to the authentication phase, this plugin also handles the
authorization phase. This is achieved by using the user groups to determine the
user’s role. Please note that the chosen role will be the one with the lowest id
(highest rights), therefore if a user belongs to an egroup that corresponds to a
default role (e.g. users) and a custom one, the default one will be chosen because
the custom roles will have a higher id, independently of the amount of rights they
might grant.
2.2 MISP Export Features
MISP is a powerful platform but only goes as far as storing and sharing IoCs.
Therefore it allows users to export the IoCs in order to use them in other appli-
cations, frameworks and platforms. As an example MISP currently supports the
11
13. export of the IoCs in two IDS formats, Snort and Suricata, apart from XML, CSV,
text and other useful formats. This export features are made available to the users
in two ways, by the use of the web UI or by the use of the API1
.
2.2.1 How the export to Bro works
MISP has been enhanced with export capabilities to the native format used by the
intelligence framework built into Bro [13]. This format implies an entry per line
with its values separated by tabulations. In addition a header has to be placed on
the first line as follows:
#fields indicator indicator_type meta.source meta.url meta.do_notice meta.if_in
The fields of the header correspond to the value of the IoC, the type, the
source of the event, the URL to the event it belongs to, a boolean that determines
if matches will be sent to Bro’s Notice framework and a parameter specifying the
network interface on which the matching should be performed. Regarding the
source of the event, it is worth mentioning that due to the fact that Bro supports
repeated rules from different sources, being this the primary key in the database,
this field is set to MISP_INSTANCE (UUID) - ORGNAME in order to avoid
collisions in the data base. MISP_INSTANCE refers to the name of the instance
(e.g. WLCG MISP, the UUID refers to the unique identifier of the event and
ORGNAME refers to the name of the source organisation.
Both the if_in and do_notice parameters are set to a fixed value of "-" and
"T", which means that there is not a specific network interface where matches
should trigger and they will all be sent to Bro’s Notice framework. The indicator
is the actual value of the IoC, its source is the organisation that uploaded it and the
url, as mentioned before, is the url of the event it belongs to. The type parameter
has to be transformed due to the fact that MISP types are more complex and rich
in variety than the Bro ones. Therefore the matching that is done is shown in
Table 1:
1
PyMISP API could also be used, however its performance is not optimal
12
14. Table 1: Bro to MISP types matching
Bro type MISP types
Intel::ADDR ip-src, ip-dst, domain|ip
Intel::SUBNET ip-src, ip-dst
Intel::DOMAIN hostname, domain, domain|ip
Intel::URL url
Intel::USER_NAME -
Intel::FILE_NAME
filename, email-attachment, filename|md5,
filename|sha1, filename|sha256
Intel::FILE_HASH
md5, sha1, sha256, filename|md5,
filename|sha1, filename|sha256
Intel::CERT_HASH x509-fingerprint-sha1
Intel::SOFTWARE user-agent
Intel::EMAIL email-src, email-dst
As it can be seen in the table above, there are no MISP types that can be
matched to the Intel::USER_NAME Bro type. In addition, it can be observed
that there are MISP types that appear in more than one Bro type. This fact is due
to them having two values, for example domain|ip has a domain value along with
an address value, therefore they will appear in Intel::ADDR and Intel::DOMAIN
but only the appropriate half of the record will be used (i.e. the domain value in
Intel::DOMAIN and the IP value in Intel::ADDR). Concerning the Intel::SUBNET
bro type it is matched to both ip-src and ip-dst but in the cases that they represent
a subnet, meaning they will be represented in IP/NETMASK format.
In consequence when MISP is queried to export a specific Bro type it will
export all published events that belong to the MISP types associated with the
queried Bro type and that have the To IDS flag set.
2.2.2 How to use the Bro export feature
The Bro export feature, as for the rest of the export formats, can used from
both the web UI and the API. In the first case it’s only a matter of clicking
the "Generate" button on the web UI. If the export data is outdated a fresh
export will be prepared and once generated, clicking the "Download" button will
start the download of a Zip file that contains 8 files: addr.intel, domain.intel,
url.intel, filename.intel, filehash.intel, certhash.intel, software.intel and email.intel
that correspond to the equally named Bro types. As mentioned in the previous
13
15. section each of the Bro and MISP data types have a one-to-many relationship.
Therefore these files might contain data from more than one MISP type.
The other option for accessing the data is by quering the API. This can be done
according to the Bro data type. For example to download the data corresponding
to the Intel:DOMAIN data type the query would be the following2
:
curl -G https://<MISP_hostname>/attributes/bro/download/domain
-H ’Authorization:"API_KEY"’ -H ’Content-type:application/json’
-H ’Accept:application/json’
Moreover if needed the API can be queried with parameters for filtering by
tag, event, and dates (or date range) and even allow events without the IDS flag
set to be exported. The URL would be the following (note that the headers are
omitted for simplicity):
/attributes/bro/download/[type]/[tags]/[event_id]/[allowNonIDS]/[from]/[to]/[last]
In case that the query is not properly formatted or requesting an non-existent
Bro type the response would be an error message.
2.3 MISP Deployment
The MISP platform currently supports Debian, Ubuntu and CentOS operating
systems and MySQL as a database (PostgreSQL support is currently experimen-
tal). For any of the options mentioned there are installation instructions in the
MISP GitHub public repository3
. In order to properly work, MISP requires many
submodules such as CakeResque, STIX and CyBox, as well as many other libraries
such as Python importlib and databases such as MySQL and Redis.
As it can be appreciated from the amount of systems involved in MISP, it can
be conlcuded that the process to set up a MISP instance can be tedious from the
installation and configuration point of view, making it error prone. Therefore,
there is a need to automatise and streamline the deployment of a MISP instances.
2
For the whole list of possible queries refer to the web documentation in the automation page:
https://YOUR_MISP_URL/events/automation
3
https://github.com/MISP/MISP/tree/2.4/INSTALL
14
16. The chosen technologies for doing so at CERN are Puppet [14] [15] [16] and
some propietary tools such as Teigi[17]. To sum up, in order to achieve this task,
a Puppet module which installs MISP and its dependencies, configures them and
manages the needed services has been developed. Consequently a Puppet manifest
that handles the installation and configuration of MISP itself, making use of the
before mentioned module, the web server on top of which MISP will run, in this case
Apache [18], and the authentication SP based in Shibboleth has been developed.
2.3.1 MISP Puppet Module
This module handles the installation of the MISP platform and its configuration,
managing also the needed services on a CentOS 7 host.
The first step carried out by the module is the installation of the dependencies
required by MISP. The full list of dependencies can be found in the installation
instructions mentioned above, nevertheless the module does not install all of them.
For example, the database (MySQL) server is not installed due to the use of the
Database On-Demand service provided by CERN IT. Moreover, the PHP version
(5.4) provided natively by CentOS 7 is deprecated and not supported by CakePHP
therefore PHP 5.6 is installed by the module and the needed dependencies are
installed in its environment using scl4
.
In the installation phase the module allows the customization of the installation
directory, the timezone and the repository from which to download the source code
of MISP, STIX and CyBox, along which their respective versions. Therefore, the
module can also be used to update the system (e.g. to update from MISP v2.4.48
to v2.4.51). However, be aware that this method would only be valid for minor
updates (e.g. within 2.4.x) and would not work for major version updates.
Concerning the configuration, the module allows for customizing both the in-
stallation and configuration directories, however the configuration directory needs
to be under the installation one. In addition, values of the configuration and
database files can be customized5
(e.g. the enrichment, import and export ser-
vices, database host, port, name and user).
After that the module takes care of maintaining MISP services up and run-
ning. Meaning that it handles the status of PHP-FPM, Haveged, Redis and its
background workers.
4
Software Collections: http://linux.die.net/man/1/scl
5
For the whole list of options please refer to Annex A
15
17. 2.3.2 MISP Puppet Manifest
The manifest handles the integration and configuration of MISP with the external
services needed (i.e. Apache and Shibboleth). It include several modules:
At first it makes use of the CERN’s proprietary module certmgr to place in
the proper directory the CERN CA generated certificates. The module also opens
ports 80 (HTTP) and 443 (HTTPS) in the local firewall inside CERN’s internal
network.
After that it handles the installation of MISP, passing the appropriate values
for it to be configured (e.g. installation directory, database values, etc.). It is
worth mentioning that in order to make use of Teigi to store the password of
the database in a security-wise manner, the configuration directory is set to a
temporal directory where the configuration files are placed and after that they are
moved to the corresponding directory inside the MISP application folder by Teigi
or puppet File resource depending on which file is being treated. This bridging
method enables Teigi to replace the tag of the database password by its value
without it being exposed in the module.
After that the module handles the configuration of PHP. This step is needed
because by default PHP would not trust CERN certificates and therefore API calls
and synchronization between instances would not be possible. Therefore the PHP
5.6 ini file is changed by the inifile module and the openssl.capath is set to the
path where the certmgr module placed the certificates.
The next step is to configure Shibboleth and Apache, the second one is slightly
more complex. The proxy_fcgi and shib modules for apache are needed, although
the default configuration is enough for them to fulfill the requirements. In addition
two virtual host are defined, one that enables the redirection of http connection to
https. The second one is the one that contains the configuration that would sup-
port MISP. It is worth mentioning that exceptions to SSO authentication method
had to be set up in the virtual host in order to allow the synchronization of in-
stances and the use of the API, therefore in those two use cases authentication
and authorization are handled via API keys.
16
18. 3 Results
As a result of this summer student project every instance of MISP, independently
of the host organisation, would be able to make use of both the Single Sign-On
login and Bro export, with the second one being highly valued by the community.
This two contributions are already available in the upstream code of MISP [3]. In
addition instances running on CentOS 7 hosts would be able to be automatically
deployed, managed and updated using Puppet.
The Single Sign-On capabilities are present since MISP tag 2.4.50, however
improvements have been added and bugs have been fixed. Therefore to use an
stable release of the plugin MISP version 2.4.52 or higher is recommended. The
Bro export features are present since MISP version 2.4.52. The puppet module
can be found upstream in the main puppet repository.
Moreover, as examples of production machines that are managed and using the
developed features we can name a worldwide shared instance hosted at CERN and
provided for the WLCG, and the MISP production instance of CERN.
17
19. 4 Future Work
The current SSO login implementation would retrieve a non-desirable result if the
user that should be mapped to a custom role also belongs to an egroup that is
matched to a default role. This problem is originated from the fact that custom
roles will have a higher numeric ID than default roles, independently of the amount
of rights they grant. Therefore an improvement would be to include a priority
property to the egroup to role mapping.
Concerning the deployment of MISP instances, currently the Puppet module
only supports CentOS 7 deployments. Therefore, adding support for other opera-
tive system families would be in the near future work.
18
20. Table of Acronyms
Acronym Definition
API Application Programing Interface
CERN European Organization for Nuclear Research
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
IdP Identity Provider
IDS Intrusion Detection System
IOC Indicator of Compromise
MISP Malware Information Sharing Platform and Threat Sharing.
NATO North Atlantic Treaty Organization
OCR Optical Character Recognition
SCL Software Collections
SIEM Security Information and Event Management
SP Service Provider
SSO Single Sign-On
STIX Structured Threat Information Expression
UI User Interface
WLCG Worldwide LHC Computing Grid
19
22. Annex A
Parameters of the MIPS Class
The MISP class can take many parameters to change the configuration of MISP.
However, they all have the default value set to the recommended value so there
is no need to change it. The parameters can be classified in the ones needed for
the installation of MISP itself, for the database, for the configuration and for the
services. The parameters are the following:
MISP installation
• misp_git_tag - Version of MISP that will be installed. By default "v2.4.51".
• install_dir - Directory in which MISP will be installed. By default "/var/www/MISP/".
• config_dir - Directory in which the configuration of MISP should be located.
By default "install_dir/app/Config/".
• stix_git_repo - Git url of the STIX module. By default "git://github.com/STIXProject/
python-stix.git".
• stix_git_tag- Version of the STIX module. By default "v1.1.1.4".
• cybox_git_repo - Git url of the CyBox repository. By default "git://github.com/
CybOXProject/python-cybox.git".
• cybox_git_tag- Version of the CyBox module. By default "v2.1.0.12".
timezone- Timezone where the instance has been placed. By default "UTC".
• default_user- User as which to run the installation of MISP. By default
apache.
• default_group- Group as which to run the installation of MISP. By default
apache.
• default_high_user- In some cases root permissions are need in the installa-
tion, this user will be used in those cases. By default root.
• default_high_group- In some cases root permissions are need in the instal-
lation, this group will be used in those cases. By default apache.
21
23. Database configuration
• db_name - Name of the database. By default "misp".
• db_user - Name of the user with rights on the database. By defeault "misp".
• db_host - Name of the host in which the database is located. By default
"misp.com".
• db_port - Port to connect to the database in the specified host. By default
3306.
• db_password - Password used to access the database. By default is empty.
MISP configuration
Site Configuration
• debug - Debug mode for the full instance. By default set to 0 (false).
• site_admin_debug - The debug level of the instance for site admins. This
feature allows site admins to run debug mode on a live instance without ex-
posing it to other users. The most verbose option of debug and site_admin_debug
is used for site admins. By default false.
This two parameters are recommended to be set to 0 and false respectively. How-
ever, if needed they can be set to true to find errors with names/tables in the
database. In this case it would be better to just set to true ’site_admin_debug’
instead of the whole instance.
Security
• security_level = ’medium’
• salt - The salt used for the hashed passwords. Keep in mind, this will invali-
date all passwords in the database. By default set to "Rooraenietu8Eeyo<Qu2eeNfterd-
dd+".
• cipherseed - Seed for the cipher. Empty by default.
22
24. • auth_method - Authentication method used for the instance. Empty means
default user-password login method. Empty by default.
• password_policy_length - Password length requirement. By default set to
6.
• password_policy_complexity - Password complexity requirement. By de-
fault set to ’/((?=.d)|(?=.W+))(?![n])(?=.[A-Z])(?=.[a-z]).*$/’.
MISP
• footermidleft - Footer text prepending the "Powered by MISP" text. Empty
by default.
• footermidright - Footer text following the "Powered by MISP" text. Empty
by default.
• host_org_id - The hosting organisation of this instance. If this is not selected
then replication instances cannot be added. By default is set to 1, meaning
the first Organisation in the system.
• email_subject_org - The organisation tag of the hosting organisation. This
is used in the e-mail subjects. By defualt set to ’ORGNAME’.
• showorg - Setting this setting to ’false’ will hide all organisation names /
logos. By default set to true.
• background_jobs - Enables the use of MISP’s background processing. By
default set to true.
• cached_attachments - Allow the XML caches to include the encoded attach-
ments. By default set to true.
• email - The e-mail address that MISP should use for all notifications. By
default "root@localhost".
• contact - The e-mail address that MISP should include as a contact address
for the instance’s support team. By default "root@localhost".
• cveurl - Turn Vulnerability type attributes into links linking to the provided
CVE lookup. By default set to ’http://cve.circl.lu/cve/’.
• disablerestalert - When enabled notification e-mails will not be sent when an
event is created via the REST interface. By default set to false.
23
25. • default_event_distribution - The default distribution setting for events (0-
3). 0 means your organisation only, 1 means this community only, 2 means
contacted communities and 3 is all communities. By default set to 1.
• default_attribute_distribution - The default distribution setting for attributes,
set it to ’event’ if you would like the attributes to default to the event dis-
tribution level. (0-3 or "event"). By default set to ’event’.
• tagging - Enable the tagging feature of MISP. By default set to true.
• full_tags_on_event_index - Show the full tag names on the event index.
By default set to true.
• footer_logo - This setting allows you to display a logo on the right side of
the footer. Empty by default.
• take_ownership_xml_import - Allows users to take ownership of an event
uploaded via the "Add MISP XML" button. By default set to false.
• unpublishedprivate - True will deny access to unpublished events to users
outside the organization of the submitter except site admins. By default set
to false.
• disable_emailing - When enabled, no outgoing e-mails will be sent by MISP.
By default set to false.
• live - If set to false the instance will only be accessible by site admins. By
default true.
• extended_alert_subject - Enabling this flag will allow the event description
to be transmitted in the alert e-mail’s subject. By default set to false.
• default_event_threat_level - The default threat level setting when creating
events. By default set to 1.
• newUserText - The message sent to the user after an account creation. By
default set to "Dear new MISP user,We would hereby like to welcome you
to the $org MISP community.Use the credentials below to log into MISP at
$misp, where you will be prompted to manually change your password to
something of your own choice. Username: $username Password: $password
If you have any questions, don’t hesitate to contact us at: $contact.Best
regards,Your $org MISP support team".
24
26. • passwordResetText - The message sent to the users when a password reset
is triggered. By default set to "Dear MISP user, A password reset has been
triggered for your account. Use the below provided temporary password to
log into MISP at $misp, where you will be prompted to manually change
your password to something of your own choice.Username: $username Your
temporary password: $passwordIf you have any questions, don’t hesitate to
contact us at: $contact. Best regards, Your $org MISP support team".
• enableEventBlacklisting - Enable the blacklisting of event UUIDs to prevent
them from being pushed to your instance. By default set to false.
• enableOrgBlacklisting - Enable blacklisting of organisation UUIDs to prevent
them from creating events. By default set to false.
• log_client_ip - All log entries will include the IP address of the user. By
default set to false.
• log_auth - MISP will log all successful authentications using API keys. By
default set to false.
• disableUserSelfManagement - When enabled only Org and Site admins can
edit a user’s profile. By default set to false.
• block_old_event_alert - Enable this setting to start blocking alert e-mails
for old events. By default set to false.
• block_old_event_alert_age - This setting will control how old an event can
be for it to be alerted on, measured in days. By default set to 30.
• maintenance_message - The message that users will see if the instance is not
live. By default set to "Great things are happening! MISP is undergoing
maintenance, but will return shortly. You can contact the administration at
$email.".
• email_subject_TLP_string - This is the TLP string in alert e-mail sent
when an event is published. By default ’TLP Amber’.
• terms_download - Choose whether the terms and conditions should be dis-
played inline (false) or offered as a download (true). By default set to false.
• showorgalternate - True enables the alternate org fields for the event index
(source org and member org) instead of the traditional way of showing only
an org field. By default set to false.
25
27. GPG
• gpg_onlyencrypted - Allow (false) unencrypted e-mails to be sent to users
that don’t have a PGP key. By default set to false.
• gpg_email - The e-mail address that the instance’s PGP key is tied to. By
default "no-reply@localhost".
• gpg_homedir - The location of the GPG homedir. By default "/var/www/MISP/.gnupg".
• gpg_password - The password (if it is set) of the PGP key of the instance.
Empty by default.
• gpg_bodyonlyencrypted - Allow (false) the body of unencrypted e-mails to
contain details about the event. By default set to false.
SMIME
• smime_enabled - Enable SMIME encryption. By default set to false.
• smime_email - The e-mail address that the instance’s SMIME key is tied to.
Empty by default.
• smime_cert_public_sign - The location of the public half of the signing
certificate. Empty by default.
• smime_key_sign - The location of the private half of the signing certificate.
Empty by default.
• smime_password - The password (if it is set) of the SMIME key of the
instance. Empty by default.
Proxy
• proxy_host - The hostname of an HTTP proxy for outgoing sync requests.
Leave empty to not use a proxy. Empty by default.
• proxy_port - The TCP port for the HTTP proxy. Empty by default.
• proxy_method - The authentication method for the HTTP proxy. Currently
supported are Basic or Digest. Empty by default.
26
28. • proxy_user - The authentication username for the HTTP proxy. Empty by
default.
• proxy_password - The authentication password for the HTTP proxy. Empty
by default.
SecureAuth
• secure_auth_amount - The number of tries a user can try to login and fail
before the bruteforce protection kicks in. By default set to 5.
• secure_auth_expire - The duration (in seconds) of how long the user will
be locked out when the allowed number of login attempts are exhausted. By
default set to 300.
Plugin
• customAuth_disable_logout - Disable the logout button for users authenti-
cate with the external auth mechanism. By default set to true.
• ZeroMQ_enable - Enables or disables the pub/sub feature of MISP. By de-
fault set to false.
• ZeroMQ_port - The port that the pub/sub feature will use. By default set
to 50000.
• ZeroMQ_redis_host- Location of the Redis db used by MISP and the Python
PUB script to queue data to be published. By default set to ’localhost’.
• ZeroMQ_redis_port - The port that Redis is listening on. By default set to
6379.
• ZeroMQ_redis_password - The password, if set for Redis. Emtpy by default.
• ZeroMQ_redis_database - The database to be used for queuing messages
for the pub/sub functionality. By default set to ’1’.
• ZeroMQ_redis_namespace - The namespace to be used for queuing messages
for the pub/sub functionality. By default set to ’mispq’.
27
29. • RPZ_policy - The default policy action for the values added to the RPZ. 0
means DROP, 1 NXDOMAIN, 2 NODATA and 3 walled-garden. By default
set to 0.
• RPZ_walled_garden - The default walled garden used by the RPZ export.
By default set to ’127.0.0.1’.
• RPZ_serial - The serial in the SOA portion of the zone file. By default set
to ’$date00’.
• RPZ_refresh - The refresh specified in the SOA portion of the zone file. By
default set to ’2h’.
• RPZ_retry - The retry specified in the SOA portion of the zone file. By
default set to ’30m’.
• RPZ_expiry - The expiry specified in the SOA portion of the zone file. By
default set to ’30d’.
• RPZ_minimum_ttl - The minimum TTL specified in the SOA portion of
the zone file. By default set to ’1h’.
• RPZ_ttl - The TTL of the zone file. By default set to ’1w’.
• RPZ_ns - The RPZ ns. By default set to ’localhost’.
• RPZ_email - The e-mail address specified in the SOA portion of the zone
file. By default set to ’root.localhost’.
• sightings_anonymise - Enabling the anonymisation of sightings will simply
aggregate all sightings instead of showing the organisations that have re-
ported a sighting. By default set to false.
• sightings_policy - This setting defines who will have access to seeing the
reported sightings. 0 means event owner, 1 event owner and sighting reporter
and 2 means everyone. By default set to 0.
• sightings_enable - When enabled, users can use the UI or the appropriate
APIs to submit sightings data about indicators. By default set to false.
• export_services_enable - Enable/disable the import services. By default set
to true.
• export_services_url - The url used to access the export services. By default
set to ’http://127.0.0.1’.
28
30. • export_services_port - The port used to access the export services. By
default set to 6666.
• export_timeout - Set a timeout for the import services. By default set to
10.
• import_services_enable - Enable/disable the import services. By default
set to true.
• import_services_url - The url used to access the import services. By default
set to ’http://127.0.0.1’.
• import_services_port - The port used to access the import services. By
default set to 6666.
• import_timeout - Set a timeout for the import services. By default set to
10.
• enrichment_services_enable - Enable/disable the enrichment services. By
default set to true.
• enrichment_services_url - The url used to access the enrichment services.
By default set to ’http://127.0.0.1’.
• enrichment_services_port - The port used to access the enrichment services.
By default set to 6666.
• enrichment_timeout - Set a timeout for the enrichment services. By default
set to 10.
• enrichment_hover_enable - Enable/disable the hover over information re-
trieved from the enrichment modules. By default set to true.
• enrichment_hover_timeout - Set a timeout for the hover services. By default
set to 5.
ApacheShibbAuth
• shib_default_org - Default organisation for user creation when using Shib-
boleth authentication plugin. By default set to 1.
• egroup_role_match - Group to role mapping used for authorization when
using Shibboleth authentication plugin. Empty by default ({}).
29
31. Services
• webservername - The name of the service of the web server on top of which
MISP is running. By default httpd.
• redis_server - If the redis database will be installed locally or not, meaning
that the redis server will be installed. By default true.
30
![Project Specification
MISP, Malware Information Sharing Platform and Threat Sharing, is an open
source software solution for collecting, storing, distributing and sharing cyber se-
curity indicators and threats about cyber security incidents analysis and malware
analysis [1][2][3]. Previously to the work described it this report the MISP login
capabilities were limited, with the default being the basic user and password based
authentication. One of the main objectives of the project was to enhance MISP
with Single Sign-On capabilities in order to make use of CERN’s centralized login
system.
Furthermore, one important functionality of the MISP platform is allowing
Indicators of Compromise (IoCs) to be exported in a format that an Intrusion
Detection System (IDS) can digest. The primary IDS used at CERN is Bro [4][5].
Until now MISP did not have the ability to export IoCs natively for Bro. Therefore
a second objective of the project was to enhance the export capabilities of MISP
by allowing it to export IoCs in the native format used by the Bro intelligence
framework.
IoCs are organized in "Events", which can contain one or more "Attribute".
These attributes are the actual IoC, meaning that is there were the specific in-
formation is stored (e.g. the IP address of an attacker). Moreover, events can be
tagged with the default tags included in MISP or with custom ones added by the
administrators. In addition, events correlations are detected by MISP and shown
in the web interface. Two events are understood as related if they have a matching
attribute (e.g. an IP address present in two events).
The deployment of a MISP instance may be tedious due to the many dependen-
cies required and the fact that it does not come packaged. Instead the installation
of various MISP versions is managed by Git [6] version tags. In this scope the ob-
jective was to develop a Puppet module that handles dependencies, installation,
configurations and services management; and a Puppet manifest which makes use
of it and other needed modules in order to successfully deploy a MISP instance.
1](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)