Skip to main content

System Acquisition, Development and Maintenance Standard

  1. Security requirements of information systems
    1. Software applications are developed or acquired to support WSSU in the achievement of its mission. These applications generally store, manipulate, retrieve and display information used to conduct WSSU activities. WSSU departments and customers become dependent on these applications, and it is essential the data processed by these applications be accurate, and readily available for authorized use. It is also critical that the software that performs these activities be protected from unauthorized access or tampering.
    2. To ensure that appropriate security is built into all WSSU information systems, all security requirements, including the need for rollback arrangements, must be identified during the requirements phase of a project and justified, agreed to and documented as part of the overall business case for a WSSU information system.
    3. Security requirements and controls must reflect the value of the information assets involved and the potential damage that might result from a failure or absence of security measures. This is especially critical for the web and other online applications. The framework for analyzing the security requirements and identifying controls to meet them is associated with threat assessment and risk management which must be performed by the information owner and technical support staff.
    4. A process must be established and implemented for critical applications to:
      1. Understand the business risks and develop a profile of the data to help to understand the risks
      2. Select security measures based on the risk profile and protection requirements
      3. Select and implement specific controls based on security requirements and technical architecture
      4. Provide a method to test the effectiveness of the security controls
      5. Develop processes and standards to support changes, ongoing management and to measure compliance.
    5. Controls in systems and applications can be placed in many places and serve a variety of purposes. The specific control mechanisms must be documented at the application level. At a minimum, the security measures that are implemented must be based on the threat and risk assessments of the information being processed.
  2. Security in development and support processes
    1. Where possible, separating development, test and operational facilities is important to achieve segregation of the roles involved. Rules for the transfer of software from development to operational status must be defined and documented.
    2. Development and test activities can cause serious problems, e.g. unwanted modification of files or system environment, or of system failure. The level of separation that is necessary, between operational, test and development environments, to prevent operational problems must be considered to ensure adequate protection of the production environment. Where possible, a similar separation must also be implemented between development and test functions. In this case, there is a need to maintain a known and stable environment in which to perform meaningful testing and to prevent inappropriate developer access.
    3. Where development and test staff have access to the operational system and its information, they may be able to introduce unauthorized and untested code or alter operational data. On some systems, this capability could be misused to commit fraud, or introduce untested or malicious code. The untested or malicious code can cause serious operational problems. Developers and testers also pose a threat to the confidentiality of operational information.
    4. Development and testing activities may cause unintended changes to software and information if they share the same computing environment. The separation of development, test and operational facilities are therefore required to reduce the risk of accidental change or unauthorized access to operational software and business data. The following controls must be considered:
      1. Development and operational software must, where possible, run on different computer processors, or in different domains or directories
      2. Development and testing activities must be separated as far as possible
      3. Compilers, editors and other system utilities must not be accessible from operational systems when not required
      4. Different log-on procedures are recommended for operational and test systems, to reduce the risk of error. Users will be encouraged to use different passwords for these systems, and menus should display appropriate identification messages
      5. In situations where separate development and production support staff exist, development staff will only have access to operational passwords where controls are in place for issuing passwords for the support of operational systems. Controls must ensure that such passwords are changed after use.
  3. Test data

    Test data must be protected and controlled. Live operational data must never be connected to a testing environment. Acceptance testing usually requires large volumes of test data that closely resembles operational data. The use of test data populated from operational databases containing sensitive information requires that those performing the tests are authorized by the appropriate data custodians to access such information.