Anticiperen op onvolkomenheden

Wat me telkenmale weer opvalt is dat IT-intensieve
systemen vaak alleen de happy flow implementeren,
en elke afwijking daarvan leidt direkt tot fouten
en falen van het systeemcomplex.  Dit treedt
meestal direkt na indienststelling van het systeem
op, en daarna is het pappen en nathouden.  De
happy flow is die gang door een (bedrijfs)proces
als alles loopt volgens het boekje.  Een heel
simpel voorbeeld uit de security hoek is SQL
injection.  De happy flow is dat een gebruiker
inlogt met naam en wachtwoord.  Een alternatief is
dat iemand SQL code injecteert om zonder naam of
wachtwoord binnen te komen.  Als er nooit is
nagedacht over die mogelijkheid, dan bestaat er
grote kans dat er geen preventieve maatregelen
genomen zijn om ongenode gasten te weren.

Het anticiperen op onvolkomenheden in systemen is
al meer dan een halve eeuw onderdeel van een
gedegen ontwerpproces.  Althans, dat behoort het
te zijn, maar dit wordt lang niet altijd gebezigd.
Meer dan zeventig jaar geleden bedacht de
Amerikaanse Defensie dit al: de FMECA.  Dit staat
voor Failure Mode, Effects and Criticality
Analysis.  Men gebruikt ook wel FMEA wat een iets
beperktere versie ervan is.  In de militaire
standaard MIL-STD-1629A worden de procedures
beschreven voor het uitvoeren van een FMECA.  Deze
methode heeft tevens geschopt tot internationale
standaard: de IEC 60812 (Analysis techniques for
system reliability -- Procedure for failure mode
and effects analysis).

Heel kort gezegd komt een FMECA hierop neer.  Het
is een methode om uit te vissen hoe een systeem
allemaal zou kunnen falen, hoe erg dat is, en wat
je allemaal kunt doen om falen te voorkomen, en zo
niet welke maatregelen je dan allemaal moet nemen
mocht het toch zover komen.  De militaire
standaard verwoordt het aldus: "This standard
establishes requirements and procedures for
performing a failure mode, effects, and
criticality analysis (FMECA) to systematically
evaluate and document, by item failure mode
analysis, the potential impact of each functional
or hardware failure on mission success, personnel
and system safety, system performance,
maintainability, and maintenance requirements.
Each potential failure is ranked by the severity
of its effect in order that appropriate corrective
actions may be taken to eliminate or control the
high risk items."

Dat is een mondvol maar er zit geen woord Spaans
bij.  Ter illustratie aangaande het SQL injection
voorbeeld: doe aan inputvalidatie waardoor je SQL
commando's afvangt.  Werk met stored procedures
zodat willekeurige SQL commando's uberhaupt niet
uitgevoerd kunnen worden, indien er toch ergens
een gaatje blijkt te zitten.  Vang de
foutmeldingen van de database af zodat
diagnostische informatie van de database engine
ongenode gasten niet in de kaart speelt.  Kijk,
daar heb je wat aan.

Een FMECA is geen statisch verhaal dat je een
keertje kunt doen en dat is het dan.  De FMECA
voer je uit in verschillende stadia van de
levenscyclus van een systeem.  Bij de begin
stadia, tot aan de exploitatiefase.  Het is niet
beperkt tot het systeem maar kan ook dienen om het
proces de maat te nemen dat het systeem
ondersteunt.  En omdat tijdens het ontwerp zaken
nog wel eens veranderen is aanpassing of herhaling
van de FMECA dan nodig.  In de IEC norm wordt dat
geadviseerd: "During a design process, the
functional elements (hardware and software) of an
item may be repeatedly rearranged or reconfigured
or its capability may be changed.  At each stage,
the relevancy of the identified failure modes and
the FMEA should be updated or even repeated."

Het aardige van dit soort methodes en technieken
is dat er reeds lang en breed over is nagedacht,
dat het in standaarden is neergelegd, en dat dit
precies is wat je nodig hebt als je IT-intensieve
systemen wilt (laten) ontwerpen, bouwen en/of
exploiteren.  Er is maar een ding dat je niet moet
nalaten.  Eis dat het ontwerpproces geintegreerd
de FMECA methodologie meeneemt.

Dit is niet het hele verhaal: eisen is de eerste
stap: een nodige voorwaarde.  Daarna moet je
uiteraard daadwerkelijk regie voeren en borgen dat
de FMECA's worden uitgevoerd, en bij veranderende
eisen of ontwerpen worden aangepast.  Bij
aanbesteding valt dit onder stringent
contractbeheer waar inhoudsmensen nodig zijn om te
kunnen toetsen of de FMECA's hout snijden en in
lijn lopen met de ontwerpstadia of latere stadia
in de levenscyclus.

Het leven wordt niet gemakkelijk door FMECA's,
omdat je daarmee het ontwerpproces uitbreidt.
Omgekeerd: het wordt moeilijker, en uitvoerders
gaan klagen en draaien om er onder uit te komen.
Daarop is stringente regievoering noodzakelijk.

Uitbreiding met FMECA's zekert wel dat niet alleen
de happy flow wordt uitgemodelleerd, en je systeem
gewoon niet fit-for-purpose blijk na oplevering.
Daarnaast eis je dit ook voor onderhoud en beheer
zodat je in latere fasen van de levenscyclus ook
de fout en faalmodi in kaart hebt en daar waar
mogelijk (preventieve) maatregelen neemt.  En dit
voordat de fouten je overkomen zonder dat je erop
had geanticipeerd.

Het alternatief van laat-maar-waaien is bij vele
systemen blijkbaar geen optie: veel te veel
systemen blijken het meteen niet goed te doen bij
oplevering.  De kosten daarvan zijn vak inhibitief
hoog ten opzichte van ontwerpkosten waar in de
beginstadia meer dan het meest simplistische wordt
ingecalculeerd.

X

Meer weten over de wondere wereld van ICT
in Jip en Janneke taal? Ga dan naar de
knipselkrant van Chris Verhoef

Prof. dr Chris Verhoef is hoogleraar informatica
aan de Vrije Universiteit in Amsterdam en
wetenschappelijk adviseur voor overheid en
bedrijfsleven.  Hij schrijft regelmatig een
column in AG II.  Hij is te bereiken via email:
x@cs.vu.nl.  Deze tekst is copyright SDU.  Niets
van deze uitgave mag zonder schriftelijke
toestemming van de uitgever worden overgenomen of
worden gepubliceerd.