Mobile আর IoT নিরাপত্তা — app permission, firmware আর device hardening

১ · ফোন এখন মানিব্যাগ, পরিচয়পত্র আর চাবির গোছা

আগে পকেটমার মানিব্যাগ নিলে ক্ষতি হতো ভেতরের টাকাটুকু। এখন ফোনের ভেতরে থাকে মোবাইল ব্যাংকিং, OTP আসার SMS, ইমেইল, ছবি, অফিসের chat আর passkey. একটি যন্ত্রই আপনার ব্যাংকের কার্ড, পরিচয়পত্র আর বাড়ির চাবির কাজ করে।

এর মধ্যে Overlay মানে অন্য app-এর ওপরে একটি নকল পর্দা বসানো। আর accessibility service হলো প্রতিবন্ধী ব্যবহারকারীর জন্য তৈরি সুবিধা, যা পর্দার লেখা পড়তে আর বোতাম চাপতে পারে। সুবিধাটি খুবই দরকারি, কিন্তু ভুল হাতে গেলে সেই ক্ষমতাই বিপজ্জনক। SMS OTP আর SIM swap নিয়ে পুরো আলোচনা আছে পর্ব ১৬ · MFA আর passkey-তে; SMS OTP-র ওপর ভরসা কমানোই এখানে মূল শিক্ষা।

২ · Android আর iOS: ফোনের ভেতরের দেয়াল

আধুনিক ফোনের নকশা একটি কথা ধরে নেয়: কোনো app-কে পুরোপুরি বিশ্বাস করা যাবে না। তাই একটি অফিসের ভবনের মতো ভাগ করা হয়। প্রতিটি কোম্পানির আলাদা ফ্লোর, দারোয়ান পরিচয়পত্র দেখে ঢুকতে দেন, আর ব্যাংকের লকার থাকে আলাদা শক্ত ঘরে।

একটি সূক্ষ্ম কথা: Code signing বলে “এই app কে সই করেছে, আর সইয়ের পর বদলায়নি।” বলে না “এই app ভালো।” একজন প্রতারকও নিজের key দিয়ে সই করতে পারে। Android-এ সই মূলত এটি নিশ্চিত করে যে update একই প্রকাশকের কাছ থেকে এসেছে। স্বাক্ষরের ভিত্তি আছে পর্ব ১১-এ, আর boot-এর সাধারণ ধারণা আছে Operating Systems কোর্সের boot পর্বে।

Permission তালিকা নিজে পড়ুন

অনুমতি তিন স্তরে ভাবুন। Internet-এর মতো সাধারণ অনুমতি install-এর সময়ই পাওয়া যায়। Camera, SMS, contacts-এর মতো বিপজ্জনক অনুমতি চলার সময় জিজ্ঞাসা করে। আর overlay, accessibility, “অজানা app install” হলো বিশেষ অনুমতি, যা Settings-এ আলাদা করে চালু করতে হয়। প্রশ্ন একটাই: এই কাজের জন্য কি এই অনুমতি সত্যিই লাগে? নিচের খেলনা report ঠিক এই প্রশ্নটি করে। এখানে needs তালিকাটি মানুষের বিচার, Android-এর দেওয়া নয়।

// Toy permission risk report. Manifests are in-memory lists; no real app is read.
const WEIGHT = { CAMERA: 15, ACCESS_FINE_LOCATION: 15, RECORD_AUDIO: 20, READ_CONTACTS: 20,
  READ_SMS: 30, RECEIVE_SMS: 30, SYSTEM_ALERT_WINDOW: 30, BIND_ACCESSIBILITY_SERVICE: 40,
  REQUEST_INSTALL_PACKAGES: 25, INTERNET: 0 };
const COMBOS = [
  [["READ_SMS", "INTERNET"], "SMS and OTP text could leave the phone"],
  [["READ_CONTACTS", "INTERNET"], "contact list could leave the phone"],
  [["BIND_ACCESSIBILITY_SERVICE", "SYSTEM_ALERT_WINDOW"], "can read and cover the screen"],
];

function report(app) {
  const extra = app.perms.filter(p => !app.needs.includes(p));
  let score = extra.reduce((sum, p) => sum + WEIGHT[p], 0);
  const hits = COMBOS.filter(([set]) =>
    set.every(p => app.perms.includes(p)) && set.some(p => extra.includes(p)));
  score += hits.length * 25;
  if (app.source !== "store") score += 20;
  const level = score >= 80 ? "DO NOT INSTALL" : score >= 30 ? "REVIEW" : "OK";
  console.log(app.name + " [" + app.source + "]: score " + score + " -> " + level);
  console.log("  not needed: " + (extra.join(", ") || "none"));
  for (const [, why] of hits) console.log("  combo: " + why);
}

report({ name: "Bus Map", source: "store", needs: ["INTERNET", "ACCESS_FINE_LOCATION"],
  perms: ["INTERNET", "ACCESS_FINE_LOCATION"] });
report({ name: "Torch Lite", source: "store", needs: ["CAMERA"],
  perms: ["CAMERA", "INTERNET", "READ_CONTACTS"] });
report({ name: "Quick Loan (fake)", source: "link", needs: ["INTERNET", "CAMERA"],
  perms: ["INTERNET", "CAMERA", "READ_SMS", "READ_CONTACTS", "SYSTEM_ALERT_WINDOW",
          "BIND_ACCESSIBILITY_SERVICE"] });

৩ · নকল app, sideloading আর rooted ফোন

Sideloading মানে অফিসিয়াল store-এর বাইরে থেকে, যেমন কোনো link বা শেয়ার করা ফাইল থেকে app install করা। Android-এ এটি বৈধ সুবিধা, অনেক প্রতিষ্ঠান নিজেদের app এভাবে দেয়। ঝুঁকি হলো, store-এর যাচাই এখানে থাকে না।

বাংলাদেশের প্রেক্ষিতে দুটি ধরন মাথায় রাখুন। এক, দ্রুত ঋণের প্রলোভন দেওয়া app. দুই, মোবাইল ব্যাংকিং বা ব্যাংকের চেহারা নকল করা app. বিভিন্ন দেশে এমন প্রতারণা নিয়ে সতর্কতা প্রকাশিত হয়েছে; এখানেও একই ঝুঁকি আছে ধরে নিন। এই পর্বে কোনো নির্দিষ্ট সেবা বা কোম্পানির কথা বলা হচ্ছে না। মূল নিয়ম সরল: মোবাইল ব্যাংকিং app নেবেন শুধু অফিসিয়াল store বা সেবাদাতার অফিসিয়াল ওয়েবসাইটের link থেকে। PIN আর OTP কাউকে জানাবেন না। যে app নিয়ে সন্দেহ আছে, তাতে কখনো লিখবেন না।

নিচে একটি কাল্পনিক ঘটনায় দেখুন, নকল app-এর পথে কোন ধাপে কে থামাতে পারত। এটি ধারণার স্তরে, প্রতিরক্ষা বোঝার জন্য।

Rooted বা jailbroken ফোন

Rooting (Android) আর jailbreak (iOS) মানে নিজের ফোনে নিরাপত্তার সীমা সরিয়ে সর্বোচ্চ অধিকার নেওয়া। এতে sandbox আর verified boot-এর ভরসা দুর্বল হয়। Update বন্ধ হতে পারে, আর কোনো ক্ষতিকর app সবচেয়ে বড় ক্ষমতা পেয়ে যেতে পারে। সাধারণ ব্যবহারের ফোনে এটি এড়ানোই ভালো। সন্দেহজনক দ্বিতীয় হাতের ফোন কিনলে OS পুরোপুরি নতুন করে বসিয়ে যাচাই করুন, আর boot-এ সতর্কবার্তা আসে কি না দেখুন।

Bank app-এর দিক থেকে কী করা যায়? Server device attestation চাইতে পারে, যেমন Android-এ Play Integrity API বা iOS-এ App Attest. এগুলো hardware-সমর্থিত ঝুঁকির সংকেত দেয়। তবে কোনো client-side যাচাই নিখুঁত নয়। তাই এটি একটি সংকেত হিসেবে ব্যবহার করুন, একমাত্র প্রতিরক্ষা হিসেবে নয়।

৪ · OWASP Mobile Top 10, নিরাপদ কোডিং আর device policy

OWASP Mobile Top 10-এর বর্তমান সংস্করণ ২০২৪ সালে চূড়ান্ত হয়েছে (OWASP-এর সাইটে ঝুঁকির পাতাটি “2023-risks” ঠিকানায় আছে)। পাশাপাশি OWASP-এর MASVS মান আর MASTG পরীক্ষা-নির্দেশিকা যাচাইয়ের কাজে লাগে। নিচের তারকা-চিহ্নিত সারিগুলো এই পর্বের মূল ফোকাস।

প্রথম নিয়ম: App ব্যবহারকারীর হাতে থাকে, তাই app-এর কোড আর ফাইল আপনার নিয়ন্ত্রণের বাইরে। Client-কে কখনো পুরো বিশ্বাস করবেন না। “Premium user কি না”, “এই লেনদেনের অনুমতি আছে কি না”, এসব যাচাই হবে server-এ। ওপরের নিয়মটি পর্ব ১৯-এর নীতির মোবাইল রূপ।

// অনিরাপদ নকশা: secret app-এর ভেতরে থাকলে যে কেউ বের করতে পারে
const val PAYMENT_API_SECRET = "example-token"
prefs.edit().putString("session", "<session-token>").apply()   // plain ফাইলে token

// নিরাপদ নকশা
// ১. Payment secret থাকবে শুধু server-এ; app নিজের session দিয়ে server-কে ডাকবে
// ২. Session token হবে স্বল্পমেয়াদি, Keystore-এর key দিয়ে encrypt করে রাখা
// ৩. Logout হলে server-এও token বাতিল

Key তৈরি করার সময় key-কে Keystore-এর ভেতরেই থাকতে বলুন। নিচের Kotlin উদাহরণে AES key তৈরি হয়, কিন্তু তার মান app কখনো দেখতে পায় না। প্রতিটি ব্যবহারে ফোনের lock-যাচাই লাগে। iOS-এ সমতুল্য কাজ Keychain করে, যেখানে WhenUnlockedThisDeviceOnly ধরনের নিয়ম দিয়ে নির্দিষ্ট করা যায় যে তথ্যটি অন্য যন্ত্রে backup হয়ে যাবে না।

val spec = KeyGenParameterSpec.Builder(
        "session_wrap_key",
        KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT)
    .setBlockModes(KeyProperties.BLOCK_MODE_GCM)
    .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
    .setKeySize(256)
    .setUserAuthenticationRequired(true)   // ব্যবহারের আগে lock-যাচাই
    .build()
val generator = KeyGenerator.getInstance(KeyProperties.KEY_ALGORITHM_AES, "AndroidKeyStore")
generator.init(spec)
generator.generateKey()                    // key বাইরে আসে না

TLS আর certificate pinning-এর লাভ-ক্ষতি

আগে সাধারণ নিয়ম: সব traffic TLS-এ, আর certificate যাচাই কখনো বন্ধ নয়। Debug-এর জন্য সব certificate মেনে নেওয়ার কোড লিখে সেটি release-এ চলে যাওয়া একটি পরিচিত ভুল। Android 9 বা নতুন version target করা app-এ cleartext traffic ডিফল্টভাবে বন্ধ থাকে, iOS-এ App Transport Security একই কাজে সাহায্য করে। TLS-এর বিস্তারিত আছে পর্ব ১২-তে।

Certificate pinning মানে app শুধু আগে থেকে ঠিক করা key বা certificate মানবে। ধরুন ব্যাংকের লকারে শুধু একজন পরিচিত কর্মকর্তার সই চলে। এতে ভুয়া certificate-এর ঝুঁকি কমে। কিন্তু সেই কর্মকর্তা বদলি হলে? লকারই খোলা যায় না। Pin বদলের পর পুরোনো app server-এর সাথে কথা বলতে পারে না, আর সবার ফোনে নতুন update পৌঁছাতে সময় লাগে।

এ কারণে Android-এর developer নির্দেশিকা সাধারণ app-এর জন্য pinning সুপারিশ করে না। একান্ত দরকার হলে একাধিক backup pin আর স্বল্প মেয়াদ রাখতে বলে। উচ্চ-ঝুঁকির app-এর বেলায় এই বিচার আলাদা হতে পারে। মনে রাখুন, pinning ব্যবহারকারীর নিজের ফোনের বিরুদ্ধে সুরক্ষা নয়; এটি মূলত network-পথের ভুয়া certificate-এর বিরুদ্ধে সুরক্ষা।

<network-security-config>
  <base-config cleartextTrafficPermitted="false" />
  <domain-config>
    <domain includeSubdomains="true">api.example.com</domain>
    <pin-set expiration="2027-06-30">
      <!-- মান দুটি নকল; আসলে public key-র SHA-256, Base64-এ -->
      <pin digest="SHA-256">example-current-key-pin=</pin>
      <pin digest="SHA-256">example-backup-key-pin=</pin>
    </pin-set>
  </domain-config>
</network-security-config>

প্রতিষ্ঠানের ফোন: device policy

অফিসের ইমেইল ব্যক্তিগত ফোনে এলে ফোনটি প্রতিষ্ঠানের ঝুঁকিও হয়ে যায়। একে বলে BYOD, মানে নিজের যন্ত্র কাজে আনা। এখানে MDM বা mobile device management system ফোনে নিয়ম প্রয়োগ করে। পুরো ধারণা আছে পর্ব ২৯ · Endpoint নিরাপত্তা-য়; মোবাইলের জন্য NIST SP 800-124 Rev. 2 (২০২৩) একটি ভালো নির্দেশিকা।

• ন্যূনতম শর্ত: Screen lock, device encryption, সমর্থিত OS version, rooted ফোন নয়।
• আলাদা ঘর: Work profile বা managed app অফিসের ডেটা আলাদা রাখে। প্রতিষ্ঠান ব্যক্তিগত ছবি বা বার্তায় হাত দেয় না।
• হারালে: লিখিত ধাপ থাকুক: ফোন হারালে কাকে জানাবেন, কত দ্রুত account সরানো হবে, remote wipe কে করবেন।
• সম্মতি আর গোপনীয়তা: ব্যক্তিগত ফোনে প্রতিষ্ঠান কী দেখবে, তা লিখিতভাবে জানান। অপ্রয়োজনীয় নজরদারি এড়ান। পরে পর্ব ৭০-এ privacy আলোচনা আসবে।
• Detection: Compliance report, নতুন device-এর login, অস্বাভাবিক স্থান থেকে access নজরে রাখুন। মোবাইল লগইনও authentication-এর সাধারণ নিয়মে পড়ে।

৫ · IoT কেন এত দুর্বল

ফোনে প্রতি মাসে update আসে। কিন্তু দোকানের কোণের CCTV camera? সেটি দশ বছর দেয়ালে ঝুলে থাকে, আর কেউ মনেও রাখে না। IoT যন্ত্রের দুর্বলতা মূলত ব্যবসার কারণে তৈরি:

একটি হিসাব। ৬ অঙ্কের সংখ্যার default PIN-এ সম্ভাবনা 10⁶, মানে প্রায় ১৯.৯ bit. ছোট হাতের অক্ষর আর সংখ্যা মিলিয়ে ৮ ঘরের random password-এ 36⁸ = 2,821,109,907,456, মানে প্রায় ৪১.৪ bit, প্রায় ২৮ লাখ গুণ বড়। কিন্তু আসল পার্থক্য এখানে নয়। সবার password এক হলে ১০,০০০ যন্ত্রের জন্য খুঁজতে হয় একটিই। Unique হলে একটি ফাঁস হলে ক্ষতি একটি যন্ত্রে থামে, ১০,০০০ থেকে ১-এ নেমে আসে। আর আয়ুর হিসাব: যন্ত্র ১০ বছর, support ২ বছর হলে (১০ − ২) ÷ ১০ = ৮০% সময় যন্ত্রটি security update ছাড়া চলবে।

OWASP IoT Top 10-এর সর্বশেষ প্রকাশিত সংস্করণ ২০১৮ সালের। পুরোনো হলেও তালিকাটি আজও প্রাসঙ্গিক; ২০২৬ সালের অক্টোবরে প্রকল্পের পাতায় নতুন সংস্করণের ঘোষণা পাওয়া যায়নি।

মান আর নিয়ম কী বলে

• ETSI EN 303 645 (সর্বশেষ V3.1.3, ২০২৪): consumer IoT-র ভিত্তি মান। ১৩টি ভাগে নিয়ম আছে। প্রথমটিই “No universal default passwords”: password থাকলে তা প্রতি যন্ত্রে unique বা ব্যবহারকারীর ঠিক করা হবে। আরও আছে vulnerability report গ্রহণের প্রকাশিত নীতি আর ঘোষিত support period.
• NIST IR 8259 (Rev. 1 চূড়ান্ত এপ্রিল ২০২৬): প্রস্তুতকারকের জন্য বাজারে আনার আগে ও পরের করণীয়। সহযোগী IR 8259A যন্ত্রের প্রযুক্তিগত ভিত্তি-সক্ষমতা বলে। এগুলো স্বেচ্ছায় মানার নির্দেশিকা।
• আইন: UK-র PSTI শাসন (২৯ এপ্রিল ২০২৪ থেকে) দুর্বল default password নিষিদ্ধ করে আর update-এর মেয়াদ জানাতে বলে। EU-র Cyber Resilience Act (Regulation 2024/2847) ধাপে ধাপে কার্যকর হচ্ছে: reporting দায় ১১ সেপ্টেম্বর ২০২৬ থেকে, মূল দায় ১১ ডিসেম্বর ২০২৭ থেকে। এগুলো অন্য দেশের নিয়ম; বাংলাদেশে বিক্রি হওয়া যন্ত্রে নিজে থেকে প্রযোজ্য ধরে নেবেন না।

নিজের প্রতিষ্ঠানের যন্ত্রের হিসাব না থাকলে কিছুই শুরু করা যায় না। Asset inventory থেকেই শুরু। নিচের খেলনা audit একটি কাল্পনিক অফিসের তালিকা দেখে অগ্রাধিকার ঠিক করে। কোনো যন্ত্রে কোনো সংযোগ করে না।

// Toy IoT fleet audit of a fictional office. In-memory inventory, nothing is contacted.
const FLEET = [
  { id: "cam-gate",   type: "CCTV",    defaultPw: true,  fwDays: 900, exposed: true,  eol: false, zone: "office" },
  { id: "nvr-1",      type: "NVR",     defaultPw: false, fwDays: 500, exposed: true,  eol: false, zone: "office" },
  { id: "cam-store",  type: "CCTV",    defaultPw: false, fwDays: 60,  exposed: false, eol: false, zone: "iot" },
  { id: "printer-2",  type: "Printer", defaultPw: true,  fwDays: 700, exposed: false, eol: false, zone: "office" },
  { id: "tv-lobby",   type: "Smart TV",defaultPw: false, fwDays: 1500,exposed: false, eol: true,  zone: "guest" },
  { id: "door-lock",  type: "Lock",    defaultPw: false, fwDays: 2000,exposed: false, eol: true,  zone: "office" },
];

function assess(d) {
  const why = [];
  let score = 0;
  const add = (hit, pts, label) => { if (hit) { score += pts; why.push(label + " +" + pts); } };
  add(d.defaultPw, 40, "default password");
  add(d.exposed, 30, "reachable from internet");
  add(d.fwDays > 365, 15, "firmware over 1 year");
  add(d.eol, 25, "end of life");
  add(d.zone === "office", 10, "not isolated");
  // Toxic pairs: internet exposure plus an easy way in goes straight to the top.
  if (d.exposed && (d.defaultPw || d.fwDays > 365)) score = Math.max(score, 100);
  const action = score >= 80 ? "TODAY" : score >= 40 ? "THIS MONTH" : "ROUTINE";
  return { ...d, score, why, action };
}

const ranked = FLEET.map(assess).sort((a, b) => b.score - a.score);
for (const d of ranked) {
  console.log(String(d.score).padStart(3) + "  " + d.action.padEnd(11) + d.id);
  if (d.why.length) console.log("     " + d.why.join(", "));
}
const count = a => ranked.filter(d => d.action === a).length;
console.log("TODAY=" + count("TODAY") + " THIS MONTH=" + count("THIS MONTH") + " ROUTINE=" + count("ROUTINE"));

৬ · Secure boot, signed firmware আর unique credential

পোস্ট অফিসের সিলমোহর ভাবুন। চিঠি কোথা থেকে এসেছে আর খোলা হয়েছে কি না, সিল দেখে বোঝা যায়। Secure boot ও একই কাজ করে: ক্ষুদ্র, বদলানো যায় না এমন শুরুর কোড আর তাতে থাকা root of trust পরের ধাপের সই দেখে, সে আবার পরেরটির। একে chain of trust বলে। Embedded দিকের আলোচনা পাবেন Microprocessors, Embedded Systems ও IoT কোর্সে।

নতুন firmware পৌঁছায় OTA update দিয়ে, মানে ইন্টারনেটের মাধ্যমে। এটি খুব সংবেদনশীল পথ, কারণ update হলো সব যন্ত্রে কোড চালানোর বৈধ দরজা। নিচে একটি খেলনা camera, যার চলতি version v1.3, anti-rollback counter 13.

এবার verifier-টি নিজে চালান। “সই” এখানে খেলনা, শুধু ধারণার জন্য। লক্ষ করুন, প্রতিটি নকল প্যাকেজ আলাদা নিয়মে আটকায়।

// Toy OTA verifier. The "signature" is a keyed FNV hash: real নয়, শুধু ধারণার জন্য.
function fnv(text) {
  let h = 0x811c9dc5;
  for (const ch of text) { h ^= ch.charCodeAt(0); h = Math.imul(h, 16777619) >>> 0; }
  return h.toString(16).padStart(8, "0");
}
const VENDOR_KEY = "example-vendor-key";     // in reality: a private key on the vendor side
const sign = (m, key) => fnv(key + "|" + m.model + "|" + m.counter + "|" + m.hash);

function release(model, counter, image, key = VENDOR_KEY) {
  const m = { model, counter, image, hash: fnv(image) };
  return { ...m, sig: sign(m, key) };
}
const device = { model: "CAM-200", counter: 13 };   // anti-rollback counter stored on device

function verify(p) {
  if (sign(p, VENDOR_KEY) !== p.sig) return "REJECT bad signature";
  if (fnv(p.image) !== p.hash) return "REJECT image hash mismatch";
  if (p.model !== device.model) return "REJECT wrong model";
  if (p.counter <= device.counter) return "REJECT rollback or replay";
  device.counter = p.counter;      // commit only after the new image boots well
  return "ACCEPT, counter now " + device.counter;
}

const good = release("CAM-200", 14, "fake-firmware-1.4");
const tampered = { ...good, image: "fake-firmware-1.4+extra" };
const stranger = release("CAM-200", 15, "fake-firmware-1.5", "example-other-key");
const old = release("CAM-200", 12, "fake-firmware-1.2");
const other = release("DVR-900", 20, "fake-firmware-9.0");
const faked = { ...old, counter: 99 };   // attacker edits the version number

for (const [name, pkg] of [["tampered", tampered], ["wrong key", stranger], ["fake counter", faked],
    ["good 1.4", good], ["replay 1.4", good], ["old 1.2", old], ["other model", other]]) {
  console.log(name.padEnd(13) + verify(pkg));
}

Hash আর সইয়ের পার্থক্যটি হাতে-কলমে দেখুন। নিচের Python কোড আসল SHA-256 ব্যবহার করে, তবে firmware-টি নকল bytes.

# Real SHA-256 check on a fake firmware image built in memory (no file, no network).
import hashlib
import hmac

image = b"FAKE-FW-1.4 " + bytes(range(256)) * 16
published = hashlib.sha256(image).hexdigest()   # the value the vendor would publish
print("image size :", len(image), "bytes")
print("published  :", published)

def check(name, data):
    got = hashlib.sha256(data).hexdigest()
    ok = hmac.compare_digest(got, published)
    same = sum(a == b for a, b in zip(got, published))
    print(f"{name:<12} {'PASS' if ok else 'FAIL'}  matching hex digits: {same}/64")

# 1. the untouched download
check("original", image)

# 2. one single bit flipped near the end
flipped = bytearray(image)
flipped[-1] ^= 0x01
check("1 bit flip", bytes(flipped))

# 3. a truncated download
check("truncated", image[:-100])

# 4. a small device hashes in chunks, so it needs little RAM; the result is the same
h = hashlib.sha256()
for i in range(0, len(image), 512):
    h.update(image[i:i + 512])
print("chunked same:", h.hexdigest() == published)

# নিজের নামানো firmware ফাইলের digest দেখুন, তারপর প্রকাশকের সই-করা মানের সাথে মেলান
sha256sum firmware-1.4.bin

Unique credential: ভালো নকশায় প্রতিটি যন্ত্র কারখানায় নিজের key বা certificate পায়, secure element-এ রাখা। সব যন্ত্রে এক গোপন key থাকলে একটি যন্ত্র খুলে key পেলেই পুরো fleet ঝুঁকিতে পড়ে। প্রথম চালুর সময় password বদল বাধ্য করাও গ্রহণযোগ্য পথ।

৭ · CCTV আর smart device আলাদা রাখুন

যন্ত্রকে আপনি পুরো শক্ত করতে পারবেন না। Firmware আপনার হাতে নেই। তাই ধরে নিন যন্ত্রটি একদিন দুর্বল হবেই, আর তার ক্ষতির পরিধি ছোট রাখুন। এটি পর্ব ২২ · Firewall আর segmentation-এর সরাসরি প্রয়োগ। ছোট অফিস বা বাসার router-এ VLAN না থাকলেও guest network দিয়ে শুরু করা যায়; দেখুন পর্ব ২৭.

এখন একটি কাল্পনিক অফিসের flat network-কে ধাপে ধাপে ভাগ করি। অফিসের কম্পিউটার 192.0.2.0/24-এ, আর camera যাবে নতুন VLAN 30-এ, 198.51.100.0/24. (ঠিকানাগুলো নথিতে ব্যবহারের জন্য সংরক্ষিত।) NVR হলো ভিডিও রেকর্ড করার যন্ত্র। পরিবর্তনগুলো শুধু নিজের network-এ করুন, কাজের সময়ের বাইরে।

title: CCTV VLAN traffic outside the approved destination list
status: experimental
logsource:
  category: firewall
detection:
  selection:
    src_ip|cidr: 198.51.100.0/24
    action: allow
  approved:
    dst_ip|cidr: 203.0.113.10/32
  condition: selection and not approved
falsepositives:
  - Firmware update server address changed by the vendor
level: high

এই Sigma-ধরনের নিয়মটি ধরিয়ে দেয় camera VLAN থেকে অনুমোদিত তালিকার বাইরে কোনো সংযোগ হলে। IoT-তে এটি খুব ভালো সংকেত, কারণ যন্ত্রের আচরণ ছোট আর স্থির: একটি camera সাধারণত কয়েকটি ঠিকানার সাথেই কথা বলে। হঠাৎ নতুন গন্তব্য, অনেক বেশি outbound traffic বা অদ্ভুত DNS নাম দেখলে তদন্ত করুন। Sigma-র বিস্তারিত আসবে পর্ব ৫৬-তে।

৮ · OT আর ICS: আগে মানুষের নিরাপত্তা

OT বা operational technology হলো যে প্রযুক্তি কারখানা, বিদ্যুৎ, পানি বা গ্যাসের ভৌত যন্ত্র চালায়। তার একটি ভাগ ICS, যেখানে PLC আর SCADA কাজ করে। একটি গার্মেন্টসের বয়লার বা পানির পাম্প ভাবুন। এখানে ভুল হলে শুধু ডেটা নয়, মানুষের প্রাণ ঝুঁকিতে পড়ে।

Purdue model ১৯৯০-এর দশকের Purdue Enterprise Reference Architecture থেকে এসেছে। নিরাপত্তায় মূল চিন্তা হলো IT আর OT-র মাঝে IDMZ রাখা, যাতে অফিসের PC সরাসরি PLC-র কাছে না যায়। মডেলটি নিখুঁত নয়; cloud আর industrial IoT-র যুগে অনেক যন্ত্র সরাসরি ওপরের স্তরে কথা বলে। মডেলটি ভাগ বোঝায়, পুরো নকশা দেয় না।

• অগ্রাধিকার ভিন্ন: NIST SP 800-82 Rev. 3 (২০২৩)-এর মতো নির্দেশিকায় OT-তে আগে safety, তারপর availability, integrity, confidentiality. IT-র চেনা CIA ক্রম এখানে উল্টে যায়।
• Patch ধীরে: Plant বন্ধ করা ব্যয়বহুল, আর patch পরীক্ষা না করে দিলে উৎপাদন বা নিরাপত্তা ঝুঁকিতে পড়তে পারে।
• Active scan নয়: OT যন্ত্র অস্বাভাবিক traffic-এ থেমে যেতে পারে। অনুমতি থাকলেও passive monitoring আর বিশেষজ্ঞের পরিকল্পনা ছাড়া scan করবেন না।
• Safety system আলাদা: Safety instrumented system-কে সাধারণ নিয়ন্ত্রণ network থেকে আলাদা রাখুন। IEC 62443 এই শিল্পের প্রধান মান পরিবার।

৯ · কেনার চেকলিস্ট আর যন্ত্রের বিদায়

সবচেয়ে সস্তা নিরাপত্তা কেনার সময়েই পাওয়া যায়। দোকানে বা online-এ দাম দেখার আগে এই প্রশ্নগুলো করুন:

• প্রথম চালুতে password বদল বাধ্য, বা প্রতিটি যন্ত্রে আলাদা password আছে
• প্রস্তুতকারক ঘোষিত support period জানিয়েছে, কত বছর security update আসবে
• Firmware update সহজ, সম্ভব হলে স্বয়ংক্রিয়, আর সই-করা বলে দলিলে লেখা আছে
• Vulnerability report করার প্রকাশিত ঠিকানা আছে (security.txt বা সমমানের)
• Cloud account ছাড়াও স্থানীয়ভাবে চলে, বা cloud বন্ধ হলে কী হবে জানি
• MFA সহ account, দরকার নেই এমন service বন্ধ করা যায়
• কোন তথ্য কোথায় যায়, privacy policy-তে স্পষ্ট

End-of-life: যন্ত্রের বিদায়

প্রতিটি যন্ত্রের end-of-life আছে। Support শেষ হওয়া মানে নতুন ত্রুটি আর ঠিক হবে না। তিনটি পথ: বদলানো, আলাদা করে রেখে দেওয়া, অথবা ঝুঁকি মেনে নিয়ে লিখে রাখা (legacy ক্ষেত্রে)।

• যন্ত্র চলে গেলে: Factory reset করুন, cloud account থেকে সরান, Wi-Fi password বদলান যদি যন্ত্রে সংরক্ষিত ছিল, আর inventory থেকে মুছুন।
• বিক্রি বা ফেলার আগে: Camera বা NVR-এর ভেতরের storage মুছুন। পুরোনো router, ফোন বা drive-এ পুরোনো password আর ছবি থাকতে পারে।
• ফোনের ক্ষেত্রে: Account থেকে বের হন, activation lock বা factory reset protection সরান, SIM আর memory card খুলে রাখুন।

১০ · AI-এর যুগে mobile আর IoT নিরাপত্তা

AI app-এর কোড আর firmware script দ্রুত লিখে দেয়। কিন্তু এই ক্ষেত্রে কিছু ভুল বারবার দেখা যায়, যা চোখে পড়ে না।

• AI-এর প্রতিটি মান, CVE বা ধারা মূল উৎসে মিলিয়েছি
• Prompt-এ secret, ব্যক্তিগত তথ্য বা আসল device serial দিইনি
• যাচাই বন্ধ করে দেওয়া ধরনের সমাধান বাদ দিয়েছি
• Diff পড়েছি, নিজের ল্যাবে বা test device-এ পরীক্ষা করেছি
• Release, মুছে ফেলা বা firmware ছাড়ার সিদ্ধান্ত মানুষ নিয়েছে