Beschikbaarheid informatiesystemen

[Verwijderd]

We hebben een leuke uitdaging vanuit wet- en regelgeving
Onze informatiesystemen moeten voldoen aan "de voor diensten overeengekomen niveau van beschikbaarheid". Op basis van een risicoanalyse moeten wij de beschikbaarheid eis bepalen.

Zoiets is helemaal nieuw voor mij als IT'er. Hoe pak ik zoiets aan? Ik heb zelf de volgende stappen uit mijn duim gezogen, kunnen jullie mij helpen?

1. inventariseer welke informatiesystemen & infrastructuurcomponenten er gebruikt worden voor welke dienst.
2. ik voer een risicoanalyse (hoe?? kans*impact=risico?) uit op die informatiesystemen & infrastructuurcomponenten binnen de specifieke dienst. M.a.w. wat is de kans dat switchX gebruikt voor dienstX omvalt.
3. daar rolt dan een beschikbaarheidspercentage uit (hoe??!)
4. ik ga naar de proceseigenaar en zeg: "beste proceseigenaar, op basis van mijn uitgevoerde risicoanalyse is het beschikbaarheidspercentage 99%.
5. de proceseigenaar accepteerd dit of komt met hogere beschikbaarheidseisen, in dat geval gaan we sleutelen om de bschikbaarheid te kunnen verhogen (uitwijk, hot stand-by, stroomgenerator etc.) en begin in weer bij stap 2

.

Thx

[PyBo]

Ik denk dat je moet beginnen met de eisen en wensen van beschikbaarheid van de informatiesystemen met daarbij een inventarisatie van de bedrijven/mensen/partijen die aan het systeem gekoppeld zullen zijn (hier zijn steakholders van te maken).

Wanneer je dit geïnventariseerd hebt kan je inderdaad een risicoanalyse uit gaan voeren, hierbij ga je kijken naar wat de zwakke onderdelen van je systeem zijn, hier maak je weer een inventarisatie van. Van ieder onderdeel kan je dan een beschikbaarheid percentage berekenen door te kijken hoe lang het vervangen van het gehele onderdeel zou zijn.

Zeg dat een switch vervangen 2 dagen duurt. Dat is 2 van de 365 dagen (2 / 365), waarbij je door kan gaan rekenen naar percentages.

Tevens misschien handig om mee te nemen voor je uitwijk, hot stand-by, stroomgenerator de scenario's (overstroming, brand, stroomstoring) wanneer dit zal gebeuren en hoe groot de kans is dat dit nodig is. Percentage's zijn misschien lastig maar een schaalverdeling is denk toch wel te bedenken.

[F_J_K]

Stap 0 is: 99.x van wat? Van de infra (kunnen pingen), van de applicatie (outlook.exe draait), van de applicatiefunctionaliteit (inloggen, mail typen, spellchecken, plaatje erbij, versturen, ontvangstbevestiging verwerken: een bug = downtime), ook nog eens met goede snelheid (binnen y seconden). En misschien denkt de klant wel dat het ook de omliggende infra (downtime van netwerk, downtime van client-PC, downtime van ontvangende mailserver, etc.) omvat.

Dat is 2 van de 365 dagen

Lijkt me niet, uptimes worden eerder per bijv. maand vastgelegd. En dan 24/7 (met/zonder onderhoudswindows) of bijv enkel kantooruren. 99% uptime is bijna 6.5 uur per maand downtime. Of een dikke anderhalf uur per maand als je alleen weekdagen 9u-17u telt.

IMHO: niet zelf willen doen. Er zijn te veel mitsen en maren waar je achteraf ruzie over krijgt als je niet voooraf weet wat het betekent.

-

Eventueel kan je het andersom aanpakken: hoeveel mag het eerste uur downtime kosten, hoeveel het tweede, etc. 99.99% roepen is makkelijk, tot je weet wat het kost (in een maatwerk-omgeving).

Onze informatiesystemen moeten voldoen aan "de voor diensten overeengekomen niveau van beschikbaarheid"

'Best effort' is ook een voor diensten overeengekomen niveau van beschikbaarheid. Bijv icm een reactiesnelheid.

[Wish]

Wat jij aan het doen bent is eigenlijk onderdeel van business continuity planning of management. Daar is best veel over te vinden, o.a. plannen van aanpak en frameworks. Hopelijk helpt je dit een beetje op weg.

[sh4d0wman]

Welke wet-/regelgeving moet je aan voldoen?

Bij een vorige werkgever kwam deze (of soorgelijke) eis voort uit ISO 27002. Voor ons was het relatief simpel omdat we ook ITIL geimplementeerd hadden en van daaruit waren Service Level Agreements opgesteld voor de interne diensten, waaronder IT.

Zoek inderdaad meer informatie zoals Wish je heeft gegeven. Kijk daarnaast ook eens naar ITIL, daar is het nodige over Service Level Agreements terug te vinden.

Verder:
- Breng prioriteit en afhankelijk in kaart van alle processen en systemen, vergeet mensen niet!
- Wat FJK zegt: definieer uptime en meet de huidige beschikbaarheid
- Spreek met de processeigenaren over de eisen en wensen van beschikbaarheid.
- Kijk hoe ver huidige percentages hier vanaf zitten
- Voer een risicoanalyse / business impact analyse uit en kijk hoe je de meest kritieke zaken kunt.oplossen of verminderen. Communiceer dit ook naar processeigenaren zodat ze weten wat voor rest-risico er is.
- Bespreek met de processeigenaren hoe de beschikbaarheid te verhogen is, wat de kosten hiervan zijn en of dit in verhouding staat tot het proces of systeem. B.v. met een gelimiteerd budget pak je eerst de kritieke systemen aan en daarna wellicht overige als er nog geld over is.

Er zijn ook diverse bedrijven die consultancy op dit gebied leveren. Wellicht goed om ook eens mee te praten want het kost wel heel veel tijd om zelf te doen. Zeker als je er weinig ervaring mee hebt. (nee, ik werk niet voor zo'n bedrijf haha).


edit: @ Eagle: dat klopt, wij gebruikten ISO/IEC 17799:2000 wat vervolgens 27002 werd en hierna hebben we 27001 geimplementeerd wat wel geaudit en gecertificeerd kan worden We moesten voldoen aan bepaalde wetgeving binnen de overheid.

[ Voor 6% gewijzigd door sh4d0wman op 23-04-2014 16:06 ]

[Eagle Creek]

Bij een vorige werkgever kwam deze (of soorgelijke) eis voort uit ISO 27002. Voor ons was het relatief simpel omdat we ook ITIL geimplementeerd hadden en van daaruit waren Service Level Agreements opgesteld voor de interne diensten, waaronder IT.

De ISO27002 is een set met maatregelen, daar kun je niet aan "voldoen".

Wat jij aan het doen bent is eigenlijk onderdeel van business continuity planning of management. Daar is best veel over te vinden, o.a. plannen van aanpak en frameworks. Hopelijk helpt je dit een beetje op weg

Niet alleen BCM, IB/ISM in zijn algemeenheid.

@Rroupp:
Leuke vraagstelling!

Om te beginnen:
- Welke wet- en regelgeving moet je aan voldoen?
- Waarom is dit bij jou als IT-er belegd? Is er ook hoger in de organisatie hulp, ondersteuning en bewustwording hiervan?

Jouw vragen:
1.
Dat is zeker goed. Begin dan wel met de diensten en hang daar classificatieniveaus aan. Vanuit daar kun je de informatiesystemen en infrastructuren in kaart brengen.

2.
Kans * Impact is een goed begin, doch basaal.
Het voorbeeld dat je noemt is niet de juiste aanpak (switch X voor dienst Y).

Voorbeeld:

Dienst = klantsupport
Benodigd = klantsupportsysteem
Afhankelijkheid infra = hoog
Beschikbaarheidseis = 3

Kans = hoe groot is de kans dat de switch uitvalt
Hoe hoog is de impact

Impact = 5, onacceptabel
Kans = 5, maar één switch

Maatregel: switch dubbel uitvoeren. Kans gaat omlaag.
(technisch gezien blijft de kans dat één switch uitvalt hetzelfde maar gaat de impact van de uitval van één switch omlaag).

3: Ligt aan de methode die je kiest.
Stel:
Kans = 1 - 5
Impact = 1 - 5
Maximale score = 25 (5*5)

Je (je management!) moet dan een risk apetite bepalen.
Bijvoorbeeld: alle risico's boven de score 20 willen we nooit accepteren.
Alle risico's boven de score 15 willen we alleen accepteren als er €XXX.XXX mee gemoeid is.
(impact kun je ook nog laten uitdrukken in financiele schade, menselijke schade, imago-schade, etc).

5: Klopt! Deels..
Op dit moment in het proces leert de praktijk dat hij zijn beschikbaarheidseisen naar BENEDEN zal bijstellen omdat enigszins duidelijk is welke kosten er gemoeid zijn met het op peil houden van het niveau dat hij eerder genoemd heeft (zie stap 1). Hier zit niet een directe loop in.
(wel later in PDCA)

[The Eagle]

Je CIA rating bepaalt je onder meer je beschikbaarheid.
C: Confidentiality
I: Integrity
A: Availability
Meestal heeft iedere letter een rating, op een schaal van 1 tot 5 (waarbij 1 het hoogste is)
De CIA rating wordt bepaald door de BIA: Business Impact Analysis. Daarin beschrijf je per CIA de risico's die bestaan (risicoanalyse) en de impact daarvan op de business. Ook kijk je hoe groot de kans is dat een issue voorkomt. Daaruit vloeit ook je set aan evt countermeasures (proactief / reactief) of acceptatie van het risico. De combinatie van die risico's en countermeasures bepaalt je algemene CIA rating voor je applicatie. Op basis daarvan kun je dan vervolgens bepalen waar je infra en procedures aan moeten voldoen. Want met alleen infra ben je er niet, maar dta had je vast zelf ook al bedacht