SDLP: Design & Development Process
Copyright © 2023 by WisePlant Group LLC. All rights reserved. Do not copy or distribute.

Introduction

This process is created and developed to meet the requirements of the ISA/IEC-62443-4-1 standard, part of the certification process and required by ISA Secure for certification purposes. It is the final intention to meet all the requirements consistently. This process should be evaluated and improved on la continuous basis to finally meet all the requirements. Suggestions and improvements are welcome.

Scope

This program applies to all areas, activities, departments, suppliers, and subcontractors whose activities are involved with the design, development, production, and support of the ZCM system.

Overview

The program contains processes or activities that must be executed in a certain sequence.  The sequence begins with the elaboration of a Requirement (RQ), once the RQ is ready, it is transferred for Development (DEV). Requirements can be generated from different needs or requests, for example: A New Functionality, a patch for a malfunction, a vulnerability of the component, or other reasons.  The RQ is generated based on a Backlog of ideas, functionalities, requests, and claims managed by the business area.

Picture 1: Design and Development Process

Once the RQ is transferred from the business to the development area, it has to be scheduled into a development, to finally end into a product release or update. Every single development must be tested individually and grouped in a development environment controlled by the development team.

The update package (PCK) is assembled to be proven and accepted at the FSA activity in the QA environment.  The complete lists of the Functional and Foundational requirements are deeply tested according to a series of Test and Stress Cases.

Design

The design is key for product consistency, user experience, quality and security. The design starts from conceptual, to preliminary design and detailed design.

Lets work on the following examples.

Functional Requirements: these types of requirements represent the essential functions for the ZCM products or ZCM Systems. Something to be performed by the product or system. These are normally higher level requirements. Functional requirements must be satisfied consistently within the different modules and system components.

• Example #1 “Module Improvement”: There is a main need to improve the look and feel of a certain module or ZCM Section. This module has several screens and to achieve this objectives several o many smaller requirements will be created.”
• Example #2 “New Feature”: a new feature needs to be introduced. In order to introduce this new feature several screens within different modules of the system has to be updated.”
• Example #3 “New System Module”: a new system module is being developed according to the system roadmap. This new module will surely have a few or several screens.”

Foundational Requirements: these types of requirements represent the security requirements based on ISA/IEC-62443-4-2 matching the SL-T=3. The ZCM System must meet a minimum of Security Level 3. Foundational requirements must be satisfied consistently within the different modules and system components.

Technical Requirements: the functional requirements are converted into more specific and detailed technical requirements. A functional may require a group of individual technical requirements for a consistent implementation within the system or products. A detailed technical requirement should contain more detailed requirements grouped by functional, non-functional, and security requirements.

Security Requirements: the foundational requirements are converted into more specific and detailed security requirements. A foundational requirement may require a group of individual security requirements for a consistent implementation within the system or products. A detailed security requirement should contain more detailed requirements grouped by FR1, FR2, FR3, FR4, FR5, FR6, and FR7.

Development Requirements: all technical and security requirements can be converted into a more specific development requirements for the individual programmers. More specific instructions with appropriate language and wording for programmers may be needed.

Picture 2: Structure of Requirements

Coding

Coding Best Practices: consists of a list of requirements, standards, styles, comments, and different criteria for developing and writing code.

SPRINT: consists of a group of technical and/or development requirements which is being used by the development team during a monthly development cycle.

Code Auditing: the written code must be evaluated against secure code practices and best coding practices. The code must be reviewed before passing to the next environment.

Testing

Testing, verifying, validating and formal acceptance needs to be executed progressively. Each individual development needs to be tested for errors, mistakes, coding practices before performing an integration test.

Individual Tests:  each specific development requirement needs to be tested within the development and/or testing environment before performing an integration test.

Integration Tests: Different developments might be needed to complete functional and/or foundational requirement. An integration test needs to be performed to verify the systems works as pretended and designed. The group of technical and security requirements needs to be tested within the testing environment before gluing into a system update with the intention to be accepted for production environment.

• Example #1 “Module Improvement”: There is a main objective to improve the look and feel of a certain module or ZCM Section. This module has several screens and to achieve this objectives several o many requirements will be created. Each individual requirement will be tested against its specific objective. But, is the main objective to change the look and feel of the entire module as pretended achieved? In order to validate and verify the main objective, an integral or integration test over the entire module needs to be performed.
• Example #2 “New Feature”: a new feature may require to introduce changes on several screen within different modules of the system. The new feature needs to be introduced consistently within the ZCM System on all screens, the reports, etc. The integral test to verify and validate that the changes have been introduced consistently must be performed before moving to QA.
• Example #3 “New System Module”: a new system module surely have a few or several screens. The system module cannot be moved into a formal approved QA release until all its parts are fully functional and ready to be used. Partial delivery to the customer is not acceptable. The integral test must verify and validate that the new module is fully functional and usable.

If you by a pair of shoes, you expect to receive the two shoes and not just the left shoe, sometime later the right shoe, and sometime later the shoelaces. Without the complete pair of shoes you cant walk. Partial deliveries to the user is typically unacceptable.

Update or Package: contains a collection of technical and/or developed requirements to be rigorously tested, verified, and accepted to be published as a new release to be used at a customer runtime environment.

Functional and Foundational Acceptance Test (FSA): it consists of a Functional and Foundational Specification Acceptance testing and verification carried out by the QA team on a dedicated QA environment where the new update or packed will be tested against use cases and stress cases. The final acceptance test needs to be executed and documented as a proof and evidence that all requirements are met and documented before a formal release.

Picture 3 – Testing Compliance and Quality Assurance

Use Case: methods and procedures to test and verify that the system or product works as expected. The functional requirements and/or its essential functional are performed impressively, consistently, and are clear to the user or users. If the user follows the instructions, the product must perform well with quality, and free of bugs.

Stress Case: method and procedures to test and verify that the foundational security requirements are met. It can be a malicious, penetration testing, certain types of wrong use (non-intentional damage) or attacks (intentional damage).

Teams

The following definitions apply to this program.

Business Team: it is the sector of WisePlant that generates the RQ for the development and finally proceeds with the acceptance of the different developments that are released at the end of the testing process.

Development Team: team of programmers who participate in the development of the different SPRINT and maintenance of the infrastructure and work tools to be used at development and production stages.

Testing Team: the group of people responsible for testing, verifying, and accepting the new release to be posted to the ZCM active users.

Production Team: the group of people in charge of the production of ZCM systems for customers.

Design & Development Process

The following sections describes the process of converting conceptual design or ideas into detailed design specifications for development and testing procedures to a final delivery for production.

All activities related to the process must be registered and recorded through the SLDP audited and supervised tools, including minutes of meetings, idea development, requirements, specifications, instructions, tests, results during the entire lifecycle of the certified products and systems.

Only authorized systems, tools, and infrastructure provided by WisePlant must be used. Team members cannot uses unauthorized tools, system, hosting, etc.

Minutes of Meetings

To ensure compliance to the secure management process SM 1 “Secure Management” the teams members must register the formal meetings and produce evidence of all topics being discussed.

Backlog of Ideas & Improvements

This section contains a backlog list of ideas for analysis and further definitions. The backlog is used as a funnel to create functional and foundational requirements. Many times these ideas requires a deeper and detailed design with technical and security requirements.

The business team is responsible for managing and determining its priorities. The lists of ideas will incubate the necessary time until it can be moved to the next stage and materialized into a Functional & Foundational Design Specification.

Any member from the team with system privileges can create and propose an idea, but it still is the business team responsibility to manage them. Occasionally, an evaluation can be carried out by also involving the Development and DevOps areas to ensure that there are no technical impediments in the new requirement.

Functional & Foundational Requirements

This section contains Functional & Foundational Requirements. Functional requirements focus on essential functions, while foundational requirements focus on security requirements.

A functional requirement can be spited into several technical requirements, while a foundational requirement can be spitted into several security requirements.

A functional or foundational requirement might involve changes on different system modules, forms, screens, scripts and forth to assure consistent and meaningful to the user. Typically a group of technical and security requirements must be finished and tested together before updating a product release.

Technical & Security Requirements

These are smaller requirements typically grouped together to implement a functional or foundational requirements.

This section contains specifications for technical more specific Technical and Security Requirements (TRQ). The Functional and Foundational Requirements are converted into one or more technical and security requirements (TRQ).

The technical and security requirements are integrated together and a more detailed and specific requirements is built to be passed to the programmers in their own language. Specific instructions might be added to the higher level requirements, such as tables, specific code to be used, variables, libraries, and such.

Bugs, Vulnerabilities, Defects & Fixes

This section contains a list of bugs, defects, inconsistencies, incomplete, failing behavior, or vulnerabilities which needs to be resolved. Usually all these requirements are for immediate implementation into the ZCM system. Eventually a deeper analysis might be required depending on the magnitude or complexity of the reported defect.

SPRINT & Releases

This section contains a group of Development Requirements related to the creation of a new release. This includes que preparation, packing, testing, verifying, and accepting. A new release is created after a SPRINT on monthly cycle. The new release is published on the 3rd Thursday of each month, the same as Microsoft does.

Document History

• Document ID: SDLP-PRO-DEV
• Title: Secure Design & Development Process
• References: SDLP Secure Development Lifecycle Program