کیا آپ کی خدمت محفوظ ہے؟ کیا آپ کو لگتا ہے کہ آپ آڈٹ کریں گے؟ کیا آپ کو لگتا ہے کہ آپ کی رسائ کا بندوبست بلٹ پروف ہے؟ شاید آپ ٹھیک ہیں ، لیکن اگر آپ اپنے آپ سے ایماندار ہیں تو آپ جانتے ہیں کہ سیکیورٹی ہمیشہ ڈبل چیکنگ کے قابل ہوتی ہے ، اور اسی وجہ سے میں اپنی رائے اور تجربات کو بانٹنے کے لئے یہ لکھ رہا ہوں۔
چھوٹے اور درمیانے درجے کے کاروبار سے ہٹ کر ماحول میں کام کرتے ہوئے ، میں نے سمجھا ہے کہ بڑے کاروباری اداروں میں بھی ، سیکیورٹی پہلوؤں کو اکثر نظرانداز کیا جاتا ہے۔ ہوسکتا ہے کہ کسی غیر منظم مائیکروسافٹ شیئرپوائنٹ میں کہیں بھی ایسی پالیسیاں لکھی گئیں ، لیکن اگر انفراسٹرکچر میں ڈیوائسز کو انسٹال کرنے یا تبدیل کرتے وقت ان پر عمل درآمد نہ ہونے اور نہ ہی ان پر غور کرنے کی دستاویزات کیا ہوں گی؟ نیز ، میں نے آلہ تیار کرنے والی کمپنیوں سے ملاقات کی ہے جن کی حفاظت کے پہلوؤں پر محدود توجہ ہے۔ یہاں تک کہ اگر اس طرح کی کمپنی کا حل قیمت ، خصوصیات یا دونوں طرح سے بڑھ جاتا ہے تو ، بعض اوقات کوئی بھی اس کمپنی کے لئے کوئی مثبت فیصلہ نہیں کرسکتا اگر شروع سے ہی واضح ہوجائے کہ حل سیکیورٹی پالیسیوں کے مطابق نہیں ہوگا۔
اس مضمون میں ، میں سیکیورٹی معاملات میں کچھ نکات دکھانا چاہتا ہوں جن پر اکثر نظرانداز کیا جاتا ہے۔ اس سے پہلے کہ کوئی بری آڈیٹر آپ کو اس کے بارے میں سکھائے اس سے پہلے کہ آپ یہاں کچھ چیزیں سیکھیں گے۔
ڈیفالٹ صارف نام / ڈیفالٹ پاس ورڈ
جب سے آپ کسی آلے کو خانے سے باہر نکالتے ہیں یا کسی سرور پر سافٹ ویئر انسٹال کرتے ہیں تو ، ڈویلپر کے پاس عام طور پر ایک "فیکٹری" اکاؤنٹ ہوتا ہے جو اکثر پہلی بار لاگ ان کرنے کے لئے پہلے سے طے شدہ صارف نام اور پاس ورڈ پر مبنی ہوتا ہے (یہ بھی ہے ممکن ہے کہ جگہ پر پاس ورڈ کا کوئی تحفظ موجود نہ ہو)۔ اس مرحلے پر ، آپ کے پاس سیکیورٹی کی سطح یا ان پالیسیوں پر منحصر ہے جو آپ پر عمل پیرا ہوں گے۔ آپشن 1 میں ان لوگوں کے حملوں سے بچنے کے لئے حسب ضرورت پاس ورڈ کے ساتھ ایک عمومی ایڈمن اکاؤنٹ رکھنا ہے جو ویب صفحات کی مدد سے آپ کے آلے کا استحصال کررہے ہیں جیسے “پہلے سے طے شدہ پاس ورڈ کی فہرست ". آپشن 2 میں ہر انتظامی صارف کا اپنا صارف نام حاصل کرنے اور پاس ورڈ کا انتخاب کرنا شامل ہوتا ہے جس کے بارے میں صرف وہ ہی واقف ہوتا ہے۔ اس کے خلاصہ کے طور پر ، کوئی یہ کہہ سکتا ہے کہ آپشن 1 انتظامیہ ٹیم سے باہر کے لوگوں کو آپ کے آلے تک رسائی سے روکتا ہے اور آپشن 2 ٹیم کے اندر موجود حملوں کو روکتا ہے ، جب تک کہ پاس ورڈ کسی کے ساتھ شیئر نہ کیا جائے۔
معاشرتی انجینرنگ
اگرچہ سوشل انجینئرنگ زیادہ تر معلومات کی حساسیت کی تربیت کا حصہ ہے ، لیکن جب بھی سوشل انجینئرنگ کے حملے کا تجربہ کیا جاتا ہے تو بہت سے ملازمین ناکام ہو رہے ہیں۔ ایک سوشل انجینئر ایک مرد یا عورت ہوسکتا ہے کہ وہ ٹیم یا تنظیم کا حصہ بننے کا بہانہ کر رہا ہو اور وہ عملی طور پر یا جسمانی طور پر صارفین کو لاگ ان کی اسناد جیسے اہم معلومات کو شیئر کرنے میں مصروف کرے گا۔ ایسی تکنیکی تشکیلات موجود نہیں ہیں جو مکمل طور پر اس کو ہونے سے روک سکتی ہیں جب تک کہ آپ انسانوں کو ملازمت دیتے ہو اور نہ ہی روبوٹ ، لیکن آپ ایسے ملازمین کو تربیت دے سکتے ہیں جو اہم معلومات سنبھال رہے ہوں اور آگاہی مہم چلائیں۔
مہمان اکاؤنٹس
کچھ منظرناموں کے لئے ، ڈویلپر نے مہمان اکاؤنٹس یا عوامی جگہ کو نافذ کیا ہے جو لاگ ان کیے بغیر استعمال یا دیکھا جاسکتا ہے۔ اگر آپ ان خصوصیات کو استعمال نہیں کررہے ہیں تو ، آپ کو ان سے آگاہ رہنا چاہئے اور صارفین کو ڈیٹا تک رسائی سے بچنے کے ل these ان مہمان اکاؤنٹس کو غیر فعال کرنا چاہئے۔ رسائی حاصل کرنے کے لئے نہیں ہیں.
غیر محفوظ پروٹوکول اور خدمات
اکثر طے شدہ ترتیب میں یہ دستیاب ہوتا ہے کہ تمام دستیاب پروٹوکول اہل ہوں۔ تاہم ، ان میں سے بہت سے محفوظ نہیں ہیں (جیسے HTTP ، FTP، Telnet، SNMP) اور مستقل طور پر غیر فعال کردیئے جائیں۔ اگر ممکن ہو تو ، آپ کو پروٹوکول کا محفوظ متبادل استعمال کرنا چاہئے۔ اگر ایف ٹی پی via کے ذریعہ بیک اپ کرتے وقت کوئی عارضی طور پر پروٹوکول کی ضرورت ہوتی ہے اور کوئی محفوظ متبادل دستیاب نہیں ہوتا ہے تو ، آپ اسے کام کی مدت کے ل enable فعال کرسکتے ہیں اور پھر سروس کو غیر فعال کردیں گے۔
کھنگالیں
کسی بھی طرح کی تبدیلی اور عمل کو مناسب انداز میں لاگ ان کیا جانا چاہئے۔ اس خصوصیت کو اکثر آڈٹ لاگ یا صارف لاگ کہا جاتا ہے۔ کچھ معاملات میں ، یہ ممکن ہے کہ آلہ ریبٹ کرتے وقت اپنا لاگ صاف کرے یا یہ لاگ دستی طور پر حذف یا تبدیل ہوسکے۔ اس کی روک تھام کے ل you ، آپ سیسلاگ سرور کے ساتھ کام کر سکتے ہیں جہاں یہ لاگ ان معلومات خود ہی آلات سے دور رکھے ہوئے ہیں اور ممکنہ حملے کے بعد اس کی جانچ کی جاسکتی ہے۔
خفیہ کاری
خفیہ نگاری معلومات کو چھپانے کے ل technologies ٹکنالوجیوں کا ایک مجموعہ ہے۔ جب بھی ممکن ہو تو ، ایک انکرپشن کی خصوصیت استعمال کی جانی چاہئے تاکہ منتقلی کے وقت ڈیٹا لیک نہیں ہوسکتا ہے۔ خفیہ کاری کا ایک عام حل AES ہے (اعلی درجے کی خفیہ کاری کا معیار).
پاس ورڈ کی طاقت اور تبدیلی کی فریکوئنسی
بہترین صورتحال میں ، محفوظ کردہ پاس ورڈ میں بے ترتیب خصوصی حرف ، نمبر ، بڑے حروف کے ساتھ ساتھ عام خطوط بھی شامل ہونے چاہئیں اور جب تک ممکن ہو لمبا ہونا چاہئے۔ اس کو کی بورڈ اور نمونوں کی پیروی نہیں کی جانی چاہئے جانور فورس حملوں میں ایسے الفاظ پر مشتمل نہیں ہونا چاہئے جو ایک لغت میں مل سکے۔ پاس ورڈ جسمانی طور پر نہیں لکھا جانا چاہئے اور یقینی طور پر اس کے بعد آپ کے مانیٹر کے سامنے یا کی بورڈ کے نیچے پھنسے ہوئے نوٹ پر ختم نہیں ہونا چاہئے۔ اگر ایسی پالیسیاں سرگرم ہیں جو پاس ورڈ نافذ کرتی ہیں جو حفظ کرنا مشکل ہے ، تو آپ کو اپنے انفارمیشن سیکیورٹی آفیسر سے پاس ورڈ مینجمنٹ سوفٹ ویئر طلب کرنا چاہئے جو آپ کی تنظیم میں منظور شدہ ہے۔
تبدیلی کی فریکوئنسی – یا عام طور پر پاس ورڈ کی تبدیلی discussion ایک مباحثے کے لئے کھلا موضوع ہے ، لیکن اگر ہر تین ماہ بعد پاس ورڈ کو تبدیل کرنے کی پالیسی بنتی ہے تو پھر اسے کرنا ہی پڑے گا۔ اب بھی ایسا کرنا سمجھ میں آتا ہے ، یہاں تک کہ اگر پاس ورڈ کو تبدیل کرنا صارفین کو بہتر حفظ کرنے کے لئے کمزور پاس ورڈز کا انتخاب کرنے کی ترغیب دیتا ہے۔ پاس ورڈ کی زندگی تقریبا 100 100 دن سے بھی کم ہے اور اس کی وجہ یہ ہے کہ عام طاقت کے ساتھ پاس ورڈ کو توڑنے میں لگ بھگ XNUMX دن لگتے ہیں۔
خلاصہ
یہ نکات صرف میرے اشارے ہیں اور در حقیقت ، آپ ہمیشہ اپنی تنظیم کے انفارمیشن سیکیورٹی اہلکاروں سے مشورہ کریں اور پہلے فعال پالیسیاں دیکھیں۔ اگر آپ کی رائے ہے یا محسوس ہوتا ہے کہ میں نے کسی اہم مضمون کو نظرانداز کردیا ہے تو ، براہ کرم نیچے کوئی تبصرہ لکھ کر آزاد کریں اور ہم مل کر مزید تکمیل پر کام کرسکتے ہیں۔
پڑھنے کے لئے شکریہ اور آڈٹ کے ساتھ اچھی قسمت۔
یہ پوسٹ اصل میں اکتوبر 2011 میں ایک ریڈیکل لاجک بلاگ پر شائع ہوئی تھی لیکن اب یہاں منتقل کردی گئی ہے کیونکہ اب پرانا پلیٹ فارم برقرار نہیں ہے۔
تصویر کریڈٹ: نکولس ریمنڈ / ایتھینا اسٹاک
