New security rules on tap for credit-card handlers
Next version of Payment Card Industry security standard due out in October
By Ellen Messmer , Network World , 08/28/2008
ICompanies that handle credit cards can expect to see revised security rules released in early October, according to the group responsible for maintaining the Payment Card Industry security standard for storage and processing of credit and debit cards.
The next version of the 12-part PCI Data Security Standard is aimed at clarifying questions that merchants and service providers had regarding the current PCI DSS 1.1 standard, says Bob Russo, general manager of the PCI Security Standards Council. Some changes in the forthcoming Version 1.2 may prompt merchants and service providers to make adjustments in their security practices to achieve PCI compliance in the future, he adds.
Read the latest WhitePaper - Determining the cause of poor application performance
Click to see: Bob Russo, manager of PCI's Security Standards Council
"We're still tweaking this, but we expect to be finished by September 8th," Russo says. DSS 1.2 will be shared with council members including merchants; card association founders, such as Visa and MasterCard; card processors; and vendors certified to perform network scans or audits as part of the PCI compliance process.
Related Content
Payment card standards body moves ahead on application standard
PCI standard's mandate raises conflict-of-interest question
Payment Card Industry updateBLOG
PCI standards body moves ahead on payment-application cert
Changes to PCI standard not expected to up the ante
TriCipher offers strong authentication as a serviceBLOG
Cisco unwraps blueprint for healthcare security
Sun offering support for OpenSSOView all related articles
The PCI DSS 1.2 document will be presented at the council's upcoming community meetings in Orlando and Brussels. Upon the official October publication of PCI DSS 1.2, the council will set deadlines for supporting the revised standard. Under discussion now is a sunset date of June 30, 2009 for PCI DSS 1.1.
PCI DSS 1.2 is not yet final, but the council is previewing what businesses can expect to see by October.
For one thing, there will be a clarification on the first rule related to using firewalls to protect cardholder data; the revised standard will change the requirement to review firewall rules from every quarter to every six months.
The council also will remove references to Wired Equivalency Privacy (WEP) to emphasize the use of stronger encryption and authentication for wireless networks. Companies using wireless technologies will be expected to implement "industry best practices," including 802.11x. Specifically, new implementations of WEP are not expected to be allowed after March 31, 2009, though current implementations could continue longer -- until June of next year, under the council's current thinking.
In addition, the revised standard probably will remove the requirement to disable service-set identifier (SSID) broadcast, because disabling SSID broadcast does not prevent a malicious user from determining the SSID, according to the council.
Among other clarifications, the revised standard will note that the requirement to use antivirus software extends to all operating system types. Software patching revisions will clarify that a "risk-based approach" for prioritization of patch installation is acceptable. In the matter of assigning a unique ID to each person for computer access, the Version 1.2 standard is expected to clarify that both passwords and passphrases — authentication challenges that require answers that the user should know — are acceptable for PCI compliance.
Want to compare security products? Visit the IT Buyer's Guides now.
A clarification related to restricting physical access to cardholder data makes it clear that this requirement also pertains to paper-based media containing cardholder data, as well as electronic media.
Some other clarifications are expected to detail the need for a protected environment to preserve an audit trail for network resources related to cardholder data. For instance, revised language will clarify that three months of audit-trail history must be immediately available for analysis or quickly accessible. In addition, the council will seek to clarify that both internal and external penetration tests are required.
After the release of PCI DSS 1.2, the next major change to the PCI security standard isn't likely soon, Russo says. "We're hoping to stick to a two-year cycle after that," he says. PCI DSS 1.2 has been under discussion for more than a year as the council reviewed the 2,500 questions it received.
zondag 31 augustus 2008
P&G outsources security to IBM
Proctor & Gamble outsources security to IBM, but keeping security staff
Opts for IBM ISS managed services to save money, boost security
By Ellen Messmer , Network World , 08/29/2008
Proctor & Gamble, the global manufacturer of household products, Friday said it has selected IBM ISS to provide managed security services.
"By teaming with IBM ISS, our objective is to both strengthen our security systems and improve the efficiency and effectiveness of our security operations," said Willie Alvarado, P&G’s Enterprise Infrastructure Services director in a statement.
Read the latest WhitePaper - Top 10 Considerations for Scaling a WAN Acceleration Solution
While P&G declined to discuss details about the security outsourcing arrangement, IBM ISS Director Peter Evans says the managed services will include internal network protection and perimeter-based defense. "Managed intrusion prevention, firewall, server protection, managed desktop and managed mail are all part of this," he says. (Compare intrusion prevention products.)
IBM ISS earlier this year indicated it was expanding its managed services portfolio, and the 5-year deal with P&G is believed to be the largest single managed services deal the vendor has seen, though it is declining to reveal dollar figures.
Related Content
IBM, Tata each dig into managed security services
Outsourcing security tasks brings controversy
Six burning questions about network security
Banks mining cash from their computer gear
IBM flash memory breaks 1 million IOPS barrier
Rackable Systems divests,; Nexan adds SMB NAS device; IBM releases XIV clustered storageBLOG
Dell gains, Sun loses in worldwide server market
IBM commits $300 million to disaster recovery build-outView all related articles
P&G will not be shedding security staff in this outsourcing arrangement, according to Evans.
"P&G will still maintain their security staff," says Evans, pointing out that they will now have more time to focus on strategic projects for online collaborative business or in mergers.
IBM ISS operates several security operations centers where remote monitoring and management of customer networking operations takes place. Under the outsourcing arrangement, P&G will partner in what IBM ISS calls a "virtual security operations center" (VSOC) in which P&G will have a Web-based portal that offers vulnerability assessment, data correlation and analysis. The VSOC will consolidate monitoring and maintenance of four IBM ISS Proventia SiteProtector management consoles in North America, Europe and Asia.
IBM ISS also anticipates the services for P&G may be expanded to include identity and access management and data-leakage prevention services in the future.
Opts for IBM ISS managed services to save money, boost security
By Ellen Messmer , Network World , 08/29/2008
Proctor & Gamble, the global manufacturer of household products, Friday said it has selected IBM ISS to provide managed security services.
"By teaming with IBM ISS, our objective is to both strengthen our security systems and improve the efficiency and effectiveness of our security operations," said Willie Alvarado, P&G’s Enterprise Infrastructure Services director in a statement.
Read the latest WhitePaper - Top 10 Considerations for Scaling a WAN Acceleration Solution
While P&G declined to discuss details about the security outsourcing arrangement, IBM ISS Director Peter Evans says the managed services will include internal network protection and perimeter-based defense. "Managed intrusion prevention, firewall, server protection, managed desktop and managed mail are all part of this," he says. (Compare intrusion prevention products.)
IBM ISS earlier this year indicated it was expanding its managed services portfolio, and the 5-year deal with P&G is believed to be the largest single managed services deal the vendor has seen, though it is declining to reveal dollar figures.
Related Content
IBM, Tata each dig into managed security services
Outsourcing security tasks brings controversy
Six burning questions about network security
Banks mining cash from their computer gear
IBM flash memory breaks 1 million IOPS barrier
Rackable Systems divests,; Nexan adds SMB NAS device; IBM releases XIV clustered storageBLOG
Dell gains, Sun loses in worldwide server market
IBM commits $300 million to disaster recovery build-outView all related articles
P&G will not be shedding security staff in this outsourcing arrangement, according to Evans.
"P&G will still maintain their security staff," says Evans, pointing out that they will now have more time to focus on strategic projects for online collaborative business or in mergers.
IBM ISS operates several security operations centers where remote monitoring and management of customer networking operations takes place. Under the outsourcing arrangement, P&G will partner in what IBM ISS calls a "virtual security operations center" (VSOC) in which P&G will have a Web-based portal that offers vulnerability assessment, data correlation and analysis. The VSOC will consolidate monitoring and maintenance of four IBM ISS Proventia SiteProtector management consoles in North America, Europe and Asia.
IBM ISS also anticipates the services for P&G may be expanded to include identity and access management and data-leakage prevention services in the future.
Uitbesteden van security??
Zin en Onzin
11-12-2007,10:55 doorRedactieReacties: 1
In het kader van de themaweek Managed Security vorig jaar betoogde ik dat het uitbesteden van beveiliging een hoge mate van maturiteit in de organisatie vraagt: je moet immers weten wat je aan beveiliging moet doen, voordat je dat door een ander kan laten doen. Om een smart buyer te zijn moet je méér materiedeskundigheid hebben dan als je het zelf doet, want bij zelf doen geval kun je nog 'Iteratief' kennis opbouwen. En bijgevolg zul je er meer van moeten weten dan je leverancier. Maar goed, dit jaar wil ik iets minder filosofisch naar deze materie kijken. Het concept Managed Security Service Provider (MSSP) lijkt bedacht te zijn door Counterpane – nou ja, dat zeggen ze zelf. Gartner heeft dit MSSP concept eind vorige eeuw omarmd en massaal aanbevolen. Volgens het magic quandrant Noord Amerika van 1/8/07 staat Verisign bovenin (zowel in visie als in het vermogen tot uitvoering), op de voet gevolgd door IBM, AT&T en Symantec en meer op afstand gevolgd door BT en onze eigen KPN (nou ja, Getronics dan). In de Europese Magic Quadrant van April 2007 staan eigenlijk alleen Cybertrust en Integralis als partijen die een geschiedenis hebben in Security, de rest zijn dezelfde doorsnee mix van systeem integrators en telco’s die alles aanbieden wat een beetje potentie lijkt te hebben. Wat overigens niets hoeft te zeggen over de kwaliteit. In dit licht moet je ook de overname van GPR door de KPN zien: BT heeft Counterpane, Deutsche Telecom heeft debis en dan kun je niet achterblijven. Deze 'me too' scenario’s spelen een grote rol, waardoor grote bedragen worden gespendeerd om het portfolio op hoofdlijnen vergelijkbaar met dat van de concurrentie te maken. De vraag of het allemaal even zinvol is voor de klant, krijgt minder aandacht zo te zien. De uitkomst van Gartner is niet verwonderlijk, als je je realiseert dat het zwaarst wegende aspect in deze weging de omvang van de firma en de financiële positie is. Met dit soort vergelijkingen zul je als je een auto koopt thuiskomen met een Opel of een Fiat. Prima auto’s hoor, maar als je naast iemand parkeert in een Donkervoort of een Spyker, steekt het wat schraal af. Als je een auto moet hebben om indruk te maken op de buren, is een Kadett of een Panda duidelijk een mismatch. En helemaal als je nog geen rijbewijs hebt – het gaat op den duur toch opvallen dat je er nooit in rijdt. Wat is er te koop? Managed Security is een containerbegrip, waarin allerlei beveiligingszaken in een doosje met een strik erom aangeboden worden. Om te voorkomen dat je appels en peren vergelijkt, is een korte rondgang noodzakelijk. Bij het vergelijken van abstracte, samengestelde proposities als Managed Security moet je nu eenmaal onder de motorkap kijken om te zien wat het aanbod nu precies inhoudt. Het resultaat van een rondgang langs de aanbieders lijkt dat het beheer van security devices geouttasked wordt. Security Devices variëren een beetje, waarbij sommige leveranciers zich beperken tot de klassieke firewalls, maar het merendeel woont inmiddels wat hoger de OSI stack in door ook allerlei IDS/IPS-achtigen en crypto spul te beheren. De meeste aanbieders concentreren zich bij het beheer van devices op de netwerk perimeter, sommigen durven de sprong het interne netwerk in, aan. Een specifieke categorie zijn de aanbieders van Managed PKI services, maar in de praktijk lijkt deze markt zeer beperkt. Nu ja, de meeste bestuurders krijgen nog steeds puistjes als je PKI roept…. Als toefje op de taart wordt over het algemeen ‘threat management’ in allerlei varianten aangeboden, waarbij je eerder dan de rest van de wereld weet dat er een gat zit in een stuk software, zonder dat je daarvoor zelf allerlei bronnen in vele talen moet gaan doorwaden om deze informatie te vinden. Om eens te gaan kijken wat je aan Managed Security zou hebben of wat je zou willen aanbieden, moeten we nader ingaan op de verschillende onderdelen van de dienstverlening. Managed Security Devices Deze categorie omvat het bulk van alle aanbieders. Met het uitbesteden van het beheer van een stel appliances is op zich niets mis, omdat die dingen ook beheerd moeten worden. Bij de producten die zich op de applicatielaag begeven is er een behoorlijke patchcyclus en als het volgende gat in een rar of chm parser gepubliceerd wordt, zal een externe leverancier wellicht sneller patchen dan je dat zelf zou doen. Doen dus. Als je vervolgens leest dat 'Managed Firewall Services' een 'totaaloplossing voor de implementatie en beheer van een effectief Security beleid binnen een organisatie' bieden “door inzet van ervaren, gecertificeerde security engineers en consultants”, ga je toch weer twijfelen. Firewalls die uitstekend helpen binnen een netwerk? Is dit een leverancier die voldoende kennis heeft? Het in de lucht en gepatched houden van een firewall, een VPN concentrator, een IDS of een log correlatiedoosje is het simpelste stuk, je moet echter nog steeds iets dóen met dergelijke apparaten. Zeker met de meer geavanceerde. Zoals ik laatst als predikte op dit platform moet je als bewaker weten wat je bewaakt omdat je anders niet weet wat je ziet. Dit houdt in dat je als MSSP-klant je leverancier in detail op de hoogte moet brengen van wát en wie er bewaakt wordt en of er intern (of extern) operationeel iets speelt waardoor normaliter valide verkeer dat op eens niet hoeft te zijn. Dat kan zoiets banaals zijn als een medewerker die uit dienst is gegaan. Het “detecteren van afwijkingen in het netwerk van de klanten en het onmiddellijk op de hoogte brengen van de klant” is dan ook grotendeels wensdenken: alle beperkingen en nuances van bewakingssystemen gelden, ongeacht of deze nu in-house dan wel geoutsourced bediend worden. Managed Security Devices zal helaas zelden meer voorstellen dan het in de lucht houden van onderbenutte geavanceerde doosjes. De bijdrage aan de veiligheid is dan ook gering, de rationale is puur kosteneffectiviteit. Hoewel effectief, je geeft minder uit aan iets wat je net zo goed kan laten, omdat je er nog niet aan toe bent. Haal eerst maar je rijbewijs voordat je die Panda koopt. Managed Secure Internet Hosting Feitelijk is dit gewoon hosting met een modieus verkooppraatje, vrijwel iedere echte hosting provider regelt de beveiliging goed. Ze moeten wel. Dit is de meest volwassen vorm van Managed Security. Managed Secure Internet Access Deze vorm kan wel interessant zijn om te outsourcen: voor je inbound proxy staat een filtering proxy die virussen en spyware vangt en de meest omineuze sites op een blacklist zet. Deze extra laag kan veel ellende voorkomen. Hierbij geldt dat dit alleen het algemene basisniveau kan leveren. Een nadeel om in de gaten te houden dat een filter op de proxylaag de feitelijke bandbreedte aanzienlijk beperkt. Dit is ondanks de uitvoerbaarheid en het evidente nut verassend genoeg een weinig gangbaar product bij de grote MSSP. Het concept wint wél terrein bij de reguliere ISP’s, waar het waarschijnlijk beter past. Managed Secure E-Mail Deze categorie wordt door een paar gespecialiseerde aanbieders geleverd, en maakt vaker deel uit van een pakket van weer een andere aanbieder. Het beveiligen van mail laat zich goed outtasken, zo lang de afnemer niet verwacht dat het fire and forget is en een tamelijk algemeen beveiligingsniveau vraagt, net als bij de Secure Internet Access. Een aandachtspunt is mail integratie met andere functies zoals webmail: mailscanners werken op SMTP niveau waardoor de eigen mailinfra niet meer extern zichtbaar mag zijn. Het kan daardoor conflicteren met webmail en de wens op userniveau verschillende regels neer te zetten. Het wordt anders als je bijvoorbeeld meer dan de standaard beveiligingsfuncties vraagt; wil je dat alles wat positief herkend wordt als virus of spam verwijderd wordt zijn er tal van prima aanbieders die dit wellicht goedkoper kunnen dan je het zelf zou doen met dezelfde standaardproducten. Wil je dat informatielekken door eigen medewerkers of alle 0-day’s worden tegengehouden, dan zul je merken dat iets anders dan een kadett niet in het assortiment zit. Managed Threat Management Wat je uitbesteedt met deze dienst is het afspeuren van de boze buitenwereld op nieuwe bedreigingen. Je MSSP koopt het op haar beurt weer in bij een hierin gespecialiseerde speler. Threat Management is prima etalagemateriaal, want je laat zien dat je proactief goed op de hoogte bent wat je bedreigd. En de besparing kan op het eerste gezicht reëel zijn, omdat het doorlezen van duizenden berichten per dag in allerlei moeilijke talen op zoek naar dat ene puntje dat een eigen systeem kan raken wellicht niet kosteneffectief is. Maar de vraag is wát je er überhaupt aan hebt. Immers, je hebt een tijdje eerder het nieuws dat er een gat zit in een PHP script op een specifieke Linux distro of je kent eerder de details over een gat in Excel. Bij de eerste moet je je afvragen of je dat script eigenlijk wel hebt, en of het in een kwetsbare opstelling draait, en bij het tweede of de organisatie het gaat vreten dat je een tijdlang – tot er een fix is – het gebruik van Excel uitsluit. En als er géén fix komt, dat je het hele product per direct overboord gooit…. Hetzelfde geldt de gedetailleerde informatie over virussen: wat heb je aan de informatie in realtime, als je antivirus producten het vervolgens niet kunnen onderscheppen? Ga je de internetpijp dichtgooien omdat er mogelijk een virus aankomt? Wanneer mag die dan weer open? Kennis zonder dat je er iets mee kunt veranderen, leidt hooguit tot een gefrustreerde Security Officer. Zonder een zeer goed functionerende beheerorganisatie en/of een dringende behoefte een hoog veiligheidsniveau te realiseren, is Threat Management dan ook meer bezigheidstherapie voor Security-knutselaars dan zakelijk zinvol. Hoewel je de directie goed de stuipen op het lijft kunt jagen met het aantal bedreigingen waar je geen middelen tegen hebt. Maar of en wanneer het nuttig is je eigen onvermogen zo te etaleren behoort tot de arena der politiek. Andere diensten Naast deze vormen van managed service worden incidenteel nog andere zaken onder de noemer geschaard, om een nog breder en indrukwekkender portfolio te bouwen. Forensische Opvolging, Managed Vulnerability Management of Managed Security Audit zijn niet meer dan terugkerende diensten in deze of gene vorm. Kan helemaal zijn wat je zoekt, maar ik zou dit onder koppelverkoop scharen; het woord Managed staat ongeveer gelijk aan een strippenkaart of een abonnement en ik zou het feit dat ik iedere twee weken de Bobo door de brievenbus krijg toch niet als Managed Service durven omschrijven. Het Managen van Managed Security Een vereiste voor iedere managed service is dat je een manier hebt om de resultaten te meten. Tenminste, als het goed is, je gaat toch geen contract afsluiten vanwege een buikgevoel en mooie taartpunten en stoplichten? Nou dan! Security Metriek geldt als een soort holy grail, net zoiets als ROSI (Return On Security Investment) dat is. Uitbesteding geeft nog een extra dimensie aan deze queeste. De uitdaging der metriek is in Managed Security van een hele andere ordegrootte dan bij normale outsourcing, en ga er van uit dat de gemiddelde service manager hier inhoudelijk niet op voorbereid is. Een Security incident is geen storing die ‘opgelost’ is als de stack van een doosje weer antwoord geeft op een ping. Eindgebruikerstevredenheid zegt bij Security niet of de gestelde doelen bereikt zijn, misschien eerder het tegendeel. De klassieke KPI’s gelden hier niet. Het gaat meestal mis in de discussies als het subtiele verschil tussen de beveiliging en de resulterende veiligheid niet voldoende onderkend wordt. Het meest realistische is het meten van de inspanning van de leverancier in plaats ‘resultaten’. Als je de leverancier op de resulterende veiligheid wilt afrekenen, moet je immers de detaillering van het beveiligingsbeleid en de dagelijkse interpretatie overlaten aan de leverancier. En dat wil je wellicht niet, niet in het minst omdat je dan maar één leverancier kunt hebben. Je kunt de bewaker van de voordeur niet afrekenen op het resultaat, behalve als je geen achterdeuren hebt én dat aan kunt tonen. Je loopt bovendien al gauw vast in oeverloze discussies over hoe dat virus op het netwerk is gekomen of waarom je niet gezien hebt dat de echtgenoot van een ex-medewerkster informatie uit een systeem steelt. Forensisch onderzoek kan dan – in sommige gevallen – uitsluitsel geven, maar de zakelijke relatie staat op dat moment al zó onder druk, en digitale bewijsvoering is zó ondoorgrondelijk en inhoudelijk betwistbaar, dat je die kant écht niet op moet willen. Het laatste aandachtspunt dat ik mee wil geven, is het verschil is tussen het meten van de beveiligingsinspanning en het meten van goede bedoelingen. Dat een Managed Security provider ISO27001/CMM-SSE of whatever gecertificeerd is, zegt niet noodzakelijker wijze iets concreets over hoe goed deze de informatie van een klant beveiligd. De gangbare methodes zijn te abstract voor een dergelijk gebruik. Ze stellen statische doelen, zonder beschrijving van de middelen, en zijn niet gedimensioneerd op uitbestedingsrelaties waarbij een leverancier meerdere partijen met verschillende beveiligingsbehoeftes bediend. Deze noodzakelijke nuanceringen maken het er niet verkoopbaarder op, behalve als de afnemer bereid en in staat is diep op de materie in te gaan. Of blind te tekenen. 'Managed Security' is al met al een gemengd pakket van onrijpe en rijpe diensten. Voor de meeste organisaties zal de bezuiniging van uitbesteden inhouden dat ze minder uitgeven aan iets wat ze net zo goed kunnen laten, behalve als ze het doen met het expliciet doel ervaring op te doen. Als ze deze eerste horde genomen hebben en een echte smart buyer zijn geworden, is het verantwoord bepaalde diensten in te kopen. Ik acht de kans groot dat ze dan weer té goed weten wat de beperkingen van de meeste proposities zijn, en hoeveel ze nog steeds zelf moeten doen, zodat ze het liever helemaal zelf blijven doen. Peter Rietveld, Senior Security consultant bij Traxion - The Identity Management Specialists -
11-12-2007,10:55 doorRedactieReacties: 1
In het kader van de themaweek Managed Security vorig jaar betoogde ik dat het uitbesteden van beveiliging een hoge mate van maturiteit in de organisatie vraagt: je moet immers weten wat je aan beveiliging moet doen, voordat je dat door een ander kan laten doen. Om een smart buyer te zijn moet je méér materiedeskundigheid hebben dan als je het zelf doet, want bij zelf doen geval kun je nog 'Iteratief' kennis opbouwen. En bijgevolg zul je er meer van moeten weten dan je leverancier. Maar goed, dit jaar wil ik iets minder filosofisch naar deze materie kijken. Het concept Managed Security Service Provider (MSSP) lijkt bedacht te zijn door Counterpane – nou ja, dat zeggen ze zelf. Gartner heeft dit MSSP concept eind vorige eeuw omarmd en massaal aanbevolen. Volgens het magic quandrant Noord Amerika van 1/8/07 staat Verisign bovenin (zowel in visie als in het vermogen tot uitvoering), op de voet gevolgd door IBM, AT&T en Symantec en meer op afstand gevolgd door BT en onze eigen KPN (nou ja, Getronics dan). In de Europese Magic Quadrant van April 2007 staan eigenlijk alleen Cybertrust en Integralis als partijen die een geschiedenis hebben in Security, de rest zijn dezelfde doorsnee mix van systeem integrators en telco’s die alles aanbieden wat een beetje potentie lijkt te hebben. Wat overigens niets hoeft te zeggen over de kwaliteit. In dit licht moet je ook de overname van GPR door de KPN zien: BT heeft Counterpane, Deutsche Telecom heeft debis en dan kun je niet achterblijven. Deze 'me too' scenario’s spelen een grote rol, waardoor grote bedragen worden gespendeerd om het portfolio op hoofdlijnen vergelijkbaar met dat van de concurrentie te maken. De vraag of het allemaal even zinvol is voor de klant, krijgt minder aandacht zo te zien. De uitkomst van Gartner is niet verwonderlijk, als je je realiseert dat het zwaarst wegende aspect in deze weging de omvang van de firma en de financiële positie is. Met dit soort vergelijkingen zul je als je een auto koopt thuiskomen met een Opel of een Fiat. Prima auto’s hoor, maar als je naast iemand parkeert in een Donkervoort of een Spyker, steekt het wat schraal af. Als je een auto moet hebben om indruk te maken op de buren, is een Kadett of een Panda duidelijk een mismatch. En helemaal als je nog geen rijbewijs hebt – het gaat op den duur toch opvallen dat je er nooit in rijdt. Wat is er te koop? Managed Security is een containerbegrip, waarin allerlei beveiligingszaken in een doosje met een strik erom aangeboden worden. Om te voorkomen dat je appels en peren vergelijkt, is een korte rondgang noodzakelijk. Bij het vergelijken van abstracte, samengestelde proposities als Managed Security moet je nu eenmaal onder de motorkap kijken om te zien wat het aanbod nu precies inhoudt. Het resultaat van een rondgang langs de aanbieders lijkt dat het beheer van security devices geouttasked wordt. Security Devices variëren een beetje, waarbij sommige leveranciers zich beperken tot de klassieke firewalls, maar het merendeel woont inmiddels wat hoger de OSI stack in door ook allerlei IDS/IPS-achtigen en crypto spul te beheren. De meeste aanbieders concentreren zich bij het beheer van devices op de netwerk perimeter, sommigen durven de sprong het interne netwerk in, aan. Een specifieke categorie zijn de aanbieders van Managed PKI services, maar in de praktijk lijkt deze markt zeer beperkt. Nu ja, de meeste bestuurders krijgen nog steeds puistjes als je PKI roept…. Als toefje op de taart wordt over het algemeen ‘threat management’ in allerlei varianten aangeboden, waarbij je eerder dan de rest van de wereld weet dat er een gat zit in een stuk software, zonder dat je daarvoor zelf allerlei bronnen in vele talen moet gaan doorwaden om deze informatie te vinden. Om eens te gaan kijken wat je aan Managed Security zou hebben of wat je zou willen aanbieden, moeten we nader ingaan op de verschillende onderdelen van de dienstverlening. Managed Security Devices Deze categorie omvat het bulk van alle aanbieders. Met het uitbesteden van het beheer van een stel appliances is op zich niets mis, omdat die dingen ook beheerd moeten worden. Bij de producten die zich op de applicatielaag begeven is er een behoorlijke patchcyclus en als het volgende gat in een rar of chm parser gepubliceerd wordt, zal een externe leverancier wellicht sneller patchen dan je dat zelf zou doen. Doen dus. Als je vervolgens leest dat 'Managed Firewall Services' een 'totaaloplossing voor de implementatie en beheer van een effectief Security beleid binnen een organisatie' bieden “door inzet van ervaren, gecertificeerde security engineers en consultants”, ga je toch weer twijfelen. Firewalls die uitstekend helpen binnen een netwerk? Is dit een leverancier die voldoende kennis heeft? Het in de lucht en gepatched houden van een firewall, een VPN concentrator, een IDS of een log correlatiedoosje is het simpelste stuk, je moet echter nog steeds iets dóen met dergelijke apparaten. Zeker met de meer geavanceerde. Zoals ik laatst als predikte op dit platform moet je als bewaker weten wat je bewaakt omdat je anders niet weet wat je ziet. Dit houdt in dat je als MSSP-klant je leverancier in detail op de hoogte moet brengen van wát en wie er bewaakt wordt en of er intern (of extern) operationeel iets speelt waardoor normaliter valide verkeer dat op eens niet hoeft te zijn. Dat kan zoiets banaals zijn als een medewerker die uit dienst is gegaan. Het “detecteren van afwijkingen in het netwerk van de klanten en het onmiddellijk op de hoogte brengen van de klant” is dan ook grotendeels wensdenken: alle beperkingen en nuances van bewakingssystemen gelden, ongeacht of deze nu in-house dan wel geoutsourced bediend worden. Managed Security Devices zal helaas zelden meer voorstellen dan het in de lucht houden van onderbenutte geavanceerde doosjes. De bijdrage aan de veiligheid is dan ook gering, de rationale is puur kosteneffectiviteit. Hoewel effectief, je geeft minder uit aan iets wat je net zo goed kan laten, omdat je er nog niet aan toe bent. Haal eerst maar je rijbewijs voordat je die Panda koopt. Managed Secure Internet Hosting Feitelijk is dit gewoon hosting met een modieus verkooppraatje, vrijwel iedere echte hosting provider regelt de beveiliging goed. Ze moeten wel. Dit is de meest volwassen vorm van Managed Security. Managed Secure Internet Access Deze vorm kan wel interessant zijn om te outsourcen: voor je inbound proxy staat een filtering proxy die virussen en spyware vangt en de meest omineuze sites op een blacklist zet. Deze extra laag kan veel ellende voorkomen. Hierbij geldt dat dit alleen het algemene basisniveau kan leveren. Een nadeel om in de gaten te houden dat een filter op de proxylaag de feitelijke bandbreedte aanzienlijk beperkt. Dit is ondanks de uitvoerbaarheid en het evidente nut verassend genoeg een weinig gangbaar product bij de grote MSSP. Het concept wint wél terrein bij de reguliere ISP’s, waar het waarschijnlijk beter past. Managed Secure E-Mail Deze categorie wordt door een paar gespecialiseerde aanbieders geleverd, en maakt vaker deel uit van een pakket van weer een andere aanbieder. Het beveiligen van mail laat zich goed outtasken, zo lang de afnemer niet verwacht dat het fire and forget is en een tamelijk algemeen beveiligingsniveau vraagt, net als bij de Secure Internet Access. Een aandachtspunt is mail integratie met andere functies zoals webmail: mailscanners werken op SMTP niveau waardoor de eigen mailinfra niet meer extern zichtbaar mag zijn. Het kan daardoor conflicteren met webmail en de wens op userniveau verschillende regels neer te zetten. Het wordt anders als je bijvoorbeeld meer dan de standaard beveiligingsfuncties vraagt; wil je dat alles wat positief herkend wordt als virus of spam verwijderd wordt zijn er tal van prima aanbieders die dit wellicht goedkoper kunnen dan je het zelf zou doen met dezelfde standaardproducten. Wil je dat informatielekken door eigen medewerkers of alle 0-day’s worden tegengehouden, dan zul je merken dat iets anders dan een kadett niet in het assortiment zit. Managed Threat Management Wat je uitbesteedt met deze dienst is het afspeuren van de boze buitenwereld op nieuwe bedreigingen. Je MSSP koopt het op haar beurt weer in bij een hierin gespecialiseerde speler. Threat Management is prima etalagemateriaal, want je laat zien dat je proactief goed op de hoogte bent wat je bedreigd. En de besparing kan op het eerste gezicht reëel zijn, omdat het doorlezen van duizenden berichten per dag in allerlei moeilijke talen op zoek naar dat ene puntje dat een eigen systeem kan raken wellicht niet kosteneffectief is. Maar de vraag is wát je er überhaupt aan hebt. Immers, je hebt een tijdje eerder het nieuws dat er een gat zit in een PHP script op een specifieke Linux distro of je kent eerder de details over een gat in Excel. Bij de eerste moet je je afvragen of je dat script eigenlijk wel hebt, en of het in een kwetsbare opstelling draait, en bij het tweede of de organisatie het gaat vreten dat je een tijdlang – tot er een fix is – het gebruik van Excel uitsluit. En als er géén fix komt, dat je het hele product per direct overboord gooit…. Hetzelfde geldt de gedetailleerde informatie over virussen: wat heb je aan de informatie in realtime, als je antivirus producten het vervolgens niet kunnen onderscheppen? Ga je de internetpijp dichtgooien omdat er mogelijk een virus aankomt? Wanneer mag die dan weer open? Kennis zonder dat je er iets mee kunt veranderen, leidt hooguit tot een gefrustreerde Security Officer. Zonder een zeer goed functionerende beheerorganisatie en/of een dringende behoefte een hoog veiligheidsniveau te realiseren, is Threat Management dan ook meer bezigheidstherapie voor Security-knutselaars dan zakelijk zinvol. Hoewel je de directie goed de stuipen op het lijft kunt jagen met het aantal bedreigingen waar je geen middelen tegen hebt. Maar of en wanneer het nuttig is je eigen onvermogen zo te etaleren behoort tot de arena der politiek. Andere diensten Naast deze vormen van managed service worden incidenteel nog andere zaken onder de noemer geschaard, om een nog breder en indrukwekkender portfolio te bouwen. Forensische Opvolging, Managed Vulnerability Management of Managed Security Audit zijn niet meer dan terugkerende diensten in deze of gene vorm. Kan helemaal zijn wat je zoekt, maar ik zou dit onder koppelverkoop scharen; het woord Managed staat ongeveer gelijk aan een strippenkaart of een abonnement en ik zou het feit dat ik iedere twee weken de Bobo door de brievenbus krijg toch niet als Managed Service durven omschrijven. Het Managen van Managed Security Een vereiste voor iedere managed service is dat je een manier hebt om de resultaten te meten. Tenminste, als het goed is, je gaat toch geen contract afsluiten vanwege een buikgevoel en mooie taartpunten en stoplichten? Nou dan! Security Metriek geldt als een soort holy grail, net zoiets als ROSI (Return On Security Investment) dat is. Uitbesteding geeft nog een extra dimensie aan deze queeste. De uitdaging der metriek is in Managed Security van een hele andere ordegrootte dan bij normale outsourcing, en ga er van uit dat de gemiddelde service manager hier inhoudelijk niet op voorbereid is. Een Security incident is geen storing die ‘opgelost’ is als de stack van een doosje weer antwoord geeft op een ping. Eindgebruikerstevredenheid zegt bij Security niet of de gestelde doelen bereikt zijn, misschien eerder het tegendeel. De klassieke KPI’s gelden hier niet. Het gaat meestal mis in de discussies als het subtiele verschil tussen de beveiliging en de resulterende veiligheid niet voldoende onderkend wordt. Het meest realistische is het meten van de inspanning van de leverancier in plaats ‘resultaten’. Als je de leverancier op de resulterende veiligheid wilt afrekenen, moet je immers de detaillering van het beveiligingsbeleid en de dagelijkse interpretatie overlaten aan de leverancier. En dat wil je wellicht niet, niet in het minst omdat je dan maar één leverancier kunt hebben. Je kunt de bewaker van de voordeur niet afrekenen op het resultaat, behalve als je geen achterdeuren hebt én dat aan kunt tonen. Je loopt bovendien al gauw vast in oeverloze discussies over hoe dat virus op het netwerk is gekomen of waarom je niet gezien hebt dat de echtgenoot van een ex-medewerkster informatie uit een systeem steelt. Forensisch onderzoek kan dan – in sommige gevallen – uitsluitsel geven, maar de zakelijke relatie staat op dat moment al zó onder druk, en digitale bewijsvoering is zó ondoorgrondelijk en inhoudelijk betwistbaar, dat je die kant écht niet op moet willen. Het laatste aandachtspunt dat ik mee wil geven, is het verschil is tussen het meten van de beveiligingsinspanning en het meten van goede bedoelingen. Dat een Managed Security provider ISO27001/CMM-SSE of whatever gecertificeerd is, zegt niet noodzakelijker wijze iets concreets over hoe goed deze de informatie van een klant beveiligd. De gangbare methodes zijn te abstract voor een dergelijk gebruik. Ze stellen statische doelen, zonder beschrijving van de middelen, en zijn niet gedimensioneerd op uitbestedingsrelaties waarbij een leverancier meerdere partijen met verschillende beveiligingsbehoeftes bediend. Deze noodzakelijke nuanceringen maken het er niet verkoopbaarder op, behalve als de afnemer bereid en in staat is diep op de materie in te gaan. Of blind te tekenen. 'Managed Security' is al met al een gemengd pakket van onrijpe en rijpe diensten. Voor de meeste organisaties zal de bezuiniging van uitbesteden inhouden dat ze minder uitgeven aan iets wat ze net zo goed kunnen laten, behalve als ze het doen met het expliciet doel ervaring op te doen. Als ze deze eerste horde genomen hebben en een echte smart buyer zijn geworden, is het verantwoord bepaalde diensten in te kopen. Ik acht de kans groot dat ze dan weer té goed weten wat de beperkingen van de meeste proposities zijn, en hoeveel ze nog steeds zelf moeten doen, zodat ze het liever helemaal zelf blijven doen. Peter Rietveld, Senior Security consultant bij Traxion - The Identity Management Specialists -
Bank verliest tapes met gegevens 12,5 miljoen klanten
Vrijdag, 30 augustus 2008
De Bank van New York Mellon heeft niet de gegevens van 4,5, maar van 12,5 miljoen klanten verloren. Het gaat om rekeninggegevens, zoals namen, adresgegevens, geboortedata en Social security nummers, die op zes onversleutelde backup tapes stonden die een koerier verloor. Vanwege het grote aantal gegevens, is het waarschijnlijk het grootste beveiligingsincident van dit jaar. "Het is schandalig dat deze berg van gegevens niet beter beschermd is, en het is net zo schandalig dat zes maanden nadat het heeft plaatsgevonden er nog eens zes miljoen extra individuen en bedrijven getroffen zijn," aldus de gouverneur van Connecticut Jodi Rell. Ze overweegt nu om de betrokken bedrijven te beboeten en hun klanten financieel te laten compenseren. Volgens de bank zijn er geen aanwijzingen dat de informatie misbruikt is.
Tags: backup tapesbankdataverlies
De Bank van New York Mellon heeft niet de gegevens van 4,5, maar van 12,5 miljoen klanten verloren. Het gaat om rekeninggegevens, zoals namen, adresgegevens, geboortedata en Social security nummers, die op zes onversleutelde backup tapes stonden die een koerier verloor. Vanwege het grote aantal gegevens, is het waarschijnlijk het grootste beveiligingsincident van dit jaar. "Het is schandalig dat deze berg van gegevens niet beter beschermd is, en het is net zo schandalig dat zes maanden nadat het heeft plaatsgevonden er nog eens zes miljoen extra individuen en bedrijven getroffen zijn," aldus de gouverneur van Connecticut Jodi Rell. Ze overweegt nu om de betrokken bedrijven te beboeten en hun klanten financieel te laten compenseren. Volgens de bank zijn er geen aanwijzingen dat de informatie misbruikt is.
Tags: backup tapesbankdataverlies
Role Based Access Control ???
Role Based Access Control
Uit Wikipedia, de vrije encyclopedie
Ga naar: navigatie, zoeken
Role Based Access Control (RBAC) is een methode waarmee op een effectieve en efficiënte wijze de toegang tot informatiesystemen kan worden ingericht.
Inhoud[verbergen]
1 Methode
1.1 Voorbeeld RBAC
2 Standaarden
3 Alternatieve toegangscontrole methodieken
4 Bekende RBAC hulpmiddelen
5 Zie ook
6 Externe links
//
[bewerk] Methode
Kenmerk van RBAC is dat individuen niet rechtstreeks worden geautoriseerd in informatiesystemen, maar dat ze uitsluitend rechten krijgen op basis van een vorm van groepslidmaatschap, op basis van de rol die ze hebben binnen een organisatie of bedrijfsproces. Ook de permissies op objecten/functies in informatiesystemen kunnen worden gegroepeerd in rollen.
Door het koppelen van de rol van de gebruiker in de organisatie aan een rol in een informatiesysteem, is het eenvoudig om de effectieve rechten van een gebruiker te bepalen. Het daadwerkelijk toekennen van rechten en permissies aan een gebruiker en het verstrekken van gerelateerde objecten (tokens en dergelijke) heet provisioning.
In het kader van RBAC trajecten wordt binnen organisaties een overzicht van de gebruikte rollen opgesteld middels de techniek van role-mining.
[bewerk] Voorbeeld RBAC
Bob vervult de rol van baliemedewerker bij een bank.
Het CRM-systeem kent de rol klantcontactbeheer.
De organisatierol baliemedewerker wordt gekoppeld aan de informatiesysteemrol klantcontactbeheer. Daarmee verkrijgt Bob automatisch de rechten die nodig zijn om de CRM functie van klantcontact te kunnen uitvoeren.
Op zich levert deze inrichting geen besparing op. Maar als nu ook Alice wordt benoemd als baliemedewerker, dan verkrijgt ook zij automatisch de rechten die nodig zijn om de CRM functie van klantcontact te kunnen uitvoeren. En als Bob van rol wisselt doordat hij niet langer baliemedewerker is maar de functie van hypotheekadviseur krijgt, dan raakt hij ook automatisch de klantcontactbeheer functies kwijt.
[bewerk] Standaarden
Het Amerikaanse NIST heeft een standaard voor RBAC gedefinieerd. De meeste producten die op de markt zijn verschenen zijn in staat om de standaard te volgen.
[bewerk] Alternatieve toegangscontrole methodieken
RBAC is niet een model om de autorisaties op een dynamische wijze toe te kennen. Om dat te realiseren kan de methode van Rule Based Access Control of Lattice Based Access Control worden toegepast. Deze beide vormen van toegangscontrole zijn ook onder de noemer Mandatory Access Control te vatten.
Ook Discretionary access control is een vorm van toegangscontrole, waarbij de eigenaar van een object zelf bepaalt wie welke toegangsrechten mag uitoefenen.
[bewerk] Bekende RBAC hulpmiddelen
BetaSystems SAM Jupiter
BHOLD Company
BMC Control SA en IdM
CA eTrust
HP Select Access
IBM TIM en TAM (Tivoli Identity Manager en Tivoli Access Manager)
Microsoft Authorization Manager (Azman)
Novell Access Manager
Sun Identity Management Suite
[bewerk] Zie ook
Bell-La Padula vertrouwelijkheidsmodel
Biba integriteitsmodel
Take-Grant Model
The Clark-Wilson integriteitsmodel
Graham-Denning Model
Security Enhanced Linux
[bewerk] Externe links
Role Based Access Controls at NIST - De RBAC standaard van het NIST
Handreiking Identity Management van het Genootschap van Informatiebeveiligers (GvIB)
Categorieën: Informatiebeveiliging Identity and Access Management
Zet RBAC bij het grof vuil
Woensdag,16:55 doorRedactieReacties: 14
In de slag om compliance aan SOX en vergelijkbare 'hoge normen' stellen beveiligingsspecialisten RBAC voor als conditio sine qua non. Deze trend wint nog steeds terrein. Er zijn ook al consultants die RBAC-compliancy eisen van software zoals Active Directory of IDM, in het kader van SOX. RBAC-achtige features in allerlei software wordt ook verpakt in compliancy termen - sommige leveren 'GRC'-modules en sinds enige tijd is er zelfs 'Compliancy As A Service (CaaS). Dit is niet heel vreemd: RBAC is eind jaren tachtig bedacht om dit soort problemen op te lossen. Maar noch SOX noch PCI-DSS schrijven het voor; er wordt alleen een "adequate internal control" geëist, en vendors en consultants roepen in koor dat RBAC in allerlei subsmaken de enige manier is. Was dat maar waar. RBAC is een slecht plan en brengt je juist verder van adequate interne controls omdat het niet werkt. Rollenexplosie Het uitgangspunt bij RBAC is dat medewerkers die hetzelfde werk doen, dezelfde rechten en applicaties nodig hebben. RBAC wekt daarmee de schijn van efficiency en 'consolidatie', van rechtvaardigheid. Deze schoonheid trekt mensen met een ordelijke geest aan, waarvan er velen in de ICT werken. Maar wat is hetzelfde werk? Het idee dat verschillende mensen dezelfde rol hebben en dus gelijk zijn, is een misvatting. Een secretaresse heeft meestal rechten op de mailbox van de baas. Een programmeur heeft toegang tot de source code repository. Maar welke baas? Welke repository? Sommige bazen hebben meerdere secretaresses of delen secretaresses. En programmeurs hebben de hebbelijkheid niet altijd aan alle projecten te werken. Medewerkers hebben altijd meer dan één rol. Sommige medewerkers hebben sóms maar één rol. Zelfs in de spreekwoordelijke koekjesfabriek hebben mensen meerdere petten - denk aan lijn en projectrollen, interimtaken en allerlei vormen van samenwerking en taakwaarneming. Bovendien zijn er ook autorisaties nodig voor eenmalige taken, zoals toegang tot een dataset voor het maken van jaarrekeningen of root toegang tot een systeem om een storing op te lossen. Ieder RBAC project stuit dan ook op het feit dat er meer rollen dan gebruikers zijn. En dan gaan ze groepen samenstellen op grond waarvan mensen rechten krijgen. Iedereen krijgt alle rechten die een ander lid van het groepje nodig heeft. Je krijgt dus altijd meer rechten dan je nodig hebt. Dat draagt niet bij tot meer veiligheid, integendeel, want als iemand expliciet rechten krijgt dan is misbruik wel heel moeilijk aan te tonen. Op dit vraagstuk struikelen de meeste implementaties. Maar er is meer mis. Autorisaties waarop? In normale omgevingen zal RBAC alleen de toegang tot applicaties, devices en directories kunnen regelen. Dit zijn hooguit indirecte waarborgen van de veiligheid van de informatie; er is immers geen mechanisme dat afdwingt waar de informatie staat. Door deze beperkingen is RBAC een puur IT-feestje, waarbij je niet op medewerking van 'de business' of 'Corporate Security' hoeft te rekenen. Een goed werkende RBAC zou ervoor kunnen zorgen dat gebruikers sneller en met minder fouten toegang tot IT resources krijgen, maar dat heeft niets met compliancy (het voorkomen van misbruik immers) te maken. Niet alles is rolgebonden Het klassieke rollendenken kent twee variabelen, rollen (functies) en autorisaties. RBAC koppelt autorisaties alleen aan functies van personen. Beveiligingseisen zijn echter niet alleen afhankelijk van medewerkers. Sommige taken mogen niet op bepaalde systemen worden uitgevoerd, omdat ze op minder veilige plaatsen staan. Denk daarbij aan balie PC's en thuiswerkplekken, maar ook aan meer en minder beveiligde zones en panden. Op jacht naar de bron RBAC vraagt aan een bronsysteem actuele attributen op grond waarvan rechten uitgedeeld kunnen worden. Het bronsysteem voor rollen is meestal de HR administratie. Daarin staat wel op welke afdeling iemand zit (of zat) en wat de functienaam van iemand is (of was). Maar je hebt veel meer input nodig als je niet met heel grove schetsen autorisaties wilt uitdelen, veel meer informatie dan HR heeft. Die moet je gaan bijhouden. Als je geen bron hebt, dan moet je alles handmatig gaan doen. Nu zijn er soms wel andere registers die de benodigde informatie bevatten. Maar om het urenschrijfsysteem, de prikklok en het helpdesksysteem te koppelen als bron voor deze onmisbare informatie, gaat nogal ver. Het zal slechts incidenteel kunnen, omdat vrijwel al deze registraties achteraf vastleggen, terwijl RBAC de informatie vooraf nodig heeft. Datakwaliteit RBAC en ieder ander geautomatiseerd autorisatiebeheer is 100% afhankelijk van triggers in bronsystemen. De datakwaliteit is kritiek, en hoe meer brongegevens je moet gebruiken, hoe meer data die nu nog informationeel is, kritiek wordt. Voor HR is het kamernummer een leuk extraatje, maar als je er provisioning aan koppelt moet het kloppen. En blijven kloppen. Het gebruik van meerdere bronnen leidt tot interessante synchronisatievragen en arbitraire keuzes over welke gegevens wanneer leidend zijn. Als één systeem 90% goede data heeft, dan gaat 10% van de autorisaties fout. Met vijf bronsystemen met ieder 90% kwaliteit mag je blij als er wel eens een transactie lukt. Bedenk je dat als data op twee plekken staat in plaats van op een plek, iedere waarde in het eigen systeem kan kloppen maar dat ze ten opzichte van elkaar kunnen verschillen waarmee de datakwaliteit daalt. Hoge kwaliteit van data is fijn, maar zeker niet gratis. Onderhoud Naast bronnen voor triggers heb je voor alle geautomatiseerde provisioning business logica nodig: iedereen die op kamernummer A213 zit krijgt default printer B11787_VNS. Zit iemand in project HUPSA dan moet hij bij de projectenshare, op de testkamer V4_120 kunnen komen, rechten op bepaalde VPN's krijgen en een nieuwere versie van bepaalde software op de PC hebben. Echter, niet iedereen in het project heeft precies hetzelfde nodig. Stopt die persoon bij project HUPSA, dan moet hij nog twee maanden bij de data kunnen voor de nazorg maar niet meer bij de rest, terwijl andere mensen die stoppen met het project geen nazorgtaken hebben en dus ook niet onder de twee maanden regel vallen. Bij een gemiddeld project zijn deze zaken bovendien niet van te voren bekend, dus ze moeten snel. Als je dit soort vragen projecteert op een organisatie met enige schaalgrootte, een paar projecten en een reorganisatietje hier en daar, dan weet je dat je dagelijks tientallen mutaties in de logica zult hebben. En dit zijn mutaties die in de regel in de applicatiecode zitten. Als dat zo is, heb je na iedere logicawijziging een nieuwe release van de Code. De Change Manager ziet je al aankomen; en met maar één change window per week kom je er in ieder geval niet. RBAC 2.0? Jean Pierre Vincent beschrijft in het blad Informatiebeveiliging een concept voor "RBAC 2.0" met een structuurwijziging (een extra abstractielaag), om niet persoonsgebonden rules te kunnen bevatten. Een prima idee, waarvoor de 'toolleveranciers' wel even hun systemen moeten aanpassen. Dat zal misschien gebeuren, maar het existentiële probleem van de beschikbaarheid van brongegevens en de realiteit van de almaar wijzigende logica wordt er niet door opgelost. Zij maken RBAC tot een monstrum van complexiteit. De implementatie- en de beheeruitdaging zal navenant zijn, evenals de foutkans, dus het beweren dat de kosten zullen dalen en de veiligheid zal toenemen is erg optimistisch, ongeacht de wijzigingen in RBAC 2.0 of later. De belangrijkste argumenten om RBAC in te voeren zijn vermindering van de kosten en het verhogen van de veiligheid. Veiliger en goedkoper, omdat het eenvoudiger zou worden. Welnu, in de zestienjarige geschiedenis van RBAC is aangetoond dat het niet in te voeren is. Mislukte projecten zijn per definitie duur. En het mislukken is echt niet omdat het niet serieus geprobeerd is, knappere koppen dan alle Security.nl lezers bij elkaar hebben de tanden erop stukgebeten. Stukjes van RBAC zie je soms wel, maar het grote geheel is nergens gelukt. Het is net zoiets als PKI en X.500 - er zitten bruikbare zaken in, maar het grote concept is te complex en te ambitieus. Onbruikbaar dus. Het is dan ook hoog tijd dat we met z'n allen afspreken nooit meer te zeggen dat RBAC een bruikbare oplossing is. Voor je het weet staat het daadwerkelijk in een bindende richtlijn. Dan moeten we het bouwen en dat heeft uiteindelijk maar één mogelijke uitkomst: een compleet fiasco. Daarmee verliezen we veel van de opgebouwde geloofwaardigheid die we als ICT Security zo moeizaam opgebouwd hebben. Door Peter Rietveld, Senior Security consultant bij Traxion - The Identity Management Specialists -
Uit Wikipedia, de vrije encyclopedie
Ga naar: navigatie, zoeken
Role Based Access Control (RBAC) is een methode waarmee op een effectieve en efficiënte wijze de toegang tot informatiesystemen kan worden ingericht.
Inhoud[verbergen]
1 Methode
1.1 Voorbeeld RBAC
2 Standaarden
3 Alternatieve toegangscontrole methodieken
4 Bekende RBAC hulpmiddelen
5 Zie ook
6 Externe links
//
[bewerk] Methode
Kenmerk van RBAC is dat individuen niet rechtstreeks worden geautoriseerd in informatiesystemen, maar dat ze uitsluitend rechten krijgen op basis van een vorm van groepslidmaatschap, op basis van de rol die ze hebben binnen een organisatie of bedrijfsproces. Ook de permissies op objecten/functies in informatiesystemen kunnen worden gegroepeerd in rollen.
Door het koppelen van de rol van de gebruiker in de organisatie aan een rol in een informatiesysteem, is het eenvoudig om de effectieve rechten van een gebruiker te bepalen. Het daadwerkelijk toekennen van rechten en permissies aan een gebruiker en het verstrekken van gerelateerde objecten (tokens en dergelijke) heet provisioning.
In het kader van RBAC trajecten wordt binnen organisaties een overzicht van de gebruikte rollen opgesteld middels de techniek van role-mining.
[bewerk] Voorbeeld RBAC
Bob vervult de rol van baliemedewerker bij een bank.
Het CRM-systeem kent de rol klantcontactbeheer.
De organisatierol baliemedewerker wordt gekoppeld aan de informatiesysteemrol klantcontactbeheer. Daarmee verkrijgt Bob automatisch de rechten die nodig zijn om de CRM functie van klantcontact te kunnen uitvoeren.
Op zich levert deze inrichting geen besparing op. Maar als nu ook Alice wordt benoemd als baliemedewerker, dan verkrijgt ook zij automatisch de rechten die nodig zijn om de CRM functie van klantcontact te kunnen uitvoeren. En als Bob van rol wisselt doordat hij niet langer baliemedewerker is maar de functie van hypotheekadviseur krijgt, dan raakt hij ook automatisch de klantcontactbeheer functies kwijt.
[bewerk] Standaarden
Het Amerikaanse NIST heeft een standaard voor RBAC gedefinieerd. De meeste producten die op de markt zijn verschenen zijn in staat om de standaard te volgen.
[bewerk] Alternatieve toegangscontrole methodieken
RBAC is niet een model om de autorisaties op een dynamische wijze toe te kennen. Om dat te realiseren kan de methode van Rule Based Access Control of Lattice Based Access Control worden toegepast. Deze beide vormen van toegangscontrole zijn ook onder de noemer Mandatory Access Control te vatten.
Ook Discretionary access control is een vorm van toegangscontrole, waarbij de eigenaar van een object zelf bepaalt wie welke toegangsrechten mag uitoefenen.
[bewerk] Bekende RBAC hulpmiddelen
BetaSystems SAM Jupiter
BHOLD Company
BMC Control SA en IdM
CA eTrust
HP Select Access
IBM TIM en TAM (Tivoli Identity Manager en Tivoli Access Manager)
Microsoft Authorization Manager (Azman)
Novell Access Manager
Sun Identity Management Suite
[bewerk] Zie ook
Bell-La Padula vertrouwelijkheidsmodel
Biba integriteitsmodel
Take-Grant Model
The Clark-Wilson integriteitsmodel
Graham-Denning Model
Security Enhanced Linux
[bewerk] Externe links
Role Based Access Controls at NIST - De RBAC standaard van het NIST
Handreiking Identity Management van het Genootschap van Informatiebeveiligers (GvIB)
Categorieën: Informatiebeveiliging Identity and Access Management
Zet RBAC bij het grof vuil
Woensdag,16:55 doorRedactieReacties: 14
In de slag om compliance aan SOX en vergelijkbare 'hoge normen' stellen beveiligingsspecialisten RBAC voor als conditio sine qua non. Deze trend wint nog steeds terrein. Er zijn ook al consultants die RBAC-compliancy eisen van software zoals Active Directory of IDM, in het kader van SOX. RBAC-achtige features in allerlei software wordt ook verpakt in compliancy termen - sommige leveren 'GRC'-modules en sinds enige tijd is er zelfs 'Compliancy As A Service (CaaS). Dit is niet heel vreemd: RBAC is eind jaren tachtig bedacht om dit soort problemen op te lossen. Maar noch SOX noch PCI-DSS schrijven het voor; er wordt alleen een "adequate internal control" geëist, en vendors en consultants roepen in koor dat RBAC in allerlei subsmaken de enige manier is. Was dat maar waar. RBAC is een slecht plan en brengt je juist verder van adequate interne controls omdat het niet werkt. Rollenexplosie Het uitgangspunt bij RBAC is dat medewerkers die hetzelfde werk doen, dezelfde rechten en applicaties nodig hebben. RBAC wekt daarmee de schijn van efficiency en 'consolidatie', van rechtvaardigheid. Deze schoonheid trekt mensen met een ordelijke geest aan, waarvan er velen in de ICT werken. Maar wat is hetzelfde werk? Het idee dat verschillende mensen dezelfde rol hebben en dus gelijk zijn, is een misvatting. Een secretaresse heeft meestal rechten op de mailbox van de baas. Een programmeur heeft toegang tot de source code repository. Maar welke baas? Welke repository? Sommige bazen hebben meerdere secretaresses of delen secretaresses. En programmeurs hebben de hebbelijkheid niet altijd aan alle projecten te werken. Medewerkers hebben altijd meer dan één rol. Sommige medewerkers hebben sóms maar één rol. Zelfs in de spreekwoordelijke koekjesfabriek hebben mensen meerdere petten - denk aan lijn en projectrollen, interimtaken en allerlei vormen van samenwerking en taakwaarneming. Bovendien zijn er ook autorisaties nodig voor eenmalige taken, zoals toegang tot een dataset voor het maken van jaarrekeningen of root toegang tot een systeem om een storing op te lossen. Ieder RBAC project stuit dan ook op het feit dat er meer rollen dan gebruikers zijn. En dan gaan ze groepen samenstellen op grond waarvan mensen rechten krijgen. Iedereen krijgt alle rechten die een ander lid van het groepje nodig heeft. Je krijgt dus altijd meer rechten dan je nodig hebt. Dat draagt niet bij tot meer veiligheid, integendeel, want als iemand expliciet rechten krijgt dan is misbruik wel heel moeilijk aan te tonen. Op dit vraagstuk struikelen de meeste implementaties. Maar er is meer mis. Autorisaties waarop? In normale omgevingen zal RBAC alleen de toegang tot applicaties, devices en directories kunnen regelen. Dit zijn hooguit indirecte waarborgen van de veiligheid van de informatie; er is immers geen mechanisme dat afdwingt waar de informatie staat. Door deze beperkingen is RBAC een puur IT-feestje, waarbij je niet op medewerking van 'de business' of 'Corporate Security' hoeft te rekenen. Een goed werkende RBAC zou ervoor kunnen zorgen dat gebruikers sneller en met minder fouten toegang tot IT resources krijgen, maar dat heeft niets met compliancy (het voorkomen van misbruik immers) te maken. Niet alles is rolgebonden Het klassieke rollendenken kent twee variabelen, rollen (functies) en autorisaties. RBAC koppelt autorisaties alleen aan functies van personen. Beveiligingseisen zijn echter niet alleen afhankelijk van medewerkers. Sommige taken mogen niet op bepaalde systemen worden uitgevoerd, omdat ze op minder veilige plaatsen staan. Denk daarbij aan balie PC's en thuiswerkplekken, maar ook aan meer en minder beveiligde zones en panden. Op jacht naar de bron RBAC vraagt aan een bronsysteem actuele attributen op grond waarvan rechten uitgedeeld kunnen worden. Het bronsysteem voor rollen is meestal de HR administratie. Daarin staat wel op welke afdeling iemand zit (of zat) en wat de functienaam van iemand is (of was). Maar je hebt veel meer input nodig als je niet met heel grove schetsen autorisaties wilt uitdelen, veel meer informatie dan HR heeft. Die moet je gaan bijhouden. Als je geen bron hebt, dan moet je alles handmatig gaan doen. Nu zijn er soms wel andere registers die de benodigde informatie bevatten. Maar om het urenschrijfsysteem, de prikklok en het helpdesksysteem te koppelen als bron voor deze onmisbare informatie, gaat nogal ver. Het zal slechts incidenteel kunnen, omdat vrijwel al deze registraties achteraf vastleggen, terwijl RBAC de informatie vooraf nodig heeft. Datakwaliteit RBAC en ieder ander geautomatiseerd autorisatiebeheer is 100% afhankelijk van triggers in bronsystemen. De datakwaliteit is kritiek, en hoe meer brongegevens je moet gebruiken, hoe meer data die nu nog informationeel is, kritiek wordt. Voor HR is het kamernummer een leuk extraatje, maar als je er provisioning aan koppelt moet het kloppen. En blijven kloppen. Het gebruik van meerdere bronnen leidt tot interessante synchronisatievragen en arbitraire keuzes over welke gegevens wanneer leidend zijn. Als één systeem 90% goede data heeft, dan gaat 10% van de autorisaties fout. Met vijf bronsystemen met ieder 90% kwaliteit mag je blij als er wel eens een transactie lukt. Bedenk je dat als data op twee plekken staat in plaats van op een plek, iedere waarde in het eigen systeem kan kloppen maar dat ze ten opzichte van elkaar kunnen verschillen waarmee de datakwaliteit daalt. Hoge kwaliteit van data is fijn, maar zeker niet gratis. Onderhoud Naast bronnen voor triggers heb je voor alle geautomatiseerde provisioning business logica nodig: iedereen die op kamernummer A213 zit krijgt default printer B11787_VNS. Zit iemand in project HUPSA dan moet hij bij de projectenshare, op de testkamer V4_120 kunnen komen, rechten op bepaalde VPN's krijgen en een nieuwere versie van bepaalde software op de PC hebben. Echter, niet iedereen in het project heeft precies hetzelfde nodig. Stopt die persoon bij project HUPSA, dan moet hij nog twee maanden bij de data kunnen voor de nazorg maar niet meer bij de rest, terwijl andere mensen die stoppen met het project geen nazorgtaken hebben en dus ook niet onder de twee maanden regel vallen. Bij een gemiddeld project zijn deze zaken bovendien niet van te voren bekend, dus ze moeten snel. Als je dit soort vragen projecteert op een organisatie met enige schaalgrootte, een paar projecten en een reorganisatietje hier en daar, dan weet je dat je dagelijks tientallen mutaties in de logica zult hebben. En dit zijn mutaties die in de regel in de applicatiecode zitten. Als dat zo is, heb je na iedere logicawijziging een nieuwe release van de Code. De Change Manager ziet je al aankomen; en met maar één change window per week kom je er in ieder geval niet. RBAC 2.0? Jean Pierre Vincent beschrijft in het blad Informatiebeveiliging een concept voor "RBAC 2.0" met een structuurwijziging (een extra abstractielaag), om niet persoonsgebonden rules te kunnen bevatten. Een prima idee, waarvoor de 'toolleveranciers' wel even hun systemen moeten aanpassen. Dat zal misschien gebeuren, maar het existentiële probleem van de beschikbaarheid van brongegevens en de realiteit van de almaar wijzigende logica wordt er niet door opgelost. Zij maken RBAC tot een monstrum van complexiteit. De implementatie- en de beheeruitdaging zal navenant zijn, evenals de foutkans, dus het beweren dat de kosten zullen dalen en de veiligheid zal toenemen is erg optimistisch, ongeacht de wijzigingen in RBAC 2.0 of later. De belangrijkste argumenten om RBAC in te voeren zijn vermindering van de kosten en het verhogen van de veiligheid. Veiliger en goedkoper, omdat het eenvoudiger zou worden. Welnu, in de zestienjarige geschiedenis van RBAC is aangetoond dat het niet in te voeren is. Mislukte projecten zijn per definitie duur. En het mislukken is echt niet omdat het niet serieus geprobeerd is, knappere koppen dan alle Security.nl lezers bij elkaar hebben de tanden erop stukgebeten. Stukjes van RBAC zie je soms wel, maar het grote geheel is nergens gelukt. Het is net zoiets als PKI en X.500 - er zitten bruikbare zaken in, maar het grote concept is te complex en te ambitieus. Onbruikbaar dus. Het is dan ook hoog tijd dat we met z'n allen afspreken nooit meer te zeggen dat RBAC een bruikbare oplossing is. Voor je het weet staat het daadwerkelijk in een bindende richtlijn. Dan moeten we het bouwen en dat heeft uiteindelijk maar één mogelijke uitkomst: een compleet fiasco. Daarmee verliezen we veel van de opgebouwde geloofwaardigheid die we als ICT Security zo moeizaam opgebouwd hebben. Door Peter Rietveld, Senior Security consultant bij Traxion - The Identity Management Specialists -
Abonneren op:
Posts (Atom)