--- /dev/null
+Access & Identity
+----------------
+
+Access & Identity Intro
+
+.. toctree::
+ :maxdepth: 2
+
+ access_identity/keystone
+ access_identity/multi_site
--- /dev/null
+========
+Keystone
+========
+Authentication is an integral part of any real world OpenStack
+deployment and so careful thought should be given to this aspect of
+system design. A complete treatment of this topic is beyond the scope of
+this guide however some key topics are presented in the following
+sections.
+
+At its most basic, authentication is the process of confirming identity
+- that a user is actually who they claim to be. A familiar example is
+providing a username and password when logging in to a system.
+
+The OpenStack Identity service (keystone) supports multiple methods of
+authentication, including user name & password, LDAP, and external
+authentication methods. Upon successful authentication, The Identity
+service provides the user with an authorization token used for
+subsequent service requests.
+
+Transport Layer Security (TLS) provides authentication between services
+and persons using X.509 certificates. Although the default mode for TLS
+is server-side only authentication, certificates may also be used for
+client authentication.
+
+
+Keystone Audit
+~~~~~~~~~~~~~~
+
+Authentication is an integral part of any real world OpenStack
+deployment and so careful thought should be given to this aspect of
+system design. A complete treatment of this topic is beyond the scope of
+this guide however some key topics are presented in the following
+sections.
+
+At its most basic, authentication is the process of confirming identity
+- that a user is actually who they claim to be. A familiar example is
+providing a username and password when logging in to a system.
+
+The OpenStack Identity service (keystone) supports multiple methods of
+authentication, including user name & password, LDAP, and external
+authentication methods. Upon successful authentication, The Identity
+service provides the user with an authorization token used for
+subsequent service requests.
+
+Transport Layer Security (TLS) provides authentication between services
+and persons using X.509 certificates. Although the default mode for TLS
+is server-side only authentication, certificates may also be used for
+client authentication.
--- /dev/null
+Multi Site
+----------
--- /dev/null
+======================
+Continuous Integration
+======================
--- /dev/null
+=========================
+Secure Coding Conventions
+=========================
+
+https://wiki.opnfv.org/security/securecode
+================
Compute Security
-----------------
+================
.. toctree::
- :maxdepth: 2
- compute/dacmaccontrols.rst
- compute/trust.rst
+ compute/hypervisor_security
+ compute/trusted_compute
+ compute/image
+ compute/direct_peripheral
+ compute/libvirt_grants
--- /dev/null
+========================
+Direct Peripheral Access
+========================
+.. toctree::
+ :maxdepth: 2
+
+ sr_iov
+ dpdk
--- /dev/null
+====
+DPDK
+====
+
+The Data Plane Development Kit (DPDK) is a set of data plane libraries and
+network interface controller drivers for fast packet processing.
+
+The DPDK provides a programming framework for Intel x86 processors and enables
+faster development of high speed data packet networking applications.
+
+It scales from Intel Atom processors to Intel Xeon processors and support for
+other processor architectures like IBM POWER8 are under progress.
+
+It is provided and supported under the open source BSD license.
+
+OPNFV Upstream Project: `DPACC <https://wiki.opnfv.org/dpacc>`_
+
+
+Security Considerations
+#######################
+
+Multi-process Limitations
+*************************
+
+There are a number of limitations to what can be done when running DPDK
+multi-process applications. Some of these are documented below:
+
+The multi-process feature requires that the exact same hugepage memory mappings
+be present in all applications.
+
+The Linux security feature - Address-Space Layout Randomization (ASLR) can
+interfere with this mapping, so it may be necessary to disable this feature in
+order to reliably run multi-process applications.
+
+Disabling Address-Space Layout Randomization (ASLR) may have security
+implications, so it is recommended that it be disabled only when absolutely
+necessary, and only when the implications of this change have been understood.
+
+For more details, refer to the DPDK documentation
+
+http://dpdk.org/doc/guides/prog_guide/multi_proc_support.html
+
+Pause Frame Exploit
+*******************
+
+Pause frame exploits are currently not possible, due to flow controls being
+disabled in DPDK (as of time of writing)
+
+http://seclists.org/oss-sec/2015/q4/425.
+
+This means that adequate protection against tcp-incast would not be present,
+until the dpdk code is remedied to provide some form of frame management.
--- /dev/null
+===================
+Hypervisor Security
+===================
+
+
+MAC & DAC Controls
+~~~~~~~~~~~~~~~~~~
+https://libvirt.org/drvqemu.html#securityselinux
--- /dev/null
+==============
+Image Security
+==============
+OpenStack Image service (glance) provides discovery, registration, and delivery
+services for disk and server images. It provides the ability to copy or snapshot
+a server image, and immediately store it away. Stored images can be used as a
+template to get new servers up and running quickly and more consistently than
+installing a server operating system and individually configuring additional
+services.
+
+In order to prevent a comprised / untrusted VNF from running on the
+infrastructure, it is important to insure integrity of glance images
+
+<TBC>
+
+Image Signing
+~~~~~~~~~~~~~
--- /dev/null
+======
+SR-IOV
+======
+
+Single Root Input / Output Virtualization (SR-IOV), is a specification by the
+PCI-SIG organization. SR-IOV allows a single Peripheral Component Interconnect
+Express (PCIe) physical device under a single root port, to appear to be
+multiple separate physical devices to the hypervisor or guest virtual machine.
+
+This form of direct access (in comparison to a bridged interface) gives the
+same performance benefit of assigning a physical PCI device to a guest, however,
+it eliminates the need for multiple physical PCI devices, and the administrative
+complications of managing a large number of devices (these are typically NICs or
+HBAs, so there's cabling involved). Because the guest OS is effectively driving
+the hardware directly, the I/O performance is on par with bare metal performance.
+
+This provides a definite improvement over emulated I/O devices or paravirtual
+I/O devices.
+
+SR-IOV provides physical functions (PFs) and virtual functions (VFs) to manage
+global functions for SR-IOV devices.
+
+SR-IOV support is implemented in the kernel of the hypervisor, with driver
+support required for both the Physical Function (PF) and Virtual Function (VF)
+devices.
+
+SR-IOV must also be enabled in the compute units BIOS.
+
+Security Considerations
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Pause frame Denial of Service
+
+If a SR-IOV enabled device has a single link to the edge switch, the device
+aggregates all traffic, both from the trusted host and from the untrusted
+guests, and sends it on the single shared link.
+
+As a result, untrusted guests can send any network frames to the edge switch.
+
+This trusted port aggregation means that it is possible for a untrusted VM to
+send MAC frame which carries a PAUSE frame. Priority-based flow control, as
+defined in the IEEE 802.1Qbb, allows an overwhelmed network node can send a
+PAUSE frame, which halts the transmission of the sender for a specified period
+of time.
+
+Remediations
+
+The pause frame attack was discovered by Igor Smolyar, Muli Ben-Yehuda,
+and Dan Tsafrir, Technion—Israel Institute of Technology and CVE was raised
+12/2015 http://seclists.org/oss-sec/2015/q4/425.
+
+Subsequently hardware vendors such as Intel, Qlogic provided patched drivers.
+
+Thus it is recommended that the latest drivers be installed on the host system.
+
+Another more rudimentary form of protection is to block flow control on the
+edge switch (or a similar role device), however this brings with it
+complications.
+
+Flow control can be used to mitigate TCP incast problems.
+
+TCP incast is a many-to-one communication pattern, typical in cloud and big data
+scenarios.
+
+A parent server could request update data or objects from multiple child nodes,
+which receive the request simultaneously. The cluster of Nodes may in turn all
+synchronously respond to the singular Parent.
+
+The result is a micro burst of many machines simultaneously sending TCP data
+streams to one machine (many to one).
--- /dev/null
+===============
+Trusted Compute
+===============
+
+Compute security relates to the compute nodes in an OPNFV deployment.
+Compute nodes host various componants such as the hypervisor itself KVM-QEMU,
+and its serving eco-system, such as Nova (which interacts with the hypervisor
+using libvirt driver).
+
+We also cover other aspects of what is considered compute security, such as
+trusted boot / pools, although of course, these can be extended to other actors
+such as neutron networking nodes.
+
+Secure Boot
+~~~~~~~~~~~
+
+Trusted Compute Pools
+~~~~~~~~~~~~~~~~~~~~~
+=================
How to Contribute
------------------
+=================
-Anyone is welcome to make additions, raise bugs, and fix issues within this Documentation.
-To do so, you will however need to first get an enviroment set up.
+Anyone is welcome to make additions, raise bugs, and fix issues within this
+Documentation.
+
+To do so, you will however need to first get an environment set up.
Development Environment
-#######################
+~~~~~~~~~~~~~~~~~~~~~~~
+
+All project data such as formatting guidelines, and upstream mapping is
+documented via sphinx which uses reStructuredText
+
+Git / Gerrit Setup
+~~~~~~~~~~~~~~~~~~
+
+For the below to work, you will need to have a linux foundation account setup,
+and have added your public SSH key to gerrit.
+
+Clone the opnfvdocs repo
+
+.. code-block:: bash
+
+ git clone ssh://<your-username>@gerrit.opnfv.org:29418/opnfvdocs
+
+Change to new repo directory
+
+.. code-block:: bash
+
+ cd opnfvdocs/docs/opnfvsecguide
-All project data such as formatting guidelines, and upstream mapping is documented via sphinx
-which uses reStructuredText
+Set up gerrit review
-It is recommended that you use a python virtualenv to keep things clean and contained.
+.. code-block:: bash
-VirtualEnv
-**********
+ git review -s
-Use of a virtual environment is recommended, as not only is it a quick easy form of
-getting the needed modules in place, it isolates the module versions to a project.
+Now make your changes to the documentation, and then perform a git add to
+'stage' the changes.
-From within your inspector directory, set up a new virtualenv::
+.. code-block:: bash
- virtualenv venv
+ git add .
-Activate the new virtual environment::
+* If you prefer, you can cherry pick a change i.e.
- source venv/bin/activate
+.. code-block:: bash
-Install requirements::
+ git add myfile.txt
- pip install -r requirements.txt
+Then commit and signoff
+
+.. code-block:: bash
+
+ git commit -a --signoff
+
+Add a descriptive change of what you did, and save out of the commit window
+(so if your in vi then :wq) and make a push for review.
+
+.. code-block:: bash
+
+ git review
+
+Now await for core reviewers to +1 and it will get built to artefacts ,
+you will see the url on the gerrit page returned by git review.
+
+Here is an example:
+
+.. code-block:: bash
+
+ [hinds@casper opnfvsecguide] $ git review
+ remote: Resolving deltas: 100% (6/6)
+ remote: New file detected, please ensure that it has the correct license header
+ remote: Processing changes: new: 1, refs: 1, done
+ remote:
+ remote: New Changes:
+ remote: https://gerrit.opnfv.org/gerrit/7825
+ remote:
+ To ssh://lukehinds@gerrit.opnfv.org:29418/opnfvdocs.git
+ [new branch] HEAD -> refs/publish/master
Sphinx Basics
-*************
+~~~~~~~~~~~~~
+
+To get started with sphinx, `visit <http://sphinx-doc.org/tutorial.html/>`_ the main tutorial which will provide a
+primer.
+
+Remember doc8 to save build rejection
+
+D001
+lines should not be longer than 79 characters, plus some exceptions
+
+D002
+no trailing whitespace
+
+D003
+no tabulation for indentation
+
+D004
+no carriage returns (use unix newlines)
+
+Verify & Build Locally
+~~~~~~~~~~~~~~~~~~~~~~
+
+Navigate to the root folder 'opnfvdocs/'
+
+Install a virtualenv
+
+.. code-block:: bash
+
+ virtualenv env
+
+Source the env:
+
+.. code-block:: bash
+
+ source env/bin/activate
+
+Install doc8 and sphinx
+
+.. code-block:: bash
+
+ pip install sphinx doc8
+
+Clone releng:
+
+.. code-block:: bash
+
+ git clone ssh://lukehinds@gerrit.opnfv.org:29418/releng
+
+You can now test and build locally
-To get started with sphinx, visit the main tutorial which will provide a primer `http://sphinx-doc.org/tutorial.html`
+.. code-block:: bash
-Hack your changes into opnfv-security-guide/source
+ ./releng/utils/docs-build.sh
-To compile changes:
+Its also worth dumping the stdout into a file to inspect post run
- make html
+.. code-block:: bash
-From here you can run a basic python web server or just navigate to the
-file:///<repo>/opnfv-security-guide/build/html/index.html in your browser
+ ./releng/utils/docs-build.sh > build.txt
--- /dev/null
+=====================
+Host Operating System
+=====================
-.. OPNFV Security Guide documentation master file, created by
- sphinx-quickstart on Tue Oct 27 19:30:29 2015.
- You can adapt this file completely to your liking, but it should at least
- contain the root `toctree` directive.
-
Welcome to OPNFV Security Guide
-================================================
+*******************************
This guide seeks to inform operators who to secure and maintain the security of the OPNFV Platform and its components.
Contents:
.. toctree::
- :maxdepth: 2
introduction
compute
network
+ access_identity
+ key_management
+ messaging
+ storage
+ tenant
+ ci
+ host_os
+ inspector
+ code
+ osvm
contribution
-
-
-
-Indices and tables
-==================
-
-* :ref:`genindex`
-* :ref:`modindex`
-* :ref:`search`
-
--- /dev/null
+=========
+Inspector
+=========
+
+Inspector is an OPNFV project, to ensure the existing Audit framework for the
+critical components in OPNFV is extensive enough and compliant to industry
+standards and foreseeable business use cases.
+
+The benefit is that:
+
+Any NFV deployment will be easily checked for compliance towards relevant audit
+frameworks and that any necessary extensions to CADF are identified
+It will be possible to assess the integrity of audit logs
+For any NFV provider, it is necessary to provide audit data relevant to the
+specific industry requirements in a standard format
Introduction
---------------
-The OPNFV Security Guide is the collaborative work of many individuals,
-involved in both the OPNFV Security Group and the wider OPNFV community.
+The OPNFV Security Guide is the collaborative work of many individuals, involved
+in both the OPNFV Security Group and the wider OPNFV community.
-The purpose of this guide is to provide the best practice security guidelines for
-deploying the OPNFV platfornm. It is a living document that is updated as
-new changes are merged into it's repository.
+The purpose of this guide is to provide the best practice security guidelines
+for deploying the OPNFV platform. It is a living document that is updated as new
+changes are merged into it's repository.
.. toctree::
:maxdepth: 2
introduction/background
+ introduction/intended_audience
introduction/acknowledgements
Pre-virtualization security protection was largely centered on the network.
Malicious attacks from hostile machines, would seek to exploit network based
-operating systems and applications, with the goal of compromising their
-target node.
+operating systems and applications, with the goal of compromising their target
+node.
Physical security had always been a much simpler business, with most focus on
the secure access of the data center hardware.
-In-turn security was built up in layers (defense in depth) where machines
-would be
-daisy chained with network cables via security appliances to provide
+
+In-turn security was built up in layers (defense in depth) where machines would
+be daisy chained with network cables via security appliances to provide
controlled segmentation and isolation.
-This form of security was built upon the principle of an 'air gap'
-being present,
-whereby machines were separate physical units, joined largely by the
-network stack.
-With the advent of virtualization (namely the hypervisor), new attack
-vectors have
-surfaced as the 'air-gap' is no longer key design aspect for security.
-Further to this elements orchestation nodes and network controllers
-lead to an even wider attack surface:
+This form of security was built upon the principle of an ‘air gap’ being present
+, whereby machines were separate physical units, joined largely by the network
+stack.
+
+With the advent of virtualization (namely the hypervisor), new attack vectors
+have surfaced as the ‘air-gap’ is no longer key design aspect for security.
+
+Further to this elements orchestation nodes and network controllers lead to an
+even wider attack surface:
* Guests breaking isolation of the hypervisor.
* Unauthorized access and control of supporting overlay network control systems.
-The hypervisor and the overlay network have now become the 'Achilles heel'
+The hypervisor and the overlay network have now become the ‘Achilles heel’
whereby all tenant data isolation is enforced within the hypervisor and its
-abstraction
-of hardware and the virtualized overlay network.
+abstraction of hardware and the virtualized overlay network.
This guide has been formulated, in order to assist users of the OPNFV platform
in securing an Telco NFV / SDN environment.
--- /dev/null
+Intended Audience
+-----------------
--- /dev/null
+==============
+Key Management
+==============
+
+
+PKI
+~~~
--- /dev/null
+==================
+Messaging Security
+==================
+
+
+RabbitMQ
+~~~~~~~~
+================
Network Security
-----------------
-
+================
.. toctree::
:maxdepth: 2
- network/neutron
+ network/design_concepts
+ network/overlay_security
+ network/sdn_security
+ network/service_forward_chain
+ network/nfv_edge
+ network/north_south
+ network/east_west
--- /dev/null
+================
+Attack Resilence
+================
--- /dev/null
+===================
+Controller Security
+===================
--- /dev/null
+===============
+Design Concepts
+===============
--- /dev/null
+====================
+East West Protection
+====================
--- /dev/null
+=================
+Integrity & Trust
+=================
--- /dev/null
+========
+NFV Edge
+========
--- /dev/null
+======================
+North South Protection
+======================
+
+Perimiter
+~~~~~~~~~
+
+
+Lights Out Management
+~~~~~~~~~~~~~~~~~~~~~
+
--- /dev/null
+================
+Overlay Security
+================
--- /dev/null
+============
+SDN Security
+============
+
+.. toctree::
+ :maxdepth: 2
+
+ controller_security
+ integrity_trust
+ attack_resilence
--- /dev/null
+=====================
+Service Forward Chain
+=====================
--- /dev/null
+=======================================
+OPNFV Security Vulnerability Management
+=======================================
+
+The OSVM process is the manage and coordinate the progressive disclosure and
+management of vulnerabilities reported or discovered within the opnfv-eco system
+and upstream projects.
+
+The process inherits from the already present and well functioning OSSG VMT
+Process and follows the Responsible Disclosure Approach.
+
+.. image:: images/osvm.png
+
+The opnfv osvm process is licensed under CC Attribution 3.0 Unported and was
+kindly granted use to us by the OpenStack vulnerability Management Team.
+
+New additions / refinements made by the opnfv security group are also under the
+3.0 Unported license.
--- /dev/null
+================
+Storage Security
+================
+
+CEPH
+~~~~
--- /dev/null
+===============
+Tenant Security
+===============
+
+.. toctree::
+ :maxdepth: 2
+
+ tenant/traffic_encryption
+ tenant/zoning
+ tenant/guest_integrity
+ tenant/monitoring
+ tenant/access_control
+ tenant/entropy
--- /dev/null
+==============
+Access Control
+==============
--- /dev/null
+==============
+Secure Entropy
+==============
--- /dev/null
+===============
+Guest Integrity
+===============
+
+Host IDS
+~~~~~~~~
+
+Image Singing
+~~~~~~~~~~~~~
--- /dev/null
+=================
+Secure Monitoring
+=================
--- /dev/null
+==================
+Traffic Encryption
+==================
--- /dev/null
+=============
+Secure Zoning
+=============
Code Review / opnfvdocs.git / commitdiff
