Github/comply
1
0
Fork 0
mirror of https://github.com/strongdm/comply synced 2024-11-22 07:34:54 +00:00
Code Issues Projects Releases Wiki Activity

Merge branch 'master' of github.com:strongdm/comply

Browse Source
This commit is contained in:
Justin McCarthy 2018-05-18 12:21:00 -07:00
commit 378a27542f
No known key found for this signature in database
GPG Key ID: 900437410E142A48
2 changed files with 315 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

186
example/policies/development.md
View File

@ -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.

131
example/policies/media.md
View File

@ -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.