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

Colin Watson colin.watson at owasp.org
Thu Feb 17 04:38:37 EST 2011


Kostas

This is a great thing to do.  If you just had to highlight one thing,
I'd suggest ASVS.  If two, I'd add SAMM.

Depending upon the purpose and level of the documents you might want
to look at the draft Code Of Conduct for Government Institutions
(produced at the summit), and also skim through what other agencies
and groups have documented - see
http://www.owasp.org/index.php/Industry:Citations  Some of those like
documents from CLUSIF and the former NISCC are highly detailed.

I'd also encourage the Greek chapter, and other chapters in Europe, to
let ENISA know about themselves for the Who-Is-Who directory
http://www.enisa.europa.eu/act/sr/files/deliverables/who-is-who-directory-on-nis-ed.-2009/at_download/fullReport
by (see p415) emailing directory at enisa.europa.eu (see UK entry on p314
as an example).

Colin

2011/2/17 Konstantinos Papapanagiotou <conpap at di.uoa.gr>:
> Leaders,
>
> 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.
>
> Kostas
>
>
>
> 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
> deliverable.
>
> - 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.
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>


More information about the OWASP-Leaders mailing list