ISO27001: beschikbaarheid

[Rekcor]

We hebben intern regelmatig discussies over ons ISO27001-certificaat, en dan met name de definitie van "beschikbaarheid". Volgens ISO27000 is de definitie daarvan "property of being accessible and usable upon demand by an authorized entity".

De discussie gaat over wanneer iets nu een "informatiebeveiligingsincident" is. Onze security officer is hier nogal... strikt in (maar goed, dat is ook haar rol). Graag jullie mening over de volgende casussen:

1. Klant vraagt ons gebruikers X, Y en Z toegang te geven. Door een invoerfout krijgen alleen X en Y toegang. De klant vergeet te testen.
2. Klant vraagt ons gebruikers X, Y en Z toegang te geven. Door een invoerfout krijgt niemand toegang. De klant vergeet te testen.
3. Klant voegt filmpje toe, maar door een onduidelijke GUI doet klant verkeerde instelling, waardoor filmpje niet werkt.
4. Wij passen CSS stylesheet aan (product=webapp) en een stuk tekst wordt voor klant onleesbaar.

Volgens onze SO zijn dit allemaal "informatiebeveiligingsincidenten" waarover we een officiele melding moeten maken, de klant moeten informeren, etc. Volgens ons zijn het gewoon foutjes/bugjes/communicatieprobleempjes van alledag.

Extreem voorbeeld:

1. Wij updaten een library, waardoor 1 pixel in een plaatje onzichtbaar wordt

Volgens de strikte definitie van ISO27000 is er nu informatie niet beschikbaar - namelijk 1 pixel - en is dit een "incident" (al is zelfs onze SO het met ons eens dat dit in dit geval niet het geval is, als je me nog kunt volgen )

[Rukapul]

Misschien moeten jullie toch op zoek naar een nieuwe Security Officer. Dit meen ik serieus.

De rol van een security officer is namelijk om de externe eisen te vertalen naar het bedrijf en scope te bewaken. Toch worden jullie blijkbaar lastig gevallen met vrijwel niet terzake doende zaken waardoor waarschijnlijk echte security zaken gemist worden.

De security officer zal beleid moeten definieren welke specifieke gevallen follow-up behoeven. Bovenstaande typisch niet

[ Voor 15% gewijzigd door Rukapul op 18-01-2017 18:16 ]

[kelvin46]

Als er door een invoerfout meer mensen toegang zouden krijgen, dan heb je een beveiligingsincident. Dat iemand geen toegang krijgt is vervelend maar heeft niet zo heel veel met een beveiligingsincident te maken.

[The Eagle]

Een incident is typisch een afwijking in de standaard operations, ie in het standaard gedrag. Daarvan is hier geen van allen spraken; works as designed.

Dat je operationeel een extra check in zou kunnen voeren om je werk beter op te leveren lijkt me wel een goede. Je kunt de klant nooit verwijten dat ie vergeet te testen; die vraagt wat aan en wil geleverd zien. En mag er imho vanuit gaan dat dat goed opgeleverd wordt

Maar als jullie SO dit als security incidneten aanmerkt mag ze idd wel eens vervangen worden, want dit gaat nergens over. Wat ik me echter nog voor kan stellen is dat dergelijke meldingen door de klant gelogd worden in jullie ticketing systeem en men ze onder het kopje security in schiet. "Kan dr niet in" kan daar zomaar inder vallen natuurlijk. Dan is het naar de letter een incident wat security gerelateerd is. Maar daarmee is het nog geen security incident

[Rukapul]

kelvin46 schreef op woensdag 18 januari 2017 @ 18:23:
Als er door een invoerfout meer mensen toegang zouden krijgen, dan heb je een beveiligingsincident. Dat iemand geen toegang krijgt is vervelend maar heeft niet zo heel veel met een beveiligingsincident te maken.

Dat gaat ook weer te kort door de bocht. Geen toegang hebben tot een kritische security of veiligheidsfunctie kan weldegelijk een security incident zijn - nogal lullig als een stormvloedkering niet gesloten kan worden wanneer dat moet Dat is echter zelden het geval en dan verdient het niet de kwalificatie van meldbaar security incident.

[F_J_K]

Rukapul schreef op woensdag 18 januari 2017 @ 18:13:
Misschien moeten jullie toch op zoek naar een nieuwe Security Officer. Dit meen ik serieus.

De rol van een security officer is namelijk om de externe eisen te vertalen naar het bedrijf en scope te bewaken. Toch worden jullie blijkbaar lastig gevallen met vrijwel niet terzake doende zaken waardoor waarschijnlijk echte security zaken gemist worden.

De security officer zal beleid moeten definieren welke specifieke gevallen follow-up behoeven. Bovenstaande typisch niet

^^ dat ja.

Security officers hebben nogal eens de naam puur te gaan voor hun eigen interpretatie van een stuk papier, dat lijkt hier des te meer het geval te zijn.

Dit is zowel voor jullie als de klanten, en voor daadwerkelijke beveiliging niet goed

[downtime]

Rekcor schreef op woensdag 18 januari 2017 @ 17:25:
We hebben intern regelmatig discussies over ons ISO27001-certificaat, en dan met name de definitie van "beschikbaarheid". Volgens ISO27000 is de definitie daarvan "property of being accessible and usable upon demand by an authorized entity".

De discussie gaat over wanneer iets nu een "informatiebeveiligingsincident" is. Onze security officer is hier nogal... strikt in (maar goed, dat is ook haar rol). Graag jullie mening over de volgende casussen:

1. Klant vraagt ons gebruikers X, Y en Z toegang te geven. Door een invoerfout krijgen alleen X en Y toegang. De klant vergeet te testen.
2. Klant vraagt ons gebruikers X, Y en Z toegang te geven. Door een invoerfout krijgt niemand toegang. De klant vergeet te testen.
3. Klant voegt filmpje toe, maar door een onduidelijke GUI doet klant verkeerde instelling, waardoor filmpje niet werkt.
4. Wij passen CSS stylesheet aan (product=webapp) en een stuk tekst wordt voor klant onleesbaar.

Volgens onze SO zijn dit allemaal "informatiebeveiligingsincidenten" waarover we een officiele melding moeten maken, de klant moeten informeren, etc. Volgens ons zijn het gewoon foutjes/bugjes/communicatieprobleempjes van alledag.

Extreem voorbeeld:

1. Wij updaten een library, waardoor 1 pixel in een plaatje onzichtbaar wordt

Volgens de strikte definitie van ISO27000 is er nu informatie niet beschikbaar - namelijk 1 pixel - en is dit een "incident" (al is zelfs onze SO het met ons eens dat dit in dit geval niet het geval is, als je me nog kunt volgen )

Wat hebben beschikbaarheid en de security officer met elkaar te maken? De security officer gaat niet over beschikbaarheid.

[Squ1zZy]

downtime schreef op woensdag 18 januari 2017 @ 20:51:
[...]

Wat hebben beschikbaarheid en de security officer met elkaar te maken? De security officer gaat niet over beschikbaarheid.

Een SO heeft wel degelijk met beschikbaarheid te maken. Denk aan b.v. de CIA Triad. De A staat voor availability. Echter gaat het dan wel om b.v. DDoS aanvallen. Ik ben het er wel mee eens dat in dit geval het niet gaat over een informatiebeveiligingsincidenten

[F_J_K]

Beschikbaarheid is inderdaad onderdeel van ISO27001. Althans van de versie die ik heb gelezen Maar dat betekent niet dat any niet-beschikaarheid meteen moet worden gerapporteerd als beveiligingsincident. Onderdeel van dezelfde norm is risicoanalyse...

Ik zou eerder willen stellen dat een overdaad aan triviale meldingen betekent dat de wel-relevante meldingen / documenten defacto niet beschikbaar zijn voor het management. Er is bij een overdaad aan info geen beschikbaarheid van informatie op het vereiste niveau.

[The Eagle]

CIA ratings vziw gaan over Confidentiality, Integrity en Availability. Zegt iets over de gegevens die in een systeem zijn opgeslagen en hoe beschikbaar die moeten zijn en er mee om gegaan moet worden. Dat je daar security op zet is dus logisch, maar dat heeft niks met die availability te maken. Dat is plat gezegd gewoon system uptime. Als een gebruiker geen toegang heeft terwijl ie dat wel zou moeten heb je idd een security incident te pakken, maar niet als die gebruiker eerder nog geen toegang had

[GX]

Het voornaamste waar je rekening mee houdt vanuit ISO27001 is toch echt vertrouwelijkheid. Die beschikbaarheid is leuk, maar kleine bugjes waardoor één pixel het niet doet moet niet eens aan de orde komen bij een enkele security officer. Als je door een bug of configuratiefout ineens de data aan de hele wereld ontsluit, dán heb je wel een incident - maar dat is weer confidentiality.

Beschikbaarheid kan je idd beter toetsen op de beschikbaarheid van je product/tooling in zichzelf. Laat dat product gewoon lekker draaien en zorg er voor dat niet het halve internet je aan het DoSen is. En ik denk dat het tijd is dat het persoon aan wie jullie de security officer rapporteert, een goed gesprek moet gaan voeren. Dat dat persoon dat nog niet doorheeft - is misschien ook een teken van zorg

[Wim-Bart]

1. Klant vraagt ons gebruikers X, Y en Z toegang te geven. Door een invoerfout krijgen alleen X en Y toegang. De klant vergeet te testen.
2. Klant vraagt ons gebruikers X, Y en Z toegang te geven. Door een invoerfout krijgt niemand toegang. De klant vergeet te testen.
3. Klant voegt filmpje toe, maar door een onduidelijke GUI doet klant verkeerde instelling, waardoor filmpje niet werkt.
4. Wij passen CSS stylesheet aan (product=webapp) en een stuk tekst wordt voor klant onleesbaar.

De eerste en tweede. Ja het is een beveilignsincident maar dit is op te lossen. Klant moet zelf testen en als na testen blijkt dat dit niet werkt dan kan dit gecorrigeerd worden. Melding komt vanuit klant en hoeft niet richting klant gemeld te worden.

Waarom is dit wel een beveilingsincident? De reden is heel simpel. Er schort iets aan de procedure voor het uitdelen van toegang. Wie zegt niet dat er ook niet te veel toegang wordt gegeven tenslotte. Hierin heeft zij gelijk.

De derde. Dit is een gebruikersfout en heeft niets met security incidenten te maken. In theorie zit je ook in gebruikersgebied en mag je dit ook niet oplossen. Je mag gebruiker begeleiden om correctie te maken, je mag een incident loggen want dit kan vaker voor komen dus eventueel extra opleiding, instructie.

De vierde. Dit moet opgelost worden. Dit had reeds getest moeten zijn voordat de klant het zag. Dit is geen informatie beveiligingsincident, maar conform change management had dit nooit mogen gebeuren.

[Rekcor]

@allen: dank!

ISO27001 gaat inderdaad wel degelijk over beschikbaarheid (de veiligste optie zou namelijk zijn: alle klantinformatie van onze servers wipen en de harde schijven met vuur en sulfur verbranden)

Waarom is dit (1) wel een beveilingsincident? De reden is heel simpel. Er schort iets aan de procedure voor het uitdelen van toegang. Wie zegt niet dat er ook niet te veel toegang wordt gegeven tenslotte. Hierin heeft zij gelijk.

Dit is een goed punt!

De vierde. Dit moet opgelost worden. Dit had reeds getest moeten zijn voordat de klant het zag. Dit is geen informatie beveiligingsincident, maar conform change management had dit nooit mogen gebeuren.

Waarom is dit geen beveiligingsincident? Er was toch informatie niet beschikbaar?

[Giesber]

Rekcor schreef op donderdag 19 januari 2017 @ 09:27:
Waarom is dit geen beveiligingsincident? Er was toch informatie niet beschikbaar?

Daar mag voor mij wel gekeken worden welke informatie niet beschikbaar is. Als het een volledige veiligheidsprocedure is, dan kan dat een probleem zijn. Als het gaat om het telefoonnummer van de helpdesk, wat bovendien nog op 5 andere plaatsen beschikbaar is, dan kan je moeilijk van een beveiligingsincident gaan spreken.