donderdag 26 juni 2008

Governance Risk & Compliance

Een aantal sessies gaan over GRC, een boeiend onderwerp met vele invalshoeken. Er is zo een grote druk op het aantoonbaar maken van het in control zijn dat deze onderwerpen erg veel aandacht misschie wel te veel (de risico's van het in control komen, hmm misschien wel een goed onderwerp voor een artikel)

De presentatie van Nick Leason had hier ook in zekere zin raakpunten mee.
Het meeste van wat ij te vertellen had is natuurlijk in zijn boek, in het nieuws en in de film aan bod gekomen. Maar er zaten toch wel een paar andachtspunten in die naar mijn idee nog steeds onderbelicht zijn in ons huidig systeem van controle.
  1. De drang om te presteren
  2. Te weining kenis van zaken
  3. Vertrouwen
  4. Het niet (real time) gekoppeld zijn van systemen
1. De drang om elke maand of elk kartaal met goede cijfers te komen. In essentie heeft dit al verschillende bedrijven in problemen gebracht omdat mensen zich hierdoor soms gedwongen voelen om "kreatief" te worden.

2. Te weinig kennis van zaken: ZIjn managers hadden totaal geen zicht op wat hij allemaal aan het doen was. Als er dus al kritische vragen gesteld werden aan zijn managers dan kwamen direct weer bij hem terug omdat hij alleen wist wat er allemaal gebeurde.
Maar ook de TOP 4 accountants stuurde auditors die eigenlijk geen verstand hadden van waar hij mee bezig was en stelde dus de verkeerde vragen mdat ze niet drufde toe te geven dat ze geen kennis van zaken hadden.

3. Nummer twee is dus de aanleiding voor drie, zijn managers moesten op een gegeven moment blind op hem vertrouwen. Maar oo de Bank of England vertrouwde de goede naam van Barrings. Dit ging zo ver dat ze uiteindeling in staat waren het 20 voudige te lenen dan dat ze uiteindelijk toegestaan waren om te lenen. Zelfs toen ze daar geen geld meer van konden lenen, stelde niemand de juiste vragen maar werden er aandelen uitgegeven om weer geld te krijgen.

4. Het feit dat de twee systemen waarin de gegevens werden ingevoerd niet realtime gekoppeld waren gaf hem elke keer een maand de tijd om met de cijfers te knoeien zodat aan het einde van de maand het verschil tussen deze twee weer 0 was.

Waar het naar mijn idee dus steeds op neer komt is dat mensen vaak werk uitvoeren op een te hoog niveau of met te weinig kennis van zaken.
Er wordt geen goede functiescheiding door gevoerd
E wordt te weinig aan controle gedaan.
Verder kan er ook gesteld worden dat verschillende lagen in een organisatie verschillende talen gesproken worden waardoor er allerlei misverstanden kunnen ontstaan

woensdag 25 juni 2008

Information-Centric Security

Onderwerpen hier waren Risico en Security Architectuur
Dataclassificatie en e-Discovery (e-Discovery is wet/regelgeving die een bedrijf verplicht informatie te leveren aan een partij die een rechtzaak wil beginnen tegen je dit bedrijf) Dit heeft natuurlijk nogals wat implicaties op data opslag, labeling e.d.

Ook DLP (Data Loss Protection) is hier besproken. Hierbij ging het over producten die je in staat stellen om data in de organisatie te vinden :), te labelen en te beschermen als het gaat om het weg "lekken" van deze data.

Naar mijn idee is het goed dat leveranciers met producten komen die het mogelijk maken gevoelige data in de organisatie te vinden. Op zich een goed idee maar daarvoor moet je dus in staat zijn data te labelen en om data te kunnen labelen moet je aan data classificatie gedaan hebben. Daarnaast is het al fout als gevoelige informatie (data) "gezocht"moet worden, naar mijn idee een veel groter probllem om mee te beginnen.

Naar mijn idee en geleerd uit ervaring in informatiebeveiliging, zijn nog veel bedrijven hier niet aan toe. Veel beslissingen over informatie in relatie tot vertrouwelijkheid en integriteit worden nog veel te vaak op de achterkant van een sigarenkistje genomen.

Verder zal de eigenaar van de data gevonden moeten worden, want hij/zij is degene die een beslissing kan nemen over de vertrouwelijkheid en integriteit van deze data.

Dat wetgeving bedrijven gaat dwingen informatie te kunnen overleggen wanneer er om gevraagd wordt is op zich niet nieuw (de belasting dienst doet dit al jaren). Maar dat deze informatie overlegd moet worden aan partijen die een rechtzaak willen beginnen geeft het op zich een nieuwe dimensie. Vooral verzekeringsmaatschappijen zullen hier de gevolgen van ondervinden. In hoeverre deze wet invloed gaat hebben op nederlandse bedrijven zal moeten gaan blijken.


DLP tools:
DLP tools zullen zeker bij bovenstaande wetgeving een rol spelen (al is het maar om de data te vinden) De besproken tools bevatten een zo genoemde discovery functie. Daarnaast worden deze tools gebruikt om het lekken van informatie tegen te gaan. Daarvoor maken ze gebruik van IDS technieken maar kennen veel meer signatures om het lekken van informatie te kunnen detecteren.
Als we nu even hierbij stil staan:
IDS technologie is er al een aantal jaren, maar hoe volwassen is het gebruik hiervan.
Verder zul je bij het gebruik van DLP tools dus veel meer false positives, false negatives e.d. hebben. Wie gaat of kan dit daadwerkelijk managen.

Naar mijn idee zal het nog wel enige jaren duren voordat deze tools veel maar ook goed gebruikt kunnen worden.

Unified Communications

Onderwerp hier was de verschuiving van traditionele telefonie naar IP telefonie dat vanuit de Telefoniemaatschappijen nog lang niet uitgenut was. Redenen hiervoor kunnen onder andere zijn dat de telco's gewend zijn aan een soort koppel verkoop. Koop je onze centrale dat heb je onze telefoons nodig.

Dit heeft ruimte gecreeerd voor leverancier die workgroup/ collaboration producten leveren. Leveranciers zoals Microsoft en IBM zijn dus gekomen met producten zoals MS-OCS, IBM Sametime en ook CISCO is dus sterk in de markt met o.a. WEB-EX.

De traditionele Telco's zijn dus strategische samenwerking aangegaan omdat ze achter lopen als het gaat om workgroup achtige oplossingen.
Hierbij moet je denken aan:
  1. IP Telephony
  2. Unified messaging
  3. Presence
  4. Fixed Mobile Convergence
  5. Telepresence and Video Conferencing
Bovenstaande lijst is tijdens de sessies behandeld door de analist waarbij hij ingegaan is op wat hiermee wordt bedoeld en wie daar wel of niet sterk in is.

Wat hierbij besproken is, is; Compliance, denk daarbij en het opslaan van voicemail als bericht waarbij privacy en bewaartermijnen belangrijk worden

maandag 23 juni 2008

Vandaag was de focus Federated Identity

Business driver was er één van de onderwerpen, waarom zou je aan federated identity beginnen.
Allereerst moet natuurlijk de vraag beantwoord worden wat is nu eigenlijk federated identity. Deze vraag werd op zich niet echt beantwoord maar zal uitleggen wat ermee bedoeld wordt.

Als voorbeeld: waar het hier om gaat is dat een organisatie niet alle gebruikers bij een zakenrelatie wil registreren. Als het om één relatie gaat is dat op zich geen probleem maar heb je veel zaken relaties dan wordt het een probleem alle gebruikers van deze relatie die toegang tot jou applicatie willen te registreren.

Om nu toch de gebruikers van deze relatie toegang te geven op jou applicatie kun je bijvoorbeeld vertrouwen op een aantal gegevens die door de zakenrelatie worden meegestuurd als toegang gezocht wordt tot.
Bijvoorbeeld hier is een gebruikers en dit is zijn ID en zijn rol binnen de organisatie van de zaken relatie. Op basis van ID en rol wordt toegang verleend tot.
Dit kan alleen op basis van vertrouwen in de zakenrelatie

Het bespaard het bedrijf de registratie van alle gebruikers van de zakenrelatie, dit betekend een vermidering van de beheerlast, beheer vind plaats bij de relatie.

Om dit mogeliijk te maken zijn allerlei afspraken, protocollen en standaarden noodzakelijk. In de sessies was het belangrijkste de onderliggende afspraken waarop het vertrouwen gebasseerd is onderbelicht. De protocollen en standaarden kwamen uitgebreid aan bod. dit maakte het minder interessant omdat dat prima op het internet verkrijgbare informatie is.

Verder werd een aantal federatieconcepten uitgelegd, zoals iDP (identity provider federation) SP (Service Provider federation ) en Federated Identity Community.

Voornaamste aandachtspunt is volgens mij het vaststellen van het niveau van vertrouwen. Alle concepten gaan uit van authenticatie maar het moeilijkst te regelen is de autorisatie. Dat laatste schieten de protocollen op dit moment nog in te kort.

Belangrijkste standaarden zijn:
  • SAML (Security Assertions Markup Language) Identity Federation gebasseerd op het uitwisselen van SAML tokens
  • WS-Fed (Web Services Federation) Een meer generiek framewerk gebasseerd op WS-Trust dat meerdere token typen ondersteund.
  • WS-SX (Web Services Secure Exchange) is een uitbreiding op de WS-Security standaard wat het mogelijk maakt vertouwde SOAP berichten uit te wisselen. Eigenlijk is het een uitbreiding op WS-Trust, WS-SecurityPolicy en WS-SecureConversation
Op het gebied van vertrouwen en Compliance heeft Liberty Alliance vandaag een belangrijke mededeling gedaan:

Namelijk het oprichten van een Special Intrest Group
Die zich bezig houdt met het beschrijven van een:
  • Identity Assurance Framework
  • Identity Governace Framework
HIerbij gaat het vooral om vraagstukken zoals:
In welke mate kan ik vertrouwen op mijn Identity provider en afspraken over de gegevens die meegestuurd worden, hoe lang worden deze bewaard waarvoor zijn ze bestemd en mogen ze gebruikt worden.
Allerlei vraagstukken die als het gaat om de wet bescherming persoonsgegevens van belang zijn. Ze geven dus meer controle aan de eigenaar van deze gegevens over het gebruik van zijn gegevens. Dit zijn dus frameworks die User Centric Identity Management ondersteunen. Iets wat tijdens deze presentaties niet aan bod is gekomen

zondag 22 juni 2008

Aangekomen


Gisteravond ben ik aangekomen
na een erg lange reis.
Vandaag is het begonnen onder andere door de registratie.
Zelfs tijdens deze registratie moest er een ID getoond worden met foto.



Het is dat het voor het werk is dat je hier naar toe gaat want het is echt vreselijk om hier te zijn
Nu nog even alle presentaties downloaden zodat er morgen ochtend goed voorbereid aan de sessies begonnen kan worden.