Informatiebeveiliging voor de requirementsanalist

Informatiebeveiliging voor de requirementsanalist

SYSQA B.V. Almere

Datum Versie Status Opgesteld door

: 15 april 2013 : 1.0 : Definitief :

Organisatie: Titel

SYSQA BV Informatiebeveiliging voor de Requirementsanalist

Pagina Versie Datum

2 van 11 1.0 15-04-2013

Inhoudsopgave Inhoudsopgave .............................................................................. 2 1

Inleiding ................................................................................. 3 1.1 Relatie met andere documenten van expertisegroep Security ............. 3 1.2 Doel en veronderstelde voorkennis ................................................. 3 1.3 Indeling van het document ............................................................ 3

2

Requirementsanalist rol beschrijving ...................................... 4

3

Requirementsontwikkeling...................................................... 5 3.1 3.2 3.3 3.4

4

Elicitatie ...................................................................................... 6 Analyse ....................................................................................... 7 Specificatie & Validatie .................................................................. 9 Conclusie..................................................................................... 9

Bijlage 1 ................................................................................ 10 4.1 Bronvermelding en overige informatie ........................................... 10

Almere © 2013

Proud of it

Organisatie: Titel


Pagina Versie Datum

3 van 11 1.0 15-04-2013

1 Inleiding 1.1 Relatie met andere documenten van expertisegroep Security De expertisegroep Security van SYSQA B.V. heeft een set van documenten over informatiebeveiliging opgeleverd.

Introductie Informatiebeveiliging

Basiskennis Informatiebeveiliging

Informatiebeveiliging voor de Requirementsanalist

Informatiebeveiliging voor Testmanagement

Informatiebeveiliging voor Functioneel Beheer

Informatiebeveiliging voor de Kwaliteitsmanager

Figuur 1 Documentstructuur IB documenten expertisegroep Security

In het zwart omlijnde blok is het voorliggende document weergegeven.

1.2 Doel en veronderstelde voorkennis Dit document is bedoeld om requirementsanalisten meer handvatten te geven bij het uitvoeren van de rol van requirementsanalist en dan met name op het gebied van informatiebeveiliging. Er wordt verondersteld dat de requirementsanalist basiskennis heeft van informatiebeveiliging. Op de kennisbank van SYSQA staat een introductie tot informatiebeveiliging, dit document verstrekt deze basiskennis. Verder kunnen de documenten voor kwaliteitsmanager, testmanager en functioneel beheer als aanvulling worden gezien. In het document staan geen uitputtende beschrijvingen van technieken en processen. Er worden vooral aandachtspunten benoemd om de requirementsanalist aan het denken te zetten bij het requirementsproces wat deze doorloopt. Hierdoor zal hij of zij meer kritische vragen op het gebied van informatiebeveiliging kunnen stellen in zijn opdracht.

1.3 Indeling van het document De opzet van dit document is als volgt. Als eerste wordt de rol van requirementsanalist toegelicht. Aanvullend wordt de requirementsontwikkeling behandeld, hier wordt het proces rondom requirementsontwikkeling in relatie met IB verder toegelicht. Een aantal tips en aandachtspunten worden aangereikt om specifiek de requirements rondom IB helder te krijgen. Als laatste zijn referenties opgenomen naar interessante en relevante artikelen in relatie tot Informatiebeveiliging.

Almere © 2013

Proud of it

Organisatie: Titel


Pagina Versie Datum

4 van 11 1.0 15-04-2013

2 Requirementsanalist rol beschrijving De requirementsanalist is in eerste instantie verantwoordelijk voor de verdere detaillering van de business requirements die in relatie met informatiebeveiliging staan, met name die zaken waar door een informatiearchitect rekening mee moet worden gehouden. In de meeste organisaties zullen deze twee rollen veelal samen werken aan de informatiebeveiliging.

Figuur 2: Soorten requirements en hun samenhang

In vergelijking met alle andere aandachtsgebieden waar een requirementsanalist zijn aandacht aan moet besteden, is het onderwerp “Informatiebeveiliging” voor een requirementsanalist niet heel veel anders. Het probleem is vaak dat informatiebeveiliging (IB) bij veel bedrijven een aandachtsgebied is wat onderbelicht blijft, veelal omdat het een onderwerp is waar vanuit de business wat angstig op gereageerd wordt. IB is een onderwerp wat voor veel stakeholders als een onbekend fenomeen wordt beschouwd, maar eigenlijk ook als iets vanzelfsprekends: “Uiteraard moet het veilig zijn!”. De benodigde informatie om tot een goede set requirements betreffende IB te komen moet dan ook veelal van de informatiebeveiligingsspecialisten in een organisatie komen. Men weet vaak nog wel dat voor bepaalde wensen aan weten regelgeving voldaan moet worden, maar inhoudelijk kan men dan niet aangeven om welke weten regelgeving het

Almere © 2013

Proud of it

Organisatie: Titel


Pagina Versie Datum

5 van 11 1.0 15-04-2013

specifiek gaat. Laat staan dat men kan vertellen hoe aan deze van toepassing zijnde weten regelgeving voldaan moet worden. Hierin ligt voor een requirementsanalist dan ook een rol weggelegd om de business te helpen om dit gebrek aan kennis aan te vullen. De insteek van dit document is dan ook niet om te beschrijven hoe het requirementsproces voor IB ingestoken moet worden. Hiervoor wordt verwezen naar het boek “Succes met de Requirements” of naar de documenten over Requirements op de kennisbank van SYSQA. Het doel van dit document is om de requirementsanalist op voorhand aan het denken te zetten over het onderwerp IB tijdens de requirementsontwikkeling, zodat de requirementsanalist tijdens dit proces de juiste vragen bij de juiste personen kan vragen omtrent IB. In dit document wordt uitgegaan van het proces voor requirementsontwikkeling zoals deze in het boek wordt beschreven.

3 Requirementsontwikkeling

Figuur 3: Onderverdeling van het requirementsproces

Requirementsontwikkeling is een onderdeel van het requirementsproces en is een proces op zich. Zie hiervoor ook hoofdstuk 3 “Requirementsontwikkeling” in “Succes met de Requirements”. Het deelproces requirementsontwikkeling is de scope van dit document, waarbij alleen de onderdelen Elicitatie en Analyse met betrekking tot IB toegelicht worden.

Figuur 4: Proces van requirementsontwikkeling

Almere © 2013

Proud of it

Organisatie: Titel


Pagina Versie Datum

6 van 11 1.0 15-04-2013

3.1 Elicitatie 3.1.1 Belanghebbenden De belanghebbenden (stakeholders) zijn de uiteindelijke doelgroep van een project. Het project moet een product of dienst opleveren waar de gebruikers iets mee moeten doen.. De belanghebbenden zouden dus moeten weten wat benodigd is om dit product of deze dienst te verwezenlijken. Het is dus noodzakelijk om voldoende tijd te claimen van de belanghebbenden om uiteindelijk tot een set van requirements omtrent IB te komen. Deze set van requirements moet van voldoende kwaliteit en diepgang zijn, zodat het project een juiste inschatting van de impact door deze requirements kan maken. In theorie start het requirementsproces bij de opstart, of liever zelfs nog voor de opstart, van het project (de inceptie fase). Het is dan van belang om de uitgangspunten voor het eindresultaat van het product of de dienst te bepalen, met name voor IB. Tijdens dit voorwerk moeten er een aantal randvoorwaarden en uitgangspunten worden overeengekomen:     

De business case, o.a. beargumenteerd vanuit het IB oogpunt; Betrokkenheid van de opdrachtgever, het topmanagement en de gebruikers; draagvlak voor IB is essentieel; Definitie van het te realiseren product of de te realiseren dienst; Acceptatiecriteria; Kwaliteitscriteria.

In de inceptie fase zal blijken dat er omtrent IB in de meeste organisaties een wat ongemakkelijk gevoel heerst. Dit is meestal ontstaan door de ergernis van de gebruikers bij het omgaan met de huidige beveiligingsmaatregelen en/of onbekendheid met IB als thema. De inceptie fase is dus het uitgelezen moment om dit ongemakkelijke gevoel om te zetten in een situatie waar de beveilingseisen op een juiste wijze geëliciteerd en gespecificeerd kunnen worden. Een externe requirementsanalist zou hierin het best kunnen faciliteren, deze heeft nog geen band met de organisatie. Dit kan voorkomen dat er teveel sentimenten in de beveiligingseisen doorsijpelen en uiteindelijk geen eenduidige verwoording van de requirements wordt bewerkstelligd. Uiteraard kan een interne requirementsanalist dezelfde rol vervullen, key blijft dat het een onafhankelijke rol binnen de organisatie is. Voordat requirements worden opgesteld wordt een stakeholderanalyse gedaan. Controleer of hierbij ook voldoende wordt gekeken naar rollen die inhoudelijk meer kunnen zeggen over bedrijfscontinuïteit en IB. De vraag is ook of de requirementsanalist of business analist voldoende van deze onderwerpen afweten en er ook voldoende focus op hebben en zo nodig de mensen met kennis op deze gebieden opschakelen. Denk aan security officer of functioneel beheerder. Een stakeholdersanalyse in combinatie met een omgevingsanalyse is dan een goed startpunt om de veelal ‘onbekende’ stakeholders omtrent security en IB in kaart te brengen. Deze personen komen (vaak) gewoon uit de business en/of de ICT, maar worden vaak bewust of onbewust niet betrokken. Uiteindelijk zijn ze vaak wel heel belangrijk bij de uiteindelijke acceptatie en in productie name van een resultaat. Na uitgebreide interviews met deze personen zou er dan een compleet beeld moeten ontstaan waarmee het ongemakkelijke gevoel bij de gebruikers weggenomen kan worden, omdat er dan duidelijke antwoorden zijn waarom IB noodzakelijk is en in welke richtingen er gezocht kan worden naar mogelijk oplossingen.

Almere © 2013

Proud of it

Organisatie: Titel


Pagina Versie Datum

7 van 11 1.0 15-04-2013

Mogelijke ‘onbekende’ stakeholders:       

(Lijn)managers; ICT-managers; Product owners; Beheerorganisatie; Eindgebruikers; Overheid; Informatiebeveiligingsmanager.

Allen hebben een eigen referentiekader, (dus beperking en) hierdoor loopt men het risico dat de input voor requirements omtrent IB beknot wordt. Noodzaak blijft het om in deze eerste fase voldoende tijd te nemen om antwoord te krijgen in het “waarom” en “hoe”. Indien hier bij het opstarten te snel aan voorbij gegaan wordt of zelfs wordt vergeten, kan dit in het project kostbaar tijdsverlies opleveren. Geen of niet volledige beveiligingseisen creëren een gebrekkige beveiligingscomponent. Hierdoor ontstaat een verhoogde kans op een ondeugdelijke link met de reeds aanwezige beveiligingsinfrastructuur en/of geen overeenstemming met het bestaande beleid omtrent IB of de architectuur voor IB in de organisatie. Om het “waarom” te kunnen definiëren is het belangrijk om de doelstelling van het resultaat van het project te weten, dit hoort onder andere uit de business case naar voren te komen. Verder kunnen schriftelijke bronnen als input dienen om requirements voor IB te eliciteren. Voorbeelden schriftelijke bronnen:  Wet- en regelgeving (WPB, Telecomunicatiewet, VIR, SoX, etc.);  IB standaarden (ISO, NIST, ISF, etc.);  IB organisaties en communities (OWASP, ISECOM);  Business rules (ICT richtlijnen, bijv. password renewal, maar ook eisen die aan derde partijen gesteld kunnen worden);  Gedocumenteerde incidenten met betrekking tot IB; Het “hoe” zijn oplossingen en die zijn voor de requirementsanalist in eerste instantie niet zo van belang, tenzij de oplossingen richtlijnen vanuit de organisatie zijn. Deze richtlijnen kunnen o.a. voortkomen uit weten regelgeving, best practices in de ICT en/of de enterprise-architectuur.

3.2 Analyse 3.2.1 Onderwerpen Mogelijke onderwerpen die in de requirements analyse fase naar voren gebracht kunnen worden: Opslag   

Secure opslaan (encryption, redundancy); Lokatie data (private/public datacenter, cloud, local disks, USB); Beschikbaarheid van de data.

Almere © 2013

Proud of it

Organisatie: Titel


Pagina Versie Datum

8 van 11 1.0 15-04-2013

Toegang    

Toegang tot data (lokatie, methode); Autorisaties van gebruikers of processen; Authenticatie van gebruikers of processen; Integriteit van de data.

Betrouwbaarheid  

Informatie moet betrouwbaar zijn, met andere woorden: beschikbaar, integer en vertrouwelijk of exclusief (niet voor iedereen); De hoofduitgangspunten die van invloed kunnen zijn op deze (non-functional) requirements zijn: o Het belang van de informatie voor de bedrijfsprocessen; o De onmisbaarheid van de informatie binnen de bedrijfsprocessen; o De herstelbaarheid van de informatie.

Maar ook de 6 elementen uit de Parkerian Hexad kunnen als input dienen. De elementen van de Parkerian hexad zijn: 1. Vertrouwelijkheid (exclusiviteit); 2. Bezit of controle; 3. Integriteit; 4. Authenticiteit; 5. Beschikbaarheid; 6. Utiliteit. Voor een toelichting op de Parkerian Hexad wordt verwezen naar “Basiskennis IB op basis van ISO27001 en ISO27002” en Wikipedia.

3.2.2 Product Risico Analyse Risico en maatregel Er is een correlatie tussen risico (= kans x impact) en maatregel.  geen risico = geen maatregelen  weinig risico = weinig maatregelen  veel risico = veel maatregelen en alle tussenliggende varianten. Maatregelen kan dan in het geval van risico’s omtrent IB vervangen worden door het woord beveiliging. In de Product Risico Analyse (PRA, zie hiervoor o.a. het boek “Succes met de Requirements” ) moet duidelijk worden welke risico’s er zijn, wat uiteindelijk met behulp van de stakeholders moet leiden naar een set requirements. De gevalideerde set requirements moet dan uiteindelijk leiden naar een set maatregelen die deze risico’s kan afdekken. Aandachtspunten voor de PRA:  Waar ligt de focus tijdens de PRA?  Welke kwaliteitsattributen van ISO 25010 vindt men belangrijk?  Kent men de security attributen?

Almere © 2013

Proud of it

Organisatie: Titel

   


Pagina Versie Datum

9 van 11 1.0 15-04-2013

Heeft de testmanager de (security) kwaliteitsattributen uitgelegd/toegelicht? Is een security officer aanwezig bij de PRA? Wordt het Informatiebeveiligingsbeleid goed in de PRA sessie meegenomen en wordt dit ook in de uitwerking van de PRA goed verwerkt? Zijn de systeem- en proceseigenaren zich voldoende bewust van de Informatiebeveiligingsrisico’s?

Staat men genoeg stil bij de risico’s wanneer een security requirement niet wordt gehaald? Een requirementsanalist hoort ook te kijken naar wat voor risico’s men loopt als een requirement niet of niet goed wordt ingevuld.

3.3 Specificatie & Validatie Deze stappen wijken niet af van zoals beschreven in het boek “Succes met de Requirements” of in de documenten over Requirements op de kennisbank van SYSQA en zullen daarom hier niet verder worden toegelicht.

3.4 Conclusie Het requirementsontwikkelingsproces voor IB wijkt niet veel af van het requirementsontwikkelingsproces voor andere onderdelen in een IT project. Maar vanwege de onbekendheid met IB en de mogelijk impact als er in het opstarttraject van een ontwikkeltraject te lichtzinnig over gedacht wordt, is het een proces wat er ook voor moet zorgen dat er awareness over IB ontstaat. De requirementsanalist speelt daar dus een grote rol in.

Almere © 2013

Proud of it

Organisatie: Titel


Pagina Versie Datum

10 van 11 1.0 15-04-2013

4 Bijlage 1 4.1 Bronvermelding en overige informatie     

Succes met de requirements! - ISBN 978 90 12 12598 7 - Martin Arendsen, Jan Jaap Cannegieter, Petra Heck, Serge de Klerk en Johan Zandhuis; Basiskennis Informatiebeveiliging op basis van ISO27001 en ISO27002 – ISBN 978 90 8753 567 4 – Hans Baars, Jule Hintzbergen, Kees Hintzbergen en Andre Smulders; Expertbrief - IB standaarden - Platform voor Informatiebeveiliging - 2009; Expertbrief - PM & IB v1.01 - Platform voor Informatiebeveiliging - juni 2007; OWASP: https://www.owasp.org/

OWASP search naar requirements: https://www.owasp.org/index.php?title=Special%3ASearch&search=requirements&go=G o

Almere © 2013

Proud of it

Organisatie: Titel


Almere © 2013

Pagina Versie Datum

11 van 11 1.0 15-04-2013

Proud of it

Informatiebeveiliging voor de requirementsanalist

Recommend Documents