[Owasp-leaders] Public consultation of Greek governmental agency on software projects requirements

Konstantinos Papapanagiotou conpap at di.uoa.gr
Thu Feb 17 04:07:09 EST 2011


The Greek General Secretariat of Information Systems (GSIS -
practically the equivalent of the IT department of IRS) has just put
up for consultation "technical requirements for software development
projects of GSIS". So far there are 8 comments and no single word
about security.

Below is a quick translation of the requirements that are up for
public consultation (https://apps.gov.gr/apps2/minfin/ggps/?p=101).
During the next few days I'll be commenting on security as a local
OWASP leader. This is an excellent opportunity to further engage with
the Greek government, also following the results of the Summit.

Please feel free to provide your suggestions. Deadline for
consultation is February 28th.


The GSIS in an effort to standardize procedures for software
development, has come up with a proposal for the requirements that
should be met by contractors who undertake software development
projects and applications developed in-house. These proposals for
consultation are the following:

- Version management (version control)
All software on which the GSIS can rightfully have access to source
code is stored in system management publications. The system is
provided by the GSIS and the precise method and the access protocol
and the respective rights and roles are given by the GSIS. Access is
always individual, in line with the security regulation of GSIS. The
accounts have access according to the duration of the various
activities during software development phases. The validity period is
determined and controlled by the head of the project.

- Management issues (issue tracking)
All actions are monitored on a system management platform. The system
is provided by the GSIS and access is given for a specific period as
defined above for version management.

- Use of FOSS licenses
When the service is relevant (eg to promote public and general
interest from adopting OSS), the supplied software should be
accompanied by a corresponding FOSS license. The same applies to
documentation, with a corresponding license.

- Unit Testing
The software should include  automated test scripts correctness of
each of its basic functional units (unit testing). The degree of
completeness of the scenarios is tested as a deliverable.

- Integration Testing
The software should include automated scripts that check the
correctness of communication between functional units (integration
testing). The degree of completeness of the scenarios is tested as a

- System testing
The software should include testing scenarios for the whole control
system on a larger scale (system testing). The degree of completeness
of the scenarios is tested as a deliverable.

- Automation Development
The various procedures relating to the development across its entire
spectrum (eg translation of source code in binary form (compilation /
build), producing code documentation, install the application in
execution environment (deployment)) are performed in a mechanical /
automated way, which is assessed as a deliverable.

- Reusable functions / Interoperability
If a software project provides functionality with potentially reusable
materials (eg single sign on), this functionality is well and
independently documented, so that it can be reused in other software
projects. We place great emphasis on the reuse of software / services
as components (components) and enrichment of existing and discourage
multiple functionalities implemented in a similar / same nature. We
follow these principles, particularly regarding interoperability of
systems and -by extension- agencies.

- Ενσωμάτωση στο υπάρχον περιβάλλον
Λαμβάνουμε πάντα υπόψη τις υφιστάμενες δομές, τη γενικότερη
αρχιτεκτονική/τοπολογία συστημάτων. Ως παραδοτέο ελέγχεται η
τεκμηρίωση εγκατάστασης λογισμικού σε υπάρχουσα ή όχι υποδομή, και οι
οποιεςσδήποτες αλληλεξαρτήσεις σε όλα τα επίπεδα (δικτυακό, συστεμικό,
εφαρμογών). Τα παραδιδόμενα συστήματα (υλικό, λογισμικό κλπ) οδηγούν
στην ενημέρωση των αντίστοιχων «αρχιτεκτονικών χαρτών» της υπηρεσίας,
που δείχνουν ανά πάσα στιγμή την οργάνωση σε διάφορα επίπεδα.

- Integration into existing environment
Always take into account existing infrastructure, the overall
architecture / topology of systems. We assess as a deliverable the
documentation of software installation on existing or not,
infrastructure and any interdependencies at all levels (network,
systemic, applications). The delivered systems (hardware, software,
etc.) lead to the update of the corresponding "architectural maps" of
the agency that demonstrate at any given time the organization at
various levels.

- Delivery procedures
The delivery of partial functionality is supported operationally,
procedurally and technically from the version management systems and
issue tracking systems as well as the provision for automatic growth.

- Documentation
There is documentation for all phases and all agreed deliverables and
functional specifications / requirements. Especially, documentation is
required for new administrative / departmental procedures introduced
by new software / service or for enriched existing procedures. E.g.
call center support procedures.

- Using technology supported
The software is implemented to develop technologies that support the
strategic directions of the agency.

More information about the OWASP-Leaders mailing list