mirror of
https://github.com/strongdm/comply
synced 2024-07-02 23:14:22 +00:00
Merge branch 'master' of github.com:strongdm/comply
This commit is contained in:
Manisha Singh
commit
fdc8038c95
|
|
@ -13,11 +13,15 @@ html lang=en
|
|||
= javascript
|
||||
document.addEventListener("DOMContentLoaded", function(event) {
|
||||
document.querySelectorAll('.cron').forEach(function(el) {
|
||||
el.innerHTML = prettyCron.toString(el.innerHTML)
|
||||
el.innerHTML = prettyCron.toString((""+el.innerHTML).trim(),true) // 6-field expressions
|
||||
})
|
||||
})
|
||||
|
||||
function show(name) {
|
||||
if (history.replaceState) {
|
||||
history.replaceState(null, null, '#'+name)
|
||||
}
|
||||
|
||||
var items = document.getElementsByClassName('top-nav')
|
||||
for (var i=0; i<items.length; i++) {
|
||||
var item = items[i]
|
||||
|
|
@ -220,5 +224,14 @@ html lang=en
|
|||
.content.has-text-centered
|
||||
p {{.Project.OrganizationName}} Confidential 2018
|
||||
= javascript
|
||||
// commented for development
|
||||
show('overview')
|
||||
if (window.location.hash=="") {
|
||||
show('overview')
|
||||
} else {
|
||||
var hashComponents = window.location.hash.split('#')
|
||||
if (hashComponents.length>1) {
|
||||
var destination = hashComponents[1]
|
||||
if (["overview","narratives","policies","procedures","standards"].indexOf(destination) >= 0) {
|
||||
show(destination)
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
@ -44,6 +44,7 @@ func newApp() *cli.App {
|
|||
}
|
||||
|
||||
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))
|
||||
|
|
|
|||
44
internal/cli/procedure.go
Normal file
44
internal/cli/procedure.go
Normal file
|
|
@ -0,0 +1,44 @@
|
|||
package cli
|
||||
|
||||
import (
|
||||
"fmt"
|
||||
|
||||
"github.com/strongdm/comply/internal/model"
|
||||
"github.com/urfave/cli"
|
||||
)
|
||||
|
||||
var procedureCommand = cli.Command{
|
||||
Name: "procedure",
|
||||
ShortName: "proc",
|
||||
Usage: "create ticket by procedure ID",
|
||||
ArgsUsage: "procedureID",
|
||||
Action: procedureAction,
|
||||
Before: projectMustExist,
|
||||
}
|
||||
|
||||
func procedureAction(c *cli.Context) error {
|
||||
procedures, err := model.ReadProcedures()
|
||||
if err != nil {
|
||||
return err
|
||||
}
|
||||
|
||||
if c.NArg() != 1 {
|
||||
return cli.NewExitError("provide a procedure ID", 1)
|
||||
}
|
||||
|
||||
procedureID := c.Args().First()
|
||||
|
||||
for _, procedure := range procedures {
|
||||
if procedure.ID == procedureID {
|
||||
// TODO: don't hardcode GH
|
||||
tp := model.GetPlugin(model.GitHub)
|
||||
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 nil
|
||||
}
|
||||
}
|
||||
|
||||
return cli.NewExitError(fmt.Sprintf("unknown procedure ID: %s", procedureID), 1)
|
||||
}
|
||||
|
|
@ -9,6 +9,7 @@ import (
|
|||
"sync"
|
||||
|
||||
"github.com/pkg/errors"
|
||||
"github.com/skratchdot/open-golang/open"
|
||||
"github.com/yosssi/ace"
|
||||
)
|
||||
|
||||
|
|
@ -22,13 +23,15 @@ const websocketReloader = `<script>
|
|||
ws.onclose = function(e) {
|
||||
// reload!
|
||||
if (connected) {
|
||||
window.location=window.location
|
||||
window.location.reload(true)
|
||||
}
|
||||
}
|
||||
})()
|
||||
</script>`
|
||||
|
||||
func html(output string, live bool, errCh chan error, wg *sync.WaitGroup) {
|
||||
opened := false
|
||||
|
||||
for {
|
||||
files, err := ioutil.ReadDir(filepath.Join(".", "templates"))
|
||||
if err != nil {
|
||||
|
|
@ -56,9 +59,7 @@ func html(output string, live bool, errCh chan error, wg *sync.WaitGroup) {
|
|||
return
|
||||
}
|
||||
|
||||
if live {
|
||||
fmt.Printf("%s -> %s\n", filepath.Join("templates", fileInfo.Name()), outputFilename)
|
||||
}
|
||||
fmt.Printf("%s -> %s\n", filepath.Join("templates", fileInfo.Name()), outputFilename)
|
||||
|
||||
tpl, err := ace.Load("", filepath.Join("templates", basename), aceOpts)
|
||||
if err != nil {
|
||||
|
|
@ -77,10 +78,17 @@ func html(output string, live bool, errCh chan error, wg *sync.WaitGroup) {
|
|||
}
|
||||
w.Close()
|
||||
}
|
||||
if !live {
|
||||
|
||||
if live {
|
||||
if !opened {
|
||||
opened = true
|
||||
open.Run("output/index.html")
|
||||
}
|
||||
} else {
|
||||
wg.Done()
|
||||
return
|
||||
}
|
||||
|
||||
<-subscribe()
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -49,14 +49,6 @@ func renderNarrativeToDisk(wg *sync.WaitGroup, errOutputCh chan error, data *ren
|
|||
go func(p *model.Narrative) {
|
||||
defer wg.Done()
|
||||
|
||||
if live {
|
||||
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))
|
||||
}
|
||||
|
||||
outputFilename := p.OutputFilename
|
||||
// save preprocessed markdown
|
||||
err = preprocessNarrative(data, p, filepath.Join(".", "output", outputFilename+".md"))
|
||||
|
|
@ -112,6 +104,13 @@ func renderNarrativeToDisk(wg *sync.WaitGroup, errOutputCh chan error, data *ren
|
|||
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)
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -49,14 +49,6 @@ func renderPolicyToDisk(wg *sync.WaitGroup, errOutputCh chan error, data *render
|
|||
go func(p *model.Policy) {
|
||||
defer wg.Done()
|
||||
|
||||
if live {
|
||||
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))
|
||||
}
|
||||
|
||||
outputFilename := p.OutputFilename
|
||||
// save preprocessed markdown
|
||||
err = preprocessPolicy(data, p, filepath.Join(".", "output", outputFilename+".md"))
|
||||
|
|
@ -110,6 +102,12 @@ func renderPolicyToDisk(wg *sync.WaitGroup, errOutputCh chan error, data *render
|
|||
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))
|
||||
}(policy)
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,6 @@ import (
|
|||
|
||||
"github.com/gorilla/websocket"
|
||||
"github.com/pkg/errors"
|
||||
"github.com/skratchdot/open-golang/open"
|
||||
"github.com/yosssi/ace"
|
||||
)
|
||||
|
||||
|
|
@ -103,10 +102,6 @@ func Build(output string, live bool) error {
|
|||
close(wgCh)
|
||||
}()
|
||||
|
||||
if live {
|
||||
open.Run("output/index.html")
|
||||
}
|
||||
|
||||
select {
|
||||
case <-wgCh:
|
||||
// success
|
||||
|
|
|
|||
File diff suppressed because one or more lines are too long
|
|
@ -98,6 +98,8 @@ func TriggerScheduled() error {
|
|||
}
|
||||
|
||||
func trigger(procedure *model.Procedure) {
|
||||
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{
|
||||
|
|
|
|||
|
|
@ -13,11 +13,15 @@ html lang=en
|
|||
= javascript
|
||||
document.addEventListener("DOMContentLoaded", function(event) {
|
||||
document.querySelectorAll('.cron').forEach(function(el) {
|
||||
el.innerHTML = prettyCron.toString(el.innerHTML)
|
||||
el.innerHTML = prettyCron.toString((""+el.innerHTML).trim(),true) // 6-field expressions
|
||||
})
|
||||
})
|
||||
|
||||
function show(name) {
|
||||
if (history.replaceState) {
|
||||
history.replaceState(null, null, '#'+name)
|
||||
}
|
||||
|
||||
var items = document.getElementsByClassName('top-nav')
|
||||
for (var i=0; i<items.length; i++) {
|
||||
var item = items[i]
|
||||
|
|
@ -220,5 +224,14 @@ html lang=en
|
|||
.content.has-text-centered
|
||||
p {{.Project.OrganizationName}} Confidential 2018
|
||||
= javascript
|
||||
// commented for development
|
||||
show('overview')
|
||||
if (window.location.hash=="") {
|
||||
show('overview')
|
||||
} else {
|
||||
var hashComponents = window.location.hash.split('#')
|
||||
if (hashComponents.length>1) {
|
||||
var destination = hashComponents[1]
|
||||
if (["overview","narratives","policies","procedures","standards"].indexOf(destination) >= 0) {
|
||||
show(destination)
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
@ -9,7 +9,6 @@ satisfies:
|
|||
- CC3.1
|
||||
- CC3.2
|
||||
- CC3.3
|
||||
- CC3.4
|
||||
majorRevisions:
|
||||
- date: Jun 1 2018
|
||||
comment: Initial document
|
||||
|
|
|
|||
|
|
@ -3,9 +3,49 @@ acronym: SCP
|
|||
satisfies:
|
||||
TSC:
|
||||
- CC8.1
|
||||
- CC3.4
|
||||
majorRevisions:
|
||||
- date: Jun 1 2018
|
||||
comment: Initial document
|
||||
---
|
||||
|
||||
# Coming Soon
|
||||
# Purpose and Scope
|
||||
|
||||
a. This information security policy defines how changes to information systems are planned and implemented
|
||||
|
||||
a. This policy applies to the entire information security program at the organization (i.e. to all information and communications technology, as well as related documentation).
|
||||
|
||||
a. All employees, contractors, part-time and temporary workers, service providers, and those employed by others to perform work for the organization, or who have been granted to the organization’s information and communications technology, must comply with this policy.
|
||||
|
||||
# Background
|
||||
|
||||
a. This policy defines specific requirements to ensure that changes to systems and applications are properly planned, evaluated, reviewed, approved, communicated, implemented, documented, and reviewed, thereby ensuring the greatest probability of success. Where changes are not successful, this document provides mechanisms for conducting post-implementation review such that future mistakes and errors can be prevented.
|
||||
|
||||
# Policy
|
||||
|
||||
a. Any changes to the security architecture or customer data handling of a system must be formally requested in writing to the organization’s Information Security Manager (ISM), and approved by the ISM and the Chief Information Officer (CIO).
|
||||
|
||||
a. All change requests must be documented.
|
||||
|
||||
a. All change requests must be prioritized in terms of benefits, urgency, effort required, and potential impacts to the organization’s operations.
|
||||
|
||||
a. All implemented changes must be communicated to relevant users.
|
||||
|
||||
a. Change management must be conducted according to the following procedure:
|
||||
|
||||
i. *Planning*: plan the change, including the implementation design, scheduling, and implementation of a communications plan, testing plan, and roll-back plan.
|
||||
|
||||
i. *Evaluation*: evaluate the change, including priority level of the service and risk that the proposed change introduces to the system; determine the change type and the specific step-by-step process to implement the change.
|
||||
|
||||
i. *Review*: review the change plan amongst the CIO, ISM, Engineering Lead, and, if applicable, Business Unit Manager.
|
||||
|
||||
i. *Approval*: the CIO must approve the change plan.
|
||||
|
||||
i. *Communication*: communicate the change to all users of the system.
|
||||
|
||||
i. *Implementation*: test and implement the change.
|
||||
|
||||
i. *Documentation*: record the change and any post-implementation issues.
|
||||
|
||||
i. *Post-change review*: conduct a post-implementation review to determine how the change is impacting the organization, either positively or negatively. Discuss and document any lessons learned.
|
||||
|
||||
|
|
|
|||
|
|
@ -8,4 +8,89 @@ majorRevisions:
|
|||
comment: Initial document
|
||||
---
|
||||
|
||||
# Coming Soon
|
||||
# Purpose and Scope
|
||||
|
||||
a. The purpose of this policy is to define expected behavior from employees towards their colleagues, supervisors, and the overall organization.
|
||||
|
||||
a. We expect all employees to follow our Code of Conduct. Offensive behavior, disruptive behavior, and participation in serious disputes should be avoided. Employees are expected to foster a respectful and collaborative environment.
|
||||
|
||||
a. This policy applies to all employees and contractors. They are bound by their Employment Offer Letter or Independent Contractor Agreement to follow the Code of Conduct Policy while performing their duties. The Code of Conduct is outlined below:
|
||||
|
||||
#Policy
|
||||
|
||||
a. *Compliance with law*
|
||||
|
||||
i. Employees should have an understanding of and comply with all environmental, safety, and fair dealing laws. When performing their job duty and dealing with the company’s products, finances, critical information, & public image, employees are expected to be ethical and responsible. If an employee is unsure of whether a contemplated action is permitted by law or Company policy, they should seek advice from the resource manager.
|
||||
|
||||
a. *Respect in the workplace*
|
||||
|
||||
i. Employees should respect their colleagues. Discriminatory behavior, harassment, or victimization will not be tolerated.
|
||||
|
||||
a. *Protection of company property*
|
||||
|
||||
i. Company property, both material or intangible, should be treated with respect and care. Employees and contractors:
|
||||
|
||||
1. Should not misuse company equipment
|
||||
|
||||
1. Should respect all intangible property, including trademarks, copyright, information, reports, and other property. These materials should be used only to complete job duties.
|
||||
|
||||
1. Should protect company facilities and other material property from damage and vandalism, whenever possible.
|
||||
|
||||
\pagebreak
|
||||
|
||||
a. *Personal appearance*
|
||||
|
||||
i. When in the workplace, employees must present themselves in an appropriate & professional manner. They should abide by the company dress code.
|
||||
|
||||
a. *Corruption*
|
||||
|
||||
i. Employees are discouraged from accepting gifts from clients or partners. Briberies are prohibited for the benefit of any external or internal party.
|
||||
|
||||
a. *Job duties and authority*
|
||||
|
||||
i. Employees should fulfill their job duties with integrity and respect towards all individuals involved.
|
||||
|
||||
i. Supervisors and managers may not use abuse their authority. Competency and workload should be taken into account when delegating duties to team members.
|
||||
|
||||
i. Team members are expected to follow their leaders’ instructions and complete their duties with thoughtfulness and in a timely manner.
|
||||
|
||||
a. *Absenteeism and tardiness*
|
||||
|
||||
i. Employees should be punctual when coming to and leaving from work and follow the schedule determined by their hiring manager. Exceptions can be made for occasions that prevent employees from following standard working hours or days, with approval from their hiring manager.
|
||||
|
||||
a. *Conflict of interest*
|
||||
|
||||
i. Employees should avoid any personal, financial, or other interests that might compete with their job duties.
|
||||
|
||||
a. *Collaboration*
|
||||
|
||||
i. Employees should be friendly with their colleagues and open to collaboration. They should not disrupt the workplace or present obstacles to their colleagues’ work.
|
||||
|
||||
a. *Communication*
|
||||
|
||||
i. Colleagues, supervisors, or team members must be open to communication amongst each other.
|
||||
|
||||
a. *Benefits*
|
||||
|
||||
i. We expect employees to not abuse their employment benefits. This can refer to time off, insurance, facilities, subscriptions, or other benefits our company offers. Refer to Human Resources for more information on benefits.
|
||||
|
||||
a. *Policies*
|
||||
|
||||
i. All employees must comply with company policies. Questions should be directed to their hiring managers and/or Human Resources.
|
||||
|
||||
a. *Disciplinary actions*
|
||||
|
||||
i. Repeated or intentional violation of the Code of Conduct Policy will be met with disciplinary action. Consequences will vary depending on the violation, but can include:
|
||||
|
||||
1. demotion
|
||||
1. reprimand
|
||||
1. suspension or termination
|
||||
1. detraction of benefits for a definite or indefinite time
|
||||
|
||||
ii. Cases of corruption, theft, embezzlement, or other unlawful behavior may call for legal action.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -9,4 +9,92 @@ majorRevisions:
|
|||
comment: Initial document
|
||||
---
|
||||
|
||||
# Coming Soon
|
||||
# Purpose and Scope
|
||||
|
||||
a. This policy outlines expected behavior of employees to keep confidential information about clients, partners, and our company secure.
|
||||
|
||||
a. This policy applies to all employees, board members, investors, and contractors, who may have access to confidential information. This policy must be made readily available to all whom it
|
||||
applies to.
|
||||
|
||||
# Background
|
||||
|
||||
a. The company's confidential information must be protected for two reasons:
|
||||
|
||||
i. It may be legally binding (i.e. sensitive customer data)
|
||||
|
||||
i. It may be fundamental to our business (i.e. business processes)
|
||||
|
||||
a. Common examples of confidential information in our company includes, but is not limited to:
|
||||
|
||||
i. Unpublished financial information
|
||||
|
||||
i. Customer/partner/vendor/external party data
|
||||
|
||||
i. Patents, formulas, new technologies, and other intellectual property
|
||||
|
||||
i. Existing and prospective customer lists
|
||||
|
||||
i. Undisclosed business strategies including pricing & marketing
|
||||
|
||||
i. Materials & processes explicitly marked as “confidential”
|
||||
|
||||
a. Employees will have varying levels of authorized access to confidential information.
|
||||
|
||||
# Policy
|
||||
|
||||
a. *Employee procedure for handling confidential information*
|
||||
|
||||
i. Lock and secure confidential information at all times
|
||||
|
||||
i. Safely dispose (i.e. shred) documents when no longer needed
|
||||
|
||||
i. View confidential information only on secure devices
|
||||
|
||||
i. Disclose information only when authorized and necessary
|
||||
|
||||
i. Do not use confidential information for personal gain, benefit, or profit
|
||||
|
||||
i. Do not disclose confidential information to anyone outside the company or to anyone within the company who does not have appropriate privileges
|
||||
|
||||
i. Do not store confidential information or replicates of confidential information in unsecured manners (i.e. on unsecured devices)
|
||||
|
||||
i. Do not remove confidential documents from company's premises unless absolutely necessary to move
|
||||
|
||||
a. *Offboarding measures*
|
||||
|
||||
i. The Hiring Manager should confirm the off-boarding procedure has been completed by final date of employment.
|
||||
|
||||
a. *Confidentiality measures*
|
||||
|
||||
i. The company will take the following measures to ensure protection of confidential information:
|
||||
|
||||
1. Store and lock paper documents
|
||||
|
||||
1. Encrypt electronic information and implement appropriate technical measures to safeguard databases
|
||||
|
||||
1. Require employees to sign non-disclosure/non-compete agreements
|
||||
|
||||
1. Consult with senior management before granting employees access to certain confidential information
|
||||
|
||||
a. *Exceptions*
|
||||
|
||||
i. Under certain legitimate conditions, confidential information may need to be disclosed. Examples include:
|
||||
|
||||
1. If a regulatory agency requests information as part of an audit or investigation
|
||||
|
||||
1. If the company requires disclosing information (within legal bounds) as part of a venture or partnership
|
||||
|
||||
i. In such cases, employee must request and receive prior written authorization from their hiring manager before disclosing confidential information to any third parties.
|
||||
|
||||
a. *Disciplinary consequences*
|
||||
|
||||
i. Employees who violate the confidentiality policy will face disciplinary and possible legal action.
|
||||
|
||||
i. A suspected breach of this policy will trigger an investigation. Intentional violations will be met with termination and repeated unintentional violations may also face termination.
|
||||
|
||||
i. This policy is binding even after the termination of employment.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -8,4 +8,89 @@ majorRevisions:
|
|||
comment: Initial document
|
||||
---
|
||||
|
||||
# Coming Soon
|
||||
|
||||
# Purpose and Scope
|
||||
|
||||
a. The purpose of this policy is to ensure that the organization establishes objectives, plans and, procedures such that a major disruption to the organization’s key business activities is minimized.
|
||||
|
||||
a. This policy applies to all infrastructure and data within the organization’s information security program.
|
||||
|
||||
a. This policy applies to all management, employees, and suppliers that are involved in decisions and processes affecting the organization’s business continuity. This policy must be made readily available to all whom it applies to.
|
||||
|
||||
# Background
|
||||
|
||||
a. The success of the organization is reliant upon the preservation of critical business operations and essential functions used to deliver key products and services. The purpose of this policy is to define the criteria for continuing business operations for the organization in the event of a disruption. Specifically, this document defines:
|
||||
|
||||
i. The structure and authority to ensure business resilience of key processes and systems.
|
||||
|
||||
i. The requirements for efforts to manage through a disaster or other disruptive event when the need arises.
|
||||
|
||||
i. The criteria to efficiently and effectively resume normal business operations after a disruption.
|
||||
|
||||
a. Within this document, the following definitions apply:
|
||||
|
||||
i. *Business impact analysis/assessment* - an exercise that determines the impact of losing the support of any resource to an enterprise, establishes the escalation of that loss over time, identifies the minimum resources needed to return to a normal level of operation, and prioritizes recovery of processes and the supporting system.
|
||||
|
||||
i. *Disaster recovery plan* - a set of human, physical, technical, and procedural resources to return to a normal level of operation, within a defined time and cost, when an activity is interrupted by an emergency or disaster.
|
||||
|
||||
i. *Recovery time objective* - the amount of time allowed for the recovery of a business function or resource to a normal level after a disaster or disruption occurs.
|
||||
|
||||
i. *Recovery point objective* - determined based on the acceptable data loss in the case of disruption of operations.
|
||||
|
||||
# Policy
|
||||
|
||||
a. *Business Risk Assessment and Business Impact Analysis*
|
||||
|
||||
i. Each manager is required to perform a business risk assessment and business impact analysis for each key business system within their area of responsibility.
|
||||
|
||||
i. The business risk assessment must identify and define the criticality of key business systems and the repositories that contain the relevant and necessary data for the key business system.
|
||||
|
||||
i. The business risk assessment must define and document the Disaster Recovery Plan (DRP) for their area of responsibility. Each DRP shall include:
|
||||
|
||||
1. Key business processes.
|
||||
|
||||
1. Applicable risk to availability.
|
||||
|
||||
1. Prioritization of recovery.
|
||||
|
||||
1. Recovery Time Objectives (RTOs).
|
||||
|
||||
1. Recovery Point Objectives (RPOs).
|
||||
|
||||
a. *Disaster Recovery Plan*
|
||||
|
||||
i. Each key business system must have a documented DRP to provide guidance when hardware, software, or networks become critically dysfunctional or cease to function (short and long term outages).
|
||||
|
||||
i. Each DRP must include an explanation of the magnitude of information or system unavailability in the event of an outage and the process that would be implemented to continue business operations during the outage. Where feasible, the DRP must consider the use of alternative, off-site computer operations (cold, warm, hot sites).
|
||||
|
||||
i. Each plan must be reviewed against the organization’s strategy, objectives, culture, and ethics, as well as policy, legal, statutory and regulatory requirements.
|
||||
|
||||
i. Each DRP must include:
|
||||
|
||||
1. An emergency mode operations plan for continuing operations in the event of temporary hardware, software, or network outages.
|
||||
|
||||
1. A recovery plan for returning business functions and services to normal on-site operations.
|
||||
|
||||
1. Procedures for periodic testing, review, and revisions of the DRP for all affected business systems, as a group and/or individually.
|
||||
|
||||
a. *Data Backup and Restoration Plans*
|
||||
|
||||
i. Each system owner must implement a data backup and restoration plan.
|
||||
|
||||
i. Each data backup and restoration plan must identify:
|
||||
|
||||
1. The data custodian for the system.
|
||||
|
||||
|
||||
1. The backup schedule of each system.
|
||||
|
||||
|
||||
1. Where backup media is to be stored and secured, as well as how access is maintained.
|
||||
|
||||
1. Who may remove backup media and transfer it to storage.
|
||||
|
||||
1. Appropriate restoration procedures to restore key business system data from backup media to the system.
|
||||
|
||||
1. The restoration testing plan and frequency of testing to confirm the effectiveness of the plan.
|
||||
|
||||
1. The method for restoring encrypted backup media.
|
||||
|
|
|
|||
|
|
@ -8,4 +8,52 @@ majorRevisions:
|
|||
comment: Initial document
|
||||
---
|
||||
|
||||
# Coming Soon
|
||||
# Purpose and Scope
|
||||
|
||||
a. The purpose of this policy is to define security procedures within the organization’s data centers and secure equipment areas.
|
||||
|
||||
a. This policy applies to any cloud hosted providers and facilities within the organization that are labeled as either a data center or a secure equipment area. Such facilities are explicitly called out within this document.
|
||||
|
||||
a. This policy applies to all management, employees and suppliers that conduct business operations within cloud host or data centers and secure equipment areas.
|
||||
|
||||
# Background
|
||||
|
||||
a. This policy defines the policies and rules governing data centers and secure equipment areas from both a physical and logical security perspective. The document lists all data centers and secure equipment areas in use by the organization, prescribes how access is controlled and enforced, and establishes procedures for any visitor or third party access. This policy also defines prohibited activities and requirements for periodic safety and security checks.
|
||||
|
||||
# Policy
|
||||
|
||||
a. The following locations are classified by the organization as secure areas and are goverened by this policy:
|
||||
|
||||
i. [list all data center locations and secure areas under the organization’s control]
|
||||
|
||||
a. Each data center and secure area must have a manager assigned. The manager’s name must be documented in the organization’s records. In the case of any on-prem data centers, the manager’s name must also be posted in and near the secure area.
|
||||
|
||||
a. Each secure area must be clearly marked. Access to the secure area must be controlled by at least a locked door. A visitor access log must be clearly marked and easily accessible just inside the door.
|
||||
|
||||
a. Persons who are not employed by the organization are considered to be visitors. Visitors accessing secure areas shall:
|
||||
|
||||
i. Obtain access to secure areas in accordance with reference a.
|
||||
|
||||
i. Only enter and remain in secure areas when escorted by a designated employee. The employee must stay with the visitor during their entire stay inside the secure area.
|
||||
|
||||
i. Log the precise time of entry and exit in the visitor access log.
|
||||
|
||||
a. The following activities are prohibited inside secure areas:
|
||||
|
||||
i. Photography, or video or audio recordings of any kind.
|
||||
|
||||
i. Connection of any electrical device to a power supply, unless specifically authorized by the responsible person.
|
||||
|
||||
i. Unauthorized usage of or tampering with any installed equipment.
|
||||
|
||||
i. Connection of any device to the network, unless specifically authorized by the responsible person.
|
||||
|
||||
i. Storage or archival of large amounts of paper materials.
|
||||
|
||||
i. Storage of flammable materials or equipment.
|
||||
|
||||
i. Use of portable heating devices.
|
||||
|
||||
i. Smoking, eating, or drinking.
|
||||
|
||||
a. Secure areas must be checked for compliance with security and safety requirements on at least a quarterly basis.
|
||||
|
|
|
|||
|
|
@ -10,4 +10,102 @@ majorRevisions:
|
|||
comment: Initial document
|
||||
---
|
||||
|
||||
# Coming Soon
|
||||
# Purpose and Scope
|
||||
|
||||
a. This security incident response policy is intended to establish controls to ensure detection of security vulnerabilities and incidents, as well as quick reaction and response to security breaches.
|
||||
|
||||
a. This document also provides implementing instructions for security incident response, to include definitions, procedures, responsibilities, and performance measures (metrics and reporting mechanisms).
|
||||
|
||||
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. A key objective of the organization’s Information Security Program is to focus on detecting information security weaknesses and vulnerabilities so that incidents and breaches can be prevented wherever possible. The organization is committed to protecting its employees, customers, and partners from illegal or damaging actions taken by others, either knowingly or unknowingly. Despite this, incidents and data breaches are likely to happen; when they do, the organization is committed to rapidly responding to them, which may include identifying, containing, investigating, resolving , and communicating information related to the breach.
|
||||
|
||||
a. This policy requires that all users report any perceived or actual information security vulnerability or incident as soon as possible using the contact mechanisms prescribed in this document. In addition, the organization must employ automated scanning and reporting mechanisms that can be used to identify possible information security vulnerabilities and incidents. If a vulnerability is identified, it must be resolved within a set period of time based on its severity. If an incident is identified, it must be investigated within a set period of time based on its severity. If an incident is confirmed as a breach, a set procedure must be followed to contain, investigate, resolve, and communicate information to employees, customers, partners and other stakeholders.
|
||||
|
||||
c. Within this document, the following definitions apply:
|
||||
|
||||
i. *Information Security Vulnerability:* a vulnerability in an information system, information system security procedures, or administrative controls that could be exploited to gain unauthorized access to information or to disrupt critical processing.
|
||||
|
||||
i. *Information Security Incident:* a suspected, attempted, successful, or imminent threat of unauthorized access, use, disclosure, breach, modification, or destruction of information; interference with information technology operations; or significant violation of information security policy.
|
||||
|
||||
# Policy
|
||||
a. All users must report any system vulnerability , incident, or event pointing to a possible incident to the Information Security Manager (ISM) as quickly as possible but no later than 24 hours. Incidents must be reported by sending an email message to <insert email address here> with details of the incident.
|
||||
|
||||
a. Users must be trained on the procedures for reporting information security incidents or discovered vulnerabilities, and their responsibilities to report such incidents. Failure to report information security incidents shall be considered to be a security violation and will be reported to the Human Resources (HR) Manager for disciplinary action.
|
||||
|
||||
a. Information and artifacts associated with security incidents (including but not limited to files, logs, and screen captures) must be preserved in the event that they need to be used as evidence of a crime.
|
||||
|
||||
a. All information security incidents must be responded to through the incident management procedures defined below.
|
||||
|
||||
a. In order to appropriately plan and prepare for incidents, the organization must review incident response procedures at least once per year for currency, and update as required.
|
||||
|
||||
a. The incident response procedure must be tested on at least twice per year
|
||||
|
||||
a. The incident response logs must be reviewed once per month to assess response effectiveness.
|
||||
|
||||
# Procedure For Establishing Incident Response System
|
||||
|
||||
a. Define on-call schedule and assign an Information Security Manager (ISM) responsible for managing incident response procedure during each availability window.
|
||||
|
||||
a. Define notification channel to alert the on-call ISM of a potential security incident. Establish company resource that includes up to date contact information for on-call ISM.
|
||||
|
||||
a. Assign management sponsors from the Engineering, Legal, HR, Marketing, and C-Suite teams.
|
||||
|
||||
a. Distribute Procedure For Execute Incident Response to all staff and ensure up-to-date versions are accessible in a dedicated company resource.
|
||||
|
||||
a. Require all staff to complete training for Procedure For Executing Incident Response at least twice per year.
|
||||
|
||||
# Procedure For Executing Incident Response
|
||||
|
||||
a. When an information security incident is identified or detected, users must notify their immediate manager within 24 hours. The manager must immediately notify the ISM on call for proper response. The following information must be included as part of the notification:
|
||||
|
||||
i. Description of the incident
|
||||
|
||||
i. Date, time, and location of the incident
|
||||
|
||||
i. Person who discovered the incident
|
||||
|
||||
i. How the incident was discovered
|
||||
|
||||
i. Known evidence of the incident
|
||||
|
||||
i. Affected system(s)
|
||||
|
||||
a. Within 48 hours of the incident being reported, the ISM shall conduct a preliminary investigation and risk assessment to review and confirm the details of the incident. If the incident is confirmed, the ISM must assess the impact to the organization and assign a severity level, which will determine the level of remediation effort required:
|
||||
|
||||
i. High: the incident is potentially catastrophic to the organization and/or disrupts the organization’s day-to-day operations; a violation of legal, regulatory or contractual requirements is likely.
|
||||
|
||||
i. Medium: the incident will cause harm to one or more business units within the organization and/or will cause delays to a business unit’s activities.
|
||||
|
||||
i. Low: the incident is a clear violation of organizational security policy, but will not substantively impact the business.
|
||||
|
||||
|
||||
a. The ISM, in consultation with management sponsors, shall determine appropriate incident response activities in order to contain and resolve incidents.
|
||||
|
||||
a. The ISM must take all necessary steps to preserve forensic evidence (e.g. log information, files, images) for further investigation to determine if any malicious activity has taken place. All such information must be preserved and provided to law enforcement if the incident is determined to be malicious.
|
||||
|
||||
a. If the incident is deemed as High or Medium, the ISM must work with the VP Brand/Creative, General Counsel, and HR Manager to create and execute a communications plan that communicates the incident to users, the public, and others affected.
|
||||
|
||||
a. The ISM must take all necessary steps to resolve the incident and recover information systems, data, and connectivity. All technical steps taken during an incident must be documented in the organization’s incident log, and must contain the following:
|
||||
|
||||
i. Description of the incident
|
||||
|
||||
i. Incident severity level
|
||||
|
||||
i. Root cause (e.g. source address, website malware, vulnerability)
|
||||
|
||||
i. Evidence
|
||||
|
||||
i. Mitigations applied (e.g. patch, re-image)
|
||||
|
||||
i. Status (open, closed, archived)
|
||||
|
||||
i. Disclosures (parties to which the details of this incident were disclosed to, such as customers, vendors, law enforcement, etc.)
|
||||
|
||||
a. After an incident has been resolved, the ISM must conduct a post mortem that includes root cause analysis and documentation any lessons learned.
|
||||
|
||||
a. Depending on the severity of the incident, the Chief Executive Officer (CEO) may elect to contact external authorities, including but not limited to law enforcement, private investigation firms, and government organizations as part of the response to the incident.
|
||||
|
||||
a. The ISM must notify all users of the incident, conduct additional training if necessary, and present any lessons learned to prevent future occurrences. Where necessary, the HR Manager must take disciplinary action if a user’s activity is deemed as malicious.
|
||||
|
|
|
|||
|
|
@ -8,4 +8,86 @@ majorRevisions:
|
|||
comment: Initial document
|
||||
---
|
||||
|
||||
# Coming Soon
|
||||
# Purpose and Scope
|
||||
|
||||
a. This information security policy defines the purpose, principles, objectives and basic rules for information security management.
|
||||
|
||||
a. This document also defines procedures to implement high level information security protections within the organization, including definitions, procedures, responsibilities and performance measures (metrics and reporting mechanisms).
|
||||
|
||||
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 high level objectives and implementation instructions for the organization’s information security program. It includes the organization’s information security objectives and requirements; such objectives and requirements are to be referenced when setting detailed information security policy for other areas of the organization. This policy also defines management roles and responsibilities for the organization’s Information Security Management System (ISMS). Finally, this policy references all security controls implemented within the organization.
|
||||
|
||||
a. Within this document, the following definitions apply:
|
||||
|
||||
i. *Confidentiality*: a characteristic of information or information systems in which such information or systems are only available to authorized entities.
|
||||
|
||||
i. *Integrity*: a characteristic of information or information systems in which such information or systems may only be changed by authorized entities, and in an approved manner.
|
||||
|
||||
i. *Availability*: a characteristic of information or information systems in which such information or systems can be accessed by authorized entities whenever needed.
|
||||
|
||||
i. *Information Security*: the act of preserving the confidentiality, integrity, and, availability of information and information systems.
|
||||
|
||||
i. *Information Security Management System (ISMS)*: the overall management process that includes the planning, implementation, maintenance, review, and, improvement of information security.
|
||||
|
||||
# References
|
||||
|
||||
a. Encryption Policy
|
||||
|
||||
a. Data Center Security Policy
|
||||
|
||||
a. Disaster Recovery Policy
|
||||
|
||||
a. Password Policy
|
||||
|
||||
a. Remote Access Policy
|
||||
|
||||
a. Removable Media/Cloud Storage/BYOD Policy
|
||||
|
||||
a. Risk Assessment Policy
|
||||
|
||||
a. Security Incident Response Policy
|
||||
|
||||
a. Software Development Lifecycle Policy
|
||||
|
||||
a. System Availability Policy
|
||||
|
||||
a. Workstation Security Policy
|
||||
|
||||
# Policy
|
||||
|
||||
a. *Managing Information Security*
|
||||
|
||||
i. The organization’s main objectives for information security include the following:
|
||||
|
||||
1. [list the reasons/objectives for maintaining information security at the organization. Examples include a better market image, reduced risk of data breaches and compromises, and compliance with legal, regulatory, and contractual requirements.]
|
||||
|
||||
i. The organization’s objectives for information security are in line with the organization’s business objectives, strategy, and plans.
|
||||
|
||||
i. Objectives for individual security controls or groups of controls are proposed by the company management team, including but not limited to [list key roles inside the organization that will participate in information security matters], and others as appointed by the CEO; these security controls are approved by the CEO in accordance with the Risk Assessment Policy (Reference (a)).
|
||||
|
||||
i. All objectives must be reviewed at least once per year.
|
||||
|
||||
i. The company will measure the fulfillment of all objectives. The measurement will be performed at least once per year. The results must be analyzed, evaluated, and reported to the management team.
|
||||
|
||||
a. *Information Security Requirements*
|
||||
|
||||
i. This policy and the entire information security program must be compliant with legal and regulatory requirements as well as with contractual obligations relevant to the organization.
|
||||
|
||||
i. All employees, contractors, and other individuals subject to the organization’s information security policy must read and acknowledge all information security policies.
|
||||
|
||||
i. The process of selecting information security controls and safeguards for the organization is defined in Reference (a).
|
||||
|
||||
i. The organization prescribes guidelines for remote workers as part of the Remote Access Policy (reference (b)).
|
||||
|
||||
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)).
|
||||
|
|
|
|||
|
|
@ -8,4 +8,60 @@ majorRevisions:
|
|||
comment: Initial document
|
||||
---
|
||||
|
||||
# Coming Soon
|
||||
# Purpose and Scope
|
||||
|
||||
a. This log management and review policy defines specific requirements for information systems to generate, store, process, and aggregate appropriate audit logs across the organization’s entire environment in order to provide key information and detect indicators of potential compromise.
|
||||
|
||||
a. This policy applies to all information systems within the organization’s production network.
|
||||
|
||||
a. This policy applies to all employees, contractors, and partners of the organization that administer or provide maintenance on the organization’s production systems. Throughout this policy, these individuals are referred to as system administrators.
|
||||
|
||||
# Background
|
||||
|
||||
a. In order to measure an information system’s level of security through confidentiality, integrity, and availability, the system must collect audit data that provides key insights into system performance and activities. This audit data is collected in the form of system logs. Logging from critical systems, applications, and services provides information that can serve as a starting point for metrics and incident investigations. This policy provides specific requirements and instructions for how to manage such logs.
|
||||
|
||||
# Policy
|
||||
|
||||
a. All production systems within the organization shall record and retain audit-logging information that includes the following information:
|
||||
|
||||
i. Activities performed on the system.
|
||||
|
||||
i. The user or entity (i.e. system account) that performed the activity, including the system that the activity was performed from.
|
||||
|
||||
i. The file, application, or other object that the activity was performed on.
|
||||
|
||||
i. The time that the activity occurred.
|
||||
|
||||
i. The tool that the activity was performed with.
|
||||
|
||||
i. The outcome (e.g., success or failure) of the activity.
|
||||
|
||||
a. Specific activities to be logged must include, at a minimum:
|
||||
|
||||
i. Information (including authentication information such as usernames or passwords) is created, read, updated, or deleted.
|
||||
|
||||
i. Accepted or initiated network connections.
|
||||
|
||||
i. User authentication and authorization to systems and networks.
|
||||
|
||||
i. Granting, modification, or revocation of access rights, including adding a new user or group; changing user privileges, file permissions, database object permissions, firewall rules, and passwords.
|
||||
|
||||
i. System, network, or services configuration changes, including software installation, patches, updates, or other installed software changes.
|
||||
|
||||
i. Startup, shutdown, or restart of an application.
|
||||
|
||||
i. Application process abort, failure, or abnormal end, especially due to resource exhaustion or reaching a resource limit or threshold (such as CPU, memory, network connections, network bandwidth, disk space, or other resources), the failure of network services such as DHCP or DNS, or hardware fault.
|
||||
|
||||
i. Detection of suspicious and/or malicious activity from a security system such as an Intrusion Detection or Prevention System (IDS/IPS), anti-virus system, or anti-spyware system.
|
||||
|
||||
a. Unless technically impractical or infeasible, all logs must be aggregated in a central system so that activities across different systems can be correlated, analyzed, and tracked for similarities, trends, and cascading effects. Log aggregation systems must have automatic and timely log ingest, event and anomaly tagging and alerting, and ability for manual review.
|
||||
|
||||
a. Logs must be manually reviewed on a regular basis:
|
||||
|
||||
i. The activities of users, administrators and system operators must be reviewed on at least a monthly basis.
|
||||
|
||||
ii. Logs related to PII must be reviewed on at least a monthly basis in order to identify unusual behavior.
|
||||
|
||||
a. When using an outsourced cloud environment, logs must be kept on cloud environment access and use, resource allocation and utilization, and changes to PII. Logs must be kept for all administrators and operators performing activities in cloud environments.
|
||||
|
||||
a. All information systems within the organization must synchronize their clocks by implementing Network Time Protocol (NTP) or a similar capability. All information systems must synchronize with the same primary time source.
|
||||
|
|
|
|||
|
|
@ -8,4 +8,92 @@ majorRevisions:
|
|||
comment: Initial document
|
||||
---
|
||||
|
||||
# Coming Soon
|
||||
# Purpose and Scope
|
||||
|
||||
a. This policy establishes the rules governing controls, monitoring, and removal of physical access to company’s facilities.
|
||||
|
||||
a. This policy applies to all staff, contractors, or third parties who require access to any physical location owned, operated, or otherwise occupied by the company. A separate policy exists for governing access to the company data center.
|
||||
|
||||
# Policy
|
||||
|
||||
a. *Management responsibilities*
|
||||
|
||||
i. Management shall ensure:
|
||||
|
||||
1. appropriate entry controls are in place for secure areas
|
||||
|
||||
1. security personnel, identification badges, or electronic key cards should be used to validate employee access to facilities
|
||||
|
||||
1. confirm visitor & guest access procedure has been followed by host staff
|
||||
|
||||
1. management periodically reviews list of individuals with physical access to facilities
|
||||
|
||||
1. card access records and visitor logs are kept for a minimum of 90 days and are periodically reviewed for unusual activity
|
||||
|
||||
a. *Key access & card systems*
|
||||
|
||||
i. The following policies are applied to all facility access cards/keys:
|
||||
|
||||
1. Access cards/keys shall not be shared or loaned to others
|
||||
|
||||
1. Access cards/keys shall not have identifying information other than a return mail address
|
||||
|
||||
1. Access cards/keys shall be returned to Human Resources when they are no longer needed
|
||||
|
||||
1. Lost or stolen access cards/keys shall be reported immediately
|
||||
|
||||
1. If an employee changes to a role that no longer requires physical access or leaves the company, their access cards/keys will be suspended
|
||||
|
||||
1. Human Resources will regularly review physical security privileges and review access logs
|
||||
|
||||
\pagebreak
|
||||
|
||||
a. *Staff & contractor access procedure*
|
||||
|
||||
i. Access to physical locations is granted to employees and contractors based on individual job function and will be granted by Human Resources.
|
||||
|
||||
i. Any individual granted access to physical spaces will be issued a physical key or access key card. Key and card issuance is tracked by Human Resources and will be periodically reviewed.
|
||||
|
||||
i. In the case of termination, Human Resources should ensure immediate revocation of access
|
||||
(i.e. collection of keys, access cards, and any other asset used to enter facilities) through the offboarding procedure.
|
||||
|
||||
a. *Visitor & guest access procedure*
|
||||
|
||||
i. The following policies are applied to identification & authorization of visitors and guests:
|
||||
|
||||
1. All visitors must request and receive written onsite authorization from a staff member.
|
||||
|
||||
1. Visitor access shall be tracked with a sign in/out log. The log shall contain:visitor’s name, firm represented, purpose of visit, and onsite personnel authorizing access
|
||||
|
||||
1. The log shall be retained for a minimum of 90 days
|
||||
|
||||
1. Visitors shall be given a badge or other identification that visibly distinguishes visitors from onsite personnel
|
||||
|
||||
1. Visitor badges shall be surrendered before leaving the facility
|
||||
|
||||
a. *Audit controls & management*
|
||||
|
||||
i. Documented procedures and evidence of practice should be in place for this policy. Acceptable controls and procedures include:
|
||||
|
||||
1. visitor logs
|
||||
|
||||
1. access control procedures
|
||||
|
||||
1. operational key-card access systems
|
||||
|
||||
1. video surveillance systems (with retrievable data)
|
||||
|
||||
1. ledgers if issuing physical keys
|
||||
|
||||
a. *Enforcement*
|
||||
|
||||
i. Employees, contractors, or third parties found in violation of this policy (whether intentional or accidental) may be subject to disciplinary action, including:
|
||||
|
||||
1. reprimand
|
||||
|
||||
1. loss of access to premises
|
||||
|
||||
1. termination
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -8,4 +8,32 @@ majorRevisions:
|
|||
comment: Initial document
|
||||
---
|
||||
|
||||
# Coming Soon
|
||||
# Purpose and Scope
|
||||
|
||||
a. The Password Policy describes the procedure to select and securely manage passwords.
|
||||
|
||||
a. This policy applies to all employees, contractors, and any other personnel who have an account on any system that resides at any company facility or has access to the company network.
|
||||
|
||||
# Policy
|
||||
|
||||
a. *Rotation requirements*
|
||||
|
||||
i. All system-level passwords should be rotated on at least a quarterly basis. All user-level passwords should be rotated at least every six months.
|
||||
|
||||
i. If a credential is suspected of being compromised, the password in question should be rotated immediately and the Engineering/Security team should be notified.
|
||||
|
||||
a. Password protection
|
||||
|
||||
i. All passwords are treated as confidential information and should not be shared with anyone. If you receive a request to share a password, deny the request and contact the system owner for assistance in provisioning an individual user account.
|
||||
|
||||
i. Do not write down passwords, store them in emails, electronic notes, or mobile devices, or share them over the phone. If you must store passwords electronically, do so with a password manager that has been approved by IT. If you truly must share a password, do so through a designated password manager or grant access to an application through a single sign on provider.
|
||||
|
||||
i. Do not use the “Remember Password” feature of applications and web browsers.
|
||||
|
||||
i. If you suspect a password has been compromised, rotate the password immediately and notify engineering/security.
|
||||
|
||||
a. Enforcement
|
||||
|
||||
i. An employee or contractor found to have violated this policy may be subject to disciplinary action.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -7,5 +7,24 @@ majorRevisions:
|
|||
- date: Jun 1 2018
|
||||
comment: Initial document
|
||||
---
|
||||
# Purpose and Scope
|
||||
|
||||
# Coming Soon
|
||||
a. This policy addresses policy education requirements for employees and contractors.
|
||||
|
||||
a. This policy applies to all full-time employees, part-time employees, and contractors. Adherence to assigned policies is binding under their Employment Offer Letter and/or Independent Contractor Agreement.
|
||||
|
||||
# Applicability
|
||||
|
||||
a. Upon hire of a new employee or contractor, the Hiring Manager will determine which subsets of policies will apply to that individual. The individual will have five working days to read the assigned policies. The following will be logged in the Policy Training Policy Ledger:
|
||||
|
||||
i. Assignment date
|
||||
|
||||
i. Completion date
|
||||
|
||||
i. Policy
|
||||
|
||||
i. Assignee
|
||||
|
||||
i. Assigner
|
||||
|
||||
i. Notes
|
||||
|
|
|
|||
|
|
@ -8,4 +8,44 @@ majorRevisions:
|
|||
comment: Initial document
|
||||
---
|
||||
|
||||
# Coming Soon
|
||||
# Purpose and Scope
|
||||
|
||||
a. This policy defines best practices to reduce the risk of data loss/exposure through workstations.
|
||||
|
||||
a. This policy applies to all employees and contractors. Workstation is defined as the collection of all company-owned and personal devices containing company data.
|
||||
|
||||
# Policy
|
||||
|
||||
a. Workstation devices must meet the following criteria:
|
||||
|
||||
i. Operating system must be no more than one generation older than current
|
||||
|
||||
i. Device must be encrypted at rest
|
||||
|
||||
i. Device must be locked when not in use or when employee leaves the workstation
|
||||
|
||||
i. Workstations must be used for authorized business purposes only
|
||||
|
||||
i. Loss or destruction of devices should be reported immediately
|
||||
|
||||
i. Laptops and desktop devices should run the latest version of antivirus software that has been approved by IT
|
||||
|
||||
a. *Desktop & laptop devices*
|
||||
|
||||
i. Employees will be issued a desktop, laptop, or both by the company, based on their job duties. Contractors will provide their own laptops.
|
||||
|
||||
i. Desktops and laptops must operate on macOS or Windows.
|
||||
|
||||
a. *Mobile devices*
|
||||
|
||||
i. Mobile devices must be operated as defined in the Removable Media Policy, Cloud Storage, and Bring Your Own Device Policy.
|
||||
|
||||
i. Mobile devices must operate on iOS or Android.
|
||||
|
||||
i. Company data may only be accessed on mobile devices with Slack and Gmail.
|
||||
|
||||
a. *Removable media*
|
||||
|
||||
i. Removable media must be operated as defined in the Removable Media Policy, Cloud Storage, and Bring Your Own Device Policy.
|
||||
|
||||
i. Removable media is permitted on approved devices as long as it does not conflict with other policies.
|
||||
|
|
|
|||
|
|
@ -13,11 +13,15 @@ html lang=en
|
|||
= javascript
|
||||
document.addEventListener("DOMContentLoaded", function(event) {
|
||||
document.querySelectorAll('.cron').forEach(function(el) {
|
||||
el.innerHTML = prettyCron.toString(el.innerHTML)
|
||||
el.innerHTML = prettyCron.toString((""+el.innerHTML).trim(),true) // 6-field expressions
|
||||
})
|
||||
})
|
||||
|
||||
function show(name) {
|
||||
if (history.replaceState) {
|
||||
history.replaceState(null, null, '#'+name)
|
||||
}
|
||||
|
||||
var items = document.getElementsByClassName('top-nav')
|
||||
for (var i=0; i<items.length; i++) {
|
||||
var item = items[i]
|
||||
|
|
@ -220,5 +224,14 @@ html lang=en
|
|||
.content.has-text-centered
|
||||
p {{.Project.OrganizationName}} Confidential 2018
|
||||
= javascript
|
||||
// commented for development
|
||||
show('overview')
|
||||
if (window.location.hash=="") {
|
||||
show('overview')
|
||||
} else {
|
||||
var hashComponents = window.location.hash.split('#')
|
||||
if (hashComponents.length>1) {
|
||||
var destination = hashComponents[1]
|
||||
if (["overview","narratives","policies","procedures","standards"].indexOf(destination) >= 0) {
|
||||
show(destination)
|
||||
}
|
||||
}
|
||||
}
|
||||
Loading…
Reference in New Issue
Block a user