increment patch for release (via Makefile)

The word "is" was missing in the first sentence of Purpose and Scope.

.gitignore

@@ -1,3 +1,4 @@
 comply
 output
 dist
+.envrc

AUTHORS.txt

@@ -1,3 +1,12 @@
 # Authors in alphabetical order:
 
+arambhashura
+Alan Cox
+Andy Magnusson
+Anthony Oliver
+Justin Bodeutsch
 Justin McCarthy <justin@strongdm.com>
+Kevin N. Murphy
+Manisha Singh
+Mason Hensley
+Matt Simerson

Gopkg.lock

@@ -7,6 +7,12 @@
   revision = "7da180ee92d8bd8bb8c37fc560e673e6557c392f"
   version = "v0.4.7"
 
+[[projects]]
+  name = "github.com/andygrunwald/go-jira"
+  packages = ["."]
+  revision = "5cfdb85cc91c6299f75b6504a1d0ec174c21be39"
+  version = "v1.3.0"
+
 [[projects]]
   branch = "master"
   name = "github.com/chzyer/readline"
@@ -79,6 +85,12 @@
   revision = "507f6050b8568533fb3f5504de8e5205fa62a114"
   version = "v1.6.0"
 
+[[projects]]
+  name = "github.com/fatih/structs"
+  packages = ["."]
+  revision = "a720dfa8df582c51dee1b36feabb906bde1588bd"
+  version = "v1.0"
+
 [[projects]]
   name = "github.com/fsnotify/fsnotify"
   packages = ["."]
@@ -194,12 +206,27 @@
   packages = ["open"]
   revision = "75fb7ed4208cf72d323d7d02fd1a5964a7a9073c"
 
+[[projects]]
+  name = "github.com/trivago/tgo"
+  packages = [
+    "tcontainer",
+    "treflect"
+  ]
+  revision = "e4d1ddd28c17dd89ed26327cf69fded22060671b"
+  version = "v1.0.1"
+
 [[projects]]
   name = "github.com/urfave/cli"
   packages = ["."]
   revision = "cfb38830724cc34fedffe9a2a29fb54fa9169cd1"
   version = "v1.20.0"
 
+[[projects]]
+  name = "github.com/xanzy/go-gitlab"
+  packages = ["."]
+  revision = "79dad8e74fd097eb2e0fd0883f1978213e88107a"
+  version = "v0.10.7"
+
 [[projects]]
   name = "github.com/yosssi/ace"
   packages = ["."]
@@ -257,6 +284,6 @@
 [solve-meta]
   analyzer-name = "dep"
   analyzer-version = 1
-  inputs-digest = "4fd2ff9f9869c3f3e30601504f4b00fce69d282ae8df42583a1c60848bfd0766"
+  inputs-digest = "50dc710fa4b581d4fd6907e0e3337c53c3d530e46c53aa71ef9f8e80d3a54d8b"
   solver-name = "gps-cdcl"
   solver-version = 1

Makefile

@@ -19,12 +19,14 @@ dist: clean
 	$(eval LDFLAGS := -ldflags='-X "github.com/strongdm/comply/internal/cli.Version=$(VERSION)"')
 	mkdir dist
 	echo $(VERSION)
-	GOOS=darwin GOARCH=amd64 CGO_ENABLED=0 go build -gcflags=-trimpath=$(GOPATH) -asmflags=-trimpath=$(GOPATH) $(LDFLAGS) -o dist/comply-$(VERSION)-darwin-amd64 .
-	GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -gcflags=-trimpath=$(GOPATH) -asmflags=-trimpath=$(GOPATH) $(LDFLAGS) -o dist/comply-$(VERSION)-linux-amd64 .
+	GOOS=darwin GOARCH=amd64 CGO_ENABLED=0 go build -gcflags=-trimpath=$(GOPATH) -asmflags=-trimpath=$(GOPATH) -ldflags '-extldflags "-static"' $(LDFLAGS) -o dist/comply-$(VERSION)-darwin-amd64 .
+	GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -gcflags=-trimpath=$(GOPATH) -asmflags=-trimpath=$(GOPATH) -ldflags '-extldflags "-static"' $(LDFLAGS) -o dist/comply-$(VERSION)-linux-amd64 .
+	GOOS=windows GOARCH=amd64 CGO_ENABLED=0 go build -gcflags=-trimpath=$(GOPATH) -asmflags=-trimpath=$(GOPATH) -ldflags '-extldflags "-static"' $(LDFLAGS) -o dist/comply-$(VERSION)-windows-amd64.exe .
 	cd dist && tar -czvf comply-$(VERSION)-darwin-amd64.tgz comply-$(VERSION)-darwin-amd64
 	cd dist && tar -czvf comply-$(VERSION)-linux-amd64.tgz comply-$(VERSION)-linux-amd64
+	cd dist && zip comply-$(VERSION)-windows-amd64.zip comply-$(VERSION)-windows-amd64.exe
 
-brew: clean assets $(GO_SOURCES)
+brew: clean $(GO_SOURCES)
 	$(eval VERSION := $(shell cat version))
 	$(eval LDFLAGS := -ldflags='-X "github.com/strongdm/comply/internal/cli.Version=$(VERSION)"')
 	mkdir bin
@@ -62,7 +64,6 @@ export-example:
 
 docker:
 	cd build && docker build -t strongdm/pandoc .
-	docker tag jagregory/pandoc:latest strongdm/pandoc:latest
 	docker push strongdm/pandoc
 
 cleanse:
@@ -78,6 +79,9 @@ release-env:
 ifndef GH_LOGIN
 	$(error GH_LOGIN must be set to a valid GitHub token)
 endif
+ifndef COMPLY_TAPDIR
+	$(error COMPLY_TAPDIR must be set to the path of the comply homebrew tap repo)
+endif
 
 release: release-env dist release-deps
 	$(eval VERSION := $(shell git describe --tags --always --dirty="-dev"))
@@ -105,11 +109,17 @@ release: release-env dist release-deps
 	--file dist/comply-$(VERSION)-linux-amd64.tgz
 
 	@echo "Update homebrew formula with the following: "
-	@echo "version $(VERSION)"
-	@curl -L https://github.com/strongdm/comply/archive/$(VERSION).tar.gz |shasum -a 256
+	$(eval SHA := $(shell curl -s -L https://github.com/strongdm/comply/archive/$(VERSION).tar.gz |shasum -a 256|cut -d" " -f1))
+	@echo "version $(VERSION) sha $(SHA)"
+	cd $$COMPLY_TAPDIR && ./update.sh $(VERSION) $(SHA)
+
 patch-release: release-env push-assets patch release
+	$(eval VERSION := $(shell git describe --tags --always --dirty="-dev"))
+	curl -X POST --data-urlencode 'payload={"channel": "#release", "username": "release", "text": "comply $(VERSION) released", "icon_emoji": ":shipit:"}' https://hooks.slack.com/services/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
 
 minor-release: release-env push-assets minor release
+	$(eval VERSION := $(shell git describe --tags --always --dirty="-dev"))
+	curl -X POST --data-urlencode 'payload={"channel": "#release", "username": "release", "text": "comply $(VERSION) released", "icon_emoji": ":shipit:"}' https://hooks.slack.com/services/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
 
 patch: clean gitsem
 	gitsem -m "increment patch for release (via Makefile)" patch

README.md

@@ -1,4 +1,4 @@
-# Comply
+![Comply](https://github.com/strongdm/comply/blob/master/logo.png)
 
 Comply is a SOC2-focused compliance automation tool:
 
@@ -12,6 +12,10 @@ macOS:
 
 `brew tap strongdm/comply; brew install comply`
 
+Linux:
+
+[Download latest release](https://github.com/strongdm/comply/releases)
+
 Go users:
 
 `go get github.com/strongdm/comply`
@@ -34,6 +38,8 @@ Join us in [Comply Users](https://join.slack.com/t/comply-users/shared_invite/en
 
 # Screenshots
 
+[Demo video](https://vimeo.com/270257486)
+
 ## Start a Project
 ![screencast 1](sc-1.gif)
 
@@ -48,6 +54,10 @@ Join us in [Comply Users](https://join.slack.com/t/comply-users/shared_invite/en
 ## Dashboard
 ![screencast 2](sc-3.gif)
 
+## Dependencies
+
+Comply relies on [pandoc](https://pandoc.org/), which can be installed directly as an OS package or invoked via Docker.
+
 ## CLI
 
 ```
@@ -58,12 +68,49 @@ USAGE:
    comply [global options] command [command options] [arguments...]
 
 COMMANDS:
-     init       initialize a new compliance repository (interactive)
-     build, b   generate a static website summarizing the compliance program
-     scheduler  create tickets based on procedure schedule
-     serve      live updating version of the build command
-     sync       sync ticket status to local cache
-     todo       list declared vs satisfied compliance controls
-     help, h    Shows a list of commands or help for one command
+     init             initialize a new compliance repository (interactive)
+     build, b         generate a static website summarizing the compliance program
+     procedure, proc  create ticket by procedure ID
+     scheduler        create tickets based on procedure schedule
+     serve            live updating version of the build command
+     sync             sync ticket status to local cache
+     todo             list declared vs satisfied compliance controls
+     help, h          Shows a list of commands or help for one command
 ```
+## Ticketing Integrations:
+- Jira
+- Github
+- Gitlab
 
+## Configuring Jira
+When comply creates a ticket (through `proc`, for instance), it sets the following fields.
+
+- assignee
+- description
+- issuetype
+- labels
+- project key
+- reporter
+- summary
+
+Please make sure that the default *Create Screen* has all of those fields enabled. Additionally, make sure that there are no other required fields for the issue type you choose.
+
+
+
+
+## Forking and local development
+> Assumes installation of golang and configuration of GOPATH in .bash_profile, .zshrc, etc
+> Inspiration: http://code.openark.org/blog/development/forking-golang-repositories-on-github-and-managing-the-import-path
+
+```
+$ go get github.com/strongdm/comply
+$ cd $GOPATH/src/github.com/strongdm/comply ; go get ./...
+$ make
+$ cd example
+$ mv comply.yml.example comply.yml
+$ ../comply -h
+$ ../comply sync
+$ ../comply serve
+#
+$ make # recompile as needed with in $GOPATH/src/github.com/strongdm/comply
+```

VERSION

@@ -1 +1 @@
-1.1.20
+1.3.5

build/Dockerfile

@@ -1,3 +1,29 @@
-FROM scratch
+FROM haskell:latest
 
-MAINTAINER strongDM Comply <comply@strongdm.com>
+# based on implementation by James Gregory <james@jagregory.com>
+MAINTAINER Comply <comply@strongdm.com>
+
+# install latex packages
+RUN apt-get update -y \
+  && apt-get install -y -o Acquire::Retries=10 --no-install-recommends \
+    texlive-latex-base \
+    texlive-xetex \
+    texlive-fonts-recommended \
+    latex-xcolor \
+    texlive-latex-extra \
+    fontconfig \
+    unzip \
+    lmodern
+
+# will ease up the update process
+# updating this env variable will trigger the automatic build of the Docker image
+ENV PANDOC_VERSION "2.2.1"
+
+# install pandoc
+RUN cabal update && cabal install pandoc-${PANDOC_VERSION}
+
+WORKDIR /source
+
+ENTRYPOINT ["/root/.cabal/bin/pandoc"]
+
+CMD ["--help"]

example/comply.yml.example

@@ -1,7 +1,31 @@
 name: "Acme"
 filePrefix: "Acme"
+
+# The following setting is optional.
+# If you set this (to, e.g. master), and you build the policies
+# on that branch, then a section is appended to each policy that
+# describes the approval. Text will look like:
+#
+# Last edit made by John Doe (jdoe@email.com) on Wed, 15 Aug 2018 12:45:28 -0400.
+# Approved by Joan Smith (jsmith@email.com) on Wed, 15 Aug 2018 16:54:48 -0400 in commit abc123123.
+#
+# The change author gets credit for the edit.
+# The person who committed or merged to the approval branch gets credit for approval.
+approvedBranch: master
 tickets:
   github:
     token: XXX
     username: strongdm
-    repo: comply
+    repo: comply
+  # jira:
+  #   username: xxxx     # This is the username you log in to Jira's UI with. Probably your email address.
+  #   password: xxxx     # If you don't have a "managed account", use your password in this field. But if your organization
+  #                      # uses SAML or OAuth, or Jira's built-in multi-factor authentication, you need to use
+  #                      # an API token. Learn more here: https://confluence.atlassian.com/cloud/api-tokens-938839638.html
+  #   project: comply
+  #   url: https://yourjira
+  #   taskType: Task     # This must be an Issue, not a sub-task
+  # gitlab:
+  #   domain: https://gitlab.example.com:443/ # or https://gitlab.com/
+  #   token: token-here
+  #   repo: full-slug/of-project

example/narratives/control.md

@@ -17,6 +17,78 @@ majorRevisions:
 
 # Control Environment Narrative
 
-Here we narrate why our control environment satisfies the control keys listed in the YML block
+The following provides a description of the control structure of {{.Name}}.
 
-# Template Coming Soon
+The intent of this description is to enumerate the logical, policy, and procedural controls that serve to monitor {{.Name}}'s application and data security. Changes uncovered by these procedures in the logical, policy, procedural, or customer environment are addressed by remediations specific to the noted change.
+
+# Logical Controls
+
+{{.Name}} employs several logical controls to protect confidential data and ensure normal operation of its core product.
+
+- Mandatory data encryption at rest and in motion
+- Multi-factor authentication for access to cloud infrastructure
+- Activity and anomaly monitoring on production systems
+- Vulnerability management program
+
+# Policy Controls
+
+{{.Name}} employs several policy controls to protect confidential data and ensure normal operation of its core product. These policies include, but are not limited to:
+
+- Access Control Policy
+- Encryption Policy
+- Office Security Policy
+- Password Policy
+- Policy Training Policy
+- Vendor Policy
+- Workstation Policy
+
+# Procedural Controls
+
+{{.Name}} has numerous scheduled procedures to monitor and tune the effectiveness of ongoing security controls, and a series of event-driven procedures to respond to security-related events.
+
+TODO: Finalize these lists
+
+## Scheduled Security and Audit Procedures
+
+- Review Access [quarterly]
+- Review Security Logs [weekly]
+- Review Cyber Risk Assessment (enumerate possible compromise scenarios) [quarterly]
+- Review Data Classification [quarterly]
+- Backup Testing [quarterly]
+- Disaster Recovery Testing [semi-annual]
+- Review Devices & Workstations [quarterly]
+- Review & Clear Low-Priority Alerts [weekly]
+- Apply OS Patches [monthly]
+- Verify Data Disposal per Retention Policy [quarterly]
+- Conduct Security Training [annual]
+- Review Security Monitoring and Alerting Configuration [quarterly]
+- Penetration Test [annual]
+- Whitebox Security Review [annual]
+- SOC2 Audit [annual]
+
+## Event-Driven Security and Audit Procedures
+
+- Onboard Employee
+- Offboard Employee
+- Investigate Security Alert
+- Investigate Security Incident
+
+# Remediations
+
+{{.Name}} uses the outcomes of the aforementioned controls and procedures to identify shortcomings in the existing control environment. Once identified, these shortcomes are remediated by improving existing controls and procedures, and creating new controls and procedures as needed.
+
+# Communications
+
+{{.Name}} communicates relevant information regarding the functioning of the above controls with internal and external parties on an as-needed basis and according to statutory requirements.
+
+## Internal
+
+{{.Name}} communicates control outcomes, anomalies, and remediations internally using the following channels:
+
+- Slack
+- Email
+- Github ticketing
+
+## External
+
+{{.Name}} communicates relevant control-related information to external parties including shareholders, customers, contractors, regulators, and government entities as needed according to contractual and regulatory/statutory obligation.

example/narratives/products.md

@@ -9,4 +9,39 @@ majorRevisions:
 
 Here we describe the key products marketed by our organization
 
-# Template Coming Soon
+# Products
+
+## Product 1
+
+Overview of product 1
+
+### Architecture
+
+Brief architectural discussion of product 1
+
+### Security Considerations
+
+Specific security considerations for product 1. Refer to policies, procedures here.
+
+# References
+
+## Narratives
+
+List relevant narratives, probably including
+Organizational Narrative
+Security Narrative
+System Narrative
+
+## Policies
+
+List relevant policies, probably including
+Application Security Policy
+Datacenter Policy
+Log Management Policy
+Password Policy
+Security Incident Response Policy
+Risk Assessment Policy
+
+## Procedures
+
+List relevant procedures, probably including access review, patching, alert monitoring, log review, pen testing

example/narratives/security.md

@@ -15,4 +15,99 @@ majorRevisions:
 
 Here we narrate why our org satisfies the control keys listed in the YML block
 
-# Template Coming Soon
+# {{.Name}} Product Architecture
+
+Describe product architecture here, emphasizing security implications
+
+# {{.Name}} Infrastructure
+
+## Product Infrastructure
+
+Describe product infrastructure, emphasizing security measures
+
+### Authorized Personnel
+
+- **AWS root account** access is granted only to the CTO and CEO
+- **AWS IAM** access is granted to to a limited group of **Operators**
+- **{{.Name}} SSH** access is granted to a limited group of **Operators**
+- **{{.Name}} DB** access is granted to a limited group of **Data Operators**
+
+## IT Infrastructure
+
+{{.Name}} uses the following cloud services for its internal infrastructure:
+
+- List cloud services
+
+Access to these cloud services is limited according to the role of the {{.Name}} employee and is reviewed quarterly as well as via regular onboarding/offboarding tasks for new and departing employees.
+
+# {{.Name}} Workstations
+
+{{.Name}} workstations are hardened against logical and physical attack by the following measures:
+
+- operating system must be within one generation of current
+- full-disk encryption
+- onboard antivirus/antimalware software
+- OS and AV automatically updated
+
+Workstation compliance with these measures is evaluated on a quarterly basis.
+
+## Remote Access
+
+Many {{.Name}} employees work remotely on a regular basis and connect to production and internal IT systems via the same methods as those employees connecting from the {{.Name}} physical office, i.e., direct encrypted access to cloud services. It is the employee's responsibility to ensure that only authorized personnel use {{.Name}} resources and access {{.Name}} systems.
+
+# Access Review
+
+Access to {{.Name}} infrastructure, both internal and product, is reviewed quarterly and inactive users are removed. Any anomalies are reported to the security team for further investigation. When employees start or depart, an onboarding/offboarding procedure is followed to provision or deprovision appropriate account access.
+
+# Penetration Testing
+
+{{.Name}} commissions an external penetration test on an annual basis. All findings are immediately reviewed and addressed to the satisfaction of the CTO/CEO.
+
+# {{.Name}} Physical Security
+
+{{.Name}} has one physical location, in San Francisco, CA. Key issuance is tracked by the Office Physical Security Policy Ledger. Office keys are additionally held by the lessor, property management, and custodial staff. These keys are not tracked by the Office Physical Security Policy Ledger. {{.Name}} managers regularly review physical access privileges.
+
+{{.Name}} infrastructure is located within AWS. {{.Name}} does not have physical access to AWS infrastructure.
+
+# Risk Assessment
+
+{{.Name}} updates its Cyber Risk Assessment on an annual basis in order to keep pace with the evolving threat landscape. The following is an inventory of adversarial and non-adversarial threats assessed to be of importance to {{.Name}}.
+
+## Adversarial Threats
+
+The following represents the inventory of adversarial threats:
+
+|Threat|Source|Vector|Target|Likelihood|Severity|
+|----------------------------+--------------+------------+-----------------+----------+------|
+| | | | | | |
+
+## Non-Adversarial Threats
+
+The following represents the inventory of non-adversarial threats:
+
+|Threat|Vector|Target|Likelihood|Severity|
+|----------------------------+--------------+-------------+----------+------|
+| | | | | |
+
+# References
+
+## Narratives
+
+Products and Services Narrative
+System Architecture Narrative
+
+## Policies
+
+Encryption Policy
+Log Management Policy
+Office Security Policy
+Remote Access Policy
+Security Incident Response Policy
+Workstation Policy
+
+## Procedures
+
+Apply OS Patches
+Review & Clear Low-Priority Alerts
+Review Access
+Review Devices & Workstations

example/policies/access.md

@@ -9,5 +9,49 @@ majorRevisions:
   - date: Jun 1 2018
     comment: Initial document
 ---
+# Purpose and Scope
+
+a. The purpose of this policy to define procedures to onboard and offboard users to technical infrastructure in a manner that minimizes the risk of information loss or exposure. 
+
+a. This policy applies to all technical infrastructure within the organization. 
+
+a. This policy applies to all full-time and part-time employees and contractors. 
+
+# Background
+
+a. In order to minimize the risk of information loss or exposure (from both inside and outside the organization), the organization is reliant on the principle of least privilege. Account creation and permission levels are restricted to only the resources absolutely needed to perform each person’s job duties. When a user’s role within the organization changes, those accounts and permission levels are changed/revoked to fit the new role and disabled when the user leaves the organization altogether. 
+
+# Policy
+
+a. *During onboarding:*
+
+    i. Hiring Manager informs HR upon hire of a new employee.
+
+    i. HR emails IT to inform them of a new hire and their role. 
+
+    i. IT creates a checklist of accounts and permission levels needed for that role. 
+
+    i. The owner of each resource reviews and approves account creation and the 
+associated permissions. 
+
+    i. IT works with the owner of each resource to set up the user. 
+
+a. *During offboarding:*
+
+    i. Hiring Manager notifies HR when an employee has been terminated. 
+
+    i. HR sends a weekly email report to IT summarizing list of users terminated and instructs IT to disable their access. 
+
+    i. IT terminates access within five business days from receipt of notification. 
+
+a. *When an employee changes roles within the organization:*
+
+    i. Hiring Manager will inform HR of a change in role.
+    
+    i. HR and IT will follow the same steps as outlined in the onboarding and offboarding procedures. 
+
+a. *Review of accounts and permissions:*
+
+    i. Each month, IT and HR will review accounts and permission levels for accuracy. 
+
 
-# Coming Soon

example/policies/application.md

@@ -8,4 +8,111 @@ majorRevisions:
     comment: Initial document
 ---
 
-# Coming Soon
+# Purpose and Scope
+
+a. This application security policy defines the security framework and requirements for applications, notably web applications, within the organization’s production environment.
+
+a. This document also provides implementing controls and instructions for web application security, to include periodic vulnerability scans and other types of evaluations and assessments.
+
+a. This policy applies to all applications within the organization’ production environment, as well as administrators and users of these applications. This typically includes employees and contractors.
+
+# Background
+
+a. Application vulnerabilities typically account for the largest number of initial attack vectors after malware infections. As a result, it is important that applications are designed with security in mind, and that they are scanned and continuously monitored for malicious activity that could indicate a system compromise. Discovery and subsequent mitigation of application vulnerabilities will limit the organization’s attack surface, and ensures a baseline level of security across all systems.
+
+a. In addition to scanning guidance, this policy also defines technical requirements and procedures  to ensure that applications are properly hardened in accordance with security best practices.
+
+# References
+
+a. Data Classification Policy
+
+a. OWASP Risk Rating Methodology
+
+a. OWASP Testing Guide
+
+a. OWASP Top Ten Project
+
+# Policy
+
+a. The organization must ensure that all applications it develops and/or acquires are securely configured and managed.
+
+a. The following security best practices must be considered and, if feasible, applied as a matter of the application’s security design:
+
+    i. Data handled and managed by the application must be classified in accordance with the Data Classification Policy (reference (a)).
+
+    i. If the application processes confidential information, a confidential record banner must be prominently displayed which highlights the type of confidential data being accessed (e.g., personally-identifiable information (PII), protected health information (PHI), etc.)
+
+    i. Sensitive data, especially data specifically restricted by law or policy (e.g., social security numbers, passwords, and credit card data) should not be displayed in plaintext.
+
+    i. Ensure that applications validate input properly and restrictively, allowing only those types of input that are known to be correct. Examples include, but are not limited to cross-site scripting, buffer overflow errors, and injection flaws.
+
+    i. Ensure that applications execute proper error handling so that errors will not provide detailed system information to an unprivileged user, deny service, impair security mechanisms, or crash the system.
+
+    i. Where possible, authorize access to applications by affiliation, membership or employment, rather than by individual. Provide an automated review of authorizations on a regular basis, where possible.
+
+    i. Ensure that applications encrypt data at rest and in transit.
+
+    i. Implement application logging to the extent practical. Retain logs of all users and access events for at least 14 days.
+
+    i. Qualified peers conduct security reviews of code  for all new or significantly modified applications; particularly, those that affect the collection, use, and/or display of confidential data. Document all actions taken.
+
+    i. Implement a change management process for changes to existing software applications.
+
+    i. Standard configuration of the application must be documented. 
+
+    i. Default passwords used within the application, such as for administrative control panels or integration with databases must be changed immediately upon installation.
+
+    i. Applications must require complex passwords in accordance with current security best practices (at least 8 characters in length, combination of alphanumeric upper/lowercase characters and symbols).
+
+    i. During development and testing, applications must not have access to live data.
+
+a. Where applications are acquired from a third party, such as a vendor:
+
+    i. Only applications that are supported by an approved vendor shall be procured and used.
+
+    i. Full support contracts must be arranged with the application vendor for full life-cycle support.
+
+    i. No custom modifications may be applied to the application without confirmation that the vendor can continue to provide support.
+
+    i. Updates, patches and configuration changes issued by the vendor shall be implemented as soon as possible.
+
+    i. A full review of applications and licenses shall be completed at least annually, as part of regular software reviews.
+
+a. Web applications must be assessed according to the following criteria:
+
+    i. New or major application releases must have a full assessment prior to approval of the change control documentation and/or release into the production environment.
+
+    i. Third-party or acquired applications must have a full assessment prior to deployment.
+
+    i. Software releases must have an appropriate assessment, as determined by the organization’s information security manager, with specific evaluation criteria based on the security risks inherent in the changes made to the application’s functionality and/or architecture.
+
+    i. Emergency releases may forego security assessments and carry the assumed risk until a proper assessment can be conducted. Emergency releases must be approved by the Chief Information Officer or designee.
+
+a. Vulnerabilities that are discovered during application assessments must be mitigated based upon the following risk levels, which are based on the Open Web Application Security Project (OWASP) Risk Rating Methodology (reference (b)):
+
+    i. High - issues categorized as high risk must be fixed immediately, otherwise alternate mitigation strategies must be implemented to limit exposure before deployment. Applications with high risk issues are subject to being taken off-line or denied release into the production environment.
+
+    i. Medium - issues categorized as medium risk must be reviewed to determine specific items to be mitigated. Actions to implement mitigations must be scheduled. Applications with medium risk issues may be taken off-line or denied release into the production environment based on the number of issues; multiple issues may increase the risk to an unacceptable level. Issues may be fixed in patch releases unless better mitigation options are present.
+
+    i. Low - issues categorized as low risk must be reviewed to determine specific items to be mitigated. Actions to implement mitigations must be scheduled.
+
+a. Testing is required to validate fixes and/or mitigation strategies for any security vulnerabilities classified as Medium risk or greater.
+
+a. The following security assessment types may be leveraged to perform an application security assessment:
+
+    i. Full - comprised of tests for all known web application vulnerabilities using both automated and manual tools based on the OWASP Testing Guide (reference (c)). A full assessment must leverage manual penetration testing techniques to validate discovered vulnerabilities to determine the overall risk of any and all discovered issues.
+
+    i. Quick - consists of an automated scan of an application for, at a minimum, the OWASP Top Ten web application security risks (reference (d)).
+
+    i. Targeted - verifies vulnerability remediation changes or new application functionality.
+
+    i. To counter the risk of unauthorized access, the organization maintains a Data Center Security Policy (reference (c)).
+
+    i. Security requirements for the software development life cycle, including system development, acquisition and maintenance are defined in the Software Development Lifecycle Policy (reference (d)).
+
+    i. Security requirements for handling information security incidents are defined in the Security Incident Response Policy (reference (e)).
+
+    i. Disaster recovery and business continuity management policy is defined in the Disaster Recovery Policy (reference (f)).
+
+    i. Requirements for information system availability and redundancy are defined in the System Availability Policy (reference (g)).
+

example/policies/availability.md

@@ -9,4 +9,92 @@ majorRevisions:
     comment: Initial document
 ---
 
-# Coming Soon
+# Purpose and Scope
+
+a. The purpose of this policy is to define requirements for proper controls to protect the availability of the organization’s information systems.
+
+a. This policy applies to all users of information systems within the organization. This typically includes employees and contractors, as well as any external parties that come into contact with systems and information controlled by the organization (hereinafter referred to as “users”). This policy must be made readily available to all users.
+
+# Background
+
+a. The intent of this policy is to minimize the amount of unexpected or unplanned downtime (also known as outages) of information systems under the organization’s control. This policy prescribes specific measures for the organization that will increase system redundancy, introduce failover mechanisms, and implement monitoring such that outages are prevented as much as possible. Where they cannot be prevented, outages will be quickly detected and remediated.
+
+a. Within this policy, an availability is defined as a characteristic of information or information systems in which such information or systems can be accessed by authorized entities whenever needed.
+
+# References
+
+a. Risk Assessment Policy
+
+# Policy
+
+a. Information systems must be consistently available to conduct and support business operations.
+
+a. Information systems must have a defined availability classification, with appropriate controls enabled and incorporated into development and production processes based on this classification.
+
+a. System and network failures must be reported promptly to the organization’s lead for Information Technology (IT) or designated IT operations manager.
+
+a. Users must be notified of scheduled outages (e.g., system maintenance) that require periods of downtime. This notification must specify the date and time of the system maintenance, expected duration, and anticipated system or service resumption time.
+
+a. Prior to production use, each new or significantly modified application must have a completed risk assessment that includes availability risks. Risk assessments must be completed in accordance with the Risk Assessment Policy (reference (a)).
+
+a. Capacity management and load balancing techniques must be used, as deemed necessary, to help minimize the risk and impact of system failures.
+
+a. Information systems  must have an appropriate data backup plan that ensures:
+
+    i. All sensitive data can be restored within a reasonable time period.
+
+    i. Full backups of critical resources are performed on at least a weekly basis.
+
+    i. Incremental backups for critical resources are performed on at least a daily basis.
+
+    i. Backups and associated media are maintained for a minimum of thirty (30) days and retained for at least one (1) year, or in accordance with legal and regulatory requirements.
+
+    i. Backups are stored off-site with multiple points of redundancy and protected using encryption and key management.
+
+    i. Tests of backup data must be conducted once per quarter. Tests of configurations must be conducted twice per year.
+
+a. Information systems  must have an appropriate redundancy and failover plan that meets the following criteria:
+
+    i. Network infrastructure that supports critical resources must have system-level redundancy (including but not limited to a secondary power supply, backup disk-array, and secondary computing system). Critical core components (including but not limited to routers, switches, and other devices linked to Service Level Agreements (SLAs)) must have an actively maintained spare. SLAs must require parts replacement within twenty-four (24) hours.
+
+    i. Servers that support critical resources must have redundant power supplies and network interface cards. All servers must have an actively maintained spare. SLAs must require parts replacement within twenty-four (24) hours.
+
+    i. Servers classified as high availability must use disk mirroring.
+
+a. Information systems must have an appropriate business continuity plan that meets the following criteria:
+
+    i. Recovery time and data loss limits are defined in Table 3. 
+
+    i. Recovery time requirements and data loss limits must be adhered to with specific documentation in the plan.
+
+    i. Company and/or external critical resources, personnel, and necessary corrective actions must be specifically identified.
+
+    i. Specific responsibilities and tasks for responding to emergencies and resuming business operations must be included in the plan.
+
+    i. All applicable legal and regulatory requirements must be satisfied.
+
++-------------------+------------------+---------------+-------------------+------------------+
+|**Availability**   | **Availability** | **Scheduled** | **Recovery Time** | **Data Loss or** |
+|**Classification** | **Requirements** | **Outage**    | **Requirements**  | **Impact Loss**  |
++===================+==================+===============+===================+==================+
+| High              | High to          | 30 minutes    | 1 hour            | Minimal          |
+|                   | Continuous       |               |                   |                  |
++-------------------+------------------+---------------+-------------------+------------------+
+|                   |                  |               |                   |                  |
++-------------------+------------------+---------------+-------------------+------------------+
+| Medium            | Standard         | 2 hours       | 4 hours           | Some data loss   |
+|                   | Availability     |               |                   | is tolerated if  |
+|                   |                  |               |                   | it results in    |
+|                   |                  |               |                   | quicker          |
+|                   |                  |               |                   | restoration      |
++-------------------+------------------+---------------+-------------------+------------------+
+|                   |                  |               |                   |                  |
++-------------------+------------------+---------------+-------------------+------------------+
+| Low               | Limited          | 4 hours       | Next              | Some data loss   |
+|                   | Availability     |               | business day      | is tolerated if  |
+|                   |                  |               |                   | it results in    |
+|                   |                  |               |                   | quicker          |
+|                   |                  |               |                   | restoration      |
++-------------------+------------------+---------------+-------------------+------------------+
+
+Table 3: Recovery Time and Data Loss Limits 

example/policies/classification.md

@@ -7,5 +7,279 @@ majorRevisions:
   - date: Jun 1 2018
     comment: Initial document
 ---
+# Appendices 
+
+Appendix A: Handling of Classified Information
+
+Appendix B: Form - Confidentiality Statement
+
+# Purpose and Scope
+
+a. This data classification policy defines the requirements to ensure that information within the organization is protected at an appropriate level.
+
+a. This document applies to the entire scope of the organization’s information security program. It includes all types of information, regardless of its form, such as paper or electronic documents, applications and databases, and knowledge or information that is not written.
+
+a. This policy applies to all individuals and systems that have access to information kept by the organization.
+
+# Background
+
+a. This policy defines the high level objectives and implementation instructions for the organization’s data classification scheme. This includes data classification levels, as well as procedures for the classification, labeling and handling of data within the organization. Confidentiality and non-disclosure agreements maintained by the organization must reference this policy.
+
+# References
+
+a. Risk Assessment Policy
+
+a. Security Incident Management Policy
+
+# Policy
+
+a. If classified information is received from outside the organization, the person who receives the information must classify it in accordance with the rules prescribed in this policy. The person thereby will become the owner of the information.
+
+a. If classified information is received from outside the organization and handled as part of business operations activities (e.g., customer data on provided cloud services), the information classification, as well as the owner of such information, must be made in accordance with the specifications of the respective customer service agreement and other legal requirements.
+
+a. When classifying information, the level of confidentiality is determined by:
+
+    i. The value of the information, based on impacts identified during the risk assessment process. More information on risk assessments is defined in the Risk Assessment Policy (reference (a)).
+
+    i. Sensitivity and criticality of the information, based on the highest risk calculated for each information item during the risk assessment.
+
+    i. Legal, regulatory and contractual obligations. 
+
+
++-------------------+------------------+---------------------------+---------------------------+
+|**Confidentiality**| **Label**        |  **Classification**       |  **Access**               |
+|     **Level**     |                  |   **Criteria**            | **Restrictions**          |
++===================+==================+===========================+============================+
+| Public            | For Public       | Making the information    | Information is available  |   
+|                   | Release          | public will not harm      | to the public.            |
+|                   |                  | the organization in       |                           |        
+|                   |                  | any way.                  |                           |
++-------------------+------------------+---------------------------+---------------------------+
+|                   |                  |                           |                           |
++-------------------+------------------+---------------------------+---------------------------+
+| Internal Use      | Internal Use     | Unauthorized access       | Information is available  |
+|                   |                  | may cause minor damage    | to all employees and      |   
+|                   |                  | and/or inconvenience      | authorized third parties. |        
+|                   |                  | to the organization.      | 
++-------------------+------------------+---------------------------+---------------------------+
+|                   |                  |                           |                           |
++-------------------+------------------+---------------------------+---------------------------+
+| Restricted        | Restricted       | Unauthorized access to    | Information is available  |
+|                   |                  | information may cause     | to a specific group of    |
+|                   |                  | considerable damage to    | employees and authhorized |
+|                   |                  | the business and/or       | third parties.            |
+|                   |                  | the organization's        |                           |
+|                   |                  | reputation.               |                           |           
++-------------------+------------------+---------------------------+---------------------------+
+|                   |                  |                           |                           |
++-------------------+------------------+---------------------------+---------------------------+
+| Confidential      |Confidential      | Unauthorized access to    | Information is available  |           
+|                   |                  | information may cause     | only to specific indivi-  |
+|                   |                  | catastrophic damage to    | duals in the              |
+|                   |                  | business and/or the       | organization.             |
+|                   |                  | organization's reputation.|                           |
++-------------------+------------------+---------------------------+---------------------------+
+
+Table 3: Information Confidentiality Levels
+
+ 
+
+d. Information must be classified based on confidentiality levels as defined in Table 3.
+
+e. Information and information system owners should try to use the lowest confidentiality level that ensures an adequate level of protection, thereby avoiding unnecessary production costs.
+
+f. Information classified as “Restricted” or “Confidential” must be accompanied by a list of authorized persons in which the information owner specifies the names or job functions of persons who have the right to access that information.
+
+g. Information classified as “Internal Use” must be accompanied by a list of authorized persons only if individuals outside the organization will have access to the document.
+
+h. Information and information system owners must review the confidentiality level of their information assets every five years and assess whether the confidentiality level should be changed. Wherever possible, confidentiality levels should be lowered.
+
+a. For cloud-based software services provided to customers, system owners under the company’s control must also review the confidentiality level of their information systems after service agreement changes or after a customer’s formal notification. Where allowed by service agreements, confidentiality levels should be lowered.
+
+a. Information must be labeled according to the following:
+
+    i. Paper documents: the confidentiality level is indicated on the top and bottom of each document page; it is also indicated on the front of the cover or envelope carrying such a document as well as on the filing folder in which the document is stored. If a document is not labeled, its default classification is Internal Use.
+
+    i. Electronic documents: the confidentiality level is indicated on the top and bottom of each document page. If a document is not labeled, its default classification is Internal Use.
+
+    i. Information systems: the confidentiality level in applications and databases must be indicated on the system access screen, as well as on the screen when displaying such information.
+    
+    i. Electronic mail: the confidentiality level is indicated in the first line of the email body. If it is not labeled, its default classification is “Internal Use”.
+    
+    i. Electronic storage media (disks, memory cards, etc.): the confidentiality level must be indicated on the top surface of the media. If it is not labeled, its default classification is “Internal Use”.
+    
+    i. Information transmitted orally: the confidentiality level should be mentioned before discussing information during face-to-face communication, by telephone, or any other means of oral communication.
+    
+a. All persons accessing classified information must follow the guidelines listed in Appendix A, “Handling of Classified Information.”
+
+a. All persons accessing classified information must complete and submit a Confidentiality Statement to their immediate supervisor or company point-of-contact. A sample Confidentiality Statement is in Appendix B.
+
+a. Incidents related to the improper handling of classified information must be reported in accordance with the Security Incident Management Policy (reference (b)).
+    
+\pagebreak 
+
+# Appendix A: Handling of Classified Information
+
+Information and information systems must be handled according to the following guidelines*:
+
+a. Paper Documents
+    
+    i. Internal Use
+
+        1. Only authorized persons may have access.
+        
+        1. If sent outside the organization, the document must be sent as registered mail.
+
+        1. Documents may only be kept in rooms without public access.
+
+        1. Documents must be removed expeditiously from printers and fax machines.
+
+    i. Restricted
+
+        1. The document must be stored in a locked cabinet.
+
+        1. Documents may be transferred within and outside the organization only in a closed envelope.
+
+        1. If sent outside the organization, the document must be mailed with a return receipt service.
+
+        1. Documents must immediately be removed from printers and fax machines.
+
+        1. Only the document owner may copy the document.
+
+        1. Only the document owner may destroy the document.
+
+    i. Confidential
+      
+        1. The document must be stored in a safe.
+
+        1. The document may be transferred within and outside the organization only by a trustworthy person in a closed and sealed envelope.
+
+        1. Faxing the document is not permitted.
+
+        1. The document may be printed only if the authorized person is standing next to the printer.
+
+a. Electronic Documents
+
+    i. Internal Use
+
+        1. Only authorized persons may have access.
+
+        1. When documents are exchanged via unencrypted file sharing services such as FTP, they must be password protected.
+
+        1. Access to the information system where the document is stored must be protected by a strong password.
+
+        1. The screen on which the document is displayed must be automatically locked after 10 minutes of inactivity.
+
+    i. Restricted
+
+        1. Only persons with authorization for this document may access the part of the information system where this document is stored.
+
+        1. When documents are exchanged via file sharing services of any type, they must be encrypted.
+
+        1. Only the document owner may erase the document.
+
+    i. Confidential
+
+        1. The document must be stored in encrypted form.
+
+        1. The document may be stored only on servers which are controlled by the organization.
+
+        1. The document may only be shared via file sharing services that are encrypted such as HTTPS and SSH. Further, the document must be encrypted and protected with a string password when transferred.
+
+a. Information Systems
+
+    i. Internal Use
+
+        1. Only authorized persons may have access.
+
+        1. Access to the information system must be protected by a strong password.
+
+        1. The screen must be automatically locked after 10 minutes of inactivity.
+
+        1. The information system may be only located in rooms with controlled physical access.
+
+    i. Restricted
+
+        1. Users must log out of the information system if they have temporarily or permanently left the workplace.
+
+        1. Data must be erased only with an algorithm that ensures secure deletion.
+
+    i. Confidential
+
+        1. Access to the information system must be controlled through multi-factor authentication (MFA).
+
+        1. The information system may only be installed on servers controlled by the organization.
+
+        1. The information system may only be located in rooms with controlled physical access and identity control of people accessing the room.
+
+a. Electronic Mail
+
+    i. Internal Use
+
+        1. Only authorized persons may have access.
+
+        1. The sender must carefully check the recipient.
+
+        1. All rules stated under “information systems” apply.
+
+    i. Restricted
+
+        1. Email must be encrypted if sent outside the organization.
+
+    i. Confidential
+
+        1. Email must be encrypted.
+
+a. Electronic Storage Media
+
+    i. Internal Use
+
+        1. Only authorized persons may have access.
+
+        1. Media or files must be password protected.
+
+        1. If sent outside the organization, the medium must be sent as registered mail.
+
+        1. The medium may only be kept in rooms with controlled physical access.
+
+    i. Restricted
+
+        1. Media and files must be encrypted.
+
+        1. Media must be stored in a locked cabinet.
+
+        1. If sent outside the organization, the medium must be mailed with a return receipt service.
+
+        1. Only the medium owner may erase or destroy the medium.
+
+    i. Confidential
+
+        1. Media must be stored in a safe.
+
+        1. Media may be transferred within and outside the organization only by a trustworthy person and in a closed and sealed envelope.
+
+a. Information Transmitted Orally
+
+    i. Internal Use
+
+        1. Only authorized persons may have access to information.
+
+        1. Unauthorized persons must not be present in the room when the information is communicated.
+
+    i. Restricted
+
+        1. The room must be sound-proof.
+
+        1. The conversation must not be recorded.
+
+    i. Confidential
+
+        1. Conversation conducted through electronic means must be encrypted.
+
+        1. No transcript of the conversation may be kept.
+
+In this document, controls are implemented cumulatively, meaning that controls for any confidentiality level imply the implementation of controls defined for lower confidentiality levels - if stricted controls are prescribed for a higher confidentiality level, then only such controls are implemented.
+
+
+
 
-# Coming Soon

example/policies/cyber.md

@@ -8,4 +8,61 @@ majorRevisions:
     comment: Initial document
 ---
 
-# Coming Soon
+# Purpose and Scope
+
+a. The purpose of this policy is to define the procedures to assess and treat information security risks within the organization, and to define the acceptable level of risk overall.
+
+a. Risk assessment and risk treatment are applied to the entire scope of the organization’s information security program, and to all information systems which are used within the organization or which could have an impact on the organization’s information security.
+
+a. This policy applies to all management and employees that take part in the organization’s risk assessments. This policy must be made readily available to all whom it applies to.
+
+# Background
+
+a. This policy defines a step-by-step process for conducting risk assessments, as well as to treat identified risks from an information security perspective. This policy also describes how to prepare the Risk Assessment Report required as part of the risk assessment process.
+
+a. When conducting a risk assessment, the organization must identify all organizational information systems . It must then identify all threats and vulnerabilities having to do with such systems , and rate the severity of such threats and vulnerabilities according to a predefined rating scale. Asset and risk owners must be defined for each risk item.
+
+a. Once the risk assessment is completed, the organization shall determine how to manage risks where the overall assessed risk rating is deemed as too high. This management is known as risk treatment. Risk treatment options include but are not limited to applying security controls, outsourcing risk, accepting risk, or discontinuing the activity associated with the risk.
+
+a. A penetration test must be performed by a third party to verify the accuracy of the risk assessment and effectiveness of deployed risk treatments.
+
+# Procedure To Execute Risk Assessment Report
+
+a. Confirms that the entire risk assessment and risk treatment process has been carried out according to the Risk Assessment Policy.
+
+a. The purpose of the risk assessment was to identify all information systems  their vulnerabilities, and threats that could exploit vulnerabilities. These parameters were further evaluated in order to establish the criticality of individual risks.
+
+a. The purpose of the risk treatment was to define the systematic means of reducing or controlling the risks identified in the risk assessment.
+
+a. All risk assessment and treatment activities were completed within the scope of the organization’s information security program.
+
+a. The risk assessment was implemented in the period from [day/month/year] to [day/month/year]. The risk treatment was implemented from [day/month/year] to [day/month/year]. Final reports were prepared during [specify period].
+
+a. The risk assessment and risk treatment process was managed by [person responsible for managing the risk assessment process] with expert assistance provided by [person or company responsible for assistance].
+
+a. During the risk assessment, information was collected through questionnaires and interviews with responsible persons, namely the asset owners across organizational units.
+
+a. The process was conducted as follows:
+
+    i. All information systems and their owners were identified.
+
+    i. Threats were identified for each asset, and corresponding vulnerabilities were identified for each threat.
+    i. Risk owners were identified for each risk.
+
+    i. Consequences of the loss of confidentiality, integrity and availability were evaluated using a score from 0 to 2, with 0 being the lowest rating and 2 being the highest rating.
+
+    i. The likelihood of risk occurrence (i.e. that the threat will exploit the vulnerability) was evaluated using a score from 0 to 2, with 0 being the lowest rating and 2 being the highest rating.
+
+    i. The level of risk was calculated by adding up the consequence and likelihood.
+
+    i. Risks with a score of 3 or 4 were determined to be unacceptable risks.
+
+    i. For each unacceptable risk, a risk treatment option was considered, and appropriate information security controls were selected.
+
+    i. After controls were applied, residual risks were assessed.
+
+a. The following documents were used or generated during the implementation of risk assessment and risk treatment:
+    
+    i. Risk Assessment Table (Appendix A): for each combination of systems , vulnerabilities and threats, this table shows the values for consequence and likelihood, and calculates the risk.
+
+    i. Risk Treatment Table (Appendix B): defines the options for risk treatment, selection of controls for each unacceptable risk, and the level of residual risk.

example/policies/development.md

@@ -8,4 +8,188 @@ majorRevisions:
     comment: Initial document
 ---
 
-# Coming Soon
+# Purpose and Scope
+
+a. The purpose of this policy is to define requirements for establishing and maintaining baseline protection standards for company software, network devices, servers, and desktops.
+
+a. This policy applies to all users performing software development, system administration, and management of these activities within the organization. This typically includes employees and contractors, as well as any relevant external parties involved in these activities (hereinafter referred to as “users”). This policy must be made readily available to all users.
+
+a. This policy also applies to enterprise-wide systems and applications developed by the organization or on behalf of the organization for production implementation.
+
+# Background
+
+a. The intent of this policy is to ensure a well-defined, secure and consistent process for managing the entire lifecycle of software and information systems, from initial requirements analysis until system decommission. The policy defines the procedure, roles, and responsibilities, for each stage of the software development lifecycle.
+
+a. Within this policy, the software development lifecycle consists of requirements analysis, architecture and design, development, testing, deployment/implementation, operations/maintenance, and decommission. These processes may be followed in any form; in a waterfall model, it may be appropriate to follow the process linearly, while in an agile development model, the process can be repeated in an iterative fashion.
+
+# References
+
+a. Risk Assessment Policy
+
+# Policy
+
+a. The organization’s Software Development Life Cycle (SDLC) includes the following phases:
+
+    i. Requirements Analysis
+
+    i. Architecture and Design
+
+    i. Testing
+
+    i. Deployment/Implementation
+
+    i. Operations/Maintenance
+
+    i. Decommission
+
+a. During all phases of the SDLC where a system is not in production, the system must not have live data sets that contain information identifying actual people or corporate entities, actual financial data such as account numbers, security codes, routing information, or any other financially identifying data. Information that would be considered sensitive must never be used outside of production environments.
+
+a. The following activities must be completed and/or considered during the requirements analysis phase:
+
+    i. Analyze business requirements.
+
+    i. Perform a risk assessment. More information on risk assessments is discussed in the Risk Assessment Policy (reference (a)).
+
+    i. Discuss aspects of security (e.g., confidentiality, integrity, availability) and how they might apply to this requirement.
+
+    i. Review regulatory requirements and the organization’s policies, standards, procedures and guidelines.
+
+    i. Review future business goals.
+
+    i. Review current business and information technology operations.
+
+    i. Incorporate program management items, including:
+
+        1. Analysis of current system users/customers.
+
+        1. Understand customer-partner interface requirements (e.g., business-level, network).
+
+        1. Discuss project timeframe.
+
+    i. Develop and prioritize security solution requirements.
+
+    i. Assess cost and budget constraints for security solutions, including development and operations.
+
+    i. Approve security requirements and budget.
+
+    i. Make “buy vs. build” decisions for security services based on the information above.
+
+a. The following must be completed/considered during the architecture and design phase:
+
+    i. Educate development teams on how to create a secure system.
+
+    i. Develop and/or refine infrastructure security architecture.
+
+    i. List technical and non-technical security controls.
+
+    i. Perform architecture walkthrough.
+
+    i. Create a system-level security design.
+
+    i. Create high-level non-technical and integrated technical security designs.
+
+    i. Perform a cost/benefit analysis for design components.
+
+    i. Document the detailed technical security design.
+
+    i. Perform a design review, which must include, at a minimum, technical reviews of application and infrastructure, as well as a review of high-level processes.
+
+    i. Describe detailed security processes and procedures, including: segregation of duties and segregation of development, testing and production environments. 
+
+    i. Design initial end-user training and awareness programs.
+
+    i. Design a general security test plan.
+
+    i. Update the organization’s policies, standards, and procedures, if appropriate.
+
+    i. Assess and document how to mitigate residual application and infrastructure vulnerabilities.
+
+    i. Design and establish separate development and test environments.
+
+a. The following must be completed and/or considered during the development phase:
+
+    i. Set up a secure development environment (e.g., servers, storage).
+
+    i. Train infrastructure teams on installation and configuration of applicable software, if required.
+
+    i. Develop code for application-level security components.
+
+    i. Install, configure and integrate the test infrastructure.
+
+    i. Set up security-related vulnerability tracking processes.
+
+    i. Develop a detailed security test plan for current and future versions (i.e., regression testing).
+
+    i. Conduct unit testing and integration testing.
+
+a. The following must be completed and/or considered during the testing phase:
+
+    i. Perform a code and configuration review through both static and dynamic analysis of code to identify vulnerabilities. 
+
+    i. Test configuration procedures.
+
+    i. Perform system tests.
+
+    i. Conduct performance and load tests with security controls enabled.
+
+    i. Perform usability testing of application security controls.
+
+
+    i. Conduct independent vulnerability assessments of the system, including the infrastructure and application.
+
+a. The following must be completed and/or considered during the deployment phase:
+
+    i. Conduct pilot deployment of the infrastructure, application and other relevant components.
+
+    i. Conduct transition between pilot and full-scale deployment.
+
+    i. Perform integrity checking on system files to ensure authenticity.
+
+    i. Deploy training and awareness programs to train administrative personnel and users in the system’s security functions.
+
+    i. Require participation of at least two developers in order to conduct full-scale deployment to the production environment.
+
+a. The following must be completed and/or considered during the operations/maintenance phase:
+
+    i. Several security tasks and activities must be routinely performed to operate and administer the system, including but not limited to:
+
+        1. Administering users and access.
+
+        1. Tuning performance.
+
+        1. Performing backups according to requirements defined in the System Availability Policy 
+
+        1. Performing system maintenance (i.e., testing and applying security updates and patches).
+
+        1. Conducting training and awareness.
+
+        1. Conducting periodic system vulnerability assessments.
+
+        1. Conducting annual risk assessments.
+
+    i. Operational systems must:
+
+        1. Be reviewed to ensure that the security controls, both automated and manual, are functioning correctly and effectively.
+
+        1. Have logs that are periodically reviewed to evaluate the security of the system and validate audit controls.
+
+        1. Implement ongoing monitoring of systems and users to ensure detection of security violations and unauthorized changes.
+
+        1. Validate the effectiveness of the implemented security controls through security training as required by the Procedure For Executing Incident Response.
+
+        1. Have a software application and/or hardware patching process that is performed regularly in order to eliminate software bug and security problems being introduced into the organization’s technology environment. Patches and updates must be applied within ninety (90) days of release to provide for adequate testing and propagation of software updates. Emergency, critical, break-fix, and zero-day vulnerability patch releases must be applied as quickly as possible.
+
+a. The following must be completed and/or considered during the decommission phase:
+
+    i. Conduct unit testing and integration testing on the system after component removal.
+
+    i. Conduct operational transition for component removal/replacement.
+
+    i. Determine data retention requirements for application software and systems data.
+
+    i. Document the detailed technical security design.
+
+    i. Update the organization’s policies, standards and procedures, if appropriate.
+
+    i. Assess and document how to mitigate residual application and infrastructure vulnerabilities.
+

example/policies/disaster.md

@@ -9,4 +9,144 @@ majorRevisions:
     comment: Initial document
 ---
 
-# Coming Soon
+# Purpose and Scope
+
+a. The purpose of this policy is to define the organization’s procedures to recover Information Technology (IT) infrastructure and IT services within set deadlines in the case of a disaster or other disruptive incident. The objective of this plan is to complete the recovery of IT infrastructure and IT services within a set Recovery Time Objective (RTO).
+
+a. This policy includes all resources and processes necessary for service and data recovery, and covers all information security aspects of business continuity management.
+
+a. This policy applies to all management, employees and suppliers that are involved in the recovery of IT infrastructure and services within the organization. This policy must be made readily available to all whom it applies to.
+
+# Background
+
+a. This policy defines the overall disaster recovery strategy for the organization. The strategy describes the organization’s Recovery Time Objective (RTO), which is defined as the duration of time and service level for critical business processes to be restored after a disaster or other disruptive event, as well as the procedures, responsibility and technical guidance required to meet the RTO. This policy also lists the contact information for personnel and service providers that may be needed during a disaster recovery event.
+
+a. The following conditions must be met for this plan to be viable:
+
+    i. All equipment, software and data (or their backups/failovers) are available in some manner.
+
+    i. If an incident takes place at the organization’s physical location, all resources involved in recovery efforts are able to be transferred to an alternate work site (such as their home office) to complete their duties.
+
+    i. The Information Security Officer is responsible for coordinating and conducting a bi-annual (at least) rehearsal of this continuity plan. 
+
+a. This plan does not cover the following types of incidents:
+
+    i. Incidents that affect customers or partners but have no effect on the organization’s systems; in this case, the customer must employ their own continuity processes to make sure that they can continue to interact with the organization and its systems.
+
+    i. Incidents that affect cloud infrastructure suppliers at the core infrastructure level, including but not limited to Google, Heroku, and Amazon Web Services. The organization depends on such suppliers to employ their own continuity processes.
+
+# Policy
+
+a. *Relocation*
+
+    i. If the organization’s primary work site is unavailable, an alternate work site shall be used by designated personnel. The organization’s alternate work site is located at [list the address of the alternate work site that the organization will use].
+
+    i. The personnel required to report to the alternate work site during a disaster includes [list the personnel titles responsible for reporting to the alternate work site].
+
+a. *Critical Services, Key Tasks and, Service Level Agreements (SLAs)*
+
+    i. The following services and technologies are considered to be critical for business operations, and must immediately be restored (in priority order):
+  
+        1. [list the critical services and technologies that must remain running during a disaster]
+
+    i. The following key tasks and SLAs must be considered during a disaster recovery event, in accordance with the organization’s objectives, agreements, and legal, contractual or regulatory obligations:
+
+        1. [list of key tasks / SLAs that must be kept operational, with respective deadlines]
+
+a. The organization’s Recovery Time Objective (RTO) is [set the maximum amount of time before critical processes must be restored, to include relocation and getting critical services/technologies back online]. Relocation and restoration of critical services and technologies must be completed within this time period.
+
+a. *Notification of Plan Initiation*
+
+    i. The following personnel must be notified when this plan is initiated:
+
+      1. [list all personnel (including titles) that must be notified of plan initiation ]
+
+    i. [person responsible for notifications, including title] is responsible for notifying the personnel listed above.
+
+a. *Plan Deactivation*
+
+    i. This plan must only be deactivated by [person or persons with authority to deactivate the plan, including job title].
+
+    i. In order for this plan to be deactivated, all relocation activities and critical service / technology tasks  as detailed above must be fully completed and/or restored. If the organization is still operating in an impaired scenario, the plan may still be kept active at the discretion of [person or persons with authority to deactivate the plan, including job title].
+
+    i. The following personnel must be notified when this plan is deactivated:
+
+        1. [list all personnel (including titles) that must be notified of plan activation]
+
+a. The organization must endeavor to restore its normal level of business operations as soon as possible.
+
+a. A list of relevant points of contact both internal and external to the organization is enclosed in Appendix A.
+
+a. During a crisis, it is vital for certain recovery tasks to be performed right away. The following actions are pre-authorized in the event of a disaster recovery event:
+
+    i. [job title] must take all steps specified in this disaster recovery plan in order to recover the organization’s information technology infrastructure and services.
+    
+    i. [job title] is authorized to make urgent purchases of equipment and services up to [amount].
+    
+    i. [job title] is authorized to communicate with clients.
+    
+    i. [job title] is authorized to communicate with the public.
+    
+    i. [job title] is authorized to communicate with public authorities such as state and local governments and law enforcement.
+    
+    i. [job title] is authorized to cooperate with [name of supplier/outsourcing partner].
+    
+    i. [add/modify/remove authorizations in this section as necessary]
+
+a. Specific recovery steps for information systems infrastructure and services are provided in Appendix B.
+
+\pagebreak 
+
+# Appendix A: Relevant Points of Contact
+
+Internal Contacts
+
++------------------+-------------------+------------------+------------------+-----------------+
+|       Name       |     Job Title     |   Phone Number   |  Email Address   |Alternate Contact|
++==================+===================+==================+==================+=================+
+|                  |                   |                  |                  |                 |
+|                  |                   |                  |                  |                 |
++------------------+-------------------+------------------+------------------+-----------------+
+|                  |                   |                  |                  |                 |
+|                  |                   |                  |                  |                 |
++------------------+-------------------+------------------+------------------+-----------------+
+
+External Contacts
+
++------------------+-------------------+------------------+------------------+-----------------+
+|       Name       |     Job Title     |   Phone Number   |  Email Address   |Alternate Contact|
++==================+===================+==================+==================+=================+
+|                  |                   |                  |                  |                 |
+|                  |                   |                  |                  |                 |
++------------------+-------------------+------------------+------------------+-----------------+
+|                  |                   |                  |                  |                 |
+|                  |                   |                  |                  |                 |
++------------------+-------------------+------------------+------------------+-----------------+
+
+\pagebreak
+
+# Appendix B: Recovery Steps for Information Systems Infrastructure & Services
+
+Specific recovery procedures are described in detail below:
+
++----------------------------+----------------------+------------------------------------+
+|     Recovery Procedure     |  Person Responsible  |  Person(s) Notified When Complete  |
++============================+======================+====================================+
+| System to be recovered:    |                      |                                    |                
+|                            |                      |                                    |                 
++----------------------------+----------------------+------------------------------------+
+| task 1:                    |                      |                                    |  
+|                            |                      |                                    |
++----------------------------+----------------------+------------------------------------+            
+| task 2:                    |                      |                                    |   
+|                            |                      |                                    |              
++----------------------------+----------------------+------------------------------------+
+| System to be recovered:    |                      |                                    |                
+|                            |                      |                                    |                 
++----------------------------+----------------------+------------------------------------+
+| task 1:                    |                      |                                    | 
+|                            |                      |                                    |    
++----------------------------+----------------------+------------------------------------+            
+| task 2:                    |                      |                                    |    
+|                            |                      |                                    |             
++----------------------------+----------------------+------------------------------------+

example/policies/encryption.md

@@ -7,5 +7,76 @@ majorRevisions:
   - date: Jun 1 2018
     comment: Initial document
 ---
+# Purpose and Scope
+
+a. This policy defines organizational requirements for the use of cryptographic controls, as well as the requirements for cryptographic keys, in order to protect the confidentiality, integrity, authenticity and nonrepudiation of information.
+
+a. This policy applies to all systems, equipment, facilities and information within the scope of the organization’s information security program.
+
+a. All employees, contractors, part-time and temporary workers, service providers, and those employed by others to perform work on behalf of the organization having to do with cryptographic systems, algorithms, or keying material are subject to this policy and must comply with it.
+
+# Background
+
+a. This policy defines the high level objectives and implementation instructions for the organization’s use of cryptographic algorithms and keys. It is vital that the organization adopt a standard approach to cryptographic controls across all work centers in order to ensure end-to-end security, while also promoting interoperability. This document defines the specific algorithms approved for use, requirements for key management and protection, and requirements for using cryptography in cloud environments.
+
+# Policy
+
+a. The organization must protect individual systems or information by means of cryptographic controls as defined in Table 3: 
+
+\pagebreak 
+
++---------------------+-------------------+----------------+--------------+
+| **Name of System/** | **Cryptographic** | **Encryption** | **Key Size** |
+| **Type of**         | **Tool**          | **Algorithm**  |              |
+| **Information**     |                   |                |              |
++=====================+===================+================+==============+
+| Public Key          |  OpenSSL          | AES-256        | 256-bit key  |
+| Infrastructure for  |                   |                |              |
+| Authentication      |                   |                |              |
++---------------------+-------------------+----------------+--------------+
+|                     |                   |                |              |
++---------------------+-------------------+----------------+--------------+
+| Data Encryption     |  OpenSSL          | AES-256        | 256-bit key  |
+| Keys                |                   |                |              |
++---------------------+-------------------+----------------+--------------+
+|                     |                   |                |              |
++---------------------+-------------------+----------------+--------------+
+| Virtual Private     |  OpenSSL and      | AES-256        | 256-bit key  |
+| Network (VPN)       |  OpenVPN          |                |              |
+| keys                |                   |                |              |
++---------------------+-------------------+----------------+--------------+
+|                     |                   |                |              |
++---------------------+-------------------+----------------+--------------+
+| Website SSL         |  OpenSSL, CERT    | AES-256        | 256-bit key  |
+| Certificate         |                   |                |              | 
++---------------------+-------------------+----------------+--------------+
+
+Table 3: Cryptographic Controls 
+
+ 
+
+b. Except where otherwise stated, keys must be managed by their owners.
+
+c. Cryptographic keys must be protected against loss, change or destruction by applying appropriate access control mechanisms to prevent unauthorized use and backing up keys on a regular basis.
+
+d. When required, customers of the organization’s cloud-based software or platform offering must be able to obtain information regarding:
+
+    i. The cryptographic tools used to protect their information.
+
+    i. Any capabilities that are available to allow cloud service customers to apply their own cryptographic solutions.
+
+    i. The identity of the countries where the cryptographic tools are used to store or transfer cloud service customers’ data.
+
+a. The use of organizationally-approved encryption must be governed in accordance with the laws of the country, region, or other regulating entity in which users perform their work. Encryption must not be used to violate any laws or regulations including import/export restrictions. The encryption used by the Company conforms to international standards and U.S. import/export requirements, and thus can be used across international boundaries for business purposes.
+
+a. All key management must be performed using software that automatically manages access control, secure storage, backup and rotation of keys. Specifically:
+
+  i. The key management service must provide key access to specifically-designated users, with the ability to encrypt/decrypt information and generate data encryption keys.
+
+  i. The key management service must provide key administration access to specifically-designated users, with the ability to create, schedule delete, enable/disable rotation, and set usage policies for keys.
+
+  i. The key management service must store and backup keys for the entirety of their operational lifetime.
+
+  i. The key management service must rotate keys at least once every 12 months.
+
 
-# Coming Soon

example/policies/media.md

@@ -8,4 +8,133 @@ majorRevisions:
     comment: Initial document
 ---
 
-# Coming Soon
+# Purpose and Scope
+
+a. This removable media, cloud storage and Bring Your Own Device (BYOD) policy defines the objectives, requirements and implementing instructions for storing data on removable media, in cloud environments, and on personally-owned devices, regardless of data classification level.
+
+a. This policy applies to all information and data within the organization’s information security program, as well as all removable media, cloud systems and personally-owned devices either owned or controlled by the organization.
+
+a. This policy applies to all users of information systems within the organization. This typically includes employees and contractors, as well as any external parties that come into contact with systems and information controlled by the organization (hereinafter referred to as “users”). This policy must be made readily available to all users.
+
+# Background
+
+a. This policy defines the procedures for safely using  removable media, cloud storage and personally-owned devices to limit data loss or exposure.  Such forms of storage must be strictly controlled because of the sensitive data that can be stored on them. Because each of these storage types are inherently ephemeral or portable in nature, it is possible for the organization to lose the ability to oversee or control the information stored on them if strict security standards are not followed.
+
+a. This document consists of three sections pertaining to removable media, cloud storage, and personally-owned devices. Each section contains requirements and implementing instructions for the registration, management, maintenance, and disposition of each type of storage.
+
+a. Within this policy, the term sensitive information refers to information that is classified as RESTRICTED or CONFIDENTIAL in accordance with the Data Classification Policy (reference (a)).
+
+# References
+
+a. Data Classification Policy
+
+a. Asset Inventory
+
+a. Security Incident Response Policy
+
+a. Encryption Policy
+
+# Policy
+
+a. *Removable Media*
+
+    i. All removable media in active use and containing data pertinent to the organization must be registered in the organization’s Asset Inventory (reference (b)).
+
+    i. All removable media listed in reference (b) must be re-inventoried on a quarterly basis to ensure that it is still within the control of the organization.
+
+        1. To re-inventory an item, the owner of the removable media must check in the item with the organization’s Information Security Manager (ISM).
+
+        1. The ISM must treat any removable media that cannot be located as lost, and a security incident report must be logged in accordance with the Security Incident Response Policy (reference (c)).
+
+    i. The owner of the removable media must conduct all appropriate maintenance on the item at intervals appropriate to the type of media, such as cleaning, formatting, labeling, etc.
+
+    i. The owner of the removable media, where practical, must ensure that an alternate or backup copy of the information located on the device exists.
+
+    i. Removable media must be stored in a safe place that has a reduced risk of fire or flooding damage. 
+
+    i. If the storage item contains sensitive information, removable media must:
+
+        1. Be stored in a locked cabinet or drawer.
+
+        1. Store only encrypted data that is securely enciphered in accordance with the Encryption Policy (reference (d)).
+
+    i. All data on removable media devices must be erased, or the device must be destroyed, before it is reused or disposed of.
+
+    i. When removable media devices are disposed, the device owner must inform the ISM so that it can be removed from reference (b).
+
+a. *Cloud Storage*
+
+    i. All cloud storage systems in active use and containing data pertinent to the organization must be registered in reference (b). Registration may be accomplished by manual or automated means.
+
+
+    i. All cloud storage systems listed in reference (b) must be re-inventoried on a quarterly basis to ensure that it is still within the control of the organization. To re-inventory an item, the owner of the removable media must check in the item with the organization’s Information Security Manager (ISM). Re-inventory may be accomplished by manual or automated means.
+
+    i. The owner of the cloud storage system must conduct all appropriate maintenance on the system at regular intervals to include system configuration, access control, performance monitoring, etc.
+
+    i. Data on cloud storage systems must be replicated to at least one other physical location. Depending on the cloud storage provider, this replication may be automatically configured.
+
+    i. The organization must only use cloud storage providers that can demonstrate, either through security accreditation, demonstration, tour, or other means that their facilities are secured, both physically and electronically, using best practices.
+
+    i. If the cloud storage system contains sensitive information, that information must be encrypted in accordance with reference (d).
+
+    i. Data must be erased from from cloud storage systems using a technology and process that is approved by the ISM. 
+
+    i. When use of a cloud storage system is discontinued, the system owner must inform the ISM so that it can be removed from reference (b).
+
+a. *Personally-owned Devices*
+
+    i. Organizational data that is stored, transferred or processed on personally-owned devices remains under the organization’s ownership, and the organization retains the right to control such data even though it is not the owner of the device.
+
+    i. The ISM is responsible for conducting overall management of personally-owned devices, to include:
+
+        1. Installation and maintenance of Mobile Device Management (MDM) software that can effectively manage, control and wipe data under the organization’s control from personally-owned devices.
+
+        1. Maintain a list of job titles and/or persons authorized to use personally-owned devices for the organization’s business, as well as the applications and databases that may be accessed from such devices.
+
+        1. Maintain a list of applications prohibited from use on personally-owned devices, and ensuring that device users are aware of these restrictions.
+
+    i. Personally-identifiable information (PII) may not be stored, processed or accessed at any time on a personally-owned device.
+
+    i. The following acceptable use requirements must be observed by users of personally-owned devices:
+
+        1. All organizational data must be backed up at regular intervals.
+
+        1. MDM and endpoint protection software must be installed on the device at all times.
+
+        1. Sensitive information stored on the device must be encrypted in accordance with reference (d).
+
+        1. The device must be secured using a password, pin, unlock pattern, fingerprint or equivalent security mechanism.
+
+        1. The device must only connect to secure and encrypted wireless networks.
+
+        1. When using the device outside of the organization’s premises, it must not be left unattended, and if possible, physically secured.
+
+        1. When using the device in public areas, the owner must take measures to ensure that the data cannot be read or accessed by unauthorized persons.
+
+        1. Patches and updates must be installed regularly.
+
+        1. Classified information must be protected in accordance with reference (a).
+
+        1. The device owner must install the ISM before the device is disposed of, sold, or provided to a third party for servicing.
+
+        1. It is prohibited to:
+
+            a. Allow device access for anyone except its owner.
+        
+            a. Store illegal materials on the device.
+
+            a. Install unlicensed software.
+
+            a. Locally-store passwords.
+
+            a. Transfer organizational data to other devices which have not been approved by the organization.
+
+    i. The organization must reserve the right to view, edit, and/or delete any organizational information that is stored, processed or transferred on the device.
+
+    i. The organization must reserve the right to perform full deletion of all of its data on the device if it considers that necessary for the protection of company-related data, without the consent of the device owner.
+
+    i. The organization will not pay the employees (the owners of BYOD) any fee for using the device for work purposes.
+
+    i. The organization will pay for any new software that needs to be installed for company use.
+
+    i. All security breaches related to personally-owned devices must be reported immediately to the ISM. 

example/policies/remote.md

@@ -10,4 +10,50 @@ majorRevisions:
     comment: Initial document
 ---
 
-# Coming Soon
+# Purpose and Scope
+
+a. The purpose of this policy is to define requirements for connecting to the organization’s systems and networks from remote hosts, including personally-owned devices, in order to minimize data loss/exposure.
+
+a. This policy applies to all users of information systems within the organization. This typically includes employees and contractors, as well as any external parties that come into contact with systems and information controlled by the organization (hereinafter referred to as “users”). This policy must be made readily accessible to all users.
+
+# Background
+
+a. The intent of this policy is to minimize the organization’s exposure to damages which may result from the unauthorized remote use of resources, including but not limited to: the loss of sensitive, company confidential data and intellectual property; damage to the organization’s public image; damage to the organization’s internal systems; and fines and/or other financial liabilities incurred as a result of such losses.
+
+a. Within this policy, the following definitions apply:
+
+    i. *Mobile computing equipment:* includes portable computers, mobile phones, smart phones, memory cards and other mobile equipment used for storage, processing and transfer of data.
+
+    i. *Remote host:* is defined as an information system, node or network that is not under direct control of the organization.
+
+    i. *Telework:* the act of using mobile computing equipment and remote hosts to perform work outside the organization’s physical premises. Teleworking does not include the use of mobile phones.
+
+# Policy
+
+a. *Security Requirements for Remote Hosts and Mobile Computing Equipment*
+
+    i. Caution must be exercised when mobile computing equipment is placed or used in uncontrolled spaces such as vehicles, public spaces, hotel rooms, meeting places, conference centers, and other unprotected areas outside the organization’s premises.
+
+    i. When using remote hosts and mobile computing equipment, users must take care that information on the device (e.g. displayed on the screen) cannot be read by unauthorized persons if the device is being used to connect to the organization’s systems or work with the organization’s data.
+
+    i. Remote hosts must be updated and patched for the latest security updates on at least a monthly basis.
+
+    i. Remote hosts must have endpoint protection software (e.g. malware scanner) installed and updated at all times.
+
+    i. Persons using mobile computing equipment off-premises are responsible for regular backups of organizational data that resides on the the device.
+
+    i. Access to the organization’s systems must be done through an encrypted and authenticated VPN connection with multi-factor authentication enabled. All users requiring remote access must be provisioned with VPN credentials from the organization’s information technology team. VPN keys must be rotated at least twice per year. Revocation of VPN keys must be included in the Offboarding Policy. 
+
+    i. Information stored on mobile computing equipment must be encrypted using hard drive full disk encryption.
+
+a. *Security Requirements for Telework*
+
+    i. Employees must be specifically authorized for telework in writing from their hiring manager .
+
+    i. Only device’s assigned owner is permitted to use remote nodes and mobile computing equipment. Unauthorized users (such as others living or working at the location where telework is performed) are not permitted to use such devices.
+
+    i. Devices must be authorized using certificates
+
+    i. Users performing telework are responsible for the appropriate configuration of the local network used for connecting to the Internet at their telework location.
+
+    i. Users performing telework must protect the organization’s intellectual property rights, either for software or other materials that are present on remote nodes and mobile computing equipment.

example/policies/retention.md

@@ -10,4 +10,79 @@ majorRevisions:
     comment: Initial document
 ---
 
-# Coming Soon
+#Appendices
+Appendix A: Retention Periods
+
+# Purpose and Scope
+
+a. This data retention policy defines the objectives and requirements for data retention within the organization.
+
+a. This policy covers all data within the organization’s custody or control, irregardless of the medium the data is stored in (electronic form, paper form, etc.) Within this policy, the medium which holds data is referred to as information, no matter what form it is in.
+
+a. This policy applies to all users of information systems within the organization. This typically includes employees and contractors, as well as any external parties that come into contact with systems and information the organization owns or controls (hereinafter referred to as “users”). This policy must be made readily available to all users.
+
+# Background
+
+a. The organization is bound by multiple legal, regulatory and contractual obligations with regard to the data it retains. These obligations stipulate how long data can be retained, and how data must be destroyed. Examples of legal, regulatory and contractual obligations include laws and regulations in the local jurisdiction where the organization conducts business, and contracts made with employees, customers, service providers, partners and others.
+
+a. The organization may also be involved in events such as litigation or disaster recovery scenarios that require it to have access to original information in order to protect the organization’s interests or those of its employees, customers, service providers, partners and others. As a result, the organization may need to archive and store information for longer that it may be needed for day-to-day operations.
+ 
+ \pagebreak 
+
+# Policy
+
+a. *Information Retention*
+
+    i. Retention is defined as the maintenance of information in a production or live environment which can be accessed by an authorized user in the ordinary course of business. 
+
+    i. Information used in the development, staging, and testing of systems shall not be retained beyond their active use period nor copied into production or live environments.
+
+    i. By default, the retention period of information shall be an active use period of exactly two years from its creation unless an exception is obtained permitting a longer or shorter retention period. The business unit responsible for the information must request the exception.
+
+    i. After the active use period of information is over in accordance with this policy and approved exceptions, information must be archived for a defined period. Once the defined archive period is over, the information must be destroyed.
+
+    i. Each business unit is responsible for the information it creates, uses, stores, processes and destroys, according to the requirements of this policy. The responsible business unit is considered to be the information owner.
+
+    i. The organization’s legal counsel may issue a litigation hold to request that information relating to potential or actual litigation, arbitration or other claims, demands, disputes or regulatory action be retained in accordance with instructions from the legal counsel.
+
+    i. Each employee and contractor affiliated with the company must return information in their possession or control to the organization upon separation and/or retirement.
+
+    i. Information owners must enforce the retention, archiving and destruction of information, and communicate these periods to relevant parties.
+
+a. *Information Archiving*
+
+    i. Archiving is defined as secured storage of information such that the information is rendered inaccessible by authorized users in the ordinary course of business but can be retrieved by an administrator designated by company management.
+
+        1. Physical (e.g., paper) records must be archived in secured storage (onsite or offsite) and clearly labeled in archive boxes naming the information owner.
+
+        1. Electronic records must be archived with strict access controls set by the information owner and appropriate to secure the confidentiality, integrity and accessibility of the information.
+
+    i. The default archiving period of information shall be 7 years unless an approved exception permits a longer or shorter period. Exceptions must be requested by the information owner.
+
+        1. As a guideline, an archiving period of more than 7 years may be granted for information with a vital historical purpose such as corporate records, contracts, and technical/trade secrets.
+
+        1. As a guideline, an archiving period of less than 7 years may be granted for information with a limited business purpose such as email, travel itineraries, pre-trip advisories, or to comply with specific legal, contractual and/or regulatory requirements (e.g., PCI DSS, GDPR, etc.)
+
+    i. Information must be destroyed (defined below) at the end of the elapsed archiving period.  
+
+a. *Information Destruction*
+
+    i. Destruction is defined as the physical or technical destruction sufficient to render the information contained in the document irretrievable by ordinary commercially-available means.
+
+    i. The organization must maintain and enforce a detailed list of approved destruction methods appropriate for each type of information archived, whether in physical storage media such as CD-ROMs, DVDs, backup tapes, hard drives, mobile devices, portable drives or in database records or backup files. Physical information in paper form must be shredded using an authorized shredding device; waste must be periodically removed by approved personnel.
+
+a. Retention and archival periods for information that is created, processed, stored and used by the organization is defined in Appendix A, “Retention Periods.” 
+
+\pagebreak 
+
+# Appendix A: Retention Periods 
+
++------------------+-------------------+------------------+------------------+-----------------+
+| Information Type | Information Owner | Storage Location | Retention Period | Archival Period |
++==================+===================+==================+==================+=================+
+|                  |                   |                  |                  |                 |
+|                  |                   |                  |                  |                 |
++------------------+-------------------+------------------+------------------+-----------------+
+|                  |                   |                  |                  |                 |
+|                  |                   |                  |                  |                 |
++------------------+-------------------+------------------+------------------+-----------------+

example/policies/risk.md

@@ -8,4 +8,130 @@ majorRevisions:
     comment: Initial document
 ---
 
-# Coming Soon
+# Purpose and Scope
+
+a. The purpose of this policy is to define the methodology for the assessment and treatment of information security risks within the organization, and to define the acceptable level of risk as set by the organization’s leadership.
+
+a. Risk assessment and risk treatment are applied to the entire scope of the organization’s information security program, and to all assets which are used within the organization or which could have an impact on information security within it.
+
+a. This policy applies to all employees of the organization who take part in risk assessment and risk treatment.
+
+# Background
+
+a. A key element of the organization’s information security program is a holistic and systematic approach to risk management. This policy defines the requirements and processes for the organization to identify information security risks. The process consists of four parts: identification of the organization’s assets, as well as the threats and vulnerabilities that apply; assessment of the likelihood and consequence (risk) of the threats and vulnerabilities being realized, identification of treatment for each unacceptable risk, and evaluation of the residual risk after treatment.
+
+# References
+
+a. Risk Assessment Report Template
+
+# Policy
+
+a. *Risk Assessment*
+
+    i. The risk assessment process includes the identification of threats and vulnerabilities having to do with company assets.
+
+    i. The first step in the risk assessment is to identify all assets within the scope of the information security program; in other words, all assets which may affect the confidentiality, integrity, and/or availability of information in the organization. Assets may include documents in paper or electronic form, applications, databases, information technology equipment, infrastructure, and external/outsourced services and processes. For each asset, an owner must be identified.
+
+    i. The next step is to identify all threats and vulnerabilities associated with each asset. Threats and vulnerabilities must be listed in a risk assessment table. Each asset may be associated with multiple threats, and each threat may be associated with multiple vulnerabilities. A sample risk assessment table is provided as part of the Risk Assessment Report Template (reference (a)).
+
+    i. For each risk, an owner must be identified. The risk owner and the asset owner may be the same individual.
+
+    i. Once risk owners are identified, they must assess:
+
+        1. Consequences for each combination of threats and vulnerabilities for an individual asset if such a risk materializes. 
+
+        1. Likelihood of occurrence of such a risk (i.e. the probability that a threat will exploit the vulnerability of the respective asset).
+
+        1. Criteria for determining consequence and likelihood are defined in Tables 3 and 4.
+    
+    i. The risk level is calculated by adding the consequence score and the likelihood score.
+
++-----------------+-----------------+--------------------------------------------------------------+
+| **Consequence** | **Consequence** | **Description**                                              | 
+| **Level**       | **Score**       |                                                              |
++=================+=================+==============================================================+
+| Low             | 0               | Loss of confidentiality, integrity, or availability will not |     
+|                 |                 | affect the organization's cash flow, legal, or contractual   |                    
+|                 |                 | obligations, or reputation.                                  |
++-----------------+-----------------+--------------------------------------------------------------+
+|                 |                 |                                                              |  
++-----------------+-----------------+--------------------------------------------------------------+
+| Moderate        | 1               | Loss of confidentiality, integrity, or availability may incur|     
+|                 |                 | financial cost and has low or moderate impact on the         |                    
+|                 |                 | organization's legal or contractual obligations and/or       |
+|                 |                 | reputation.                                                  |
++-----------------+-----------------+--------------------------------------------------------------+
+|                 |                 |                                                              |  
++-----------------+-----------------+--------------------------------------------------------------+
+| High            | 2               | Loss of confidentiality, integrity, or availability will have|     
+|                 |                 | immediate and or/considerable impact on the organization's   |                    
+|                 |                 | cash flow, operations, legal and contractual obligations,and/|
+|                 |                 | or reputation.                                               |
++-----------------+-----------------+--------------------------------------------------------------+
+|                 |                 |                                                              |  
++-----------------+-----------------+--------------------------------------------------------------+
+
+Table 3: Description of Consequence Levels and Criteria
+
++-----------------+-----------------+--------------------------------------------------------------+
+| **Likelihood**  | **Likelihood**  | **Description**                                              | 
+| **Level**       | **Score**       |                                                              |
++=================+=================+==============================================================+
+| Low             | 0               | Either existing security controls are strong and have so far |     
+|                 |                 | provided an adequate level of protection, or the probability |                    
+|                 |                 | of the risk being realized is extremely low. No new incidents|
+|                 |                 | are expected in the future.                                  |
++-----------------+-----------------+--------------------------------------------------------------+
+|                 |                 |                                                              |  
++-----------------+-----------------+--------------------------------------------------------------+
+| Moderate        | 1               | Either existing security controls have most provided an      |     
+|                 |                 | adequate level of protection or the probability of the risk  |                    
+|                 |                 | being realized is moderate. Some minor incidents may have    |
+|                 |                 | occured. New incidents are possible, but not highly likely.  |
++-----------------+-----------------+--------------------------------------------------------------+
+|                 |                 |                                                              |  
++-----------------+-----------------+--------------------------------------------------------------+
+| High            | 2               | Either existing security controls are not in place or        |
+|                 |                 | ineffective; there is a high probability of the risk being   |                    
+|                 |                 | realized. Incidents have a high likelihood of occuring in the|
+|                 |                 | future.                                             |
++-----------------+-----------------+--------------------------------------------------------------+
+|                 |                 |                                                              |  
++-----------------+-----------------+--------------------------------------------------------------+
+
+Table 4: Description of Likelihood Levels and Criteria
+
+ 
+
+b. *Risk Acceptance Criteria*
+
+    i. Risk values 0 through 2 are considered to be acceptable risks.
+
+    i. Risk values 3 and 4 are considered to be unacceptable risks. Unacceptable risks must be treated.
+
+c. *Risk Treatment*
+
+    i. Risk treatment is implemented through the Risk Treatment Table. All risks from the Risk Assessment Table must be copied to the Risk Treatment Table for disposition, along with treatment options and residual risk. A sample Risk Treatment Table is provided in reference (a).
+
+    i. As part of this risk treatment process, the CEO and/or other company managers shall determine objectives for mitigating or treating risks. All unacceptable risks must be treated. For continuous improvement purposes, company managers may also opt to treat other risks for company assets, even if their risk score is deemed to be acceptable.
+
+    i. Treatment options for risks include the following options:
+
+        1. Selection or development of security control(s).
+
+        1. Transferring the risks to a third party; for example, by purchasing an insurance policy or signing a contract with suppliers or partners.
+
+        1. Avoiding the risk by discontinuing the business activity that causes such risk.
+
+        1. Accepting the risk; this option is permitted only if the selection of other risk treatment options would cost more than the potential impact of the risk being realized.
+
+    i. After selecting a treatment option, the risk owner should estimate the new consequence and likelihood values after the planned controls are implemented.
+
+a. *Regular Reviews of Risk Assessment and Risk Treatment*
+
+    i. The Risk Assessment Table and Risk Treatment Table must be updated when newly identified risks are identified. At a minimum, this update and review shall be conducted once per year. It is highly recommended that the Risk Assessment and Risk Treatment Table be updated when significant changes occur to the organization, technology, business objectives, or business environment.
+
+a. *Reporting*
+
+    i. The results of risk assessment and risk treatment, and all subsequent reviews, shall be documented in a Risk Assessment Report.
+

example/policies/vendor.md

@@ -8,4 +8,40 @@ majorRevisions:
     comment: Initial document
 ---
 
-# Coming Soon
+# Purpose and Scope
+
+a. This policy defines the rules for relationships with the organization’s Information Technology (IT) vendors and partners. 
+
+a. This policy applies to all IT vendors and partners who have the ability to impact the confidentiality, integrity, and availability of the organization’s technology and sensitive information, or who are within the scope of the organization’s information security program.
+
+a. This policy applies to all employees and contractors that are responsible for the management and oversight of IT vendors and partners of the organization. 
+
+# Background
+
+a. The overall security of the organization is highly dependent on the security of its contractual relationships with its IT suppliers and partners. This policy defines  requirements for effective management and oversight of such suppliers and partners from an information security perspective. The policy prescribes minimum standards a vendor must meet from an information security standpoint, including security clauses, risk assessments, service level agreements, and incident management.
+
+# References
+
+a. Information Security Policy
+
+a. Security Incident Response Policy
+
+# Policy
+
+a. IT vendors are prohibited from accessing the organization’s information security assets until  a contract containing security controls is agreed to and signed by the appropriate parties.
+
+a. All IT vendors must comply with the security policies defined and derived from the Information Security Policy (reference (a)). 
+
+a. All security incidents by IT vendors or partners must be documented in accordance with the organization’s Security Incident Response Policy (reference (b)) and immediately forwarded to the Information Security Manager (ISM). 
+
+a. The organization must adhere to the terms of all Service Level Agreements (SLAs) entered into with IT vendors. As terms are updated, and as new ones are entered into, the organization must implement any changes or controls needed to ensure it remains in compliance. 
+
+a. Before entering into a contract and gaining access to the parent organization’s information systems, IT vendors must undergo a risk assessment. 
+
+    i. Security risks related to IT vendors and partners must be identified during the risk assessment process. 
+    
+    i. The risk assessment must identify risks related to information and communication technology, as well as risks related to IT vendor supply chains, to include sub-suppliers. 
+
+a. IT vendors and partners must ensure that organizational records are protected, safeguarded, and disposed of securely. The organization strictly adheres to all applicable legal, regulatory and contractual requirements regarding the collection, processing, and transmission of sensitive data such as Personally-Identifiable Information (PII). 
+
+a. The organization may choose to audit IT vendors and partners to ensure compliance with applicable security policies, as well as legal, regulatory and contractual obligations.

example/procedures/offboarding.md

@@ -2,4 +2,10 @@ id: "offboard"
 name: "Offboard User"
 ---
 
-# Coming Soon
+Resolve this ticket by executing the following steps:
+
+- [ ] Immediately suspend user in SSO
+- [ ] Append HR termination request e-mail to this ticket
+- [ ] Look up manually-provisioned applications for this role or user
+- [ ] Validate access revocation in each
+- [ ] Append confirmation or revocation to this ticket

example/procedures/onboarding.md

@@ -2,4 +2,11 @@ id: "onboard"
 name: "Onboard New User"
 ---
 
-# Coming Soon
+Resolve this ticket by executing the following steps:
+
+- [ ] Append HR add request e-mail to this ticket
+- [ ] Proactively validate role assignment with manager (see HR request e-mail)
+- [ ] Add user to default group for the specified role
+- [ ] Provision any manually-provisioned applications by role
+    - [ ] Append manual provisioning confirmation to this ticket
+- [ ] Proactively confirm with new user that they can access all provisioned systems

example/procedures/patch.md

@@ -1,6 +1,15 @@
 id: "patch"
 name: "Apply OS patches"
-cron: "0 0 1 * * *"
+cron: "0 0 0 15 * *"
 ---
 
-# Coming Soon
+# OS Patch Procedure
+
+Resolve this ticket by executing the following steps:
+
+- [ ] Pull the latest scripts from the Ops repository
+- [ ] Execute `ENV=staging patch-all.sh`
+- [ ] Inspect output
+    - [ ] Errors? Investigate and resolve
+- [ ] Execute `ENV=production patch-all.sh`
+- [ ] Attach log output to this ticket

example/procedures/workstation.md

@@ -1,6 +1,40 @@
 id: "workstation"
 name: "Collect Workstation Details"
-cron: "0 0 * * * *"
+cron: "0 0 0 15 4 *"
 ---
 
-# Coming Soon
+Resolve this ticket by executing the following steps:
+
+- [ ] Send the communications below
+- [ ] For any email replies, attach content to this ticket
+- [ ] Validate responses are received from each
+
+
+```
+To: Desktop support
+Subject: Annual workstation inventory
+
+Please attach the current workstation inventory to the following ticket: [REPLACE WITH URL TO THIS TICKET]
+
+The workstation inventory shall include the following fields:
+    * Serial number
+    * Custodian
+    * Full disk encryption status
+    * Malware protection status
+```
+
+
+```
+To: Outsourced Call Center IT
+Subject: Annual workstation inventory
+
+As part of our ongoing compliance efforts and per our services agreement, we require a current inventory of workstations in use in the service of our account.
+
+Please respond to this message with the current inventory.
+
+The workstation inventory shall include the following fields:
+    * Serial number
+    * Custodian
+    * Full disk encryption status
+    * Malware protection status
+```

internal/cli/app.go

@@ -6,15 +6,24 @@ import (
 	"io"
 	"io/ioutil"
 	"log"
+	"math/rand"
+	"net/http"
 	"os"
+	"os/exec"
 	"path/filepath"
+	"regexp"
+	"strconv"
 	"strings"
 	"time"
+	"unicode"
+	"unicode/utf8"
 
 	"github.com/docker/docker/api/types"
 	"github.com/docker/docker/client"
 	"github.com/pkg/errors"
 	"github.com/strongdm/comply/internal/config"
+	"github.com/strongdm/comply/internal/gitlab"
+	"github.com/strongdm/comply/internal/jira"
 	"github.com/strongdm/comply/internal/plugin/github"
 	"github.com/urfave/cli"
 )
@@ -40,18 +49,20 @@ func newApp() *cli.App {
 	app.Usage = "policy compliance toolkit"
 
 	app.Commands = []cli.Command{
-		initCommand,
+		beforeCommand(initCommand, notifyVersion),
 	}
 
-	app.Commands = append(app.Commands, beforeCommand(buildCommand, projectMustExist))
-	app.Commands = append(app.Commands, beforeCommand(procedureCommand, projectMustExist))
-	app.Commands = append(app.Commands, beforeCommand(schedulerCommand, projectMustExist))
-	app.Commands = append(app.Commands, beforeCommand(serveCommand, projectMustExist))
-	app.Commands = append(app.Commands, beforeCommand(syncCommand, projectMustExist))
-	app.Commands = append(app.Commands, beforeCommand(todoCommand, projectMustExist))
+	app.Commands = append(app.Commands, beforeCommand(buildCommand, projectMustExist, notifyVersion))
+	app.Commands = append(app.Commands, beforeCommand(procedureCommand, projectMustExist, notifyVersion))
+	app.Commands = append(app.Commands, beforeCommand(schedulerCommand, projectMustExist, notifyVersion))
+	app.Commands = append(app.Commands, beforeCommand(serveCommand, projectMustExist, notifyVersion))
+	app.Commands = append(app.Commands, beforeCommand(syncCommand, projectMustExist, notifyVersion))
+	app.Commands = append(app.Commands, beforeCommand(todoCommand, projectMustExist, notifyVersion))
 
 	// Plugins
 	github.Register()
+	jira.Register()
+	gitlab.Register()
 
 	return app
 }
@@ -96,7 +107,157 @@ func ticketingMustBeConfigured(c *cli.Context) error {
 	return nil
 }
 
-func dockerMustExist(c *cli.Context) error {
+// notifyVersion asynchronously notifies the availability of version updates
+func notifyVersion(c *cli.Context) error {
+	go func() {
+		defer func() {
+			recover() // suppress panic
+		}()
+
+		r, err := http.Get("http://comply-releases.s3.amazonaws.com/channel/stable/VERSION")
+		body, err := ioutil.ReadAll(r.Body)
+		if err != nil {
+			// fail silently
+		}
+
+		version := strings.TrimSpace(string(body))
+
+		// only when numeric versions are present
+		firstRune, _ := utf8.DecodeRuneInString(string(body))
+		if unicode.IsDigit(firstRune) && version != Version {
+			// only once every ~10 times
+			if rand.Intn(10) == 0 {
+				fmt.Fprintf(os.Stderr, "a new version of comply is available")
+			}
+		}
+	}()
+	return nil
+}
+
+func pandocMustExist(c *cli.Context) error {
+	eitherMustExistErr := fmt.Errorf("\n\nPlease install either Docker or the pandoc package and re-run `%s`. Find OS-specific pandoc installation instructions at: [TODO]", c.Command.Name)
+
+	pandocExistErr, found, goodVersion, pdfLatex := pandocBinaryMustExist(c)
+	dockerExistErr, inPath, isRunning := dockerMustExist(c)
+
+	config.SetPandoc(pandocExistErr == nil, dockerExistErr == nil)
+	check := func(b bool) string {
+		if b {
+			return "✔"
+		} else {
+			return "✖"
+		}
+
+	}
+
+	if pandocExistErr != nil && dockerExistErr != nil {
+
+		fmt.Printf(`
+[%s] pandoc binary installed and in PATH
+[%s] pandoc version compatible
+[%s] pdflatex binary installed and in PATH
+[%s] docker binary installed
+[%s] docker running
+
+`, check(found), check(goodVersion), check(pdfLatex), check(inPath), check(isRunning))
+
+		return eitherMustExistErr
+	}
+
+	// if we don't have pandoc, but we do have docker, execute a pull
+	if (pandocExistErr != nil && dockerExistErr == nil) || config.WhichPandoc() == config.UseDocker {
+		dockerPull(c)
+	}
+
+	return nil
+}
+
+func pandocBinaryMustExist(c *cli.Context) (e error, found, goodVersion, pdfLatex bool) {
+	cmd := exec.Command("pandoc", "-v")
+	outputRaw, err := cmd.Output()
+
+	e = nil
+	found = false
+	goodVersion = false
+	pdfLatex = false
+
+	if err != nil {
+		e = errors.Wrap(err, "error calling pandoc")
+	} else {
+		found = true
+		goodVersion = true
+		output := strings.TrimSpace((string(outputRaw)))
+		versionErr := errors.New("cannot determine pandoc version")
+		if !strings.HasPrefix(output, "pandoc") {
+			e = versionErr
+			goodVersion = false
+		} else {
+			re := regexp.MustCompile(`pandoc (\d+)\.(\d+)`)
+			result := re.FindStringSubmatch(output)
+			if len(result) != 3 {
+				e = versionErr
+				goodVersion = false
+			} else {
+				major, err := strconv.Atoi(result[1])
+				if err != nil {
+					e = versionErr
+					goodVersion = false
+				}
+				minor, err := strconv.Atoi(result[2])
+				if err != nil {
+					e = versionErr
+					goodVersion = false
+				}
+				if major < 2 || minor < 1 {
+					e = errors.New("pandoc 2.1 or greater required")
+					goodVersion = false
+				}
+			}
+		}
+	}
+
+	// pdflatex must also be present
+	cmd = exec.Command("pdflatex", "--version")
+	outputRaw, err = cmd.Output()
+	if err != nil {
+		e = errors.Wrap(err, "error calling pdflatex")
+	} else if !strings.Contains(string(outputRaw), "TeX") {
+		e = errors.New("pdflatex is required")
+	} else {
+		pdfLatex = true
+	}
+
+	return e, found, goodVersion, pdfLatex
+}
+
+func dockerMustExist(c *cli.Context) (e error, inPath, isRunning bool) {
+	dockerErr := fmt.Errorf("Docker must be available in order to run `%s`", c.Command.Name)
+
+	inPath = true
+	cmd := exec.Command("docker", "--version")
+	_, err := cmd.Output()
+	if err != nil {
+		inPath = false
+	}
+
+	isRunning = true
+	ctx := context.Background()
+	cli, err := client.NewEnvClient()
+	if err != nil {
+		isRunning = false
+		return dockerErr, inPath, isRunning
+	}
+
+	_, err = cli.Ping(ctx)
+	if err != nil {
+		isRunning = false
+		return dockerErr, inPath, isRunning
+	}
+
+	return nil, inPath, isRunning
+}
+
+func dockerPull(c *cli.Context) error {
 	dockerErr := fmt.Errorf("Docker must be available in order to run `%s`", c.Command.Name)
 
 	ctx := context.Background()
@@ -146,12 +307,17 @@ func dockerMustExist(c *cli.Context) error {
 }
 
 func cleanContainers(c *cli.Context) error {
-	dockerErr := fmt.Errorf("Docker must be available in order to run `%s`", c.Command.Name)
-
 	ctx := context.Background()
 	cli, err := client.NewEnvClient()
 	if err != nil {
-		return dockerErr
+		// no Docker? nothing to clean.
+		return nil
+	}
+
+	_, err = cli.Ping(ctx)
+	if err != nil {
+		// no Docker? nothing to clean.
+		return nil
 	}
 
 	containers, err := cli.ContainerList(ctx, types.ContainerListOptions{All: true})

internal/cli/build.go

@@ -11,7 +11,7 @@ var buildCommand = cli.Command{
 	ShortName: "b",
 	Usage:     "generate a static website summarizing the compliance program",
 	Action:    buildAction,
-	Before:    beforeAll(dockerMustExist, cleanContainers),
+	Before:    beforeAll(pandocMustExist, cleanContainers),
 }
 
 func buildAction(c *cli.Context) error {

internal/cli/init.go

@@ -100,7 +100,7 @@ func initAction(c *cli.Context) error {
 
 	chooser = promptui.Select{
 		Label: "Ticket System",
-		Items: []string{"GitHub", "Jira", "None"},
+		Items: []string{"GitHub", "Jira", "GitLab", "None"},
 	}
 
 	choice, _, err = chooser.Run()
@@ -116,8 +116,9 @@ func initAction(c *cli.Context) error {
 	case 0:
 		ticketing = model.GitHub
 	case 1:
-		fmt.Println("\nHello Jira user! The Jira ticketing plugin is currently in development, please join us on Slack for a status update.")
-		ticketing = model.NoTickets
+		ticketing = model.Jira
+	case 2:
+		ticketing = model.GitLab
 	default:
 		ticketing = model.NoTickets
 	}

internal/cli/procedure.go

@@ -3,6 +3,7 @@ package cli
 import (
 	"fmt"
 
+	"github.com/strongdm/comply/internal/config"
 	"github.com/strongdm/comply/internal/model"
 	"github.com/urfave/cli"
 )
@@ -13,7 +14,7 @@ var procedureCommand = cli.Command{
 	Usage:     "create ticket by procedure ID",
 	ArgsUsage: "procedureID",
 	Action:    procedureAction,
-	Before:    projectMustExist,
+	Before:    beforeAll(projectMustExist, ticketingMustBeConfigured),
 }
 
 func procedureAction(c *cli.Context) error {
@@ -28,14 +29,22 @@ func procedureAction(c *cli.Context) error {
 
 	procedureID := c.Args().First()
 
+	ts, err := config.Config().TicketSystem()
+	if err != nil {
+		return cli.NewExitError("error in ticket system configuration", 1)
+	}
+
+	tp := model.GetPlugin(model.TicketSystem(ts))
+
 	for _, procedure := range procedures {
 		if procedure.ID == procedureID {
-			// TODO: don't hardcode GH
-			tp := model.GetPlugin(model.GitHub)
-			tp.Create(&model.Ticket{
+			err = tp.Create(&model.Ticket{
 				Name: procedure.Name,
 				Body: fmt.Sprintf("%s\n\n\n---\nProcedure-ID: %s", procedure.Body, procedure.ID),
 			}, []string{"comply", "comply-procedure"})
+			if err != nil {
+				return err
+			}
 			return nil
 		}
 	}

internal/cli/serve.go

@@ -10,7 +10,7 @@ var serveCommand = cli.Command{
 	Name:   "serve",
 	Usage:  "live updating version of the build command",
 	Action: serveAction,
-	Before: beforeAll(dockerMustExist, cleanContainers),
+	Before: beforeAll(pandocMustExist, cleanContainers),
 }
 
 func serveAction(c *cli.Context) error {

internal/cli/sync.go

@@ -1,6 +1,7 @@
 package cli
 
 import (
+	"github.com/strongdm/comply/internal/config"
 	"github.com/strongdm/comply/internal/model"
 	"github.com/urfave/cli"
 )
@@ -13,8 +14,12 @@ var syncCommand = cli.Command{
 }
 
 func syncAction(c *cli.Context) error {
-	// TODO: unhardcode plugin
-	tp := model.GetPlugin(model.GitHub)
+	ts, err := config.Config().TicketSystem()
+	if err != nil {
+		return cli.NewExitError("error in ticket system configuration", 1)
+	}
+
+	tp := model.GetPlugin(model.TicketSystem(ts))
 	tickets, err := tp.FindByTagName("comply")
 	if err != nil {
 		return err

internal/config/config.go

@@ -1,6 +1,7 @@
 package config
 
 import (
+	"errors"
 	"io/ioutil"
 	"os"
 	"path/filepath"
@@ -10,15 +11,54 @@ import (
 
 var projectRoot string
 
+var dockerAvailable, pandocAvailable bool
+
+const (
+	Jira      = "jira"
+	GitHub    = "github"
+	GitLab    = "gitlab"
+	NoTickets = "none"
+)
+
+const (
+	// UseDocker invokes pandoc within Docker
+	UseDocker = "docker"
+	// UsePandoc invokes pandoc directly
+	UsePandoc = "pandoc"
+)
+
 // SetProjectRoot is used by the test suite.
 func SetProjectRoot(dir string) {
 	projectRoot = dir
 }
 
 type Project struct {
-	Name       string                 `yaml:"name"`
-	FilePrefix string                 `yaml:"filePrefix"`
-	Tickets    map[string]interface{} `yaml:"tickets"`
+	Name           string                 `yaml:"name"`
+	Pandoc         string                 `yaml:"pandoc,omitempty"`
+	FilePrefix     string                 `yaml:"filePrefix"`
+	Tickets        map[string]interface{} `yaml:"tickets"`
+	ApprovedBranch string                 `yaml:"approvedBranch"`
+}
+
+// SetPandoc records pandoc availability during initialization
+func SetPandoc(pandoc bool, docker bool) {
+	pandocAvailable = pandoc
+	dockerAvailable = docker
+}
+
+// WhichPandoc indicates which pandoc invocation path should be used
+func WhichPandoc() string {
+	cfg := Config()
+	if cfg.Pandoc == UsePandoc {
+		return UsePandoc
+	}
+	if cfg.Pandoc == UseDocker {
+		return UseDocker
+	}
+	if pandocAvailable {
+		return UsePandoc
+	}
+	return UseDocker
 }
 
 // YAML is the parsed contents of ProjectRoot()/config.yml.
@@ -42,14 +82,14 @@ func Exists() bool {
 }
 
 // Config is the parsed contents of ProjectRoot()/config.yml.
-func Config() Project {
+func Config() *Project {
 	p := Project{}
 	cfgBytes, err := ioutil.ReadFile(filepath.Join(ProjectRoot(), "comply.yml"))
 	if err != nil {
 		panic("unable to load config.yml: " + err.Error())
 	}
 	yaml.Unmarshal(cfgBytes, &p)
-	return p
+	return &p
 }
 
 // ProjectRoot is the fully-qualified path to the root directory.
@@ -64,3 +104,29 @@ func ProjectRoot() string {
 
 	return projectRoot
 }
+
+// TicketSystem indicates the type of the configured ticket system
+func (p *Project) TicketSystem() (string, error) {
+	if len(p.Tickets) > 1 {
+		return NoTickets, errors.New("multiple ticket systems configured")
+	}
+
+	for k := range p.Tickets {
+		switch k {
+		case GitHub:
+			return GitHub, nil
+		case Jira:
+			return Jira, nil
+		case GitLab:
+			return GitLab, nil
+		case NoTickets:
+			return NoTickets, nil
+		default:
+			// explicit error for this case
+			return "", errors.New("unrecognized ticket system configured")
+		}
+	}
+
+	// no ticket block configured
+	return NoTickets, nil
+}

internal/gitlab/gitlab.go

@@ -0,0 +1,189 @@
+package gitlab
+
+import (
+	"fmt"
+	"strconv"
+	"sync"
+
+	"github.com/pkg/errors"
+	"github.com/strongdm/comply/internal/model"
+	"github.com/xanzy/go-gitlab"
+)
+
+const (
+	cfgDomain = "domain"
+	cfgToken  = "token"
+	cfgRepo   = "repo"
+)
+
+var prompts = map[string]string{
+	cfgDomain: "Fully Qualified GitLab Domain",
+	cfgToken:  "GitLab Token",
+	cfgRepo:   "GitLab Repository",
+}
+
+// Prompts are human-readable configuration element names
+func (g *gitlabPlugin) Prompts() map[string]string {
+	return prompts
+}
+
+// Register causes the Github plugin to register itself
+func Register() {
+	model.Register(model.GitLab, &gitlabPlugin{})
+}
+
+type gitlabPlugin struct {
+	domain   string
+	token    string
+	reponame string
+
+	clientMu sync.Mutex
+	client   *gitlab.Client
+}
+
+func (g *gitlabPlugin) api() *gitlab.Client {
+	g.clientMu.Lock()
+	defer g.clientMu.Unlock()
+	if g.client == nil {
+		// get go-gitlab client
+		gl := gitlab.NewClient(nil, g.token)
+		gl.SetBaseURL(g.domain)
+		g.client = gl
+	}
+	return g.client
+}
+
+func (g *gitlabPlugin) Get(ID string) (*model.Ticket, error) {
+	return nil, nil
+}
+
+func (g *gitlabPlugin) Configured() bool {
+	return g.reponame != "" && g.token != ""
+}
+
+func (g *gitlabPlugin) Links() model.TicketLinks {
+	links := model.TicketLinks{}
+	links.AuditAll = fmt.Sprintf("%s/%s/issues?scope=all&utf8=✓&state=all&label_name[]=comply-audit", g.domain, g.reponame)
+	links.AuditOpen = fmt.Sprintf("%s/%s/issues?scope=all&utf8=✓&state=opened&label_name[]=comply-audit", g.domain, g.reponame)
+	links.ProcedureAll = fmt.Sprintf("%s/%s/issues?scope=all&utf8=✓&state=all&label_name[]=comply-procedure", g.domain, g.reponame)
+	links.ProcedureOpen = fmt.Sprintf("%s/%s/issues?scope=all&utf8=✓&state=opened&label_name[]=comply-procedure", g.domain, g.reponame)
+	return links
+}
+
+func (g *gitlabPlugin) Configure(cfg map[string]interface{}) error {
+	var err error
+
+	if g.domain, err = getCfg(cfg, cfgDomain); err != nil {
+		return err
+	}
+	if g.token, err = getCfg(cfg, cfgToken); err != nil {
+		return err
+	}
+	if g.reponame, err = getCfg(cfg, cfgRepo); err != nil {
+		return err
+	}
+
+	return nil
+}
+
+func getCfg(cfg map[string]interface{}, k string) (string, error) {
+	v, ok := cfg[k]
+	if !ok {
+		return "", errors.New("Missing key: " + k)
+	}
+
+	vS, ok := v.(string)
+	if !ok {
+		return "", errors.New("Malformatted key: " + k)
+	}
+	return vS, nil
+}
+
+func (g *gitlabPlugin) FindOpen() ([]*model.Ticket, error) {
+	options := &gitlab.ListProjectIssuesOptions{
+		State: gitlab.String("opened"),
+	}
+
+	issues, _, err := g.api().Issues.ListProjectIssues(g.reponame, options)
+
+	if err != nil {
+		return nil, errors.Wrap(err, "error during FindOpen")
+	}
+
+	return toTickets(issues), nil
+}
+
+func (g *gitlabPlugin) FindByTag(name, value string) ([]*model.Ticket, error) {
+	panic("not implemented")
+}
+
+func (g *gitlabPlugin) FindByTagName(name string) ([]*model.Ticket, error) {
+	options := &gitlab.ListProjectIssuesOptions{
+		State:  gitlab.String("all"),
+		Labels: []string{name},
+	}
+
+	issues, _, err := g.api().Issues.ListProjectIssues(g.reponame, options)
+
+	if err != nil {
+		return nil, errors.Wrap(err, "error during FindOpen")
+	}
+
+	return toTickets(issues), nil
+}
+
+func (g *gitlabPlugin) LinkFor(t *model.Ticket) string {
+	panic("not implemented")
+}
+
+func (g *gitlabPlugin) Create(ticket *model.Ticket, labels []string) error {
+	options := &gitlab.CreateIssueOptions{
+		Title:       gitlab.String(ticket.Name),
+		Description: gitlab.String(ticket.Body),
+		Labels:      labels,
+	}
+	_, _, err := g.api().Issues.CreateIssue(g.reponame, options)
+	return err
+}
+
+func toTickets(issues []*gitlab.Issue) []*model.Ticket {
+	var tickets []*model.Ticket
+	for _, i := range issues {
+		tickets = append(tickets, toTicket(i))
+	}
+	return tickets
+}
+
+func toTicket(i *gitlab.Issue) *model.Ticket {
+	t := &model.Ticket{Attributes: make(map[string]interface{})}
+	t.ID = strconv.Itoa(i.ID)
+	t.Name = i.Title
+	t.Body = i.Description
+	t.CreatedAt = i.CreatedAt
+	t.State = toState(i.State)
+
+	for _, l := range i.Labels {
+		if l == "audit" {
+			t.SetBool("comply-audit")
+		}
+		if l == "procedure" {
+			t.SetBool("comply-procedure")
+		}
+	}
+	return t
+}
+
+func toState(state string) model.TicketState {
+	switch state {
+	case "closed":
+		return model.Closed
+	}
+	return model.Open
+}
+
+func ss(s *string) string {
+	if s == nil {
+		return ""
+	}
+	return *s
+}

internal/gitlab/gitlab_test.go

@@ -0,0 +1,9 @@
+package gitlab
+
+import (
+	"testing"
+)
+
+func TestGitlab(t *testing.T) {
+	createOne()
+}

internal/jira/jira.go

@@ -0,0 +1,193 @@
+package jira
+
+import (
+	"fmt"
+	"sync"
+	"time"
+
+	"github.com/pkg/errors"
+	"github.com/strongdm/comply/internal/model"
+
+	jira "github.com/andygrunwald/go-jira"
+)
+
+const (
+	cfgUsername = "username"
+	cfgPassword = "password"
+	cfgURL      = "url"
+	cfgProject  = "project"
+	cfgTaskType = "taskType"
+)
+
+var prompts = map[string]string{
+	cfgUsername: "Jira Username",
+	cfgPassword: "Jira Password",
+	cfgURL:      "Jira URL",
+	cfgProject:  "Jira Project Code",
+	cfgTaskType: "Jira Task Type",
+}
+
+// Prompts are human-readable configuration element names
+func (j *jiraPlugin) Prompts() map[string]string {
+	return prompts
+}
+
+// Register causes the Github plugin to register itself
+func Register() {
+	model.Register(model.Jira, &jiraPlugin{})
+}
+
+type jiraPlugin struct {
+	username string
+	password string
+	url      string
+	project  string
+	taskType string
+
+	clientMu sync.Mutex
+	client   *jira.Client
+}
+
+func (j *jiraPlugin) api() *jira.Client {
+	j.clientMu.Lock()
+	defer j.clientMu.Unlock()
+
+	if j.client == nil {
+		tp := jira.BasicAuthTransport{
+			Username: j.username,
+			Password: j.password,
+		}
+
+		client, _ := jira.NewClient(tp.Client(), j.url)
+		j.client = client
+	}
+	return j.client
+}
+
+func (j *jiraPlugin) Get(ID string) (*model.Ticket, error) {
+	return nil, nil
+}
+
+func (j *jiraPlugin) Configured() bool {
+	return j.username != "" && j.password != "" && j.url != "" && j.project != "" && j.taskType != ""
+}
+
+func (j *jiraPlugin) Links() model.TicketLinks {
+	links := model.TicketLinks{}
+	links.ProcedureAll = fmt.Sprintf("%s/issues/?jql=labels+=+comply-procedure", j.url)
+	links.ProcedureOpen = fmt.Sprintf("%s/issues/?jql=labels+=+comply-procedure+AND+resolution+=+Unresolved", j.url)
+	// links.AuditAll = fmt.Sprintf("%s/issues?q=is%3Aissue+is%3Aopen+label%3Acomply+label%3Aaudit", j.url)
+	// links.AuditOpen = fmt.Sprintf("%s/issues?q=is%3Aissue+is%3Aopen+label%3Acomply+label%3Aaudit", j.url)
+	return links
+}
+
+func (j *jiraPlugin) Configure(cfg map[string]interface{}) error {
+	var err error
+
+	if j.username, err = getCfg(cfg, cfgUsername); err != nil {
+		return err
+	}
+	if j.password, err = getCfg(cfg, cfgPassword); err != nil {
+		return err
+	}
+	if j.url, err = getCfg(cfg, cfgURL); err != nil {
+		return err
+	}
+	if j.project, err = getCfg(cfg, cfgProject); err != nil {
+		return err
+	}
+	if j.taskType, err = getCfg(cfg, cfgTaskType); err != nil {
+		return err
+	}
+
+	return nil
+}
+
+func getCfg(cfg map[string]interface{}, k string) (string, error) {
+	v, ok := cfg[k]
+	if !ok {
+		return "", errors.New("Missing key: " + k)
+	}
+
+	vS, ok := v.(string)
+	if !ok {
+		return "", errors.New("Malformatted key: " + k)
+	}
+	return vS, nil
+}
+
+func (j *jiraPlugin) FindOpen() ([]*model.Ticket, error) {
+	panic("not implemented")
+}
+
+func (j *jiraPlugin) FindByTag(name, value string) ([]*model.Ticket, error) {
+	panic("not implemented")
+}
+
+func (j *jiraPlugin) FindByTagName(name string) ([]*model.Ticket, error) {
+	issues, _, err := j.api().Issue.Search("labels=comply", &jira.SearchOptions{MaxResults: 1000})
+	if err != nil {
+		return nil, errors.Wrap(err, "unable to fetch Jira issues")
+	}
+	return toTickets(issues), nil
+}
+
+func (j *jiraPlugin) LinkFor(t *model.Ticket) string {
+	panic("not implemented")
+}
+
+func (j *jiraPlugin) Create(ticket *model.Ticket, labels []string) error {
+	i := jira.Issue{
+		Fields: &jira.IssueFields{
+			Type: jira.IssueType{
+				Name: j.taskType,
+			},
+			Project: jira.Project{
+				Key: j.project,
+			},
+			Summary:     ticket.Name,
+			Description: ticket.Body,
+			Labels:      labels,
+		},
+	}
+
+	_, _, err := j.api().Issue.Create(&i)
+	if err != nil {
+		return errors.Wrap(err, "unable to create ticket")
+	}
+	return nil
+}
+
+func toTickets(issues []jira.Issue) []*model.Ticket {
+	var tickets []*model.Ticket
+	for _, i := range issues {
+		tickets = append(tickets, toTicket(&i))
+	}
+	return tickets
+}
+
+func toTicket(i *jira.Issue) *model.Ticket {
+	t := &model.Ticket{Attributes: make(map[string]interface{})}
+	t.ID = i.ID
+	t.Name = i.Fields.Summary
+	t.Body = i.Fields.Description
+	createdAt := time.Time(i.Fields.Created)
+	t.CreatedAt = &createdAt
+	t.State = toState(i.Fields.Resolution)
+
+	for _, l := range i.Fields.Labels {
+		t.SetBool(l)
+	}
+	return t
+}
+
+func toState(status *jira.Resolution) model.TicketState {
+	if status == nil {
+		return model.Open
+	}
+	switch status.Name {
+	case "Done":
+		return model.Closed
+	}
+	return model.Open
+}

internal/jira/jira_test.go

@@ -0,0 +1,9 @@
+package jira
+
+import (
+	"testing"
+)
+
+func TestJira(t *testing.T) {
+	createOne()
+}

internal/model/document.go

@@ -2,7 +2,7 @@ package model
 
 import "time"
 
-type Policy struct {
+type Document struct {
 	Name    string `yaml:"name"`
 	Acronym string `yaml:"acronym"`
 

internal/model/fs.go

@@ -91,8 +91,8 @@ func ReadStandards() ([]*Standard, error) {
 }
 
 // ReadNarratives loads narrative descriptions from the filesystem.
-func ReadNarratives() ([]*Narrative, error) {
-	var narratives []*Narrative
+func ReadNarratives() ([]*Document, error) {
+	var narratives []*Document
 
 	files, err := path.Narratives()
 	if err != nil {
@@ -100,7 +100,7 @@ func ReadNarratives() ([]*Narrative, error) {
 	}
 
 	for _, f := range files {
-		n := &Narrative{}
+		n := &Document{}
 		mdmd := loadMDMD(f.FullPath)
 		err = yaml.Unmarshal([]byte(mdmd.yaml), &n)
 		if err != nil {
@@ -141,8 +141,8 @@ func ReadProcedures() ([]*Procedure, error) {
 }
 
 // ReadPolicies loads policy documents from the filesystem.
-func ReadPolicies() ([]*Policy, error) {
-	var policies []*Policy
+func ReadPolicies() ([]*Document, error) {
+	var policies []*Document
 
 	files, err := path.Policies()
 	if err != nil {
@@ -150,7 +150,7 @@ func ReadPolicies() ([]*Policy, error) {
 	}
 
 	for _, f := range files {
-		p := &Policy{}
+		p := &Document{}
 		mdmd := loadMDMD(f.FullPath)
 		err = yaml.Unmarshal([]byte(mdmd.yaml), &p)
 		if err != nil {

internal/model/model.go

@@ -2,8 +2,8 @@ package model
 
 type Data struct {
 	Standards  []*Standard
-	Narratives []*Narrative
-	Policies   []*Policy
+	Narratives []*Document
+	Policies   []*Document
 	Procedures []*Procedure
 	Tickets    []*Ticket
 	Audits     []*Audit

internal/model/narrative.go

@@ -1,15 +0,0 @@
-package model
-
-import "time"
-
-type Narrative struct {
-	Name    string `yaml:"name"`
-	Acronym string `yaml:"acronym"`
-
-	Revisions      []Revision   `yaml:"majorRevisions"`
-	Satisfies      Satisfaction `yaml:"satisfies"`
-	FullPath       string
-	OutputFilename string
-	ModifiedAt     time.Time
-	Body           string
-}

internal/model/plugin.go

@@ -17,11 +17,13 @@ type TicketSystem string
 
 const (
 	// Jira from Atlassian.
-	Jira = TicketSystem("jira")
+	Jira = TicketSystem(config.Jira)
 	// GitHub from GitHub.
-	GitHub = TicketSystem("github")
+	GitHub = TicketSystem(config.GitHub)
+	// GitLab from GitLab.
+	GitLab = TicketSystem(config.GitLab)
 	// NoTickets indicates no ticketing system integration.
-	NoTickets = TicketSystem("none")
+	NoTickets = TicketSystem(config.NoTickets)
 )
 
 type TicketLinks struct {
@@ -50,6 +52,10 @@ func GetPlugin(ts TicketSystem) TicketPlugin {
 	tsPluginsMu.Lock()
 	defer tsPluginsMu.Unlock()
 
+	if ts == NoTickets {
+		return &noopTicketSystem{}
+	}
+
 	tp, ok := tsPlugins[ts]
 	if !ok {
 		panic("Unknown ticket system: " + ts)
@@ -81,7 +87,10 @@ func GetPlugin(ts TicketSystem) TicketPlugin {
 					}
 					cfgStringed[kS] = v
 				}
-				tp.Configure(cfgStringed)
+				err := tp.Configure(cfgStringed)
+				if err != nil {
+					panic(fmt.Sprintf("Configuration error `%s` in project YAML", err))
+				}
 			}
 		})
 	}
@@ -100,3 +109,36 @@ func Register(ts TicketSystem, plugin TicketPlugin) {
 
 	tsPlugins[ts] = plugin
 }
+
+type noopTicketSystem struct{}
+
+func (*noopTicketSystem) Get(ID string) (*Ticket, error) {
+	return nil, nil
+}
+func (*noopTicketSystem) FindOpen() ([]*Ticket, error) {
+	return []*Ticket{}, nil
+}
+func (*noopTicketSystem) FindByTag(name, value string) ([]*Ticket, error) {
+	return []*Ticket{}, nil
+}
+func (*noopTicketSystem) FindByTagName(name string) ([]*Ticket, error) {
+	return []*Ticket{}, nil
+}
+func (*noopTicketSystem) Create(ticket *Ticket, labels []string) error {
+	return nil
+}
+func (*noopTicketSystem) Configure(map[string]interface{}) error {
+	return nil
+}
+func (*noopTicketSystem) Prompts() map[string]string {
+	return make(map[string]string)
+}
+func (*noopTicketSystem) Links() TicketLinks {
+	return TicketLinks{}
+}
+func (*noopTicketSystem) LinkFor(ticket *Ticket) string {
+	return ""
+}
+func (*noopTicketSystem) Configured() bool {
+	return false
+}

internal/plugin/github/github.go

@@ -69,10 +69,10 @@ func (g *githubPlugin) Configured() bool {
 
 func (g *githubPlugin) Links() model.TicketLinks {
 	links := model.TicketLinks{}
-	links.AuditAll = fmt.Sprintf("https://github.com/%s/%s/issues?q=is%3Aissue+is%3Aopen+label%3Acomply+label%3Aaudit", g.username, g.reponame)
-	links.AuditOpen = fmt.Sprintf("https://github.com/%s/%s/issues?q=is%3Aissue+is%3Aopen+label%3Acomply+label%3Aaudit", g.username, g.reponame)
-	links.ProcedureAll = fmt.Sprintf("https://github.com/%s/%s/issues?q=is%3Aissue+label%3Acomply+label%3Aprocedure", g.username, g.reponame)
-	links.ProcedureOpen = fmt.Sprintf("https://github.com/%s/%s/issues?q=is%3Aissue+is%3Aopen+label%3Acomply+label%3Aprocedure", g.username, g.reponame)
+	links.AuditAll = fmt.Sprintf("https://github.com/%s/%s/issues?q=is%%3Aissue+is%%3Aopen+label%%3Acomply+label%%3Aaudit", g.username, g.reponame)
+	links.AuditOpen = fmt.Sprintf("https://github.com/%s/%s/issues?q=is%%3Aissue+is%%3Aopen+label%%3Acomply+label%%3Aaudit", g.username, g.reponame)
+	links.ProcedureAll = fmt.Sprintf("https://github.com/%s/%s/issues?q=is%%3Aissue+label%%3Acomply+label%%3Acomply-procedure", g.username, g.reponame)
+	links.ProcedureOpen = fmt.Sprintf("https://github.com/%s/%s/issues?q=is%%3Aissue+is%%3Aopen+label%%3Acomply+label%%3Acomply-procedure", g.username, g.reponame)
 	return links
 }
 
@@ -135,7 +135,8 @@ func (g *githubPlugin) FindByTagName(name string) ([]*model.Ticket, error) {
 }
 
 func (g *githubPlugin) LinkFor(t *model.Ticket) string {
-	return fmt.Sprintf("https://github.com/strongdm/comply/issues/%s", t.ID)
+	// return fmt.Sprintf("https://github.com/strongdm/comply/issues/%s", t.ID)
+	panic("not implemented")
 }
 
 func (g *githubPlugin) Create(ticket *model.Ticket, labels []string) error {

internal/render/controller.go

@@ -5,6 +5,7 @@ import (
 	"sort"
 	"time"
 
+	"github.com/pkg/errors"
 	"github.com/strongdm/comply/internal/config"
 	"github.com/strongdm/comply/internal/model"
 )
@@ -32,8 +33,8 @@ type renderData struct {
 	Name       string
 	Project    *project
 	Stats      *stats
-	Narratives []*model.Narrative
-	Policies   []*model.Policy
+	Narratives []*model.Document
+	Policies   []*model.Document
 	Procedures []*model.Procedure
 	Standards  []*model.Standard
 	Tickets    []*model.Ticket
@@ -93,8 +94,12 @@ func load() (*model.Data, *renderData, error) {
 	rd.Name = project.OrganizationName
 	rd.Controls = controls
 
-	// TODO: unhardcode plugin
-	tp := model.GetPlugin(model.GitHub)
+	ts, err := config.Config().TicketSystem()
+	if err != nil {
+		return nil, nil, errors.Wrap(err, "error in ticket system configuration")
+	}
+
+	tp := model.GetPlugin(model.TicketSystem(ts))
 	if tp.Configured() {
 		links := tp.Links()
 		rd.Links = &links
@@ -133,7 +138,7 @@ func addStats(modelData *model.Data, renderData *renderData) {
 		}
 
 		if t.State == model.Open {
-			if t.Bool("procedure") {
+			if t.Bool("comply-procedure") {
 				stats.ProcedureOpen++
 				if t.CreatedAt != nil {
 					age := int(time.Since(*t.CreatedAt).Hours() / float64(24))

internal/render/document.go

@@ -2,7 +2,6 @@ package render
 
 import (
 	"bytes"
-	"context"
 	"fmt"
 	"io/ioutil"
 	"os"
@@ -12,89 +11,34 @@ import (
 	"text/template"
 	"time"
 
-	"github.com/docker/docker/api/types"
-	"github.com/docker/docker/api/types/container"
-	"github.com/docker/docker/client"
+	"os/exec"
+
 	"github.com/pkg/errors"
 	"github.com/strongdm/comply/internal/config"
 	"github.com/strongdm/comply/internal/model"
 )
 
 // TODO: refactor and eliminate duplication among narrative, policy renderers
-func renderPolicyToDisk(wg *sync.WaitGroup, errOutputCh chan error, data *renderData, policy *model.Policy, live bool) {
+func renderToFilesystem(wg *sync.WaitGroup, errOutputCh chan error, data *renderData, doc *model.Document, live bool) {
 	// only files that have been touched
-	if !isNewer(policy.FullPath, policy.ModifiedAt) {
+	if !isNewer(doc.FullPath, doc.ModifiedAt) {
 		return
 	}
-	recordModified(policy.FullPath, policy.ModifiedAt)
-
-	ctx := context.Background()
-	cli, err := client.NewEnvClient()
-	if err != nil {
-		errOutputCh <- errors.Wrap(err, "unable to read Docker environment")
-		return
-	}
-
-	pwd, err := os.Getwd()
-	if err != nil {
-		errOutputCh <- errors.Wrap(err, "unable to get workding directory")
-		return
-	}
-
-	hc := &container.HostConfig{
-		Binds: []string{pwd + ":/source"},
-	}
+	recordModified(doc.FullPath, doc.ModifiedAt)
 
 	wg.Add(1)
-	go func(p *model.Policy) {
+	go func(p *model.Document) {
 		defer wg.Done()
 
 		outputFilename := p.OutputFilename
 		// save preprocessed markdown
-		err = preprocessPolicy(data, p, filepath.Join(".", "output", outputFilename+".md"))
+		err := preprocessDoc(data, p, filepath.Join(".", "output", outputFilename+".md"))
 		if err != nil {
 			errOutputCh <- errors.Wrap(err, "unable to preprocess")
 			return
 		}
 
-		resp, err := cli.ContainerCreate(ctx, &container.Config{
-			Image: "strongdm/pandoc",
-			Cmd: []string{"--smart", "--toc", "-N", "--template=/source/templates/default.latex", "-o",
-				fmt.Sprintf("/source/output/%s", outputFilename),
-				fmt.Sprintf("/source/output/%s.md", outputFilename),
-			},
-		}, hc, nil, "")
-		if err != nil {
-			errOutputCh <- errors.Wrap(err, "unable to create Docker container")
-			return
-		}
-
-		defer func() {
-			timeout := 2 * time.Second
-			cli.ContainerStop(ctx, resp.ID, &timeout)
-			err := cli.ContainerRemove(ctx, resp.ID, types.ContainerRemoveOptions{Force: true})
-			if err != nil {
-				errOutputCh <- errors.Wrap(err, "unable to remove container")
-				return
-			}
-		}()
-
-		if err := cli.ContainerStart(ctx, resp.ID, types.ContainerStartOptions{}); err != nil {
-			errOutputCh <- errors.Wrap(err, "unable to start Docker container")
-			return
-		}
-
-		_, err = cli.ContainerWait(ctx, resp.ID)
-		if err != nil {
-			errOutputCh <- errors.Wrap(err, "error awaiting Docker container")
-			return
-		}
-
-		_, err = cli.ContainerLogs(ctx, resp.ID, types.ContainerLogsOptions{ShowStdout: true})
-		if err != nil {
-			errOutputCh <- errors.Wrap(err, "error reading Docker container logs")
-			return
-		}
+		pandoc(outputFilename, errOutputCh)
 
 		// remove preprocessed markdown
 		err = os.Remove(filepath.Join(".", "output", outputFilename+".md"))
@@ -108,10 +52,44 @@ func renderPolicyToDisk(wg *sync.WaitGroup, errOutputCh chan error, data *render
 			rel = p.FullPath
 		}
 		fmt.Printf("%s -> %s\n", rel, filepath.Join("output", p.OutputFilename))
-	}(policy)
+	}(doc)
 }
 
-func preprocessPolicy(data *renderData, pol *model.Policy, fullPath string) error {
+func getGitApprovalInfo(pol *model.Document) (string, error) {
+	cfg := config.Config()
+
+	// if no approved branch specified in config.yaml, then nothing gets added to the document
+	if cfg.ApprovedBranch == "" {
+		return "", nil
+	}
+
+	// Decide whether we are on the git branch that contains the approved policies
+	gitBranchArgs := []string{"rev-parse", "--abbrev-ref", "HEAD"}
+	gitBranchCmd := exec.Command("git", gitBranchArgs...)
+	gitBranchInfo, err := gitBranchCmd.CombinedOutput()
+	if err != nil {
+		fmt.Println(string(gitBranchInfo))
+		return "", errors.Wrap(err, "error looking up git branch")
+	}
+
+	// if on a different branch than the approved branch, then nothing gets added to the document
+	if strings.Compare(strings.TrimSpace(fmt.Sprintf("%s", gitBranchInfo)), cfg.ApprovedBranch) != 0 {
+		return "", nil
+	}
+
+	// Grab information related to commit, so that we can put approval information in the document
+	gitArgs := []string{"log", "-n", "1", "--pretty=format:Last edit made by %an (%aE) on %aD.\n\nApproved by %cn (%cE) on %cD in commit %H.", "--", pol.FullPath}
+	cmd := exec.Command("git", gitArgs...)
+	gitApprovalInfo, err := cmd.CombinedOutput()
+	if err != nil {
+		fmt.Println(string(gitApprovalInfo))
+		return "", errors.Wrap(err, "error looking up git committer and author data")
+	}
+
+	return fmt.Sprintf("%s\n%s", "# Authorship and Approval", gitApprovalInfo), nil
+}
+
+func preprocessDoc(data *renderData, pol *model.Document, fullPath string) error {
 	cfg := config.Config()
 
 	var w bytes.Buffer
@@ -147,6 +125,11 @@ func preprocessPolicy(data *renderData, pol *model.Policy, fullPath string) erro
 		revisionTable = fmt.Sprintf("|Date|Comment|\n|---+--------------------------------------------|\n%s\nTable: Document history\n", rows)
 	}
 
+	gitApprovalInfo, err := getGitApprovalInfo(pol)
+	if err != nil {
+		return err
+	}
+
 	doc := fmt.Sprintf(`%% %s
 %% %s
 %% %s
@@ -162,6 +145,8 @@ foot-content: "%s confidential %d"
 %s
 
 \newpage
+%s
+
 %s`,
 		pol.Name,
 		cfg.Name,
@@ -172,6 +157,7 @@ foot-content: "%s confidential %d"
 		satisfiesTable,
 		revisionTable,
 		body,
+		gitApprovalInfo,
 	)
 	err = ioutil.WriteFile(fullPath, []byte(doc), os.FileMode(0644))
 	if err != nil {

internal/render/html.go

@@ -82,7 +82,7 @@ func html(output string, live bool, errCh chan error, wg *sync.WaitGroup) {
 		if live {
 			if !opened {
 				opened = true
-				open.Run("output/index.html")
+				open.Run(filepath.Join(".", "output", "index.html"))
 			}
 		} else {
 			wg.Done()

internal/render/narrative.go

@@ -1,184 +0,0 @@
-package render
-
-import (
-	"bytes"
-	"context"
-	"fmt"
-	"io/ioutil"
-	"os"
-	"path/filepath"
-	"strings"
-	"sync"
-	"text/template"
-	"time"
-
-	"github.com/docker/docker/api/types"
-	"github.com/docker/docker/api/types/container"
-	"github.com/docker/docker/client"
-	"github.com/pkg/errors"
-	"github.com/strongdm/comply/internal/config"
-	"github.com/strongdm/comply/internal/model"
-)
-
-// TODO: refactor and eliminate duplication among narrative, policy renderers
-func renderNarrativeToDisk(wg *sync.WaitGroup, errOutputCh chan error, data *renderData, narrative *model.Narrative, live bool) {
-	// only files that have been touched
-	if !isNewer(narrative.FullPath, narrative.ModifiedAt) {
-		return
-	}
-	recordModified(narrative.FullPath, narrative.ModifiedAt)
-
-	ctx := context.Background()
-	cli, err := client.NewEnvClient()
-	if err != nil {
-		errOutputCh <- errors.Wrap(err, "unable to read Docker environment")
-		return
-	}
-
-	pwd, err := os.Getwd()
-	if err != nil {
-		errOutputCh <- errors.Wrap(err, "unable to get workding directory")
-		return
-	}
-
-	hc := &container.HostConfig{
-		Binds: []string{pwd + ":/source"},
-	}
-
-	wg.Add(1)
-	go func(p *model.Narrative) {
-		defer wg.Done()
-
-		outputFilename := p.OutputFilename
-		// save preprocessed markdown
-		err = preprocessNarrative(data, p, filepath.Join(".", "output", outputFilename+".md"))
-		if err != nil {
-			errOutputCh <- errors.Wrap(err, "unable to preprocess")
-			return
-		}
-
-		cmd := []string{"--smart", "--toc", "-N", "--template=/source/templates/default.latex", "-o",
-			fmt.Sprintf("/source/output/%s", outputFilename),
-			fmt.Sprintf("/source/output/%s.md", outputFilename)}
-
-		resp, err := cli.ContainerCreate(ctx, &container.Config{
-			Image: "strongdm/pandoc",
-			Cmd:   cmd},
-			hc, nil, "")
-
-		if err != nil {
-			errOutputCh <- errors.Wrap(err, "unable to create Docker container")
-			return
-		}
-
-		defer func() {
-			timeout := 2 * time.Second
-			cli.ContainerStop(ctx, resp.ID, &timeout)
-			err := cli.ContainerRemove(ctx, resp.ID, types.ContainerRemoveOptions{Force: true})
-			if err != nil {
-				errOutputCh <- errors.Wrap(err, "unable to remove container")
-				return
-			}
-		}()
-
-		if err := cli.ContainerStart(ctx, resp.ID, types.ContainerStartOptions{}); err != nil {
-			errOutputCh <- errors.Wrap(err, "unable to start Docker container")
-			return
-		}
-
-		_, err = cli.ContainerWait(ctx, resp.ID)
-		if err != nil {
-			errOutputCh <- errors.Wrap(err, "error awaiting Docker container")
-			return
-		}
-
-		_, err = cli.ContainerLogs(ctx, resp.ID, types.ContainerLogsOptions{ShowStdout: true})
-		if err != nil {
-			errOutputCh <- errors.Wrap(err, "error reading Docker container logs")
-			return
-		}
-
-		// remove preprocessed markdown
-		err = os.Remove(filepath.Join(".", "output", outputFilename+".md"))
-		if err != nil {
-			errOutputCh <- err
-			return
-		}
-
-		rel, err := filepath.Rel(config.ProjectRoot(), p.FullPath)
-		if err != nil {
-			rel = p.FullPath
-		}
-		fmt.Printf("%s -> %s\n", rel, filepath.Join("output", p.OutputFilename))
-
-	}(narrative)
-}
-
-func preprocessNarrative(data *renderData, pol *model.Narrative, fullPath string) error {
-	cfg := config.Config()
-
-	var w bytes.Buffer
-	bodyTemplate, err := template.New("body").Parse(pol.Body)
-	if err != nil {
-		w.WriteString(fmt.Sprintf("# Error processing template:\n\n%s\n", err.Error()))
-	} else {
-		bodyTemplate.Execute(&w, data)
-	}
-	body := w.String()
-
-	revisionTable := ""
-	satisfiesTable := ""
-
-	// ||Date|Comment|
-	// |---+------|
-	// | 4 Jan 2018 | Initial Version |
-	// Table: Document history
-
-	if len(pol.Satisfies) > 0 {
-		rows := ""
-		for standard, keys := range pol.Satisfies {
-			rows += fmt.Sprintf("| %s | %s |\n", standard, strings.Join(keys, ", "))
-		}
-		satisfiesTable = fmt.Sprintf("|Standard|Controls Satisfied|\n|-------+--------------------------------------------|\n%s\nTable: Control satisfaction\n", rows)
-	}
-
-	if len(pol.Revisions) > 0 {
-		rows := ""
-		for _, rev := range pol.Revisions {
-			rows += fmt.Sprintf("| %s | %s |\n", rev.Date, rev.Comment)
-		}
-		revisionTable = fmt.Sprintf("|Date|Comment|\n|---+--------------------------------------------|\n%s\nTable: Document history\n", rows)
-	}
-
-	doc := fmt.Sprintf(`%% %s
-%% %s
-%% %s
-
----
-header-includes: yes
-head-content: "%s"
-foot-content: "%s confidential %d"
----
-
-%s
-
-%s
-
-\newpage
-%s`,
-		pol.Name,
-		cfg.Name,
-		fmt.Sprintf("%s %d", pol.ModifiedAt.Month().String(), pol.ModifiedAt.Year()),
-		pol.Name,
-		cfg.Name,
-		time.Now().Year(),
-		satisfiesTable,
-		revisionTable,
-		body,
-	)
-	err = ioutil.WriteFile(fullPath, []byte(doc), os.FileMode(0644))
-	if err != nil {
-		return errors.Wrap(err, "unable to write preprocessed narrative to disk")
-	}
-	return nil
-}

internal/render/pandoc.go

@@ -0,0 +1,101 @@
+package render
+
+import (
+	"context"
+	"fmt"
+	"os"
+	"os/exec"
+	"time"
+
+	"github.com/docker/docker/api/types"
+	"github.com/docker/docker/api/types/container"
+	"github.com/docker/docker/client"
+	"github.com/pkg/errors"
+	"github.com/strongdm/comply/internal/config"
+)
+
+var pandocArgs = []string{"-f", "markdown+smart", "--toc", "-N", "--template", "templates/default.latex", "-o"}
+
+func pandoc(outputFilename string, errOutputCh chan error) {
+	if config.WhichPandoc() == config.UsePandoc {
+		err := pandocPandoc(outputFilename)
+		if err != nil {
+			errOutputCh <- err
+		}
+	} else {
+		dockerPandoc(outputFilename, errOutputCh)
+	}
+}
+
+func dockerPandoc(outputFilename string, errOutputCh chan error) {
+	pandocCmd := append(pandocArgs, fmt.Sprintf("/source/output/%s", outputFilename), fmt.Sprintf("/source/output/%s.md", outputFilename))
+	ctx := context.Background()
+	cli, err := client.NewEnvClient()
+	if err != nil {
+		errOutputCh <- errors.Wrap(err, "unable to read Docker environment")
+		return
+	}
+
+	pwd, err := os.Getwd()
+	if err != nil {
+		errOutputCh <- errors.Wrap(err, "unable to get workding directory")
+		return
+	}
+
+	hc := &container.HostConfig{
+		Binds: []string{pwd + ":/source"},
+	}
+
+	resp, err := cli.ContainerCreate(ctx, &container.Config{
+		Image: "strongdm/pandoc",
+		Cmd:   pandocCmd},
+		hc, nil, "")
+
+	if err != nil {
+		errOutputCh <- errors.Wrap(err, "unable to create Docker container")
+		return
+	}
+
+	defer func() {
+		timeout := 2 * time.Second
+		cli.ContainerStop(ctx, resp.ID, &timeout)
+		err := cli.ContainerRemove(ctx, resp.ID, types.ContainerRemoveOptions{Force: true})
+		if err != nil {
+			errOutputCh <- errors.Wrap(err, "unable to remove container")
+			return
+		}
+	}()
+
+	if err := cli.ContainerStart(ctx, resp.ID, types.ContainerStartOptions{}); err != nil {
+		errOutputCh <- errors.Wrap(err, "unable to start Docker container")
+		return
+	}
+
+	_, err = cli.ContainerWait(ctx, resp.ID)
+	if err != nil {
+		errOutputCh <- errors.Wrap(err, "error awaiting Docker container")
+		return
+	}
+
+	_, err = cli.ContainerLogs(ctx, resp.ID, types.ContainerLogsOptions{ShowStdout: true})
+	if err != nil {
+		errOutputCh <- errors.Wrap(err, "error reading Docker container logs")
+		return
+	}
+
+	if _, err = os.Stat(fmt.Sprintf("output/%s", outputFilename)); err != nil && os.IsNotExist(err) {
+		errOutputCh <- errors.Wrap(err, "output not generated; verify your Docker image is up to date")
+		return
+	}
+}
+
+// 🐼
+func pandocPandoc(outputFilename string) error {
+	cmd := exec.Command("pandoc", append(pandocArgs, fmt.Sprintf("output/%s", outputFilename), fmt.Sprintf("output/%s.md", outputFilename))...)
+	outputRaw, err := cmd.CombinedOutput()
+	if err != nil {
+		fmt.Println(string(outputRaw))
+		return errors.Wrap(err, "error calling pandoc")
+	}
+	return nil
+}

internal/render/pdf.go

@@ -25,7 +25,7 @@ func pdf(output string, live bool, errCh chan error, wg *sync.WaitGroup) {
 			return
 		}
 		for _, policy := range policies {
-			renderPolicyToDisk(&pdfWG, errOutputCh, data, policy, live)
+			renderToFilesystem(&pdfWG, errOutputCh, data, policy, live)
 		}
 
 		narratives, err := model.ReadNarratives()
@@ -35,7 +35,7 @@ func pdf(output string, live bool, errCh chan error, wg *sync.WaitGroup) {
 		}
 
 		for _, narrative := range narratives {
-			renderNarrativeToDisk(&pdfWG, errOutputCh, data, narrative, live)
+			renderToFilesystem(&pdfWG, errOutputCh, data, narrative, live)
 		}
 
 		pdfWG.Wait()

internal/ticket/scheduler.go

@@ -5,7 +5,9 @@ import (
 	"sort"
 	"time"
 
+	"github.com/pkg/errors"
 	"github.com/robfig/cron"
+	"github.com/strongdm/comply/internal/config"
 	"github.com/strongdm/comply/internal/model"
 )
 
@@ -68,7 +70,10 @@ func TriggerScheduled() error {
 				// in the future, nothing to do
 				continue
 			}
-			trigger(procedure)
+			err = trigger(procedure)
+			if err != nil {
+				return err
+			}
 		} else {
 			// don't go back further than 13 months
 			tooOld := time.Now().Add(-1 * time.Hour * 24 * (365 + 30))
@@ -88,7 +93,10 @@ func TriggerScheduled() error {
 				}
 
 				// is in the past? then trigger.
-				trigger(procedure)
+				err = trigger(procedure)
+				if err != nil {
+					return err
+				}
 				break SEARCH
 			}
 		}
@@ -97,13 +105,18 @@ func TriggerScheduled() error {
 	return nil
 }
 
-func trigger(procedure *model.Procedure) {
+func trigger(procedure *model.Procedure) error {
 	fmt.Printf("triggering procedure %s (cron expression: %s)\n", procedure.Name, procedure.Cron)
 
-	// TODO: don't hardcode GH
-	tp := model.GetPlugin(model.GitHub)
-	tp.Create(&model.Ticket{
+	ts, err := config.Config().TicketSystem()
+	if err != nil {
+		return errors.Wrap(err, "error in ticket system configuration")
+	}
+
+	tp := model.GetPlugin(model.TicketSystem(ts))
+	err = tp.Create(&model.Ticket{
 		Name: procedure.Name,
 		Body: fmt.Sprintf("%s\n\n\n---\nProcedure-ID: %s", procedure.Body, procedure.ID),
 	}, []string{"comply", "comply-procedure"})
+	return err
 }

themes/comply-soc2/narratives/control.md

@@ -17,6 +17,78 @@ majorRevisions:
 
 # Control Environment Narrative
 
-Here we narrate why our control environment satisfies the control keys listed in the YML block
+The following provides a description of the control structure of {{.Name}}.
 
-# Template Coming Soon
+The intent of this description is to enumerate the logical, policy, and procedural controls that serve to monitor {{.Name}}'s application and data security. Changes uncovered by these procedures in the logical, policy, procedural, or customer environment are addressed by remediations specific to the noted change.
+
+# Logical Controls
+
+{{.Name}} employs several logical controls to protect confidential data and ensure normal operation of its core product.
+
+- Mandatory data encryption at rest and in motion
+- Multi-factor authentication for access to cloud infrastructure
+- Activity and anomaly monitoring on production systems
+- Vulnerability management program
+
+# Policy Controls
+
+{{.Name}} employs several policy controls to protect confidential data and ensure normal operation of its core product. These policies include, but are not limited to:
+
+- Access Control Policy
+- Encryption Policy
+- Office Security Policy
+- Password Policy
+- Policy Training Policy
+- Vendor Policy
+- Workstation Policy
+
+# Procedural Controls
+
+{{.Name}} has numerous scheduled procedures to monitor and tune the effectiveness of ongoing security controls, and a series of event-driven procedures to respond to security-related events.
+
+TODO: Finalize these lists
+
+## Scheduled Security and Audit Procedures
+
+- Review Access [quarterly]
+- Review Security Logs [weekly]
+- Review Cyber Risk Assessment (enumerate possible compromise scenarios) [quarterly]
+- Review Data Classification [quarterly]
+- Backup Testing [quarterly]
+- Disaster Recovery Testing [semi-annual]
+- Review Devices & Workstations [quarterly]
+- Review & Clear Low-Priority Alerts [weekly]
+- Apply OS Patches [monthly]
+- Verify Data Disposal per Retention Policy [quarterly]
+- Conduct Security Training [annual]
+- Review Security Monitoring and Alerting Configuration [quarterly]
+- Penetration Test [annual]
+- Whitebox Security Review [annual]
+- SOC2 Audit [annual]
+
+## Event-Driven Security and Audit Procedures
+
+- Onboard Employee
+- Offboard Employee
+- Investigate Security Alert
+- Investigate Security Incident
+
+# Remediations
+
+{{.Name}} uses the outcomes of the aforementioned controls and procedures to identify shortcomings in the existing control environment. Once identified, these shortcomes are remediated by improving existing controls and procedures, and creating new controls and procedures as needed.
+
+# Communications
+
+{{.Name}} communicates relevant information regarding the functioning of the above controls with internal and external parties on an as-needed basis and according to statutory requirements.
+
+## Internal
+
+{{.Name}} communicates control outcomes, anomalies, and remediations internally using the following channels:
+
+- Slack
+- Email
+- Github ticketing
+
+## External
+
+{{.Name}} communicates relevant control-related information to external parties including shareholders, customers, contractors, regulators, and government entities as needed according to contractual and regulatory/statutory obligation.

themes/comply-soc2/narratives/products.md

@@ -9,4 +9,39 @@ majorRevisions:
 
 Here we describe the key products marketed by our organization
 
-# Template Coming Soon
+# Products
+
+## Product 1
+
+Overview of product 1
+
+### Architecture
+
+Brief architectural discussion of product 1
+
+### Security Considerations
+
+Specific security considerations for product 1. Refer to policies, procedures here.
+
+# References
+
+## Narratives
+
+List relevant narratives, probably including
+Organizational Narrative
+Security Narrative
+System Narrative
+
+## Policies
+
+List relevant policies, probably including
+Application Security Policy
+Datacenter Policy
+Log Management Policy
+Password Policy
+Security Incident Response Policy
+Risk Assessment Policy
+
+## Procedures
+
+List relevant procedures, probably including access review, patching, alert monitoring, log review, pen testing

themes/comply-soc2/narratives/security.md

@@ -15,4 +15,99 @@ majorRevisions:
 
 Here we narrate why our org satisfies the control keys listed in the YML block
 
-# Template Coming Soon
+# {{.Name}} Product Architecture
+
+Describe product architecture here, emphasizing security implications
+
+# {{.Name}} Infrastructure
+
+## Product Infrastructure
+
+Describe product infrastructure, emphasizing security measures
+
+### Authorized Personnel
+
+- **AWS root account** access is granted only to the CTO and CEO
+- **AWS IAM** access is granted to to a limited group of **Operators**
+- **{{.Name}} SSH** access is granted to a limited group of **Operators**
+- **{{.Name}} DB** access is granted to a limited group of **Data Operators**
+
+## IT Infrastructure
+
+{{.Name}} uses the following cloud services for its internal infrastructure:
+
+- List cloud services
+
+Access to these cloud services is limited according to the role of the {{.Name}} employee and is reviewed quarterly as well as via regular onboarding/offboarding tasks for new and departing employees.
+
+# {{.Name}} Workstations
+
+{{.Name}} workstations are hardened against logical and physical attack by the following measures:
+
+- operating system must be within one generation of current
+- full-disk encryption
+- onboard antivirus/antimalware software
+- OS and AV automatically updated
+
+Workstation compliance with these measures is evaluated on a quarterly basis.
+
+## Remote Access
+
+Many {{.Name}} employees work remotely on a regular basis and connect to production and internal IT systems via the same methods as those employees connecting from the {{.Name}} physical office, i.e., direct encrypted access to cloud services. It is the employee's responsibility to ensure that only authorized personnel use {{.Name}} resources and access {{.Name}} systems.
+
+# Access Review
+
+Access to {{.Name}} infrastructure, both internal and product, is reviewed quarterly and inactive users are removed. Any anomalies are reported to the security team for further investigation. When employees start or depart, an onboarding/offboarding procedure is followed to provision or deprovision appropriate account access.
+
+# Penetration Testing
+
+{{.Name}} commissions an external penetration test on an annual basis. All findings are immediately reviewed and addressed to the satisfaction of the CTO/CEO.
+
+# {{.Name}} Physical Security
+
+{{.Name}} has one physical location, in San Francisco, CA. Key issuance is tracked by the Office Physical Security Policy Ledger. Office keys are additionally held by the lessor, property management, and custodial staff. These keys are not tracked by the Office Physical Security Policy Ledger. {{.Name}} managers regularly review physical access privileges.
+
+{{.Name}} infrastructure is located within AWS. {{.Name}} does not have physical access to AWS infrastructure.
+
+# Risk Assessment
+
+{{.Name}} updates its Cyber Risk Assessment on an annual basis in order to keep pace with the evolving threat landscape. The following is an inventory of adversarial and non-adversarial threats assessed to be of importance to {{.Name}}.
+
+## Adversarial Threats
+
+The following represents the inventory of adversarial threats:
+
+|Threat|Source|Vector|Target|Likelihood|Severity|
+|----------------------------+--------------+------------+-----------------+----------+------|
+| | | | | | |
+
+## Non-Adversarial Threats
+
+The following represents the inventory of non-adversarial threats:
+
+|Threat|Vector|Target|Likelihood|Severity|
+|----------------------------+--------------+-------------+----------+------|
+| | | | | |
+
+# References
+
+## Narratives
+
+Products and Services Narrative
+System Architecture Narrative
+
+## Policies
+
+Encryption Policy
+Log Management Policy
+Office Security Policy
+Remote Access Policy
+Security Incident Response Policy
+Workstation Policy
+
+## Procedures
+
+Apply OS Patches
+Review & Clear Low-Priority Alerts
+Review Access
+Review Devices & Workstations

themes/comply-soc2/policies/access.md

@@ -9,5 +9,49 @@ majorRevisions:
   - date: Jun 1 2018
     comment: Initial document
 ---
+# Purpose and Scope
+
+a. The purpose of this policy is to define procedures to onboard and offboard users to technical infrastructure in a manner that minimizes the risk of information loss or exposure. 
+
+a. This policy applies to all technical infrastructure within the organization. 
+
+a. This policy applies to all full-time and part-time employees and contractors. 
+
+# Background
+
+a. In order to minimize the risk of information loss or exposure (from both inside and outside the organization), the organization is reliant on the principle of least privilege. Account creation and permission levels are restricted to only the resources absolutely needed to perform each person’s job duties. When a user’s role within the organization changes, those accounts and permission levels are changed/revoked to fit the new role and disabled when the user leaves the organization altogether. 
+
+# Policy
+
+a. *During onboarding:*
+
+    i. Hiring Manager informs HR upon hire of a new employee.
+
+    i. HR emails IT to inform them of a new hire and their role. 
+
+    i. IT creates a checklist of accounts and permission levels needed for that role. 
+
+    i. The owner of each resource reviews and approves account creation and the 
+associated permissions. 
+
+    i. IT works with the owner of each resource to set up the user. 
+
+a. *During offboarding:*
+
+    i. Hiring Manager notifies HR when an employee has been terminated. 
+
+    i. HR sends a weekly email report to IT summarizing list of users terminated and instructs IT to disable their access. 
+
+    i. IT terminates access within five business days from receipt of notification. 
+
+a. *When an employee changes roles within the organization:*
+
+    i. Hiring Manager will inform HR of a change in role.
+    
+    i. HR and IT will follow the same steps as outlined in the onboarding and offboarding procedures. 
+
+a. *Review of accounts and permissions:*
+
+    i. Each month, IT and HR will review accounts and permission levels for accuracy. 
+
 
-# Coming Soon

themes/comply-soc2/policies/application.md

@@ -8,4 +8,111 @@ majorRevisions:
     comment: Initial document
 ---
 
-# Coming Soon
+# Purpose and Scope
+
+a. This application security policy defines the security framework and requirements for applications, notably web applications, within the organization’s production environment.
+
+a. This document also provides implementing controls and instructions for web application security, to include periodic vulnerability scans and other types of evaluations and assessments.
+
+a. This policy applies to all applications within the organization’ production environment, as well as administrators and users of these applications. This typically includes employees and contractors.
+
+# Background
+
+a. Application vulnerabilities typically account for the largest number of initial attack vectors after malware infections. As a result, it is important that applications are designed with security in mind, and that they are scanned and continuously monitored for malicious activity that could indicate a system compromise. Discovery and subsequent mitigation of application vulnerabilities will limit the organization’s attack surface, and ensures a baseline level of security across all systems.
+
+a. In addition to scanning guidance, this policy also defines technical requirements and procedures  to ensure that applications are properly hardened in accordance with security best practices.
+
+# References
+
+a. Data Classification Policy
+
+a. OWASP Risk Rating Methodology
+
+a. OWASP Testing Guide
+
+a. OWASP Top Ten Project
+
+# Policy
+
+a. The organization must ensure that all applications it develops and/or acquires are securely configured and managed.
+
+a. The following security best practices must be considered and, if feasible, applied as a matter of the application’s security design:
+
+    i. Data handled and managed by the application must be classified in accordance with the Data Classification Policy (reference (a)).
+
+    i. If the application processes confidential information, a confidential record banner must be prominently displayed which highlights the type of confidential data being accessed (e.g., personally-identifiable information (PII), protected health information (PHI), etc.)
+
+    i. Sensitive data, especially data specifically restricted by law or policy (e.g., social security numbers, passwords, and credit card data) should not be displayed in plaintext.
+
+    i. Ensure that applications validate input properly and restrictively, allowing only those types of input that are known to be correct. Examples include, but are not limited to cross-site scripting, buffer overflow errors, and injection flaws.
+
+    i. Ensure that applications execute proper error handling so that errors will not provide detailed system information to an unprivileged user, deny service, impair security mechanisms, or crash the system.
+
+    i. Where possible, authorize access to applications by affiliation, membership or employment, rather than by individual. Provide an automated review of authorizations on a regular basis, where possible.
+
+    i. Ensure that applications encrypt data at rest and in transit.
+
+    i. Implement application logging to the extent practical. Retain logs of all users and access events for at least 14 days.
+
+    i. Qualified peers conduct security reviews of code  for all new or significantly modified applications; particularly, those that affect the collection, use, and/or display of confidential data. Document all actions taken.
+
+    i. Implement a change management process for changes to existing software applications.
+
+    i. Standard configuration of the application must be documented. 
+
+    i. Default passwords used within the application, such as for administrative control panels or integration with databases must be changed immediately upon installation.
+
+    i. Applications must require complex passwords in accordance with current security best practices (at least 8 characters in length, combination of alphanumeric upper/lowercase characters and symbols).
+
+    i. During development and testing, applications must not have access to live data.
+
+a. Where applications are acquired from a third party, such as a vendor:
+
+    i. Only applications that are supported by an approved vendor shall be procured and used.
+
+    i. Full support contracts must be arranged with the application vendor for full life-cycle support.
+
+    i. No custom modifications may be applied to the application without confirmation that the vendor can continue to provide support.
+
+    i. Updates, patches and configuration changes issued by the vendor shall be implemented as soon as possible.
+
+    i. A full review of applications and licenses shall be completed at least annually, as part of regular software reviews.
+
+a. Web applications must be assessed according to the following criteria:
+
+    i. New or major application releases must have a full assessment prior to approval of the change control documentation and/or release into the production environment.
+
+    i. Third-party or acquired applications must have a full assessment prior to deployment.
+
+    i. Software releases must have an appropriate assessment, as determined by the organization’s information security manager, with specific evaluation criteria based on the security risks inherent in the changes made to the application’s functionality and/or architecture.
+
+    i. Emergency releases may forego security assessments and carry the assumed risk until a proper assessment can be conducted. Emergency releases must be approved by the Chief Information Officer or designee.
+
+a. Vulnerabilities that are discovered during application assessments must be mitigated based upon the following risk levels, which are based on the Open Web Application Security Project (OWASP) Risk Rating Methodology (reference (b)):
+
+    i. High - issues categorized as high risk must be fixed immediately, otherwise alternate mitigation strategies must be implemented to limit exposure before deployment. Applications with high risk issues are subject to being taken off-line or denied release into the production environment.
+
+    i. Medium - issues categorized as medium risk must be reviewed to determine specific items to be mitigated. Actions to implement mitigations must be scheduled. Applications with medium risk issues may be taken off-line or denied release into the production environment based on the number of issues; multiple issues may increase the risk to an unacceptable level. Issues may be fixed in patch releases unless better mitigation options are present.
+
+    i. Low - issues categorized as low risk must be reviewed to determine specific items to be mitigated. Actions to implement mitigations must be scheduled.
+
+a. Testing is required to validate fixes and/or mitigation strategies for any security vulnerabilities classified as Medium risk or greater.
+
+a. The following security assessment types may be leveraged to perform an application security assessment:
+
+    i. Full - comprised of tests for all known web application vulnerabilities using both automated and manual tools based on the OWASP Testing Guide (reference (c)). A full assessment must leverage manual penetration testing techniques to validate discovered vulnerabilities to determine the overall risk of any and all discovered issues.
+
+    i. Quick - consists of an automated scan of an application for, at a minimum, the OWASP Top Ten web application security risks (reference (d)).
+
+    i. Targeted - verifies vulnerability remediation changes or new application functionality.
+
+    i. To counter the risk of unauthorized access, the organization maintains a Data Center Security Policy (reference (c)).
+
+    i. Security requirements for the software development life cycle, including system development, acquisition and maintenance are defined in the Software Development Lifecycle Policy (reference (d)).
+
+    i. Security requirements for handling information security incidents are defined in the Security Incident Response Policy (reference (e)).
+
+    i. Disaster recovery and business continuity management policy is defined in the Disaster Recovery Policy (reference (f)).
+
+    i. Requirements for information system availability and redundancy are defined in the System Availability Policy (reference (g)).
+

themes/comply-soc2/policies/availability.md

@@ -9,4 +9,92 @@ majorRevisions:
     comment: Initial document
 ---
 
-# Coming Soon
+# Purpose and Scope
+
+a. The purpose of this policy is to define requirements for proper controls to protect the availability of the organization’s information systems.
+
+a. This policy applies to all users of information systems within the organization. This typically includes employees and contractors, as well as any external parties that come into contact with systems and information controlled by the organization (hereinafter referred to as “users”). This policy must be made readily available to all users.
+
+# Background
+
+a. The intent of this policy is to minimize the amount of unexpected or unplanned downtime (also known as outages) of information systems under the organization’s control. This policy prescribes specific measures for the organization that will increase system redundancy, introduce failover mechanisms, and implement monitoring such that outages are prevented as much as possible. Where they cannot be prevented, outages will be quickly detected and remediated.
+
+a. Within this policy, an availability is defined as a characteristic of information or information systems in which such information or systems can be accessed by authorized entities whenever needed.
+
+# References
+
+a. Risk Assessment Policy
+
+# Policy
+
+a. Information systems must be consistently available to conduct and support business operations.
+
+a. Information systems must have a defined availability classification, with appropriate controls enabled and incorporated into development and production processes based on this classification.
+
+a. System and network failures must be reported promptly to the organization’s lead for Information Technology (IT) or designated IT operations manager.
+
+a. Users must be notified of scheduled outages (e.g., system maintenance) that require periods of downtime. This notification must specify the date and time of the system maintenance, expected duration, and anticipated system or service resumption time.
+
+a. Prior to production use, each new or significantly modified application must have a completed risk assessment that includes availability risks. Risk assessments must be completed in accordance with the Risk Assessment Policy (reference (a)).
+
+a. Capacity management and load balancing techniques must be used, as deemed necessary, to help minimize the risk and impact of system failures.
+
+a. Information systems  must have an appropriate data backup plan that ensures:
+
+    i. All sensitive data can be restored within a reasonable time period.
+
+    i. Full backups of critical resources are performed on at least a weekly basis.
+
+    i. Incremental backups for critical resources are performed on at least a daily basis.
+
+    i. Backups and associated media are maintained for a minimum of thirty (30) days and retained for at least one (1) year, or in accordance with legal and regulatory requirements.
+
+    i. Backups are stored off-site with multiple points of redundancy and protected using encryption and key management.
+
+    i. Tests of backup data must be conducted once per quarter. Tests of configurations must be conducted twice per year.
+
+a. Information systems  must have an appropriate redundancy and failover plan that meets the following criteria:
+
+    i. Network infrastructure that supports critical resources must have system-level redundancy (including but not limited to a secondary power supply, backup disk-array, and secondary computing system). Critical core components (including but not limited to routers, switches, and other devices linked to Service Level Agreements (SLAs)) must have an actively maintained spare. SLAs must require parts replacement within twenty-four (24) hours.
+
+    i. Servers that support critical resources must have redundant power supplies and network interface cards. All servers must have an actively maintained spare. SLAs must require parts replacement within twenty-four (24) hours.
+
+    i. Servers classified as high availability must use disk mirroring.
+
+a. Information systems must have an appropriate business continuity plan that meets the following criteria:
+
+    i. Recovery time and data loss limits are defined in Table 3. 
+
+    i. Recovery time requirements and data loss limits must be adhered to with specific documentation in the plan.
+
+    i. Company and/or external critical resources, personnel, and necessary corrective actions must be specifically identified.
+
+    i. Specific responsibilities and tasks for responding to emergencies and resuming business operations must be included in the plan.
+
+    i. All applicable legal and regulatory requirements must be satisfied.
+
++-------------------+------------------+---------------+-------------------+------------------+
+|**Availability**   | **Availability** | **Scheduled** | **Recovery Time** | **Data Loss or** |
+|**Classification** | **Requirements** | **Outage**    | **Requirements**  | **Impact Loss**  |
++===================+==================+===============+===================+==================+
+| High              | High to          | 30 minutes    | 1 hour            | Minimal          |
+|                   | Continuous       |               |                   |                  |
++-------------------+------------------+---------------+-------------------+------------------+
+|                   |                  |               |                   |                  |
++-------------------+------------------+---------------+-------------------+------------------+
+| Medium            | Standard         | 2 hours       | 4 hours           | Some data loss   |
+|                   | Availability     |               |                   | is tolerated if  |
+|                   |                  |               |                   | it results in    |
+|                   |                  |               |                   | quicker          |
+|                   |                  |               |                   | restoration      |
++-------------------+------------------+---------------+-------------------+------------------+
+|                   |                  |               |                   |                  |
++-------------------+------------------+---------------+-------------------+------------------+
+| Low               | Limited          | 4 hours       | Next              | Some data loss   |
+|                   | Availability     |               | business day      | is tolerated if  |
+|                   |                  |               |                   | it results in    |
+|                   |                  |               |                   | quicker          |
+|                   |                  |               |                   | restoration      |
++-------------------+------------------+---------------+-------------------+------------------+
+
+Table 3: Recovery Time and Data Loss Limits 

themes/comply-soc2/policies/classification.md

@@ -7,5 +7,279 @@ majorRevisions:
   - date: Jun 1 2018
     comment: Initial document
 ---
+# Appendices 
+
+Appendix A: Handling of Classified Information
+
+Appendix B: Form - Confidentiality Statement
+
+# Purpose and Scope
+
+a. This data classification policy defines the requirements to ensure that information within the organization is protected at an appropriate level.
+
+a. This document applies to the entire scope of the organization’s information security program. It includes all types of information, regardless of its form, such as paper or electronic documents, applications and databases, and knowledge or information that is not written.
+
+a. This policy applies to all individuals and systems that have access to information kept by the organization.
+
+# Background
+
+a. This policy defines the high level objectives and implementation instructions for the organization’s data classification scheme. This includes data classification levels, as well as procedures for the classification, labeling and handling of data within the organization. Confidentiality and non-disclosure agreements maintained by the organization must reference this policy.
+
+# References
+
+a. Risk Assessment Policy
+
+a. Security Incident Management Policy
+
+# Policy
+
+a. If classified information is received from outside the organization, the person who receives the information must classify it in accordance with the rules prescribed in this policy. The person thereby will become the owner of the information.
+
+a. If classified information is received from outside the organization and handled as part of business operations activities (e.g., customer data on provided cloud services), the information classification, as well as the owner of such information, must be made in accordance with the specifications of the respective customer service agreement and other legal requirements.
+
+a. When classifying information, the level of confidentiality is determined by:
+
+    i. The value of the information, based on impacts identified during the risk assessment process. More information on risk assessments is defined in the Risk Assessment Policy (reference (a)).
+
+    i. Sensitivity and criticality of the information, based on the highest risk calculated for each information item during the risk assessment.
+
+    i. Legal, regulatory and contractual obligations. 
+
+
++-------------------+------------------+---------------------------+---------------------------+
+|**Confidentiality**| **Label**        |  **Classification**       |  **Access**               |
+|     **Level**     |                  |   **Criteria**            | **Restrictions**          |
++===================+==================+===========================+============================+
+| Public            | For Public       | Making the information    | Information is available  |   
+|                   | Release          | public will not harm      | to the public.            |
+|                   |                  | the organization in       |                           |        
+|                   |                  | any way.                  |                           |
++-------------------+------------------+---------------------------+---------------------------+
+|                   |                  |                           |                           |
++-------------------+------------------+---------------------------+---------------------------+
+| Internal Use      | Internal Use     | Unauthorized access       | Information is available  |
+|                   |                  | may cause minor damage    | to all employees and      |   
+|                   |                  | and/or inconvenience      | authorized third parties. |        
+|                   |                  | to the organization.      | 
++-------------------+------------------+---------------------------+---------------------------+
+|                   |                  |                           |                           |
++-------------------+------------------+---------------------------+---------------------------+
+| Restricted        | Restricted       | Unauthorized access to    | Information is available  |
+|                   |                  | information may cause     | to a specific group of    |
+|                   |                  | considerable damage to    | employees and authhorized |
+|                   |                  | the business and/or       | third parties.            |
+|                   |                  | the organization's        |                           |
+|                   |                  | reputation.               |                           |           
++-------------------+------------------+---------------------------+---------------------------+
+|                   |                  |                           |                           |
++-------------------+------------------+---------------------------+---------------------------+
+| Confidential      |Confidential      | Unauthorized access to    | Information is available  |           
+|                   |                  | information may cause     | only to specific indivi-  |
+|                   |                  | catastrophic damage to    | duals in the              |
+|                   |                  | business and/or the       | organization.             |
+|                   |                  | organization's reputation.|                           |
++-------------------+------------------+---------------------------+---------------------------+
+
+Table 3: Information Confidentiality Levels
+
+ 
+
+d. Information must be classified based on confidentiality levels as defined in Table 3.
+
+e. Information and information system owners should try to use the lowest confidentiality level that ensures an adequate level of protection, thereby avoiding unnecessary production costs.
+
+f. Information classified as “Restricted” or “Confidential” must be accompanied by a list of authorized persons in which the information owner specifies the names or job functions of persons who have the right to access that information.
+
+g. Information classified as “Internal Use” must be accompanied by a list of authorized persons only if individuals outside the organization will have access to the document.
+
+h. Information and information system owners must review the confidentiality level of their information assets every five years and assess whether the confidentiality level should be changed. Wherever possible, confidentiality levels should be lowered.
+
+a. For cloud-based software services provided to customers, system owners under the company’s control must also review the confidentiality level of their information systems after service agreement changes or after a customer’s formal notification. Where allowed by service agreements, confidentiality levels should be lowered.
+
+a. Information must be labeled according to the following:
+
+    i. Paper documents: the confidentiality level is indicated on the top and bottom of each document page; it is also indicated on the front of the cover or envelope carrying such a document as well as on the filing folder in which the document is stored. If a document is not labeled, its default classification is Internal Use.
+
+    i. Electronic documents: the confidentiality level is indicated on the top and bottom of each document page. If a document is not labeled, its default classification is Internal Use.
+
+    i. Information systems: the confidentiality level in applications and databases must be indicated on the system access screen, as well as on the screen when displaying such information.
+    
+    i. Electronic mail: the confidentiality level is indicated in the first line of the email body. If it is not labeled, its default classification is “Internal Use”.
+    
+    i. Electronic storage media (disks, memory cards, etc.): the confidentiality level must be indicated on the top surface of the media. If it is not labeled, its default classification is “Internal Use”.
+    
+    i. Information transmitted orally: the confidentiality level should be mentioned before discussing information during face-to-face communication, by telephone, or any other means of oral communication.
+    
+a. All persons accessing classified information must follow the guidelines listed in Appendix A, “Handling of Classified Information.”
+
+a. All persons accessing classified information must complete and submit a Confidentiality Statement to their immediate supervisor or company point-of-contact. A sample Confidentiality Statement is in Appendix B.
+
+a. Incidents related to the improper handling of classified information must be reported in accordance with the Security Incident Management Policy (reference (b)).
+    
+\pagebreak 
+
+# Appendix A: Handling of Classified Information
+
+Information and information systems must be handled according to the following guidelines*:
+
+a. Paper Documents
+    
+    i. Internal Use
+
+        1. Only authorized persons may have access.
+        
+        1. If sent outside the organization, the document must be sent as registered mail.
+
+        1. Documents may only be kept in rooms without public access.
+
+        1. Documents must be removed expeditiously from printers and fax machines.
+
+    i. Restricted
+
+        1. The document must be stored in a locked cabinet.
+
+        1. Documents may be transferred within and outside the organization only in a closed envelope.
+
+        1. If sent outside the organization, the document must be mailed with a return receipt service.
+
+        1. Documents must immediately be removed from printers and fax machines.
+
+        1. Only the document owner may copy the document.
+
+        1. Only the document owner may destroy the document.
+
+    i. Confidential
+      
+        1. The document must be stored in a safe.
+
+        1. The document may be transferred within and outside the organization only by a trustworthy person in a closed and sealed envelope.
+
+        1. Faxing the document is not permitted.
+
+        1. The document may be printed only if the authorized person is standing next to the printer.
+
+a. Electronic Documents
+
+    i. Internal Use
+
+        1. Only authorized persons may have access.
+
+        1. When documents are exchanged via unencrypted file sharing services such as FTP, they must be password protected.
+
+        1. Access to the information system where the document is stored must be protected by a strong password.
+
+        1. The screen on which the document is displayed must be automatically locked after 10 minutes of inactivity.
+
+    i. Restricted
+
+        1. Only persons with authorization for this document may access the part of the information system where this document is stored.
+
+        1. When documents are exchanged via file sharing services of any type, they must be encrypted.
+
+        1. Only the document owner may erase the document.
+
+    i. Confidential
+
+        1. The document must be stored in encrypted form.
+
+        1. The document may be stored only on servers which are controlled by the organization.
+
+        1. The document may only be shared via file sharing services that are encrypted such as HTTPS and SSH. Further, the document must be encrypted and protected with a string password when transferred.
+
+a. Information Systems
+
+    i. Internal Use
+
+        1. Only authorized persons may have access.
+
+        1. Access to the information system must be protected by a strong password.
+
+        1. The screen must be automatically locked after 10 minutes of inactivity.
+
+        1. The information system may be only located in rooms with controlled physical access.
+
+    i. Restricted
+
+        1. Users must log out of the information system if they have temporarily or permanently left the workplace.
+
+        1. Data must be erased only with an algorithm that ensures secure deletion.
+
+    i. Confidential
+
+        1. Access to the information system must be controlled through multi-factor authentication (MFA).
+
+        1. The information system may only be installed on servers controlled by the organization.
+
+        1. The information system may only be located in rooms with controlled physical access and identity control of people accessing the room.
+
+a. Electronic Mail
+
+    i. Internal Use
+
+        1. Only authorized persons may have access.
+
+        1. The sender must carefully check the recipient.
+
+        1. All rules stated under “information systems” apply.
+
+    i. Restricted
+
+        1. Email must be encrypted if sent outside the organization.
+
+    i. Confidential
+
+        1. Email must be encrypted.
+
+a. Electronic Storage Media
+
+    i. Internal Use
+
+        1. Only authorized persons may have access.
+
+        1. Media or files must be password protected.
+
+        1. If sent outside the organization, the medium must be sent as registered mail.
+
+        1. The medium may only be kept in rooms with controlled physical access.
+
+    i. Restricted
+
+        1. Media and files must be encrypted.
+
+        1. Media must be stored in a locked cabinet.
+
+        1. If sent outside the organization, the medium must be mailed with a return receipt service.
+
+        1. Only the medium owner may erase or destroy the medium.
+
+    i. Confidential
+
+        1. Media must be stored in a safe.
+
+        1. Media may be transferred within and outside the organization only by a trustworthy person and in a closed and sealed envelope.
+
+a. Information Transmitted Orally
+
+    i. Internal Use
+
+        1. Only authorized persons may have access to information.
+
+        1. Unauthorized persons must not be present in the room when the information is communicated.
+
+    i. Restricted
+
+        1. The room must be sound-proof.
+
+        1. The conversation must not be recorded.
+
+    i. Confidential
+
+        1. Conversation conducted through electronic means must be encrypted.
+
+        1. No transcript of the conversation may be kept.
+
+In this document, controls are implemented cumulatively, meaning that controls for any confidentiality level imply the implementation of controls defined for lower confidentiality levels - if stricted controls are prescribed for a higher confidentiality level, then only such controls are implemented.
+
+
+
 
-# Coming Soon

themes/comply-soc2/policies/cyber.md

@@ -8,4 +8,61 @@ majorRevisions:
     comment: Initial document
 ---
 
-# Coming Soon
+# Purpose and Scope
+
+a. The purpose of this policy is to define the procedures to assess and treat information security risks within the organization, and to define the acceptable level of risk overall.
+
+a. Risk assessment and risk treatment are applied to the entire scope of the organization’s information security program, and to all information systems which are used within the organization or which could have an impact on the organization’s information security.
+
+a. This policy applies to all management and employees that take part in the organization’s risk assessments. This policy must be made readily available to all whom it applies to.
+
+# Background
+
+a. This policy defines a step-by-step process for conducting risk assessments, as well as to treat identified risks from an information security perspective. This policy also describes how to prepare the Risk Assessment Report required as part of the risk assessment process.
+
+a. When conducting a risk assessment, the organization must identify all organizational information systems . It must then identify all threats and vulnerabilities having to do with such systems , and rate the severity of such threats and vulnerabilities according to a predefined rating scale. Asset and risk owners must be defined for each risk item.
+
+a. Once the risk assessment is completed, the organization shall determine how to manage risks where the overall assessed risk rating is deemed as too high. This management is known as risk treatment. Risk treatment options include but are not limited to applying security controls, outsourcing risk, accepting risk, or discontinuing the activity associated with the risk.
+
+a. A penetration test must be performed by a third party to verify the accuracy of the risk assessment and effectiveness of deployed risk treatments.
+
+# Procedure To Execute Risk Assessment Report
+
+a. Confirms that the entire risk assessment and risk treatment process has been carried out according to the Risk Assessment Policy.
+
+a. The purpose of the risk assessment was to identify all information systems  their vulnerabilities, and threats that could exploit vulnerabilities. These parameters were further evaluated in order to establish the criticality of individual risks.
+
+a. The purpose of the risk treatment was to define the systematic means of reducing or controlling the risks identified in the risk assessment.
+
+a. All risk assessment and treatment activities were completed within the scope of the organization’s information security program.
+
+a. The risk assessment was implemented in the period from [day/month/year] to [day/month/year]. The risk treatment was implemented from [day/month/year] to [day/month/year]. Final reports were prepared during [specify period].
+
+a. The risk assessment and risk treatment process was managed by [person responsible for managing the risk assessment process] with expert assistance provided by [person or company responsible for assistance].
+
+a. During the risk assessment, information was collected through questionnaires and interviews with responsible persons, namely the asset owners across organizational units.
+
+a. The process was conducted as follows:
+
+    i. All information systems and their owners were identified.
+
+    i. Threats were identified for each asset, and corresponding vulnerabilities were identified for each threat.
+    i. Risk owners were identified for each risk.
+
+    i. Consequences of the loss of confidentiality, integrity and availability were evaluated using a score from 0 to 2, with 0 being the lowest rating and 2 being the highest rating.
+
+    i. The likelihood of risk occurrence (i.e. that the threat will exploit the vulnerability) was evaluated using a score from 0 to 2, with 0 being the lowest rating and 2 being the highest rating.
+
+    i. The level of risk was calculated by adding up the consequence and likelihood.
+
+    i. Risks with a score of 3 or 4 were determined to be unacceptable risks.
+
+    i. For each unacceptable risk, a risk treatment option was considered, and appropriate information security controls were selected.
+
+    i. After controls were applied, residual risks were assessed.
+
+a. The following documents were used or generated during the implementation of risk assessment and risk treatment:
+    
+    i. Risk Assessment Table (Appendix A): for each combination of systems , vulnerabilities and threats, this table shows the values for consequence and likelihood, and calculates the risk.
+
+    i. Risk Treatment Table (Appendix B): defines the options for risk treatment, selection of controls for each unacceptable risk, and the level of residual risk.

themes/comply-soc2/policies/development.md

@@ -8,4 +8,188 @@ majorRevisions:
     comment: Initial document
 ---
 
-# Coming Soon
+# Purpose and Scope
+
+a. The purpose of this policy is to define requirements for establishing and maintaining baseline protection standards for company software, network devices, servers, and desktops.
+
+a. This policy applies to all users performing software development, system administration, and management of these activities within the organization. This typically includes employees and contractors, as well as any relevant external parties involved in these activities (hereinafter referred to as “users”). This policy must be made readily available to all users.
+
+a. This policy also applies to enterprise-wide systems and applications developed by the organization or on behalf of the organization for production implementation.
+
+# Background
+
+a. The intent of this policy is to ensure a well-defined, secure and consistent process for managing the entire lifecycle of software and information systems, from initial requirements analysis until system decommission. The policy defines the procedure, roles, and responsibilities, for each stage of the software development lifecycle.
+
+a. Within this policy, the software development lifecycle consists of requirements analysis, architecture and design, development, testing, deployment/implementation, operations/maintenance, and decommission. These processes may be followed in any form; in a waterfall model, it may be appropriate to follow the process linearly, while in an agile development model, the process can be repeated in an iterative fashion.
+
+# References
+
+a. Risk Assessment Policy
+
+# Policy
+
+a. The organization’s Software Development Life Cycle (SDLC) includes the following phases:
+
+    i. Requirements Analysis
+
+    i. Architecture and Design
+
+    i. Testing
+
+    i. Deployment/Implementation
+
+    i. Operations/Maintenance
+
+    i. Decommission
+
+a. During all phases of the SDLC where a system is not in production, the system must not have live data sets that contain information identifying actual people or corporate entities, actual financial data such as account numbers, security codes, routing information, or any other financially identifying data. Information that would be considered sensitive must never be used outside of production environments.
+
+a. The following activities must be completed and/or considered during the requirements analysis phase:
+
+    i. Analyze business requirements.
+
+    i. Perform a risk assessment. More information on risk assessments is discussed in the Risk Assessment Policy (reference (a)).
+
+    i. Discuss aspects of security (e.g., confidentiality, integrity, availability) and how they might apply to this requirement.
+
+    i. Review regulatory requirements and the organization’s policies, standards, procedures and guidelines.
+
+    i. Review future business goals.
+
+    i. Review current business and information technology operations.
+
+    i. Incorporate program management items, including:
+
+        1. Analysis of current system users/customers.
+
+        1. Understand customer-partner interface requirements (e.g., business-level, network).
+
+        1. Discuss project timeframe.
+
+    i. Develop and prioritize security solution requirements.
+
+    i. Assess cost and budget constraints for security solutions, including development and operations.
+
+    i. Approve security requirements and budget.
+
+    i. Make “buy vs. build” decisions for security services based on the information above.
+
+a. The following must be completed/considered during the architecture and design phase:
+
+    i. Educate development teams on how to create a secure system.
+
+    i. Develop and/or refine infrastructure security architecture.
+
+    i. List technical and non-technical security controls.
+
+    i. Perform architecture walkthrough.
+
+    i. Create a system-level security design.
+
+    i. Create high-level non-technical and integrated technical security designs.
+
+    i. Perform a cost/benefit analysis for design components.
+
+    i. Document the detailed technical security design.
+
+    i. Perform a design review, which must include, at a minimum, technical reviews of application and infrastructure, as well as a review of high-level processes.
+
+    i. Describe detailed security processes and procedures, including: segregation of duties and segregation of development, testing and production environments. 
+
+    i. Design initial end-user training and awareness programs.
+
+    i. Design a general security test plan.
+
+    i. Update the organization’s policies, standards, and procedures, if appropriate.
+
+    i. Assess and document how to mitigate residual application and infrastructure vulnerabilities.
+
+    i. Design and establish separate development and test environments.
+
+a. The following must be completed and/or considered during the development phase:
+
+    i. Set up a secure development environment (e.g., servers, storage).
+
+    i. Train infrastructure teams on installation and configuration of applicable software, if required.
+
+    i. Develop code for application-level security components.
+
+    i. Install, configure and integrate the test infrastructure.
+
+    i. Set up security-related vulnerability tracking processes.
+
+    i. Develop a detailed security test plan for current and future versions (i.e., regression testing).
+
+    i. Conduct unit testing and integration testing.
+
+a. The following must be completed and/or considered during the testing phase:
+
+    i. Perform a code and configuration review through both static and dynamic analysis of code to identify vulnerabilities. 
+
+    i. Test configuration procedures.
+
+    i. Perform system tests.
+
+    i. Conduct performance and load tests with security controls enabled.
+
+    i. Perform usability testing of application security controls.
+
+
+    i. Conduct independent vulnerability assessments of the system, including the infrastructure and application.
+
+a. The following must be completed and/or considered during the deployment phase:
+
+    i. Conduct pilot deployment of the infrastructure, application and other relevant components.
+
+    i. Conduct transition between pilot and full-scale deployment.
+
+    i. Perform integrity checking on system files to ensure authenticity.
+
+    i. Deploy training and awareness programs to train administrative personnel and users in the system’s security functions.
+
+    i. Require participation of at least two developers in order to conduct full-scale deployment to the production environment.
+
+a. The following must be completed and/or considered during the operations/maintenance phase:
+
+    i. Several security tasks and activities must be routinely performed to operate and administer the system, including but not limited to:
+
+        1. Administering users and access.
+
+        1. Tuning performance.
+
+        1. Performing backups according to requirements defined in the System Availability Policy 
+
+        1. Performing system maintenance (i.e., testing and applying security updates and patches).
+
+        1. Conducting training and awareness.
+
+        1. Conducting periodic system vulnerability assessments.
+
+        1. Conducting annual risk assessments.
+
+    i. Operational systems must:
+
+        1. Be reviewed to ensure that the security controls, both automated and manual, are functioning correctly and effectively.
+
+        1. Have logs that are periodically reviewed to evaluate the security of the system and validate audit controls.
+
+        1. Implement ongoing monitoring of systems and users to ensure detection of security violations and unauthorized changes.
+
+        1. Validate the effectiveness of the implemented security controls through security training as required by the Procedure For Executing Incident Response.
+
+        1. Have a software application and/or hardware patching process that is performed regularly in order to eliminate software bug and security problems being introduced into the organization’s technology environment. Patches and updates must be applied within ninety (90) days of release to provide for adequate testing and propagation of software updates. Emergency, critical, break-fix, and zero-day vulnerability patch releases must be applied as quickly as possible.
+
+a. The following must be completed and/or considered during the decommission phase:
+
+    i. Conduct unit testing and integration testing on the system after component removal.
+
+    i. Conduct operational transition for component removal/replacement.
+
+    i. Determine data retention requirements for application software and systems data.
+
+    i. Document the detailed technical security design.
+
+    i. Update the organization’s policies, standards and procedures, if appropriate.
+
+    i. Assess and document how to mitigate residual application and infrastructure vulnerabilities.
+

themes/comply-soc2/policies/disaster.md

@@ -8,5 +8,144 @@ majorRevisions:
   - date: Jun 1 2018
     comment: Initial document
 ---
+#Purpose and Scope 
 
-# Coming Soon
+a. The purpose of this policy is to define the organization’s procedures to recover Information Technology (IT) infrastructure and IT services within set deadlines in the case of a disaster or other disruptive incident. The objective of this plan is to complete the recovery of IT infrastructure and IT services within a set Recovery Time Objective (RTO).
+
+a. This policy includes all resources and processes necessary for service and data recovery, and covers all information security aspects of business continuity management.
+
+a. This policy applies to all management, employees and suppliers that are involved in the recovery of IT infrastructure and services within the organization. This policy must be made readily available to all whom it applies to.
+
+# Background
+
+a. This policy defines the overall disaster recovery strategy for the organization. The strategy describes the organization’s Recovery Time Objective (RTO), which is defined as the duration of time and service level for critical business processes to be restored after a disaster or other disruptive event, as well as the procedures, responsibility and technical guidance required to meet the RTO. This policy also lists the contact information for personnel and service providers that may be needed during a disaster recovery event.
+
+a. The following conditions must be met for this plan to be viable:
+
+    i. All equipment, software and data (or their backups/failovers) are available in some manner.
+
+    i. If an incident takes place at the organization’s physical location, all resources involved in recovery efforts are able to be transferred to an alternate work site (such as their home office) to complete their duties.
+
+    i. The Information Security Officer is responsible for coordinating and conducting a bi-annual (at least) rehearsal of this continuity plan. 
+
+a. This plan does not cover the following types of incidents:
+
+    i. Incidents that affect customers or partners but have no effect on the organization’s systems; in this case, the customer must employ their own continuity processes to make sure that they can continue to interact with the organization and its systems.
+
+    i. Incidents that affect cloud infrastructure suppliers at the core infrastructure level, including but not limited to Google, Heroku, and Amazon Web Services. The organization depends on such suppliers to employ their own continuity processes.
+
+# Policy
+
+a. *Relocation*
+
+    i. If the organization’s primary work site is unavailable, an alternate work site shall be used by designated personnel. The organization’s alternate work site is located at [list the address of the alternate work site that the organization will use].
+
+    i. The personnel required to report to the alternate work site during a disaster includes [list the personnel titles responsible for reporting to the alternate work site].
+
+a. *Critical Services, Key Tasks and, Service Level Agreements (SLAs)*
+
+    i. The following services and technologies are considered to be critical for business operations, and must immediately be restored (in priority order):
+  
+        1. [list the critical services and technologies that must remain running during a disaster]
+
+    i. The following key tasks and SLAs must be considered during a disaster recovery event, in accordance with the organization’s objectives, agreements, and legal, contractual or regulatory obligations:
+
+        1. [list of key tasks / SLAs that must be kept operational, with respective deadlines]
+
+a. The organization’s Recovery Time Objective (RTO) is [set the maximum amount of time before critical processes must be restored, to include relocation and getting critical services/technologies back online]. Relocation and restoration of critical services and technologies must be completed within this time period.
+
+a. *Notification of Plan Initiation*
+
+    i. The following personnel must be notified when this plan is initiated:
+
+      1. [list all personnel (including titles) that must be notified of plan initiation ]
+
+    i. [person responsible for notifications, including title] is responsible for notifying the personnel listed above.
+
+a. *Plan Deactivation*
+
+    i. This plan must only be deactivated by [person or persons with authority to deactivate the plan, including job title].
+
+    i. In order for this plan to be deactivated, all relocation activities and critical service / technology tasks  as detailed above must be fully completed and/or restored. If the organization is still operating in an impaired scenario, the plan may still be kept active at the discretion of [person or persons with authority to deactivate the plan, including job title].
+
+    i. The following personnel must be notified when this plan is deactivated:
+
+        1. [list all personnel (including titles) that must be notified of plan activation]
+
+a. The organization must endeavor to restore its normal level of business operations as soon as possible.
+
+a. A list of relevant points of contact both internal and external to the organization is enclosed in Appendix A.
+
+a. During a crisis, it is vital for certain recovery tasks to be performed right away. The following actions are pre-authorized in the event of a disaster recovery event:
+
+    i. [job title] must take all steps specified in this disaster recovery plan in order to recover the organization’s information technology infrastructure and services.
+    
+    i. [job title] is authorized to make urgent purchases of equipment and services up to [amount].
+    
+    i. [job title] is authorized to communicate with clients.
+    
+    i. [job title] is authorized to communicate with the public.
+    
+    i. [job title] is authorized to communicate with public authorities such as state and local governments and law enforcement.
+    
+    i. [job title] is authorized to cooperate with [name of supplier/outsourcing partner].
+    
+    i. [add/modify/remove authorizations in this section as necessary]
+
+a. Specific recovery steps for information systems infrastructure and services are provided in Appendix B.
+
+\pagebreak 
+
+# Appendix A: Relevant Points of Contact
+
+Internal Contacts
+
++------------------+-------------------+------------------+------------------+-----------------+
+|       Name       |     Job Title     |   Phone Number   |  Email Address   |Alternate Contact|
++==================+===================+==================+==================+=================+
+|                  |                   |                  |                  |                 |
+|                  |                   |                  |                  |                 |
++------------------+-------------------+------------------+------------------+-----------------+
+|                  |                   |                  |                  |                 |
+|                  |                   |                  |                  |                 |
++------------------+-------------------+------------------+------------------+-----------------+
+
+External Contacts
+
++------------------+-------------------+------------------+------------------+-----------------+
+|       Name       |     Job Title     |   Phone Number   |  Email Address   |Alternate Contact|
++==================+===================+==================+==================+=================+
+|                  |                   |                  |                  |                 |
+|                  |                   |                  |                  |                 |
++------------------+-------------------+------------------+------------------+-----------------+
+|                  |                   |                  |                  |                 |
+|                  |                   |                  |                  |                 |
++------------------+-------------------+------------------+------------------+-----------------+
+
+\pagebreak
+
+# Appendix B: Recovery Steps for Information Systems Infrastructure & Services
+
+Specific recovery procedures are described in detail below:
+
++----------------------------+----------------------+------------------------------------+
+|     Recovery Procedure     |  Person Responsible  |  Person(s) Notified When Complete  |
++============================+======================+====================================+
+| System to be recovered:    |                      |                                    |                
+|                            |                      |                                    |                 
++----------------------------+----------------------+------------------------------------+
+| task 1:                    |                      |                                    |  
+|                            |                      |                                    |
++----------------------------+----------------------+------------------------------------+            
+| task 2:                    |                      |                                    |   
+|                            |                      |                                    |              
++----------------------------+----------------------+------------------------------------+
+| System to be recovered:    |                      |                                    |                
+|                            |                      |                                    |                 
++----------------------------+----------------------+------------------------------------+
+| task 1:                    |                      |                                    | 
+|                            |                      |                                    |    
++----------------------------+----------------------+------------------------------------+            
+| task 2:                    |                      |                                    |    
+|                            |                      |                                    |             
++----------------------------+----------------------+------------------------------------+

themes/comply-soc2/policies/encryption.md

@@ -7,5 +7,76 @@ majorRevisions:
   - date: Jun 1 2018
     comment: Initial document
 ---
+# Purpose and Scope
+
+a. This policy defines organizational requirements for the use of cryptographic controls, as well as the requirements for cryptographic keys, in order to protect the confidentiality, integrity, authenticity and nonrepudiation of information.
+
+a. This policy applies to all systems, equipment, facilities and information within the scope of the organization’s information security program.
+
+a. All employees, contractors, part-time and temporary workers, service providers, and those employed by others to perform work on behalf of the organization having to do with cryptographic systems, algorithms, or keying material are subject to this policy and must comply with it.
+
+# Background
+
+a. This policy defines the high level objectives and implementation instructions for the organization’s use of cryptographic algorithms and keys. It is vital that the organization adopt a standard approach to cryptographic controls across all work centers in order to ensure end-to-end security, while also promoting interoperability. This document defines the specific algorithms approved for use, requirements for key management and protection, and requirements for using cryptography in cloud environments.
+
+# Policy
+
+a. The organization must protect individual systems or information by means of cryptographic controls as defined in Table 3: 
+
+\pagebreak 
+
++---------------------+-------------------+----------------+--------------+
+| **Name of System/** | **Cryptographic** | **Encryption** | **Key Size** |
+| **Type of**         | **Tool**          | **Algorithm**  |              |
+| **Information**     |                   |                |              |
++=====================+===================+================+==============+
+| Public Key          |  OpenSSL          | AES-256        | 256-bit key  |
+| Infrastructure for  |                   |                |              |
+| Authentication      |                   |                |              |
++---------------------+-------------------+----------------+--------------+
+|                     |                   |                |              |
++---------------------+-------------------+----------------+--------------+
+| Data Encryption     |  OpenSSL          | AES-256        | 256-bit key  |
+| Keys                |                   |                |              |
++---------------------+-------------------+----------------+--------------+
+|                     |                   |                |              |
++---------------------+-------------------+----------------+--------------+
+| Virtual Private     |  OpenSSL and      | AES-256        | 256-bit key  |
+| Network (VPN)       |  OpenVPN          |                |              |
+| keys                |                   |                |              |
++---------------------+-------------------+----------------+--------------+
+|                     |                   |                |              |
++---------------------+-------------------+----------------+--------------+
+| Website SSL         |  OpenSSL, CERT    | AES-256        | 256-bit key  |
+| Certificate         |                   |                |              | 
++---------------------+-------------------+----------------+--------------+
+
+Table 3: Cryptographic Controls 
+
+ 
+
+b. Except where otherwise stated, keys must be managed by their owners.
+
+c. Cryptographic keys must be protected against loss, change or destruction by applying appropriate access control mechanisms to prevent unauthorized use and backing up keys on a regular basis.
+
+d. When required, customers of the organization’s cloud-based software or platform offering must be able to obtain information regarding:
+
+    i. The cryptographic tools used to protect their information.
+
+    i. Any capabilities that are available to allow cloud service customers to apply their own cryptographic solutions.
+
+    i. The identity of the countries where the cryptographic tools are used to store or transfer cloud service customers’ data.
+
+a. The use of organizationally-approved encryption must be governed in accordance with the laws of the country, region, or other regulating entity in which users perform their work. Encryption must not be used to violate any laws or regulations including import/export restrictions. The encryption used by the Company conforms to international standards and U.S. import/export requirements, and thus can be used across international boundaries for business purposes.
+
+a. All key management must be performed using software that automatically manages access control, secure storage, backup and rotation of keys. Specifically:
+
+  i. The key management service must provide key access to specifically-designated users, with the ability to encrypt/decrypt information and generate data encryption keys.
+
+  i. The key management service must provide key administration access to specifically-designated users, with the ability to create, schedule delete, enable/disable rotation, and set usage policies for keys.
+
+  i. The key management service must store and backup keys for the entirety of their operational lifetime.
+
+  i. The key management service must rotate keys at least once every 12 months.
+
 
-# Coming Soon

themes/comply-soc2/policies/media.md

@@ -8,4 +8,133 @@ majorRevisions:
     comment: Initial document
 ---
 
-# Coming Soon
+# Purpose and Scope
+
+a. This removable media, cloud storage and Bring Your Own Device (BYOD) policy defines the objectives, requirements and implementing instructions for storing data on removable media, in cloud environments, and on personally-owned devices, regardless of data classification level.
+
+a. This policy applies to all information and data within the organization’s information security program, as well as all removable media, cloud systems and personally-owned devices either owned or controlled by the organization.
+
+a. This policy applies to all users of information systems within the organization. This typically includes employees and contractors, as well as any external parties that come into contact with systems and information controlled by the organization (hereinafter referred to as “users”). This policy must be made readily available to all users.
+
+# Background
+
+a. This policy defines the procedures for safely using  removable media, cloud storage and personally-owned devices to limit data loss or exposure.  Such forms of storage must be strictly controlled because of the sensitive data that can be stored on them. Because each of these storage types are inherently ephemeral or portable in nature, it is possible for the organization to lose the ability to oversee or control the information stored on them if strict security standards are not followed.
+
+a. This document consists of three sections pertaining to removable media, cloud storage, and personally-owned devices. Each section contains requirements and implementing instructions for the registration, management, maintenance, and disposition of each type of storage.
+
+a. Within this policy, the term sensitive information refers to information that is classified as RESTRICTED or CONFIDENTIAL in accordance with the Data Classification Policy (reference (a)).
+
+# References
+
+a. Data Classification Policy
+
+a. Asset Inventory
+
+a. Security Incident Response Policy
+
+a. Encryption Policy
+
+# Policy
+
+a. *Removable Media*
+
+    i. All removable media in active use and containing data pertinent to the organization must be registered in the organization’s Asset Inventory (reference (b)).
+
+    i. All removable media listed in reference (b) must be re-inventoried on a quarterly basis to ensure that it is still within the control of the organization.
+
+        1. To re-inventory an item, the owner of the removable media must check in the item with the organization’s Information Security Manager (ISM).
+
+        1. The ISM must treat any removable media that cannot be located as lost, and a security incident report must be logged in accordance with the Security Incident Response Policy (reference (c)).
+
+    i. The owner of the removable media must conduct all appropriate maintenance on the item at intervals appropriate to the type of media, such as cleaning, formatting, labeling, etc.
+
+    i. The owner of the removable media, where practical, must ensure that an alternate or backup copy of the information located on the device exists.
+
+    i. Removable media must be stored in a safe place that has a reduced risk of fire or flooding damage. 
+
+    i. If the storage item contains sensitive information, removable media must:
+
+        1. Be stored in a locked cabinet or drawer.
+
+        1. Store only encrypted data that is securely enciphered in accordance with the Encryption Policy (reference (d)).
+
+    i. All data on removable media devices must be erased, or the device must be destroyed, before it is reused or disposed of.
+
+    i. When removable media devices are disposed, the device owner must inform the ISM so that it can be removed from reference (b).
+
+a. *Cloud Storage*
+
+    i. All cloud storage systems in active use and containing data pertinent to the organization must be registered in reference (b). Registration may be accomplished by manual or automated means.
+
+
+    i. All cloud storage systems listed in reference (b) must be re-inventoried on a quarterly basis to ensure that it is still within the control of the organization. To re-inventory an item, the owner of the removable media must check in the item with the organization’s Information Security Manager (ISM). Re-inventory may be accomplished by manual or automated means.
+
+    i. The owner of the cloud storage system must conduct all appropriate maintenance on the system at regular intervals to include system configuration, access control, performance monitoring, etc.
+
+    i. Data on cloud storage systems must be replicated to at least one other physical location. Depending on the cloud storage provider, this replication may be automatically configured.
+
+    i. The organization must only use cloud storage providers that can demonstrate, either through security accreditation, demonstration, tour, or other means that their facilities are secured, both physically and electronically, using best practices.
+
+    i. If the cloud storage system contains sensitive information, that information must be encrypted in accordance with reference (d).
+
+    i. Data must be erased from from cloud storage systems using a technology and process that is approved by the ISM. 
+
+    i. When use of a cloud storage system is discontinued, the system owner must inform the ISM so that it can be removed from reference (b).
+
+a. *Personally-owned Devices*
+
+    i. Organizational data that is stored, transferred or processed on personally-owned devices remains under the organization’s ownership, and the organization retains the right to control such data even though it is not the owner of the device.
+
+    i. The ISM is responsible for conducting overall management of personally-owned devices, to include:
+
+        1. Installation and maintenance of Mobile Device Management (MDM) software that can effectively manage, control and wipe data under the organization’s control from personally-owned devices.
+
+        1. Maintain a list of job titles and/or persons authorized to use personally-owned devices for the organization’s business, as well as the applications and databases that may be accessed from such devices.
+
+        1. Maintain a list of applications prohibited from use on personally-owned devices, and ensuring that device users are aware of these restrictions.
+
+    i. Personally-identifiable information (PII) may not be stored, processed or accessed at any time on a personally-owned device.
+
+    i. The following acceptable use requirements must be observed by users of personally-owned devices:
+
+        1. All organizational data must be backed up at regular intervals.
+
+        1. MDM and endpoint protection software must be installed on the device at all times.
+
+        1. Sensitive information stored on the device must be encrypted in accordance with reference (d).
+
+        1. The device must be secured using a password, pin, unlock pattern, fingerprint or equivalent security mechanism.
+
+        1. The device must only connect to secure and encrypted wireless networks.
+
+        1. When using the device outside of the organization’s premises, it must not be left unattended, and if possible, physically secured.
+
+        1. When using the device in public areas, the owner must take measures to ensure that the data cannot be read or accessed by unauthorized persons.
+
+        1. Patches and updates must be installed regularly.
+
+        1. Classified information must be protected in accordance with reference (a).
+
+        1. The device owner must install the ISM before the device is disposed of, sold, or provided to a third party for servicing.
+
+        1. It is prohibited to:
+
+            a. Allow device access for anyone except its owner.
+        
+            a. Store illegal materials on the device.
+
+            a. Install unlicensed software.
+
+            a. Locally-store passwords.
+
+            a. Transfer organizational data to other devices which have not been approved by the organization.
+
+    i. The organization must reserve the right to view, edit, and/or delete any organizational information that is stored, processed or transferred on the device.
+
+    i. The organization must reserve the right to perform full deletion of all of its data on the device if it considers that necessary for the protection of company-related data, without the consent of the device owner.
+
+    i. The organization will not pay the employees (the owners of BYOD) any fee for using the device for work purposes.
+
+    i. The organization will pay for any new software that needs to be installed for company use.
+
+    i. All security breaches related to personally-owned devices must be reported immediately to the ISM. 

themes/comply-soc2/policies/remote.md

@@ -10,4 +10,50 @@ majorRevisions:
     comment: Initial document
 ---
 
-# Coming Soon
+# Purpose and Scope
+
+a. The purpose of this policy is to define requirements for connecting to the organization’s systems and networks from remote hosts, including personally-owned devices, in order to minimize data loss/exposure.
+
+a. This policy applies to all users of information systems within the organization. This typically includes employees and contractors, as well as any external parties that come into contact with systems and information controlled by the organization (hereinafter referred to as “users”). This policy must be made readily accessible to all users.
+
+# Background
+
+a. The intent of this policy is to minimize the organization’s exposure to damages which may result from the unauthorized remote use of resources, including but not limited to: the loss of sensitive, company confidential data and intellectual property; damage to the organization’s public image; damage to the organization’s internal systems; and fines and/or other financial liabilities incurred as a result of such losses.
+
+a. Within this policy, the following definitions apply:
+
+    i. *Mobile computing equipment:* includes portable computers, mobile phones, smart phones, memory cards and other mobile equipment used for storage, processing and transfer of data.
+
+    i. *Remote host:* is defined as an information system, node or network that is not under direct control of the organization.
+
+    i. *Telework:* the act of using mobile computing equipment and remote hosts to perform work outside the organization’s physical premises. Teleworking does not include the use of mobile phones.
+
+# Policy
+
+a. *Security Requirements for Remote Hosts and Mobile Computing Equipment*
+
+    i. Caution must be exercised when mobile computing equipment is placed or used in uncontrolled spaces such as vehicles, public spaces, hotel rooms, meeting places, conference centers, and other unprotected areas outside the organization’s premises.
+
+    i. When using remote hosts and mobile computing equipment, users must take care that information on the device (e.g. displayed on the screen) cannot be read by unauthorized persons if the device is being used to connect to the organization’s systems or work with the organization’s data.
+
+    i. Remote hosts must be updated and patched for the latest security updates on at least a monthly basis.
+
+    i. Remote hosts must have endpoint protection software (e.g. malware scanner) installed and updated at all times.
+
+    i. Persons using mobile computing equipment off-premises are responsible for regular backups of organizational data that resides on the the device.
+
+    i. Access to the organization’s systems must be done through an encrypted and authenticated VPN connection with multi-factor authentication enabled. All users requiring remote access must be provisioned with VPN credentials from the organization’s information technology team. VPN keys must be rotated at least twice per year. Revocation of VPN keys must be included in the Offboarding Policy. 
+
+    i. Information stored on mobile computing equipment must be encrypted using hard drive full disk encryption.
+
+a. *Security Requirements for Telework*
+
+    i. Employees must be specifically authorized for telework in writing from their hiring manager .
+
+    i. Only device’s assigned owner is permitted to use remote nodes and mobile computing equipment. Unauthorized users (such as others living or working at the location where telework is performed) are not permitted to use such devices.
+
+    i. Devices must be authorized using certificates
+
+    i. Users performing telework are responsible for the appropriate configuration of the local network used for connecting to the Internet at their telework location.
+
+    i. Users performing telework must protect the organization’s intellectual property rights, either for software or other materials that are present on remote nodes and mobile computing equipment.

themes/comply-soc2/policies/retention.md

@@ -10,4 +10,79 @@ majorRevisions:
     comment: Initial document
 ---
 
-# Coming Soon
+#Appendices
+Appendix A: Retention Periods
+
+# Purpose and Scope
+
+a. This data retention policy defines the objectives and requirements for data retention within the organization.
+
+a. This policy covers all data within the organization’s custody or control, irregardless of the medium the data is stored in (electronic form, paper form, etc.) Within this policy, the medium which holds data is referred to as information, no matter what form it is in.
+
+a. This policy applies to all users of information systems within the organization. This typically includes employees and contractors, as well as any external parties that come into contact with systems and information the organization owns or controls (hereinafter referred to as “users”). This policy must be made readily available to all users.
+
+# Background
+
+a. The organization is bound by multiple legal, regulatory and contractual obligations with regard to the data it retains. These obligations stipulate how long data can be retained, and how data must be destroyed. Examples of legal, regulatory and contractual obligations include laws and regulations in the local jurisdiction where the organization conducts business, and contracts made with employees, customers, service providers, partners and others.
+
+a. The organization may also be involved in events such as litigation or disaster recovery scenarios that require it to have access to original information in order to protect the organization’s interests or those of its employees, customers, service providers, partners and others. As a result, the organization may need to archive and store information for longer that it may be needed for day-to-day operations.
+ 
+ \pagebreak 
+
+# Policy
+
+a. *Information Retention*
+
+    i. Retention is defined as the maintenance of information in a production or live environment which can be accessed by an authorized user in the ordinary course of business. 
+
+    i. Information used in the development, staging, and testing of systems shall not be retained beyond their active use period nor copied into production or live environments.
+
+    i. By default, the retention period of information shall be an active use period of exactly two years from its creation unless an exception is obtained permitting a longer or shorter retention period. The business unit responsible for the information must request the exception.
+
+    i. After the active use period of information is over in accordance with this policy and approved exceptions, information must be archived for a defined period. Once the defined archive period is over, the information must be destroyed.
+
+    i. Each business unit is responsible for the information it creates, uses, stores, processes and destroys, according to the requirements of this policy. The responsible business unit is considered to be the information owner.
+
+    i. The organization’s legal counsel may issue a litigation hold to request that information relating to potential or actual litigation, arbitration or other claims, demands, disputes or regulatory action be retained in accordance with instructions from the legal counsel.
+
+    i. Each employee and contractor affiliated with the company must return information in their possession or control to the organization upon separation and/or retirement.
+
+    i. Information owners must enforce the retention, archiving and destruction of information, and communicate these periods to relevant parties.
+
+a. *Information Archiving*
+
+    i. Archiving is defined as secured storage of information such that the information is rendered inaccessible by authorized users in the ordinary course of business but can be retrieved by an administrator designated by company management.
+
+        1. Physical (e.g., paper) records must be archived in secured storage (onsite or offsite) and clearly labeled in archive boxes naming the information owner.
+
+        1. Electronic records must be archived with strict access controls set by the information owner and appropriate to secure the confidentiality, integrity and accessibility of the information.
+
+    i. The default archiving period of information shall be 7 years unless an approved exception permits a longer or shorter period. Exceptions must be requested by the information owner.
+
+        1. As a guideline, an archiving period of more than 7 years may be granted for information with a vital historical purpose such as corporate records, contracts, and technical/trade secrets.
+
+        1. As a guideline, an archiving period of less than 7 years may be granted for information with a limited business purpose such as email, travel itineraries, pre-trip advisories, or to comply with specific legal, contractual and/or regulatory requirements (e.g., PCI DSS, GDPR, etc.)
+
+    i. Information must be destroyed (defined below) at the end of the elapsed archiving period.  
+
+a. *Information Destruction*
+
+    i. Destruction is defined as the physical or technical destruction sufficient to render the information contained in the document irretrievable by ordinary commercially-available means.
+
+    i. The organization must maintain and enforce a detailed list of approved destruction methods appropriate for each type of information archived, whether in physical storage media such as CD-ROMs, DVDs, backup tapes, hard drives, mobile devices, portable drives or in database records or backup files. Physical information in paper form must be shredded using an authorized shredding device; waste must be periodically removed by approved personnel.
+
+a. Retention and archival periods for information that is created, processed, stored and used by the organization is defined in Appendix A, “Retention Periods.” 
+
+\pagebreak 
+
+# Appendix A: Retention Periods 
+
++------------------+-------------------+------------------+------------------+-----------------+
+| Information Type | Information Owner | Storage Location | Retention Period | Archival Period |
++==================+===================+==================+==================+=================+
+|                  |                   |                  |                  |                 |
+|                  |                   |                  |                  |                 |
++------------------+-------------------+------------------+------------------+-----------------+
+|                  |                   |                  |                  |                 |
+|                  |                   |                  |                  |                 |
++------------------+-------------------+------------------+------------------+-----------------+

themes/comply-soc2/policies/risk.md

@@ -8,4 +8,130 @@ majorRevisions:
     comment: Initial document
 ---
 
-# Coming Soon
+# Purpose and Scope
+
+a. The purpose of this policy is to define the methodology for the assessment and treatment of information security risks within the organization, and to define the acceptable level of risk as set by the organization’s leadership.
+
+a. Risk assessment and risk treatment are applied to the entire scope of the organization’s information security program, and to all assets which are used within the organization or which could have an impact on information security within it.
+
+a. This policy applies to all employees of the organization who take part in risk assessment and risk treatment.
+
+# Background
+
+a. A key element of the organization’s information security program is a holistic and systematic approach to risk management. This policy defines the requirements and processes for the organization to identify information security risks. The process consists of four parts: identification of the organization’s assets, as well as the threats and vulnerabilities that apply; assessment of the likelihood and consequence (risk) of the threats and vulnerabilities being realized, identification of treatment for each unacceptable risk, and evaluation of the residual risk after treatment.
+
+# References
+
+a. Risk Assessment Report Template
+
+# Policy
+
+a. *Risk Assessment*
+
+    i. The risk assessment process includes the identification of threats and vulnerabilities having to do with company assets.
+
+    i. The first step in the risk assessment is to identify all assets within the scope of the information security program; in other words, all assets which may affect the confidentiality, integrity, and/or availability of information in the organization. Assets may include documents in paper or electronic form, applications, databases, information technology equipment, infrastructure, and external/outsourced services and processes. For each asset, an owner must be identified.
+
+    i. The next step is to identify all threats and vulnerabilities associated with each asset. Threats and vulnerabilities must be listed in a risk assessment table. Each asset may be associated with multiple threats, and each threat may be associated with multiple vulnerabilities. A sample risk assessment table is provided as part of the Risk Assessment Report Template (reference (a)).
+
+    i. For each risk, an owner must be identified. The risk owner and the asset owner may be the same individual.
+
+    i. Once risk owners are identified, they must assess:
+
+        1. Consequences for each combination of threats and vulnerabilities for an individual asset if such a risk materializes. 
+
+        1. Likelihood of occurrence of such a risk (i.e. the probability that a threat will exploit the vulnerability of the respective asset).
+
+        1. Criteria for determining consequence and likelihood are defined in Tables 3 and 4.
+    
+    i. The risk level is calculated by adding the consequence score and the likelihood score.
+
++-----------------+-----------------+--------------------------------------------------------------+
+| **Consequence** | **Consequence** | **Description**                                              | 
+| **Level**       | **Score**       |                                                              |
++=================+=================+==============================================================+
+| Low             | 0               | Loss of confidentiality, integrity, or availability will not |     
+|                 |                 | affect the organization's cash flow, legal, or contractual   |                    
+|                 |                 | obligations, or reputation.                                  |
++-----------------+-----------------+--------------------------------------------------------------+
+|                 |                 |                                                              |  
++-----------------+-----------------+--------------------------------------------------------------+
+| Moderate        | 1               | Loss of confidentiality, integrity, or availability may incur|     
+|                 |                 | financial cost and has low or moderate impact on the         |                    
+|                 |                 | organization's legal or contractual obligations and/or       |
+|                 |                 | reputation.                                                  |
++-----------------+-----------------+--------------------------------------------------------------+
+|                 |                 |                                                              |  
++-----------------+-----------------+--------------------------------------------------------------+
+| High            | 2               | Loss of confidentiality, integrity, or availability will have|     
+|                 |                 | immediate and or/considerable impact on the organization's   |                    
+|                 |                 | cash flow, operations, legal and contractual obligations,and/|
+|                 |                 | or reputation.                                               |
++-----------------+-----------------+--------------------------------------------------------------+
+|                 |                 |                                                              |  
++-----------------+-----------------+--------------------------------------------------------------+
+
+Table 3: Description of Consequence Levels and Criteria
+
++-----------------+-----------------+--------------------------------------------------------------+
+| **Likelihood**  | **Likelihood**  | **Description**                                              | 
+| **Level**       | **Score**       |                                                              |
++=================+=================+==============================================================+
+| Low             | 0               | Either existing security controls are strong and have so far |     
+|                 |                 | provided an adequate level of protection, or the probability |                    
+|                 |                 | of the risk being realized is extremely low. No new incidents|
+|                 |                 | are expected in the future.                                  |
++-----------------+-----------------+--------------------------------------------------------------+
+|                 |                 |                                                              |  
++-----------------+-----------------+--------------------------------------------------------------+
+| Moderate        | 1               | Either existing security controls have most provided an      |     
+|                 |                 | adequate level of protection or the probability of the risk  |                    
+|                 |                 | being realized is moderate. Some minor incidents may have    |
+|                 |                 | occured. New incidents are possible, but not highly likely.  |
++-----------------+-----------------+--------------------------------------------------------------+
+|                 |                 |                                                              |  
++-----------------+-----------------+--------------------------------------------------------------+
+| High            | 2               | Either existing security controls are not in place or        |
+|                 |                 | ineffective; there is a high probability of the risk being   |                    
+|                 |                 | realized. Incidents have a high likelihood of occuring in the|
+|                 |                 | future.                                             |
++-----------------+-----------------+--------------------------------------------------------------+
+|                 |                 |                                                              |  
++-----------------+-----------------+--------------------------------------------------------------+
+
+Table 4: Description of Likelihood Levels and Criteria
+
+ 
+
+b. *Risk Acceptance Criteria*
+
+    i. Risk values 0 through 2 are considered to be acceptable risks.
+
+    i. Risk values 3 and 4 are considered to be unacceptable risks. Unacceptable risks must be treated.
+
+c. *Risk Treatment*
+
+    i. Risk treatment is implemented through the Risk Treatment Table. All risks from the Risk Assessment Table must be copied to the Risk Treatment Table for disposition, along with treatment options and residual risk. A sample Risk Treatment Table is provided in reference (a).
+
+    i. As part of this risk treatment process, the CEO and/or other company managers shall determine objectives for mitigating or treating risks. All unacceptable risks must be treated. For continuous improvement purposes, company managers may also opt to treat other risks for company assets, even if their risk score is deemed to be acceptable.
+
+    i. Treatment options for risks include the following options:
+
+        1. Selection or development of security control(s).
+
+        1. Transferring the risks to a third party; for example, by purchasing an insurance policy or signing a contract with suppliers or partners.
+
+        1. Avoiding the risk by discontinuing the business activity that causes such risk.
+
+        1. Accepting the risk; this option is permitted only if the selection of other risk treatment options would cost more than the potential impact of the risk being realized.
+
+    i. After selecting a treatment option, the risk owner should estimate the new consequence and likelihood values after the planned controls are implemented.
+
+a. *Regular Reviews of Risk Assessment and Risk Treatment*
+
+    i. The Risk Assessment Table and Risk Treatment Table must be updated when newly identified risks are identified. At a minimum, this update and review shall be conducted once per year. It is highly recommended that the Risk Assessment and Risk Treatment Table be updated when significant changes occur to the organization, technology, business objectives, or business environment.
+
+a. *Reporting*
+
+    i. The results of risk assessment and risk treatment, and all subsequent reviews, shall be documented in a Risk Assessment Report.
+

themes/comply-soc2/policies/vendor.md

@@ -8,4 +8,40 @@ majorRevisions:
     comment: Initial document
 ---
 
-# Coming Soon
+# Purpose and Scope
+
+a. This policy defines the rules for relationships with the organization’s Information Technology (IT) vendors and partners. 
+
+a. This policy applies to all IT vendors and partners who have the ability to impact the confidentiality, integrity, and availability of the organization’s technology and sensitive information, or who are within the scope of the organization’s information security program.
+
+a. This policy applies to all employees and contractors that are responsible for the management and oversight of IT vendors and partners of the organization. 
+
+# Background
+
+a. The overall security of the organization is highly dependent on the security of its contractual relationships with its IT suppliers and partners. This policy defines  requirements for effective management and oversight of such suppliers and partners from an information security perspective. The policy prescribes minimum standards a vendor must meet from an information security standpoint, including security clauses, risk assessments, service level agreements, and incident management.
+
+# References
+
+a. Information Security Policy
+
+a. Security Incident Response Policy
+
+# Policy
+
+a. IT vendors are prohibited from accessing the organization’s information security assets until  a contract containing security controls is agreed to and signed by the appropriate parties.
+
+a. All IT vendors must comply with the security policies defined and derived from the Information Security Policy (reference (a)). 
+
+a. All security incidents by IT vendors or partners must be documented in accordance with the organization’s Security Incident Response Policy (reference (b)) and immediately forwarded to the Information Security Manager (ISM). 
+
+a. The organization must adhere to the terms of all Service Level Agreements (SLAs) entered into with IT vendors. As terms are updated, and as new ones are entered into, the organization must implement any changes or controls needed to ensure it remains in compliance. 
+
+a. Before entering into a contract and gaining access to the parent organization’s information systems, IT vendors must undergo a risk assessment. 
+
+    i. Security risks related to IT vendors and partners must be identified during the risk assessment process. 
+    
+    i. The risk assessment must identify risks related to information and communication technology, as well as risks related to IT vendor supply chains, to include sub-suppliers. 
+
+a. IT vendors and partners must ensure that organizational records are protected, safeguarded, and disposed of securely. The organization strictly adheres to all applicable legal, regulatory and contractual requirements regarding the collection, processing, and transmission of sensitive data such as Personally-Identifiable Information (PII). 
+
+a. The organization may choose to audit IT vendors and partners to ensure compliance with applicable security policies, as well as legal, regulatory and contractual obligations.

themes/comply-soc2/procedures/offboarding.md

@@ -2,4 +2,10 @@ id: "offboard"
 name: "Offboard User"
 ---
 
-# Coming Soon
+Resolve this ticket by executing the following steps:
+
+- [ ] Immediately suspend user in SSO
+- [ ] Append HR termination request e-mail to this ticket
+- [ ] Look up manually-provisioned applications for this role or user
+- [ ] Validate access revocation in each
+- [ ] Append confirmation or revocation to this ticket

themes/comply-soc2/procedures/onboarding.md

@@ -2,4 +2,11 @@ id: "onboard"
 name: "Onboard New User"
 ---
 
-# Coming Soon
+Resolve this ticket by executing the following steps:
+
+- [ ] Append HR add request e-mail to this ticket
+- [ ] Proactively validate role assignment with manager (see HR request e-mail)
+- [ ] Add user to default group for the specified role
+- [ ] Provision any manually-provisioned applications by role
+    - [ ] Append manual provisioning confirmation to this ticket
+- [ ] Proactively confirm with new user that they can access all provisioned systems

themes/comply-soc2/procedures/patch.md

@@ -1,6 +1,15 @@
 id: "patch"
 name: "Apply OS patches"
-cron: "0 0 1 * * *"
+cron: "0 0 0 15 * *"
 ---
 
-# Coming Soon
+# OS Patch Procedure
+
+Resolve this ticket by executing the following steps:
+
+- [ ] Pull the latest scripts from the Ops repository
+- [ ] Execute `ENV=staging patch-all.sh`
+- [ ] Inspect output
+    - [ ] Errors? Investigate and resolve
+- [ ] Execute `ENV=production patch-all.sh`
+- [ ] Attach log output to this ticket

themes/comply-soc2/procedures/workstation.md

@@ -1,6 +1,40 @@
 id: "workstation"
 name: "Collect Workstation Details"
-cron: "0 0 * * * *"
+cron: "0 0 0 15 4 *"
 ---
 
-# Coming Soon
+Resolve this ticket by executing the following steps:
+
+- [ ] Send the communications below
+- [ ] For any email replies, attach content to this ticket
+- [ ] Validate responses are received from each
+
+
+```
+To: Desktop support
+Subject: Annual workstation inventory
+
+Please attach the current workstation inventory to the following ticket: [REPLACE WITH URL TO THIS TICKET]
+
+The workstation inventory shall include the following fields:
+    * Serial number
+    * Custodian
+    * Full disk encryption status
+    * Malware protection status
+```
+
+
+```
+To: Outsourced Call Center IT
+Subject: Annual workstation inventory
+
+As part of our ongoing compliance efforts and per our services agreement, we require a current inventory of workstations in use in the service of our account.
+
+Please respond to this message with the current inventory.
+
+The workstation inventory shall include the following fields:
+    * Serial number
+    * Custodian
+    * Full disk encryption status
+    * Malware protection status
+```

vendor/github.com/andygrunwald/go-jira/.gitignore

@@ -0,0 +1,29 @@
+# Compiled Object files, Static and Dynamic libs (Shared Objects)
+*.o
+*.a
+*.so
+
+# Don't check in vendor
+vendor/
+
+# Folders
+_obj
+_test
+
+# Architecture specific extensions/prefixes
+*.[568vq]
+[568vq].out
+
+*.cgo1.go
+*.cgo2.c
+_cgo_defun.c
+_cgo_gotypes.go
+_cgo_export.*
+
+_testmain.go
+
+*.exe
+*.test
+*.prof
+*.iml
+.idea

vendor/github.com/andygrunwald/go-jira/.travis.yml

@@ -0,0 +1,17 @@
+language: go
+
+sudo: false
+
+go:
+  - 1.4
+  - 1.5
+  - 1.6
+  - 1.7
+  - 1.8
+  - 1.9
+
+before_install:
+  - go get -t ./...
+
+script:
+  - GOMAXPROCS=4 GORACE="halt_on_error=1" go test -race -v ./...

vendor/github.com/andygrunwald/go-jira/Gopkg.lock

@@ -0,0 +1,36 @@
+# This file is autogenerated, do not edit; changes may be undone by the next 'dep ensure'.
+
+
+[[projects]]
+  name = "github.com/fatih/structs"
+  packages = ["."]
+  revision = "a720dfa8df582c51dee1b36feabb906bde1588bd"
+  version = "v1.0"
+
+[[projects]]
+  branch = "master"
+  name = "github.com/google/go-querystring"
+  packages = ["query"]
+  revision = "53e6ce116135b80d037921a7fdd5138cf32d7a8a"
+
+[[projects]]
+  name = "github.com/pkg/errors"
+  packages = ["."]
+  revision = "645ef00459ed84a119197bfb8d8205042c6df63d"
+  version = "v0.8.0"
+
+[[projects]]
+  name = "github.com/trivago/tgo"
+  packages = [
+    "tcontainer",
+    "treflect"
+  ]
+  revision = "e4d1ddd28c17dd89ed26327cf69fded22060671b"
+  version = "v1.0.1"
+
+[solve-meta]
+  analyzer-name = "dep"
+  analyzer-version = 1
+  inputs-digest = "e84ca9eea6d233e0947b0d760913db2983fd4cbf6fd0d8690c737a71affb635c"
+  solver-name = "gps-cdcl"
+  solver-version = 1

vendor/github.com/andygrunwald/go-jira/Gopkg.toml

@@ -0,0 +1,46 @@
+# Gopkg.toml example
+#
+# Refer to https://github.com/golang/dep/blob/master/docs/Gopkg.toml.md
+# for detailed Gopkg.toml documentation.
+#
+# required = ["github.com/user/thing/cmd/thing"]
+# ignored = ["github.com/user/project/pkgX", "bitbucket.org/user/project/pkgA/pkgY"]
+#
+# [[constraint]]
+#   name = "github.com/user/project"
+#   version = "1.0.0"
+#
+# [[constraint]]
+#   name = "github.com/user/project2"
+#   branch = "dev"
+#   source = "github.com/myfork/project2"
+#
+# [[override]]
+#   name = "github.com/x/y"
+#   version = "2.4.0"
+#
+# [prune]
+#   non-go = false
+#   go-tests = true
+#   unused-packages = true
+
+
+[[constraint]]
+  name = "github.com/fatih/structs"
+  version = "1.0.0"
+
+[[constraint]]
+  branch = "master"
+  name = "github.com/google/go-querystring"
+
+[[constraint]]
+  name = "github.com/pkg/errors"
+  version = "0.8.0"
+
+[[constraint]]
+  name = "github.com/trivago/tgo"
+  version = "1.0.1"
+
+[prune]
+  go-tests = true
+  unused-packages = true

vendor/github.com/andygrunwald/go-jira/LICENSE

@@ -0,0 +1,22 @@
+The MIT License (MIT)
+
+Copyright (c) 2015 Andy Grunwald
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+

vendor/github.com/andygrunwald/go-jira/Makefile

@@ -0,0 +1,2 @@
+test:
+	go test -v ./...

vendor/github.com/andygrunwald/go-jira/README.md

@@ -0,0 +1,271 @@
+# go-jira
+
+[![GoDoc](https://godoc.org/github.com/andygrunwald/go-jira?status.svg)](https://godoc.org/github.com/andygrunwald/go-jira)
+[![Build Status](https://travis-ci.org/andygrunwald/go-jira.svg?branch=master)](https://travis-ci.org/andygrunwald/go-jira)
+[![Go Report Card](https://goreportcard.com/badge/github.com/andygrunwald/go-jira)](https://goreportcard.com/report/github.com/andygrunwald/go-jira)
+
+[Go](https://golang.org/) client library for [Atlassian JIRA](https://www.atlassian.com/software/jira).
+
+![Go client library for Atlassian JIRA](./img/logo_small.png "Go client library for Atlassian JIRA.")
+
+## Features
+
+* Authentication (HTTP Basic, OAuth, Session Cookie)
+* Create and retrieve issues
+* Create and retrieve issue transitions (status updates)
+* Call every API endpoint of the JIRA, even if it is not directly implemented in this library
+
+This package is not JIRA API complete (yet), but you can call every API endpoint you want. See [Call a not implemented API endpoint](#call-a-not-implemented-api-endpoint) how to do this. For all possible API endpoints of JIRA have a look at [latest JIRA REST API documentation](https://docs.atlassian.com/jira/REST/latest/).
+
+## Compatible JIRA versions
+
+This package was tested against JIRA v6.3.4 and v7.1.2.
+
+## Installation
+
+It is go gettable
+
+    $ go get github.com/andygrunwald/go-jira
+
+For stable versions you can use one of our tags with [gopkg.in](http://labix.org/gopkg.in). E.g.
+
+```go
+package main
+
+import (
+	jira "gopkg.in/andygrunwald/go-jira.v1"
+)
+...
+```
+
+(optional) to run unit / example tests:
+
+    $ cd $GOPATH/src/github.com/andygrunwald/go-jira
+    $ go test -v ./...
+
+## API
+
+Please have a look at the [GoDoc documentation](https://godoc.org/github.com/andygrunwald/go-jira) for a detailed API description.
+
+The [latest JIRA REST API documentation](https://docs.atlassian.com/jira/REST/latest/) was the base document for this package.
+
+## Examples
+
+Further a few examples how the API can be used.
+A few more examples are available in the [GoDoc examples section](https://godoc.org/github.com/andygrunwald/go-jira#pkg-examples).
+
+### Get a single issue
+
+Lets retrieve [MESOS-3325](https://issues.apache.org/jira/browse/MESOS-3325) from the [Apache Mesos](http://mesos.apache.org/) project.
+
+```go
+package main
+
+import (
+	"fmt"
+	"github.com/andygrunwald/go-jira"
+)
+
+func main() {
+	jiraClient, _ := jira.NewClient(nil, "https://issues.apache.org/jira/")
+	issue, _, _ := jiraClient.Issue.Get("MESOS-3325", nil)
+
+	fmt.Printf("%s: %+v\n", issue.Key, issue.Fields.Summary)
+	fmt.Printf("Type: %s\n", issue.Fields.Type.Name)
+	fmt.Printf("Priority: %s\n", issue.Fields.Priority.Name)
+
+	// MESOS-3325: Running mesos-slave@0.23 in a container causes slave to be lost after a restart
+	// Type: Bug
+	// Priority: Critical
+}
+```
+
+### Authentication
+
+The `go-jira` library does not handle most authentication directly.  Instead, authentication should be handled within
+an `http.Client`.  That client can then be passed into the `NewClient` function when creating a jira client.
+
+For convenience, capability for basic and cookie-based authentication is included in the main library.
+
+#### Basic auth example
+
+A more thorough, [runnable example](examples/basicauth/main.go) is provided in the examples directory.
+
+```go
+func main() {
+	tp := jira.BasicAuthTransport{
+		Username: "username",
+		Password: "password",
+	}
+
+	client, err := jira.NewClient(tp.Client(), "https://my.jira.com")
+
+	u, _, err := client.User.Get("some_user")
+
+	fmt.Printf("\nEmail: %v\nSuccess!\n", u.EmailAddress)
+}
+```
+
+#### Authenticate with session cookie
+
+A more thorough, [runnable example](examples/cookieauth/main.go) is provided in the examples directory.
+
+Note:  The `AuthURL` is almost always going to have the path `/rest/auth/1/session`
+
+```go
+	tp := jira.CookieAuthTransport{
+		Username: "username",
+		Password: "password",
+		AuthURL:  "https://my.jira.com/rest/auth/1/session",
+	}
+
+	client, err := jira.NewClient(tp.Client(), "https://my.jira.com")
+	u, _, err := client.User.Get("admin")
+
+	fmt.Printf("\nEmail: %v\nSuccess!\n", u.EmailAddress)
+}
+```
+
+#### Authenticate with OAuth
+
+If you want to connect via OAuth to your JIRA Cloud instance checkout the [example of using OAuth authentication with JIRA in Go](https://gist.github.com/Lupus/edafe9a7c5c6b13407293d795442fe67) by [@Lupus](https://github.com/Lupus).
+
+For more details have a look at the [issue #56](https://github.com/andygrunwald/go-jira/issues/56).
+
+### Create an issue
+
+Example how to create an issue.
+
+```go
+package main
+
+import (
+	"fmt"
+	"github.com/andygrunwald/go-jira"
+)
+
+func main() {
+	base := "https://my.jira.com"
+	tp := jira.CookieAuthTransport{
+		Username: "username",
+		Password: "password",
+		AuthURL:  fmt.Sprintf("%s/rest/auth/1/session", base),
+	}
+
+	jiraClient, err := jira.NewClient(tp.Client(), base)
+	if err != nil {
+		panic(err)
+	}
+
+	i := jira.Issue{
+		Fields: &jira.IssueFields{
+			Assignee: &jira.User{
+				Name: "myuser",
+			},
+			Reporter: &jira.User{
+				Name: "youruser",
+			},
+			Description: "Test Issue",
+			Type: jira.IssueType{
+				Name: "Bug",
+			},
+			Project: jira.Project{
+				Key: "PROJ1",
+			},
+			Summary: "Just a demo issue",
+		},
+	}
+	issue, _, err := jiraClient.Issue.Create(&i)
+	if err != nil {
+		panic(err)
+	}
+
+	fmt.Printf("%s: %+v\n", issue.Key, issue.Fields.Summary)
+}
+```
+
+### Call a not implemented API endpoint
+
+Not all API endpoints of the JIRA API are implemented into *go-jira*.
+But you can call them anyway:
+Lets get all public projects of [Atlassian`s JIRA instance](https://jira.atlassian.com/).
+
+```go
+package main
+
+import (
+	"fmt"
+	"github.com/andygrunwald/go-jira"
+)
+
+func main() {
+	base := "https://my.jira.com"
+	tp := jira.CookieAuthTransport{
+		Username: "username",
+		Password: "password",
+		AuthURL:  fmt.Sprintf("%s/rest/auth/1/session", base),
+	}
+
+	jiraClient, err := jira.NewClient(tp.Client(), base)
+	req, _ := jiraClient.NewRequest("GET", "/rest/api/2/project", nil)
+
+	projects := new([]jira.Project)
+	_, err := jiraClient.Do(req, projects)
+	if err != nil {
+		panic(err)
+	}
+
+	for _, project := range *projects {
+		fmt.Printf("%s: %s\n", project.Key, project.Name)
+	}
+
+	// ...
+	// BAM: Bamboo
+	// BAMJ: Bamboo JIRA Plugin
+	// CLOV: Clover
+	// CONF: Confluence
+	// ...
+}
+```
+
+## Implementations
+
+* [andygrunwald/jitic](https://github.com/andygrunwald/jitic) - The JIRA Ticket Checker
+
+## Code structure
+
+The code structure of this package was inspired by [google/go-github](https://github.com/google/go-github).
+
+There is one main part (the client).
+Based on this main client the other endpoints, like Issues or Authentication are extracted in services. E.g. `IssueService` or `AuthenticationService`.
+These services own a responsibility of the single endpoints / usecases of JIRA.
+
+## Contribution
+
+Contribution, in any kind of way, is highly welcome!
+It doesn't matter if you are not able to write code.
+Creating issues or holding talks and help other people to use [go-jira](https://github.com/andygrunwald/go-jira) is contribution, too!
+A few examples:
+
+* Correct typos in the README / documentation
+* Reporting bugs
+* Implement a new feature or endpoint
+* Sharing the love if [go-jira](https://github.com/andygrunwald/go-jira) and help people to get use to it
+
+If you are new to pull requests, checkout [Collaborating on projects using issues and pull requests / Creating a pull request](https://help.github.com/articles/creating-a-pull-request/).
+
+### Dependency management
+
+`go-jira` uses `dep` for dependency management.  After cloning the repo, it's easy to make sure you have the correct dependencies by running `dep ensure`.
+
+For adding new dependencies, updating dependencies, and other operations, the [Daily Dep](https://golang.github.io/dep/docs/daily-dep.html) is a good place to start.
+
+### Sandbox environment for testing
+
+Jira offers sandbox test environments at http://go.atlassian.com/cloud-dev.
+
+You can read more about them at https://developer.atlassian.com/blog/2016/04/cloud-ecosystem-dev-env/.
+
+## License
+
+This project is released under the terms of the [MIT license](http://en.wikipedia.org/wiki/MIT_License).

vendor/github.com/andygrunwald/go-jira/authentication.go

@@ -0,0 +1,187 @@
+package jira
+
+import (
+	"encoding/json"
+	"fmt"
+	"io/ioutil"
+	"net/http"
+)
+
+const (
+	// HTTP Basic Authentication
+	authTypeBasic = 1
+	// HTTP Session Authentication
+	authTypeSession = 2
+)
+
+// AuthenticationService handles authentication for the JIRA instance / API.
+//
+// JIRA API docs: https://docs.atlassian.com/jira/REST/latest/#authentication
+type AuthenticationService struct {
+	client *Client
+
+	// Authentication type
+	authType int
+
+	// Basic auth username
+	username string
+
+	// Basic auth password
+	password string
+}
+
+// Session represents a Session JSON response by the JIRA API.
+type Session struct {
+	Self    string `json:"self,omitempty"`
+	Name    string `json:"name,omitempty"`
+	Session struct {
+		Name  string `json:"name"`
+		Value string `json:"value"`
+	} `json:"session,omitempty"`
+	LoginInfo struct {
+		FailedLoginCount    int    `json:"failedLoginCount"`
+		LoginCount          int    `json:"loginCount"`
+		LastFailedLoginTime string `json:"lastFailedLoginTime"`
+		PreviousLoginTime   string `json:"previousLoginTime"`
+	} `json:"loginInfo"`
+	Cookies []*http.Cookie
+}
+
+// AcquireSessionCookie creates a new session for a user in JIRA.
+// Once a session has been successfully created it can be used to access any of JIRA's remote APIs and also the web UI by passing the appropriate HTTP Cookie header.
+// The header will by automatically applied to every API request.
+// Note that it is generally preferrable to use HTTP BASIC authentication with the REST API.
+// However, this resource may be used to mimic the behaviour of JIRA's log-in page (e.g. to display log-in errors to a user).
+//
+// JIRA API docs: https://docs.atlassian.com/jira/REST/latest/#auth/1/session
+//
+// Deprecated: Use CookieAuthTransport instead
+func (s *AuthenticationService) AcquireSessionCookie(username, password string) (bool, error) {
+	apiEndpoint := "rest/auth/1/session"
+	body := struct {
+		Username string `json:"username"`
+		Password string `json:"password"`
+	}{
+		username,
+		password,
+	}
+
+	req, err := s.client.NewRequest("POST", apiEndpoint, body)
+	if err != nil {
+		return false, err
+	}
+
+	session := new(Session)
+	resp, err := s.client.Do(req, session)
+
+	if resp != nil {
+		session.Cookies = resp.Cookies()
+	}
+
+	if err != nil {
+		return false, fmt.Errorf("Auth at JIRA instance failed (HTTP(S) request). %s", err)
+	}
+	if resp != nil && resp.StatusCode != 200 {
+		return false, fmt.Errorf("Auth at JIRA instance failed (HTTP(S) request). Status code: %d", resp.StatusCode)
+	}
+
+	s.client.session = session
+	s.authType = authTypeSession
+
+	return true, nil
+}
+
+// SetBasicAuth sets username and password for the basic auth against the JIRA instance.
+//
+// Deprecated: Use BasicAuthTransport instead
+func (s *AuthenticationService) SetBasicAuth(username, password string) {
+	s.username = username
+	s.password = password
+	s.authType = authTypeBasic
+}
+
+// Authenticated reports if the current Client has authentication details for JIRA
+func (s *AuthenticationService) Authenticated() bool {
+	if s != nil {
+		if s.authType == authTypeSession {
+			return s.client.session != nil
+		} else if s.authType == authTypeBasic {
+			return s.username != ""
+		}
+
+	}
+	return false
+}
+
+// Logout logs out the current user that has been authenticated and the session in the client is destroyed.
+//
+// JIRA API docs: https://docs.atlassian.com/jira/REST/latest/#auth/1/session
+//
+// Deprecated: Use CookieAuthTransport to create base client.  Logging out is as simple as not using the
+// client anymore
+func (s *AuthenticationService) Logout() error {
+	if s.authType != authTypeSession || s.client.session == nil {
+		return fmt.Errorf("no user is authenticated")
+	}
+
+	apiEndpoint := "rest/auth/1/session"
+	req, err := s.client.NewRequest("DELETE", apiEndpoint, nil)
+	if err != nil {
+		return fmt.Errorf("Creating the request to log the user out failed : %s", err)
+	}
+
+	resp, err := s.client.Do(req, nil)
+	if err != nil {
+		return fmt.Errorf("Error sending the logout request: %s", err)
+	}
+	if resp.StatusCode != 204 {
+		return fmt.Errorf("The logout was unsuccessful with status %d", resp.StatusCode)
+	}
+
+	// If logout successful, delete session
+	s.client.session = nil
+
+	return nil
+
+}
+
+// GetCurrentUser gets the details of the current user.
+//
+// JIRA API docs: https://docs.atlassian.com/jira/REST/latest/#auth/1/session
+func (s *AuthenticationService) GetCurrentUser() (*Session, error) {
+	if s == nil {
+		return nil, fmt.Errorf("AUthenticaiton Service is not instantiated")
+	}
+	if s.authType != authTypeSession || s.client.session == nil {
+		return nil, fmt.Errorf("No user is authenticated yet")
+	}
+
+	apiEndpoint := "rest/auth/1/session"
+	req, err := s.client.NewRequest("GET", apiEndpoint, nil)
+	if err != nil {
+		return nil, fmt.Errorf("Could not create request for getting user info : %s", err)
+	}
+
+	resp, err := s.client.Do(req, nil)
+	if err != nil {
+		return nil, fmt.Errorf("Error sending request to get user info : %s", err)
+	}
+	if resp.StatusCode != 200 {
+		return nil, fmt.Errorf("Getting user info failed with status : %d", resp.StatusCode)
+	}
+
+	defer resp.Body.Close()
+	ret := new(Session)
+	data, err := ioutil.ReadAll(resp.Body)
+	if err != nil {
+		return nil, fmt.Errorf("Couldn't read body from the response : %s", err)
+	}
+
+	err = json.Unmarshal(data, &ret)
+
+	if err != nil {
+		return nil, fmt.Errorf("Could not unmarshall received user info : %s", err)
+	}
+
+	return ret, nil
+}

vendor/github.com/andygrunwald/go-jira/board.go

@@ -0,0 +1,166 @@
+package jira
+
+import (
+	"fmt"
+	"time"
+)
+
+// BoardService handles Agile Boards for the JIRA instance / API.
+//
+// JIRA API docs: https://docs.atlassian.com/jira-software/REST/server/
+type BoardService struct {
+	client *Client
+}
+
+// BoardsList reflects a list of agile boards
+type BoardsList struct {
+	MaxResults int     `json:"maxResults" structs:"maxResults"`
+	StartAt    int     `json:"startAt" structs:"startAt"`
+	Total      int     `json:"total" structs:"total"`
+	IsLast     bool    `json:"isLast" structs:"isLast"`
+	Values     []Board `json:"values" structs:"values"`
+}
+
+// Board represents a JIRA agile board
+type Board struct {
+	ID       int    `json:"id,omitempty" structs:"id,omitempty"`
+	Self     string `json:"self,omitempty" structs:"self,omitempty"`
+	Name     string `json:"name,omitempty" structs:"name,omitemtpy"`
+	Type     string `json:"type,omitempty" structs:"type,omitempty"`
+	FilterID int    `json:"filterId,omitempty" structs:"filterId,omitempty"`
+}
+
+// BoardListOptions specifies the optional parameters to the BoardService.GetList
+type BoardListOptions struct {
+	// BoardType filters results to boards of the specified type.
+	// Valid values: scrum, kanban.
+	BoardType string `url:"boardType,omitempty"`
+	// Name filters results to boards that match or partially match the specified name.
+	Name string `url:"name,omitempty"`
+	// ProjectKeyOrID filters results to boards that are relevant to a project.
+	// Relevance meaning that the JQL filter defined in board contains a reference to a project.
+	ProjectKeyOrID string `url:"projectKeyOrId,omitempty"`
+
+	SearchOptions
+}
+
+// Wrapper struct for search result
+type sprintsResult struct {
+	Sprints []Sprint `json:"values" structs:"values"`
+}
+
+// Sprint represents a sprint on JIRA agile board
+type Sprint struct {
+	ID            int        `json:"id" structs:"id"`
+	Name          string     `json:"name" structs:"name"`
+	CompleteDate  *time.Time `json:"completeDate" structs:"completeDate"`
+	EndDate       *time.Time `json:"endDate" structs:"endDate"`
+	StartDate     *time.Time `json:"startDate" structs:"startDate"`
+	OriginBoardID int        `json:"originBoardId" structs:"originBoardId"`
+	Self          string     `json:"self" structs:"self"`
+	State         string     `json:"state" structs:"state"`
+}
+
+// GetAllBoards will returns all boards. This only includes boards that the user has permission to view.
+//
+// JIRA API docs: https://docs.atlassian.com/jira-software/REST/cloud/#agile/1.0/board-getAllBoards
+func (s *BoardService) GetAllBoards(opt *BoardListOptions) (*BoardsList, *Response, error) {
+	apiEndpoint := "rest/agile/1.0/board"
+	url, err := addOptions(apiEndpoint, opt)
+	req, err := s.client.NewRequest("GET", url, nil)
+	if err != nil {
+		return nil, nil, err
+	}
+
+	boards := new(BoardsList)
+	resp, err := s.client.Do(req, boards)
+	if err != nil {
+		jerr := NewJiraError(resp, err)
+		return nil, resp, jerr
+	}
+
+	return boards, resp, err
+}
+
+// GetBoard will returns the board for the given boardID.
+// This board will only be returned if the user has permission to view it.
+//
+// JIRA API docs: https://docs.atlassian.com/jira-software/REST/cloud/#agile/1.0/board-getBoard
+func (s *BoardService) GetBoard(boardID int) (*Board, *Response, error) {
+	apiEndpoint := fmt.Sprintf("rest/agile/1.0/board/%v", boardID)
+	req, err := s.client.NewRequest("GET", apiEndpoint, nil)
+	if err != nil {
+		return nil, nil, err
+	}
+
+	board := new(Board)
+	resp, err := s.client.Do(req, board)
+	if err != nil {
+		jerr := NewJiraError(resp, err)
+		return nil, resp, jerr
+	}
+
+	return board, resp, nil
+}
+
+// CreateBoard creates a new board. Board name, type and filter Id is required.
+// name - Must be less than 255 characters.
+// type - Valid values: scrum, kanban
+// filterId - Id of a filter that the user has permissions to view.
+// Note, if the user does not have the 'Create shared objects' permission and tries to create a shared board, a private
+// board will be created instead (remember that board sharing depends on the filter sharing).
+//
+// JIRA API docs: https://docs.atlassian.com/jira-software/REST/cloud/#agile/1.0/board-createBoard
+func (s *BoardService) CreateBoard(board *Board) (*Board, *Response, error) {
+	apiEndpoint := "rest/agile/1.0/board"
+	req, err := s.client.NewRequest("POST", apiEndpoint, board)
+	if err != nil {
+		return nil, nil, err
+	}
+
+	responseBoard := new(Board)
+	resp, err := s.client.Do(req, responseBoard)
+	if err != nil {
+		jerr := NewJiraError(resp, err)
+		return nil, resp, jerr
+	}
+
+	return responseBoard, resp, nil
+}
+
+// DeleteBoard will delete an agile board.
+//
+// JIRA API docs: https://docs.atlassian.com/jira-software/REST/cloud/#agile/1.0/board-deleteBoard
+func (s *BoardService) DeleteBoard(boardID int) (*Board, *Response, error) {
+	apiEndpoint := fmt.Sprintf("rest/agile/1.0/board/%v", boardID)
+	req, err := s.client.NewRequest("DELETE", apiEndpoint, nil)
+	if err != nil {
+		return nil, nil, err
+	}
+
+	resp, err := s.client.Do(req, nil)
+	if err != nil {
+		err = NewJiraError(resp, err)
+	}
+	return nil, resp, err
+}
+
+// GetAllSprints will returns all sprints from a board, for a given board Id.
+// This only includes sprints that the user has permission to view.
+//
+// JIRA API docs: https://docs.atlassian.com/jira-software/REST/cloud/#agile/1.0/board/{boardId}/sprint
+func (s *BoardService) GetAllSprints(boardID string) ([]Sprint, *Response, error) {
+	apiEndpoint := fmt.Sprintf("rest/agile/1.0/board/%s/sprint", boardID)
+	req, err := s.client.NewRequest("GET", apiEndpoint, nil)
+	if err != nil {
+		return nil, nil, err
+	}
+
+	result := new(sprintsResult)
+	resp, err := s.client.Do(req, result)
+	if err != nil {
+		err = NewJiraError(resp, err)
+	}
+
+	return result.Sprints, resp, err
+}

vendor/github.com/andygrunwald/go-jira/error.go

@@ -0,0 +1,82 @@
+package jira
+
+import (
+	"bytes"
+	"encoding/json"
+	"fmt"
+	"io/ioutil"
+
+	"github.com/pkg/errors"
+)
+
+// Error message from JIRA
+// See https://docs.atlassian.com/jira/REST/cloud/#error-responses
+type Error struct {
+	HTTPError     error
+	ErrorMessages []string          `json:"errorMessages"`
+	Errors        map[string]string `json:"errors"`
+}
+
+// NewJiraError creates a new jira Error
+func NewJiraError(resp *Response, httpError error) error {
+	if resp == nil {
+		return errors.Wrap(httpError, "No response returned")
+	}
+
+	defer resp.Body.Close()
+	body, err := ioutil.ReadAll(resp.Body)
+	if err != nil {
+		return errors.Wrap(err, httpError.Error())
+	}
+
+	jerr := Error{HTTPError: httpError}
+	err = json.Unmarshal(body, &jerr)
+	if err != nil {
+		httpError = errors.Wrap(errors.New("Could not parse JSON"), httpError.Error())
+		return errors.Wrap(err, httpError.Error())
+	}
+
+	return &jerr
+}
+
+// Error is a short string representing the error
+func (e *Error) Error() string {
+	if len(e.ErrorMessages) > 0 {
+		// return fmt.Sprintf("%v", e.HTTPError)
+		return fmt.Sprintf("%s: %v", e.ErrorMessages[0], e.HTTPError)
+	}
+	if len(e.Errors) > 0 {
+		for key, value := range e.Errors {
+			return fmt.Sprintf("%s - %s: %v", key, value, e.HTTPError)
+		}
+	}
+	return e.HTTPError.Error()
+}
+
+// LongError is a full representation of the error as a string
+func (e *Error) LongError() string {
+	var msg bytes.Buffer
+	if e.HTTPError != nil {
+		msg.WriteString("Original:\n")
+		msg.WriteString(e.HTTPError.Error())
+		msg.WriteString("\n")
+	}
+	if len(e.ErrorMessages) > 0 {
+		msg.WriteString("Messages:\n")
+		for _, v := range e.ErrorMessages {
+			msg.WriteString(" - ")
+			msg.WriteString(v)
+			msg.WriteString("\n")
+		}
+	}
+	if len(e.Errors) > 0 {
+		for key, value := range e.Errors {
+			msg.WriteString(" - ")
+			msg.WriteString(key)
+			msg.WriteString(" - ")
+			msg.WriteString(value)
+			msg.WriteString("\n")
+		}
+	}
+	return msg.String()
+}

vendor/github.com/andygrunwald/go-jira/group.go

@@ -0,0 +1,153 @@
+package jira
+
+import (
+	"fmt"
+	"net/url"
+)
+
+// GroupService handles Groups for the JIRA instance / API.
+//
+// JIRA API docs: https://docs.atlassian.com/jira/REST/server/#api/2/group
+type GroupService struct {
+	client *Client
+}
+
+// groupMembersResult is only a small wrapper around the Group* methods
+// to be able to parse the results
+type groupMembersResult struct {
+	StartAt    int           `json:"startAt"`
+	MaxResults int           `json:"maxResults"`
+	Total      int           `json:"total"`
+	Members    []GroupMember `json:"values"`
+}
+
+// Group represents a JIRA group
+type Group struct {
+	ID                   string          `json:"id"`
+	Title                string          `json:"title"`
+	Type                 string          `json:"type"`
+	Properties           groupProperties `json:"properties"`
+	AdditionalProperties bool            `json:"additionalProperties"`
+}
+
+type groupProperties struct {
+	Name groupPropertiesName `json:"name"`
+}
+
+type groupPropertiesName struct {
+	Type string `json:"type"`
+}
+
+// GroupMember reflects a single member of a group
+type GroupMember struct {
+	Self         string `json:"self,omitempty"`
+	Name         string `json:"name,omitempty"`
+	Key          string `json:"key,omitempty"`
+	EmailAddress string `json:"emailAddress,omitempty"`
+	DisplayName  string `json:"displayName,omitempty"`
+	Active       bool   `json:"active,omitempty"`
+	TimeZone     string `json:"timeZone,omitempty"`
+}
+
+type GroupSearchOptions struct {
+	StartAt              int
+	MaxResults           int
+	IncludeInactiveUsers bool
+}
+
+// Get returns a paginated list of users who are members of the specified group and its subgroups.
+// Users in the page are ordered by user names.
+// User of this resource is required to have sysadmin or admin permissions.
+//
+// JIRA API docs: https://docs.atlassian.com/jira/REST/server/#api/2/group-getUsersFromGroup
+//
+// WARNING: This API only returns the first page of group members
+func (s *GroupService) Get(name string) ([]GroupMember, *Response, error) {
+	apiEndpoint := fmt.Sprintf("/rest/api/2/group/member?groupname=%s", url.QueryEscape(name))
+	req, err := s.client.NewRequest("GET", apiEndpoint, nil)
+	if err != nil {
+		return nil, nil, err
+	}
+
+	group := new(groupMembersResult)
+	resp, err := s.client.Do(req, group)
+	if err != nil {
+		return nil, resp, err
+	}
+
+	return group.Members, resp, nil
+}
+
+// Get returns a paginated list of members of the specified group and its subgroups.
+// Users in the page are ordered by user names.
+// User of this resource is required to have sysadmin or admin permissions.
+//
+// JIRA API docs: https://docs.atlassian.com/jira/REST/server/#api/2/group-getUsersFromGroup
+func (s *GroupService) GetWithOptions(name string, options *GroupSearchOptions) ([]GroupMember, *Response, error) {
+	var apiEndpoint string
+	if options == nil {
+		apiEndpoint = fmt.Sprintf("/rest/api/2/group/member?groupname=%s", url.QueryEscape(name))
+	} else {
+		apiEndpoint = fmt.Sprintf(
+			"/rest/api/2/group/member?groupname=%s&startAt=%d&maxResults=%d&includeInactiveUsers=%t",
+			url.QueryEscape(name),
+			options.StartAt,
+			options.MaxResults,
+			options.IncludeInactiveUsers,
+		)
+	}
+	req, err := s.client.NewRequest("GET", apiEndpoint, nil)
+	if err != nil {
+		return nil, nil, err
+	}
+
+	group := new(groupMembersResult)
+	resp, err := s.client.Do(req, group)
+	if err != nil {
+		return nil, resp, err
+	}
+	return group.Members, resp, nil
+}
+
+// Add adds user to group
+//
+// JIRA API docs: https://docs.atlassian.com/jira/REST/cloud/#api/2/group-addUserToGroup
+func (s *GroupService) Add(groupname string, username string) (*Group, *Response, error) {
+	apiEndpoint := fmt.Sprintf("/rest/api/2/group/user?groupname=%s", groupname)
+	var user struct {
+		Name string `json:"name"`
+	}
+	user.Name = username
+	req, err := s.client.NewRequest("POST", apiEndpoint, &user)
+	if err != nil {
+		return nil, nil, err
+	}
+
+	responseGroup := new(Group)
+	resp, err := s.client.Do(req, responseGroup)
+	if err != nil {
+		jerr := NewJiraError(resp, err)
+		return nil, resp, jerr
+	}
+
+	return responseGroup, resp, nil
+}
+
+// Remove removes user from group
+//
+// JIRA API docs: https://docs.atlassian.com/jira/REST/cloud/#api/2/group-removeUserFromGroup
+func (s *GroupService) Remove(groupname string, username string) (*Response, error) {
+	apiEndpoint := fmt.Sprintf("/rest/api/2/group/user?groupname=%s&username=%s", groupname, username)
+	req, err := s.client.NewRequest("DELETE", apiEndpoint, nil)
+	if err != nil {
+		return nil, err
+	}
+
+	resp, err := s.client.Do(req, nil)
+	if err != nil {
+		jerr := NewJiraError(resp, err)
+		return resp, jerr
+	}
+
+	return resp, nil
+}

vendor/github.com/andygrunwald/go-jira/jira.go

@@ -0,0 +1,432 @@
+package jira
+
+import (
+	"bytes"
+	"encoding/json"
+	"fmt"
+	"io"
+	"net/http"
+	"net/url"
+	"reflect"
+	"time"
+
+	"github.com/google/go-querystring/query"
+	"github.com/pkg/errors"
+)
+
+// A Client manages communication with the JIRA API.
+type Client struct {
+	// HTTP client used to communicate with the API.
+	client *http.Client
+
+	// Base URL for API requests.
+	baseURL *url.URL
+
+	// Session storage if the user authentificate with a Session cookie
+	session *Session
+
+	// Services used for talking to different parts of the JIRA API.
+	Authentication *AuthenticationService
+	Issue          *IssueService
+	Project        *ProjectService
+	Board          *BoardService
+	Sprint         *SprintService
+	User           *UserService
+	Group          *GroupService
+	Version        *VersionService
+}
+
+// NewClient returns a new JIRA API client.
+// If a nil httpClient is provided, http.DefaultClient will be used.
+// To use API methods which require authentication you can follow the preferred solution and
+// provide an http.Client that will perform the authentication for you with OAuth and HTTP Basic (such as that provided by the golang.org/x/oauth2 library).
+// As an alternative you can use Session Cookie based authentication provided by this package as well.
+// See https://docs.atlassian.com/jira/REST/latest/#authentication
+// baseURL is the HTTP endpoint of your JIRA instance and should always be specified with a trailing slash.
+func NewClient(httpClient *http.Client, baseURL string) (*Client, error) {
+	if httpClient == nil {
+		httpClient = http.DefaultClient
+	}
+
+	parsedBaseURL, err := url.Parse(baseURL)
+	if err != nil {
+		return nil, err
+	}
+
+	c := &Client{
+		client:  httpClient,
+		baseURL: parsedBaseURL,
+	}
+	c.Authentication = &AuthenticationService{client: c}
+	c.Issue = &IssueService{client: c}
+	c.Project = &ProjectService{client: c}
+	c.Board = &BoardService{client: c}
+	c.Sprint = &SprintService{client: c}
+	c.User = &UserService{client: c}
+	c.Group = &GroupService{client: c}
+	c.Version = &VersionService{client: c}
+
+	return c, nil
+}
+
+// NewRawRequest creates an API request.
+// A relative URL can be provided in urlStr, in which case it is resolved relative to the baseURL of the Client.
+// Relative URLs should always be specified without a preceding slash.
+// Allows using an optional native io.Reader for sourcing the request body.
+func (c *Client) NewRawRequest(method, urlStr string, body io.Reader) (*http.Request, error) {
+	rel, err := url.Parse(urlStr)
+	if err != nil {
+		return nil, err
+	}
+
+	u := c.baseURL.ResolveReference(rel)
+
+	req, err := http.NewRequest(method, u.String(), body)
+	if err != nil {
+		return nil, err
+	}
+
+	req.Header.Set("Content-Type", "application/json")
+
+	// Set authentication information
+	if c.Authentication.authType == authTypeSession {
+		// Set session cookie if there is one
+		if c.session != nil {
+			for _, cookie := range c.session.Cookies {
+				req.AddCookie(cookie)
+			}
+		}
+	} else if c.Authentication.authType == authTypeBasic {
+		// Set basic auth information
+		if c.Authentication.username != "" {
+			req.SetBasicAuth(c.Authentication.username, c.Authentication.password)
+		}
+	}
+
+	return req, nil
+}
+
+// NewRequest creates an API request.
+// A relative URL can be provided in urlStr, in which case it is resolved relative to the baseURL of the Client.
+// Relative URLs should always be specified without a preceding slash.
+// If specified, the value pointed to by body is JSON encoded and included as the request body.
+func (c *Client) NewRequest(method, urlStr string, body interface{}) (*http.Request, error) {
+	rel, err := url.Parse(urlStr)
+	if err != nil {
+		return nil, err
+	}
+
+	u := c.baseURL.ResolveReference(rel)
+
+	var buf io.ReadWriter
+	if body != nil {
+		buf = new(bytes.Buffer)
+		err = json.NewEncoder(buf).Encode(body)
+		if err != nil {
+			return nil, err
+		}
+	}
+
+	req, err := http.NewRequest(method, u.String(), buf)
+	if err != nil {
+		return nil, err
+	}
+
+	req.Header.Set("Content-Type", "application/json")
+
+	// Set authentication information
+	if c.Authentication.authType == authTypeSession {
+		// Set session cookie if there is one
+		if c.session != nil {
+			for _, cookie := range c.session.Cookies {
+				req.AddCookie(cookie)
+			}
+		}
+	} else if c.Authentication.authType == authTypeBasic {
+		// Set basic auth information
+		if c.Authentication.username != "" {
+			req.SetBasicAuth(c.Authentication.username, c.Authentication.password)
+		}
+	}
+
+	return req, nil
+}
+
+// addOptions adds the parameters in opt as URL query parameters to s.  opt
+// must be a struct whose fields may contain "url" tags.
+func addOptions(s string, opt interface{}) (string, error) {
+	v := reflect.ValueOf(opt)
+	if v.Kind() == reflect.Ptr && v.IsNil() {
+		return s, nil
+	}
+
+	u, err := url.Parse(s)
+	if err != nil {
+		return s, err
+	}
+
+	qs, err := query.Values(opt)
+	if err != nil {
+		return s, err
+	}
+
+	u.RawQuery = qs.Encode()
+	return u.String(), nil
+}
+
+// NewMultiPartRequest creates an API request including a multi-part file.
+// A relative URL can be provided in urlStr, in which case it is resolved relative to the baseURL of the Client.
+// Relative URLs should always be specified without a preceding slash.
+// If specified, the value pointed to by buf is a multipart form.
+func (c *Client) NewMultiPartRequest(method, urlStr string, buf *bytes.Buffer) (*http.Request, error) {
+	rel, err := url.Parse(urlStr)
+	if err != nil {
+		return nil, err
+	}
+
+	u := c.baseURL.ResolveReference(rel)
+
+	req, err := http.NewRequest(method, u.String(), buf)
+	if err != nil {
+		return nil, err
+	}
+
+	// Set required headers
+	req.Header.Set("X-Atlassian-Token", "nocheck")
+
+	// Set authentication information
+	if c.Authentication.authType == authTypeSession {
+		// Set session cookie if there is one
+		if c.session != nil {
+			for _, cookie := range c.session.Cookies {
+				req.AddCookie(cookie)
+			}
+		}
+	} else if c.Authentication.authType == authTypeBasic {
+		// Set basic auth information
+		if c.Authentication.username != "" {
+			req.SetBasicAuth(c.Authentication.username, c.Authentication.password)
+		}
+	}
+
+	return req, nil
+}
+
+// Do sends an API request and returns the API response.
+// The API response is JSON decoded and stored in the value pointed to by v, or returned as an error if an API error has occurred.
+func (c *Client) Do(req *http.Request, v interface{}) (*Response, error) {
+	httpResp, err := c.client.Do(req)
+	if err != nil {
+		return nil, err
+	}
+
+	err = CheckResponse(httpResp)
+	if err != nil {
+		// Even though there was an error, we still return the response
+		// in case the caller wants to inspect it further
+		return newResponse(httpResp, nil), err
+	}
+
+	if v != nil {
+		// Open a NewDecoder and defer closing the reader only if there is a provided interface to decode to
+		defer httpResp.Body.Close()
+		err = json.NewDecoder(httpResp.Body).Decode(v)
+	}
+
+	resp := newResponse(httpResp, v)
+	return resp, err
+}
+
+// CheckResponse checks the API response for errors, and returns them if present.
+// A response is considered an error if it has a status code outside the 200 range.
+// The caller is responsible to analyze the response body.
+// The body can contain JSON (if the error is intended) or xml (sometimes JIRA just failes).
+func CheckResponse(r *http.Response) error {
+	if c := r.StatusCode; 200 <= c && c <= 299 {
+		return nil
+	}
+
+	err := fmt.Errorf("Request failed. Please analyze the request body for more details. Status code: %d", r.StatusCode)
+	return err
+}
+
+// GetBaseURL will return you the Base URL.
+// This is the same URL as in the NewClient constructor
+func (c *Client) GetBaseURL() url.URL {
+	return *c.baseURL
+}
+
+// Response represents JIRA API response. It wraps http.Response returned from
+// API and provides information about paging.
+type Response struct {
+	*http.Response
+
+	StartAt    int
+	MaxResults int
+	Total      int
+}
+
+func newResponse(r *http.Response, v interface{}) *Response {
+	resp := &Response{Response: r}
+	resp.populatePageValues(v)
+	return resp
+}
+
+// Sets paging values if response json was parsed to searchResult type
+// (can be extended with other types if they also need paging info)
+func (r *Response) populatePageValues(v interface{}) {
+	switch value := v.(type) {
+	case *searchResult:
+		r.StartAt = value.StartAt
+		r.MaxResults = value.MaxResults
+		r.Total = value.Total
+	case *groupMembersResult:
+		r.StartAt = value.StartAt
+		r.MaxResults = value.MaxResults
+		r.Total = value.Total
+	}
+	return
+}
+
+// BasicAuthTransport is an http.RoundTripper that authenticates all requests
+// using HTTP Basic Authentication with the provided username and password.
+type BasicAuthTransport struct {
+	Username string
+	Password string
+
+	// Transport is the underlying HTTP transport to use when making requests.
+	// It will default to http.DefaultTransport if nil.
+	Transport http.RoundTripper
+}
+
+// RoundTrip implements the RoundTripper interface.  We just add the
+// basic auth and return the RoundTripper for this transport type.
+func (t *BasicAuthTransport) RoundTrip(req *http.Request) (*http.Response, error) {
+	req2 := cloneRequest(req) // per RoundTripper contract
+
+	req2.SetBasicAuth(t.Username, t.Password)
+	return t.transport().RoundTrip(req2)
+}
+
+// Client returns an *http.Client that makes requests that are authenticated
+// using HTTP Basic Authentication.  This is a nice little bit of sugar
+// so we can just get the client instead of creating the client in the calling code.
+// If it's necessary to send more information on client init, the calling code can
+// always skip this and set the transport itself.
+func (t *BasicAuthTransport) Client() *http.Client {
+	return &http.Client{Transport: t}
+}
+
+func (t *BasicAuthTransport) transport() http.RoundTripper {
+	if t.Transport != nil {
+		return t.Transport
+	}
+	return http.DefaultTransport
+}
+
+// CookieAuthTransport is an http.RoundTripper that authenticates all requests
+// using Jira's cookie-based authentication.
+//
+// Note that it is generally preferrable to use HTTP BASIC authentication with the REST API.
+// However, this resource may be used to mimic the behaviour of JIRA's log-in page (e.g. to display log-in errors to a user).
+//
+// JIRA API docs: https://docs.atlassian.com/jira/REST/latest/#auth/1/session
+type CookieAuthTransport struct {
+	Username string
+	Password string
+	AuthURL  string
+
+	// SessionObject is the authenticated cookie string.s
+	// It's passed in each call to prove the client is authenticated.
+	SessionObject []*http.Cookie
+
+	// Transport is the underlying HTTP transport to use when making requests.
+	// It will default to http.DefaultTransport if nil.
+	Transport http.RoundTripper
+}
+
+// RoundTrip adds the session object to the request.
+func (t *CookieAuthTransport) RoundTrip(req *http.Request) (*http.Response, error) {
+	if t.SessionObject == nil {
+		err := t.setSessionObject()
+		if err != nil {
+			return nil, errors.Wrap(err, "cookieauth: no session object has been set")
+		}
+	}
+
+	req2 := cloneRequest(req) // per RoundTripper contract
+	for _, cookie := range t.SessionObject {
+		req2.AddCookie(cookie)
+	}
+
+	return t.transport().RoundTrip(req2)
+}
+
+// Client returns an *http.Client that makes requests that are authenticated
+// using cookie authentication
+func (t *CookieAuthTransport) Client() *http.Client {
+	return &http.Client{Transport: t}
+}
+
+// setSessionObject attempts to authenticate the user and set
+// the session object (e.g. cookie)
+func (t *CookieAuthTransport) setSessionObject() error {
+	req, err := t.buildAuthRequest()
+	if err != nil {
+		return err
+	}
+
+	var authClient = &http.Client{
+		Timeout: time.Second * 60,
+	}
+	resp, err := authClient.Do(req)
+	if err != nil {
+		return err
+	}
+
+	t.SessionObject = resp.Cookies()
+	return nil
+}
+
+// getAuthRequest assembles the request to get the authenticated cookie
+func (t *CookieAuthTransport) buildAuthRequest() (*http.Request, error) {
+	body := struct {
+		Username string `json:"username"`
+		Password string `json:"password"`
+	}{
+		t.Username,
+		t.Password,
+	}
+
+	b := new(bytes.Buffer)
+	json.NewEncoder(b).Encode(body)
+
+	req, err := http.NewRequest("POST", t.AuthURL, b)
+	if err != nil {
+		return nil, err
+	}
+
+	req.Header.Set("Content-Type", "application/json")
+	return req, nil
+}
+
+func (t *CookieAuthTransport) transport() http.RoundTripper {
+	if t.Transport != nil {
+		return t.Transport
+	}
+	return http.DefaultTransport
+}
+
+// cloneRequest returns a clone of the provided *http.Request.
+// The clone is a shallow copy of the struct and its Header map.
+func cloneRequest(r *http.Request) *http.Request {
+	// shallow copy of the struct
+	r2 := new(http.Request)
+	*r2 = *r
+	// deep copy of the Header
+	r2.Header = make(http.Header, len(r.Header))
+	for k, s := range r.Header {
+		r2.Header[k] = append([]string(nil), s...)
+	}
+	return r2
+}

vendor/github.com/andygrunwald/go-jira/metaissue.go

@@ -0,0 +1,194 @@
+package jira
+
+import (
+	"fmt"
+	"strings"
+
+	"github.com/google/go-querystring/query"
+	"github.com/trivago/tgo/tcontainer"
+)
+
+// CreateMetaInfo contains information about fields and their attributed to create a ticket.
+type CreateMetaInfo struct {
+	Expand   string         `json:"expand,omitempty"`
+	Projects []*MetaProject `json:"projects,omitempty"`
+}
+
+// MetaProject is the meta information about a project returned from createmeta api
+type MetaProject struct {
+	Expand string `json:"expand,omitempty"`
+	Self   string `json:"self,omitempty"`
+	Id     string `json:"id,omitempty"`
+	Key    string `json:"key,omitempty"`
+	Name   string `json:"name,omitempty"`
+	// omitted avatarUrls
+	IssueTypes []*MetaIssueType `json:"issuetypes,omitempty"`
+}
+
+// MetaIssueType represents the different issue types a project has.
+//
+// Note: Fields is interface because this is an object which can
+// have arbitraty keys related to customfields. It is not possible to
+// expect these for a general way. This will be returning a map.
+// Further processing must be done depending on what is required.
+type MetaIssueType struct {
+	Self        string                `json:"self,omitempty"`
+	Id          string                `json:"id,omitempty"`
+	Description string                `json:"description,omitempty"`
+	IconUrl     string                `json:"iconurl,omitempty"`
+	Name        string                `json:"name,omitempty"`
+	Subtasks    bool                  `json:"subtask,omitempty"`
+	Expand      string                `json:"expand,omitempty"`
+	Fields      tcontainer.MarshalMap `json:"fields,omitempty"`
+}
+
+// GetCreateMeta makes the api call to get the meta information required to create a ticket
+func (s *IssueService) GetCreateMeta(projectkeys string) (*CreateMetaInfo, *Response, error) {
+	return s.GetCreateMetaWithOptions(&GetQueryOptions{ProjectKeys: projectkeys, Expand: "projects.issuetypes.fields"})
+}
+
+// GetCreateMetaWithOptions makes the api call to get the meta information without requiring to have a projectKey
+func (s *IssueService) GetCreateMetaWithOptions(options *GetQueryOptions) (*CreateMetaInfo, *Response, error) {
+	apiEndpoint := "rest/api/2/issue/createmeta"
+
+	req, err := s.client.NewRequest("GET", apiEndpoint, nil)
+	if err != nil {
+		return nil, nil, err
+	}
+	if options != nil {
+		q, err := query.Values(options)
+		if err != nil {
+			return nil, nil, err
+		}
+		req.URL.RawQuery = q.Encode()
+	}
+
+	meta := new(CreateMetaInfo)
+	resp, err := s.client.Do(req, meta)
+
+	if err != nil {
+		return nil, resp, err
+	}
+
+	return meta, resp, nil
+}
+
+// GetProjectWithName returns a project with "name" from the meta information received. If not found, this returns nil.
+// The comparison of the name is case insensitive.
+func (m *CreateMetaInfo) GetProjectWithName(name string) *MetaProject {
+	for _, m := range m.Projects {
+		if strings.ToLower(m.Name) == strings.ToLower(name) {
+			return m
+		}
+	}
+	return nil
+}
+
+// GetProjectWithKey returns a project with "name" from the meta information received. If not found, this returns nil.
+// The comparison of the name is case insensitive.
+func (m *CreateMetaInfo) GetProjectWithKey(key string) *MetaProject {
+	for _, m := range m.Projects {
+		if strings.ToLower(m.Key) == strings.ToLower(key) {
+			return m
+		}
+	}
+	return nil
+}
+
+// GetIssueTypeWithName returns an IssueType with name from a given MetaProject. If not found, this returns nil.
+// The comparison of the name is case insensitive
+func (p *MetaProject) GetIssueTypeWithName(name string) *MetaIssueType {
+	for _, m := range p.IssueTypes {
+		if strings.ToLower(m.Name) == strings.ToLower(name) {
+			return m
+		}
+	}
+	return nil
+}
+
+// GetMandatoryFields returns a map of all the required fields from the MetaIssueTypes.
+// if a field returned by the api was:
+// "customfield_10806": {
+//					"required": true,
+//					"schema": {
+//						"type": "any",
+//						"custom": "com.pyxis.greenhopper.jira:gh-epic-link",
+//						"customId": 10806
+//					},
+//					"name": "Epic Link",
+//					"hasDefaultValue": false,
+//					"operations": [
+//						"set"
+//					]
+//				}
+// the returned map would have "Epic Link" as the key and "customfield_10806" as value.
+// This choice has been made so that the it is easier to generate the create api request later.
+func (t *MetaIssueType) GetMandatoryFields() (map[string]string, error) {
+	ret := make(map[string]string)
+	for key := range t.Fields {
+		required, err := t.Fields.Bool(key + "/required")
+		if err != nil {
+			return nil, err
+		}
+		if required {
+			name, err := t.Fields.String(key + "/name")
+			if err != nil {
+				return nil, err
+			}
+			ret[name] = key
+		}
+	}
+	return ret, nil
+}
+
+// GetAllFields returns a map of all the fields for an IssueType. This includes all required and not required.
+// The key of the returned map is what you see in the form and the value is how it is representated in the jira schema.
+func (t *MetaIssueType) GetAllFields() (map[string]string, error) {
+	ret := make(map[string]string)
+	for key := range t.Fields {
+
+		name, err := t.Fields.String(key + "/name")
+		if err != nil {
+			return nil, err
+		}
+		ret[name] = key
+	}
+	return ret, nil
+}
+
+// CheckCompleteAndAvailable checks if the given fields satisfies the mandatory field required to create a issue for the given type
+// And also if the given fields are available.
+func (t *MetaIssueType) CheckCompleteAndAvailable(config map[string]string) (bool, error) {
+	mandatory, err := t.GetMandatoryFields()
+	if err != nil {
+		return false, err
+	}
+	all, err := t.GetAllFields()
+	if err != nil {
+		return false, err
+	}
+
+	// check templateconfig against mandatory fields
+	for key := range mandatory {
+		if _, okay := config[key]; !okay {
+			var requiredFields []string
+			for name := range mandatory {
+				requiredFields = append(requiredFields, name)
+			}
+			return false, fmt.Errorf("Required field not found in provided jira.fields. Required are: %#v", requiredFields)
+		}
+	}
+
+	// check templateConfig against all fields to verify they are available
+	for key := range config {
+		if _, okay := all[key]; !okay {
+			var availableFields []string
+			for name := range all {
+				availableFields = append(availableFields, name)
+			}
+			return false, fmt.Errorf("Fields in jira.fields are not available in jira. Available are: %#v", availableFields)
+		}
+	}
+
+	return true, nil
+}

vendor/github.com/andygrunwald/go-jira/project.go

@@ -0,0 +1,162 @@
+package jira
+
+import (
+	"fmt"
+
+	"github.com/google/go-querystring/query"
+)
+
+// ProjectService handles projects for the JIRA instance / API.
+//
+// JIRA API docs: https://docs.atlassian.com/jira/REST/latest/#api/2/project
+type ProjectService struct {
+	client *Client
+}
+
+// ProjectList represent a list of Projects
+type ProjectList []struct {
+	Expand          string          `json:"expand" structs:"expand"`
+	Self            string          `json:"self" structs:"self"`
+	ID              string          `json:"id" structs:"id"`
+	Key             string          `json:"key" structs:"key"`
+	Name            string          `json:"name" structs:"name"`
+	AvatarUrls      AvatarUrls      `json:"avatarUrls" structs:"avatarUrls"`
+	ProjectTypeKey  string          `json:"projectTypeKey" structs:"projectTypeKey"`
+	ProjectCategory ProjectCategory `json:"projectCategory,omitempty" structs:"projectsCategory,omitempty"`
+	IssueTypes      []IssueType     `json:"issueTypes,omitempty" structs:"issueTypes,omitempty"`
+}
+
+// ProjectCategory represents a single project category
+type ProjectCategory struct {
+	Self        string `json:"self" structs:"self,omitempty"`
+	ID          string `json:"id" structs:"id,omitempty"`
+	Name        string `json:"name" structs:"name,omitempty"`
+	Description string `json:"description" structs:"description,omitempty"`
+}
+
+// Project represents a JIRA Project.
+type Project struct {
+	Expand       string             `json:"expand,omitempty" structs:"expand,omitempty"`
+	Self         string             `json:"self,omitempty" structs:"self,omitempty"`
+	ID           string             `json:"id,omitempty" structs:"id,omitempty"`
+	Key          string             `json:"key,omitempty" structs:"key,omitempty"`
+	Description  string             `json:"description,omitempty" structs:"description,omitempty"`
+	Lead         User               `json:"lead,omitempty" structs:"lead,omitempty"`
+	Components   []ProjectComponent `json:"components,omitempty" structs:"components,omitempty"`
+	IssueTypes   []IssueType        `json:"issueTypes,omitempty" structs:"issueTypes,omitempty"`
+	URL          string             `json:"url,omitempty" structs:"url,omitempty"`
+	Email        string             `json:"email,omitempty" structs:"email,omitempty"`
+	AssigneeType string             `json:"assigneeType,omitempty" structs:"assigneeType,omitempty"`
+	Versions     []Version          `json:"versions,omitempty" structs:"versions,omitempty"`
+	Name         string             `json:"name,omitempty" structs:"name,omitempty"`
+	Roles        struct {
+		Developers string `json:"Developers,omitempty" structs:"Developers,omitempty"`
+	} `json:"roles,omitempty" structs:"roles,omitempty"`
+	AvatarUrls      AvatarUrls      `json:"avatarUrls,omitempty" structs:"avatarUrls,omitempty"`
+	ProjectCategory ProjectCategory `json:"projectCategory,omitempty" structs:"projectCategory,omitempty"`
+}
+
+// ProjectComponent represents a single component of a project
+type ProjectComponent struct {
+	Self                string `json:"self" structs:"self,omitempty"`
+	ID                  string `json:"id" structs:"id,omitempty"`
+	Name                string `json:"name" structs:"name,omitempty"`
+	Description         string `json:"description" structs:"description,omitempty"`
+	Lead                User   `json:"lead,omitempty" structs:"lead,omitempty"`
+	AssigneeType        string `json:"assigneeType" structs:"assigneeType,omitempty"`
+	Assignee            User   `json:"assignee" structs:"assignee,omitempty"`
+	RealAssigneeType    string `json:"realAssigneeType" structs:"realAssigneeType,omitempty"`
+	RealAssignee        User   `json:"realAssignee" structs:"realAssignee,omitempty"`
+	IsAssigneeTypeValid bool   `json:"isAssigneeTypeValid" structs:"isAssigneeTypeValid,omitempty"`
+	Project             string `json:"project" structs:"project,omitempty"`
+	ProjectID           int    `json:"projectId" structs:"projectId,omitempty"`
+}
+
+// PermissionScheme represents the permission scheme for the project
+type PermissionScheme struct {
+	Expand      string `json:"expand" structs:"expand,omitempty"`
+	Self        string `json:"self" structs:"self,omitempty"`
+	ID          int    `json:"id" structs:"id,omitempty"`
+	Name        string `json:"name" structs:"name,omitempty"`
+	Description string `json:"description" structs:"description,omitempty"`
+}
+
+// GetList gets all projects form JIRA
+//
+// JIRA API docs: https://docs.atlassian.com/jira/REST/latest/#api/2/project-getAllProjects
+func (s *ProjectService) GetList() (*ProjectList, *Response, error) {
+	return s.ListWithOptions(&GetQueryOptions{})
+}
+
+// ListWithOptions gets all projects form JIRA with optional query params, like &GetQueryOptions{Expand: "issueTypes"} to get
+// a list of all projects and their supported issuetypes
+//
+// JIRA API docs: https://docs.atlassian.com/jira/REST/latest/#api/2/project-getAllProjects
+func (s *ProjectService) ListWithOptions(options *GetQueryOptions) (*ProjectList, *Response, error) {
+	apiEndpoint := "rest/api/2/project"
+	req, err := s.client.NewRequest("GET", apiEndpoint, nil)
+	if err != nil {
+		return nil, nil, err
+	}
+
+	if options != nil {
+		q, err := query.Values(options)
+		if err != nil {
+			return nil, nil, err
+		}
+		req.URL.RawQuery = q.Encode()
+	}
+
+	projectList := new(ProjectList)
+	resp, err := s.client.Do(req, projectList)
+	if err != nil {
+		jerr := NewJiraError(resp, err)
+		return nil, resp, jerr
+	}
+
+	return projectList, resp, nil
+}
+
+// Get returns a full representation of the project for the given issue key.
+// JIRA will attempt to identify the project by the projectIdOrKey path parameter.
+// This can be an project id, or an project key.
+//
+// JIRA API docs: https://docs.atlassian.com/jira/REST/latest/#api/2/project-getProject
+func (s *ProjectService) Get(projectID string) (*Project, *Response, error) {
+	apiEndpoint := fmt.Sprintf("rest/api/2/project/%s", projectID)
+	req, err := s.client.NewRequest("GET", apiEndpoint, nil)
+	if err != nil {
+		return nil, nil, err
+	}
+
+	project := new(Project)
+	resp, err := s.client.Do(req, project)
+	if err != nil {
+		jerr := NewJiraError(resp, err)
+		return nil, resp, jerr
+	}
+
+	return project, resp, nil
+}
+
+// GetPermissionScheme returns a full representation of the permission scheme for the project
+// JIRA will attempt to identify the project by the projectIdOrKey path parameter.
+// This can be an project id, or an project key.
+//
+// JIRA API docs: https://docs.atlassian.com/jira/REST/latest/#api/2/project-getProject
+func (s *ProjectService) GetPermissionScheme(projectID string) (*PermissionScheme, *Response, error) {
+	apiEndpoint := fmt.Sprintf("/rest/api/2/project/%s/permissionscheme", projectID)
+	req, err := s.client.NewRequest("GET", apiEndpoint, nil)
+	if err != nil {
+		return nil, nil, err
+	}
+
+	ps := new(PermissionScheme)
+	resp, err := s.client.Do(req, ps)
+	if err != nil {
+		jerr := NewJiraError(resp, err)
+		return nil, resp, jerr
+	}
+
+	return ps, resp, nil
+}

vendor/github.com/andygrunwald/go-jira/sprint.go

@@ -0,0 +1,106 @@
+package jira
+
+import (
+	"fmt"
+	"github.com/google/go-querystring/query"
+)
+
+// SprintService handles sprints in JIRA Agile API.
+// See https://docs.atlassian.com/jira-software/REST/cloud/
+type SprintService struct {
+	client *Client
+}
+
+// IssuesWrapper represents a wrapper struct for moving issues to sprint
+type IssuesWrapper struct {
+	Issues []string `json:"issues"`
+}
+
+// IssuesInSprintResult represents a wrapper struct for search result
+type IssuesInSprintResult struct {
+	Issues []Issue `json:"issues"`
+}
+
+// MoveIssuesToSprint moves issues to a sprint, for a given sprint Id.
+// Issues can only be moved to open or active sprints.
+// The maximum number of issues that can be moved in one operation is 50.
+//
+// JIRA API docs: https://docs.atlassian.com/jira-software/REST/cloud/#agile/1.0/sprint-moveIssuesToSprint
+func (s *SprintService) MoveIssuesToSprint(sprintID int, issueIDs []string) (*Response, error) {
+	apiEndpoint := fmt.Sprintf("rest/agile/1.0/sprint/%d/issue", sprintID)
+
+	payload := IssuesWrapper{Issues: issueIDs}
+
+	req, err := s.client.NewRequest("POST", apiEndpoint, payload)
+
+	if err != nil {
+		return nil, err
+	}
+
+	resp, err := s.client.Do(req, nil)
+	if err != nil {
+		err = NewJiraError(resp, err)
+	}
+	return resp, err
+}
+
+// GetIssuesForSprint returns all issues in a sprint, for a given sprint Id.
+// This only includes issues that the user has permission to view.
+// By default, the returned issues are ordered by rank.
+//
+//  JIRA API Docs: https://docs.atlassian.com/jira-software/REST/cloud/#agile/1.0/sprint-getIssuesForSprint
+func (s *SprintService) GetIssuesForSprint(sprintID int) ([]Issue, *Response, error) {
+	apiEndpoint := fmt.Sprintf("rest/agile/1.0/sprint/%d/issue", sprintID)
+
+	req, err := s.client.NewRequest("GET", apiEndpoint, nil)
+
+	if err != nil {
+		return nil, nil, err
+	}
+
+	result := new(IssuesInSprintResult)
+	resp, err := s.client.Do(req, result)
+	if err != nil {
+		err = NewJiraError(resp, err)
+	}
+
+	return result.Issues, resp, err
+}
+
+// Get returns a full representation of the issue for the given issue key.
+// JIRA will attempt to identify the issue by the issueIdOrKey path parameter.
+// This can be an issue id, or an issue key.
+// If the issue cannot be found via an exact match, JIRA will also look for the issue in a case-insensitive way, or by looking to see if the issue was moved.
+//
+// The given options will be appended to the query string
+//
+// JIRA API docs: https://docs.atlassian.com/jira-software/REST/7.3.1/#agile/1.0/issue-getIssue
+//
+// TODO: create agile service for holding all agile apis' implementation
+func (s *SprintService) GetIssue(issueID string, options *GetQueryOptions) (*Issue, *Response, error) {
+	apiEndpoint := fmt.Sprintf("rest/agile/1.0/issue/%s", issueID)
+
+	req, err := s.client.NewRequest("GET", apiEndpoint, nil)
+
+	if err != nil {
+		return nil, nil, err
+	}
+
+	if options != nil {
+		q, err := query.Values(options)
+		if err != nil {
+			return nil, nil, err
+		}
+		req.URL.RawQuery = q.Encode()
+	}
+
+	issue := new(Issue)
+	resp, err := s.client.Do(req, issue)
+
+	if err != nil {
+		jerr := NewJiraError(resp, err)
+		return nil, resp, jerr
+	}
+
+	return issue, resp, nil
+}

vendor/github.com/andygrunwald/go-jira/user.go

@@ -0,0 +1,119 @@
+package jira
+
+import (
+	"encoding/json"
+	"fmt"
+	"io/ioutil"
+)
+
+// UserService handles users for the JIRA instance / API.
+//
+// JIRA API docs: https://docs.atlassian.com/jira/REST/cloud/#api/2/user
+type UserService struct {
+	client *Client
+}
+
+// User represents a JIRA user.
+type User struct {
+	Self            string     `json:"self,omitempty" structs:"self,omitempty"`
+	Name            string     `json:"name,omitempty" structs:"name,omitempty"`
+	Password        string     `json:"-"`
+	Key             string     `json:"key,omitempty" structs:"key,omitempty"`
+	EmailAddress    string     `json:"emailAddress,omitempty" structs:"emailAddress,omitempty"`
+	AvatarUrls      AvatarUrls `json:"avatarUrls,omitempty" structs:"avatarUrls,omitempty"`
+	DisplayName     string     `json:"displayName,omitempty" structs:"displayName,omitempty"`
+	Active          bool       `json:"active,omitempty" structs:"active,omitempty"`
+	TimeZone        string     `json:"timeZone,omitempty" structs:"timeZone,omitempty"`
+	ApplicationKeys []string   `json:"applicationKeys,omitempty" structs:"applicationKeys,omitempty"`
+}
+
+// UserGroup represents the group list
+type UserGroup struct {
+	Self string `json:"self,omitempty" structs:"self,omitempty"`
+	Name string `json:"name,omitempty" structs:"name,omitempty"`
+}
+
+// Get gets user info from JIRA
+//
+// JIRA API docs: https://docs.atlassian.com/jira/REST/cloud/#api/2/user-getUser
+func (s *UserService) Get(username string) (*User, *Response, error) {
+	apiEndpoint := fmt.Sprintf("/rest/api/2/user?username=%s", username)
+	req, err := s.client.NewRequest("GET", apiEndpoint, nil)
+	if err != nil {
+		return nil, nil, err
+	}
+
+	user := new(User)
+	resp, err := s.client.Do(req, user)
+	if err != nil {
+		return nil, resp, NewJiraError(resp, err)
+	}
+	return user, resp, nil
+}
+
+// Create creates an user in JIRA.
+//
+// JIRA API docs: https://docs.atlassian.com/jira/REST/cloud/#api/2/user-createUser
+func (s *UserService) Create(user *User) (*User, *Response, error) {
+	apiEndpoint := "/rest/api/2/user"
+	req, err := s.client.NewRequest("POST", apiEndpoint, user)
+	if err != nil {
+		return nil, nil, err
+	}
+
+	resp, err := s.client.Do(req, nil)
+	if err != nil {
+		return nil, resp, err
+	}
+
+	responseUser := new(User)
+	defer resp.Body.Close()
+	data, err := ioutil.ReadAll(resp.Body)
+	if err != nil {
+		e := fmt.Errorf("Could not read the returned data")
+		return nil, resp, NewJiraError(resp, e)
+	}
+	err = json.Unmarshal(data, responseUser)
+	if err != nil {
+		e := fmt.Errorf("Could not unmarshall the data into struct")
+		return nil, resp, NewJiraError(resp, e)
+	}
+	return responseUser, resp, nil
+}
+
+// GetGroups returns the groups which the user belongs to
+//
+// JIRA API docs: https://docs.atlassian.com/jira/REST/cloud/#api/2/user-getUserGroups
+func (s *UserService) GetGroups(username string) (*[]UserGroup, *Response, error) {
+	apiEndpoint := fmt.Sprintf("/rest/api/2/user/groups?username=%s", username)
+	req, err := s.client.NewRequest("GET", apiEndpoint, nil)
+	if err != nil {
+		return nil, nil, err
+	}
+
+	userGroups := new([]UserGroup)
+	resp, err := s.client.Do(req, userGroups)
+	if err != nil {
+		return nil, resp, NewJiraError(resp, err)
+	}
+	return userGroups, resp, nil
+}
+
+// Find searches for user info from JIRA:
+// It can find users by email, username or name
+//
+// JIRA API docs: https://docs.atlassian.com/jira/REST/cloud/#api/2/user-findUsers
+func (s *UserService) Find(property string) ([]User, *Response, error) {
+	apiEndpoint := fmt.Sprintf("/rest/api/2/user/search?username=%s", property)
+	req, err := s.client.NewRequest("GET", apiEndpoint, nil)
+	if err != nil {
+		return nil, nil, err
+	}
+
+	users := []User{}
+	resp, err := s.client.Do(req, &users)
+	if err != nil {
+		return nil, resp, NewJiraError(resp, err)
+	}
+	return users, resp, nil
+}

vendor/github.com/andygrunwald/go-jira/version.go

@@ -0,0 +1,96 @@
+package jira
+
+import (
+	"encoding/json"
+	"fmt"
+	"io/ioutil"
+)
+
+// VersionService handles Versions for the JIRA instance / API.
+//
+// JIRA API docs: https://docs.atlassian.com/jira/REST/latest/#api/2/version
+type VersionService struct {
+	client *Client
+}
+
+// Version represents a single release version of a project
+type Version struct {
+	Self            string `json:"self,omitempty" structs:"self,omitempty"`
+	ID              string `json:"id,omitempty" structs:"id,omitempty"`
+	Name            string `json:"name,omitempty" structs:"name,omitempty"`
+	Description     string `json:"description,omitempty" structs:"name,omitempty"`
+	Archived        bool   `json:"archived,omitempty" structs:"archived,omitempty"`
+	Released        bool   `json:"released,omitempty" structs:"released,omitempty"`
+	ReleaseDate     string `json:"releaseDate,omitempty" structs:"releaseDate,omitempty"`
+	UserReleaseDate string `json:"userReleaseDate,omitempty" structs:"userReleaseDate,omitempty"`
+	ProjectID       int    `json:"projectId,omitempty" structs:"projectId,omitempty"` // Unlike other IDs, this is returned as a number
+}
+
+// Get gets version info from JIRA
+//
+// JIRA API docs: https://developer.atlassian.com/cloud/jira/platform/rest/#api-api-2-version-id-get
+func (s *VersionService) Get(versionID int) (*Version, *Response, error) {
+	apiEndpoint := fmt.Sprintf("/rest/api/2/version/%v", versionID)
+	req, err := s.client.NewRequest("GET", apiEndpoint, nil)
+	if err != nil {
+		return nil, nil, err
+	}
+
+	version := new(Version)
+	resp, err := s.client.Do(req, version)
+	if err != nil {
+		return nil, resp, NewJiraError(resp, err)
+	}
+	return version, resp, nil
+}
+
+// Create creates a version in JIRA.
+//
+// JIRA API docs: https://developer.atlassian.com/cloud/jira/platform/rest/#api-api-2-version-post
+func (s *VersionService) Create(version *Version) (*Version, *Response, error) {
+	apiEndpoint := "/rest/api/2/version"
+	req, err := s.client.NewRequest("POST", apiEndpoint, version)
+	if err != nil {
+		return nil, nil, err
+	}
+
+	resp, err := s.client.Do(req, nil)
+	if err != nil {
+		return nil, resp, err
+	}
+
+	responseVersion := new(Version)
+	defer resp.Body.Close()
+	data, err := ioutil.ReadAll(resp.Body)
+	if err != nil {
+		e := fmt.Errorf("Could not read the returned data")
+		return nil, resp, NewJiraError(resp, e)
+	}
+	err = json.Unmarshal(data, responseVersion)
+	if err != nil {
+		e := fmt.Errorf("Could not unmarshall the data into struct")
+		return nil, resp, NewJiraError(resp, e)
+	}
+	return responseVersion, resp, nil
+}
+
+// Update updates a version from a JSON representation.
+//
+// JIRA API docs: https://developer.atlassian.com/cloud/jira/platform/rest/#api-api-2-version-id-put
+func (s *VersionService) Update(version *Version) (*Version, *Response, error) {
+	apiEndpoint := fmt.Sprintf("rest/api/2/version/%v", version.ID)
+	req, err := s.client.NewRequest("PUT", apiEndpoint, version)
+	if err != nil {
+		return nil, nil, err
+	}
+	resp, err := s.client.Do(req, nil)
+	if err != nil {
+		jerr := NewJiraError(resp, err)
+		return nil, resp, jerr
+	}
+
+	// This is just to follow the rest of the API's convention of returning a version.
+	// Returning the same pointer here is pointless, so we return a copy instead.
+	ret := *version
+	return &ret, resp, nil
+}

vendor/github.com/fatih/structs/.gitignore

@@ -0,0 +1,23 @@
+# Compiled Object files, Static and Dynamic libs (Shared Objects)
+*.o
+*.a
+*.so
+
+# Folders
+_obj
+_test
+
+# Architecture specific extensions/prefixes
+*.[568vq]
+[568vq].out
+
+*.cgo1.go
+*.cgo2.c
+_cgo_defun.c
+_cgo_gotypes.go
+_cgo_export.*
+
+_testmain.go
+
+*.exe
+*.test

vendor/github.com/fatih/structs/.travis.yml

@@ -0,0 +1,11 @@
+language: go
+go: 
+ - 1.7.x
+ - tip
+sudo: false
+before_install:
+- go get github.com/axw/gocov/gocov
+- go get github.com/mattn/goveralls
+- if ! go get github.com/golang/tools/cmd/cover; then go get golang.org/x/tools/cmd/cover; fi
+script:
+- $HOME/gopath/bin/goveralls -service=travis-ci

vendor/github.com/fatih/structs/LICENSE

@@ -0,0 +1,21 @@
+The MIT License (MIT)
+
+Copyright (c) 2014 Fatih Arslan
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

vendor/github.com/fatih/structs/README.md

@@ -0,0 +1,163 @@
+# Structs [![GoDoc](http://img.shields.io/badge/go-documentation-blue.svg?style=flat-square)](http://godoc.org/github.com/fatih/structs) [![Build Status](http://img.shields.io/travis/fatih/structs.svg?style=flat-square)](https://travis-ci.org/fatih/structs) [![Coverage Status](http://img.shields.io/coveralls/fatih/structs.svg?style=flat-square)](https://coveralls.io/r/fatih/structs)
+
+Structs contains various utilities to work with Go (Golang) structs. It was
+initially used by me to convert a struct into a `map[string]interface{}`. With
+time I've added other utilities for structs.  It's basically a high level
+package based on primitives from the reflect package. Feel free to add new
+functions or improve the existing code.
+
+## Install
+
+```bash
+go get github.com/fatih/structs
+```
+
+## Usage and Examples
+
+Just like the standard lib `strings`, `bytes` and co packages, `structs` has
+many global functions to manipulate or organize your struct data. Lets define
+and declare a struct:
+
+```go
+type Server struct {
+	Name        string `json:"name,omitempty"`
+	ID          int
+	Enabled     bool
+	users       []string // not exported
+	http.Server          // embedded
+}
+
+server := &Server{
+	Name:    "gopher",
+	ID:      123456,
+	Enabled: true,
+}
+```
+
+```go
+// Convert a struct to a map[string]interface{}
+// => {"Name":"gopher", "ID":123456, "Enabled":true}
+m := structs.Map(server)
+
+// Convert the values of a struct to a []interface{}
+// => ["gopher", 123456, true]
+v := structs.Values(server)
+
+// Convert the names of a struct to a []string
+// (see "Names methods" for more info about fields)
+n := structs.Names(server)
+
+// Convert the values of a struct to a []*Field
+// (see "Field methods" for more info about fields)
+f := structs.Fields(server)
+
+// Return the struct name => "Server"
+n := structs.Name(server)
+
+// Check if any field of a struct is initialized or not.
+h := structs.HasZero(server)
+
+// Check if all fields of a struct is initialized or not.
+z := structs.IsZero(server)
+
+// Check if server is a struct or a pointer to struct
+i := structs.IsStruct(server)
+```
+
+### Struct methods
+
+The structs functions can be also used as independent methods by creating a new
+`*structs.Struct`. This is handy if you want to have more control over the
+structs (such as retrieving a single Field).
+
+```go
+// Create a new struct type:
+s := structs.New(server)
+
+m := s.Map()              // Get a map[string]interface{}
+v := s.Values()           // Get a []interface{}
+f := s.Fields()           // Get a []*Field
+n := s.Names()            // Get a []string
+f := s.Field(name)        // Get a *Field based on the given field name
+f, ok := s.FieldOk(name)  // Get a *Field based on the given field name
+n := s.Name()             // Get the struct name
+h := s.HasZero()          // Check if any field is initialized
+z := s.IsZero()           // Check if all fields are initialized
+```
+
+### Field methods
+
+We can easily examine a single Field for more detail. Below you can see how we
+get and interact with various field methods:
+
+
+```go
+s := structs.New(server)
+
+// Get the Field struct for the "Name" field
+name := s.Field("Name")
+
+// Get the underlying value,  value => "gopher"
+value := name.Value().(string)
+
+// Set the field's value
+name.Set("another gopher")
+
+// Get the field's kind, kind =>  "string"
+name.Kind()
+
+// Check if the field is exported or not
+if name.IsExported() {
+	fmt.Println("Name field is exported")
+}
+
+// Check if the value is a zero value, such as "" for string, 0 for int
+if !name.IsZero() {
+	fmt.Println("Name is initialized")
+}
+
+// Check if the field is an anonymous (embedded) field
+if !name.IsEmbedded() {
+	fmt.Println("Name is not an embedded field")
+}
+
+// Get the Field's tag value for tag name "json", tag value => "name,omitempty"
+tagValue := name.Tag("json")
+```
+
+Nested structs are supported too:
+
+```go
+addrField := s.Field("Server").Field("Addr")
+
+// Get the value for addr
+a := addrField.Value().(string)
+
+// Or get all fields
+httpServer := s.Field("Server").Fields()
+```
+
+We can also get a slice of Fields from the Struct type to iterate over all
+fields. This is handy if you wish to examine all fields:
+
+```go
+s := structs.New(server)
+
+for _, f := range s.Fields() {
+	fmt.Printf("field name: %+v\n", f.Name())
+
+	if f.IsExported() {
+		fmt.Printf("value   : %+v\n", f.Value())
+		fmt.Printf("is zero : %+v\n", f.IsZero())
+	}
+}
+```
+
+## Credits
+
+ * [Fatih Arslan](https://github.com/fatih)
+ * [Cihangir Savas](https://github.com/cihangir)
+
+## License
+
+The MIT License (MIT) - see LICENSE.md for more details

vendor/github.com/fatih/structs/field.go

@@ -0,0 +1,141 @@
+package structs
+
+import (
+	"errors"
+	"fmt"
+	"reflect"
+)
+
+var (
+	errNotExported = errors.New("field is not exported")
+	errNotSettable = errors.New("field is not settable")
+)
+
+// Field represents a single struct field that encapsulates high level
+// functions around the field.
+type Field struct {
+	value      reflect.Value
+	field      reflect.StructField
+	defaultTag string
+}
+
+// Tag returns the value associated with key in the tag string. If there is no
+// such key in the tag, Tag returns the empty string.
+func (f *Field) Tag(key string) string {
+	return f.field.Tag.Get(key)
+}
+
+// Value returns the underlying value of the field. It panics if the field
+// is not exported.
+func (f *Field) Value() interface{} {
+	return f.value.Interface()
+}
+
+// IsEmbedded returns true if the given field is an anonymous field (embedded)
+func (f *Field) IsEmbedded() bool {
+	return f.field.Anonymous
+}
+
+// IsExported returns true if the given field is exported.
+func (f *Field) IsExported() bool {
+	return f.field.PkgPath == ""
+}
+
+// IsZero returns true if the given field is not initialized (has a zero value).
+// It panics if the field is not exported.
+func (f *Field) IsZero() bool {
+	zero := reflect.Zero(f.value.Type()).Interface()
+	current := f.Value()
+
+	return reflect.DeepEqual(current, zero)
+}
+
+// Name returns the name of the given field
+func (f *Field) Name() string {
+	return f.field.Name
+}
+
+// Kind returns the fields kind, such as "string", "map", "bool", etc ..
+func (f *Field) Kind() reflect.Kind {
+	return f.value.Kind()
+}
+
+// Set sets the field to given value v. It returns an error if the field is not
+// settable (not addressable or not exported) or if the given value's type
+// doesn't match the fields type.
+func (f *Field) Set(val interface{}) error {
+	// we can't set unexported fields, so be sure this field is exported
+	if !f.IsExported() {
+		return errNotExported
+	}
+
+	// do we get here? not sure...
+	if !f.value.CanSet() {
+		return errNotSettable
+	}
+
+	given := reflect.ValueOf(val)
+
+	if f.value.Kind() != given.Kind() {
+		return fmt.Errorf("wrong kind. got: %s want: %s", given.Kind(), f.value.Kind())
+	}
+
+	f.value.Set(given)
+	return nil
+}
+
+// Zero sets the field to its zero value. It returns an error if the field is not
+// settable (not addressable or not exported).
+func (f *Field) Zero() error {
+	zero := reflect.Zero(f.value.Type()).Interface()
+	return f.Set(zero)
+}
+
+// Fields returns a slice of Fields. This is particular handy to get the fields
+// of a nested struct . A struct tag with the content of "-" ignores the
+// checking of that particular field. Example:
+//
+//   // Field is ignored by this package.
+//   Field *http.Request `structs:"-"`
+//
+// It panics if field is not exported or if field's kind is not struct
+func (f *Field) Fields() []*Field {
+	return getFields(f.value, f.defaultTag)
+}
+
+// Field returns the field from a nested struct. It panics if the nested struct
+// is not exported or if the field was not found.
+func (f *Field) Field(name string) *Field {
+	field, ok := f.FieldOk(name)
+	if !ok {
+		panic("field not found")
+	}
+
+	return field
+}
+
+// FieldOk returns the field from a nested struct. The boolean returns whether
+// the field was found (true) or not (false).
+func (f *Field) FieldOk(name string) (*Field, bool) {
+	value := &f.value
+	// value must be settable so we need to make sure it holds the address of the
+	// variable and not a copy, so we can pass the pointer to strctVal instead of a
+	// copy (which is not assigned to any variable, hence not settable).
+	// see "https://blog.golang.org/laws-of-reflection#TOC_8."
+	if f.value.Kind() != reflect.Ptr {
+		a := f.value.Addr()
+		value = &a
+	}
+	v := strctVal(value.Interface())
+	t := v.Type()
+
+	field, ok := t.FieldByName(name)
+	if !ok {
+		return nil, false
+	}
+
+	return &Field{
+		field: field,
+		value: v.FieldByName(name),
+	}, true
+}

vendor/github.com/fatih/structs/tags.go

@@ -0,0 +1,32 @@
+package structs
+
+import "strings"
+
+// tagOptions contains a slice of tag options
+type tagOptions []string
+
+// Has returns true if the given optiton is available in tagOptions
+func (t tagOptions) Has(opt string) bool {
+	for _, tagOpt := range t {
+		if tagOpt == opt {
+			return true
+		}
+	}
+
+	return false
+}
+
+// parseTag splits a struct field's tag into its name and a list of options
+// which comes after a name. A tag is in the form of: "name,option1,option2".
+// The name can be neglectected.
+func parseTag(tag string) (string, tagOptions) {
+	// tag is one of followings:
+	// ""
+	// "name"
+	// "name,opt"
+	// "name,opt,opt2"
+	// ",opt"
+
+	res := strings.Split(tag, ",")
+	return res[0], res[1:]
+}

vendor/github.com/trivago/tgo/LICENSE

@@ -0,0 +1,202 @@
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "{}"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright {yyyy} {name of copyright owner}
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.
+