A co autentizace? IT požaduje autentizaci před přenosem dat. To samozřejmě BACnet nedělá.
Architektura sítě, kterou navrhujete, není izolovaná. Není na oddělené OT síti. Ve skutečnosti je na stejné síti jako pokladna.
Proč by to někdo dělal? Odkazuji na model vydírání, který navrhli jiní uživatelé. Pokud někdo získá přístup ke všem zařízením v rozsahu 30000 kusů, může je zneužít na jakémkoli místě kdykoli.
Ale oceňuji zpětnou vazbu. Pokud se mýlím, dejte mi vědět, jak. Vidím váš názor, že směrování z místa na místo je šifrováno díky použití IPSec.
Nezdůrazňoval jsem, kolik je na lokalitách starého zařízení. 30,000 s prakticky rovnoměrným zastoupením za posledních 15 let, některé ještě z roku 1995. Také nejběžnější řadič nemá BACnet/SC.
Rychlé googlení ukazuje, že současné řídicí systémy BASrouterSC jsou dostupné.
Carrier XT-RB je BACnet SC. S koncem tohoto roku mají všechna řídicí zařízení Carrier BACnet schopná BACnet SC.
Ale BACnet SC je potřeba pouze pro přenos dat do cloudu, který sídlí na serveru mimo zabezpečenou síť vlastníka. Je potřeba další SC řadič, který data dešifruje, což přidává hodně nákladů a složitosti.
Jakmile jsou data šifrována, vracíme se k podobnému stavu jako proprietární sítě, které byly původním důvodem vzniku BACnet. Soukromé šifrovací klíče a heslem chráněné sítě zabrání interoperabilitě, kterou BACnet měl umožnit vlastníkům budov a zabránit uvěznění do jednoho dodavatele.
Posun k SaaS v BAS bude velmi negativní pro vlastníky budov. Alespoň můj názor.
Protokol BacnetSC vyžaduje certifikáty. V specifikaci není žádný proces distribuce masově, ani podpora Automatizovaného řízení certifikátů (ACME). BacnetSC neumožňuje revokaci certifikátů.
Nelze tedy poslat certifikát zařízení a poté ho odvolat. Neexistuje žádný mechanismus revokace certifikátů. Nejlepší řešení jsou krátkodobé certifikáty, ale to znamená, že je nutné pravidelně zasílat nové certifikáty do všech zařízení. Bez podpory ACME nelze tuto tvorbu nebo nasazení certifikátů dávkově provádět.
Specifikace popisuje uzly a centra, ale zatím nebyla vyvinuta komunikace node-to-node.
BACnetSC by mělo být vyspělejší, ale stále se má co zlepšovat.
Pokud používá zákazník firewally na zdroji a cíli, může IPSec ve firewallu zašifrovat provoz BACnet při přechodu z lokalit na místo nebo do podnikové nebo cloudové sítě.
Packet je před odjezdem zašifrován a na koncovém firewallu dešifrován. BACnet/SC to dělá na portu 443, což zašifruje provoz BACnet.
BACnet neobsahuje credentials nebo PII a OT data jsou většinou bez kontextu. Proč by někdo hackoval OT BACnet? Pokud má takové schopnosti, hledáte skutečné cíle.
Je minimální riziko, pokud je IT oddělení kompetentní. Snažíte se je vystrašit z ničeho.
Není vzdálené, pokud nemohou prolomit firewall. Firewall VLAN by měl chránit síť před útoky zvenčí. Navíc BACnet nevede útoky na firmy. Hackují se pouze přihlašovací údaje operátorů, aby se získal přístup do zabezpečených sítí.
Cloud se připojuje pouze k routerům BACnet SC. Ty pak poskytují cloudům šifrované datové toky s daty BACnet.
Typický vzdálený přenos je přes VPN nebo povolenou IP, zatímco propojení může být realizováno přes VLAN, která zahrnují firewally nebo BBMD připojení, jež mohou být také za firewallem s otevřenými porty. Použití Tridium JACE zvýší šifrování připojení Niagara nebo, podle značky ovládání, může být použito REST připojení.
Jakékoliv zneužití. Nevěřím jejich řešení, a chci, aby ho nepoužívali. Každý nejhorší scénář je skvělý.
Jsem v „proti“ táboře a snažím se všechny možné scénáře, aby je odradili od toho, aby ho používali.
Co přesně jsou vaše konkrétní obavy z BACnet SC? Nikdy jsem neslyšel, že by někdo tvrdil, že je nedokonalé.