Mga gateway
Ang aming mga gateway ay ang backbone ng imprastraktura ng SensorFlow. Ang kanilang pangunahing layunin ay dalawa. Ang mga ito ay nagsisilbing proxy para sa aming mga sensor upang ipasa ang naitalang data ng sensor sa cloud pati na rin ang pagpasa ng mga command sa mga sensor na natanggap mula sa dashboard. Pangalawa, sila ang nagtataglay ng aming makina sa paggawa ng desisyon na siyang namamahala sa pagkontrol sa mga instrumentong kasangkapan batay sa naitalang impormasyon ng sensor (hal. walang tao sa silid -> patayin ang AC) Pinili namin ang diskarteng ito para sa dalawang pangunahing dahilan:
1. Seguridad: Paulit-ulit kaming nakakahanap ng mga kuwento sa balita ng mga Internet of Things (IOT) na device na inaatake ng mga hacker. Ang mga kuwentong ito ay may isang karaniwang denominator: Direktang ikinonekta ng mga vendor ang mga ito sa internet ngunit hindi nila napagtanto na ang mga limitadong kakayahan ng mga device ay nag-iiwan sa kanila na mahina sa mga sopistikadong pag-atake at/o gumawa sila ng mga shortcut sa pagpapatupad ng layer ng seguridad ng mga IOT device. Dahil dito, pinili naming protektahan ang aming mga device sa likod ng aming mga gateway upang limitahan ang ibabaw ng pag-atake at paganahin ang lahat ng komunikasyon sa pamamagitan ng mas sopistikadong device na maaaring walang kahirap-hirap na magpatupad ng mga makabagong protocol ng seguridad.
2. Sistema ng pagganap: Ang Internet of Things ay dapat na gawing mas matalino ang mga gusali, gayunpaman, madalas naming nalaman na ang mga supplier ay masyadong umaasa sa cloud at kilalang koneksyon sa internet. Para maiwasan na ang isang matalinong gusali ay nagiging piping gusali sa sandaling bumaba ang internet, idinisenyo namin ang aming system sa paraang ang lahat ng pagpapasya sa automation ay ginawa sa gateway at hindi sa cloud. Samakatuwid, kahit na walang koneksyon sa internet, susubaybayan at awtomatiko pa rin ang lahat ng appliances, magpapatuloy ang naitalang data sa gateway at mai-stream pabalik sa SensorFlow cloud kapag online na muli ang internet.
Ang mga IOT sensor ng SensorFlow ay eksklusibong nakikipag-ugnayan sa SensorFlow gateway gamit ang aming proprietary Airlink protocol. Nangyayari ang komunikasyong ito sa mga sub GHz band, kadalasan sa pagitan ng 920-925 MHz depende sa bansa at sa gayon ay hindi nakakasagabal sa kasalukuyang imprastraktura ng Bluetooth o WiFi. Ang bawat gateway ay maaaring sumuporta ng hanggang 960 sensor Node, ngunit sa pagsasagawa, nalaman namin na karaniwan naming kumokonekta ng hindi hihigit sa 300 node bawat gateway, depende sa matamo na wireless range, dahil sa layout ng gusali at materyal. Karaniwan, nag-i-install kami ng hindi hihigit sa 15 Gateway bawat site, na may average na bilang ng mga gateway na naka-install na may numero sa paligid ng 7-8.
Mga Kinakailangan sa Gateway
Ang aming mga gateway ay nakadepende sa imprastraktura ng internet ng site at maaaring ikonekta sa pamamagitan ng WiFi o ethernet, na ang ethernet ang mas gustong opsyon. Hindi kami nagbubukas ng anumang mga port sa labas at lahat ng komunikasyon ay pinasimulan sa labas gamit ang mga normal na kahilingan o mga koneksyon sa VPN. Hindi kami gumagamit ng anumang imprastraktura ng proxy. Maaaring makamit ang karagdagang pag-minimize ng surface ng pag-atake kung magse-set up ang kliyente ng sub network para kumonekta sa aming mga gateway. Sa pamamagitan nito, maaari nating ihiwalay ang ating mga komunikasyon sa network ng hotel. Ang anumang imprastraktura ng firewall ay dapat ipatupad ng network ng kliyente na ibinigay at hindi makakaapekto sa aming mga Gateway dahil papalabas ang lahat ng komunikasyon. Ang gateway ay nangangailangan ng mga sumusunod na port na bukas sa firewall para sa papalabas na komunikasyon:
Mga Kinakailangan sa Bandwidth
Ang mga kinakailangan sa bandwidth para sa mga gateway ay napakababa, dahil pangunahin nilang ipinapasa ang data ng IOT sa anyo ng mga maiikling mensahe ng json pati na rin ang mga mensahe ng log para sa mga layuning diagnostic. Ang kabuuang dami ng pag-upload ng mga Gateway ay humigit-kumulang 2MB bawat oras, depende sa aktwal na pag-install. Ang downstream na daloy ng data ay magiging bale-wala sa karaniwang operasyon at hindi lalampas sa ilang kilo byte bawat araw.
Mga Kinakailangan sa Protocol
Nakikipag-ugnayan ang gateway sa 3 panlabas na serbisyo:
1. Amazon Web Services (AWS)- Pinapatakbo ang lahat ng cloud infrastructure na bumubuo sa SensorFlow analytics at dashboard backend. Ang lahat ng mga pakikipag-ugnayan ay sinigurado gamit ang AWS Cognito, isang serbisyong nagbibigay ng pagpapatunay, awtorisasyon, at pamamahala ng user. (https://aws.amazon.com/cognito)
2. Balena.io-https://Balena.io/
Ginagamit ang Balena bilang pamamahala ng fleet para sa mga gateway. Nag-uulat ito sa katayuan ng gateway at namamahala sa anumang mga update/patch sa gateway. Ang BalenaOS ay ang batayang operating system ng gateway. Ang pangunahing application ay tumatakbo sa isang lalagyan ng Docker sa OS. Ang isang detalyadong paglalarawan ng mga pagpapatupad ng seguridad na nauugnay sa Balena ay matatagpuan dito: https://www.balena.io/docs/learn/welcome/security/
Mga komunikasyon sa Balena:
1. Isang VPN para sa oras ng pag-uulat ng system at pagpapadala ng mga log
2. Isang serbisyo ng botohan upang suriin kung mayroong anumang mga update
1. Papertrail-https://papertrailapp.com
Ang data ng log mula sa mga gateway ay ipinapadala sa papertrail para sa pamamahala ng log. Ginagamit ito para sa madaling pagbabasa ng mga log para sa anumang mga isyu sa pag-troubleshoot. Mahahanap ang mga log sa loob ng 2 linggo at naka-archive sa loob ng isang taon. (Ang pinagbabatayan ng storage ay AWS S3).
Larawan 1 mga detalye ng mga bahagi na nakikipag-ugnayan sa site at kung paano sila nakikipag-ugnayan.
Pangkalahatang-ideya ng network na nagdedetalye sa mga channel ng komunikasyon sa pagitan ng aming mga node, gateway at mga panlabas na serbisyo.
Dashboard
Ang aming dashboard ay nagbibigay-daan sa mga kliyente na makita ang data na naitala pati na rin ang kontrolin ang mga instrumentong AC system. Maaari itong ma-access mula sa anumang web browser at pinahihintulutan sa pamamagitan ng username at password login. Naka-host ito sa Google Firebase at binubuo ng kumbinasyon ng html, javascript at iba't ibang larawan. Lahat ng komunikasyon ay may AWS cloud over TLS.
Ginagamit din ng pagpapatunay at awtorisasyon para sa dashboard ang serbisyo ng AWS cognito (https://aws.amazon.com/cognito). Gagawa kami ng mga user account sa kahilingan ng kliyente na bigyan lamang ng may-katuturang staff ng access sa dashboard.
AWS Guard Duty (https://aws.amazon.com/guardduty/) ay ginagamit upang subaybayan ang cloud account para sa anumang hindi pangkaraniwang o kahina-hinalang aktibidad.
Imbakan ng data
Ang data na ipinadala sa AWS cloud ay nakaimbak sa DynamoDB (isang NoSql database) para sa mga layunin ng serbisyo ng application. Ang data ay iniimbak din sa isang mataas na pagganap ng time-series na Database (Postgres + TimeScaleDB extension) para sa mga layunin ng data science. Ang parehong mga database ay hino-host ng AWS. Ang DynamoDB ay tumatakbo bilang isang pinamamahalaang serbisyo mula sa AWS at ang aming time-series database ay naka-host sa isang AWS EC2 instance.
Suporta at Pagpapanatili
Kami ay naghahangad na magbigay ng end-to-end na serbisyo sa aming mga kliyente at may nakatuong suporta sa standby upang matugunan ang mga isyu sa system sa pamamagitan ng aming mga remote na kakayahan sa pagpapanatili. Kabilang dito ang kakayahang i-update ang firmware ng mga sensor node gamit ang over-the-air na proseso ng pag-update sa pagitan ng mga gateway at ng mga sensor. Ginagamit namin ito upang maghatid ng mga update sa seguridad, pag-aayos ng bug o mga bagong feature sa aming mga sensor. Higit pa rito, mayroon kaming kakayahan na malayuang i-update ang aming gateway software pati na rin simulan, i-restart at isara ang mga gateway gamit ang serbisyo ng balena.io. Sa mga bihirang kaso, kung mabibigo ang lahat ng malalayong hakbang, hihingi kami ng tulong sa mga on-site na inhinyero ng hotel. Ito ay kadalasang para sa pagpapalit ng baterya o pagpapalit ng sirang o sirang hardware. Kung sakaling ang gawain ay masyadong kumplikado para sa mga on-site na inhinyero na isakatuparan, magpapadala kami ng isa sa aming nakatuong mga tagapamahala ng proyekto sa pag-install upang gawin ang mga kinakailangang gawain. Susuriin ito batay sa bawat kaso.
Gateway Security
Tanging ang mga gateway ng SensorFlow ay direktang konektado sa network ng kliyente, habang ang mga sensor node ay makikipag-ugnayan lamang sa aming gateway at hindi kailanman sa internet nang direkta. Dahil dito, ang mga gateway lamang ang posibleng masugatan sa malalayong cyber-attack sa pamamagitan ng internet. Karaniwan naming ikinokonekta ang aming mga gateway sa parehong network kung saan kumokonekta ang mga bisita sa hotel. Nangangahulugan ito na mula sa pananaw ng disenyo ng network, ang panganib sa seguridad na nauugnay sa aming mga gateway ay maaaring ituring na katumbas ng anumang device na maaaring kumonekta ng isang bisita sa network ng hotel. Kahit na ang isang umaatake ay nakakuha ng access o ganap na kontrol sa SensorFlow gateway, ang mga kahihinatnan ay minimal at nakahiwalay sa gateway na pinag-uusapan.
Mga Bunga ng Gateway Attacks
1. (Minor) Pagkaantala o pag-deactivate ng automation: Ito ay hahantong sa pagkawala ng mga matitipid at ilang pagkawala ng data sa mga silid na sineserbisyuhan ng gateway na ito. Ito ang mangyayari kung ihihinto ng umaatake ang SensorFlow application na tumatakbo sa gateway.
2. (Minor) Epekto sa kaginhawaan ng bisita: Ito ay maaaring mangyari kung ang isang attacker ay namamahala na patayin ang mga FCU pagkatapos magkaroon ng access sa gateway. Gayunpaman, ito ay magiging lubhang malabong dahil ang umaatake ay kailangang ganap na i-reverse engineer ang aming lihim na proprietary protocol upang makapagpadala ng wastong mga utos sa aming mga device na magiging isang seryosong pagsisikap sa engineering. Ang pinsala ay maaari ding madaling mapigil sa pamamagitan ng pag-off sa apektadong gateway, kung saan ang aming mga thermostat ay magpapatuloy sa normal na offline na operasyon. Hindi posibleng permanenteng i-hostage ang imprastraktura sa pamamagitan ng attack vector na ito.
3. (Minor) Access sa network ng hotel: Ang isang attacker na nakakuha ng kontrol sa gateway ay maaaring gumamit ng gateway upang makinig sa trapiko ng network o i-jam ang network ng ingay. Ang mga kahihinatnan ng sitwasyong ito ay pangunahing nakadepende sa network setup ng hotel. Karaniwan naming iminumungkahi na ang mga gateway ay konektado sa kanilang sariling nakahiwalay na subnet o sa parehong network kung saan kumokonekta ang mga bisita ng hotel, na may parehong mga pribilehiyo at paghihigpit. Samakatuwid, ang isang mahusay na idinisenyong network setup ay hindi magpapahintulot sa isang device sa network ng gateway o guest network na ma-access ang mahahalagang imprastraktura ng network ng hotel.
Direktang Malayong Pag-atake sa Mga Open Gateway Port
Inilalarawan ng sitwasyong ito ang isang umaatake na sinusubukang makakuha ng malayuang pag-access sa gateway sa pamamagitan ng mga bukas na port.
Likelihood: Imposible
Ang attack vector na ito ay itinuturing na imposible dahil ang gateway ay hindi nakikinig sa anumang mga port sa labas at ang anumang komunikasyon ay pinasimulan palabas mula sa mga gateway. Ang gawi na ito ay minana mula sa BalenaOS, ang operating system na bumubuo sa base ng gateway software.
Ang isang detalyadong paglalarawan ng mga pagpapatupad ng seguridad na nauugnay sa Balena at kung paano nila pinamamahalaan ang komunikasyon at awtorisasyon ay matatagpuan dito: https://www.balena.io/docs/learn/welcome/security/
Pinapatakbo namin ang SensorFlow application sa loob ng isang docker container sa ibabaw ng BalenaOS, na nakikipag-ugnayan sa SensorFlow cloud infrastructure. Ang lahat ng komunikasyon sa aming Cloud ay muling papalabas at walang mga port na nabuksan kaya ang aming sariling application ay hindi nagdaragdag ng dagdag na attack surface sa gateway.
Dahil sa nabanggit, magiging imposible para sa isang umaatake na mahanap at atakehin ang aming mga gateway nang malayuan nang hindi muna nilalabag ang imprastraktura ng network ng kliyente. Ito ay totoo lalo na kung ang mga gateway ay karagdagang protektado ng isang firewall na naghihigpit sa pag-access sa network ng kliyente. Kahit na nakalusot sila sa firewall, hindi pa rin sila makakahanap ng anumang mga bukas na port na aatake sa ating mga gateway.
Man in the Middle Attacks on the Gateways
Ang tanging paraan para atakehin ang gateway ay para sa isang attacker na gayahin ang Balena cloud o ang SensorFlow cloud. Maaaring subukan ng isang matagumpay na attacker na magpadala ng mga command sa mga nakakonektang thermostat o palitan ang gateway firmware gamit ang sarili nilang firmware.
Likelihood: Bihira
Isinasaalang-alang namin ang sitwasyong ito ng pag-atake na napakalamang na hindi magtagumpay dahil ang lahat ng aming mga API ay sinigurado sa pamamagitan ng karaniwang HTTPS TLS encryption at pahintulot at pagpapatunay na batay sa sertipiko. Totoo ito para sa mga endpoint ng serbisyo na ipinakita ng Balena para sa kontrol at malayuang pagpapanatili pati na rin sa lahat ng SensorFlow cloud API na sinigurado ng serbisyo ng AWS Cognito. Samakatuwid, ang isang attacker ay kailangang matagumpay na nakawin ang SensorFlow o Balena root certificate upang magtagumpay sa attack vector na ito.
Pisikal na Pag-atake Sa Gateway
Kung magkakaroon ng pisikal na access ang isang attacker sa gateway, maaari niyang subukang palitan ang firmware ng aming mga gateway sa pamamagitan ng pagpapaalis sa mga SD card na nag-iimbak ng operating system at samakatuwid, gumawa ng device sa network ng hotel sa ilalim ng kanilang kontrol at malamang na naka-whitelist para kumonekta. nang hindi na kailangang dumaan sa isang captive portal.
Likelihood: Bihira
Dahil isa itong on-premise na pag-atake na nangangailangan ng teknikal na kaalaman, itinuturing namin ang posibilidad ng pag-atakeng ito na napakabihirang. Lalo na sa mga nabanggit na limitasyon sa imprastraktura ng network na dapat na malapat sa lahat ng device sa gateway o guest network. Upang maisagawa ang ganitong uri ng pag-atake, magiging mas madali para sa umaatake na direktang ikonekta ang isang device sa network ng hotel, sa halip na dumaan sa gateway ng SensorFlow.
Node Security
Ang aming mga sensor node ay kumokonekta lamang sa aming mga gateway sa pamamagitan ng aming proprietary protocol na tinatawag na AirLink. Dahil dito, sila ay ganap na hindi maabot at hindi matuklasan mula sa labas at samakatuwid ay hindi maaaring direktang atakehin. Ang aming mga node ay hindi nagsasalita ng anumang IP na nakabatay sa protocol at dahil dito, ay hindi direktang nakikipag-ugnayan sa imprastraktura ng network ng hotel. Ang kanilang mga kakayahan sa bandwidth ay lubhang limitado sa pamamagitan ng disenyo, na ginagawang hindi angkop para sa anumang pag-atake sa imprastraktura ng network ng hotel. Ito ay bunga ng paggamit ng LoRa vs WiFi o Bluetooth. Ang lahat ng komunikasyon ay nangyayari sa binary form, na ginagawang napakahirap ng mga pagtatangka ng reverse engineering ng aming protocol.
Mga Bunga Ng Pag-atake Sa Mga Node
1. (Minor) Epekto sa kaginhawahan ng bisita: Kung magagawa ng isang attacker na ikonekta ang isang rogue node o ganap na makontrol ang isang node, maaari siyang magpadala ng maling data ng occupancy na maaaring makaimpluwensya sa gawi ng FCU sa mga kwartong iyon. Maaari itong magdulot ng thermal discomfort sa mga bisita. Madaling mababawasan ang epekto sa pamamagitan ng pag-off sa SensorFlow Gateways o pag-blacklist sa node mula sa Gateway network.
2. (Minor) Pagkaantala o pag-deactivate ng automation: Kung ang isang attacker ay namamahala na i-deactivate o idiskonekta ang mga sensor node, ang automation ay madi-disable na humahantong sa pagkawala ng mga matitipid at pagkawala ng data.
Pag-install ng Rogue Node
Sa kasong ito, sinusubukan ng isang attacker na mag-install ng malisyosong node sa property.
Likelihood: Bihira
Dahil ang aming protocol ay pagmamay-ari at hindi na-publish, kailangan ng isang tao na kumpletuhin ang isang buong reverse engineering exercise ng aming wireless protocol upang subukang ikonekta ang isang rogue node sa SensorFlow system. Mangangailangan ito ng isang umaatake na nasa site sa loob ng ilang araw o linggo upang mangolekta ng sapat na impormasyon mula sa mga regular na komunikasyon upang magkaroon ng malayong pagkakataon na ma-decipher ang protocol.
Bukod pa rito, lahat ng aming mga node ay naglalaman ng isang natatanging numero ng id, na tinatawag na MAC address, na aming itinatala bago namin dalhin ang kagamitan sa site. Tatanggihan ng aming mga gateway ang anumang node na walang kinikilalang MAC address. Ang MAC address ng isang node ay ipinagpapalit lamang sa panahon ng paunang proseso ng koneksyon na ginagawang napakahirap para sa isang umaatake na maglunsad ng isang naka-target na pag-atake. Kung ang isang umaatake ay dumaan sa lahat ng pagsisikap na ito, ang tanging pinsala na maaari niyang makamit ay ang kontrolin ang mga FCU sa mga silid ng hotel nang hindi nakikita kung aling mga silid ang kanilang kinokontrol. Sa pamamagitan ng lahat ng pagsusumikap na ito, maaari lamang silang magdulot ng mga kaunting inis sa mga bisita. Kahit na sinubukan ng isang attacker na magdulot ng pinsala sa pamamagitan ng paggamit ng replay attack sa aming komunikasyon, kakailanganin nilang magkaroon ng detalyadong pag-unawa sa mga timing ng komunikasyon ng aming network na lubos na maglilimita sa tagumpay ng attack vector na ito.
Pag-atake sa pamamagitan ng Pag-upgrade ng Firmware Function
Ang aming mga sensor node ay na-upgrade nang malayuan. Pinalitaw ng aming mga gateway ang pag-upgrade na ito.
Likelihood: Bihira
Habang nagsasalita kami ng proprietary protocol sa pagitan ng mga sensor at ng aming mga gateway, kailangang kontrolin ng isang attacker ang aming mga gateway o magdala ng katumbas na hardware on-site. Pagkatapos noon, kailangan din nilang i-reverse engineer ang aming kumpletong protocol sa pag-upgrade ng firmware na magiging isang napaka sopistikadong pagsisikap sa engineering na may kaunting resulta.
Pag-jamming ng Network
Ang bawat wireless network ay mahina sa mga pag-atake ng network jamming. Kaya ang isang on-site attacker ay maaaring magtagumpay na idiskonekta ang ilang mga node sa pamamagitan ng pag-jamming sa mga frequency kung saan gumagana ang SensorFlow system. Walang magagawa upang maiwasan ito, gayunpaman, ang tanging resulta ay ang pag-deactivate ng automation at nagiging sanhi ng ilang pagkawala ng data.
Likelihood: Bihira
Mga Pisikal na Pag-atake Sa Mga Node
Ang lahat ng nasa itaas ay nangangailangan ng reverse engineering efforts upang maging matagumpay. Ang pinakamabilis na paraan ng paggawa nito ay ang pagtatangka na i-download ang firmware mula sa aming mga node at pagkatapos ay subukang i-decompile ito.
Likelihood: Bihira
Imposible ito habang ni-lock namin ang aming mga node pagkatapos ng programming, ibig sabihin, ang pagkonekta sa isang tool upang i-download ang firmware ay mangangailangan ng pag-unlock sa node na agad na bumubura sa firmware.