1256
U

Eigenschap:Beschrijving

Uit NORA Online
Ga naar: navigatie, zoeken
KennismodelKennismodel NORA
TypeTekst
Geldige waarden
Meerdere waarden toegestaanNee
Weergave op invulformulierenTekstvak
Defaultwaarde
ToelichtingDeze elementeigenschap kan gebruikt worden om een element te voorzien van een beschrijving.
Specialisatie van



Deze eigenschap wordt gebruikt door de volgende elementtypen:


Pagina's die de eigenschap "Beschrijving" gebruiken

Er zijn 25 pagina's die deze eigenschappen gebruiken.

(vorige 25 | volgende 25) (20 | 50 | 100 | 250 | 500) bekijken.

A
Architectuurproducten +Normatieve en descriptieve documenten die huidige/toekomstige architectuur van een organisatie/domein schetsen.  +
Authenticatie +Het aantonen dat degene die zich identificeert ook daadwerkelijk degene is die zich als zodanig voorgeeft: ben je het ook echt? Authenticatie noemt men ook wel verificatie van de identiteit.  +
Authenticiteit +Een kwaliteitsattribuut van een informatieobject. Het toont aan dat het informatieobject is wat het beweert te zijn, dat het is gemaakt of verzonden door de persoon of organisatie die beweert het te hebben gemaakt of verzonden en dat het is gemaakt en verzonden op het tijdstip als aangegeven bij het informatieobject.  +
Authentiek gegeven +In een basisregistratie opgenomen gegeven dat bij wettelijk voorschrift als authentiek is aangemerkt  +
Autorisatie +Het proces van het toekennen van rechten voor de toegang tot geautomatiseerde functies en/of gegevens in ICT voorzieningen  +
Autorisatie +Voor de betiteling ‘Beperking toegang tot informatie’ is gekozen om het object “Autorisatie’ te gebruiken omdat het beter aansluit op een van toegangsmechanismen, identificatie, authenticatie en autorisatie. Na het identificatie- en authenticatieproces krijgen gebruikers/beheerders verdere specifieke toegang tot informatiesystemen voor gebruik of voor beheerdoeleinden. De toegangsbeperking wordt gecreëerd door middel van rollen en toegangsprofielen die voortkomen uit de het toegangsbeleid.  +
Autorisatieproces +De ISO en BIO control 9.2.6. ‘Toegangsrechten intrekken of aanpassen’ stelt eisen aan een autorisatieproces, dat bestaat uit enkele sub-processen zoals: toekennen (of verlenen), verwerken, intrekken, blokkeren, archiveren en controleren. Dit autorisatieproces zorgt ervoor dat autorisaties gestructureerd plaatsvinden. Deze sub-processen zijn gerelateerd aan de fasen: instroom, doorstroom en uitstroom. Deze sub-processen worden verdere in bijlage 3 beschreven.  +
Autorisatieproces onwerkbaar, hoge beheerlast en complexiteit door te hoge granulariteit +Autorisatieproces onwerkbaar, hoge beheerlast en complexiteit door te hoge granulariteit.  +
Autorisatievoorzieningsfaciliteiten +Om autorisatie efficiënt en effectief te kunnen inrichten zijn er technische autorisatievoorzieningsmiddelen noodzakelijk, personeelsregistratiesysteem, een autorisatiebeheersysteem en autorisatiefaciliteiten.  +
B
BAG (Basisregistratie Adressen en Gebouwen) +De Basisregistratie Adressen en Gebouwen (BAG) is de registratie waarin gemeentelijke basisgegevens over alle gebouwen en adressen in Nederland zijn verzameld. De BAG is gebaseerd op de Wet basisregistraties adressen en gebouwen. Gemeenten zijn bronhouder van de gebouw- en adresgegevens. Alle bestuursorganen zijn verplicht om vanaf 1 juli 2011 gebruik te maken van de BAG bij de uitvoering van hun publiekrechtelijke taken.  +
BAG/BAG viewer +Website waar een BAG-kaart getoond wordt. Klikken op panden toont de onderliggende pand- en verblijfsobjectgegevens. Viewer toont actuele en historische gegevens. [https://bagviewer.kadaster.nl/lvbag/bag-viewer/index.html BAG viewer op website Kadaster].  +
BAG/Compact eenmalig of abonnement +BAG Compact is een XML-bestand met alle BAG-adressen op basis van een vaste peildatum van heel Nederland. Behalve adressen bevat het bestand ook adresgerelateerde elementen uit de LV BAG. [http://www.kadaster.nl/web/Themas/Registraties/BAG/BAG-product/BAG-Compact.htm BAG Compact] op website Kadaster.  +
BAG/Digilevering +Abonnementenservice om realtime een bericht te ontvangen bij een wijziging in de LV BAG. [http://www.kadaster.nl/web/Themas/Registraties/BAG/BAG-product/BAG-Digilevering.htm BAG Digilevering] op website Kadaster.  +
BAG/Extract +Levering van een totaalstand van alle BAG-gegevens voor het gevraagde gebied (volledige levenscyclus of op peildatum). Mogelijk om te selecteren op gemeente, meerder gemeenten of geheel Nederland. Een bestand van heel Nederland is permanent beschikbaar met een vertraging van maximaal één maand. Bij een abonnement bestaan twee varianten: óf periodieke (maandelijks/dagelijks) levering van de wijzigingen ten opzichte van de voorgaande levering óf maandelijks een levering van de een totaalstand. [http://www.kadaster.nl/web/Themas/Registraties/BAG/BAG-product/BAG-Extract.htm BAG Extract] op website Kadaster.  +
BAG/Extract mutaties +Bij een abonnement bestaan twee varianten: óf periodieke (maandelijks/dagelijks) levering van de wijzigingen ten opzichte van de voorgaande levering óf maandelijks een levering van de totaalstand.  +
BAG/Geocodeerservice +Zoekservice van [https://www.pdok.nl/diensten#PDOK%20Locatieserver PDOK] waar men kan zoeken op administratiegegevens om daarna naar de positie op de kaart van het gegeven te gaan. Bij gegevens kan men denken aan o.a. adressen, straten, woonplaatsen (BAG), maar ook aan Kadastrale informatie (DKK), weginformatie (NWB), Wijk-en buurtinformatie en Waterschapsinformatie.  +
BAG/WMS-WFS via PDOK +Biedt BAG gegevens van een in de vraag gespecificeerde geografische contour, hetzij als ‘plaatje’ (WMS) hetzij als data, welke door de afnemer gevisualiseerd, opgeslagen en bewerkt kunnen worden. De WFS service is vooralsnog gemaximeerd op 15000 objecten. *[https://www.pdok.nl/nl/service/wms-bag BAG WMS] op website PDOK. *[https://www.pdok.nl/nl/service/wfs-bag BAG WFS] op website PDOK  +
BAG/bevragen +Webservice voor het geautomatiseerd bevragen van de LV-BAG met behulp van software van de afnemer. BAG Bevragen kan de volledige levenscyclus van een object opvragen. [http://www.kadaster.nl/web/Themas/Registraties/BAG/BAG-product/BAG-Bevragen.htm BAG bevragen] op website Kadaster.  +
BGT (Basisregistratie Grootschalige Topografie) +De Basisregistratie Grootschalige Topografie (BGT) wordt een uniform topografisch basisbestand met objecten in heel Nederland op een schaal van 1:500 tot 1:5.000. Het doel van de realisatie van de BGT is dat de hele overheid gebruik maakt van dezelfde basisset grootschalige topografie van Nederland. Topografie is de beschrijving van de fysieke werkelijkheid. Dus de dingen die in het terrein fysiek aanwezig zijn.  +
BGT Gegevenscatalogus +De BGT vormt de kern (verplichtende deel) van het informatiemodel geografie (IMGeo). De verdiepingsslag van de BGT die in IMGeo is vastgelegd als het optionele deel, is bedoeld voor het opslaan en uitwisselen van beheer- en plustopografie. IMGeo zorgt ervoor dat wie de optionele informatie wil beheren en/of uitwisselen, dit volgens een landelijke standaard kan doen. IMGeo biedt ook voor 3D uitwisseling van grootschalige topografie een optionele standaard en baseert zich hiervoor op de internationale standaard CityGML.  +
BIO (Baseline Informatiebeveiliging Overheid) +De Ministerraad van 14 december 2018 heeft de Baseline Informatiebeveiliging Overheid (BIO) vastgesteld voor het Rijk en in het interbestuurlijk verkeer met het Rijk. De BIO is: * een gemeenschappelijk normenkader, gebaseerd op de internationale norm ISO 27001/2 voor de beveiliging van de informatie(systemen) van de overheid; * een afgeleide van de huidige [[BIR (Baseline Informatiebeveiliging Rijksdienst)|BIR2017]], die al in werking is voor het Rijk; * een concretisering van een aantal normen tot verplichte overheidsmaatregelen. Iedere overheidslaag heeft besloten de bestaande eigen baseline informatiebeveiliging te vervangen door de BIO. Het gevolg van bovengenoemde besluiten is dat alle overheidsorganisaties hun bestaande sectorale baselines zullen vervangen door de BIO. De BIO vervangt voor de gemeenten, waterschappen, provincies en het Rijk respectievelijk de BIG, BIWA, IBI en de BIR2017. Om te voorkomen dat het Rijk in de informatie-uitwisseling met andere bestuurslagen andere normen gaat eisen, heeft de Ministerraad besloten om de BIO te hanteren in de informatie-uitwisseling tussen het Rijk en alle bestuurslagen. Een PDF-versie is te vinden op [https://cip-overheid.nl/category/producten/bio/#bio-tekst cip.overheid.nl/producten/bio] ==Hulpbronnen voor de toepassing v/d BIO in de praktijk== Het [[Centrum Informatiebeveiliging en Privacybescherming (CIP)]] ontwikkelt i.s.m. het ministerie van BZK de zogenaamde BIO Thema's, die voor een bepaald onderwerp een praktische uitwerking van de BIO betekenen. We ontsluiten die op noraonline in de : → [[ ISOR (Information Security Object Repository)]]. Meer informatie en documenten van het CIP delen zij in het het forum op Pleio : → [https://cip.pleio.nl/ cip.pleio.nl]. Ook de Informatie Beveiligings Dienst (IBD), de sectorale CERT / CSIRT voor alle Nederlandse gemeenten, heeft een set met praktische documenten gepubliceerd, zoals een template voor een verwerkingsregister en handreikingen voor (gemeentelijke) processen zoals dataclassificatie in het kader van de BIO. : → [https://www.informatiebeveiligingsdienst.nl/producten/ informatiebeveiligingsdienst.nl/producten/]  +
BIO Thema Applicatieontwikkeling - Geïdentificeerde objecten ingedeeld naar IFGS +. [[Afbeelding:Thema Applicatieontwikkeling - Geïdentificeerde objecten ingedeeld naar IFGS.png|thumb|350px|none|alt=”Geïdentificeerde objecten ingedeeld naar IFGS”]]  +
BIO Thema Applicatieontwikkeling - IFGS gekoppeld aan het V-model +. [[Afbeelding:Thema Applicatieontwikkeling - IFGS gekoppeld aan het V-model.png|thumb|350px|none|alt=”IFGS gekoppeld aan het V-model”]]  +
BIO Thema Applicatieontwikkeling - Identificatie applicatieontwikkeling objecten +== Identificatie applicatieontwikkeling objecten== Objecten voor applicatieontwikkeling worden gerelateerd aan de ontwikkelfasen geïdentificeerd aan de hand van onderzoeksvragen en risicogebieden. De objecten zijn afgeleid van de invalshoek van de algemene beveiligingseisen: Beschikbaarheid, Integriteit, Vertrouwelijkheid en Controleerbaarheid (BIVC) die vervolgens zijn ingedeeld in de drie domeinen: Beleid, Uitvoering en Control. De vragen die hierbij een rol hebben gespeeld zijn: * welke randvoorwaardelijke elementen spelen vanuit de optiek van BIVC een rol bij applicatieontwikkeling en -onderhoud en wat is de consequentie bij afwezigheid hiervan; * welke elementen spelen vanuit de optiek van BIVC een rol bij applicatieontwikkeling en wat is de consequentie bij afwezigheid hiervan; * welke elementen spelen vanuit de optiek van BIVC een rol bij de beheersing van applicatieontwikkeling en wat is de consequentie bij afwezigheid hiervan? ===De organisatie van applicatieontwikkelobjecten=== Zoals al in ISOR:Ontwikkelcyclus van applicatieontwikkeling is aangegeven worden de geïdentificeerde applicatie objecten op basis van de lagenstructuur: Beleid domein, Uitvoering domein en Control domein georganiseerd. Hiermee worden deze aspecten in de juiste contextuele samenhang gepositioneerd. De betekenis die aan de lagen wordt toegekend, zijn: 'Beleid domein': Binnen dit domein bevinden zich conditionele elementen over de applicatieontwikkeling. Hier zijn eisen opgenomen ten aanzien van ‘geboden’ en verboden’, zoals applicatiebeveiligingsbeleid, de te hanteren wet en regelgeving en andere vormen van reguleringen en beperkingen. 'Uitvoering domein': Binnen dit domein bevinden zich: * elementen die gerelateerd zijn aan operationele activiteiten ten aanzien van het ontwikkelen van applicaties; * elementen die aangeven hoe deze activiteiten georganiseerd moeten zijn; en * elementen die gerelateerd zijn aan beveiligingsaspecten die bij de activiteiten in acht moeten worden genomen. 'Control domein': Binnen dit domein bevinden zich elementen die zorg dragen voor de beheersing van het ontwikkelproces en/of het in standhouden van activiteiten die naar wens verlopen. ===Observatie bij de exercitie van het identificeren van objecten uit ISO=== Uit observatie van de werkgroep blijkt dat bij het identificeren van objecten uit ISO27001 weinig controls te vinden zijn die direct gerelateerd zijn aan de ontwikkelstadia: analyseren, specificeren, ontwerpen en ontwikkelen. Dit komt door het feit dat binnen ISO niet is uitgegaan van de ontwikkelfasen van systeem ontwikkeling en wellicht ook door het feit dat de activiteiten binnen deze fasen gerelateerd zijn aan specifieke methoden en/of programmeertalen. In ISO27001 zijn wel security controls en bijbehorende maatregelen aangetroffen die indirect te maken hebben met de ontwikkelfasen. ===Applicatieontwikkeling objecten geprojecteerd op BUC en gesorteerd naar IFGS=== Tabel 'Overzicht van applicatieontwikkeling objecten ingedeeld naar BUC' geeft een overzicht van de applicatieontwikkeling objecten die in hoofdstukken [[ISOR:BIO Thema Applicatieontwikkeling Beleid|Beleid domein]], [[ISOR:BIO Thema Applicatieontwikkeling Uitvoering|Uitvoering domein]] en [[ISOR:BIO Thema Applicatieontwikkeling Control|Control domein]] nader zijn uitgewerkt. Eerst is door de werkgroepleden, vanuit een ‘baseline-based’ benadering, een lijst gemaakt van de relevante objecten uit verschillende baselines. Los van de baselines zijn enkele objecten door de werkgroep als relevant voor dit thema aangegeven (zie tabel 1). We zijn ons ervan bewust dat deze zogenaamde ‘baseline-based’ benadering tot selectie van objecten leidt die niet allemaal in de huidig wereld van systeemontwikkelingsaanpak thuishoren. We hebben ervoor gekozen om een ‘baseline-based’ toe te passen, om zo de overgang naar de Agile benadering beter te kunnen maken. Uit de inhoudelijke bestudering van de objecten, vanuit de ‘baseline-based’ benadering, bleken toch doublures te zijn in de objecten; m.a.w. twee verschillende objecten die dezelfde inhoud kenden. Sommige objecten hebben we vooralsnog bewust achterwege gelaten vanwege het geringe belang van deze objecten in relatie tot de totale scope. We willen opmerken dat er verschillende termen gehanteerd worden, zoals informatiesystemen, applicaties, systemen, toepassingen. Het op te leveren document moet qua gebruikte termen consistent zijn, daarom hebben wij ervoor gekozen om de term ‘systeem’ in de betiteling van de control (dus het object) aan te passen naar Applicatieontwikkeling. ''Beleid'' [[Afbeelding:Thema Applicatieontwikkeling - Beleid objecten t.a.v. Applicatieontwikkeling gepresenteerd in matrix vorm.png|thumb|350px|none|alt=Beleid objecten t.a.v. Applicatieontwikkeling gepresenteerd in matrix vorm|Beleid-objecten]] ''Uitvoering'' [[Afbeelding:Thema Applicatieontwikkeling - Uitvoering objecten t.a.v. Applicatieontwikkeling gepresenteerd in matrix vorm.png|thumb|350px|none|alt=Uitvoering objecten t.a.v. Applicatieontwikkeling gepresenteerd in matrix vorm|Uitvoering objecten]] ''Control'' [[Afbeelding:Thema Applicatieontwikkeling - Control objecten t.a.v. Applicatieontwikkeling gepresenteerd in matrix vorm.png|thumb|350px|none|alt=Control objecten t.a.v. Applicatieontwikkeling gepresenteerd in matrix vorm|Control-objecten]] <table class="wikitable"> <tr> <th></th> <th>Nr</th> <th>Objecten</th> <th>Referentie</th> <th>IFGS</th> </tr> <tr> <td>Beleid domein</td> <td>B.01</td> <td>Beleid voor (beveiligd)ontwikkelen</td> <td>ISO27002: 14.2.1</td> <td>I</td> </tr> <tr> <td></td> <td>B.02</td> <td>Systeem ontwikkelmethode</td> <td>SoGP</td> <td>I</td> </tr> <tr> <td></td> <td>B.03</td> <td>Classificatie van informatie</td> <td>ISO27002: 8.2.1</td> <td>I</td> </tr> <tr> <td></td> <td>B.04</td> <td>Engineeringprincipes voor beveiligde systemen</td> <td>ISO27002: 14.2.5</td> <td>I</td> </tr> <tr> <td></td> <td>B.05</td> <td>Business Impact Analyse(BIA)</td> <td>SoGP/IR2.2</td> <td>I</td> </tr> <tr> <td></td> <td>B.06</td> <td>Privacy en bescherming persoonsgegevens(GEB/DPIA)</td> <td>ISO27002:18.2.4, CIP Domeingroep BIO</td> <td>I</td> </tr> <tr> <td></td> <td>B.07</td> <td>Kwaliteit managementsysteem</td> <td>CIP Domeingroep BIO</td> <td>F</td> </tr> <tr> <td></td> <td>B.08</td> <td>Toegangsbeveiliging op programmacode</td> <td>ISO27002: 9.4.5</td> <td>G</td> </tr> <tr> <td></td> <td>B.09</td> <td>Projectorganisatie</td> <td>CIP Domeingroep BIO</td> <td>S</td> </tr> <tr> <td>Uitvoering domein</td> <td>U.01</td> <td>Procedures voor wijzigingsbeheer m.b.t. applicaties en systemen</td> <td>ISO27002: 14.2.2</td> <td>I</td> </tr> <tr> <td></td> <td>U.02</td> <td>Beperkingen voor de installatie van software (richtlijnen)</td> <td>ISO27002: 12.6.2</td> <td>I</td> </tr> <tr> <td></td> <td>U.03</td> <td>Richtlijnen voor programmacode(best practices)</td> <td>CIP Domeingroep BIO</td> <td>I</td> </tr> <tr> <td></td> <td>U.04</td> <td>Analyse en specificatie van informatiesystemen</td> <td>Cobit</td> <td>F</td> </tr> <tr> <td></td> <td>U.05</td> <td>Analyse en specificatie van informatiebeveiligingseisen</td> <td>ISO27002:14.1.1</td> <td>F</td> </tr> <tr> <td></td> <td>U.06</td> <td>Applicatie ontwerp</td> <td>SoGP</td> <td>F</td> </tr> <tr> <td></td> <td>U.07</td> <td>Applicatiefunctionaliteiten(invoer, verwerking, uitvoer)</td> <td>ISO27002:12.2.1, 12.2.2, 12.2.4, BIR 1.0</td> <td>F</td> </tr> <tr> <td></td> <td>U.08</td> <td>Applicatiebouw</td> <td>SoGP</td> <td>F</td> </tr> <tr> <td></td> <td>U.09</td> <td>Testen van systeembeveiliging</td> <td>ISO27002:14.2.8</td> <td>F</td> </tr> <tr> <td></td> <td>U.10</td> <td>Systeemacceptatie tests</td> <td>ISO27002:14.2.9</td> <td>F</td> </tr> <tr> <td></td> <td>U.11</td> <td>Beschermen van testgegevens</td> <td>ISO27002:14.3.1</td> <td>F</td> </tr> <tr> <td></td> <td>U.12</td> <td>Beveiligde Ontwikkel- (en Test-)omgeving</td> <td>ISO27002: 14.2.6</td> <td>G</td> </tr> <tr> <td></td> <td>U.13</td> <td>Applicatiekoppelingen</td> <td>ISO25010,NIST CA, CIP Domeingroep BIO</td> <td>G</td> </tr> <tr> <td></td> <td>U.14</td> <td>Logging en monitoring</td> <td>CIP Domeingroep BIO</td> <td>G</td> </tr> <tr> <td></td> <td>U.15</td> <td>Applicatie architectuur</td> <td>ISO25010, CIP Domeingroep BIO</td> <td>S</td> </tr> <tr> <td></td> <td>U.16</td> <td>Tooling ontwikkelmethode</td> <td>ISO25010, CIP Domeingroep BIO</td> <td>S</td> <tr> <td>Control domein</td> <td>C.01</td> <td>Richtlijnen evaluatie ontwikkelactiviteiten</td> <td>ISO27002: 12.6.1, CIP Domeingroep BIO</td> <td>I</td> </tr> <tr> <td></td> <td>C.02</td> <td>Versiebeheer</td> <td>CIP Domeingroep BIO</td> <td>F</td> </tr> <tr> <td></td> <td>C.03</td> <td>Patchmanagement van externe programmacode</td> <td>CIP Domeingroep BIO</td> <td>F</td> </tr> <tr> <td></td> <td>C.04</td> <td>(Software)configuratie beheer</td> <td>CIP Domeingroep BIO</td> <td>F</td> </tr> <tr> <td></td> <td>C.05</td> <td>Quality management</td> <td>CIP Domeingroep BIO</td> <td>F</td> </tr> <tr> <td></td> <td>C.06</td> <td>Compliance Assurance</td> <td>CIP Domeingroep BIO</td> <td>F</td> </tr> <tr> <td></td> <td>C.07</td> <td>Technische beoordeling van informatiesystemen na wijziging besturingsplatform</td> <td>ISO27002: 14.2.3</td> <td>F</td> </tr> <tr> <td></td> <td>C.08</td> <td>Beheersing van softwareontwikkeling(sprojecten</td> <td>CIP Domeingroep BIO</td> <td>S</td> </tr> <caption align="bottom">Applicatieontwikkeling, Overzicht objecten ingedeeld naar BUC</caption></table>  +
BIO Thema Applicatieontwikkeling - Inleiding +==Inleiding== Het belang en de risico’s die de organisatie aan het bedrijfsproces of beheerproces stelt, bepalen inherent de eisen die gesteld moeten worden aan de applicatie(s) die het betreffende proces ondersteunen. De risicobeoordeling van de functionaliteit, gevoeligheid van de gegevens, belang van de applicatie voor de organisatie bepalen of en welke normen van toepassing zijn. Wij willen u erop attenderen dat in dit document de termen applicatie en informatiesysteem worden gehanteerd. De ISO spreekt over informatiesystemen, dit thema betreft applicaties, wat een onderdeel is van een informatiesysteem. Bij de controls hanteren we informatiesysteem om bij de tekst van de ISO te blijven. ===Context Applicatieontwikkeling=== Dit document bevat de uitwerking van het thema ‘Applicatieontwikkeling’. Een applicatie kan worden verworven door interne ontwikkeling, uitbesteding of inkoop van een commercieel product. Dit kan ook door een combinatie van interne ontwikkeling en uitbesteding (zie afbeelding 'Overzicht van type applicaties'). Hierbij kan het voortraject (het specificeren) door de klant zelf worden verricht terwijl het technische deel (het ontwikkelen) door de externe partij wordt uitgevoerd. Hierbij zullen extra afspraken over de beveiligingsaspecten gemaakt moeten worden. Gedurende de ontwikkelcyclus van de applicatie zal voldaan moeten zijn aan zowel functionele als beveiligingseisen. Ook moeten bij de ontwikkeling het informatiebeveiligingsbeleid, wet en regelgeving (o.a. AVG, BIO) en eisen ten aanzien van de technische omgeving worden betrokken. In dit thema zullen de beveiligingseisen ten aanzien van applicatieontwikkeling worden samengesteld. Het uitgangspunt hierbij is de noodzakelijke beveiligingseisen, in de vorm van controls en onderliggende maatregelen, uit de BIO en ISO27002 (2013) in een samenhangende context te plaatsen en waar nodig deze aan te vullen met controls uit andere ISO standaarden, NIST of Standard of Good practice. Alvorens de controls, die gerelateerd zijn aan objecten, te identificeren, wordt eerst een algemene ontwikkelcyclus beschreven om een beter beeld te krijgen over de te hanteren stadia. Deze exercitie is zinvol om de geïdentificeerde objecten uit ISO/BIO en overige standaarden beter contextueel in samenhang te plaatsen. De beschrijving van de stadia vindt plaats in § 1.4 ‘Ontwikkelcyclus van applicaties’. ===Doel van het thema Applicatieontwikkeling=== Dit thema is opgesteld om zowel de interne als de externe leverancier over een instrument te laten beschikken gericht op de implementatie van applicaties in de technische omgeving van de leverancier of van de klant zelf. Het thema geeft hiermee inzicht in de kwaliteitszorg die de leverancier dient toe te passen, en wat de klant kan verwachten, bij het opleveren van nieuwe software. Het geeft tegelijkertijd de verplichte activiteiten weer van de klant. Hiernaast kan het als instrument dienen voor het geven van inzicht in het beveiligings- en beheersingsniveau van de ontwikkel- en onderhoudsorganisatie van de leverancier. ===Scope en begrenzing van Applicatieontwikkeling=== In dit thema zullen we ons voornamelijk richten op conditionele, beveiligings- en beheersingsaspecten die gerelateerd zijn aan het ontwikkelen van applicaties. We beperken ons binnen dit thema tot het inhouse ontwikkelen van applicaties en waarbij geen aandacht wordt besteed aan: * de activiteiten die gerelateerd zijn aan onderhoud van applicaties, webapplicatie en ERP pakketten (zie afbeelding 'Overzicht van type applicaties'); * het type gebruikers- en business eisen omdat deze eisen organisatieafhankelijk zijn; * de toegangsbeveiligingsaspecten omdat deze aspecten in het thema ‘Toegangsbeveiliging’ en in de SIG ISO25010 geadresseerd zijn. [[Afbeelding:Thema Applicatieontwikkeling - Overzicht van type applicaties.png|thumb|350px|none|alt=”Overzicht van type applicaties”]] ===Ontwikkelcyclus van applicatieontwikkeling=== Een applicatie (software) wordt ontwikkeld om een (bedrijfs)proces te ondersteunen. Hiervoor dient eerst een context analyse te worden gemaakt om de juiste functionele vereisten te identificeren. De applicatie moet voldoen aan de behoeften van gebruikers en stakeholders in de vorm van wet- en regelgeving, eisen en requirements of te wel een Programma van Eisen (PvE). Dit PvE wordt ontwikkeld in samenwerking met informatie analisten, softwareontwikkelaars en -gebruikers. De kwaliteit (succes) van een applicatie wordt o.a. bepaald door: * hoe goed de applicatie het vastgestelde programma van eisen weerspiegelt; * hoe goed het programma van eisen de gebruikerseisen en wensen weerspiegelt; * hoe goed de gebruikerseisen en wensen de reële situatie (daadwerkelijke noodzakelijkheden) weerspiegelt. Slechte kwaliteit van het PvE wordt o.a. veroorzaakt door onjuistheden, verkeerde aannames, inconsistenties, onduidelijk taalgebruik en ontoereikendheid. Bij applicatieontwikkeling is een goede inrichting van projectmanagement en de te hanteren systeem ontwikkelmethode (Systeem Development Life cycle) essentieel. Het applicatieontwikkeling proces wordt verdeeld in activiteiten die niet noodzakelijk als sequentiële stappen doorlopen worden (zie ook §1.5 ‘Ontwikkelmethoden’). De onderkende activiteiten zijn: * analyseren; * specificeren; * ontwerpen; * ontwikkelen; * valideren(testen); * gebruik en beheer. Opmerking: Bij agile worden in ieder geval ontwikkelen en een deel van het valideren als één activiteit uitgevoerd. Een deel van het ontwerpen kan daar ook bij horen. Ook wordt het andere deel van valideren en gebruiken wel gelijktijdig gedaan. Hiervoor zijn verschillende modellen bekend. Afbeelding 'De ontwikkelactiviteiten van software en indeling van essentiële elementen in drie domeinen' geeft een schematische weergave van een ontwikkelproces in de vorm van het V-Model. De activiteiten zullen hieronder worden toegelicht. Ze verschaffen mogelijkheden om de geïdentificeerde operationele objecten uit BIO, ISO27001/2 en overige standaarden te rubriceren. [[Afbeelding:Thema Applicatieontwikkeling - De ontwikkelactiviteiten van software en indeling van essentiële elementen in drie domeinen.png|thumb|350px|none|alt=”De ontwikkelactiviteiten van software en indeling van essentiële elementen in drie domeinen”]] Hiernaast spelen ook essentiële randvoorwaardelijke- en beheersingselementen een rol bij de ontwikkel- en onderhoudsactiviteiten. De operationele-, randvoorwaardelijke- en beheersingselementen voor het thema Applicatieontwikkeling kunnen ingedeeld worden in drie domeinen: Beleid, Uitvoering en Control. Deze indeling wordt eveneens afgebeeld in afbeelding 'De ontwikkelactiviteiten van software en indeling van essentiële elementen in drie domeinen'. ''Perspectieven'' De linkerkant van het model beschrijft het ontwikkelperspectief en de rechterkant het gebruikersperspectief. Als de applicatieontwikkeling plaatsvindt bij een externe organisatie of een aparte businessunit zijn deze perspectieven gescheiden. Ingeval van uitbesteding wordt, afhankelijk van de afspraken tussen de klant en de leverancier, de rechterkant aangeduid als het leveranciersperspectief en de linkerkant als het klantperspectief. Hierover dienen klant en leverancier heldere afspraken te maken. Afspraken dienen gericht te zijn op: * het uitwisselen van kennis, specifiek over de overdracht van proceskennis van de (gebruiks)organisatie naar de ontwikkelorganisatie; * het tijdens het ontwikkelproces niet verstoren van het primaire proces; * het toezien op de bescherming van intellectuele eigendommen en van gevoelige informatie. De verantwoordelijken binnen het ontwikkelproces moeten verantwoording kunnen afleggen over de kwaliteit van het geleverde product. Om een goede beheersing te waarborgen is het vanuit best practices noodzakelijk de verschillende lifecycle stadia te isoleren in een eigen omgeving zodat gegarandeerd kan worden dat het primaire proces niet wordt verstoord. Daarbij vindt een expliciete afsluiting van een fase plaats zodat een gecontroleerde overgang mogelijk wordt. Dit concept wordt een OTAP-straat genoemd. ''Analyseren'' In deze fase wordt de context van het businessproces, dat door de te ontwikkelen applicatie ondersteund moet worden, geanalyseerd. Hierbij worden de noodzakelijke requirements, waaronder de bedrijfsfuncties, gegevens en veranderwensen vanuit de bedrijfsprocessen geïdentificeerd en vastgelegd. De focus ligt op de ‘waarom’ aspecten. Onder andere de volgende activiteiten worden uitgevoerd: * onderzoeken en brainstormen over de te ontwikkelen software, om duidelijkheid te krijgen wat het doel is van de software; * analyseren van eisen en wensen van gebruikers, beheerders en partners ten aanzien van functionele en niet-functionele aspecten. ''Specificeren'' Deze activiteit richt zich op de ‘wat’ aspecten. De business-, gebruikers-, stakeholders- (non)functionele- en data requirements worden gespecificeerd. Ook worden de noodzakelijke business rules en de noodzakelijke beperkingen in de vorm van constraints vastgelegd in een functioneel ontwerp. ''Ontwerpen'' Bij deze activiteit vindt de tijdens in de eerdere fase gedetailleerde en vastgestelde uitwerking van informatie en modellen plaats. Deze fase richt zich op de relaties en afhankelijkheden tussen de te bouwen componenten. Hierbij worden de bedrijfs- en procesvereisten gemodelleerd in een ontwerp (architectuur) voor het te bouwen informatie(deel)systeem. Aandacht dient besteed te worden aan de kwaliteitseisen gerelateerd aan gebruikers, functionaliteit en beveiliging. ''Ontwikkelen'' In deze fase worden de softwarecomponenten geconstrueerd (gecodeerd). De relaties en afhankelijkheden van de te automatiseren processen en modules worden vastgelegd in een softwarearchitectuur. Uiteindelijk zullen de programma’s geschreven worden op basis van deze (applicatie/software) architectuur. Hierbij moet ook rekening worden gehouden met enkele ontwikkeleisen, zoals: * reproduceerbaarheid van code; * effectief testbaarheid; * toepassing van externe programma bibliotheek; * toepassing tools en gebruik van licenties; * toepassing van gestandaardiseerde vocabulaire (ISO25010); * inzicht in relaties en afhankelijkheden tussen softwareobjecten; * softwarefeatures (eisen: interfaces, koppelingen, API’s); * richten op aantoonbaar veilig programmeren (Secure Software Design). ''Valideren'' In deze fase worden de ontwikkelde modules/programma’s getest en uiteindelijk geaccepteerd. Gecontroleerd wordt of de software volgens de ontwerprichtlijnen is gebouwd. In deze fase kunnen ook fouten boven water komen die al in eerdere stadia gemaakt zijn. In deze fase wordt aandacht besteed aan bepaalde eisen, zoals: * de applicatie biedt slechts die functionaliteit die in de specificaties/ontwerp zijn opgenomen. (m.a.w.: geen functionaliteit buiten specificaties/ontwerp); * conformiteit aan de gespecificeerde functionaliteit (gebruikers)/ontwerp (Security by Design), AVG). ''Gebruiken'' Als de software voltooid en getest is zal het in gebruik genomen moeten worden volgens een standaardprocedure van de ‘OTAP-straat’. ''Onderhoud/Beheer'' Tenslotte dient de software periodiek op basis van nieuwe functionele eisen en of voorkomende fouten te worden onderhouden en (weer) in beheer te worden genomen. ===Ontwikkelmethoden=== Er zijn verschillende modellen voor het ontwikkelen van applicaties, zoals: lineair, iteratief en Agile. * 'Lineaire methode' Het meest bekend voorbeeld is de watervalmethode (zie §1.4). In deze lineaire ontwikkelmethode wordt het eindproduct (softwareproduct) in een aantal fases opgeleverd. In elke fase wordt een concreet gedefinieerd deelproduct vervaardigd. Requirements moeten duidelijk zijn en vooraf zijn vastgelegd. Kennisoverdracht en monitoring vinden plaats op basis van specifieke documenten en formats. * 'Iteratieve ontwikkelmethode' Iteratieve ontwikkeling is een methode waarbij het eindproduct niet in één keer wordt opgeleverd, maar gefaseerd tot stand komt, waarbij fases herhaaldelijk worden doorlopen. Na elke zogenaamde iteratie wordt het proces geëvalueerd en zo nodig aangepast. In de praktijk worden iteratieve- en lineaire ontwikkelmethoden met elkaar gecombineerd. * 'Agile methode' Een agile methode wordt gekenmerkt door korte, in tijd gelimiteerde sprints. De inhoud van een sprint wordt bij de start ervan bepaald. De gevolgde werkwijze kan (dagelijks) worden aangepast al naar gelang de wensen van de zelfsturende teams. Er wordt gebruik gemaakt van een geordende lijst van product features die gedurende het gehele project wordt bijgewerkt op basis van de behoefte van de klant. Daarmee worden in feite de productspecificaties opgebouwd. De nadruk ligt op samenwerking en mondelinge kennisoverdracht. Prioriteit wordt gegeven aan het opleveren van sprints en producten met de op dat moment hoogste toegevoegde waarde. De sprints worden gedaan door zelfsturende teams met multidisciplinaire teamleden en zonder vastgelegde taken, rollen en verantwoordelijkheden. Afbeelding 'Schematische weergave van een iteratie/agile ontwikkelproces in de vorm van het V-Model' geeft een schematische weergave van een iteratie/agile ontwikkelproces in de vorm van het V-Model. [[Afbeelding:Thema Applicatieontwikkeling - Schematische weergave van een iteratie agile ontwikkelproces in de vorm van het V-Model.png|thumb|350px|none|alt=”Schematische weergave van een iteratie/agile ontwikkelproces in de vorm van het V-Model”]] ===Applicatie objecten uit baseline in relatie tot ontwikkelmethode=== Bij de selectie van applicatie objecten uit ISO en overige baselines is in eerste instantie uitgegaan van de lineaire-/iteratieve aanpak van applicatieontwikkeling. Mogelijk volgen later een versie die gerelateerd is aan applicatieonderhoud en een versie die gerelateerd is aan de Agile methode. Dit zullen aparte documenten zijn die overeenkomsten zullen hebben met dit document, maar vanuit de optiek van onderhoud of Agile aanpak kunnen objecten aangepast en/of toegevoegd worden.  +