diff --git a/README.md b/README.md
index 30fe269..d91ed58 100644
--- a/README.md
+++ b/README.md
@@ -1,4 +1,28 @@
-security-notes
-==============
-
 OpenStack Security Notes (OSSN)
+===============================
+
+The OpenStack Security Group (OSSG) publishes Security Notes to advise users
+of security related issues. Security notes are similar to advisories; they
+address vulnerabilities in 3rd party tools typically used within OpenStack
+deployments and provide guidance on common configuration mistakes that can
+result in an insecure operating environment. 
+
+Repository Layout
+-----------------
+
+This repository contains published Security Notes and templates that should
+be used when creating new Security Notes.
+
+    notes - contains Security Notes in e-mail format (see the templates)
+    templates - contains e-mail and wiki format templates
+
+Useful Links
+------------
+
+A list of published Security Notes is available here:
+
+    https://wiki.openstack.org/wiki/Security_Notes
+
+The process used to create new Security Notes is available here:
+
+    https://wiki.openstack.org/wiki/Security/Security_Note_Process
diff --git a/notes/OSSN-0001 b/notes/OSSN-0001
new file mode 100644
index 0000000..fa3cdd6
--- /dev/null
+++ b/notes/OSSN-0001
@@ -0,0 +1,46 @@
+Selecting LXC as Nova Virtualization Driver can lead to data compromise
+---
+
+### Summary### 
+LXC does not provide the same level of separation as hypervisors when chosen as
+the Nova 'virtualization driver'. Attempting to use LXC as a drop in
+replacement for a hypervisor can result in data exposure between tenants.
+
+### Affected Services / Software ###
+Nova, LXC, Libvirt, 'Virtualization Driver'
+
+### Discussion ###
+The Libvirt LXC functionality exposed by OpenStack is built on the kernel
+namespace & cgroup technologies. Until Linux 3.8, there has been no support for
+separate user namespaces in the kernel. As such, there has been no way to
+securely isolate containers from each other or the host environment using DAC
+(discretionary access control). For example, they can escape their resource
+constraints by modifying cgroups settings, or attack the host via various files
+in the proc and sysfs filesystems. The use of MAC (mandatory access control)
+technologies like SELinux or AppArmour can mitigate these problems, but it is
+not practical to write MAC policies that would allow running full OS installs
+in LXC under OpenStack.
+
+Although initial user namespace support was merged in Linux 3.8, it is not yet
+complete, or mature enough to be considered secure. Work is ongoing to finish
+the kernel namespace support and enhance libvirt LXC to take advantage of it.
+
+### Recommended Actions ###
+The OSSG advises that anyone deploying Nova in environments that require any
+level of separation use a hypervisor such as Xen, KVM, VMware or Hyper-V.
+
+LXC security pivots on a system known as DAC (discretionary access control)
+which is not currently capable of providing strong isolation of guests. Work is
+underway to improve DAC but it’s not ready for production use at this time.
+
+The OSSG recommends against using LXC for enforcing secure separation of guests.
+Even with appropriate AppArmour policies applied.
+
+### Contacts / References ###
+Nova : http://docs.openstack.org/developer/nova/
+LXC : http://lxc.sourceforge.net/
+Libvirt : http://libvirt.org/
+KVM : http://www.linux-kvm.org/page/Main_Page
+Xen: http://xen.org/products/xenhyp.html
+LXC DAC : https://wiki.ubuntu.com/UserNamespace
+LXC LibVirt Discussion : https://www.berrange.com/posts/2011/09/27/getting-started-with-lxc-using-libvirt/
diff --git a/notes/OSSN-0002 b/notes/OSSN-0002
new file mode 100644
index 0000000..cd7f77e
--- /dev/null
+++ b/notes/OSSN-0002
@@ -0,0 +1,36 @@
+HTTP POST limiting advised to avoid Essex/Folsom Keystone DoS
+---
+
+### Summary ###
+Concurrent Keystone POST requests with large body messages are held in memory
+without filtering or rate limiting, this can lead to resource exhaustion on the
+Keystone server.
+
+### Affected Services / Software ###
+Keystone, Databases
+
+### Discussion ###
+Keystone stores POST messages in memory before validation, concurrent
+submission of multiple large POST messages can cause the Keystone process to be
+killed due to memory exhaustion, resulting in a remote Denial of Service.
+
+In many cases Keystone will be deployed behind a load-balancer or proxy that
+can rate limit POST messages inbound to Keystone. Grizzly is protected
+against that through the sizelimit middleware.
+
+### Recommended Actions ###
+If you are in a situation where Keystone is directly exposed to incoming POST
+messages and not protected by the sizelimit middleware there are a number of
+load-balancing/proxy options, we suggest you consider one of the following:
+
+Nginx: Open-source, high-performance HTTP server and reverse proxy.
+Nginx Config: http://wiki.nginx.org/HttpCoreModule#client_max_body_size
+
+Apache: HTTP Server Project
+Apache Config: http://httpd.apache.org/docs/2.4/mod/core.html#limitrequestbody
+
+### Contacts / References ###
+This OSSN Bug: https://bugs.launchpad.net/ossn/+bug/1155566
+Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+bug/1098177
+OpenStack Security ML : openstack-security@lists.openstack.org
+OpenStack Security Group : https://launchpad.net/~openstack-ossg
diff --git a/notes/OSSN-0003 b/notes/OSSN-0003
new file mode 100644
index 0000000..fe2542c
--- /dev/null
+++ b/notes/OSSN-0003
@@ -0,0 +1,44 @@
+Keystone configuration should not be world readable
+---
+
+### Summary ###
+In some deployments keystone.conf which contains confidential information, is
+set to world readable.
+
+### Affected Services / Software ###
+Keystone, DevStack, Deployment
+
+### Discussion ###
+It is important that deployers of OpenStack ensure that keystone.conf is not
+world readable. In some deployments the keystone configuration file is readable
+by all users (and processes) on the installation system. This file should be
+set with the most restrictive permissions that allow the system to continue
+proper operations.
+
+In particular, the password configuration of the LDAP section and the
+admin_token contain secret information:
+
+---- being example config snippet ----
+[ldap]
+url = ldap://localhost
+user = dc=Manager,dc=example,dc=com
+password = None <- should be secret
+suffix = cn=example,cn=com
+use_dumb_member = False
+allow_subtree_delete = False
+dumb_member = cn=dumb,dc=example,dc=com
+
+[DEFAULT]
+admin_token = passw0rd <- should be secret
+---- end example config snippet ----
+
+### Recommended Actions ###
+Ensure that in your deployment keystone.conf uses the most restrictive
+permissions that allow the system to continue proper operations.
+
+### Contacts / References ###
+This OSSN : https://bugs.launchpad.net/ossn/+bug/1168252
+Original LaunchPad Bug : https://bugs.launchpad.net/devstack/+bug/1168252
+OpenStack Security ML : openstack-security@lists.openstack.org
+OpenStack Security Group : https://launchpad.net/~openstack-ossg
+CVE: CVE-2013-1977
diff --git a/notes/OSSN-0004 b/notes/OSSN-0004
new file mode 100644
index 0000000..a2dbda1
--- /dev/null
+++ b/notes/OSSN-0004
@@ -0,0 +1,60 @@
+Authenticated users are able to update passwords without providing their
+current password
+---
+
+### Summary ###
+An authenticated user is able to change their password without providing their
+current password. This allows compromised authentication tokens to be used to
+permanently compromise a user account.
+
+### Affected Services / Software ###
+Horizon, Keystone, Identity, Grizzly
+
+### Discussion ###
+Horizon allows a user to change their own password, which uses the Identity API
+to perform the password change. A user is required to supply their current
+password to successfully perform a password change. This requirement prevents a
+malicious user from stealing a user's authentication token and changing that
+user's password to permanently compromise their account. With this additional
+password check, a compromised authentication token only compromises the user
+account until the token is no longer valid due to expiration or revocation.
+
+When using the Identity v3 API, a user is able to successfully change their
+password without supplying the correct current password. This leaves users
+vulnerable to permanently compromised accounts if their authentication token is
+compromised. The Identity v2 API is not vulnerable to this issue, as it has a
+separate API call for updating user passwords that properly validates the
+current password.
+
+### Recommended Actions ###
+In the OpenStack Grizzly release, a user is allowed to update the attributes in
+their own entry by default. It is recommended that you restrict user updates to
+only be allowed by admin users. This is done by setting the "update_user"
+policy to "admin_required" in Keystone's policy.json file. Here is an example
+snippet of a properly configured policy.json file:
+
+---- begin example policy.json snippet ----
+    "identity:get_user": [["rule:admin_required"]],
+    "identity:list_users": [["rule:admin_required"]],
+    "identity:create_user": [["rule:admin_required"]],
+    "identity:update_user": [["rule:admin_required"]],
+    "identity:delete_user": [["rule:admin_required"]],
+---- end example policy.json snippet ----
+
+This change has the side-effect of restricting a user from updating any of
+their own attributes, not just their password.
+
+In the OpenStack Havana release, the default policy is to only allow admin
+users to update attributes in user entries. In addition, Horizon will not
+allow a user to change their own password if it is using the Identity v3 API,
+even if Keystone is configured to allow users to update their own entries.
+Despite this restriction in Horizon, it is recommended to leave the default
+"update_user" policy setting as is, as an attacker could target Keystone
+directly without using Horizon to initiate a password change.
+
+### Contacts / References ###
+This OSSN : https://bugs.launchpad.net/ossn/+bug/1237989
+Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+bug/1237989
+OpenStack Security ML : openstack-security@lists.openstack.org
+OpenStack Security Group : https://launchpad.net/~openstack-ossg
+CVE: CVE-2013-4471
diff --git a/notes/OSSN-0005 b/notes/OSSN-0005
new file mode 100644
index 0000000..be4c410
--- /dev/null
+++ b/notes/OSSN-0005
@@ -0,0 +1,54 @@
+Glance allows sharing of images between projects without consumer project
+approval
+---
+
+### Summary ###
+Glance allows images to be shared between projects. In certain API versions,
+images can be shared without the consumer project's approval. This allows
+potentially malicious images to show up in a project's image list.
+
+### Affected Services / Software ###
+Glance, Image Service, Diablo, Essex, Folsom, Grizzly, Havana
+
+### Discussion ###
+Since the OpenStack Diablo release, Glance allows images to be shared between
+projects. To share an image, the producer of the image adds the consumer
+project as a member of the image. When using the Image Service API v1, the
+image producer is able to share an image with a consumer project without their
+approval. This results in the shared image showing up in the image list for the
+consumer project. This can mislead users with roles in the consumer project
+into running a potentially malicious image.
+
+The Image Service API v2.0 does not allow image sharing between projects, so a
+project is not susceptible to running unauthorized images shared by other
+projects. The Image Service API v2.1 allows image sharing using a two-step
+process. An image producer must add a consumer as a member of the image, and
+the consumer must accept the shared image before it shows up in their image
+list. This additional approval process allows a consumer to control what images
+show up in their image list, thus preventing potentially malicious images being
+used without the consumers knowledge.
+
+### Recommended Actions ###
+In the OpenStack Diablo, Essex, and Folsom releases, Glance supports image
+sharing using the Image Service API v1. There is no way to require approval of
+a shared image by consumer projects. Users should be cautioned to be careful
+when using images from their image list, as they may be using an image that was
+shared with them without their knowledge.
+
+In the OpenStack Grizzly and Havana releases, Glance supports the Image Service
+API v2.1 or later. Support is still provided for Image Service API v1, which
+allows image sharing between projects without consumer project approval. It is
+recommended to disable v1 of the Image Service API if possible. This can be
+done by setting the following directive in the glance-api.conf configuration
+file:
+
+---- begin example glance-api.conf snippet ----
+enable_v1_api = False
+---- end example glance-api.conf snippet ----
+
+### Contacts / References ###
+This OSSN : https://bugs.launchpad.net/ossn/+bug/1226078
+Original LaunchPad Bug : https://bugs.launchpad.net/glance/+bug/1226078
+OpenStack Security ML : openstack-security@lists.openstack.org
+OpenStack Security Group : https://launchpad.net/~openstack-ossg
+CVE: CVE-2013-4354
diff --git a/notes/OSSN-0006 b/notes/OSSN-0006
new file mode 100644
index 0000000..c9618b5
--- /dev/null
+++ b/notes/OSSN-0006
@@ -0,0 +1,63 @@
+Keystone can allow user impersonation when using REMOTE_USER for external
+authentication
+---
+
+### Summary ###
+When external authentication is used with Keystone using the "ExternalDefault"
+plug-in, external usernames containing "@" characters are truncated at the "@"
+character before being mapped to a local Keystone user. This can result in
+separate external users mapping to the same local Keystone user, which could
+lead to user impersonation.
+
+### Affected Services / Software ###
+Keystone, Havana
+
+### Discussion ###
+When Keystone is run in the Apache HTTP Server, the webserver can handle
+authentication and pass the authenticated username to Keystone using the
+REMOTE_USER environment variable. External authentication behavior is handled
+by authentication plugins in Keystone. In the Havana release of OpenStack, if
+the external username provided in the REMOTE_USER environment variable
+contains an "@" character Keystone will only use the portion preceding the "@"
+character as the username when using the "ExternalDefault" authentication
+plugin. This results in the ability for multiple unique external usernames to
+map to the same single username in Keystone. For example, the external
+usernames "jdoe@example1.com" and "jdoe@example2.com" would both map to the
+Keystone user "jdoe". This behavior could potentially be abused to allow one to
+impersonate another similarly named external user.
+
+Keystone in OpenStack releases prior to Havana uses the entire value contained
+in the REMOTE_USER environment variable, so those versions are not vulnerable
+to this impersonation issue.
+
+### Recommended Actions ###
+If the "ExternalDefault" plugin is being used for external authentication in
+the Havana release, you should ensure that external usernames do not contain
+"@" characters unless you want to collapse similarly named external users into
+a single user on the Keystone side.
+
+If your external usernames do contain "@" characters and you do not want to
+collapse similarly named external users into a single user on the Keystone
+side, you might be able to use the "ExternalDomain" plug-in. This plugin
+considers the portion of the external username that follows an "@" character to
+be the domain that the user belongs to in Keystone. This allows similarly named
+external users to map to separate Keystone users if the portion of the external
+username that follows an "@" character maps to a Keystone domain name. To
+configure the "ExternalDomain" authentication plugin, set the "external"
+parameter in the "[auth]" section of Keystone's keystone.conf as follows:
+
+---- begin example keystone.conf snippet ----
+[auth]
+methods = external,password,token
+external = keystone.auth.plugins.external.ExternalDomain
+---- end example keystone.conf snippet ----
+
+If neither of the above recommendations work for your deployment, a custom
+authentication plugin can be created that uses the external username that
+contains an "@" character as-is.
+
+### Contacts / References ###
+This OSSN : https://bugs.launchpad.net/ossn/+bug/1254619
+Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+bug/1254619
+OpenStack Security ML : openstack-security@lists.openstack.org
+OpenStack Security Group : https://launchpad.net/~openstack-ossg
diff --git a/templates/email-template.txt b/templates/email-template.txt
new file mode 100644
index 0000000..d507389
--- /dev/null
+++ b/templates/email-template.txt
@@ -0,0 +1,26 @@
+Title (single sentence)
+---
+
+### Summary ###
+A few sentences describing the issue at a high level.
+
+### Affected Services / Software ###
+A comma separated list of affected services and OpenStack releases.
+ 
+### Discussion ###
+A detailed discussion of the problem.  This should have enough detail that the
+person reading can determine if their deployment is affected, when the problem
+was introduced, and what types of attacks/problems that an affected deployment
+would be exposed to.
+
+### Recommended Actions ###
+A detailed description of what can be done to remediate the problem (if
+possible).  If the recommendation involves configuration changes, example
+snippets of configuration files should be included here.
+
+### Contacts / References ###
+This OSSN : <link to launchpad OSSN bug>
+Original LaunchPad Bug : <link to launchpad bug for affected project/service>
+OpenStack Security ML : openstack-security@lists.openstack.org
+OpenStack Security Group : https://launchpad.net/~openstack-ossg
+CVE: <CVE number if one was filed>
diff --git a/templates/wiki-template.txt b/templates/wiki-template.txt
new file mode 100644
index 0000000..bbb81a2
--- /dev/null
+++ b/templates/wiki-template.txt
@@ -0,0 +1,26 @@
+__NOTOC__
+== Title (single sentence) ==
+
+=== Summary ===
+A few sentences describing the issue at a high level.
+
+=== Affected Services / Software ===
+A comma separated list of affected services and OpenStack releases.
+
+=== Discussion ===
+A detailed discussion of the problem.  This should have enough detail that the
+person reading can determine if their deployment is affected, when the problem
+was introduced, and what types of attacks/problems that an affected deployment
+would be exposed to.
+
+=== Recommended Actions ===
+A detailed description of what can be done to remediate the problem (if
+possible).  If the recommendation involves configuration changes, example
+snippets of configuration files should be included here.
+
+=== Contacts / References ===
+* This OSSN :<link to launchpad OSSN bug>
+* Original LaunchPad Bug : <link to launchpad bug for affected project/service>
+* OpenStack Security ML : openstack-security@lists.openstack.org
+* OpenStack Security Group : https://launchpad.net/~openstack-ossg
+* CVE: <CVE number if one was filed>