Cloud__Computing cloud____computing.pptx

rmhmha1 11 views 31 slides Sep 02, 2025
Slide 1
Slide 1 of 31
Slide 1
1
Slide 2
2
Slide 3
3
Slide 4
4
Slide 5
5
Slide 6
6
Slide 7
7
Slide 8
8
Slide 9
9
Slide 10
10
Slide 11
11
Slide 12
12
Slide 13
13
Slide 14
14
Slide 15
15
Slide 16
16
Slide 17
17
Slide 18
18
Slide 19
19
Slide 20
20
Slide 21
21
Slide 22
22
Slide 23
23
Slide 24
24
Slide 25
25
Slide 26
26
Slide 27
27
Slide 28
28
Slide 29
29
Slide 30
30
Slide 31
31

About This Presentation

Cloud Computing


Slide Content

Secure Software Design & Programming تصميم وتطوير البرمجيات الآمنة مدرس المقرر: د. فهد آل قاسم

Course information - 1 مفردات المقرر مقدمة عامة Introduction . هجمة فيض الذاكرة المؤقتة Buffer overflow attack . التصميم الآمن Secure Design . فحص الإدخال Input Validation . الاستدعاء والمخرجات Output and Call-Out . طرق وأدوات تحليل الكود Analysis Approaches & Tools التعامل مع الأخطاء Error Handling . 2 التقييم 10% تكليفات 5 % مشاركة 10 % امتحان نصفي 25 % العملي 50 % الامتحان النهائي 100 إجمالي الدرجة النهائية

Course information - 2 التكليفات المطلوبة خلال المقرر : مطلوب من كل مجموعة القيام بالبحث عن هجمات/ثغرات برمجية متنوعة، سواء كانت ثغرات عامة، في كل اللغات، أو خاصة بلغة برمجة معينة، باستثناء تلك المخصصة لـ C/C ++ . على المجموعة فهم الهجمة وفهم التدابير المضادة لها، واعداد تقرير وافي بذلك. تبحث كل مجموعة، أيضا، عن أدوات تحليل الكود من منظور الحماية، وتختار أداة واحدة مجانية، أو أكثر، وتجري عليها تجربة تفحص أحد المشاريع البرمجية المصدرية المتاحة على النت، بلغة برمجة حديثة. تسلم المجموعة في نهاية الترم تقريرا مشروحا بالأمثلة العملية، عن الهجمة وتنفيذها وأساليب الحماية منها. وكذلك طريقة استخدام وتطبيق الأداة أو الأدوات التي اختاروها. تسلم أسماء المجموعات في المحاضرة الثالثة كحد أقصى، ولا تزيدا المجموعة الواحدة عن 3 طلاب، وأيا كان العدد فكل مجموعة مطالبة بنفس التقرير. يعتمد تقييم التكليفات على معايير الترتيب والتنظيم والتنوع، وكذلك التواصل والمناقشة خلال الترم . يتم العرض والتسليم في المحاضرة العاشرة. 3

Secure Software Design & Programming Introduction

Outline Why is most software insecure? Must consider security throughout lifecycle Weakness groupings Risk management/assurance cases Processes vs. phases/stages لماذا تعتبر أغلب البرامج غير آمنة؟ يجب مراعاة الأمان طوال دورة الحياة مجموعات نقاط الضعف حالات إدارة المخاطر/الضمان العمليات مقابل المراحل/الخطوات 5

Insecure software Insecure software may: Release private/secret information Corrupt information Lose service Costing: money time trust lives 6 قد يؤدي البرنامج غير الآمن إلى: كشف معلومات خاصة/سرية. إفساد المعلومات فقدان الخدمة. التكلفة: المال الوقت الثقة الحياة

Why is most software insecure? قليل من المطورين يعرفون كيفية تطوير برامج آمنة معظم المدارس لا تتضمنها في مناهجها الدراسية إذا كانت كذلك، فهي على مستوى الدراسات العليا الاختياري، وليست مطلوبة في مرحلة البكالوريوس كتب/دورات البرمجة لا تدرسها بعض العمليات الشائعة خطيرة بطبيعتها (خاصة C/C++) معظم المطورين لا يفكرون مثل المهاجمين: "كيف يمكن مهاجمة هذا؟"، كن متشككًا بعض الشيء!! المطورون لا يتعلمون من أخطاء الآخرين الأمنية معظم الثغرات الأمنية ناجمة عن نفس الأخطاء على مدار أكثر من 40 عامًا سنتعلم عن الأخطاء الشائعة... حتى لا ترتكبها لا يستطيع العملاء تقييم أمان البرامج بسهولة غالبًا ما لا يتم النظر في الأمان بجدية على سبيل المثال، في العقود والمتطلبات ومعايير التقييم لا يقوم المديرون دائمًا بتخصيص الموارد/التدريب بشكل كافٍ 7

Must consider security throughout lifecycle 8 Source: “Improving Security Across the Software Development Lifecycle – Task Force Report”, April 1, 2004. http://www.cyberpartnership.org/init.html ; based on Gary McGraw 2004, IEEE Security and Privacy. Fair use asserted. Developing secure software requires actions throughout lifecycle “Defense-in-breadth” "الدفاع الشامل " This class focuses on design & implementation (code) يتطلب تطوير البرامج الآمنة اتخاذ إجراءات طوال دورة الحياة

What do other organizations do? BSIMM Survey Building Security in Maturity Model (BSIMM) دراسة ( مسحية ) لمبادرات أمن البرمجيات في مختلف المنظمات يوضح النسبة المئوية للأنشطة المختلفة بين 109 منظمة تم استطلاع آرائها https://www.bsimm.com/ 4 domains (divided in 12 practices, divided into many activities) Governance . Intelligence. Secure Software Development Lifecycle (SSDL) Touchpoints. Deployment. 4 مجالات (مقسمة إلى 12 ممارسة، مقسمة إلى العديد من الأنشطة) الحوكمة: الممارسات التي تساعد في تنظيم وإدارة وقياس مبادرة أمن البرمجيات . الاستخبارات: الممارسات التي تؤدي إلى تجميع المعرفة المؤسسية المستخدمة في تنفيذ أنشطة أمن البرمجيات نقاط اتصال دورة حياة تطوير البرمجيات الآمنة (SSDL): الممارسات المرتبطة بتحليل وضمان عمليات وتطوير برامج معينة. النشر: الممارسات التي تتفاعل مع منظمات أمن الشبكات وصيانة البرامج التقليدية 9 Developing secure software requires more than design & code... but you need those fundamentals

Attacker, Cracker, Hacker Attack : الهجوم: "أي نوع من الأنشطة الخبيثة التي تحاول جمع أو تعطيل أو إنكار أو تدهور أو تدمير موارد نظام المعلومات أو المعلومات نفسها." Attacker : المهاجم : شخص يهاجم النظام (بدون إذن) Cracker : المخترق: "الشخص الذي يحاول الوصول إلى أنظمة الكمبيوتر دون إذن" (نوع من المهاجمين) Hacker: الهاكر: "الشخص الذي يستمتع بالحصول على فهم عميق للعمل الداخلي للنظام وأجهزة الكمبيوتر وشبكات الكمبيوتر على وجه الخصوص" [RFC 1392] خطأ شائع يقع فيه الصحفيون NOTE : Hacker ≠ attacker Most hackers don’t attack systems Many attackers aren’t hackers (might not be clever or knowledgeable ) 10

Security objectives Typical security objectives (CIA): الأهداف الأمنية النموذجية (CIA): الموثوقية : "لا يجوز قراءة غير مصرح بها" السلامة : "لا يجوز إجراء أي تعديل غير مصرح به (كتابة/حذف)" التوفر: "يستمر في العمل في ظل وجود هجوم" في بعض الأحيان يتم إدراج الأهداف أو الآليات الداعمة بشكل منفصل: عدم الإنكار (من المرسل و/أو المستقبل) الخصوصية (على سبيل المثال، حماية هوية المستخدم ) التدقيق/المساءلة/التسجيل الهوية ومصادقة [الهوية] (I&A)، والتفويض تم اختصار الأخيرين إلى AuthN و AuthZ 11

Authorization Once you have user identity and authentication, you can determine what they’re authorized to do بمجرد حصولك على هوية المستخدم والمصادقة عليه، يمكنك تحديد ما هو مصرح له بفعله Discretionary Access Control البيانات لها مالك، والمالك هو الذي يقرر من يمكنه القيام بماذا Mandatory Access Control تتمتع البيانات بخصائص معينة، ولا يمكن منح بعض حقوق الوصول حتى من قبل المالك (على سبيل المثال، التصنيف) Role Based Access Control (RBAC) تعيين المستخدمين إلى أدوار (ثابتة أو ديناميكية) تم منح الوصول إلى الدور، وليس للمستخدم مباشرة في بعض الأحيان تكون هناك قيود على العضوية (يجب ألا يكون الموظف المستلم وكيل شراء) 12

Auditing/Accountability/Logging التدقيق/المساءلة/التسجيل Record system actions, esp. security-relevant ones (e.g., log in) Detect unusual activity that might signal attack or exploitation لذا يمكنك اتخاذ الإجراء: افصل هذا الاتصال، وأغلق النظام، وقم بمقاضاة، ... قد يساعد في الاسترداد أو منع الاستغلال في المستقبل (من خلال معرفة ما حدث) غالبًا ما ترسل الأنظمة التشغيلية السجلات إلى أماكن أخرى إذا تم إفساد النظام، فلا يمكن تغيير إدخالات السجل القديمة 13

Weaknesses & Vulnerabilities Weakness: A type of defect/flaw that might lead to a failure to meet security objectives الضعف: نوع من العيوب/الخلل الذي قد يؤدي إلى الفشل في تحقيق أهداف الأمان Vulnerability: “Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited by a threat source” [CNSS 4009] الثغرة : "ضعف في نظام المعلومات، أو إجراءات أمن النظام، أو الضوابط الداخلية، أو التنفيذ الذي "قد يتم استغلالها من قبل مصدر التهديد" [CNSS 4009] 14

Weakness classifications Software is vulnerable because of some weakness that is exploitable عادة ما يكون الضعف غير مقصود عادة ما يكون الضعف (نوع/نوع الخلل) قد حدث آلاف المرات من قبل We’ll spend lots of time learning about weaknesses – so you won’t make the same mistakes Many weakness classification systems exist هناك العديد من أنظمة تصنيف الضعف Common Weakness Enumeration (CWE) – merged “Seven pernicious kingdoms”, etc. Key is to learn what these weaknesses are 15

Common Weakness Enumeration (CWE) Common Weakness Enumeration (CWE) = list of software weaknesses, Weakness = Type of vulnerabilities تعداد نقاط الضعف الشائعة (CWE) = قائمة نقاط الضعف في البرامج ، الضعف = نوع الثغرات الأمنية CWE-120 = Buffer Copy without Checking Size of Input (“Classic Buffer Overflow”) Common naming system: نظام التسمية المشترك Useful as “common name” (e.g., tool coordination) Does have some structuring/organization (slices, graphs, parents/children)… but that’s not its strength More info: http://cwe.mitre.org 16

Seven Pernicious Kingdoms الممالك السبع الخبيثة Input Validation and Representation API Abuse Security Features Time and State Error Handling Code Quality Encapsulation المصدر: تسيبينيوك، تشيس، وماكجرو ، " سبع ممالك خبيثة: تصنيف لأخطاء أمن البرمجيات "، وقائع مؤتمر SSATTM، 2005 17 Source: Tsipenyuk, Chess, and McGraw, “Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors”, Proceedings SSATTM, 2005

Abstract view of a program 18 Program Process Data (Structured Program Internals) Input Output Call-out to other programs (also consider input & output issues)

نظرة مجردة للبرنامج 19 برنامج بيانات العملية (البيانات الداخلية للبرنامج المنظم) مدخل الناتج نداء إلى برامج اخرى (ضع في اعتبارك أيضًا قضايا الإدخال والإخراج)

Risk Management should be part of entire system lifecycle Potential impacts of security vulnerabilities are a risk Manage that risk as part of risk management If complex to communicate, assurance case can help 20 Risk management process: Communication and consultation Establishing the context Risk assessment Risk identification Risk analysis Risk evaluation Risk Treatment Source: DoD Risk, Issue, and Opportunity Management Guide for Defense Acquisition Programs, January 2017, http://www.acq.osd.mil/se/docs/2017-RIO.pdf Source: ISO 31000:2009

يجب أن تكون إدارة المخاطر جزءًا من دورة حياة النظام بالكامل التأثيرات المحتملة لثغرات الأمن تشكل خطرًا إدارة تلك المخاطر كجزء من إدارة المخاطر إذا كان التواصل معقدًا، يمكن أن تساعدك حالة التأكيد 21 عملية إدارة المخاطر: التواصل والتشاور تحديد السياق تقييم المخاطر تحديد المخاطر تحليل المخاطر تقييم المخاطر معالجة المخاطر المصدر: إدارة المخاطر والقضايا والفرص بوزارة الدفاع دليل برامج المشتريات الدفاعية، يناير 2017، http://www.acq.osd.mil/se/docs/2017-RIO.pdf المصدر: ISO 31000:2009

Possible risk responses Avoid / eliminate تأكد من عدم حدوث المخاطر. الأفضل، ولكن ليس دائمًا عمليًا Control / reduce / mitigate Limit system privileges so if attacker “takes over” a program, that program cannot do everything Limit data available on potentially-attacked system Detect/respond/recover (quickly) Recover quickly when network denial-of-service ends Maintain protected backups, easy restore mechanism Transfer / share (e.g., outsourcing, insurance) Assume / accept / retain (budget for it !) النقطة الأساسية حول المخاطر لا يمكنك القضاء على جميع المخاطر! هدف جيد، ولكن ليس من الممكن تحقيقه دائمًا (بتكلفة معقولة) يمكنك إدارتهم ​ 22

Assurance case (ISO/IEC 15026) Assurance = Grounds for justified confidence that a claim has been/will be achieved (but how communicate that?) ISO/IEC 15026-2:2011 specifies defines structure & contents of an assurance case تسهيل الاتصالات بين أصحاب المصلحة واتخاذ القرارات الهندسية عادةً للمطالبات مثل السلامة والأمن ISO doesn’t mandate a graphical notation; primarily 3 in use: المطالبات والحجج والأدلة (CAE) - بسيطة للغاية تدوين هيكلة الهدف (GSN) - متطور، ويمكن أن يكون معقدًا نموذج حالة التأكيد المنظم (SACM) – يجمع بين السمات An assurance case includes: المطالبات: مطالبات من المستوى الأعلى لخاصية نظام أو منتج الحجج: الحجج المنهجية التي تبرر هذا الادعاء الأدلة/الافتراضات: الأدلة والافتراضات الصريحة التي تشكل أساس الحجة 23

Processes vs. stages/phases العمليات و المراحل ؟ ISO/IEC/IEEE 12207:2017, Systems and software engineering — Software life cycle processes Identifies processes in software, which are the same as ISO/IEC/IEEE 15288 (system life cycle processes) Processes aren’t stages/phases Process = “set of interrelated or interacting activities that transforms inputs into outputs” Stage (aka phase) = “period within the life cycle of an entity that relates to the state of its description or realization” [relate to major progress and achievement milestones…] [i.e., period of time ] العملية = "مجموعة من الأنشطة المترابطة أو المتفاعلة التي تحول المدخلات إلى مخرجات" المرحلة (أو الطور) = "فترة ضمن دورة حياة الكيان تتعلق بحالة وصفه أو تحقيقه" [تتعلق بمعالم التقدم والإنجاز الرئيسية...] [أي فترة زمنية] في الممارسة العملية تحدث العمليات بالتوازي 24

Basics of Unix/Linux/POSIX تركيزنا على التطبيقات الآمنة/برامج الخادم لا يتعلق الأمر بإنشاء أنظمة تشغيل آمنة ، مع أنها نفس المبادئ . يجب فهم نموذج الأمان للمكونات الداعمة (على سبيل المثال، نظام التشغيل وأنظمة إدارة قواعد البيانات) ، ( e.g., OS and DBMS) Focus on Unix/Linux/POSIX model, used in: Linux-based (Red Hat Enterprise, Fedora, Ubuntu, Debian , Android, …) Unix (*BSDs, Solaris, AIX, …) MacOS & iOS We will call these “Unix-like” systems MS Windows’ model is different in detail, though in many cases very similar (many analogies) 25

Kernel vs. User space Usually implemented as: Kernel: النواة: برنامج منخفض المستوى يتصل بالأجهزة وينفذ هياكل أساسية User space: Processes that run programs Some processes have special privileges Some long-running processes provide services (daemons) 26 Kernel User space Kernel

Users & Groups Each user is assigned user id (UID) – an integer يمكن لـ UID 0 ("المستخدم الجذر") تجاوز عناصر التحكم الأمنية يوجد ملف passwd يسرد اسم المستخدم ومعرف المستخدم الخاص به Users belong to at least one group كل مجموعة لها اسم ومعرف مجموعة (GID) - عدد صحيح في الممارسة العملية، يتمتع GID 0 أيضًا بامتيازات خاصة تسمح الأنظمة الحديثة للمستخدمين بالانتماء إلى العديد من المجموعات يوجد ملف/قائمة المجموعة فيها اسم المجموعة ومعرف المجموعة والعضوية Separate different users in a multi-user system Android: Applications have different UID/GID 27

Processes A process = a running program عملية = برنامج قيد التشغيل Same program may be run by >1 process Process may have multiple threads of control ترث العمليات معظم السمات والحقوق من عملية الإنشاء، وغالبًا ما تو رثها إلى المستخدم الذي أنشأها See running processes with command line: ps - ef Processes have various attributes 28

Files Files, aka filesystem objects (FSOs), can be read from or written to. Files may be: Regular (ordinary) file, character special file, block special file, FIFO special file, symbolic link, socket, and directory Pathname: A sequence of bytes to identify a file تبدأ أسماء المسارات المطلقة بـ "/" (الدليل الجذر) لا تبدأ أسماء المسارات العادية في الدليل الحالي تسلسل مكونات اسم المسار (أسماء الملفات) و"/" (فاصل الدليل) ما يطلق عليه الكثيرون "أسماء الملفات" هي رسميًا "مكونات مسار الاسم" قد تشير أسماء المسارات المختلفة إلى نفس الملف يمكنك إنشاء أسماء مستعارة متعددة لنفس الملف الأساسي إذا قمت بإزالة ملف، فقد يظل موجودًا عبر مسار آخر أسماء الملفات وأسماء المسارات لا تكون بالضرورة سلسلة أحرف قد تكون تسلسلات البايتات غير قانونية/لا معنى لها في الإعدادات المحلية الحالية (أو الأخرى ) 29

Sockets (for TCP/IP) Sockets represent network communication endpoints Today, network == Internet protocol (IP), and usually TCP (creates illusion of data flow) If you want to encrypt it, typically build encryption on top socket() bind() listen() accept() read()/ write() close()/ shutdown() Server Client socket() connect() read()/ write() close()/ shutdown() Establish connection

Released under CC BY-SA 3.0 This presentation is released under the Creative Commons Attribution- ShareAlike 3.0 Unported (CC BY-SA 3.0) license You are free: to Share — to copy, distribute and transmit the work to Remix — to adapt the work to make commercial use of the work Under the following conditions: Attribution — You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work) Share Alike — If you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one These conditions can be waived by permission from the copyright holder dwheeler at dwheeler dot com Details at: http://creativecommons.org/licenses/by-sa/3.0/ Attribute me as “David A. Wheeler” 31