JERICHO, met de voeten in de klei.

Presentatie over: "JERICHO, met de voeten in de klei."— Transcript van de presentatie:

1 JERICHO, met de voeten in de klei.
Martien van Deth 18 March 2008

2 De actualiteit 11 March :03 Initial planning for the ISF project on Architectural Responses... At a high-level, it is proposed that the Architectural Responses to the Disappearing Network Boundary project workshops will: * examine how the network makes a connection between local computing devices (eg personal computers and hand-held devices) and the servers used by an organization * highlight architectural solutions that can help protect the expanding network boundary (eg by segregating 'trusted' networks)‏ * explore scenarios for remote access and different connection types (eg VPN, SSL, NAC and TLS)‏ * discuss protecting the 'inner zone' of servers and data centres (eg the issues involved with using HIDS, NIDS, malware protection gateways and firewalls)‏ * investigate the requirement to manage an increasingly complex corporate infrastructure while satisfying the business’ objective for mobility, interconnection and flexibility.

3 Onderwerpen Het standaard Jericho “fenomeen”. De 10 uitgangspunten.
Hoe daar mee om te gaan. De gevolgen van een en ander voor : - Consumerization - Infrastructuur en Extrastructuur - “substrate” - WoW (without overhead whatever)‏ - “WiFi” - IDM - SAAS - xSSO - DRM

4 Jericho, borrelpraat ? Oh ja, die lui van de deperimeterisatie
(ont-muring), uh weg met de firewalls.

5 Jericho Jericho forum does not aim to remove all firewalls nor in the networks neither at the perimeter of the network. Current difficulties are linked to the complexity of the flows administration(*) on the perimeter of the network, therefore this have to be reduced. However firewalls are required to ensure availability and to guarantee QoS. Jericho forum recommends keeping firewalls with basic features such as detection of port scanning, DoS… (*) Volume ( klanten en “regels” )‏

6 Het Jericho “fenomeen”
De essentie: Increasingly, information will flow between business organizations over shared and third-party networks, so that ultimately the only reliable security strategy is to protect the information itself, rather than the network and the rest of the IT infrastructure

7 Het Jericho “fenomeen”
De essentie: Informatie uitwisseling tussen business organisaties zal meer en meer geschieden over gedeelde en door derde partijen geleverde netwerken . Uiteindelijk is dan de enige betrouwbare security strategie het beschermen van de informatie zelf inplaats van het netwerk en de overige IT infrastructuur.

8 De 10 (11) uitgangspunten B.J.

9 De 10 (11) uitgangspunten, Forum basics -1
The scope and level of protection should be specific and appropriate to the asset at risk Security mechanisms must be pervasive, simple, scalable and easy to manage Assume context at your peril Devices and applications must communicate using open and secure protocols All device must be capable of maintaining their security policy on an un-trusted network All people, processes, technology must have declared a transparent level of trust for any transaction

10 De 10 (11) uitgangspunten, Forum basics -2
Mutual trust assurance levels must be determinable (mutual authentication)‏ Authentication, authorization and accountability must inter- operate/exchange outside your locus/area of control Access the data should be controlled by security attributes of the data itself Security requires segregation of privileges (even for administrators)‏ By default, data must be secured when stored, in transit and in use regarding its sensibility.

11 De 10 uitgangspunten, “eigen perceptie” -1
(Commandment 1) In our context, “asset” means “data and services” (Commandment 2) Term “reusable” has been added to describe a “coherent service”: Security services have to be defined in order to ease their reuse in different context. (Commandment 2) The term “defence in depth” has been removed to avoid confusion between different notions. The new principles “Security mechanisms must be integrated into the information system” is proposed. (Commandment 3) In order to take in account a possible modification in the AF/KL context, “Periodic” has been added to re-evaluate security times to times. (Commandment 4) “as appropriate” has been added in the “In Brief” section in order to be closer of the initial definition of the Jericho forum (Commandment 5) The word “Devices” is used instead of “systems” to meet the main statements of the 5th commandment.

12 De 10 (11) uitgangspunten, “eigen perceptie”-2
(Commandments 5) Attendees stressed that the fact that “Devices must protect themselves regarding the context” are not the responsibilities of AF/KL: This statement aims vendors. The AF/KL responsibility is to choose a secure device by construction . For legacy devices, a migration plan has to be defined and put them into a critical zone during the time (Commandment 6) In the future, the trust model has to be shared by AF and KLM (Commandment 7) Not only authentication but all security services must be adapted to sensivity (Commandment 7) Trust is mutual and services must be adapted as so. (Commandment 8) “must” as be changed into “should” in order to allow specificities (Commandment 9) “must” as be changed into “should” in order to allow specificities. “Embedded” has been changed to “embedded/attached”. (Commandment 11) Any data should have a default security which has to be determined in the security policy. In order to reflect this aspect, the sentence “Data must be protected by default as soon as created “ has been modified into “Data must be protected at the good level as soon as created” (Commandment 11) In order to precise the “In Brief” section, the sentence “Removing the default security must be a conscious act” has been added accordingly to Jericho’s commandments.

13 Van uitgangspunten naar “Architecture by principles”
Risico analyse is verplicht. Veiligheids maatregelen moeten geselecteerd worden op basis van de risico analyse. Veiligheid moet simpel zijn. Veiligheids mechanismes moeten geintegreerd zijn in het informatie systeem. Een “trust model” moet gedefineerd, uitgerold en gedeeld worden in de AF/KL contekst. Eisen te stellen aan veiligheids maatregelen moeten conform de “gevoeligheid” zijn en afgedwongen worden in het trust model. Veiligheid moet dynamisch gecontroleerd en afgedwongen worden. Intern gemanagede identities moeten niet gedupliceerd zijn.

14 Architectuur principes, vervolg..
Data Data moet geklassificeerd en, met inachtname daarvan, beschermd worden. Veiligheids attributen moeten onderdeel uitmaken van c.q. gekoppeld zijn aan de data. Data moet op het juiste niveau beschermd worden direct op het moment van ontstaan. Veiligheids attributen moeten de toegangsrechten specificeren en de component “tijd” bevatten. Systemen & applicaties Uitsluitend standaard/open protocollen moeten gebruikt worden. Veiligheids mechanismes (inclusief encryptie) moeten een onderdeel van het protocol zijn. Bijvoorkeur kiezen wij protocollen met ingebouwde veiligheidsmechanismes. Systemen moeten zichzelf beschermen.

15 Architectuur principes, vervolg..
Netwerk De (laatste) ommuring voorziet in basis beveiliging (= QoS: en dat alleen als alle andere principes toegepast zijn). De bescherming vindt zo dicht mogelijk plaats bij de “assets” (data en diensten). Het netwerk alleen lost niet alle veilgheids problemen op. Veiligheids diensten Veiligheids diensten moeten bijdragen aan de implementatie van het “trust model”. Veiliogheids faciliteiten moeten aangeboden worden als schaalbare en herbruikbare “cohaerente” diensten. AAA moeten co-opereren buiten de het gecontrolerde interne gebied. Organisatie Scheiding van verantwoordelijkheden moet afgedwongen worden. Onafhankelijke “control” moet gecreerd worden.

16 Jericho en security zitten al tot diep in de haarvaten
Skyteam Open Skies Homeland Security E-Commerce Paspoort Diplomatiek paspoort Visum Schengen Massa toerisme Previum “Simpel” = Federation of trust = Global free enterprise = IDM provisioning = Grenzenloze business = Certificate, herbruikbaar = Role based access = Authorisatie = eSSO = Consumerisatie = Strong authentication = (veilige) self-service

17 Consumenten technologie voor zakelijk gebruik, zegen of vloek ?
Consumerization Consumenten technologie voor zakelijk gebruik, zegen of vloek ?

18 Resistance is futile (Startrek, Cyborgs)‏

19

20

21 Airplane security

22 Infrastructuur en Extrastructuur -1
Vorige eeuw: Veel company specifieke IT oplossingen, “speciaal” tot op divisie niveau (divisie verzuiling). Rond het Milennium: Company breed gestandaardiseerde IT, maar nog wel in de bedrijfskleur “blauw” gespoten. Na het Millenium: Corporate Commodity Industrie Standaards (er is geen airline spreadsheet, echt niet.)‏ Verschuiving van “interne diensten” naar “externe diensten”

23 Infrastructuur en Extrastructuur -2
Buiten (!) de company bestaat er een hoeveelheid uitontwikkelde commodity services tegen commodity prijzen. The corporate infrastructuur is in competitie met externe commodity services. Deze “extrastructuur” is in toenemende mate “businessgrade” en voldoet aan “goed is goed genoeg” in vele gevallen. Enterprise Substrate: Het enterprise “substraat” bestaat uit zowel corporate infrastructuur als “extrastructuur”.

24 WOW, op kantoor Without overhead Workstation Web only Workstation
Without overhead WAN W'ones own Workstation IT4ME programma

25 WOW, maar dus ook (vooral..) thuis
Internet centric VPN (ipsec of SSL)‏ 2 Factor RSA service Healthcheck (Cisco NAC)‏ WiFi, ADSl,Kabel, UMTS,WiMax.. WASSA (web attached secure storage anywhere)‏ Community site (Google Enterprise APPs- “sites”)‏ Digitaal financieel rugzakje... Helpdesk

26 “WiFi”, positionering Filosofie: Zoals buiten, zo ook binnen (infra- en extrastructuur vallen samen). Access van binnen EN buiten is Internet centric. Hiermee is “WiFi” gewoon een manier van Internet toegang, net zoals ADSL thuis, een 3G/4G UMTS HSDPA of wat dan ook. Niets speciaals dus, de kern is een secure tunnel over het Internet faciliteit. Elke provider c.q. technologie voldoet, we doen geen aannames over de veiligheid van het pad c.q. Provider.

27 “WiFI” , consequentie positionering
We kunnen elk moment van Internetprovider wisselen. De access technology in het kantoor is niet “iets anders” (efficient dus, 1 corporate service). Hotspots in kantoren geven Internet toegang, niet meer, niet minder. Om niet in NOVA te komen onderdrukt SSID of “smurfnet”. Encryptie en access codes niet vereist (!). Soms wel ingeval resource protection (DoS). NB: Een vreemde PC op een ethernetkabel in een KLM kantoor krijgt Internet toegang. Geen aansprakelijkheidheid als je maar NIET beveiligt...)‏

28 “Moskowitz” praat Wij denken dat xxx voor het aanbieden van dit netwerk kan worden aangemerkt als 'mere conduit', het doorgeven van van een ander afkomstige informatie of het verschaffen van toegang tot een communicatienetwerk (art. 6:196C BW). Dit betekent dat KLM niet aansprakelijk is voor de doorgegeven informatie over het netwerk, indien KLM: - niet het initiatief tot de doorgifte neemt; - niet bepaalt aan wie de informatie wordt doorgegeven; en - niet degene is die deze informatie heeft geselecteerd of gewijzigd. Indien xxx slechts een WiFi netwerk aanbiedt aan derden en zich op geen enkele wijze met de content bemoeit, zal de aansprakelijkheid van KLM voor de doorgegeven informatie via haar WiFi netwerk op grond van dit art. 6:196C BW zijn uitgesloten. Het bovenstaande geldt ten aanzien van de aansprakelijkheid voor de doorgegeven informatie. Wat verder nog denkbaar is, is dat gebruikers xxx aansprakelijk stellen voor het functioneren van het netwerk zelf. Indien KLM ook deze aansprakelijkheid wil inperken, zou gedacht kunnen worden aan het toepassen van gebruiksvoorwaarden. Indien het technisch mogelijk is om gebruikers van het WiFi netwerk naar een website van KLM te leiden bij gebruik van het netwerk, zouden deze gebruiksvoorwaarden bijvoorbeeld op de homepage van deze website geplaatst kunnen worden.

29 Intermezzo: “Unbundling”
Security oplossingen tenderen monolitisch te zijn. Wij ontkoppelen: - RSA 2 factor (door meerdere systemen aanroepbaar). - Certificates (single service)‏ - eSSO (buiten veelvoud van access management systemen). - Een “losse” IDM service. En vervolgens veel aandacht nodig om dingen niet doorelkaar heen te laten lopen.

30 IDM IDM SUN Inhouse (Mio Euro prject)‏
provisioning, password reset, RBAC Enterprise substrate conditie (de basis van alles), identity/security besteed je (voorlopig) niet uit (!). TIP: klein zakelijk zou eens naar OpenID moeten kijken (en dat dan inhouse draaien...). Dat kost beduidend minder dan een paar miljoen.

31 SAAS Software as a Service. Volgens onze visie een element in “Enterprise Substrate”. Eisen: - Gebruikt “onze” RSA service - Gebruikt “onze” certificate service - Acteert op “onze” IDM - Wij doen de “authorisaties” - Speelt “ons” eSSO spel mee. Wel leuk, niet makkelijk, wel mogelijk ?

32 Uitstapje naar eSSO presentatie (los)‏

33 DRM Digital Rights management, bekend van iTunes.
Bestaat echt, bijna Jericho: Oracle IRM - Document certificate protected. - Geen leesbare copy/paste (ook niet printscreen!)‏ - Printen kan protected worden. - Copy/paste in ander document voor rechthebbenden leesbaar, voor anderen niet Nog niet helemaal uitgerijpt en MS Office centric (geen OO en equivalenten). Voordeel van de twijfel dus.

34 Certificates PKI en x.509. Men verklaart je voor gek. KLM onderzoekt “Trust Alert” . Certificate management en re-vocation is problematisch. Trust Alert lost dit op met “selfdestruction” certificates (time based). Scenario (utopie ?): T.A. Certificate te bekomen op basis van 2 factor. Server staat “publiek” !. Met de dagpas hebben we dan SSO , zowel voor interne als externe services.

35