Menu
Home > Policies > Policy & Procedure >
Policy & Procedure
Policy Title :
System Development Policy
Policy Number :
VIII. 5
Responsible Party :
Information Technology
Effective Date :
08/01/2014
Revised Date :
_______________________

Purpose

The objective of this Information Security Policies is to secure PMU’s Information Assets and staff.

Eachin this is standards, to a security the

Statement :

This functional policy covers PMU’s Systems Development and Maintenance. It is essential that security is built into information systems and not bolted on afterward. Therefore ITD will document the security and control requirements to be determined during system design, development of the system architecture and to be implemented in the final system. Effective security related change control procedures will be in place to ensure changes occur to the system in a controlled and secure environment with minimal risk to the “live” environment.

It is each user’s responsibility and obligation to ensure that all IT resources are used only for its intended business purpose and that information contained or transmitted via these resources are protected from unauthorized use, appropriation, or corruption.

Procedure :

·       Scope

●     All Information Assets (Digital Media)

●     All software assets

●     All physical assets, such as computer and network equipment.

●     All supporting services, such as power and network link

●     All management information systems

●     All business activities supported by PMU.

●     All of the above are either owned or leased by the PMU and under PMU’s possession, custody, or control.

 

General Responsibilities

 

It is the responsibility of the different departments/offices and each employee to take necessary steps for ensuring compliance with the guidelines in this policy, and any further Policies and Procedures that may be added in due course of time.

 

Systems Development and Maintenance Functional Policies

Roles and Responsibilities

Project Management

The Project Managers responsibilities include, but are not limited to the following:

●     Provides overall direction for the project;

●     Ensures appropriate representation of affected users and business units if necessary;

●     Monitors and controls costs and project timetable; and

●     Ensures deliverables are a quality product.

●     Ensure adequate implementation of security policies.

Project Planning

 

Purpose of Project Planning

Planning must be done for development of new systems/applications and for any major and/or minor enhancements to systems/applications.

 

Creation of Project Plan

 

 

Project Plan creation must include consideration for the following:

●     The allocation of personnel and information resources needed for analysis, design, implementation, administration, and maintenance.

●     The plan must include a discussion of specific goals as an integral part of the system requirements.  This must include:

●     Documentation of known constraints, which could impede proper development;

●     Processes to ensure adequate security has been addressed, such as security reviews.

●     All cost estimates must include the cost of analysis, design, implementation, and ongoing administration and maintenance.

●     All time estimates must include a reasonable estimate of the time required for a thorough analysis and implementation.

●     The planned reporting structure and hierarchy must include the appropriate management levels needed for approval and control throughout the project, including:

●     Requirements will be defined, and specifications approved by the Owner prior to acquiring or starting development of any applications; and

●     Recoverability processes must be considered during planning since this could influence the selection of computing platforms and database management systems.

 

Analysis of the System/Application

 

Purpose of Analysis

Analysis defines the features and functions of the system or application and provides the logical system specifications from which requirements will be defined.

Analysis

The following must be included during the analysis:

●     A risk analysis to determine the controls required for the system or application under development or acquired, including:

●     Performing a threats and vulnerability analysis. Security vulnerability considerations including those introduced when designing the connectivity or interface with other systems and applications; and

●     Performing a business impact analysis. This must include an analysis of the impact on both existing and new systems and of opening new connections

●     In defining the required operating environment, existing operating system security controls must be utilized (where available).

●     The environment selected must support all requirements of the system or application being developed.

●     Where an application or system has no specific requirements, a statement to that effect should be documented and approved by management.

●     The analysis must balance user’s requirements with required security controls.

●     An acquisition vs. development analysis must include specifications for required academic and business need.

●     Any Request for Proposal or Request for Information used to solicit vendors must include selection criteria for functionality.

 

Design of the System/Application

Purpose of Design

●     Design uses the logical models from analysis and makes them executable.

●     The work done in design provides the basis for actual development of the system or application. System and physical architecture, interfaces, policy processes, and documentation are design components.

 

Requirements in Design

For all systems designed within or for PMU, requirements must be used, which have been determined in the analysis phase, prior to the application development phase. During the system design phase, Information Owners, PMU and Information Security must determine the proper control environment of the application by using the security specifications of the analysis phase.

Development Environment

Securing Source Code under Development

For securing source code under development the following must be adhered to:

●     Source code, including parameter and configuration files, is a valuable information asset and must be protected when in development.

●     Access control to the development environment and authorization control for all data and source code files must be implemented.

●     Developer access must be restricted to only those resources required to perform established job duties.

●     Security audit records capable of providing sufficient information for after- the-fact investigation of loss, impropriety or other inappropriate activity must be generated and reviewed.

●     Source code under development may be at greater risk of being acquired before all copyright protection is in place, thus making it subject to claims of ownership by intruders.

●     Programmers must maintain documentation of their program development and changes in order to legally support claims of ownership for software not yet copyrighted.

●     Systems/applications documentation must be prepared and maintained throughout the development/maintenance lifecycles to ensure continuity.

 

Management of Changes to Source Code under Development

Management of changes to source code under development must conform to the following:

●     Version control must be utilized for ensuring ongoing management of changes to the source code. An automated process with specific version tracking functionality or a policy procedure may provide version control.

●     Source code under development must be backed up and secured from unauthorized access.

●     Changes to source code must allow for rollback. Rollback will enable the developer to restore source code to its original state if necessary.

●     Changes to source code under development must be part of the change control process.

●     System/Application documentation should be updated when changes are made.

●     Changes to source code must be evaluated by a second person to review if any inappropriate code has been included (i.e. Trojan horses, etc).

Test  vs. Production Environments

The following must be adhered to for the test and. production environments:

●     Development and testing must be performed in an environment which is separate from production, either physically or logically, to ensure that testing and production processing cannot impact each other.

●     If possible, testing should not involve any components of the production environment, including software, hardware, and network connectivity.

●     Testing should be done only with test data; production files and data must never be impacted by the development process.

●     If access to production environment is required, such access must be approved by the Information Owner and must be limited to read only.

●     Copies of production data may be used for testing, after scrambling where feasible, if they are controlled to the same degree as in production.

●     Sensitive data should be sanitized or deleted from the created test data.

●     Production processing must be performed only with production data. Production data must never be impacted by the testing process.

●     Development hardware must not be migrated to a production environment until all development and testing is completed and proper signoff was obtained.

●     It is recommended that the operating system and all file systems be reinstalled and reinitialized to ensure that all production security controls are in place.

●     Measurements need to be in place to ensure that the tested system is transferred to production without any alterations (e.g. using checksums).

 

Testing of the System or Application

Purpose of Testing

●     Testing verifies that the features and functions of the system or application are in line with the development specifications and ensures that its operation is compatible with the environment in which it will run.

●     During testing, the test scenarios are designed for unit, system, integration, and acceptance testing.

●     All tests are executed and the results are logged and evaluated. All errors must be corrected during testing and before implementation.

 

Security Requirements for Testing

Security must be integrally included in unit, system, integration, and user acceptance tests. This includes both developed and purchased software.  In all cases:

●     Test plans must include time and resources to sufficiently test all aspects of the security functionality.

●     Scenarios for testing security must be designed in attempt to defeat or circumvent security.

●     Testing procedures must be properly documented on the change request forms.

●     During integration and acceptance testing, logical access restrictions must ensure that developers have no update access and that the code being tested cannot be modified without written consent of the user.

●     Both successful and unsuccessful access attempts must be tested and the appropriate audit logging must be verified.

●     The developer must supervise unit testing in the testing environment. The developers manager must then perform an independent review of these results.

●     As part of the test, verification must be done to ensure that the newly developed system or application does not introduce vulnerabilities in existing structures, common networks and systems.

●     If test data must be transmitted to an external site, other than to the ultimate recipient, to complete a test, all sensitive or proprietary information in the data must be sanitized or deleted.

●     If the system or application is intended to execute on more than one type of platform, security must be tested in each of the possible operating environments.

●     Testing of security administration functions is required.

●     If the software being tested was purchased, it may be advisable to have a technical representative from the vendor onsite during the testing.

●     The system or application must be tested when the security function is down to ensure that access is not allowed.

●     All testing logs and evaluations must be secured and marked.

●     Where a mechanized scanning tool is available, a vulnerability scan must be completed for all new systems prior to being approved for production. The tools used for such scans must not be distributed to the developers or any persons other than security or system administrators.

●     All significant modifications, major enhancements and new systems must be integration and acceptance tested prior to installation of the software in production.

●     Volume and stress testing for the security functions must be included in the test plan. If possible, maximum user access should be simulated to measure the response of the system.

●     Backup and recovery processes for the system or application and for any databases must be tested.

●     Disaster Recovery Plans must be tested and updated to ensure changes to systems/applications are adequately addressed.

●     All tests performed must be signed off in the test plan/test script by staff who performed the test and must be approved by the Business Owner.

 

Unit Testing

●     The developer will supervise unit testing in the development environment.

●     Testing procedures must be properly documented and the developer's manager must perform an independent review of unit test results.

●     If problems are noted, the developer will document the problem, make appropriate modifications in the development environment.

 

Integration Testing

●     All significant modifications, major enhancements and new systems will follow integration testing prior to installation of the software in production.

●     System stress testing and volume testing must be performed, and in some cases, parallel testing will be required.

●     Integration testing must be conducted in a separate, independently controlled environment.

●     During integration testing, logical access restrictions must ensure that developers have no update access and that the code being tested cannot be modified without the written consent of the user.

●     Copies of production data, sanitized from any customer data, or pre- designed test datasets must be used for testing purposes..

 

 

User Acceptance Testing

●     All significant modifications, major enhancements and new systems must be acceptance tested by the appropriate users, prior to installation of the software in production.

●     The user acceptance plan will include tests of all major functions, processes and interfacing systems.

●     Testing procedures must be properly documented on the change request forms.

●     During acceptance testing, logical access restrictions must ensure that developers have no update access and that the code being tested cannot be modified without the written consent of the user.

●     If problems are noted, the user will document the problem, the developer will make appropriate modifications in the development environment and submit it to CASD for re-testing.

Implementation of the System or Application

Purpose of Implementation

●     Implementation installs the system or application into production.

●     During implementation, data is converted as needed, and live processing begins.

●     Users and operators should be trained before implementation.

 

 

Requirements for Implementation

Before moving a system or application into production, the following must be accomplished:

●     An operational readiness review must be completed which includes evidence of the following items at a minimum:

○     Compliance with the current PMU IT Architecture;

○     Satisfactory completion of vulnerability scanning, where feasible;

○     Preparation of a Disaster Recovery/Contingency Processing Plan; and

○     Assignment of an appropriate number of qualified System and Security Administrators.

●     A backup of all existing files and databases that will be impacted must be done before beginning implementation.

●     After successful installation, all developer access must be removed to the production environment.

●     If multiple sessions were allowed for any testers or other users, they should be reviewed in production and limited if no longer needed or conflicts with existing access.

●     Approval to move software from development to production must be obtained.

●     Approval to move software from production to development must be obtained within the formal change management process.

●     Security administrators and users must be fully trained on the new functions.

●     Any policy security processes required for implementation must be in place.

●     Availability of a facility to print security reports, such as:

○     Security violations;

○     User profiles and access rights; and

○     User administration activities.

●     Personnel to review and monitor audit intrusion reports must be available and trained.

●     For purchased software, a written vendor statement that all security controls have been successfully implemented and are functional must be obtained.

●     Only object code should be distributed to end users.

●     Rollback plans need to be in place.

●     License data on all purchased software distributed must be maintained.

●     If the new system or application is replacing an existing system, procedures for maintaining security administration on both systems during the implementation must be established.

●     Ensure the correct version is installed (the version that was tested and signed off).

●     Ensure the necessary SLA is in place and signed.

 

Maintenance of Systems or Application

General Maintenance Information

General maintenance information includes:

●     Maintenance of systems and applications begins after the system or application is stable and no longer under development and continues over the life of the system.

●     It includes day-to-day system/application monitoring, tuning for performance purposes, scheduled and emergency maintenance functions, problem management to correct faults and to adapt to business change, change control for system enhancements, and security administration.

●     Maintenance actions must be planned and must sufficiently cover the maintenance of security functionality of systems/applications.

 

 

Monitoring of Systems and Applications

Monitoring of systems and applications must be in accordance with the following:

●     Systems and applications are only valuable if they are available at the required times. All parties involved must ensure that procedures to support operational monitoring of all production systems and applications are in place.

●     Dated and time stamped logs should be produced to aid in evaluating the operations. Examples of areas to monitor include:

○     Outages and downtime;

○     Volume of usage for data and users;

○     General system response time; and

○     System and resource access.

Emergency Maintenance Procedures

Emergency procedures for correcting unpredicted software errors must include:

●     The ability to grant sufficient access to enable the maintenance personnel to accomplish the task.

●     As soon as the emergency is past, details of the changes implemented must be documented.

●     This documentation should include the following details:

○     The change requestor;

○     Authorization for change;

○     Short description of the required change; and

○     The time frame in which the change was required.

●     Normal maintenance or change control procedures should be applied retroactively.

●     Emergency changes to programs should be made to separate copies of the programs to allow production work to continue.

●     After the emergency, implementation approval as used in change management should be utilized.

●     If it was necessary to grant special access to production resources, activities must be monitored and logged.  After the emergency, all such access must be revoked.

 

The installation of any type of back door that circumvents security controls is prohibited.