Waarom u moet overstappen op Connext DDS Secure

"Beveiliging moet worden ingebouwd, niet vastgeschroefd." Waar. Je hebt het gehoord. Ik heb het ook gehoord. Nu het IIoT snel realiteit wordt, wordt deze zin zelfs zo vaak herhaald dat ik me zorgen maak dat het een cliché wordt dat een gevoel van urgentie creëert zonder echte potentie. Maar waarom wordt beveiliging om te beginnen vaak vastgeschroefd? Zal het begrijpen van de redenen ons helpen het te vermijden? Ik hoop het. Er zijn veel redenen, variërend van economische tot regelgevende, educatieve en technische redenen, waar ik in deze blogpost niet in detail op in kan gaan (zie de IISF voor meer details).

In sommige gevallen is tijdens de ontwikkeling van de systeemarchitectuur niet goed nagedacht over het dreigingslandschap, de bijbehorende risico's en beveiligingsoverwegingen. In andere gevallen worden bestaande systemen herbestemd om onder geheel andere omstandigheden met geheel andere bedreigingen te werken. Beveiligingsanalisten staan ​​vaak afwijzend tegenover dergelijke inspanningen, en dat is begrijpelijk. Management op een hoger niveau wordt echter doorgaans gedreven om beslissingen te nemen door marktkrachten, waarbij hogere prioriteit wordt gegeven aan efficiëntie en hoogwaardige functionaliteit. Misschien is beveiliging een overhead waar u zich zorgen over kunt maken als u eenmaal het basissysteem aan de gang hebt. Of misschien denkt u dat uw systeem "air gapped" zal zijn. Maar het is op dat moment waarschijnlijk te laat om de beveiliging te overwegen vanwege de kosten van het opnieuw ontwerpen van het systeem. Dus men zou proberen zijn best te doen door later beveiliging toe te voegen nadat het basissysteem is opgestart. In veel gevallen is het proces om later beveiliging toe te voegen niet goed gedefinieerd of, in gevallen waar er bekende best practices zijn, niet goed gevolgd. Waarom zouden we ons dan verbazen over de teleurstellende status van beveiliging in het IIoT?

Een deel van de uitdaging van beveiligingstechniek is het bedenken van architecturen die een acceptabele bescherming bieden tegen beveiligingsbedreigingen die voortkomen uit fouten, onheil of kwaadwilligheid, terwijl de bedrijfsfunctie en de prestaties van het systeem tot een minimum worden beperkt. Dit klinkt eenvoudig, maar is in de praktijk vrij moeilijk te realiseren – vooral omdat systemen complexer en onderling afhankelijk worden en grotere, meer diverse groepen mensen eraan werken om ze te realiseren. Met name voor IIoT-systemen moeten beveiligingsmaatregelen worden overwogen binnen de bredere beperkingen van interoperabiliteit, prestaties, schaalbaarheid, veerkracht, veiligheid en compliance, in omgevingen waar veiligheidsbedreigingen en bijbehorende risico's vrij snel veranderen. Deze overwegingen zijn levendig besproken en overwogen bij de ontwikkeling van de DDS-beveiligingsspecificatie en RTI's Connext® DDS Secure.

Als u al een DDS-gebruiker bent of DDS overweegt om dit te worden, moet u zeker RTI Connext DDS Secure overwegen. Hieronder zal ik bespreken hoe Connext DDS Secure beveiligingsconfiguraties mogelijk maakt waarmee architecten en ingenieurs de juiste balans tussen beveiliging en prestaties kunnen vinden, op basis van beveiligingsrisico's en prestatie-eisen. Ik zal ook een voorbeeld geven van een onderzoeksproject dat gericht is op het veilig integreren van klinische omgevingen om de resultaten voor de patiënt aanzienlijk te verbeteren.

Is DDS-beveiliging de juiste keuze voor uw gebruik?

RTI-ingenieurs gebruiken doorgaans een vuistregel om te zien of het ontwerpen van het systeem van een klant op basis van DDS echt zinvol is, of dat ze beter af zijn met een ander connectiviteitsraamwerk (zie IICF voor een gedetailleerde, technische discussie over dit onderwerp). Als het antwoord op ten minste drie van de volgende vijf vragen "ja" is, zou DDS in het algemeen het meest geschikte raamwerk voor het systeem zijn naast andere bestaande connectiviteitsraamwerken:

1. Is het een groot probleem als uw systeem voor korte tijd niet meer werkt?
2. Heeft u de afgelopen twee weken 'milliseconde' of 'microseconde' gezegd?
3. Heeft u meer dan 10 software-engineers?
4. Verzendt u gegevens naar veel plaatsen, in plaats van slechts één (bijvoorbeeld naar de cloud of een database)?
5. Implementeer je een nieuwe IIoT-architectuur?

Als uw antwoord op vraag 1 ja is, heeft u strenge eisen op het gebied van beschikbaarheid en fouttolerantie. DDS biedt al functies die enorm helpen met deze vereisten, waaronder volledig peer-to-peer-werking (dus zonder enige storingspunten), en verschillende relevante parameters, waaronder beleid voor eigendom, duurzaamheid, levendigheid en deadline QoS. Bovendien zorgt DDS Security voor scheiding van DDS-domeinen, authenticatie van DDS-deelnemers, autorisatie om DDS-onderwerpen te publiceren of zich erop te abonneren en authenticatie van DDS-berichten voordat gegevens worden doorgegeven van de middleware naar toepassingen op een hoger niveau. Deze functies zorgen voor preventie en/of aanzienlijke beperking van de impact van sommige klassen van Denial-of-Service (DOS)-aanvallen. Deze functies, in combinatie met de juiste maatregelen voor toegangscontrole op netwerk-, besturingssysteem- en applicatieniveau, zouden een betere bescherming bieden tegen mogelijke DoS-aanvallen in op DDS gebaseerde systemen.

Als uw antwoord op vraag 2 ja is, is de kans groot dat u aanzienlijke realtime vereisten heeft. In dergelijke gevallen wilt u de beveiliging van uw DDS-systeem verfijnen op basis van zowel risico- als prestatievereisten. Het kan u bijvoorbeeld niet schelen dat een temperatuurmeting van een sensor in een openbare ruimte wordt gecodeerd en vertrouwelijk wordt verzonden, maar u geeft waarschijnlijk wel om de authenticiteit van die metingen. Met DDS Security kunt u dergelijke configuraties definiëren en afdwingen, zonder wijzigingen in uw applicatiecode aan te brengen.

Een positief antwoord op vraag 3 betekent waarschijnlijk dat u de kosten van interoperabiliteit tussen softwareontwikkelingsteams die elk aan verschillende aspecten van een vrij groot softwareproject werken, wilt minimaliseren. Het datacentrische ontwerp van DDS stelt softwareteams in staat om het eens te worden over welke gegevens (d.w.z. typen en onderwerpen) moeten worden gedistribueerd en hoe (d.w.z. met welke QoS-instellingen), zonder dat het noodzakelijk is om API's voor gegevensverwerking bloot te leggen. Evenzo maken DDS-beveiligingsconfiguraties voor ingebouwde plug-ins (bijv. domeinbeheer en deelnemersmachtigingsbestanden) het mogelijk om beveiligingsbeleid voor gegevensdistributie te definiëren. Deze expliciete beleidsregels worden opgesteld op basis van uw datamodellen en hoe u DDS-domeinen wilt beschermen. Dit beleid kan onafhankelijk worden beoordeeld door beveiligingsingenieurs en systeemarchitecten en kan worden aangepast op basis van risicoanalyse en prestatie-eisen zonder wijzigingen in de applicatiecode aan te brengen.

Een positief antwoord op vraag 4 betekent waarschijnlijk dat u multicast optimaal wilt gebruiken voor een veel efficiëntere gegevenslevering. In tegenstelling tot populaire oplossingen op transportniveau, zoals TLS/DTLS, die geen gebruik kunnen maken van de voordelen van multicast, is DDS Security ingebouwd met multicast-ondersteuning, wat een meer geoptimaliseerde prestatie van gegevenslevering mogelijk maakt.

Als je antwoord op vraag 5 positief is, heb je de kans om beveiliging in te bouwen zonder je al te veel zorgen te maken over legacy code. Tegelijkertijd heeft u waarschijnlijk schaalbaarheid, interoperabiliteit en het vermijden van vendor lock-in op uw lijst met vereisten. DDS is een van de belangrijkste connectiviteitstechnologieën voor het IIoT (zie IICF voor meer details) en is gebaseerd op een openbaar beschikbare set specificaties. Bovendien maakt DDS Security gebruik van een pluggable architectuur met gestandaardiseerde API's voor authenticatie, autorisatie, cryptografie, data tagging en logging. Deze functies, samen met de ondersteuning van expliciet en gedetailleerd beveiligingsbeleid voor gegevensdistributie, maken DDS een sterke kandidaat voor next-gen IIoT-systemen, waardoor beveiliging kan worden ontworpen in, niet vastgebout aan, uw systeemarchitectuur.

Dit klinkt allemaal interessant, maar gebruikt iemand DDS Security? Het antwoord is een krachtig ja. RTI Connext DDS Secure is al geëvalueerd en gebruikt door een aantal van onze commerciële en overheidsklanten. We hebben de feedback die we van deze early adopters hebben ontvangen, verwerkt in onze productlijn. In gevallen waarin verdere verduidelijking of updates van de DDS-beveiligingsspecificatie nodig waren, hebben we de problemen aan de DDS-gemeenschap voorgelegd om de standaard verder te verbeteren.

Voorbeeld:DDS-beveiliging voor veilige interoperabiliteit van medische apparatuur

Een interessant voorbeeld dat de voordelen van DDS en DDS Security laat zien, duikt op in de context van Integrated Clinical Environments (ICE). Het ICE-raamwerk, zoals gedefinieerd door de ASTM F2761-09-standaard, biedt een benadering voor het integreren van heterogene medische apparaten en het coördineren van hun activiteiten om klinische workflows te automatiseren. Vanuit een hoogstaand perspectief is het idee achter ICE om medische apparaten die voldoen aan de ICE-standaard, ofwel native of met behulp van een aftermarket-adapter, te laten samenwerken met andere ICE-compatibele apparaten, ongeacht de fabrikant. Indien correct uitgevoerd, belooft deze aanpak dramatische verbeteringen in de patiëntveiligheid mogelijk te maken. Bekende voorbeelden zijn onder meer transfers van patiënten van de operatiekamer (OK) naar inten

[1] [2] 下一页