Heel goed. Niet de techniek maar de achterliggende informatie is leidend.

Heb je wel begrepen waar het over gaat? Het gaat helemaal niet over techniek.

Volgens mij bedoelt karma4 dat ook

Ik vind het goed te lezen dat er verschil wordt gemaakt tussen informatie-eigenaar en informatie-managen.
Zo ook de CISO die ondersteunend en geen risico drager.

Jammer dat ze ‘m een andere positie willen geven, want daar hangt het niet van af.
Het hangt af van je controle inrichting en rapportage afhandeling af.

Klinkt wel leuk dat informatie maar informatie is datgene wat de mens ontleent aan gegevens.

Laten we beginnen met data classificatie.

Ik vind dit een veel te algemeen verhaal.

Maar ik ben überhaupt al niet zo te spreken over de aanpak van het NCSC.

Deze is de start voordat je met dataclassificatie kan beginnen
"Om zicht en grip te krijgen op de risico’s rondom informatie, moet u eerst zicht en grip krijgen op de informatie zelf. Inzien dat informatie, net als bijvoorbeeld personeel, de voorraad en de financiën, een bedrijfsmiddel is dat actief beheer nodig heeft, helpt daarbij. "
Data is een technische weergave van informatie. Die weergave kan onvolledig dan wel onbetrouwbaar zijn.

Eens.

Laten we inderdaad vooral niet beginnen met data classificatie maar eerst met informatie modellen en op basis van de behoeften van de informatie eigenaar bepalen welke beveiliging nodig is , ipv alles over 1 kam te scheren van 3 of 4 verschillende niveaus, voor alleen maar CIA. Er is veel meer dan dat.

Data zijn ruwe gegevens zonder context die ik niet kan beschermen zonder te weten welke informatie beveiliging er moet zijn.
Helaas worden termen Informatie en data telkens maar weer door elkaar gehaald, zelfs in de wetgeving. GDPR, zou GIPR moeten zijn.

Data is geen technische weergave van informatie.
Je hebt namelijk technische en niet technische informatie.
Wanneer je het hebt over technisch dan kan je het hebben over programmeer code, dB van signalen enzo voorts.
Als voorbeeld van niet technische informatie, die vind je vaker ook terug in verkoop-folders van bijvoorbeeld IT oplossingen.
Als je vervolgens een vergelijking van die IT-oplossingen maakt kan je bijvoorbeeld ook informatie naast elkaar plaatsen, daaronder niet technische informatie.
Voor een dubbeltje op de eerste rang willen zitten met die IT-oplossingen maakt van verkoopprijs informatie nog geen technisch risico,
maar wel degelijk is een lage verkoopprijs of exclusief gebruikte ontwikkel-methode als verkoop-informatie een indicatie kan zijn voor in doorsnee meer risico's.



Alle goede bedoeling daargelaten, informatie en risico's zijn altijd context-gebonden.
Ik lees daar spijtig genoeg niets opvallends over in de publicatie.
Als je de context snapt dan kan je het karakter van de impact van een eventueel optredend risico ook beter en kan je op voorhand meer trefzeker maatregelen afwegen.
Dus dit lijkt me in dit verband bepaald niet onbelangrijk.



Splitst "risico's" dan in ieder geval uit in termen van gepercipieerde risico's en gecorrigeerde risico's specifiek voor een bepaald moment of een bepaalde duur (plotseling danwel opbouw / aanhoudend / afbouw).
Dan krijg je voor gepercipieerde risico's [t] kans x impact, voor moment [t].
Voor de gecorrigeerde risico's[t] krijg je (kans - potentiële reductie door maatregel) x (impact - reductie door maatregel).

Drugs is ook niet leidend.

Nee hoor data kan 0 informatie bevatten.

Vond ik dus ook. Als ze beginnen met "Informatie en ICT zijn tegenwoordig onlosmakelijk verbonden" haak ik af.

Data zijn ruwe gegevens zonder context.
Informatie heeft een betekenis.

technische informatie bestaat uit ruwe gegevens plus een context.
Het feit dat je kunt aanduiden wat er staat, wat het betekent, is omdat er een betekenis is gegeven aan de data.
Zolang er geen context aan data zit, kun je er niks mee.

Er is geen technische en niet-technische data. Data = data.
Data wordt getransformeerd tot informatie en dan is het voor de gebruiker technische informatie of medische informatie of wat dan ook.

Als ik jou bepaalde cijfers laat zien heb je geen idee wat het is, tot ik je erbij vertel hoe je die data kunt transformeren (interpreteren), Daarna is het informatie geworden.

En daarom moet je beginnen met het beveiligen van informatie, want dat heeft een betekenis. Data op zich zelf niet.
Informatie classificatie. Niet data classificatie.

Bovendien, CIA is te limitatief er zijn meer aspecten aan informatie: tijdigheid, compleetheid, toegankelijkheid, etc.

Ik llees je reactie en ik geloof dat we in een zelfde richting zitten. Die verkoopprijs in een folder is een aardig voorbeeld.

Als een gebruiker een voor hem technisch onbegrijpelijk heeft en ik ga hem proberen te helpen dan:
- de technische sleutels, een presentatie van een gegeven heeft voor hem geen betekenis, dat is wel betekenisvolle informatie voor mij. De velden tekst en cijfertjes zouden een fraude geval of voorbereiding van jaarcijfers kunnen zijn.
Ik wil niet eens weten wat het betekent als dat niets met zijn vraag te maken heeft. Wel lastig als hij zijn hand ergens boven houdt. Begrijp ik zijn probleem dan moet er een begrijpelijk ticket van gemaakt worden.
- is de actie een herstel aan code of database inhoud, dan moet een ander daarmee aan de slag informatie die voor hem begrijpelijk is. De inhoud van het werk van de gebruiker en de analyse van het probleem zijn voor hem betekenisloos

Mijn insteek:
In een interactie zie je de betekenis en context over hetzelfde als wat de informatie betekent voor een ieder nuances heeft.
Het wordt heel vervelend als onbegrip ontstaat door gebruik van dezelfde woorden waarbij geheel andere betekenissen met andere achterliggende informatie bedoeld wordt. "Document retention policy" waar gaat het dan over, bewaren informamtie:
https://ico.org.uk/media/about-the-ico/policies-and-procedures/2259025/retention-and-disposal-schedule-for-website.pdf

Wat je noemt als voorbeelden, tijdigheid valt onder availabiltiy, compleetheid onder integrity, toegankelijkheid onder confidentiality. Ik mis met de CIA wel de tijd van geldigheid. Het zo met de tijd ander eisen kunnen hebben.
Deze is denk ik belangrijker.
https://www.noraonline.nl/wiki/BIO_Thema_Applicatieontwikkeling/Identificatie_applicatieontwikkeling_objecten
Noemt BIVC BIV als de directe tegenhanger van CIA en de C van Controleerbaarheid.

Precies, wat voor mij informatie kan zijn kan voor jou data zijn. En we moeten het onderscheid tussen informatie en data scherp houden.

Je schaart m'n voorbeelden onder CIA, maar als we dat doen dan doen we bij het classificeren vaak te kort aan de specificatie, aan de details. Die gaan verloren.
Beschikbaar en tijdig zijn 2 verschillende elementen die wel met elkaar verbonden zijn, waar tijdig niet zonder beschikbaarheid kan zijn, maar andersom wel.

Integriteit betekent juistheid, maar niet per se compleetheid. Andersom waarschijnlijk wel. Maar misschien ook niet altijd.

Het context aspect impliceert dat je niet alleen doorziet of de waarde van de technische kant van een IT oplossing voor iemand er toe doet,
het impliceert in algemene zin dat je doorhebt en kan vertellen en garanderen als ontwikkelaar waardoor je oplossing wel of uitsluitend kwetsbaar is voor een bepaald type risico.
En kan dat risico qua tijd aspect sluipenderwijs zich opbouwen, vooral instantaan zich voordoen, direct en volledig op moment [t] te reduceren tot 0, kunnen effecten ervan langer na-ijlen nadat de oorzaak van het risico is ondervangen.
En kan dat risico qua tijd aspect zich ongepland voordoen en is het risico wel of niet bijstuurbaar?
Is er binnen een tijdspanne dat het risico zich voordoet om reductie richting 0 te bereiken toenemend meer inspanning nodig of kan worden volstaan met een gelijkblijvende inspanning binnen die tijdspanne?

Buiten de context van de IT oplossing weet de klant / opdrachtgever / informatie verwerker dan ook beter hoe uitgebreid de impact van het risico op de informatie verwerking kan uitpakken afgezet tegen welke beheersbaarheid je kan verwachten.
Nu worden teveel apples voor oranges verkocht.
De Google Apps suite is bijvoorbeeld doorgaans prima beschikbaar (available.
Een uitval van 1 van de applicatie zal doorgaans plotseling en kortdurend zijn.
Die specifieke IT oplossing zou voor een eerste indruk misschien qua risico's nihil hebben,
maar het gaat voor beheersbaarheid natuurlijk niet om een eerste indruk of beschouwing van de buitenschil.
Iedere IT-er, langdurige IT gebruiker en lezer van dit forum weet immers dat er onder de motorkap allerlei malafide scripts kunnen draaien en dat dus een op oog business as usual ogende buitenschil zeker nog geen vrijwaring is dat een risico zich niet actueel voordoet.
Je ontdekt het echter wel als je weet te vermoeden welk stuk informatie vanuit welke context niet hoort te veranderen en je door had dat je dat moest controleren als informatie verwerker en applicatie beheerder(s).
Dat kan met Google Apps weer lastiger zijn dan bij andere IT oplossingen die misschien weer eerder een database corrumperen (MS-Access en aanverwanten) en dus qua data weer andere risico's en andere bereidheid van maatregelen vergt.

Denk bij aard en tijdspanne ter illustratie aan het volgende;
Van die informatie die binnen een IT oplossing wordt onttrekken, buiten het oog van de informatie verwerker of überhaupt niet te stoppen valt zonder dat een diepe ingreep wordt toegepast, loopt dat minder snel in de gaten.
Dan weet je automatisch ook dat je de beheersmaatregelen daarvoor vernuftig moet inregelen.

Voor IT oplossingen die je binnen verschillende context zou inzetten zou je daarom best vanwege een ander soort set van beheersmaatregelen ook best steeds voor andere andere IT oplossingen kunnen kiezen.
Niet omdat je in een bepaalde functie een vervelend dwangneuroot moet zijn of omdat je wantrouwend bent maar puur omdat je de context van het risico snapt en beheersbaar maakt die beter bij je organisatie en diens klanten passen.

Inderdaad AMBI I1 voor degenen die dat nog wat zegt.