Defender for IoT en uw netwerkarchitectuur
Dit artikel is een in een reeks artikelen waarin het implementatiepad voor OT-bewaking met Microsoft Defender voor IoT wordt beschreven.
Gebruik de onderstaande inhoud voor meer informatie over uw eigen operationele technologie (OT)/IoT-netwerkarchitectuur en waar elk van uw systeemelementen in lagen van OT-netwerksegmentatie valt.
OT-/IoT-netwerklagen
Het netwerk van uw organisatie bestaat uit veel apparaattypen, die kunnen worden onderverdeeld in de volgende hoofdgroepen:
- Eindpuntapparaten. Kan meerdere subgroepen bevatten, zoals servers, computers, IoT-apparaten (internet of things), enzovoort.
- Netwerkapparaten. De infrastructuur bedienen met netwerkservices en kan netwerkswitches, firewalls, routers en toegangspunten omvatten.
De meeste netwerkomgevingen zijn ontworpen met een hiërarchisch model van drie lagen. Bijvoorbeeld:
| Laag | Omschrijving |
|---|---|
| Toegang | De toegangslaag is waar de meeste eindpunten zich bevinden. Deze eindpunten worden doorgaans geleverd door een standaardgateway en routering vanuit de bovenste lagen, en vaak routering vanuit de distributielaag. * Een standaardgateway is een netwerkservice of entiteit binnen het lokale subnet dat verantwoordelijk is voor het routeren van verkeer buiten het LAN- of IP-segment. |
| Verdeling | De distributielaag is verantwoordelijk voor het samenvoegen van meerdere toegangslagen en het leveren van communicatie naar de kernlaag met services zoals VLAN-routering, kwaliteit van service, netwerkbeleid, enzovoort. |
| Kern | De kernlaag bevat de hoofdserverfarm van de organisatie en biedt snelle en lage latentieservices via de distributielaag. |
Het Purdue-model van netwerkarchitectuur
Het Purdue Reference Model for Industrial Control System (ICS)/OT-netwerksegmentatie definieert nog eens zes lagen, met specifieke onderdelen en relevante beveiligingscontroles voor elke laag.
Elk apparaattype in uw OT-netwerk valt in een specifiek niveau van het Purdue-model, zoals wordt weergegeven in de volgende afbeelding:
In de volgende tabel wordt elk niveau van het Purdue-model beschreven wanneer dit wordt toegepast op apparaten die u mogelijk in uw netwerk hebt:
| Naam | Beschrijving |
|---|---|
| Niveau 0: Cel en gebied | Niveau 0 bestaat uit een groot aantal sensoren, actuatoren en apparaten die betrokken zijn bij het basisproductieproces. Deze apparaten voeren de basisfuncties van het industriële automatiserings- en controlesysteem uit, zoals: - Een motor rijden - Variabelen meten - Een uitvoer instellen - Het uitvoeren van belangrijke functies, zoals schilderen, lassen en buigen |
| Niveau 1: Procesbeheer | Niveau 1 bestaat uit ingesloten controllers die het productieproces beheren en manipuleren waarvan de sleutelfunctie is om te communiceren met de apparaten op niveau 0. In discrete productie zijn deze apparaten programmeerbare logische controllers (PLC's) of externe telemetrie-eenheden (RTU's). In de procesproductie wordt de basiscontroller een gedistribueerd besturingselementsysteem (DCS) genoemd. |
| Niveau 2: Toezicht | Niveau 2 vertegenwoordigt de systemen en functies die zijn gekoppeld aan het runtimetoezicht en de werking van een gebied van een productiefaciliteit. Deze omvatten meestal het volgende: - Operatorinterfaces of human-machine interfaces (HMIs) - Alarm- of waarschuwingssystemen - Proceshistoricus en batchbeheersystemen - Werkstations in de controleruimte Deze systemen communiceren met de PLC's en RTU's in niveau 1. In sommige gevallen communiceren of delen ze gegevens met de systemen en toepassingen van de site of onderneming (niveau 4 en niveau 5). Deze systemen zijn voornamelijk gebaseerd op standaardcomputers en besturingssystemen (Unix of Microsoft Windows). |
| Niveaus 3 en 3.5: Siteniveau en industrieel perimeternetwerk | Het siteniveau vertegenwoordigt het hoogste niveau van industriële automatisering en controlesystemen. De systemen en toepassingen die op dit niveau bestaan, beheren sitebrede industriële automatisering en controlefuncties. Niveaus 0 tot en met 3 worden beschouwd als essentieel voor sitebewerkingen. De systemen en functies die op dit niveau bestaan, kunnen het volgende omvatten: - Productierapportage (bijvoorbeeld cyclustijden, kwaliteitsindex, voorspellend onderhoud) - Planthistoricus - Gedetailleerde productieplanning - Operationeel beheer op siteniveau - Apparaat- en materiaalbeheer - Server voor het starten van patches - Bestandsserver - Industrieel domein, Active Directory, terminalserver Deze systemen communiceren met de productiezone en delen gegevens met de bedrijfssystemen (niveau 4 en niveau 5) en toepassingen. |
| Niveaus 4 en 5: Bedrijfs- en bedrijfsnetwerken | Niveau 4 en niveau 5 vertegenwoordigen de site of het bedrijfsnetwerk waar de gecentraliseerde IT-systemen en -functies bestaan. De IT-organisatie beheert de services, systemen en toepassingen rechtstreeks op deze niveaus. |
OT-sensoren in uw netwerk plaatsen
Wanneer Defender for IoT-netwerksensoren zijn verbonden met uw netwerkinfrastructuur, ontvangen ze gespiegeld verkeer, zoals van SPAN-poorten (Switch Mirror) of netwerk-TAPs. De beheerpoort van de sensor maakt verbinding met het bedrijfs-, bedrijfs- of sensorbeheernetwerk, zoals voor netwerkbeheer vanuit Azure Portal.
Bijvoorbeeld:
In de volgende afbeelding worden Defender for IoT-resources toegevoegd aan hetzelfde netwerk als eerder beschreven, waaronder een SPAN-poort, netwerksensor en Defender for IoT in Azure Portal.
Zie Voorbeeld van OT-netwerkconnectiviteitsmodellen voor meer informatie.
Interessante verkeerspunten identificeren
Interessante punten vanuit een beveiligingsperspectief zijn doorgaans de interfaces die verbinding maken tussen de standaardgatewayentiteit en de kern- of distributieswitch.
Het identificeren van deze interfaces als interessante punten zorgt ervoor dat verkeer van binnen het IP-segment naar buiten het IP-segment wordt bewaakt. Zorg ervoor dat u ook rekening houdt met ontbrekend verkeer. Dit is verkeer dat oorspronkelijk is bestemd om het segment te verlaten, maar uiteindelijk in het segment blijft. Zie Verkeersstromen in uw netwerk voor meer informatie.
Bij het plannen van een Defender for IoT-implementatie raden we u aan de volgende elementen in uw netwerk te overwegen:
| Overweging | Omschrijving |
|---|---|
| Unieke verkeerstypen binnen een segment | Houd vooral rekening met de volgende typen verkeer binnen een netwerksegment: Broadcast-/Multicast-verkeer: verkeer dat wordt verzonden naar een entiteit binnen het subnet. Met Internet Group Management Protocol (IGMP) wordt snooping in uw netwerk geconfigureerd, maar er is geen garantie dat multicast-verkeer wordt doorgestuurd naar een specifieke entiteit. Broadcast- en multicast-verkeer wordt doorgaans verzonden naar alle entiteiten in het lokale IP-subnet, inclusief de standaardgatewayentiteit, en wordt daarom ook gedekt en bewaakt. Unicast-verkeer: verkeer dat rechtstreeks naar de bestemming wordt doorgestuurd, zonder de volledige subneteindpunten te overschrijden, inclusief de standaardgateway. Bewaak unicastverkeer met Defender for IoT door sensoren rechtstreeks op de toegangsswitches te plaatsen. |
| Beide verkeersstromen bewaken | Wanneer u verkeer naar Defender for IoT streamt, staan sommige leveranciers en producten een richtingsstroom toe, wat een kloof in uw gegevens kan veroorzaken. Het is erg handig om beide richtingen van verkeer te bewaken om netwerkgespreksinformatie over uw subnetten en betere nauwkeurigheid in het algemeen op te halen. |
| De standaardgateway van een subnet zoeken | Voor elk interessant subnet is het interessante punt een verbinding met de entiteit die fungeert als de standaardgateway voor het netwerksubnet. In sommige gevallen is er echter verkeer binnen het subnet dat niet wordt bewaakt door het reguliere interessante punt. Het bewaken van dit type verkeer, dat anders niet wordt bewaakt door de typische implementatie, is handig, met name op gevoelige subnetten. |
| Atypisch verkeer | Het bewaken van verkeer dat niet anders wordt bewaakt door de typische implementatie, kan extra streamingpunten en netwerkoplossingen vereisen, zoals RSPAN, netwerk tappers, enzovoort. Zie Verkeersspiegelingsmethoden voor OT-bewaking voor meer informatie. |
Voorbeeld van verkeersdiagram
In het volgende diagram ziet u een voorbeeldnetwerk in een gebouw van drie verdiepingen, waarbij de eerste en tweede verdieping zowel eindpunten als switches bevatten, en de derde verdieping eindpunten en switches bevat, maar ook firewalls, kernswitches, een server en routers.
Verkeer dat buiten het IP-segment reist, wordt weergegeven met een blauwe stippellijn.
Interessant verkeer wordt rood gemarkeerd en geeft de plaatsen aan waar we aanraden om netwerksensoren te plaatsen om dat interessante verkeer naar Defender for IoT te streamen.
Verkeersstromen in uw netwerk
Apparaten die netwerkverkeer activeren, komen overeen met het geconfigureerde subnetmasker en IP-adres met een doel-IP-adres om te begrijpen wat het doel van het verkeer moet zijn. Het doel van het verkeer is de standaardgateway of elders in het IP-segment. Dit overeenkomende proces kan ook een ARP-proces activeren om het MAC-adres voor het doel-IP-adres te vinden.
Op basis van de resultaten van het overeenkomende proces houden apparaten hun netwerkverkeer bij als verkeer binnen of buiten het IP-segment.
| Verkeer | Omschrijving | Voorbeeld |
|---|---|---|
| Verkeer buiten het IP-segment | Wanneer de verkeersbestemming niet binnen het bereik van het subnetmasker wordt gevonden, verzendt het eindpuntapparaat het verkeer naar de specifieke standaardgateway die verantwoordelijk is voor het routeren van de verkeersstroom naar andere relevante segmenten. Elk verkeer dat buiten een IP-segment reist, loopt via een standaardgateway om het netwerksegment te kruisen, als eerste hop in het pad naar de bestemming. Opmerking: Het plaatsen van een Defender for IoT OT-netwerksensor zorgt ervoor dat al het verkeer buiten het segment wordt gestreamd naar Defender for IoT, geanalyseerd en kan worden onderzocht. |
- Een pc is geconfigureerd met een IP-adres van 10.52.2.201 en een subnetmasker van 255.255.255.0. - De pc activeert een netwerkstroom naar een webserver met een doel-IP-adres van 10.17.0.88. - Het besturingssysteem van de pc berekent het doel-IP-adres met het bereik van IP-adressen in het segment om te bepalen of het verkeer lokaal moet worden verzonden, binnen het segment of rechtstreeks naar de standaardgatewayentiteit die de juiste route naar de bestemming kan vinden. - Op basis van de resultaten van de berekening vindt het besturingssysteem dat voor de IP- en subnetpeering ( 10.52.2.17 en 255.255.255.0), het segmentbereik is 10.52.2.0 – 10.52.2.255. De resultaten betekenen dat de webserver zich niet binnen hetzelfde IP-segment bevindt als de pc en dat het verkeer naar de standaardgateway moet worden verzonden. |
| Verkeer binnen het IP-segment | Als het apparaat het doel-IP-adres binnen het bereik van het subnetmasker vindt, wordt het verkeer niet door het IP-segment gekruist en binnen het segment om het MAC-doeladres te vinden. Voor dit verkeer is een ARP-resolutie vereist, waardoor een broadcastpakket wordt geactiveerd om het MAC-adres van het doel-IP-adres te vinden. |
- Een pc is geconfigureerd met een IP-adres van 10.52.2.17 en een subnetmasker van 255.255.255.0. - Deze pc activeert een netwerkstroom naar een andere pc, met een doeladres van 10.52.2.131. - Het besturingssysteem van de pc berekent het doel-IP-adres met het bereik van IP-adressen in het segment om te bepalen of het verkeer lokaal moet worden verzonden, binnen het segment of rechtstreeks naar de standaardgatewayentiteit die de juiste route naar de bestemming kan vinden. - Op basis van de resultaten van de berekening vindt het besturingssysteem dat voor de IP- en subnetpeering ( 10.52.2.17 en 255.255.255.0), het segmentbereik is 10.52.2.0 – 10.52.2.255. De resultaten betekenen dat het doel-IP-adres van de pc zich in hetzelfde segment bevindt als de pc zelf en dat het verkeer rechtstreeks in het segment moet worden verzonden. |
Defender for IoT-implementatie implementeren met een unidirectionele gateway
Als u met een unidirectionele gateway werkt, zoals Waterval, Uil Cyber Defense of AzureMann, waarbij gegevens in één richting door een gegevensdiode gaan, gebruikt u een van de volgende methoden om te begrijpen waar u uw OT-sensoren kunt plaatsen:
Plaats uw OT-sensoren buiten de netwerkperimeter (aanbevolen). In dit scenario ontvangt uw sensor SPAN-verkeer via de diode, unidirectioneel van het netwerk naar de bewakingspoort van de sensor. We raden u aan deze methode te gebruiken in grote implementaties. Bijvoorbeeld:
Plaats uw OT-sensoren in de netwerkperimeter. In dit scenario verzendt de sensor UDP Syslog-waarschuwingen naar doelen buiten de perimeter via de gegevensdiode. Bijvoorbeeld:
OT-sensoren die binnen de netwerkperimeter worden geplaatst, worden door de lucht geplaatst en moeten lokaal worden beheerd. Ze kunnen geen verbinding maken met de cloud of worden beheerd vanuit Azure Portal. U moet deze sensoren bijvoorbeeld handmatig bijwerken met nieuwe bedreigingsinformatiepakketten.
Als u met een unidirectioneel netwerk werkt en sensoren in de cloud nodig hebt die worden beheerd vanuit Azure Portal, moet u ervoor zorgen dat u uw sensoren buiten de netwerkperimeter plaatst.
