آیا معاملات اینترنتی امن، واقعاً امن هستند؟

امروزه مرورگرها از تکنیکی به نام SSL (Secure Socket Layer) استفاده می کنند تا اطلاعاتی را که بین مرورگر شما و وب سرور مبادله می شود، رمزنگاری کنند. هنگامی که علامت «قفل» در گوشه پایین مرورگر نمایش داده می شود، به این معنی است که مرورگر ارتباط رمزشده امن با سرور برقرار کرده است و لذا ارسال دیتای حساس مانند شماره کارت اعتباری امن است. اما آیا واقعا این سیستم امن است و می توان از این طریق با اطمینان تراکنشهای حساس مالی را رد و بدل کرد؟ پاسخ این است که SSL فقط ارتباط بین مرورگر شما و وب سرور را امن می کند و برای محافظت از اطلاعات شما در آن سرور کاری انجام نمی دهد. در شرکت های بزرگ که می توانند سرورها و خطوط ارتباطی با ظرفیت های بالا را اختصاصی و برای ارتباط مستقیم تهیه کنند، تا جایی که شما بتوانید به شرکت اعتماد کنید، مشکلی ایجاد نخواهد شد. اما بسیاری از شرکت های کوچک تر توانایی تهیه سرور اختصاصی را ندارند. آنها از «میزبانی شخص ثالث» استفاده می کنند و این جایی است که عدم امنیت بوجود می آید. شما مجبورید به میزبانی که هیچ شناختی از آن ندارید، اطمینان کنید و به ایمن بودن نحوه دریافت اطلاعاتتان از آن میزبان توسط شرکت مورد نظرتان اعتماد کنید. اما تضمینی برای ایمن بودن این ارتباط نیست!

بیشتر میزبان های وب برای کلاینت های خود یک برنامه  (CGI (Common Gateway Interface ارائه می دهند که FormMail نام دارد. آنچه که این برنامه انجام می دهد این است که محتوای یک فرم اینترنتی را، مانند فرمی که شما اطلاعات کارت اعتباری خود را در آن قرار می دهید، می گیرد و از طریق ایمیل به شرکت ارسال می کند. برای این ایمیل نه محافظتی وجود دارد و نه رمزنگاری صورت می گیرد.

آنچه که اتفاق می افتد این است که شرکتی که شما از آن خرید می کنید، ظاهری امن به خود می گیرد تا شما اطلاعات حساس را وارد کنید. سپس همان اطلاعات را از طریق ایمیل معمولی برای شرکت ارسال می کند. در واقع تمای این روال برای دادن یک احساس امنیت کاذب به شماست. بسیار هستند شرکت های کوچکی که سایتشان توسط شرکت های شخص ثالثی میزبانی می شود که ابداً سرویس های امن SSL ارائه نمی کنند.

پرسش هایی که مشتریان در ذهن شان ایجاد می شود، معمولاً در باره نحوه ارسال این اطلاعات و آگاه شدن خودشان از سفارش هایشان است و از طرف دیگر قرار دادن یک فرم امن آنها را قانع می کند که معامله با شرکت مورد نظر از طریق اینترنت امن است و به دانستن نکات دیگر توجهی نشان نمی دهند.

توجه کنید که خود شرکت ها می گویند «هدف یک فرم امن راضی کردن کاربران به وارد کردن جزئیات کارتشان است». با خود فکر کنید که اگر ایمیل کردن اطلاعات کارت اعتباریتان به شرکت بدون استفاده از رمزنگاری، امنیت کافی را دارد، چرا خودتان این کار را نکنید؟ آیا احساس امنیت خواهید کرد اگر بدانید که این شرکت (یا سایر شرکت های مشابه) سهواً شما را فریب می دهند که معاملات به این شکل امن است، در حالیکه نیست؟ هنوز، این شرکت ها مشتریانی دارند که به آنها پول می دهند تا به آنها این حس کاذب را بدهند.

ایمن کردن معاملات

با وجود تمام این شرکت هایی که به تاجران راه هایی ارائه می کنند تا به مشتریانشان این احساس کاذب امنیت را بدهند، یک شرکت کوچک بمنظور امن کردن واقعی معاملات، چه باید بکند؟ یک روش برای آن شرکت، استفاده از ایمیل های رمزشده مانند PGP است. نسخه هایی از FormMail وجود دارند که از ایمیل رمزشده PGP  استفاده می کنند. در حالیکه بعضی از این روش استفاده می کنند، برای بعضی شرکتهای تجاری کوچک بدلیل نداشتن افراد خبره برای تنظیم و استفاده از PGP، این کار مشکل است. بعضی شرکت های میزبان اینترنت وجود دارند که بخش سرور این ارتباط را تنظیم می کنند، اما در طرف کلاینت که یک شرکت کوچک تجاری است باید بتواند PGP را روی کامپیوتر خود نصب و استفاده کند.

روش امن دیگر، ذخیره اطلاعات در پایگاه داده ای روی وب سرور اما در جایی است که از وب دسترسی مستقیم به آن ممکن نباشد. زمانی که شرکت میزبان اینترنت قابل اعتماد نیست و یا قصد دارید امنیت بیشتری را به وجود آورید، این پایگاه داده می تواند رمزنگاری شود. تاجران بعداً می توانند اطلاعات مربوط به معاملات را با استفاده از ارتباط رمزشده SSL خود بازیابی کنند. اما در این روش فروشنده باید بتواند سیستم امن را برای خود ایجاد کند. این عمل به میزان مشخصی از تواناییهای برنامه سازی احتیاج دارد تا اسکریپت های CGI برای استفاده از این سیستم نوشته شود.

بنابراین روند مورد نظر امن به این شکل خواهد بود؛ فرم سفارش امن است و اطلاعات بین کامپیوتر مشتری و سرور بصورت رمز شده خواهد بود. در سرور، اطلاعات بصورت رمزشده در یک پایگاه داده ذخیره می شود. سپس فروشنده از طریق ایمیل از رسیدن سفارش ها مطلع می شود (هیچ گونه اطلاعات مهم و حساس در ایمیل ها قرار ندارد) و بالاخره، فروشنده اطلاعات را از طریق یک ارتباط امن دیگر بازیابی می کند.

بنابراین، وقتی که را ههایی برای تامین امنیت واقعی برای معاملات وجود دارد، چگونه باید مشتری را مطلع کرد که معامله واقعاً امن است یا خیر؟ در حال حاضر راه ساده ای وجود ندارد. مشخصاً، شما می خواهید مطمئن شوید که فرم امن است، بعلاوه می خواهید مطمئن شوید که شرکت به شما حس کاذب امنیت نمی دهد و این حس واقعی است. یک راه این است که به سیاست های حریم  خصوصی آن شرکت نگاهی بیندازید (البته با این فرض که چنین چیزی وجود دارد) و مطمئن شوید که در آن ذکر شده است که «اطلاعات کارت اعتباری هیچ مشتری هرگز بدون رمزنگاری از طریق اینترنت ارسال نخواهد شد.» 

بهرحال، هنوز روش کاملی برای تضمین امن ماندن اطلاعات وجود ندارد. بنابراین به جمله Caveat Emptor می رسیم که «بگذارید خریدار خود آگاه و مواظب باشد.»

مقدمه

حتماً در مقوله های مرتبط با امنیت کامپیوتر و شبکه با عبارت Incident Handling مواجه شده اید. ابتدا ببینیم یک رویداد امنیتی ( (Security Incident چیست. هر سازمان باید رویداد امنیتی را برای تشکیلاتش کند. تعاریف زیر نمونه هایی از این دست هستند:

هر رویداد مضر مشخص یا مشکوکی که به امنیت سیستم ها یا شبکه های کامپیوتری مربوط باشد.

یا

عمل نقض کردن آشکار یا ضمنی سیاست امنیتی.

فعالیت هایی زیر مثال هایی از  یک رویداد امنیتی هستند:

·         تلاشهایی (چه موفق و چه ناموفق) برای حصول دسترسی غیرمجاز به یک سیستم یا دیتای آن

·         ازکار افتادن ناخواسته یا عدم پذیرش سرویس

·         استفاده غیرمجاز از یک سیستم به هدف پردازش یا ذخیره سازی دیتا

·         تغییراتی در مشخصات سخت افزار یا نرم افزار بدون آگاهی یا اجازه یا دخالت صاحب آن.

فعالیت شبکه یا میزبان که بالقوه امنیت کامپیوتر را تهدید می کند نیز می تواند بعنوان رویداد امنیتی کامپیوتری تعریف گردد.

برخورد با رویداد

 منظور از این عبارت نحوه مقابله و اقداماتی است که در هنگام وقوع یک مسأله امنیتی انجام می گیرد. در حقیقت این اقدامات به سه بخش تقسیم می شود. گزارش رویداد، تحلیل رویداد و واکنش به رویداد.

اهمیت واکنش به رویدادهای امنیتی سیستم ها، کمتر از تشخیص آنها نیست. اقداماتی که شما بدنبال تشخیص یک رویداد انجام می دهید، نه تنها عملیات سازمان را تحت تأثیر قرار می دهد، بلکه ممکن است باعث تغییرات بسیاری در آینده چنین روندهایی و وضعیت امنیتی خودتان گردد.

در این مقاله به برخورد با رویدادهای امنیتی نه از دیدگاه تکنیکی بلکه از دیدگاه عواملی مانند عوامل انسانی، سیاست برخورد و زمان پرداخته می شود. برای اینکه بتوان بیشتر با نحوه  برخورد یک سازمان به یک رویداد امنیتی آشنا شد، به مثالی در این باره می پردازیم.

مثالی از واکنش به یک رویداد در یک سازمان بزرگ

این مثال فقط برای نشان دادن تلاش های ممکن برای واکنش ارائه شده است و یک مدل کلی نیست.

هنگام مشاهده ثبت وقایع مربوط به نفوذ در ساعت ? بامداد، پرسنل ?? ساعته مراقبت از شبکه کشف می کنند که حمله ای با موفقیت انجام شده است.

برای بسیاری از سازمان ها، واکنش فوری، قطع شبکه برای تأخیر یا قطع افشای اطلاعات بیشتر خواهد بود، اما ما سعی داریم که از چنین واکنشی پرهیز کنیم و پرسنل بخش مراقبت نیز از این قضیه مطلع هستند. درعوض، چک لیست هایی را که در اختیار دارند برای برخورد با این نوع رویداد به اجرا می گذارند.

قدم اول خبرکردن و ارائه گزارشی مختصر به رئیس بخش امنیت سیستمها (یا نماینده اش) است. تا این فرد از خواب بیدار گردد و از حمله مطلع گردد، چهار دقیقه از اطلاع دهی اولیه سپری شده است.

با اطلاعاتی که موجود است، نماینده امنیت shutdown کامل سیستم را نمی پذیرد، اما اجازه فراخوانی یک گروه امداد را می دهد. در حالیکه نماینده بخش امنیت به سمت محل حرکت می کند، پرسنل بخش مراقبت شروع به این فراخوانی می کند. نمایندگانی از بخشهایی چون عملیات شبکه، قانونی، مهندسی، اجرایی و مدیریت آگاه شده اند و به محل فراخوانده شده اند. مجری قانون محلی نیز خبر شده است و ثبت رویدادها به ترتیب وقوع آغاز می شود.

حالا از اخطار اولیه ?? دقیقه گذشته است.

نماینده بخش امنیت که اولین فرد باخبر شده است، اولین کسی است که می رسد. این شخص تنظیم و آماده سازی مرکز امداد را آغاز می کند. کیف امداد باز است که در آن یک لپ تاپ، باتری اضافه، لامپ، ابزار، چک لیست ها و صفحات یادداشت برای تمام اعضای تیم امداد، و ابزار گوناگون دیگر وجود دارد. کپی هایی از اطلاعات موجود نیز برای توزیع بین اعضای تیم و مدیریت ارشد آن آماده شده است. ?? دقیقه از زمان اخطار اولیه گذشته است.

سایر اعضای گروه  به صورت پراکنده در طول این زمان وارد شده اند و پرسنل بخش مراقبت نیز تحقیق بیشتری در مورد نفوذ انجام داده است. بررسی اولیه آشکار می کند که نفوذگر به سیستم یک کاربر وارد شده است، اما هنوز به نقاط دیگر شبکه پیشروی نکرده است. حمله از طریق استفاده یک کاربر از یک اتصال dial-up که مورد تأیید نبوده صورت گرفته است. نفوذ واقعی هشت ساعت قبل از کشف اولیه صورت گرفته است.

کل گروه ?? دقیقه بعد از اولین اخطار گرد هم می آیند. تمام اعضاء با سرعت در محل حاضر و شروع به فکر کردن و نقشه کشیدن و ارائه راه حل شده اند. مناظرات به موافقت هایی منجر می شود. سیستم مورد نفوذ از شبکه جدا خواهد شد و عملیات تعیین و تشخیص آغاز خواهد شد. خلاصه ای برای مدیر ارشد تهیه و مراحل اولیه کامل می شوند. ??? دقیقه گذشته است.

نماینده عملیات شبکه، مسؤول قطع کردن سیستم مذکور می شود. نماینده اجرایی ثبت وقایع را روی لپ تاپ به روز و بررسی مجدد می کند. این فرد با ثبت لحظه به لحظه از تمام رویدادها، بعنوان نقطه مرکزی تمام فعالیت ها و ارتباطات گروه عمل می کند. نماینده قانونی با آگاه شدن از وضعیت موجود و راهنمایی هایی داده شده به وی، به خانه برمی گردد تا ابتدای صبح به محل برگردد. پرسنل بخش مهندسی و امنیت، اطلاعاتی را که تا کنون جمع آوری شده و شامل دیتای حاصل از سیستم تحت نفوذ قرار گرفته است،  بررسی می کنند. این اطلاعات روی بستر یک شبکه مجزا بررسی و تحلیل می شود تا نفوذگر، ابزار حمله و روش هایی ممکن برای بستن آسیب پذیری در کل سازمان مشخص شود.

با سپری شدن ??? دقیقه از آغاز، گروه برای مرور و به روز رسانی پیشرفت کار دوباره دور هم جمع می شوند. مشخص شده است که نفوذگر از یک IP بیگانه جعلی از طریق اتصال dial-up استفاده کرده است و فقط قادر به دستیابی به همان سیستم بوده است. بررسی کامل شبکه احتیاج به این دارد که سرورها از شبکه جدا شوند و این عملیات ? ساعت زمان نیاز دارد. گروه با مشورت و تصویب مدیریت ارشد، تصمیم به این بررسی می گیرد اما بعد از بسته شدن سازمان در انتهای روز کاری بعد.

هنگامی که روز کاری آغاز می شود، فعالیت ها به بیرون فاش می شود و فردی که سیستمش مورد نفوذ قرار گرفته مورد مصاحبه قرار می گیرد و سیستم مورد نفوذ پاکسازی می گردد و به افراد ارشد گزارشها بصورت خلاصه ارائه می شود. بهرحال، عملیات امداد به اوج خود می رسد و مرتفع سازی آغاز می شود. تا ساعت ?? رویداد برطرف شده است و گزارش نهایی روز بعد آماده خواهد شد.

کسانی هستند که به فوریت مستندسازی تهدید بوجود آمده و عملیات آنی اصرار می ورزند که باید ? ساعت اضافه نیز برای آنها دید. برای سازمان شما، ممکن است چنین موردی رخ دهد، و شما بخواهید اولین گام بعد از تعیین رویداد، جداسازی یکطرفه و ناگهانی از شبکه و سیستم ها باشد. اما در این حالت خاص، مزیت انتخاب یک روند سیستماتیک، حفظ عملیات عادی برای یک روز کامل کاری بود، (بجای خاموش کردن کل سیستم سازمان برای یک روز کاری) که نتیجه آن نیم دوجین افراد خسته، چند ساعت کار جبرانی و اضافه کاری و خاموش بودن تنها یک سیستم در طول یک روز کاری بود. از نظر افراد درگیر این عملیات، هزینه ای که توسط این روش صرفه جویی شد، ارزش ریسک را داشت.