Gerbang
Gateway kami adalah tulang punggung infrastruktur SensorFlow. Tujuan utama mereka ada dua. Mereka berfungsi sebagai proxy bagi sensor kami untuk meneruskan data sensor yang direkam ke cloud serta meneruskan perintah ke sensor yang diterima dari dasbor. Kedua, mereka menampung mesin pengambilan keputusan kami yang bertugas mengendalikan peralatan yang diinstrumentasi berdasarkan informasi sensor yang terekam (misalnya tidak ada orang di dalam ruangan -> mematikan AC). Kami memilih pendekatan ini karena dua alasan utama:
1. Keamanan: Berkali-kali kita menemukan cerita di berita tentang perangkat Internet of Things (IOT) yang diserang oleh peretas. Kisah-kisah ini memiliki kesamaan: Vendor menghubungkannya langsung ke internet tetapi gagal menyadari bahwa terbatasnya kemampuan perangkat membuat mereka rentan terhadap serangan canggih dan/atau mereka mengambil jalan pintas dalam penerapan lapisan keamanan perangkat IOT. Karena alasan inilah, kami memilih untuk melindungi perangkat kami di belakang gateway kami untuk membatasi permukaan serangan dan memungkinkan semua komunikasi melalui perangkat yang jauh lebih canggih yang dapat dengan mudah menerapkan protokol keamanan canggih.
2. Kinerja sistem: Internet of Things seharusnya membuat bangunan menjadi lebih cerdas, namun kita sering menemukan bahwa pemasok terlalu mengandalkan cloud dan konektivitas internet yang unggul. Untuk menghindari gedung cerdas berubah menjadi gedung bodoh segera setelah internet terputus, kami merancang sistem kami sedemikian rupa sehingga semua keputusan otomatisasi dibuat di gateway dan bukan di cloud. Oleh karena itu, bahkan tanpa konektivitas internet, semua peralatan akan tetap dipantau dan diotomatisasi, data yang direkam akan disimpan di gateway dan dialirkan kembali ke cloud SensorFlow setelah internet kembali online.
Sensor IOT SensorFlow berkomunikasi secara eksklusif dengan gateway SensorFlow menggunakan protokol Airlink milik kami. Komunikasi ini terjadi pada pita subGHz, biasanya antara 920-925 MHz tergantung negaranya sehingga tidak mengganggu infrastruktur Bluetooth atau WiFi yang ada. Setiap gateway dapat mendukung hingga 960 Node sensor, namun dalam praktiknya, kami menemukan bahwa kami biasanya menghubungkan tidak lebih dari 300 node per gateway, bergantung pada jangkauan nirkabel yang dapat dicapai, karena tata letak dan material bangunan. Biasanya kami memasang tidak lebih dari 15 Gateway per situs, dengan rata-rata jumlah gateway yang terpasang berjumlah sekitar 7-8.
Persyaratan Gerbang
Gateway kami bergantung pada infrastruktur internet situs dan dapat dihubungkan melalui WiFi atau ethernet, dengan ethernet menjadi pilihan yang lebih disukai. Kami tidak membuka port apa pun ke luar dan semua komunikasi keluar dimulai menggunakan permintaan normal atau koneksi VPN. Kami tidak menggunakan infrastruktur proxy apa pun. Minimalkan tambahan permukaan serangan dapat dicapai jika klien menyiapkan subjaringan agar gateway kami dapat terhubung. Dengan ini, kita dapat mengisolasi komunikasi kita dari jaringan hotel. Infrastruktur firewall apa pun harus diterapkan oleh jaringan klien yang disediakan dan tidak akan memengaruhi Gateway kami karena semua komunikasi bersifat keluar. Gateway memerlukan port berikut agar terbuka di firewall untuk komunikasi keluar:
Persyaratan Bandwidth
Persyaratan bandwidth untuk gateway sangat rendah, karena gateway tersebut terutama meneruskan data IOT dalam bentuk pesan json singkat serta pesan log untuk tujuan diagnostik. Total volume unggahan Gateway adalah sekitar 2MB per jam, tergantung instalasi sebenarnya. Aliran data hilir akan diabaikan dalam pengoperasian biasa dan tidak akan melebihi beberapa kilo byte per hari.
Persyaratan Protokol
Gateway berinteraksi dengan 3 layanan eksternal:
1. Layanan Web Amazon (AWS)- Menjalankan semua infrastruktur cloud yang membentuk analitik SensorFlow dan backend dasbor. Semua interaksi diamankan menggunakan AWS Cognito, layanan yang menyediakan autentikasi, otorisasi, dan manajemen pengguna. (https://aws.amazon.com/cognito)
2. Balena.io-https://Balena.io/
Balena digunakan sebagai manajemen armada untuk gerbang. Ini melaporkan status gateway dan mengelola pembaruan/tambalan apa pun ke gateway. BalenaOS adalah sistem operasi dasar gateway. Aplikasi utama berjalan dalam wadah Docker di OS. Penjelasan rinci mengenai penerapan keamanan terkait Balena dapat ditemukan di sini:https://www.balena.io/docs/learn/welcome/security/
Komunikasi Balena: 1. VPN untuk melaporkan uptime sistem dan pengiriman log 2. Layanan polling untuk memeriksa apakah ada pembaruan
1. Jejak kertas-https://papertrailapp.com
Data log dari gateway dikirim ke papertrail untuk manajemen log. Ini digunakan untuk memudahkan pembacaan log untuk masalah pemecahan masalah apa pun. Log dapat dicari selama 2 minggu dan diarsipkan selama satu tahun. (Penyimpanan yang mendasarinya adalah AWS S3).
Gambar 1merinci komponen yang berkomunikasi di tempat dan bagaimana mereka berinteraksi.
Gambar 1: Ikhtisar jaringan yang merinci saluran komunikasi antara node, gateway, dan layanan eksternal kami.
Dasbor
Dasbor kami memungkinkan klien melihat data yang direkam serta mengontrol sistem AC yang diinstrumentasi. Itu dapat diakses dari browser web apa pun dan diotorisasi melalui login nama pengguna dan kata sandi. Itu dihosting di Google Firebase dan terdiri dari kombinasi html, javascript, dan berbagai gambar. Semua komunikasi dilakukan dengan AWS cloud melalui TLS.
Otentikasi dan otorisasi untuk dasbor juga menggunakan layanan AWS cognito (https://aws.amazon.com/cognito). Kami akan membuat akun pengguna berdasarkan permintaan klien untuk memberikan hanya staf yang relevan akses ke dasbor.
Tugas Penjaga AWS (https://aws.amazon.com/guardduty/) digunakan untuk memantau akun cloud untuk aktivitas yang tidak biasa atau mencurigakan.
Penyimpanan data
Data yang dikirim ke AWS cloud disimpan di DynamoDB (database NoSql) untuk tujuan layanan aplikasi. Data juga disimpan dalam Database deret waktu berkinerja tinggi (ekstensi Postgres + TimeScaleDB) untuk tujuan ilmu data. Kedua database dihosting oleh AWS. DynamoDB berjalan sebagai layanan terkelola dari AWS dan basis data rangkaian waktu kami dihosting pada instans AWS EC2.
Dukungan dan Pemeliharaan
Kami bercita-cita untuk memberikan layanan end-to-end kepada klien kami dan memiliki dukungan khusus yang siaga untuk mengatasi masalah sistem melalui kemampuan pemeliharaan jarak jauh kami. Ini termasuk kemampuan untuk memperbarui firmware node sensor menggunakan proses pembaruan over-the-air antara gateway dan sensor. Kami menggunakan ini untuk memberikan pembaruan keamanan, perbaikan bug, atau fitur baru ke sensor kami. Selain itu, kami memiliki kemampuan untuk memperbarui perangkat lunak gateway kami dari jarak jauh serta memulai, memulai ulang, dan mematikan gateway menggunakan layanan balena.io. Dalam kasus yang jarang terjadi, jika semua tindakan jarak jauh gagal, kami akan meminta bantuan teknisi hotel di lokasi. Ini sebagian besar untuk penggantian baterai atau pertukaran perangkat keras yang rusak atau rusak. Jika tugas yang ada terlalu rumit untuk dilaksanakan oleh teknisi di lokasi, kami akan mengirimkan salah satu manajer proyek instalasi khusus kami untuk melakukan pekerjaan yang diperlukan. Hal ini akan dievaluasi berdasarkan kasus per kasus.
Keamanan Gerbang
Hanya gateway SensorFlow yang terhubung langsung ke jaringan klien, sedangkan node sensor hanya akan berkomunikasi dengan gateway kami dan tidak pernah dengan internet secara langsung. Oleh karena itu, hanya gateway yang berpotensi rentan terhadap serangan siber jarak jauh melalui internet. Kami biasanya menghubungkan gateway kami ke jaringan yang sama dengan yang terhubung dengan tamu hotel. Artinya, dari sudut pandang desain jaringan, risiko keamanan yang terkait dengan gateway kami dapat dianggap sama dengan risiko perangkat apa pun yang mungkin dihubungkan oleh tamu ke jaringan hotel. Sekalipun penyerang mendapatkan akses atau kendali penuh atas gateway SensorFlow, konsekuensinya minimal dan terisolasi pada gateway yang bersangkutan.
Konsekuensi Serangan Gateway
1. (Kecil) Gangguan atau penonaktifan otomatisasi: Hal ini akan menyebabkan hilangnya tabungan dan hilangnya sejumlah data di ruangan yang dilayani oleh gateway ini. Hal ini akan terjadi jika penyerang menghentikan aplikasi SensorFlow yang berjalan di gateway.
2. (Minor) Dampak terhadap kenyamanan tamu: Hal ini dapat terjadi jika penyerang berhasil mematikan FCU setelah mendapatkan akses ke gateway. Namun hal ini sangat tidak mungkin terjadi karena penyerang harus sepenuhnya merekayasa balik protokol rahasia milik kami agar dapat mengirimkan perintah yang valid ke perangkat kami yang merupakan upaya rekayasa yang serius. Kerusakan juga dapat dengan mudah diatasi dengan mematikan gerbang yang terpengaruh, yang kemudian termostat kami akan melanjutkan pengoperasian offline normal. Tidak mungkin menyandera infrastruktur secara permanen melalui vektor serangan ini.
3. (Kecil) Akses ke jaringan hotel: Penyerang yang mendapatkan kendali atas gateway dapat menggunakan gateway untuk mendengarkan lalu lintas jaringan atau mengganggu jaringan dengan gangguan. Konsekuensi dari skenario ini terutama bergantung pada pengaturan jaringan hotel. Kami biasanya menyarankan agar gateway dihubungkan ke subnetnya yang terisolasi atau ke jaringan yang sama yang terhubung dengan tamu hotel, dengan hak istimewa dan batasan yang sama. Oleh karena itu, pengaturan jaringan yang dirancang dengan baik tidak akan memungkinkan perangkat di jaringan gateway atau jaringan tamu mengakses infrastruktur jaringan hotel yang penting.
Serangan Jarak Jauh Langsung pada Port Gateway Terbuka
Skenario ini menjelaskan penyerang mencoba mendapatkan akses jarak jauh ke gateway melalui port terbuka.
Kemungkinan: Tidak mungkin
Vektor serangan ini dianggap mustahil karena gateway tidak mendengarkan port apa pun di luar dan komunikasi apa pun dimulai keluar dari gateway. Perilaku ini diwarisi dari BalenaOS, sistem operasi yang menjadi basis perangkat lunak gateway. Penjelasan rinci tentang implementasi keamanan terkait Balena dan cara mereka mengelola komunikasi dan otorisasi dapat ditemukan di sini:
Kami menjalankan aplikasi SensorFlow di dalam wadah buruh pelabuhan di atas BalenaOS, yang berinteraksi dengan infrastruktur cloud SensorFlow. Semua komunikasi dengan Cloud kami sekali lagi bersifat outbound dan tidak ada port yang dibuka sehingga aplikasi kami tidak menambahkan permukaan serangan tambahan ke gateway.
Karena hal di atas, mustahil bagi penyerang untuk menemukan dan menyerang gateway kami dari jarak jauh tanpa melanggar infrastruktur jaringan klien terlebih dahulu. Hal ini terutama berlaku jika gateway juga dilindungi oleh firewall yang membatasi akses ke jaringan klien. Bahkan jika mereka berhasil menembus firewall, mereka tetap tidak akan menemukan port terbuka untuk menyerang gateway kami.
Manusia di Tengah Menyerang Gerbang
Satu-satunya cara untuk menyerang gateway adalah dengan menyamar sebagai awan Balena atau awan SensorFlow. Penyerang yang berhasil dapat mencoba mengirimkan perintah ke termostat yang terhubung atau menukar firmware gateway dengan firmware mereka sendiri.
Kemungkinan: Jarang
Kami menganggap skenario serangan ini sangat kecil kemungkinannya untuk berhasil karena semua API kami diamankan melalui enkripsi HTTPS TLS standar serta otorisasi dan autentikasi berbasis sertifikat. Hal ini berlaku untuk titik akhir layanan yang dihadirkan oleh Balena untuk kontrol dan pemeliharaan jarak jauh serta semua API cloud SensorFlow yang diamankan oleh layanan AWS Cognito. Oleh karena itu, penyerang harus berhasil mencuri sertifikat root SensorFlow atau Balena agar berhasil dengan vektor serangan ini.
Serangan Fisik Pada Gerbang
Jika penyerang mendapatkan akses fisik ke gateway, mereka dapat mencoba mengganti firmware gateway kami dengan mengganti kartu SD yang menyimpan sistem operasi dan oleh karena itu, membuat perangkat di jaringan hotel di bawah kendali mereka dan kemungkinan besar masuk daftar putih untuk terhubung. tanpa harus melalui captive portal.
Kemungkinan: Jarang
Karena ini adalah serangan di lokasi yang memerlukan pengetahuan teknis, kami menganggap kemungkinan terjadinya serangan ini sangat jarang terjadi. Terutama mengingat keterbatasan infrastruktur jaringan yang disebutkan di atas yang seharusnya berlaku untuk semua perangkat di gateway atau jaringan tamu. Untuk melakukan serangan semacam ini, akan lebih mudah bagi penyerang untuk langsung menghubungkan perangkat ke jaringan hotel, dibandingkan melalui gateway SensorFlow.
Keamanan Node
Node sensor kami hanya terhubung ke gateway kami melalui protokol milik kami yang disebut AirLink. Oleh karena itu, mereka sama sekali tidak dapat dijangkau dan ditemukan dari luar sehingga tidak dapat diserang secara langsung. Node kami tidak menggunakan protokol berbasis IP apa pun dan oleh karena itu, tidak dapat berinteraksi langsung dengan infrastruktur jaringan hotel. Kemampuan bandwidth mereka juga sangat terbatas, sehingga tidak cocok untuk serangan apa pun terhadap infrastruktur jaringan hotel. Ini adalah konsekuensi penggunaan LoRa vs WiFi atau Bluetooth. Semua komunikasi terjadi dalam bentuk biner, membuat upaya rekayasa balik protokol kami menjadi sangat sulit.
Konsekuensi Serangan Pada Node
1. (Kecil) Dampak pada kenyamanan tamu: Jika penyerang berhasil menghubungkan node jahat atau sepenuhnya mengambil kendali atas sebuah node, dia dapat mengirimkan data hunian palsu yang kemudian dapat memengaruhi perilaku FCU di ruangan tersebut. Hal ini dapat menyebabkan ketidaknyamanan termal bagi tamu. Dampaknya dapat dengan mudah dikurangi dengan menonaktifkan SensorFlow Gateway atau memasukkan node ke dalam daftar hitam dari jaringan Gateway.
2. (Kecil) Gangguan atau penonaktifan otomatisasi: Jika penyerang berhasil menonaktifkan atau memutuskan sambungan node sensor, otomatisasi akan dinonaktifkan yang menyebabkan hilangnya simpanan dan hilangnya data.
Memasang Node Nakal
Dalam kasus ini, penyerang mencoba memasang node jahat di properti.
Kemungkinan: Jarang
Karena protokol kami adalah hak milik dan tidak dipublikasikan, seseorang perlu menyelesaikan latihan rekayasa balik sepenuhnya pada protokol nirkabel kami untuk mencoba menghubungkan node jahat ke sistem SensorFlow. Hal ini mengharuskan penyerang berada di lokasi selama beberapa hari atau minggu untuk mengumpulkan informasi yang cukup dari komunikasi reguler agar memiliki peluang kecil untuk menguraikan protokol.
Selain itu, semua node kami berisi nomor id unik, yang disebut alamat MAC, yang kami catat sebelum kami membawa peralatan ke lokasi. Gateway kami akan menolak node mana pun yang tidak memiliki alamat MAC yang dikenali. Alamat MAC suatu node hanya dipertukarkan selama proses koneksi awal sehingga sangat sulit bagi penyerang untuk melancarkan serangan yang ditargetkan. Jika penyerang melakukan semua upaya ini, satu-satunya kerusakan yang dapat ia peroleh adalah mengendalikan FCU di kamar hotel tanpa mengetahui kamar mana yang mereka kendalikan. Melalui semua upaya ini, mereka hanya dapat menimbulkan gangguan kecil pada para tamu. Bahkan jika penyerang mencoba menyebabkan kerusakan dengan menggunakan serangan replay pada komunikasi kami, mereka perlu mendapatkan pemahaman rinci tentang waktu komunikasi jaringan kami yang akan sangat membatasi keberhasilan vektor serangan ini.
Serangan Melalui Fungsi Peningkatan Firmware
Node sensor kami ditingkatkan dari jarak jauh. Gateway kami memicu peningkatan ini.
Kemungkinan: Jarang
Karena kita berbicara tentang protokol kepemilikan antara sensor dan gateway kami, penyerang harus mengambil kendali gateway kami atau membawa perangkat keras yang setara ke lokasi. Setelah itu, mereka juga harus merekayasa balik protokol peningkatan firmware lengkap kami yang akan menjadi upaya rekayasa yang sangat canggih dengan hasil minimal.
Gangguan Jaringan
Setiap jaringan nirkabel rentan terhadap serangan gangguan jaringan. Jadi penyerang di lokasi dapat berhasil memutuskan sambungan beberapa node dengan mengganggu frekuensi yang digunakan sistem SensorFlow. Tidak ada yang dapat dilakukan untuk mencegah hal ini, namun satu-satunya akibat adalah menonaktifkan otomatisasi dan menyebabkan hilangnya sejumlah data.
Kemungkinan: Jarang
Serangan Fisik Pada Node
Semua hal di atas memerlukan upaya rekayasa balik agar berhasil. Cara tercepat untuk melakukan hal ini adalah dengan mencoba mengunduh firmware dari node kami dan kemudian mencoba mendekompilasinya.
Kemungkinan: Jarang
Hal ini tidak mungkin dilakukan karena kami mengunci node kami setelah pemrograman, artinya menghubungkan alat untuk mengunduh firmware akan memerlukan pembukaan kunci node yang akan segera menghapus firmware.