JanaxLooij
commented
6 years ago [jvgeijlswijk@6-6-2013] Arne Bruinse schreef op 03-06-2013:
Hierbij de uitwerking van het antwoord op het security isssue zoals benoemd door Alliander. Na intern overleg zijn wij van mening dat een verdere specificering van beveiliging niet in de standaard thuis hoort:
De VISI systematiek bevat alle voorwaarden om tussen servers van verschillende bedrijven te communiceren.
De beveiliging van het internetverkeer tussen servers staat los van de VISI sytematiek. Door één bepaalde beveiligingsoplossing voor te schrijven worden bedrijven beperkt om in geval van nieuwe beveiligingsstandaarden te schakelen en hierop over te stappen. Bedrijven die met elkaar afspreken om via VISI te communiceren kunnen met elkaar een specifieke beveiliging voor de onderlinge verbinding afspreken.
Om deze reden noemen wij alleen enkele mogelijke beveiligingsopties die gekozen kunnen worden.
Hier een voorbeeld hoe dat in IIS kan: https://www.sslcertificaten.nl/knowledgebase/MS_IIS/IIS7_-_website_beveiligen_met_client_certificaten IIS7 kan worden ingesteld om gebruik te maken van client certificaten voor authenticatie, voor zowel een website als voor bijvoorbeeld OWA. Hiervoor wordt eerst een webserver certificaat uitgegeven aan de webserver door de Enterprise Root Certification Authority. Vervolgens worden client certificaten uitgegeven aan gebruikers, via een speciale website op de server. Dit client certificaat kan vervolgens worden opgeslagen in de Certificate Store van de gebruiker, of op een token of smart card. De keypair kan ook rechtstreeks vanaf de token of smart card worden aangemaakt indien dit wordt ondersteund door de token.
Daarnaast kunt u op uw eigen server zorgen dat u de IP-adressen van uw VISI-contacten op een whitelist zet, en andere IP-adressen de toegang tot uw VISI service ontzegt.
Achtergrond "Op donderdag 25 april hebben we een gesprek gehad met Quyntess (SAPii) en Bakker&Spees voor het testen van de koppeling tussen SAPii en B&S.
Tijdens dit gesprek is een security issue naar voren gekomen. ViSi kent geen authenticatie op username en wachtwoord. Maw, als je het adres van de soap server van een ViSi software leverancier kent, kun je hier berichten naar toe sturen. Deze berichten worden geanalyseerd en indien het bericht-id matcht, dan wordt het bericht afgehandeld. Dit is conform de ViSi standaard. Andersom verwacht B&S dit dus ook van SAPii.
Voor Alliander is dit een zwaarwegend security issue. Deze zal toegevoegd moeten worden aan de lijst van issues die we geadresseerd willen hebben tijdens de Pressure Cooker."
"We hebben de grondhouding dat verkeer over Internet versleuteld is. Bijvoorbeeld met een TLS (SSL is oud) tunnel of (nog beter) met versleutelde en ondertekende SOAP berichten met WS-Security.
Ook bij beveiliging willen we gebruik maken van open protocollen, dus als we encryptie toepassen, zijn dat publieke protocollen zoals AES (met min. Sleutellengte van 128 bit) en RSA (met min. Sleutellengte van 1024 bit)"
Functionele samenvatting Dit punt betreft feitelijk technische eisen voor de SOAP Server.
Oplossing(en) De VISI Standaard dient af te dwingen dat de communicatie tussen SOAP Servers plaatsvindt via https en SSL, waardoor de inhoud van ontvangen berichten niet onderschept kan worden.
Het gebruik van HTTPS (TLS 1.0 of hoger, met minimaal 128 bits encryptie) voor het versturen van VISI berichten en bijlagen is verplicht. Het is niet toegestaan om de "parseMessage" SOAP service aan te bieden over een onbeveiligd http kanaal.
Verder dient alle communicatie (indien deze over internet verloopt) tussen een VISI gebruiker en een VISI applicatie gebruik te maken van HTTPS met dezelfde specificaties.
Overige beveiligingsmaatregelen kunnen desgewenst op infrastructuur niveau worden getroffen.
Aanbeveling(en) Verder kunnen SOAP Servers de techniek "whitelist" gebruiken, waardoor alleen geautoriseerde SOAP server berichten naar een SOAP Server kunnen sturen .
Acties
testscenario documenteren: Adressen verifieren op HTTPS (actiehouder: Peter Willems)
leidraad aanpassen (actiehouder: Peter Willems)
Backwards compatibility
Geen consequenties, want het is alleen een verfijning van een bestaande bepaling
Attachments
certificeringstest_item.png
This work item was migrated from CodePlex
CodePlex work item ID: '1003' Assigned to: 'PeterWillems' Vote count: '1'