misusecase و usecase های امنیتی در استخراج نیازمندیهای امنیتی

چکیده

در سال های اخیر، Misusecase ها با تمرکز بر تهدیدات و استثناها در سیستم، به یک روش محبوب تجزیه و تحلیل و ایجاد امنیت (غیرفعال) مورد نیاز در هنگام ترکیب با Usecaseها  تبدیل شده است. علاوه بر این، برخی از مقالات اخیر موارد دیگری از Usecase، به نام  Usecase های امنیتی را نشان می دهند که تمرکز بر توالی های مضر داشته و می تواند به تشخیص نیازهای امنیتی کمک کند. در این مقاله به سوالات زیر پاسخ دهیم. رابطه بین Misusecaseها /usecaseها و Usecaseهای امنیتی چیست؟ تفاوت های بین این دو روش زمانی که در مورد موارد مشابه برای تعیین الزامات امنیتی تعیین می شود چیست؟ آیا تفاوت های مهم بین نتایج وجود دارد؟ اگر آنها با هم اجرا شوند، آیا بهره وری بهتر می شود یا خیر؟

1. معرفی

در حال حاضر تعداد زیادی از سازمان های توسعه نرم افزار متوجه شده اند که توسعه نیازهای امنیتی در حین توسعه نرم افزار مهمتر از طراحی محافظت پس از تولید نرم افزار است چرا که توجه به نیازهای امنیتی در مراحل اولیه چرخه تولید نرم افزاری به طور بالقوه میلیون ها دلار صرفه جویی می کند. بنابراین، روش های تجزیه و تحلیل و مستند سازی تهدیدات امنیتی و الزامات امنیتی، مانند Misusecaseها /usecaseهاو Usecaseهای امنیتی، افزایش یافته است.

Misusecase ها، یک فرم جدید از فناوری قدیمی توسعه Usecaseها است. Usecaseها به طور نسبتا خوبی برای فرآیند بررسی نیازمندی‌های کاربردی به کار می‌رود . با این حال، زمانی که برای استخراج الزاماتی که جزء وظایف نیست (nonfunctional) مورد استفاده قرار می‌گیرد مانند نیازمندیهای امنیتی ، دیگر کاربرد ندارند، برخلاف Usecaseها، misusecaseها می‌تواند برای مشخص کردن الزامات nonfunctional ( امنیت ) اعمال شود، چرا که آن‌ها در بررسی استثناها و تهدیدها به جای توابع در یک سیستم خوب هستند. اصطلاح Usecase و Misusecase توصیف‌شده در [ ۱ ] [ ۲ ] توسط این مقاله اتخاذ می‌شود. این اصطلاح موجب ایجاد یک بازی مانند Chessیا Go می‌شود که به درستی کار می‌کند تا فرآیند استخراج و رابطه بین Misusecaseها  و Usecaseها  شود.

در سال های اخیر، یک موضوع مرتبط با تحقیق، به نام Usecaseهای امنیتی، توسعه یافته است. Usecaseهای امنیتی یکی دیگر از Usecaseها است که بطور خاص برای تهیه الزامات امنیتی مورد استفاده قرار می گیرد. در مقایسه با Misusecaseها / ا Usecaseها ، Usecaseهای امنیتی نیز بر اقدامات خصمانه از عوامل حمله تمرکز می کنند؛ اما آنها پروسه تشخیص متفاوت و الزامات امنیتی مشخص را دارند. برای به دست آوردن تفاوت های بیشتر، این مقاله به مقایسه این دو روش و با استفاده از موارد مشابه آنها پرداخته است.

این مقاله با معرفی Misusecaseها / Usecaseها، اصطلاح آنها، بهره برداری (تهیه الزامات امنیتی) و یک نمونه خاص آغاز می شود. بخش 3 در مورد برخی از نظرات در مورد Usecaseهای  امنیتی صحبت می کند و این روش را از طریق دو مثال در تجارت الکترونیک توضیح می دهد [4]. در بخش 4 با توجه به مراحل [1] [7] نشان داده شده است که چگونه Misusecaseها /usecaseها را می توان در مواردی که در بخش 3 آمده است اعمال شود. بخش 5 این دو روش را مقایسه می کند و مزایا و معایب هر یک از آنها را در بر می گیرد . سرانجام بخش 6 نتیجه گیری این مقاله است.

2. Misusecaseها / Usecaseها

2.1 اصل و کاربرد

برای درک Misusecaseها، ابتدا لازم است که Usecaseها را درک کنید. این به این دلیل است که Misusecaseها از Usecaseها بدست آمده و بر اساس اصول مشابه است. استفاده از موارد [8] مجموعه ای از سناریو های سازمان یافته بر اساس توالی اقدامات انجام شده توسط کاربران نرمال است. به این معنا است که آنها بر روی آنچه که یک سیستم می تواند انجام دهد یا هدف آن تمرکز کند کار می کنند. از این رو استفاده از موارد مناسب برای تجزیه و تحلیل و تشریح الزامات عملکردی در یک سیستم مناسب است. این کار از طریق مشخصات نوشته شده از اقدامات سیستم در فرم هایی است که شامل نام مورد استفاده، بازیگر، پیش شرط، جریان رویدادها، وضعیت پس از آن و مسیر جایگزین است. استفاده از Usecaseها، وضوح و قابلیت مجدد الزامات را افزایش می دهد.

با توسعه و رشد تجارت همراه و تجارت الکترونیک مردم به طور آگاهانه و عمدی به سیستم هایی که از آنها حمایت می کنند روی می آورند. این باعث اهمیت رو به رشد نیازهای امنیتی موثر شده است. متاسفانه، با نگاهی به رویکرد عادی یک سیستم، عملکرد Usecaseها، در ایجاد این نیازهای امنیتی کم است. بنابراین، Usecaseها باید با Misusecase ها توسعه داده شود تا به این هدف برسیم. Misusecase ها [1] [2] [7]، یک فرم تخصصی از Usecaseها است که بر استثنا و تهدیدات ناشی از عوامل خصمانه به یک سیستم تمرکز دارد. ساده ترین کاربرد Misusecase ها /usecaseها  این است که نیازهای خاص امنیتی را در شرایط غیر رسمی و رسمی بیان کند. علاوه بر تجزیه و تحلیل نیازها، Misusecase ها /usecaseها نیز در بسیاری از انواع دیگر از نرم افزار ارزشمند است [1] [2]. برخی از این موارد عبارتند از شناسایی استثناها، ایجاد موارد تست و برخورد با تعارضات هنگام طراحی یک سیستم که در این مقاله توضیح داده نشده است. 

معمولا رویکرد توسعه Misusecase ها /usecaseها از بالا به پایین است که به صورت بازگشتی از سطوح بالاتر به پایین تر حرکت می کند؛ تجزیه و تحلیل و تعیین الزامات از نقاط هر دو طرف یعنی کاربر و سوء استفاده کنندگان. موارد احتمالی استفاده شده به طور مداوم با تهدیدات بالقوه به چالش کشیده می شوند و تهدید کشف شده باعث ایجاد توابع جدید می شود. ارتباطات مورد بررسی در سطوح پایین تر ممکن است به عنوان مکمل سطوح بالاتر حل شوند. فرآیند به طور مداوم تکرار خواهد شد تا زمانی که مشکلات سیستم به طور کامل تعریف شود. در بخش بعدی، اصطلاح Usecase برای توضیح یک نمونه معمول بحث می شود.

2.2 مثال Misusecase ها /usecaseها [1]

Misusecase ها /usecase ها از موارد اصطلاح ‘game’ است که الگوریتم آن به عنوان یک استراتژی یک تیم از تفکر پیش رو برای بهترین حرکت در مقابل تیم دیگر و اقدام به بستن آن است. استفاده از این اصطلاح مزایای متعددی را به ارمغان می آورد. اصطلاح از جملاتی که بیان می شود، جامع تر است، ارتباط میان مواردی را به طور واضح ایجاد می کند و در نهایت آسان ساختن و تفسیر اختلافات آسان است. در این اصطلاح، کاربران و یا عوامل خصمانه توسط چند stickmen ارائه شده؛ تیم های سفید و سیاه به ترتیب برای Usecase  و Misusecase قرار می گیرند. این رابطه به شرح زیر است: یک سیستم در سطح بالایی شامل زیر سیستم هایی در سطوح پایین تر است؛ یک Misusecase  “یک Usecase  را تهدید می کند”؛ یک Usecase ” Misusecase ” را کاهش می دهد. تمام تحرکات یک شکل ظریف متعادل را از بالا تا پایین می باشد. همانطور که در زیر ، در مثال خودرو نشان داده شده است، هنگامی که یک دزد تلاش می کند تا خودرو را سرقت کند، راننده باید یک زیرسیستم به نام قفل را برای شکست دادن این تلاش انجام دهد. سپس دزد سعی می کند تا سیستم جرقه زنی را که راننده می تواند با قفل کردن انتقال کنترل کند را کوتاه کند. با این حال، آیا شما اعتقاد دارید که دزد تسلیم خواهد شد؟ احتمالا نه ، از این رو، محدودیت اصلی این اصطلاح این است که همیشه با وجود استثنائات نامعلومی، با تکیه بر Misusecase ها / Usecaseها، همیشه وجود دارد.

شکل1. Misusecaseها /usecaseها از موارد تصدیق برای یک سیستم خودرو

3. Usecaseهای امنیتی

3.1 اصل و بکاربرد

موارد Usecase امنیتی نوع دیگری از Usecaseها است که بطور ویژه برای تشریح الزامات امنیتی می باشد که تولید و بهره برداری آن در [3] [4] [5] [6] معرفی شده است. همانطور که UseCaseها توضیح داده شده است، اصل و استعاره Usecase امنیتی را می توان در اینجا حذف کرد. یک رویکرد برای اعمال آنها این است که کشف الزامات امنیتی (Usecase امنیتی) را از الزامات عملکردی (Usecaseهای نرم افزارها) جدا کند. Usecaseهای امنیتی نیاز به چندین سرویس امنیتی انتزاعی با شرایط امنیتی دارند. هنگامی که شرایط امنیتی خود راضی هستند، آنها توابع مورد نیاز (Usecase نرم افزار) را به یک سیستم گسترش خواهد داد. اساسا، در سیستم های مختلف، چندین ویژگی امنیتی عمومی وجود دارد [3] [4] [6]. بنابراین موارد ضروری استفاده از امنیت یک روش بسیار قابل استفاده برای سازماندهی و تعیین شرایط امنیتی را فراهم می کند. این دلیل اصلی است که علیرغم افزایش علاقه به موارد Misusecase، این رویکرد به کاربرد صنعتی در مقیاس بزرگ اعمال شده است. 

با توجه به تجزیه و تحلیل تهدید، شش نوع خدمات امنیتی (Usecaseها امنیتی) در سیستم های کاربردی مورد استفاده قرار می گیرد. اینها به شرح زیر است:

سرویس تأیید هویت: اجازه می دهد یک نهاد (یک کاربر یا سیستم) خود را مثبت به یک نهاد دیگر شناسایی کند.

کنترل دسترسی: حفاظت از دسترسی غیر مجاز به منابع.

محرمانه بودن: محافظت در برابر افشاء غیر مجاز اطلاعات به هر نهاد را انجام می دهد.

یکپارچگی: از تغییرات غیر مجاز داده ها محافظت می کند.

عدم انکار: محافظت در برابر انکار برقراری ارتباط و یا تراکنش بس از انجام کامل آن و در آنده.

در دسترس بودن (انکار سرویس): انکار سرویس هنگامی رخ می دهد که یک طرف مجاز از دسترسی به یک سیستم که به آن دسترسی قانونی دارد جلوگیری شود. [4]

3.2 مثال Usecaseها امنیتی [4]

پیش از شروع بررسی آنها، پیش شرط هایی وجود دارد که مقایسه را دقیق تر می کند:

1. نمونه ها بر اساس امنیت سیستم نرم افزاری به جای امنیت شبکه می باشد؛
2. با پیش شرط فوق، در اینجا نیازی به بررسی انکار خدمات نیست.
3. فرض بر این است که پایگاه داده امن است.

3.2.1 مرور کاتالوگ

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

تأیید هویت کاربران را از طریق ورود هویت شناسایی می کند که سیستم می تواند کاربران مشروع را پذیرش کند (اطلاعات هویت برای کنترل دسترسی آن نگهداری می شود) و از آن کسانی که معتبر نیستند، جلوگیری کند. اگر مشتری به عنوان یک کاربر مشروع شناخته شود، سیستم از اطلاعات هویت خود برای بررسی اینکه آیا او برای دسترسی به یک فهرست خاص مجوز دارد یا نه ، استفاده می کند. در حالی که Misusecase های اصطلاح استفاده‌شده در Usecaseها ( فرم متنی ) را قبول دارد، آن‌ها می‌توانند به صورت زیر ارایه شوند:

نام Usecase: مرور کاتالوگ

خلاصه: مشتری کاتالوگ را برای فهرست انتخاب می کند.

بازیگر: مشتری

پیش شرط: سیستم آماده است.

توضیحات (بر اساس Usecase):

1. <تأیید هویت>
2. مشتری برای مشاهده یک فهرست کاتالوگ را انتخاب می کند.
3. سیستم نمایش فهرست کاتالوگ.
4. درخواست کاربر برای مشاهده یک کاتالوگ خاص
5. <دسترسی مجوز>
6. سیستم خواندن کاتالوگ و آن را نمایش می دهد.

شرایط پست: مشتری یک فروشگاه را مرور کرده است. [4]

علاوه بر این، فهرست پرونده Usecase، دو Usecase  دیگر از پرونده را برای تعریف در همان فرم دارد. این ها احراز هویت و مجوز دسترسی است. با این حال، تعاریف آنها نیازی نیست که در اینجا لیست شوند چون برای مقایسه ما لازم نیست. شکل 2 رابطه بین اینها را نشان می دهد.

شکل 2 مرور کاتالوگ را با Usecase  امنیتی در سیستم تجارت الکترونیک مرور کنید

3.2.2 انجام خرید

مثال دیگر از Usecaseهای امنیتی نرم افزاری ،   انجام خرید امن بین مشتریان و تامین کنندگان از طریق درخواست های خرید است. در طی خرید، یک مشتری می خواهد درخواست خرید خود را به یک تامین کننده ارسال کند و با کارت اعتباری پرداخت کند. این باعث می شود که سیستم درخواست رمزگذاری برای حفظ محرمانه بودن و حفاظت از داده های با ارزش را بررسی و بدرستی تغییر دهد. علاوه بر این، برای اجتناب از انکار نادرست درخواست، این سیستم به یک سرویس – نیاز دارد. معمولا امضای دیجیتالی در این سناریو به کار گرفته می‌شود. شکل ۳ این فرآیند را نشان می‌دهد که شامل دو Usecase   از برنامه ( ” درخواست خرید ” و ” دریافت درخواست خرید ” ) و سه Usecase امنیتی است. برخلاف مثال اول، دو عملگر یک درخواست وجود دارند، به طوری که از دو نقطه مشاهده می‌شود. توصیفات این Usecaseها در فرم متنی، در اینجا حذف می‌شوند، که نظم بکارگیری Usecaseهای  امنیت را تعریف می‌کنند.

شکل 3 درخواست خرید را با استفاده از Usecase امنیتی انجام دهید

4. نرم افزار Misusecaseها / Usecaseها برای موارد تجارت همراه

4.1 مرور کاتالوگ با Misusecaseها / Usecaseها

برای اعمال Misusecaseها /usecaseها در این دو مورد تجارت همراه، شش دانشجو دعوت شدند. همه دارای تجربه امنیتی در بخش علوم کامپیوتر هستند. یک کارگاه کوچک غیر رسمی شکل گرفت که در آن ما تظاهر می کردیم که نه تنها کاربران، بلکه عوامل منفی تهدید کننده سیستم هستند. در اینجا Misusecase ها /usecase ها به عنوان یک روش غیر رسمی برای تحلیل و تعیین شرایط امنیتی در سیستم های کوچک استفاده شد. بنابراین، گروه فقط نیاز به تجزیه و تحلیل و لیست تمام  Misusecaseها /usecase ها و ارتباط آنها با توجه به مراحل معرفی شده در [1] داشت، اما نه برای آماده شدن برای پروژه های بعدی. در طی این فرایند، تکرارهای متعددی برای اصلاح پیشبرد وجود داشت. علاوه بر این، فرض بر این بود که سوء استفاده کنندگان در این موارد در نظر گرفته شوند، فقط به جای افراد خودی، بیگانه هستند. این تاثیری بر نتیجه ما تاثندارد. برای Usecase مرور کاتالوگ، کار ما به شرح زیر است:

1. برای بررسی اینکه که سیستم چیست و تقریبا در مورد عملکرد آن فکر می کند: سیستم در برخی از کاتالوگ های تجارت همراه عمل می کند که عملکرد اصلی آنها مرور کاتالوگ و ممنوعیت خواندن غیرقانونی است.
2. برای روشن کردن کاربران و سوء استفاده کنندگان: کاربران اینجا باید مشتریان و سیستم باشد؛ سوءاستفاده کنندگان می توانند کاربرانی باشند که قصد سوء استفاده دارند و یا هکرها. با این حال، هیچ عملیات کتبی در این سیستم وجود ندارد، کاربرانی که احتمال سوء استفاده دارند در اینجا می تواند نادیده گرفته شود.
3. برای تایید و نوشتن موارد کاربرد دقیق استفاده توسط کاربران: به نظر ما، Usecaseها در این مثال بسیار ساده هستند، اساسا با برآورد ما یکسان است. در این وضعیت، ما می توانیم از یک stickman برای نشان دادن هر دو کاربر برای ساده سازی نمودار استفاده کنیم. در این سناریو، پرونده های استفاده شده مورد بررسی قرار می گیرند و کنترل های امنیتی را مرور می کنند. در اینجا، کنترل امنیتی یک تابع فرعی از عملکرد اصلی است که یک عملکرد مرور کاتالوگ است.
4. برای کشف لیست Misusecaseها برای عوامل خصمانه: در حال حاضر ما Usecaseها را داریم، بنابراین ما فقط باید به دنبال راهی برای تهدید آنها باشیم. علاوه بر Misusecaseها، ارتباط بین این و Usecaseها موجود باید برقرار شود. بر اساس تحلیل ما، تلاش اصلی یک هکر این است که وارد فهرستی شود که برای او باز نشده است. هکر می تواند Usecase اصلی را از طریق حمله رمز عبور خشونت آمیز (brute-force ( ، حمله امنیتی سوراخ امنیتی و شبیه سازی کاربران تهدید کند. این سه نوع حملات که توسط اعضای گروه ما به پایان رسید، به طور کلی و قدرتمندتر از دیگران بود.
5. برای درک چگونگی مقابله با Misusecaseها: برای هر تهدید چندین مکانیزم امنیتی وجود دارد. صرف نظر از این، Misusecaseها مستقیما به مکانیسم متمرکز نمی شوند، بنابراین هر یک از این ها می تواند برای ارائه یک ایده کلی انتخاب شود. ابتدا تصمیم گرفتیم از تلاش های ورود به سیستم برای شکست یک حمله خشونت آمیز (brute-force ( استفاده کنیم؛ دوم استفاده از سیستم فایروال برای حفاظت سیستم از هکرها ؛ اگر هکرها بخواهند وانمود كنند كه كاربر هستند، تا زماني كه تشخيص هویت كاربر انجام نشود ، همه Usecaseها در دسته کنترل امنیتی قرار دارند.
6. برای مستند سازی پرونده های Usecaseهای زیرسیستم و برخی Misusecaseها: این فرآیند غیر قابل اجتناب را می توان به عنوان مکمل اصطلاح در یک سیستم کاملا پیچیده مشاهده کرد.

بر این اساس، ما فکر نمیکردیم که در این مثال ضروری باشد.

نتیجه فرآیند نشان داده شده در شکل 4 به ما درک کاملی از توضیحات بالا را می دهد.

شکل 4 مرور کاتالوگ با Misusecaseها /usecaseها

4.2 انجام خرید با سوء استفاده /usecaseها از مورد

به منظور مقایسه دقیق تر و قانع کننده تر، Misusecaseها /usecaseها را در موارد دیگر تجارت همراه که در 3.2.2 ارائه شده است، انجام می دهیم. مراحل اصلی در این Usecase برای اطمینان از الزامات امنیتی همانند آخرین درخواست است، که خلاصه آن به شرح زیر است:

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

شکل 5 درخواست خرید را با Misusecaseها / Usecaseها انجام دهید.

با این حال، برخلاف مثال اول، مشخصات Usecase برای موارد زیر باید نوشته شود زیرا عملکرد این Usecaseها به ترتیب داده شده است: درخواست رمزگذاری باید پس از دو مورد دیگر باشد. این به این دلیل است که نیاز به رمزنگاری اطلاعات امنیت نیز دارد. شرح زیر برای درخواست رمزگذاری زیر است:

نام Usecase: درخواست رمزنگاری

خلاصه: سیستم درخواست خرید مشتری را رمزگذاری می کند.

بازیگر: سیستم

پیش شرط: تمام اطلاعات مورد نیاز سیستم (خرید و امنیت) آماده است.

شرح:

1. سیستم اطلاعات را از مشتریان جمع آوری می کند.
2. سیستم اطلاعات را رمزگذاری می کند.

جایگزین، گزینه ها:

اگر اطلاعات امنیت آماده نیست، سیستم باید منتظر بماند تا ارائه شود.

شرایط پست:   سیستم همه اطلاعات را رمزگذاری کرده است.

5. مقایسه

در این قسمت، شکل 2 و 4، شکل 3 و 5 مقایسه می شود. این جزئیات شباهت ها و تمایز بین Misusecaseها / Usecaseها و Usecaseها امنیتی از جنبه های مختلف را مشخص می کند. در زیر چیزهایی است که یافت شد:

(1). هدف از روش: اگرچه هر دو روش برای شناسایی نیازهای امنیتی مفید هستند، اما اهداف کاملا متفاوت دارند. از آنجا که Misusecaseها /usecaseها  اجازه می دهد که سوء استفاده کنندگان با موفقیت به برنامه های کاربردی روی آورند، این روش یک روش موثر برای تجزیه و تحلیل تهدیدات امنیتی است تا اینکه به طور مستقیم نیازهای امنیتی را مشخص کند. در مقابل، Usecaseهای امنیتی استفاده اجازه می دهد برنامه های کاربردی برای موفقیت خود را از تهدیدات مربوطه محافظت کنند. این اهداف آشکار ارائه الزامات امنیتی خاص است. بنابراین Usecaseهای امنیتی (SUCs) یک روش مستقیم تر نسبت به Misusecaseها /usecaseها (MUCs است که هنگام تهیه الزامات امنیتی مورد استفاده قرار می گیرد. از دیدگاه نویسنده، Usecaseها امنیتی عمدتا از Misusecaseها استفاده می کنند. با این وجود هیچ نمایش یا مشخصاتی در ارتباط آنها در هنگام استفاده از SUCs وجود ندارد. به عبارت دیگر، نقشه های SUC برای سمت چپ (تیم سفید) در قطعات MUC ایستاده است.

(2). اصطلاح Usecase: برای اولین تفاوت، MUC ها باید تهدیدات را از دیدگاه کاربران و عوامل خصمانه تحلیل کند؛ در حالی که SUCs فقط می تواند کاربران قانونی را استخدام کند. علاوه بر این، اصطلاح هایی که توسط دو روش مورد استفاده قرار می گیرند بسیار متفاوت هستند. از یک طرف، هر دو از فرم متنی برای Usecaseها استفاده می کنند؛ از سوی دیگر، MUC ها نمودار بازی را به عنوان اصطلاح اصلی استفاده می کنند، در حالی که SUC ها از نمودار ها به عنوان بیان دیگر متون استفاده می کنند. از این رو، ایجاد MUC ها لذت بخش تر از SUCs است.

(3). نتیجه نهایی: الزامات استخراج‌شده از MUCs و SUCs مهم‌ترین چیز برای تحلیل گران برای تخمین و درک آن‌ها هستند. از چهار شکل از این دو مورد، ما می‌توانیم ببینیم که الزامات مربوط به MUCs نسبت به آنها خاص‌تر هستند. هیچ یک از دو روش بر روی فن‌آوری‌های امنیت بتن (concrete) متمرکز نیستند. بنابراین برای بسیاری از سیستم‌ها، SUCs یک روش بسیار قابل‌استفاده مجدد برای بررسی نیازمندی‌های امنیتی هستند. این موارد کارآمدتر و مقرون‌به‌صرفه هستند چون استفاده مجدد از الزامات می‌تواند سرعت بالا داشته و منجر به کسر قابل‌توجه در هزینه‌های توسعه شود. با این حال، پیشنهاد کردن مکانیزم‌های قابل‌استفاده مجدد  به طور کامل برای سیستم‌های مختلف دشوار است. بنابراین برای برخی سیستم‌ها، MUCs هنوز نقش مهمی در استخراج نیازمندی‌های امنیتی ایفا می‌کنند. با این حال ، پتانسیل آن‌ها برای درک نتیجه مورد نیاز به تجربه تحلیل گران محدود می‌شود.

(۴). کشف اختلافها:  در MUCs هنگامی که دو حالت با یکدیگر در نمودار بازی درگیر می‌شوند، بررسی شده و از طریق نمودار بازی، اختلافهای آشکار شده توسط MUCs یافت می‌شوند. بر خلاف MUCs، SUCs از روش علمی و دقیق تری برای تعریف درگیری‌ها استفاده می‌کنند. این به عنوان زبان محدودیت شی(OCL) شناخته می‌شود که می‌تواند اختلافهای بالقوه را در پی داشته باشد . هنگامی که یک OCL برای اجرای  سیستم خرید به کار می‌رود، ممکن است دریابیم که اگر یک امضای دیجیتالی برای ارایه سرویس امنیتی غیر انکار کننده با یک عملکرد هش انجام شود، که یک سرویس یکپارچگی را نیز فراهم می‌کند و یک رابطه متقابل انحصاری ( صفر یا یک ) داشته باشد. به این معنا که اگر دو مکانیسم برای یک سرویس امنیتی وجود داشته باشد ، اختلافها وجود خواهند داشت زیرا آن‌ها می‌توانند با تصمیمات مشابه با آن‌ها مغایرت داشته باشند.

به طور کلی، در دو مثال، الزامات ناشی از Misusecaseها / Uscaseها را می توان در Misusecaseهای امنیتی استفاده کرد. در بیشتر موارد، Misusecaseهای امنیتی مناسب تر برای تعیین الزامات امنیتی است. با این وجود، Misusecase ها / Usecaseها  نیز می تواند به طور مستقل کار کند و از لحاظ نظری می تواند در جهت تقویت عملکرد Usecaseهای امنیتی استفاده کند زیرا آنها قادر به تحلیل شرایط خاص هستند. یک نمونه خوب در [6] بررسی شرایط امنیتی با ترکیب Misusecaseها  و Usecaseهای امنیتی وجود دارد.

6. نتیجه گیری

در این مقاله، عملکرد Misusecase ها / Usecaseها و Usecaseها امنیتی مقایسه شده است که برای بررسی نیازهای امنیتی مورد استفاده قرار می گیرد. هر دو روش دارای مزایا و معایب خاص خود هستند و برای انواع مختلف برنامه ها مناسب هستند. بدیهی است، استفاده از Usecaseها امنیتی برای سیستم های بزرگ موثر است. برای کارهای آینده استفاده از این دو روش برای بهبود اثربخشی آن‌ها ارزشمند است.

آدرس کانال تلگرام سایت بیگ دیتا:

t.me/bigdata_channel

آدرس کانال سروش ما:
https://sapp.ir/bigdata_channel

جهت دیدن سرفصل های دوره های آموزشی بر روی اینجا کلیک کنید.

 

7. منابع

• Alexander, Misuse cases: use cases with hostile intent , IEEE Software 20(1), 5866, Jan/Feb 2003.
• Alexander, Misuse cases help to elicit requirements non-functional , Computing & Control Engineering Journal, Volume 14, Issue 1, 40 45, Feb. 2003.
• Guttorm S., Donald F., Andreas L. Opdahl, A Reuse-Based Approach to Determining Security Requirements , Proceedings of the Ninth International Workshop on Requirements Engineering: Foundation for Software Quality, REFSQ’03, 127-136, 2003.
• Gomaa, H., Eonsuk Shin, M., Modelling complex systems by separating application and security concerns , Engineering Complex Computer Systems, 2004. Proceedings.

Ninth IEEE International Conference, 19  28, 14-16 April 2004.

• Popp, G., Jurjens, J., Wimmel, G., Breu, R., Security-critical system development with extended use cases , Software Engineering Conference, 2003. Tenth Asia-Pacific 2003, 478 487, 2003.
• Donald Firesmith, Security Use Cases , Journal of Object Technology, vol. 2, no. 3, 53-64, May-June 2003.
• Sindre, G., Opdahl, A.L., Eliciting security requirements by misuse cases , Technology of Object-Oriented Languages and Systems, 2000, TOOLS-Pacific 2000, Proceedings. 37th International Conference on 20-23 Nov. 2000, 120 131, 2000.  [8] I. Alexander, T. Zink, Introduction to systems engineering with use cases , Computing & Control Engineering Journal Volume 13, Issue 6, 289  297, Dec. 2002.

 

Visits: 751