image

Snel moet opheldering geven over databeveiliging Belastingdienst

woensdag 24 oktober 2018, 13:26 door Redactie, 25 reacties

Staatssecretaris Snel van Financiën moet opheldering geven over de databeveiliging bij de Belastingdienst. Onlangs werd bekend dat de fiscus niet bijhoudt welke medewerkers gegevens uit de systemen opvragen, omdat dit technisch niet mogelijk zou zijn. Aanleiding voor VVD-Kamerleden Lodders en Middendorp om Snel enkele vragen te stellen.

Zo moet de staatssecretaris laten weten welke technische onmogelijkheden de Belastingdienst bedoelt en of de berichtgeving klopt dat de fiscus geen inzicht heeft in waar welke data zich bevindt in de systemen. Lodders en Middendorp vragen ook naar mogelijkheden om persoonsgegevens bij de Belastingdienst te beveiligen. "Zou het met meer kennis en kunde en/of een betere algemene ICT-architectuur bij de overheid wel mogelijk zijn om persoonsgegevens bij de Belastingdienst te beveiligen? Zo nee, waarom niet?", aldus de vraag van de Kamerleden.

Snel moet verder laten weten of hij het ermee eens is dat het opslaan van geselecteerde persoonsgegevens in één heldere en unieke bron het probleem van het gebrek aan overzicht bij de Belastingdienst waar persoonsgegevens zich bevinden kan oplossen en of er nog meer overheidsinstellingen zijn die problemen hebben met de beveiliging van persoonsgegevens.

In juni maakte de staatssecretaris nog bekend dat de Belastingdienst binnen een jaar aan de Algemene verordening gegevensbescherming (AVG) zou voldoen. Lodders en Middendorp willen nu weten wanneer dit precies zal zijn en of er mogelijke vervolgstappen van de Autoriteit Persoonsgegevens zullen volgen. De staatssecretaris heeft drie weken de tijd om de vragen te beantwoorden (pdf).

Reacties (25)
24-10-2018, 13:59 door Power2All
Iets met geen budget, teveel opgehoopte troep (aka, een soort van Windows ME flashback), en geen inzicht hebben wat voor systemen er gebruikt worden.
24-10-2018, 14:04 door Anoniem
Door Power2All: Iets met geen budget, teveel opgehoopte troep (aka, een soort van Windows ME flashback), en geen inzicht hebben wat voor systemen er gebruikt worden.
Je vergeet alle Cobalt code die niemand meer kan lezen.... van alle Cobalt programmeurs hebben gebruik gemaakt van de vervroegde pensioen regeling

TheYOSH
24-10-2018, 14:23 door Anoniem
Door Power2All: Iets met geen budget, teveel opgehoopte troep (aka, een soort van Windows ME flashback), en geen inzicht hebben wat voor systemen er gebruikt worden.
Ik kan me voorstellen dat de blunder met de vrijwillige vertrekregeling ook het nodige ontregeld heeft en dat ze daar nu last van hebben.
24-10-2018, 14:24 door Anoniem
Door Anoniem: Je vergeet alle Cobalt code die niemand meer kan lezen.... van alle Cobalt programmeurs hebben gebruik gemaakt van de vervroegde pensioen regeling

TheYOSH
Cobalt? Bedoel je COBOL?
24-10-2018, 15:01 door Anoniem
Dit valt mij zowiezo op meerdere plekken op. Ik was laatst bij een gezondheidszorg instellingen waar verschillende artsen patienten behandelen en nergens staat geregistreerd wie wat heeft gedocumenteerd.
24-10-2018, 15:11 door Anoniem
Kamervragen, jeuj. Beetje suf om te komen zeuren als alle goede mensen al lang en breed weggebonjourd zijn. Maarja, je moet toch wat dus toch maar eens wakker worden en gaan vingerzwaaien. En er dan achterkomen dat de problemen oplossen zo eenvoudig nog niet is. Was je er op tijd bijgeweest dan had het voor minder geld en moeite beter gekund. Maarja.

Dit is waarom we vroeger wel zeiden dan regeren is vooruitzien, en waarom je kan zeggen dat we al een paar decennia niet geregeerd worden. Er is gewoon niemand met voldoende inhoudelijke kennis om op tijd de boel bij te kunnen sturen. Want niemand binnen wat dan bestuur heet kan ver genoeg vooruitzien om de problemen aan te zien komen. Dat willen ze ook helemaal niet, want ze zijn met hele andere dingen bezig. De belastingdienst is dan wel een mooie grote puinhoop, het is zeker niet de enige chronische puinhoop.
24-10-2018, 15:47 door Anoniem
Door Anoniem:
Door Power2All: Iets met geen budget, teveel opgehoopte troep (aka, een soort van Windows ME flashback), en geen inzicht hebben wat voor systemen er gebruikt worden.
Je vergeet alle Cobalt code die niemand meer kan lezen.... van alle Cobalt programmeurs hebben gebruik gemaakt van de vervroegde pensioen regeling

TheYOSH

Als kennis van COBOL het enige probleem zou zijn, dan is dat op te lossen door eigen programmeurs op cursus te sturen. Of als die cursus niet meer gegeven wordt, ze de handboeken in laten duiken of een pensionaris dit laten onderrichten.
(Die goei oude tijd toen er nog echt geprogramemerd werd)

Dat lost alleen de spaghettiebrei aan systemen bij de belastingdienst niet op.
Dat is het grotere probleem. En blijkbaar is die brei zo onoverzichtelijk, dat niet meer duidelijk is wie waar bij kan.

En dan mag je er ook van uit gaan, dat accounts/wachtwoorden van systemen gedeeld zullen worden.(In ieder geval tot het tegendeel bewezen is)
24-10-2018, 16:43 door Anoniem
Wat echt het probleem is, is dat de overheid geen kennis heeft hoe je software architectuur moet onderhouden en aanpassen. De overheid laat zich door iedereen adviseren en wetenschappers en grote consultants hebben allemaal hun eigen expertise en kijken vanuit een smalle invalshoek terwijl het probleem veel abstracter bekeken moet worden.
24-10-2018, 17:09 door Anoniem
Door Anoniem: Wat echt het probleem is, is dat de overheid geen kennis heeft hoe je software architectuur moet onderhouden en aanpassen. De overheid laat zich door iedereen adviseren en wetenschappers en grote consultants hebben allemaal hun eigen expertise en kijken vanuit een smalle invalshoek terwijl het probleem veel abstracter bekeken moet worden.

De belastingdienst heeft ook last van de onvoorspelbaarheid van de politiek.

Die beslissen pas op het laatste moment (eind december) of er een wijziging in de belastingwetten moet komen (meestal met nog een laatste amandement die alle aannames overhoop gooit) en verwachten vervolgens dat die gewijzigende regeltjes dit binnen enkele weken geimplementeerd, getest en in gebruik genomen zijn.

Omdat er door de jaren heen haastige patch op haastige patch op haastige patch (ad nauseum) op die (Cobol-)code heeft plaatsgevonden, wordt de onderhoudbaarheid van die code steeds slechter.

Als de politiek nu eens een aantal jaren geen wijzigingen in de belastingwetgeving zou doorvoeren, of hier langere lopptijden voor aan zou houden, dan heeft de belastingdienst ook lucht.
Dan kan ze personeel aan te trekken. Die (laten) trainen. En dan deze spaghettie ombouwen naar een systeem dat flexibiliteit bevat en dus minder adhoc aanpassingen aan de code nodig heeft.
Let wel: door de onvoorspelbaarheid/nukken van de politiek zullen er altijd wel absurde regels bedacht worden waar geen enkele code op berekend is.
24-10-2018, 17:19 door Tha Cleaner
Door Anoniem: Wat echt het probleem is, is dat de overheid geen kennis heeft hoe je software architectuur moet onderhouden en aanpassen. De overheid laat zich door iedereen adviseren en wetenschappers en grote consultants hebben allemaal hun eigen expertise en kijken vanuit een smalle invalshoek terwijl het probleem veel abstracter bekeken moet worden.
Wat je zegt klopt maar voor een klein gedeelte. Maar er speelt veel meer dat veel belangrijker is.Namelijk het politieke landschap is veel complexer van de techniek. Afdelingen die denken dat ze god zijn en dat daarom alles moet wijken voor hun voorkeur.
Nog afgezien de belastingplannen iedere jaar weer anders zijn en steeds complexer worden.
Het momenteel een spaghetti is op de ICT afdeling maar dat het eigenlijk onmogelijk is om dit goed aan te pakken. Te complex te veel stakeholders.
24-10-2018, 17:22 door karma4 - Bijgewerkt: 24-10-2018, 17:29
Het antwoord is in de eerdere openbaar gemaakte zaken terug te vinden. Je moet het willen zien.
Handmatig werk moet ict problemen oplossen dan gebruik je de mogelijkheden buiten het zicht van ict.
In de vele systemen met geplande verbeteringen zie je deze tot standaard oplossingen verheven.

Ik kan me voorstellen dat de blunder met de vrijwillige vertrekregeling ook het nodige ontregeld heeft en dat ze daar nu last van hebben.
Ik denk van niet. Het waren schaal E en F in de rvu regeling die de kosten omhooggevallen brachten. Denk dan aan ljjnmanagers en architecten. Daar onder zijn de mensen die het wer doen B C die weinig aan een gedwongen vertrek met armoedige vergoeding hebben. De hoge raad heeft de Bd tegengesproken.
Het is eerder een geblunder dat interne strijden doorgaan.
24-10-2018, 17:31 door Anoniem
Door Anoniem:
De belastingdienst heeft ook last van de onvoorspelbaarheid van de politiek.

Die beslissen pas op het laatste moment (eind december) of er een wijziging in de belastingwetten moet komen (meestal met nog een laatste amandement die alle aannames overhoop gooit) en verwachten vervolgens dat die gewijzigende regeltjes dit binnen enkele weken geimplementeerd, getest en in gebruik genomen zijn.

Omdat er door de jaren heen haastige patch op haastige patch op haastige patch (ad nauseum) op die (Cobol-)code heeft plaatsgevonden, wordt de onderhoudbaarheid van die code steeds slechter.

Als de politiek nu eens een aantal jaren geen wijzigingen in de belastingwetgeving zou doorvoeren, of hier langere lopptijden voor aan zou houden, dan heeft de belastingdienst ook lucht.
Dan kan ze personeel aan te trekken. Die (laten) trainen. En dan deze spaghettie ombouwen naar een systeem dat flexibiliteit bevat en dus minder adhoc aanpassingen aan de code nodig heeft.
Let wel: door de onvoorspelbaarheid/nukken van de politiek zullen er altijd wel absurde regels bedacht worden waar geen enkele code op berekend is.

Veranderingen vinden overal in de IT plaats en als je niet snel genoeg kunt veranderen is je development team het probleem.
Tegenwoordig bestaan er genoeg oplossingen voor het voorkomen van spaghettie als je kijkt hoe Amazon bijvoorbeeld code schrijft en onderhoudt.
In de ICT dien je flexibele te zijn.

Daarnaast hoe groot zou een Beslatingdienst systeem zijn?
Niet veel groter dan dat de Webshop van Amazon.
24-10-2018, 18:02 door Anoniem
Een hulde voor de analoge/mechanische wereld die we vroeger kende,
de heimwee naar die tijd word steeds groter,

Geen smartphone-tablet,sleepnet,meltdown-spectre,cybercrime,digitale corruptie,
hackers,nsa,bedrijfsleven en overheid die alles van je wilt weten etc.

Niets is 100% veilig,en alles blijft lek,mosterd na de maaltijd,altijd maar weer,
investeringen,patchen en maar patchen.
Ik heb als burger niets te willen,wel afhankelijk moeten worden van de digitalisering.
24-10-2018, 19:10 door Anoniem
Door Anoniem: Veranderingen vinden overal in de IT plaats en als je niet snel genoeg kunt veranderen is je development team het probleem. Tegenwoordig bestaan er genoeg oplossingen voor het voorkomen van spaghettie als je kijkt hoe Amazon bijvoorbeeld code schrijft en onderhoudt. In de ICT dien je flexibele te zijn.

Zeg dat maar tegen de COBOL programmeeurs die 10-tallen jaren geleden de code moesten schrijven, en de politiek die sindsdien alelen maar met late wijzigingen is gekomen. Dan is code op orde houden niet mogelijk.
Het nu omschrijven van alle bestaande regeltjes naar nieuwe flexibele code, is een monnikenwerk. En hier heb je geen standaard software voor. Dit is maatwerk / een kennissysteem.

Door Anoniem: Daarnaast hoe groot zou een Beslatingdienst systeem zijn?
Niet veel groter dan dat de Webshop van Amazon.

Amazon heeft iets meer mensen in dinst voor de softwasre ontwikkleing. Is later begonnen dan de belastingdienst en heeft heel veel minder te maken met willekurige late politieke besluiten en dus meer tijd om aanpassingen te implementeren.

Vergis je vervolgens niet in de grootte (programmmacode regels, data-opslag, atl FTe op de IT afdeling. Hoe wil jij dit meten???) Zeker als je alleen naar de webshop kijkt en niet naar het distributie systeem erachter. Dan is de belastindienst echt wel groter.
Die spaghettiecode is complex. En in talen die niet meer courant zijn.
Anders dan bij Amazon. (mag je hopen)


Maar als jij denkt het beter te kunnen doen...
Bouw een "systeempje" voor de belastingdienst dat aan alle actuele regels voldoet en onderhoudbaar is (en niet groter dat de webshop code van Amazon), en laat vervolgens de politiek en belastingmedewerkers erop los.
Laat maar een jaartje schaduwdraaien. Eens kijken hoe goed jouw systeempje zich staande houdt in de harde werkelijkheid.
24-10-2018, 20:04 door Anoniem

Veranderingen vinden overal in de IT plaats en als je niet snel genoeg kunt veranderen is je development team het probleem.
Tegenwoordig bestaan er genoeg oplossingen voor het voorkomen van spaghettie als je kijkt hoe Amazon bijvoorbeeld code schrijft en onderhoudt.
In de ICT dien je flexibele te zijn.

Daarnaast hoe groot zou een Beslatingdienst systeem zijn?
Niet veel groter dan dat de Webshop van Amazon.
Appels en peren vergelijken, gaat niet om hoe groot, maar om hoe complex.
Een webshop is totaal iets anders en veel simpeler.
Waarschijnlijk zal het veel groter zijn als jij denkt.
24-10-2018, 21:30 door Anoniem
Door Anoniem:
Veranderingen vinden overal in de IT plaats en als je niet snel genoeg kunt veranderen is je development team het probleem.
Tegenwoordig bestaan er genoeg oplossingen voor het voorkomen van spaghettie als je kijkt hoe Amazon bijvoorbeeld code schrijft en onderhoudt.
In de ICT dien je flexibele te zijn.

Daarnaast hoe groot zou een Beslatingdienst systeem zijn?
Niet veel groter dan dat de Webshop van Amazon.

Het probleem bij de Nederlandse overheid is dat ze allemaal mensen inhuren om hun vuile klusjes te doen. Ze willen zelf zo min mogelijk risico's nemen.
Hoe de belastingdienst dit bijvoorbeeld doen is door consultants in te huren en deze consultants iets te laten implementeren op ze laten zich door deze mensen adviseren en dan wanneer deze mensen klaar zijn met hun projecten is het afgelopen en is de kennis verdwenen.
Nederlandse overheid weet niet zoveel van computers, netals de hackers van de AIVD, zo goed zijn ze niet.
25-10-2018, 10:23 door Anoniem
Door Anoniem: Daarnaast hoe groot zou een Beslatingdienst systeem zijn?
Niet veel groter dan dat de Webshop van Amazon.
Reken maar dat dat veel groter is. Vergelijk het invullen van je aangifte inkomstenbelasting eens met een online aankoop. Ik kan je verzekeren dat de belastingaangifte veel meer varianten en mogelijkheden ondersteunt dan die online aankoop. Dat je je aangifte tegenwoordig ingevuld voor je snufferd krijgt verlaagt de complexiteit voor jou, maar om ook dat goed te doen is het systeem voor de belastingdienst juist ingewikkelder geworden.

En dan is inkomstenbelasting maar één van de vele vormen van belasting. Daar komt bij dat al die vormen niet ingericht kunnen worden zoals de organisatie wel handig vindt maar dat het precies de wetgeving moet implementeren. En niet alleen de nationale wetgeving, ook allerlei internationale verdragen moeten erin verwerkt worden zodra een aspect (inkomstencomponent, vestigingsplaats, betaling) de grens over gaat. De boekhouding van een bedrijf moet ook aan regels voldoen, natuurlijk, maar bedenk dat waar een specifiek bedrijf aan moet voldoen maar een van de varianten is waar de belastingdienst mee te maken heeft, en de belastingdienst moet alle varianten ondersteunen.

De webshop van Amazon zal veel meer transacties verwerken, maar de automatiseringsinspanning wordt voor een belangrijk deel niet bepaald door het transactievolume (al moet je systeem dat wel trekken en is schaalbaarheid dus een criterium) maar door de complexiteit van die transacties. En die is bij de belastingdienst heel wat hoger dan bij een webwinkel.
25-10-2018, 10:26 door Anoniem
Door Anoniem:
Door Anoniem: Veranderingen vinden overal in de IT plaats en als je niet snel genoeg kunt veranderen is je development team het probleem. Tegenwoordig bestaan er genoeg oplossingen voor het voorkomen van spaghettie als je kijkt hoe Amazon bijvoorbeeld code schrijft en onderhoudt. In de ICT dien je flexibele te zijn.

Zeg dat maar tegen de COBOL programmeeurs die 10-tallen jaren geleden de code moesten schrijven, en de politiek die sindsdien alelen maar met late wijzigingen is gekomen. Dan is code op orde houden niet mogelijk.
Het nu omschrijven van alle bestaande regeltjes naar nieuwe flexibele code, is een monnikenwerk. En hier heb je geen standaard software voor. Dit is maatwerk / een kennissysteem.

Door Anoniem: Daarnaast hoe groot zou een Beslatingdienst systeem zijn?
Niet veel groter dan dat de Webshop van Amazon.

Amazon heeft iets meer mensen in dinst voor de softwasre ontwikkleing. Is later begonnen dan de belastingdienst en heeft heel veel minder te maken met willekurige late politieke besluiten en dus meer tijd om aanpassingen te implementeren.

Vergis je vervolgens niet in de grootte (programmmacode regels, data-opslag, atl FTe op de IT afdeling. Hoe wil jij dit meten???) Zeker als je alleen naar de webshop kijkt en niet naar het distributie systeem erachter. Dan is de belastindienst echt wel groter.
Die spaghettiecode is complex. En in talen die niet meer courant zijn.
Anders dan bij Amazon. (mag je hopen)


Maar als jij denkt het beter te kunnen doen...
Bouw een "systeempje" voor de belastingdienst dat aan alle actuele regels voldoet en onderhoudbaar is (en niet groter dat de webshop code van Amazon), en laat vervolgens de politiek en belastingmedewerkers erop los.
Laat maar een jaartje schaduwdraaien. Eens kijken hoe goed jouw systeempje zich staande houdt in de harde werkelijkheid.

Het probleem is dan dat de overheid nogsteeds Cobol gebruikt en niet weet hoe je Cobol code kan integreren met Brokers zoals Amazon dat doet. Amazon gebruikt verschillende programmeer talen te gelijk.
25-10-2018, 10:28 door Anoniem
Ach de overheid weet niks van ICT, de enige die van ICT wat afwist was IVO Opstelten die had grote plannen om de ICT te centraliseren en overheid diensten met elkaar te laten samenwerken. Dit had potentieel miljoenen geld kunnen besparen.
25-10-2018, 12:13 door Anoniem
Door Anoniem: Het probleem is dan dat de overheid nogsteeds Cobol gebruikt en niet weet hoe je Cobol code kan integreren met Brokers zoals Amazon dat doet. Amazon gebruikt verschillende programmeer talen te gelijk.
Ik neem aan dat met "Brokers" message broker-software bedoelt?

Als je even wat gerichtge zoekopdrachten loslaat kom je zowel vacatures als cv's op linkedin tegen die suggereren dat de belastingdienst van Websphere MQ gebruik maakt (dat is van IBM en bestaat al sinds 1993, ook voor mainframes en COBOL). Dat de belastingdienst grote problemen met hun automatisering heeft is duidelijk, maar ik betwijfel dat het probleem gebrek aan kennis van dit soort dingen is.
25-10-2018, 19:11 door NonNocere
Door Anoniem:
Door Anoniem:
Als de politiek nu eens een aantal jaren geen wijzigingen in de belastingwetgeving zou doorvoeren, of hier langere lopptijden voor aan zou houden, dan heeft de belastingdienst ook lucht.
Volgens mij heeft heel Nederland hiermee te maken en niet alleen de belastingdienst. Het is een voorspelbaar proces, je moet alleen de ontwikkeling op de voet willen volgen, scenario's met bijbehorende software ontwikkelen. En ja, soms moet je code weggooien omdat een ander scenario is gekozen. Het is een kwestie van willen en doen!
26-10-2018, 11:26 door Anoniem
Een paar quates van reaguurders:

Door NonNocere:Het is een kwestie van willen en doen!

Door Anoniem: Het probleem is dan dat de overheid nogsteeds Cobol gebruikt en niet weet hoe je Cobol code kan integreren met Brokers zoals Amazon dat doet.

Door Anoniem:Veranderingen vinden overal in de IT plaats en als je niet snel genoeg kunt veranderen is je development team het probleem. Tegenwoordig bestaan er genoeg oplossingen voor het voorkomen van spaghettie als je kijkt hoe Amazon bijvoorbeeld code schrijft en onderhoudt. In de ICT dien je flexibele te zijn.

Ad nauseum.


Ik zou zeggen: doe het eens voor aan de belastingdienst. Blijkbaar weten jullie (als stuurlieden op de wal) het allemaal zoveel beter.
Nu nog aantonen svp.
26-10-2018, 19:39 door Tha Cleaner
Door NonNocere:
Door Anoniem:
Door Anoniem:
Als de politiek nu eens een aantal jaren geen wijzigingen in de belastingwetgeving zou doorvoeren, of hier langere lopptijden voor aan zou houden, dan heeft de belastingdienst ook lucht.
Volgens mij heeft heel Nederland hiermee te maken en niet alleen de belastingdienst. Het is een voorspelbaar proces, je moet alleen de ontwikkeling op de voet willen volgen, scenario's met bijbehorende software ontwikkelen. En ja, soms moet je code weggooien omdat een ander scenario is gekozen. Het is een kwestie van willen en doen!
En hier laat je nu precies zien dat je er totaal geen kaas van hebt gegeten hoe dit soort complexe infrastructuur in elkaar zit.

Je bent het schoolvoorbeeld van de beste stuurlui staan aan wal.
27-10-2018, 20:55 door karma4 - Bijgewerkt: 27-10-2018, 20:56
Door Anoniem: .....
Het probleem is dan dat de overheid nogsteeds Cobol gebruikt en niet weet hoe je Cobol code kan integreren met Brokers zoals Amazon dat doet. Amazon gebruikt verschillende programmeer talen te gelijk.
Ze zullen nog cobol gebruiken als het systeem stabiel is en al 30+ jaar stabiel draait. Verder zo wat alles wat er sinds die tijd ook ooit de beste optie was zeg maar elke taal elk os elk dbms via vele leveranciers in een soa stand alone en micro services benadering. Verschillende interne bloedgroepen particulier - bedrijf douane fiod en wat nog meer.
Dan heb je daar boven de vele shadow ict oplossingen waar het feitelijke werk gedaan wordt.
Amazon mag als groot winkelier aardig lijken de genoemde complexiteit bij de Bd is veel groter.
29-10-2018, 14:24 door hanspaint
Door Anoniem:
Door Power2All: Iets met geen budget, teveel opgehoopte troep (aka, een soort van Windows ME flashback), en geen inzicht hebben wat voor systemen er gebruikt worden.
Je vergeet alle Cobalt code die niemand meer kan lezen.... van alle Cobalt programmeurs hebben gebruik gemaakt van de vervroegde pensioen regeling

TheYOSH
De taal heet Cobol en er zijn nog een heleboel mensen die dit kunnen lezen. Met Assembler programmas is dat wat anders en het zou me niets verbazen als die ook nog gebruikt worden. Buiten dat de taal waarin een programma is geschreven zegt niets over de kwaliteit en is ook niet per definitie troep.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.