• Software development and operations
  • Metadata
  • Applicability
  • To conduct software development and operations
  • Implement all operations activities as software development
  • Make security a key part of software development and operations
  • Control changes to software and systems
  • Operate reliable systems with appropriate redundancy and availability
  • Perform testing of software
  • Have PHI only on production systems
  • Do not outsource development
  • Respect Intellectual Property Rights and licenses
  • Enforcement
  • References

Software development and operations

MedStack Confidential

Metadata

• responsible officer: CTO
• date
  • effective: 2018-06-20
  • revised: 2019-06-11
  • reviewed: 2018-06-20

Applicability

• people: This policy applies to all employees, contractors, suppliers and vendors who develop software that interacts with PHI.

To conduct software development and operations

• Perform these activities
  • Define operational procedures and responsibilities
  • Control operational software and authorize changes
  • Acquire, develop, test, document and maintain systems
  • Implement security requirements for information systems
  • Protect data used for testing
• On these entities
  • configurations
  • infrastructure
  • data
  • software

    Code	Section	Title	Text
    ISO	A.12.1	Operational procedures and responsibilities	Objective: To ensure correct and secure operations of information processing facilities.
    ISO	A.12.5	Control of operational software	Objective: To ensure the integrity of operational systems.
    ISO	A.14	System acquisition, development and maintenance
    ISO	A.14.2	Security in development and support processes	Objective: To ensure that information security is designed and implemented within the development lifecycle of information systems.

Implement all operations activities as software development

• Make all changes to operational systems by
  • modifying source code
  • executing the source code
  • using automated tools
• Use software development methods to
  • test development, staging and operational systems
  • ensure that performance matches expectations
  • document software and processes (where they are not self-documenting)
  • log modifications to the systems

    Code	Section	Title	Text
    ISO	A.12.1.1	Documented operating procedures	Operating procedures shall be documented and made available to all users who need them.
    ISO	A.12.1.2	Change management	Changes to the organization, business processes, information processing facilities and systems that affect information security shall be controlled.
    ISO	A.12.5.1	Installation of software on operational systems	Procedures shall be implemented to control the installation of software on operational systems.

Make security a key part of software development and operations

• Design and develop systems to be secure
  • Design using Privacy by Design and Security by Design.
  • Develop using security best-practices (e.g. OWASP).
  • Use secure development environments.
  • Avoid unnecessary changes.
  • Design systems to be continuously auditable and testable.
• Scan and test operational systems applications for vulnerabilities
  • Scan operational systems for security flaws.
  • Commission third-party network scans.
  • Commission third-party penetration tests .
• Manage vulnerabilities
  • Document, review and manage vulnerabilities.
  • Monitor security news for new vulnerabilities.

    Code	Section	Title	Text
    ISO	A.12.6.1	Management of technical vulnerabilities	Information about technical vulnerabilities of information systems being used shall be obtained in a timely fashion, the organization’s exposure to such vulnerabilities evaluated and appropriate measures taken to address the associated risk.
    ISO	A.12.7.1	Information systems audit controls	Audit requirements and activities involving verification of operational systems shall be carefully planned and agreed to minimise disruptions to business processes.
    ISO	A.14.1	Security requirements of information systems	Objective: To ensure that information security is an integral part of information systems across the entire lifecycle. This also includes the requirements for information systems which provide services over public networks.
    ISO	A.14.1.1	Information security requirements analysis and specification	The information security related requirements shall be included in the requirements for new information systems or enhancements to existing information systems.
    ISO	A.14.1.2	Securing application services on public networks	Information involved in application services passing over public networks shall be protected from fraudulent activity, contract dispute and unauthorized disclosure and modification.
    ISO	A.14.1.3	Protecting application services transactions	Information involved in application service transactions shall be protected to prevent incomplete transmission, mis-routing, unauthorized message alteration, unauthorized disclosure, unauthorized message duplication or replay.
    ISO	A.14.2.1	Secure development policy	Rules for the development of software and systems shall be established and applied to developments within the organization.
    ISO	A.14.2.4	Restrictions on changes to software packages	Modifications to software packages shall be discouraged, limited to necessary changes and all changes shall be strictly controlled.
    ISO	A.14.2.5	Secure system engineering principles	Principles for engineering secure systems shall be established, documented, maintained and applied to any information system implementation efforts.
    ISO	A.14.2.6	Secure development environment	Organizations shall establish and appropriately protect secure development environments for system development and integration efforts that cover the entire system development lifecycle.
    Privacy by Design
    OWASP Security by Design Principles

Control changes to software and systems

• Use a source control system
  • to control changes to software
  • to manage access to source code
• Control and automate the deployment of software to production
  • Peer review new and modified software before deployment to production.
  • Use a continuous deployment system.
• In case of emergency changes outside of the normal process
  • document the changes made
  • incorporate the changes back into the normal process
• Use the principle of least privilege
  • Grant software the minimum necessary access to perform its function.
  • Limit only production engineers to have access to production systems.

    Code	Section	Title	Text
    ISO	A.14.2.2	System change control procedures	Changes to systems within the development lifecycle shall be controlled by the use of formal change control procedures.

Operate reliable systems with appropriate redundancy and availability

Code	Section	Title	Text
ISO	A.12.1.3	Capacity management	The use of resources shall be monitored, tuned and projections made of future capacity requirements to ensure the required system performance.
ISO	A.17.2.1	Availability of information processing facilities	Information processing facilities shall be implemented with redundancy sufficient to meet availability requirements.

Perform testing of software

• Automate testing in a secure manner
  • Implement automated tests of systems.
  • Perform testing primarily on non-production systems.
  • Do not use real data or PHI for testing or demonstrations.
• Test for
  • regressions
  • security flaws
  • acceptance criteria

    Code	Section	Title	Text
    ISO	A.12.1.4	Separation of development, testing and operational environments	Development, testing, and operational environments shall be separated to reduce the risks of unauthorized access or changes to the operational environment.
    ISO	A.14.2.3	Technical review of applications after operating platform changes	When operating platforms are changed, business critical applications shall be reviewed and tested to ensure there is no adverse impact on organizational operations or security.
    ISO	A.14.2.8	System security testing	Testing of security functionality shall be carried out during development.
    ISO	A.14.2.9	System acceptance testing	Acceptance testing programs and related criteria shall be established for new information systems, upgrades and new versions.
    ISO	A.14.3	Test data	Objective: To ensure the protection of data used for testing.
    ISO	A.14.3.1	Protection of test data	Test data shall be selected carefully, protected and controlled.

Have PHI only on production systems

• Do not copy PHI to non-production systems
  • only production systems are secured and managed correctly to handle PHI
• If PHI is on a non-production system
  • Evaluate the security of the non-production system (e.g. a secure workstation).
  • Securely delete the data as soon as possible.
  • Report the incident.

Do not outsource development

• All development is performed by employees or contractors directly managed by employees.

  Code	Section	Title	Text
  ISO	A.14.2.7	Outsourced development	The organization shall supervise and monitor the activity of outsourced system development.

Respect Intellectual Property Rights and licenses

• Identify and comply with IPR for source code of external origin (including open source software).
• Identify and comply with IPR for software tools (including open source software).

  Code	Section	Title	Text
  ISO	A.18.1.2	Intellectual property rights	Appropriate procedures shall be implemented to ensure compliance with legislative, regulatory and contractual requirements related to intellectual property rights and use of proprietary software products.

Enforcement

• Responsible party: All managers and supervisors
• sanctions: standard

References

Code	Section	Title	Text
ISO	A.9.4.5	Access control to program source code	Access to program source code shall be restricted.
ISO	A.12.6	Technical vulnerability management	Objective: To prevent exploitation of technical vulnerabilities.
ISO	A.17.2	Redundancies	Objective: To ensure availability of information processing facilities.
SOC 2	CC8.1	The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives.	The following points of focus, specifically related to all engagements using the trust services criteria, highlight important characteristics relating to this criterion: - Manages Changes Throughout the System Lifecycle—A process for managing system changes throughout the lifecycle of the system and its components (infrastructure, data, software and procedures) is used to support system availability and processing integrity. - Authorizes Changes—A process is in place to authorize system changes prior to development. - Designs and Develops Changes—A process is in place to design and develop system changes. - Documents Changes—A process is in place to document system changes to support ongoing maintenance of the system and to support system users in performing their responsibilities. - Tracks System Changes—A process is in place to track system changes prior to implementation. - Configures Software—A process is in place to select and implement the configuration parameters used to control the functionality of software. - Tests System Changes—A process is in place to test system changes prior to implementation. - Approves System Changes—A process is in place to approve system changes prior to implementation. - Deploys System Changes—A process is in place to implement system changes. - Identifies and Evaluates System Changes—Objectives affected by system changes are identified, and the ability of the modified system to meet the objectives is evaluated throughout the system development life cycle. - Identifies Changes in Infrastructure, Data, Software, and Procedures Required to Remediate Incidents—Changes in infrastructure, data, software, and procedures required to remediate incidents to continue to meet objectives are identified, and the change process is initiated upon identification. - Creates Baseline Configuration of IT Technology—A baseline configuration of IT and control systems is created and maintained. - Provides for Changes Necessary in Emergency Situations —A process is in place for authorizing, designing, testing, approving and implementing changes necessary in emergency situations (that is, changes that need to be implemented in an urgent timeframe). Additional points of focus that apply only in an engagement using the trust services criteria for confidentiality: - Protects Confidential Information—The entity protects confidential information during system design, development, testing, implementation, and change processes to meet the entity's objectives related to confidentiality. Additional points of focus that apply only in an engagement using the trust services criteria for privacy: - Protects Personal Information—The entity protects personal information during system design, development, testing, implementation, and change processes to meet the entity's objectives related to privacy.
CHI	SR80	Implementing Software and Upgrades in the EHRi	Organizations hosting components of the EHRi must put procedures in place to control the implementation of software and upgrades on operational systems hosting these components.
CHI	SR81	Protecting EHRi Software	Organizations hosting components of the EHRi must maintain control over access to program source libraries for EHRi components where such libraries are within the control of the organization.
CHI	SR82	Managing Known Vulnerabilities	Organizations hosting components of the EHRi must take steps to test for and prevent the exploitation of published vulnerabilities in systems and software that host those components.

November 13, 2019

Powered by