Skip to content
A virtual MediaWiki development environment, built on Vagrant, VirtualBox, and Puppet.
Puppet Ruby HTML Shell Python Gherkin Other
Branch: master
Clone or download
Pull request Compare This branch is 2 commits ahead, 757 commits behind wikimedia:master.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
.config plugin: Acceptance tests for `vagrant roles` Mar 10, 2015
cache Add the RESTBase and Cassandra roles to MW-Vagrant May 19, 2015
features
lib Add setting nfs_force_v3 to force NFS 3 Jul 6, 2016
logs/puppet Move Vagrant helpers to lib/mediawiki_vagrant.rb Jul 12, 2013
puppet Bump Semantic Forms to 3.7 Dec 1, 2016
settings.d Fix spelling in settings.d/README Apr 29, 2016
spec Add setting nfs_force_v3 to force NFS 3 Jul 6, 2016
srv Install non-vendor services to /vagrant/srv Apr 8, 2015
support Packager: Start README file with info about the ISO Jun 23, 2016
.arcconfig Add .arcconfig Jun 20, 2016
.gitattributes Make ISO README friendlier for Windows users Jan 10, 2015
.gitignore Add *.iml (IDEA Ultimate project files) to .gitignore Sep 24, 2015
.gitmodules
.gitreview In .gitreview: defaultrebase=0 Jun 26, 2013
.mailmap Update AUTHORS.txt and add .mailmap Mar 14, 2016
.puppet-lint.rc Make puppet-lint strict Oct 27, 2015
.rspec Unit tests for Environment class Feb 3, 2015
.rubocop.yml Fixed Style/SpecialGlobalVars RuboCop offense Nov 20, 2015
.rubocop_todo.yml
.yardopts Mention experimental providers in README Mar 20, 2015
AUTHORS.txt Update AUTHORS.txt and add .mailmap Mar 14, 2016
Gemfile Updated Vagrant Ruby gem to the latest version Feb 3, 2016
Gemfile.lock Bump Gemfile.lock versions Jul 6, 2016
HACKING.md Formalize conventions for Exec resources Jul 19, 2014
LICENSE Initial commit Sep 13, 2016
LocalSettings.php Use Redis for main stash by default (and regardless). May 11, 2016
README.md
Rakefile Fixed Style/PerlBackrefs RuboCop offence Nov 10, 2015
Vagrantfile Add setting nfs_force_v3 to force NFS 3 Jul 6, 2016
mediawiki-vagrant.gemspec Fixed Style/SpecialGlobalVars RuboCop offense Nov 20, 2015
setup.bat Setup script and commands for installation and configuration Jul 10, 2014
setup.sh Setup script and commands for installation and configuration Jul 10, 2014

README.md

Unfetter fork of mediawiki-vagrant

This is a fork of https://github.com/wikimedia/mediawiki-vagrant/ which provides a downloadable version of The MITRE Corporation's Cyber Analytics Repository (CAR) and Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK™) wikis. Along with CARET, the CAR Exploration Tool. For more information, please see https://mitre.github.io/unfetter

Install

  1. Install Virtualbox 5.0.26 and vagrant 1.8.1
  2. Perform all of the instructions for the normal mediawiki-vagrant installation but perform the git clone with the address of this repository. Do not download the zip file from this repository. It will not provide the needed submodules.
  • Per the mediawiki-vagrant instructions, run git submodule update --init --recursive followed by the appropriate setup script for your operating system.
  • Run the appropriate setup script for your platform (e.g., setup.bat or setup.sh).
  • If you receive an error when building the mediawiki-vagrant gem, make sure you're using the version of Vagrant specified in the Gemfile.lock file.
  1. After performing an initial vagrant up enter a vagrant roles enable unfetter to enable the Unfetter roles, which installs the CAR and ATT&CK wiki content.
  2. Enter vagrant provision to provision the VM according to the Unfetter role
  • We recommend disabling any proxies during setup. We have found that provisioning does not work well when using a proxy.
  1. Navigate to http://localhost:8080/ to view a version of CAR. A link to ATT&CK is list on the CAR landing page. CARET is located at http://localhost:8080/caret.

Adding New Groups, Analytics, and Sensors

The downloadable versions of CAR and ATT&CK are designed to be customizable for users to add new adversary groups (to ATT&CK) or analytics and sensors (to CAR).

Adding a New Group to ATT&CK

  1. On the navigation bar on the left hand side of the ATT&CK wiki there is a heading for “Groups.”
  2. Underneath the “Groups” heading is the option to “Add a Group.” Navigate to this page.
  3. On the “Create Group” page, you will see text boxes for “Alias” and “Description” as well as drop-down menus and fields for “Techniques” and “Software.” Complete these fields and hit save to register the entry.
  • Alias refers to the name(s) of the group.
  • Description is a brief summary of the group – such as what campaigns the group is responsible for and information about the attribution of the group.
  • Techniques Used are the ATT&CM techniques used. The open field may be used to explain how that particular group uses the ATT&CK technique.
  • Software is a field to list the named software used by the group.

Adding a New Analytic to CAR

  1. On the navigation bar on the left-hand side of the CAR wiki there is a heading for “Contribute.”
  2. Underneath the “Contribute” heading is the option “Analytics.” Navigate to this page.
  3. On the “Create Analytic” page, you will see text boxes for: Title, Hypothesis, Submission Date, Information Domain, Host/Network Subtypes, Network Protocols (where applicable), Type, Status, Output Description, ATT&CK Detection, Pseudocode, and Unit Tests (where applicable). Complete these fields and hit save to register the entry. For more information about the CAR Data Model, see “Data Model” under the “Coverage” heading of the navigation bar on the left hand side of the wiki.
  • Title refers to the name of the analytic.
  • Hypothesis refers to the question, challenge, or adversary behavior the analytic is trying to detect and how the user believes it can be detected.
  • Submission Date refers to when the analytic was created by the user.
  • Information Domain refers to where the analytic[1] applies and works to detect the adversary – either at the analytic, host, or network level.
  • Host/Network Subtypes refers to the object in the data model that must be monitored and gathered in order to obtain the data necessary to run the analytic.
  • Network Protocols applies to network analytics and refers to the specific protocol that contains the data (i.e., SMB).
  • Type refers to the types of analytics categorized by the CAR data model (TTP, Attribution, Posture/Hygiene, Situational Awareness, Forensic, Anomaly, Statistical, Investigative, Malware, Event Characterization).
  • Status refers to whether the analytic is actively being used in the system, in which case the status is listed as "active."
  • Output Description refers to the objects, actions, and fields in the data model the analytic detects. For more information, please see the Data Model page found on the left-hand navigation bar of the wiki.
  • ATT&CK Detection refers to the ATT&CK techniques, tactics, and level of coverage (moderate or complete) of the analytic.
  • Pseudocode refers to a description of how the analytic might be implemented.
  • Unit Tests refer to a test that can be run to trigger the analytic.

Adding a New Sensor to CAR

  1. On the navigation bar on the left-hand side of the CAR wiki there is a heading for “Contribute.”
  2. Underneath the “Contribute” heading is the option “Sensors.” Navigate to this page.
  3. On the “Create Sensor” page you will see options for: Title, Manufacturer, Release Date, Version, Website, Description, Analytic Coverage, Technique Coverage, and Data Model Coverage. Complete these fields and checkboxes and hit save to register the entry.
  • Title refers to the name of the sensor.
  • Manufacturer refers to the company producing the sensor.
  • Release Date refers to the Manufacturer’s release date for the sensor.
  • Version refers to the version of the sensor being used.
  • Website refers to the Manufacturer’s website for the sensor.
  • Description refers to what the sensor is, who it is owned by, what it does, what information it collects, and how.
  • Analytic Coverage is the analytics that use information from this sensor to produce results. Mapping a sensor to an analytic indicates that a sensor can be used in conjunction with an analytic to answer a question about a group’s ATT&CK technique coverage.
  • Technique Coverage is the ATT&CK techniques that a sensor can help identify when used in conjunction with particular analytics. Coverage is either not present (red), partial (yellow), or complete (green) in the colored boxes of the ATT&CK Matrix.
  • Data Model Coverage refers to the objects, actions, and fields within the Data Model that a sensor collects. The Data Model, inspired strongly by CybOX™, is an organization of the objects or observables that may be monitored on the host and from the network. Each object on the host can be identified by two dimensions: its actions and fields. When grouped together, the three-tuple of (object, action, field) acts like a coordinate, and describes what properties and state changes of the object can be captured by a sensor. Compare the Data Model's use in analytics that map to ATT&CK and its use for different sensors. For example, the “process” object of the Data Model requires fields such as “FQDN” and “Hostname” and must capture actions such as “create” and “terminate.” Some sensors are static/forensic rather than real-time in nature and do not capture the individual actions of the Data Model; thus, they have incomplete ATT&CK coverage, indicating an inability to use the analytics of CAR to detect an adversary completing a particular ATT&CK technique.

1: Select analytic when an analytic is designed to group other analytics together.
ATT&CK is a trademark of The MITRE Corporation.

Copyright 2016 The MITRE Corporation. ALL RIGHTS RESERVED.

You can’t perform that action at this time.