Skip to main content

Secure Development Procedure for Empower Family

Author: Don Scott

Last Updated: February 25, 2026

Information Security Development Procedure​

1. Purpose​

The purpose of this procedure is to provide a framework for the development and maintenance of information systems, ensuring they are designed, built, and maintained in a manner that is secure and compliant with ISO 27001.

2. Scope​

This procedure applies to all individuals who are responsible for the acquisition, development, and maintenance of information systems with respect to product development (Empower and related products). This includes IT staff, contractors, vendors, and any third party service providers.

3. Exceptions​

Any exceptions to the procedure must be approved by the Procedure Owner in writing.

4. Terms and Definitions​

ISO 27001: An international standard on how to manage information security.

Development Team: The group of people responsible for developing and maintaining the organization’s information systems.

Procedure Owner: The individual or role responsible for the maintenance and supervision of the procedure. At the current time this is Evan Sotos (Engineering Manager, Incubations) and Paul Madden (VP, IS).

Auditors: Individuals tasked with ensuring compliance with the procedure.

(D)DoS: Distributed Denial of Service (DDoS) is a malicious attempt to disrupt the normal traffic of a targeted server, service, or network by overwhelming the target or its surrounding infrastructure with a flood of Internet traffic. This is achieved by utilizing multiple compromised computer systems as sources of traffic, making it difficult for the target to distinguish legitimate user traffic from attack traffic.

5. Procedure​

The rules for the development of software and systems must be applied to software development for Empower and related product development within the organization.All team members are responsible for understanding and following these rules.

A.14.1.1 Secure Development Planning and Documentation (ISO 27001:2022 A.5.8, A.8.28)​

  • Security Integration: Information security shall be integrated into the development lifecycle of all Features from inception to decommissioning. This includes adopting a security-first approach to coding, ensuring that security credentials are never included in code, performing static analysis to maintain code quality and to catch accidental security lapses.
  • Production Environment Access: Restrict access to the production environment to authorized personnel only, ensuring a clear separation between development and production. Product engineers are prohibited from direct access to make changes to: code, SQL schemas/databases, and infrastructure of any kind. This prohibition does not apply to control surfaces (like feature flags) that are designed for use after deployment, but would apply to environmental variables.
  • Traceability of Changes: All code changes must be directly tied back to user stories in the product backlog. This requirement ensures that every modification to the codebase is justified, documented, and traceable to a specific need or improvement.
    • Changes to systems within the organization's control must be reviewed and approved by authorized individuals. This includes, but is not limited to, system enhancements, patches, and major configuration changes.
    • The ADR formal process for requesting, documenting, approving, and implementing changes must be followed for high impact features. See SSFR below.
  • Security Sensitive Features Rule ("SSFR"): The feature template shall include a field titled "Security Sensitive", Product Managers, Pod Leads, and Engineering staff must set this flag to true for any work that could reasonably have a material impact on a security subsystem (like auth, JWT validation, keycloak, SSO, RBAC) or expose any new public endpoint to the internet, or otherwise have any impact that may reasonably increase security risk using this procedure as a guide. All features with security sensitive flag on must have one or more linked PBI's documenting the security aspect(s) of that development work.
  • Secure Coding Training: All developers in HSAL are required to complete additional "developer" security training to help employees be more aware of the current threat environment, and what they may need to consider to keep Hitachi Solutions and our clients safe. The firm will conduct periodic refresher courses to keep developers updated on new threats and secure coding techniques.

A.14.1.2 Protection from Network Threats (ISO 27001:2022 A.8.26, A.8.32)​

  • Public Endpoint General Rule: INTERNAL PUBLIC ENDPOINTS OF ANY KIND OUTSIDE EXISTING HTTPS TUNNELS ARE HIGHLY DISCOURAGED and introduction of new endpoints is subject to the Security Sensitive Features Rule (SSFR).
    • We have regularly found that public endpoints are almost immediately attacked. Public endpoints using password authentication are completely prohibited; no new public endpoints will be approved that use basic authentication, and all existing endpoints must be covered by a SSFR. Internal development environments and test systems are_not_ exempt from this rule.
    • Public endpoint using TLS 1.2 or greater, SSO-based token authentication, or other approved mechanisms may be introduced provided the SSFR is followed, and the rest of this procedure document is addressed; especially this subsection.
    • No_Direct_ Internet Exposure: in order to protect our services from volumetric and layer7 DDoS attacks, as a rule we do not expose public endpoints (even for HTTPS) directly. Instead, the product infrastructure leverages Cloudflare tunnels to a accept ingress traffic through Cloudflare -- only after it has been scrubbed for attack traffic through that service. This both provides an additional layer of protection and hides our public IP address space from attackers -- forcing attack traffic to pass through the considerable network that Cloudflare provides for scrubbing.
    • No exceptions this general rule will be granted except by the Procedure Owner for exceptional reasons.
  • Data Encryption: Implement strong encryption for data in transit and at rest, especially for information passing over public networks, to protect against unauthorized disclosure and modification. This means no HTTP or other non-encrypted protocols are allowed except as required to redirect users to secure channels.
  • Firewalls and Intrusion Detection: This team shall utilize firewalls and intrusion detection systems to monitor and protect application services from fraudulent activities and security breaches. For purposes of most of our systems this means that all egress flows through the Cloudflare tunnels above.
  • Private Networking: Use private networking for all internal development and testing activities to minimize external threats. Public endpoints for internal development assets are strongly discouraged.
  • Authentication Standards: For any sensitive endpoints, Single Sign-On (SSO) should be used, avoiding the use of any basic authentication mechanisms.

A.14.1.3 Transaction Security (ISO 27001:2022 A.8.26)​

Especially for security sensitive features, or any features involving authorizing or causing a material consumption of Hitachi Solutions compute resources, the following special consideration will be given:

  • Utilize cryptographic hash functions and digital signatures to detect unauthorized alterations to messages. Implement message authentication codes (MACs) to ensure the integrity and authenticity of the messages.
  • Enforce strict access control measures to restrict who can send or modify information in application service transactions.
  • Utilize only approved authentication mechanisms like multi-factor authentication (MFA) to verify the identity of users accessing the system.
  • Ensure secure configuration of network devices to prevent misrouting of information; see above.

A.14.2.1 Secure Development Environment (ISO 27001:2022 A.8.25)​

A secure development environment must be established and appropriately protected.

  • Test Environments: Test environments should mimic the production environment as closely as possible and should be used for development and testing purposes only. No production customer data should be present in development environments.

A.14.2.2 System Change Control (ISO 27001:2022 A.8.32)​

When development is performed and we are making changes, we must ensure accountability and traceability of those changes.

  • Pull Request Rule:. No changes shall be made directly to the main branch, all changes should be made via pull request, with on additional approver to make sure we have multiple eyes on changes we make to the main branch.
  • User Story Linage: No changes to product code, or the related infrastructure may be performed without a User Story defining the scope and reason for the change. These User Stories shall be linked in the Pull Request which implements the change in the code base.
  • Automated Security Reviews: Packages are subject to regular dependency exploitation tests as part of their repository configuration. If a package dependency is found to have known exploits or patches available, a PR is automatically created to patch the package. Repository owners are required to assess automated patching PRs every day.

A.14.2.3 Technical Review and Testing of Applications (ISO 27001:2022 A.8.32)​

  • Major Changes: When major systems are changed, especially SSF's a QA plan must be in place to test this feature. This will require Software Engineer in Test capacity and developer capacity.
  • Any Other Change + Releases Generally: All minor (and major) releases of the Empower Data Platform are subject to QA review for new User Stories and regression testing.

A.14.2.4 Prohibition from Security Sensitive Refactoring without Approval (ISO 27001:2022 A.8.32)​

In general, changes to security sensitive subsystems, and refactoring of the code around these systems is discouraged. This applies to changes to the systems directly, to changes in major software dependencies that implement them, or any other change that could reasonably be determined to be security sensitive.

  • Security Sensitive Changes: Any changes or refactoring is subject to the SSFR, regardless of how small. This means User Stories should not be raised under a Feature that is not SSFR marked, and should it be discovered that a User Story is security sensitive, the feature must be marked as security sensitive and escalated to the Product team.

A.14.2.5 Secure System Engineering Principles (ISO 27001:2022 A.8.27)​

  • Principle of Least Privilege: Every component of the system must operate with the least amount of privilege necessary to perform its function, to minimize the potential impact of a security breach.
  • Fail-Safe Defaults: Systems should be designed on the principle of failing securely. In case of a system failure or anomaly, the default state of the system should be secure and minimize risk.
  • Separation of Duties: Critical tasks and functions must be divided among multiple individuals or teams to prevent fraud or unauthorized actions. This includes separating development, testing, and production environments and duties.
  • Defense in Depth: Implement multiple layers of security controls throughout the system. If one layer fails, the subsequent layers will provide the necessary protection.
  • Security by Design: Security measures and considerations must be integrated at the earliest stages of system development and throughout the lifecycle, not bolted on as an afterthought.

A.14.2.6 Secure Development Environment (ISO 27001:2022 A.8.31)​

  • Access Control: Strict access control measures must be implemented for the development environment. Access should be limited based on roles, with multi-factor authentication required.
  • Use of Standardized and Approved Tools: Only use development and testing tools that have been approved by the security team to ensure they do not introduce vulnerabilities into the system.
  • Monitoring and Logging: Implement continuous monitoring and logging of all development environment activities to detect and respond to security incidents rapidly.

A.14.2.7 Outsourced Development (ISO 27001:2022 A.8.30)​

  • Vendor Security Assessment: Before engaging with any third-party development team, that vendor must meet organization's security standards, subject to standard IT policy.
  • Secure Communication Channels: All vendors must use approved Hitachi Solutions tools, especially when sharing sensitive or proprietary information.

A.14.2.8 System Security Testing (ISO 27001:2022 A.8.29)​

  • Active Security Testing: The Empower product uses a number of products to review the security posture of Empower. For instance, Empower uses Cloudflare WAF heuristic detection, DataDog Security Posture Analysis, Github Dependabot dependency monitoring.
  • Remediation and Re-testing: When defects in the product are identified that are security-sensitive, those features shall be promptly prioritized in the backlog to be addressed in the next minor version.

A.14.2.9 System Acceptance Testing (ISO 27001:2022 A.8.29)​

  • Acceptance Criteria: Defined and clear acceptance criteria for new systems, upgrades, and changes shall be present on all features. These criteria should be based on the security requirements and objectives of the organization.
  • User Acceptance Testing (UAT): Involve end-users in the acceptance testing phase to ensure the system meets their requirements and operates securely in a real-world environment.
  • Documentation and Approval: Document all acceptance testing procedures, results, and approvals via the product backlog in Azure DevOps. Ensure that the system cannot move into production without formal acceptance and sign-off from the security team.

A.14.3.1 Protection of Test Data (ISO 27001:2022 A.8.33)​

  • Security Measures for Test Data: Apply the same security controls and measures for protecting test data as for production data, considering the sensitivity and classification of the data.
  • Data Usage: Employees should not use production data in our development environments except if that production data is Hitachi's own, SYNTHETIC data.

Review and Revision​

This procedure will be reviewed as it is deemed appropriate, but no less frequently than every 12 months. Procedure review will be undertaken by the Procedure Owner.

  • March 22, 2024 - Original revision
  • November 20, 2024 - Added ISO 27001:2022 references.
  • February 25, 2026 - Updated SSFR for Feature Template, Changed Procedure Owner to Evan Sotos

References​

ISO/IEC 27001:2013 Information technology — Security techniques — Information security management systems — Requirements