ما هو الأمن السيبراني؟ ثلاثية CIA والخطر Risk للمبتدئين

كل أسبوع تقريباً تقرأ خبراً عن جهة تسربت بيانات عملائها، أو شركة توقفت خدماتها أياماً بسبب برنامج فدية، أو حساب رسمي استولى عليه شخص لا يعرفه أحد، وفي كل خبر تتكرر عبارة «الأمن السيبراني» حتى صارت تعني كل شيء: كلمة مرور الموظف، وجدار الحماية في الشبكة، وضوابط الهيئة الوطنية، وفريق يراقب الشاشات ليلاً. وإذا كنت مسؤولاً عن أي بيانات، ولو كانت ملف Excel فيه أسماء العملاء وأرقام جوالاتهم، أو بريد فريق صغير، أو موقع متجر، فأنت تسأل نفسك السؤال الذي يسأله كل من يبدأ: ماذا أحمي بالضبط؟ ومن ماذا؟ ومن أين أبدأ قبل أن أشتري أي أداة؟

والإجابة لا تبدأ بالأدوات، وإنما بلغة صغيرة يتكلم بها كل العاملين في هذا المجال: ثلاث كلمات تصف ما تحميه في البيانات (السرية والسلامة والتوافر)، وأربع كلمات تصف كيف يحدث الضرر (الأصل والثغرة والتهديد والخطر)، وكلمة واحدة تصف ما تفعله أنت (الضابط). ومن يملك هذه اللغة يستطيع أن يقرأ أي خبر اختراق ويعرف ما الذي فشل فيه، ويقرأ أي عرض من شركة أمنية ويعرف ماذا يغطي، ويقرأ الضوابط الأساسية للهيئة الوطنية للأمن السيبراني ويفهم لماذا رتبت بهذا الشكل. وهذا المقال هو أول مقال في مرحلة البداية في مسار الأمن السيبراني، وسوف نبني فيه هذه اللغة على ملف واحد صغير فيه بيانات عملاء، نراه يتسرب ويتعدل ويتوقف بأعيننا في تجربة تعمل على جهازك.

وسوف نناقش في هذا المقال ما يلي:

• ماذا يعني الأمن السيبراني Cybersecurity في التعريف الرسمي للهيئة الوطنية وفي معجم NIST، ولماذا يهمك التعريف قبل الأدوات.
• ثلاثية CIA: السرية Confidentiality والسلامة Integrity والتوافر Availability، مع حادثة موثقة لكل واحدة، وما يضاف إليها من خصائص.
• تجربة عملية في Container صغير: نشفر الملف ونتحقق من بصمته، ثم نعدل الملف المشفر دون معرفة كلمة المرور، ثم نملأ القرص حتى يتوقف الحفظ.
• الأصل Asset والثغرة Vulnerability والتهديد Threat والخطر Risk، وكيف ترتبط الأربع في سلسلة واحدة.
• سجل مخاطر Risk Register صغير ومصفوفة المخاطر Risk Matrix، وكيف ينقل ضابط واحد خطراً من الأحمر إلى الأخضر.
• أنواع الضوابط Controls: الوقائية والكاشفة والتصحيحية، والإدارية والتقنية والمادية.
• أخطاء شائعة عند من يبدأ، وجدول يلخص كل مفهوم بسؤال واحد، ثم إلى أين تذهب بعد هذا المقال.

ما هو الأمن السيبراني Cybersecurity؟ التعريف الذي تبني عليه

قد يتساءل البعض: لماذا نبدأ بتعريف، والقارئ يريد أن يحمي بياناته الآن؟ والإجابة على ذلك أن التعريف هو الذي يحدد حدود عملك، فإذا ظننت أن الأمن السيبراني هو «برنامج مكافح الفيروسات» فسوف تثبته وتنام مطمئناً وقاعدة بياناتك مكشوفة للإنترنت بكلمة مرور افتراضية، وإذا ظننته «فريقاً يراقب الشاشات» فسوف تنتظر أن تملك ميزانية لفريق قبل أن تفعل أي شيء. والتعريف الصحيح يقول لك ما الذي يدخل في مسؤوليتك وما الذي لا يدخل.

والتعريف الرسمي في المملكة نجده في ملحق المصطلحات في الضوابط الأساسية للأمن السيبراني ECC-2:2024، وهو مأخوذ من تنظيم الهيئة الوطنية للأمن السيبراني الصادر بالأمر الملكي رقم 6801 بتاريخ 11/02/1439هـ، ونصه أن الأمن السيبراني هو حماية الشبكات وأنظمة تقنية المعلومات وأنظمة التقنيات التشغيلية ومكوناتها من أجهزة وبرمجيات، وما تقدمه من خدمات، وما تحويه من بيانات، من أي اختراق أو تعطيل أو تعديل أو دخول أو استخدام أو استغلال غير مشروع، ويضيف التعريف أن المفهوم يشمل أمن المعلومات والأمن الإلكتروني والأمن الرقمي ونحو ذلك. لاحظ في هذا التعريف ثلاثة أشياء: أنه لا يذكر أداة واحدة، وأنه يحمي الخدمة والبيانات معاً لا الأجهزة وحدها، وأن الأفعال التي يمنعها (الاطلاع، والتعديل، والتعطيل) هي بالضبط الثلاثية التي سوف نشرحها بعد قليل.

أما الفرق بين الأمن السيبراني وأمن المعلومات Information Security، ومن أين جاء كل مصطلح وكيف تطور من تقارير السبعينيات إلى أطر اليوم، فقد خصصنا له مقالاً مستقلاً في هذه المرحلة، لأن القصة طويلة وتستحق أن تروى كاملة. وما يكفيك هنا أن الضوابط السعودية نفسها تعامل أمن المعلومات كجزء من الأمن السيبراني، وأن كل ما سوف تقرؤه في هذا المقال ينطبق على الاثنين.

وهناك ملاحظة يجب أن تتذكرها من البداية: لا توجد حماية آمنة بنسبة 100%، فكل نظام يعمل ويتصل بالناس وبالشبكة يحمل قدراً من المخاطرة، والهدف الواقعي هو أن تعرف أين تقع المخاطر الكبيرة عندك، وأن تخفضها إلى مستوى تقبله إدارتك وتستطيع العيش معه، وأن تكتشف المشكلة بسرعة وتتعافى منها إذا وقعت. وهذه الجملة الأخيرة، الاكتشاف والتعافي، هي ما يغيب عن أغلب من يبدأ، فيصرف كل جهده على المنع ثم يفاجأ بأنه لا يعرف أن شيئاً حدث إلا بعد أشهر.

ثلاثية CIA: ثلاثة أسئلة تسألها عن أي بيانات

خذ ملف العملاء الذي ذكرناه في البداية، ملف فيه رقم العميل واسمه وجواله ورصيده، واسأل عنه ثلاثة أسئلة: هل يستطيع أن يقرأه من لا يحق له؟ وهل يستطيع أحد أن يغير ما فيه دون أن تعرف؟ وهل تستطيع أنت أن تفتحه في اللحظة التي تحتاجه فيها؟ هذه الأسئلة الثلاثة هي ما يسميه المجال ثلاثية CIA، وهي اختصار للحروف الأولى من الكلمات الإنجليزية الثلاث، والصورة التالية تبينها على ملف العملاء:

وهذه الكلمات ليست اجتهاداً من مدرب أو كتاب، فمعهد NIST الأمريكي يعرف كل واحدة منها في معجمه، والضوابط الأساسية السعودية تعرفها في ملحقها بتعريفات قريبة جداً، والمعيار الأمريكي FIPS 199 بنى عليها طريقة تصنيف الأنظمة كلها: لكل نظام تسأل ما أثر فقدان السرية، وما أثر فقدان السلامة، وما أثر فقدان التوافر، ثم تعطي كل واحدة مستوى منخفضاً أو متوسطاً أو عالياً. وسوف نأخذ كل واحدة منها بالتفصيل.

السرية Confidentiality: من يستطيع أن يقرأ؟

يعرف معجم NIST السرية بأنها الحفاظ على القيود المصرح بها على الوصول إلى المعلومات والإفصاح عنها، بما فيها وسائل حماية الخصوصية والمعلومات الشخصية، والتعريف في الضوابط الأساسية يكاد يكون الترجمة نفسها. وبلغة أبسط: البيانات لا يراها إلا من يحق له أن يراها، في الوقت الذي يحق له فيه، وبالقدر الذي يحتاجه. ولاحظ كلمة «المصرح بها»، فالسرية لا تعني أن لا يرى البيانات أحد، وإنما أن يراها الأشخاص الصحيحون فقط، وموظف خدمة العملاء الذي يرى رقم جوال العميل لا يمس السرية، لكن نفس الموظف إذا أرسل الملف كاملاً إلى بريده الشخصي فقد مسها.

والسرية تفشل بطرق كثيرة، أشهرها اختراق من الخارج يسحب قاعدة البيانات، لكن أكثرها تكراراً في الواقع أبسط من ذلك: ملف مشترك برابط عام نسي صاحبه أن يغلقه، أو نسخة احتياطية على سيرفر مكشوف دون كلمة مرور، أو جهاز محمول سرق من سيارة وقرصه غير مشفر، أو موظف غادر الشركة وحسابه ما زال يعمل. والأدوات التي تحمي السرية معروفة: التشفير Encryption في التخزين وأثناء النقل، والتحكم في الوصول Access Control الذي يحدد من يقرأ ماذا، والمصادقة Authentication التي تتأكد أن الشخص هو من يقول إنه هو، وتصنيف البيانات Data Classification الذي يقول لك أي البيانات تستحق الحماية الأشد.

السلامة Integrity: هل تغيرت البيانات دون إذن؟

السلامة في تعريف NIST هي الحماية من التعديل أو الإتلاف غير السليم للمعلومات، وتشمل ضمان أصالة المعلومات Authenticity وعدم إنكارها Non-repudiation. وبلغة أبسط: الرصيد الذي في الملف هو الرصيد الصحيح، ولم يغيره أحد إلا من يحق له التغيير، وإذا غيره أحد فأنت تستطيع أن تعرف ذلك. ولاحظ الجزء الأخير، فالسلامة في الواقع لا تعني أن التعديل مستحيل، لأن من يملك صلاحية الكتابة على الملف يستطيع تعديله دائماً، وإنما تعني أن التعديل غير المصرح به يكتشف.

وفشل السلامة أخطر مما يبدو، لأنه صامت في الغالب: تسريب البيانات قد تعرف به من خبر أو من رسالة ابتزاز، وتوقف الخدمة تعرف به في الدقيقة نفسها، لكن تعديل سعر منتج أو رقم حساب بنكي في فاتورة أو سطر في كود برنامج قد يبقى أشهراً دون أن ينتبه له أحد، وكل قرار يبنى على هذه البيانات خلال تلك الأشهر يكون قراراً خاطئاً. ولهذا السبب تضيف الضوابط الأساسية السعودية كلمة «الدقة» Accuracy إلى الثلاثية في أكثر من موضع، فهدف مكون إدارة الأصول 2-1 مثلاً يتحدث عن الحفاظ على «السرية والسلامة والدقة والتوافر».

والأدوات التي تحمي السلامة هي دوال الهاش Hash Functions التي تعطي بصمة للملف تتغير إذا تغير بايت واحد فيه، والتوقيع الرقمي Digital Signature الذي يثبت من كتب البيانات وأنها لم تتغير بعده، وختم السلامة HMAC الذي يشبه البصمة لكنه يحتاج مفتاحاً سرياً، والصلاحيات التي تحدد من يكتب، والسجلات Logs التي تحفظ من غير ماذا ومتى، وضبط التغيير Change Management الذي يمنع أن يعدل أحد نظاماً حياً دون مراجعة.

التوافر Availability: هل تصل إلى البيانات وقت الحاجة؟

التوافر في تعريف NIST هو ضمان الوصول إلى المعلومات واستخدامها في الوقت المناسب وبطريقة موثوقة، وفي الضوابط السعودية «ضمان الوصول إلى المعلومات والبيانات والأنظمة والتطبيقات واستخدامها في الوقت المناسب». وكلمة «في الوقت المناسب» هي المهمة هنا، فبيانات تستعيدها بعد أسبوع من نسخة احتياطية لم تكن متوفرة خلال ذلك الأسبوع، ومتجر يعود للعمل بعد انتهاء موسم التخفيضات خسر ما كان يفترض أن يبيعه.

ولاحظ أن التوافر هو الضلع الوحيد في الثلاثية الذي يفشل كثيراً دون أي مهاجم: قرص ممتلئ، أو تحديث فاشل، أو انقطاع كهرباء، أو حذف بالخطأ، أو شهادة TLS انتهت صلاحيتها، وكلها تعطل الخدمة كما يعطلها هجوم حجب الخدمة DDoS أو برنامج الفدية Ransomware. ولهذا السبب لا يقتصر الأمن السيبراني على المخترقين، فمن يحمي التوافر يحمي من الخطأ البشري والعطل التقني بالقدر نفسه. والأدوات هنا هي النسخ الاحتياطي Backup واختبار الاستعادة، والتكرار Redundancy في السيرفرات والاتصالات والكهرباء، والمراقبة Monitoring التي تنبهك قبل امتلاء القرص، وخطط استمرارية الأعمال Business Continuity.

لماذا لا تستطيع أن ترفع الثلاثة إلى الحد الأقصى معاً؟

هناك مشكلة رئيسية في الثلاثية يجب أن تفهمها مبكراً: الأضلاع الثلاثة تتنافس في كثير من الأحيان، وكل قرار يقوي أحدها قد يضعف الآخر. فإذا شفرت ملف العملاء بكلمة مرور لا يعرفها إلا شخص واحد، فقد رفعت السرية إلى أعلى درجة، لكنك خفضت التوافر، لأن هذا الشخص إذا غاب أو نسي كلمة المرور فلن يفتح الملف أحد. وإذا أخذت عشر نسخ احتياطية ووزعتها على أماكن كثيرة، فقد رفعت التوافر، لكن كل نسخة إضافية مكان جديد قد تتسرب منه البيانات، أي أنك خفضت السرية إن لم تشفرها. وإذا طلبت موافقتين قبل أي تعديل على الأسعار، فقد رفعت السلامة، لكنك أبطأت العمل، وفي يوم ازدحام قد يتعطل تعديل عاجل لأن المدير الثاني في اجتماع.

وبالتالي فالسؤال الصحيح ليس «كيف أرفع الثلاثة» وإنما «أي ضلع هو الأهم لهذه البيانات بالذات». ففي ملف الرواتب السرية هي الأهم، وفي سجل العمليات المالية السلامة هي الأهم، وفي متجر يبيع في موسم معين التوافر هو الأهم، وفي سجلات المرضى في مستشفى قد تكون الثلاثة عالية معاً، فتدفع الثمن في التعقيد والتكلفة. وهذا بالضبط ما يطلبه منك معيار FIPS 199 حين يعطي كل ضلع مستوى أثر مستقلاً، وما سوف نفعله في سجل المخاطر بعد قليل.

ما الذي يضاف إلى الثلاثية؟ الأصالة وعدم الإنكار والمساءلة

مع الوقت أضاف المجال خصائص أخرى تشرح ما لا تشرحه الثلاثية بوضوح، وسوف تقابلها في الضوابط وفي أسئلة المقابلات:

• الأصالة Authenticity: أن تتأكد أن البيانات أو الرسالة جاءت فعلاً ممن يدعي أنه أرسلها، وهي في معجم NIST خاصية الأصل الحقيقي الذي يمكن التحقق منه والوثوق به. ورسالة بريد تبدو قادمة من المدير المالي تطلب تحويلاً عاجلاً هي فشل في الأصالة قبل أي شيء آخر.
• عدم الإنكار Non-repudiation: ألا يستطيع من فعل شيئاً أن ينكر أنه فعله، كمن وقع عقداً بتوقيع رقمي، وتعريفها في معجم NIST يربطها بالدليل الذي يثبت أصل البيانات وتسليمها.
• المساءلة Accountability: أن يرتبط كل فعل بشخص محدد، ولهذا السبب تكره فرق الأمن الحسابات المشتركة مثل admin الذي يستخدمه خمسة موظفين، فإذا حذف أحدهم شيئاً لن تعرف من هو.

وكل هذه الخصائص تعود في النهاية إلى الثلاثية، فالأصالة جزء من السلامة في تعريف NIST نفسه، والمساءلة تحتاج سجلات سليمة، لذلك تكفيك الثلاثية في أغلب النقاشات، واحتفظ بالخصائص الأخرى لما تحتاج إلى دقة أكبر.

تجربة عملية: ترى الثلاثية بعينك في Container واحد

الكلام عن السرية والسلامة يبقى مجرداً حتى ترى كل واحدة تعمل وتفشل أمامك، لذلك سوف نبني تجربة صغيرة لا تحتاج إلا Docker على جهازك، ولا تتصل بأي شيء خارجه. والفكرة أن نأخذ ملف عملاء صغيراً فيه بيانات وهمية، ونحميه بالتشفير، ونحسب بصمته، ثم نجرب ثلاث طرق للفشل: كلمة مرور خاطئة، وتعديل على الملف الأصلي، وتعديل على الملف المشفر نفسه، ثم نملأ قرصاً صغيراً حتى يتوقف الحفظ. وسوف نستخدم Docker Image الرسمية python:3.13.17-slim لأنها تحتوي على OpenSSL وأدوات GNU الأساسية دون أي تثبيت إضافي.

تجهيز الملف

أنشئ مجلداً فارغاً على جهازك، وافتح فيه Container بالأمر التالي، فيصبح المجلد متاحاً داخله في المسار /work:

mkdir cia-lab && cd cia-lab
docker run --rm -it --name cia-lab -v "$PWD":/work -w /work python:3.13.17-slim bash

وإذا كنت تعمل من Git Bash على Windows فأضف MSYS_NO_PATHCONV=1 قبل الأمر واستخدم "$(pwd -W)" بدل "$PWD"، والسبب أن Git Bash يحول المسارات التي تبدأ بشرطة مائلة إلى مسارات Windows فيفشل ربط المجلد. الآن داخل الـ Container ننشئ الملف بسطرين لعميلين وهميين:

printf 'id,name,phone,balance\n1,customer-a,0500000001,100\n2,customer-b,0500000002,250\n' > customers.csv
cat customers.csv

id,name,phone,balance
1,customer-a,0500000001,100
2,customer-b,0500000002,250

السرية: نشفر الملف ثم نجرب كلمة مرور خاطئة

نشفر الملف بالخوارزمية AES-256 في نمط CBC، ونشتق المفتاح من كلمة المرور بالدالة PBKDF2 مع 600000 تكرار، كما يشرح دليل الأمر openssl enc:

openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt -in customers.csv -out customers.enc -pass pass:Lab-Only-Pass-2026
ls -l customers.csv customers.enc
head -c 64 customers.enc | od -An -c | head -4

والمخرج سوف يكون كما يلي:

-rw-r--r-- 1 root root 78 Oct 28 08:16 customers.csv
-rw-r--r-- 1 root root 96 Oct 28 08:16 customers.enc
   S   a   l   t   e   d   _   _   M 016   y   @ 364   G 307   ?
   Z 323   -   c 234 260 244 340   { 214 026 213 311 313 346 356
 300 313   e   G  \v 371   > 265 017   u 364 221   C 253 272 211
   C   k   m 366 347   Z 305 226 373 334 301   _ 373 251 347 363

في المخرج أعلاه لاحظ التالي:

• حجم الملف الأصلي 78 بايت، والمشفر 96 بايت. والفرق 18 بايت يتكون من 16 بايت في البداية (كلمة Salted__ ثم ثمانية بايتات عشوائية اسمها الملح Salt) وبايتين من الحشو Padding الذي يكمل آخر كتلة إلى 16 بايت، لأن AES يعمل على كتل من 16 بايت.
• الملح يختلف في كل مرة تشفر فيها الملف، فإذا شفرت الملف نفسه بكلمة المرور نفسها مرتين ستحصل على ملفين مختلفين تماماً، وهذا مقصود حتى لا يعرف من يرى الملفين أنهما متطابقان.
• بعد الملح لا تقرأ شيئاً: لا الأسماء ولا الأرقام، وهذه هي السرية التي يحميها التشفير.
• الرقم 600000 هو عدد مرات تكرار الاشتقاق، وكلما زاد أبطأ كل محاولة تخمين لكلمة المرور، وسوف نرى أثر هذا الرقم بالتفصيل في مقال كلمات المرور في هذا المسار.

الآن نجرب ما يفعله من سرق الملف المشفر ولا يعرف كلمة المرور، فيحاول بكلمة أخرى:

openssl enc -d -aes-256-cbc -pbkdf2 -iter 600000 -in customers.enc -pass pass:wrong-pass

bad decrypt
4017A9A17B7F0000:error:1C800064:Provider routines:ossl_cipher_unpadblock:bad decrypt:../providers/implementations/ciphers/ciphercommon_block.c:107:
� ES����t����N��}?��ʰ�n���e`������A
�@$���
�'|��AH``

ولاحظ هنا أن OpenSSL طبع رسالة bad decrypt، لكنه طبع أيضاً حروفاً عشوائية: هذا ناتج فك التشفير بمفتاح خاطئ، وما كشف الخطأ هو أن الحشو في آخر الملف لم يكن صحيحاً. أي أن OpenSSL لم يعرف أن كلمة المرور خاطئة لأنه يقارنها بشيء، وإنما لأن الناتج جاء بشكل غير متوقع في آخره. وهذه الملاحظة الصغيرة تقودنا إلى أهم درس في التجربة كلها، كما سيأتي.

السلامة: بصمة الملف تكشف أي تعديل

نحسب بصمة الملف الأصلي بالدالة SHA-256 ونحفظها، ثم نتصرف كموظف غير الرصيد من 100 إلى 900 دون إذن، ثم نتحقق:

sha256sum customers.csv | tee customers.sha256
sed -i 's/,100$/,900/' customers.csv
cat customers.csv
sha256sum -c customers.sha256

b7a74c9482b9f5f4ed3c761e963af992554078c1492ec872727f6c2d2117bf18  customers.csv
id,name,phone,balance
1,customer-a,0500000001,900
2,customer-b,0500000002,250
customers.csv: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match

تغيير حرف واحد من 78 حرفاً أعطى بصمة مختلفة تماماً، فرفض sha256sum الملف وأعاد رمز خروج 1، وأي سكربت يعتمد على هذا الفحص يستطيع أن يتوقف هنا. وعندما نعيد الرقم إلى 100 يعود الفحص إلى customers.csv: OK. لكن انتبه إلى نقطة ضعف هذه الطريقة: البصمة محفوظة في ملف بجوار الملف الأصلي، فمن يستطيع تعديل الأول يستطيع غالباً أن يحسب بصمة جديدة ويكتبها في الثاني، ولذلك تحفظ البصمات في مكان لا يكتب فيه من يكتب في البيانات، أو تستخدم ختماً يحتاج مفتاحاً سرياً كما سنرى بعد قليل.

ماذا يحدث إذا عدل أحدهم الملف المشفر نفسه؟

هنا السؤال الذي يقع فيه كثيرون: الملف مشفر، والمهاجم لا يعرف كلمة المرور، فهل يستطيع أن يغير ما بداخله؟ أغلب الناس يجيبون بلا، لأنهم يظنون أن التشفير يحمي السرية والسلامة معاً. والتجربة التالية تجيب عن السؤال بشكل مختلف. نعرف أن الرقم 100 يقع في البايت 46 من الملف الأصلي، أي في الكتلة الثالثة (الكتل مرقمة من صفر وكل كتلة 16 بايت)، ونعرف من طريقة عمل نمط CBC أن كل كتلة بعد فك تشفيرها تدمج مع الكتلة المشفرة التي قبلها بعملية XOR. فإذا غيرنا البايت المقابل في الكتلة المشفرة السابقة، تغير البايت نفسه في الناتج بالقيمة التي نختارها. نعدل بايتاً واحداً في الملف المشفر بسكربت Python صغير، دون أن نعرف كلمة المرور أو المفتاح:

python3 - <<'PY'
data = bytearray(open('customers.enc', 'rb').read())
pt = open('customers.csv', 'rb').read()      # نستخدمه فقط لنعرف موضع الرقم، والمهاجم يعرفه من شكل الملف
off = pt.index(b',100\n') + 1
blk = off // 16
print("plaintext length", len(pt), "offset of 100 =", off, "in block", blk)
pos = 16 + (blk - 1) * 16 + (off % 16)       # 16 بايت للرأس والملح، ثم الكتلة السابقة
data[pos] ^= ord('1') ^ ord('9')
open('tampered.enc', 'wb').write(data)
PY
openssl enc -d -aes-256-cbc -pbkdf2 -iter 600000 -in tampered.enc -pass pass:Lab-Only-Pass-2026 | od -An -c | head -8
echo "exit=${PIPESTATUS[0]}"

plaintext length 78 offset of 100 = 46 in block 2
   i   d   ,   n   a   m   e   ,   p   h   o   n   e   ,   b   a
   9   #   I 346 355   u   t 334 264 270 375  \f 331 304 356 370
   -   a   ,   0   5   0   0   0   0   0   0   0   1   ,   9   0
   0  \n   2   ,   c   u   s   t   o   m   e   r   -   b   ,   0
   5   0   0   0   0   0   0   0   2   ,   2   5   0  \n
exit=0

والنتيجة كما تبينها الصورة التالية:

في المخرج أعلاه لاحظ التالي:

• رمز الخروج exit=0، أي أن OpenSSL فك التشفير بنجاح ولم يطبع أي تحذير، لأن الحشو في آخر الملف لم يتأثر.
• الكتلة الثانية (التي عدلنا فيها البايت) أصبحت حروفاً عشوائية، وهذا ثمن التعديل، لكن البرنامج لم يلاحظه.
• الكتلة الثالثة فيها 9 0 0 بدل 1 0 0، أي أن الرصيد أصبح 900 دون أن نعرف كلمة المرور. ولو كان الملف يحتوي على مبلغ تحويل أو رقم حساب، لكان المهاجم قد غيره بالطريقة نفسها.

والدرس هنا أن التشفير وحده يحمي السرية ولا يحمي السلامة، وأن نمطاً مثل CBC يسمح بتعديل محسوب في الناتج إذا عرف المهاجم شكل البيانات، وشكل ملفات العملاء والفواتير معروف في الغالب. والحل نوعان: إما أن تضيف ختم سلامة HMAC بمفتاح منفصل وتتحقق منه قبل فك التشفير، وإما أن تستخدم تشفيراً موثقاً Authenticated Encryption مثل AES-GCM أو ChaCha20-Poly1305 الذي يحسب الختم ويتحقق منه تلقائياً ويرفض الملف المعدل. وهذا ما يفعله ختم HMAC في التجربة نفسها:

openssl dgst -sha256 -hmac Lab-Only-Mac-Key customers.enc
openssl dgst -sha256 -hmac Lab-Only-Mac-Key tampered.enc

HMAC-SHA2-256(customers.enc)= 87943657075acecff9c97405ce5fb7b4064f167a56852694c5151286bcb8d204
HMAC-SHA2-256(tampered.enc)= 80751c77da595a7ac3fd9060a54681d9bd4b2218eb712af0859d2866374880af

الختمان مختلفان تماماً، ومن لا يعرف مفتاح الختم لا يستطيع أن يحسب ختماً صحيحاً للملف المعدل، على عكس البصمة العادية في الخطوة السابقة. وهذا هو الفرق بين بصمة SHA-256 التي يحسبها أي أحد، وختم HMAC الذي يحسبه من يملك المفتاح فقط. وفي التطبيق العملي لا تبني هذه الأشياء بيدك: البروتوكولات الحديثة مثل TLS 1.3 لا تستخدم إلا التشفير الموثق، وأدوات النسخ الاحتياطي الجيدة تتحقق من سلامة كل كتلة، والمهم أن تعرف السؤال الذي تسأله لأي أداة تشفير: هل تكتشف التعديل، أم تحمي القراءة فقط؟

التوافر: القرص الممتلئ يوقف الخدمة دون أي مهاجم

الضلع الثالث نجربه بطريقة مختلفة، لأن أكثر ما يعطل التوافر في الشركات الصغيرة ليس هجوماً وإنما قرص امتلأ بالسجلات أو بالنسخ الاحتياطية القديمة. نشغل Container جديداً ونعطيه قرصاً مؤقتاً في الذاكرة حجمه 2 MB فقط بالخيار --tmpfs، ثم نكتب فيه «طلبات» حجم كل واحد 100 KB حتى يمتلئ، ثم نحاول أن نحفظ طلباً جديداً كما يفعل أي تطبيق:

docker run --rm --name cia-avail --tmpfs /data:size=2m python:3.13.17-slim sh -c '
cd /data; i=0
while true; do
  i=$((i+1))
  if ! head -c 102400 /dev/urandom > order-$i.bin 2>/tmp/err.txt; then
    echo "order $i failed: $(cat /tmp/err.txt)"; break
  fi
done
df -h /data | tail -1
ls | wc -l
python3 -c "open(\"/data/new-order.json\",\"w\").write(\"{}\"*10000)"'

order 21 failed: head: error writing 'standard output': No space left on device
tmpfs           2.0M  2.0M     0 100% /data
21
Traceback (most recent call last):
  File "<string>", line 1, in <module>
    open("/data/new-order.json","w").write("{}"*10000)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^
OSError: [Errno 28] No space left on device

عشرون طلباً حفظت، والطلب 21 فشل برسالة No space left on device، ثم فشل التطبيق نفسه حين حاول أن يحفظ طلباً جديداً بالخطأ رقم 28. ولاحظ تفصيلة صغيرة: في المحاولة الأولى لهذه التجربة كنا نكتب رسالة الخطأ في ملف داخل القرص الممتلئ نفسه، فخرجت الرسالة فارغة، لأن ملف الخطأ لم يجد مكاناً يكتب فيه. وهذا يحدث في الإنتاج بالضبط: التطبيق الذي يكتب سجلاته على القرص نفسه الذي امتلأ يتوقف عن تسجيل سبب توقفه، فتبحث عن السبب في سجلات فارغة. لذلك راقب المساحة الحرة بتنبيه قبل أن تصل إلى الصفر بوقت كاف، وضع السجلات على قسم منفصل أو أرسلها إلى سيرفر سجلات مركزي، وفعل تدوير السجلات Log Rotation.

وفي نهاية التجربة اخرج من الـ Container الأول بالأمر exit، ولا يبقى شيء يحتاج حذفاً لأننا شغلنا الاثنين بالخيار --rm، والقرص المؤقت يختفي مع الـ Container الثاني.

الأصل والثغرة والتهديد والخطر: كيف يحدث الضرر؟

الثلاثية تقول لك ما الذي يمكن أن يفشل، لكنها لا تقول لك كيف يفشل ولا ما الذي تبدأ به، ولذلك يستخدم المجال أربع كلمات أخرى تصف الطريق إلى الضرر. وهذه الكلمات تتكرر في كل إطار وكل تقرير تدقيق، والخلط بينها هو أكثر ما يربك من يبدأ، فيقول «عندنا تهديد» وهو يقصد ثغرة، أو «الخطر عالي» وهو يقصد أن الثغرة خطيرة. والصورة التالية تبين كيف ترتبط الأربع:

الأصل Asset: ما الذي له قيمة عندك؟

الأصل في تعريف الضوابط الأساسية هو أي شيء ملموس أو غير ملموس له قيمة للجهة، ويذكر التعريف الأشخاص والأجهزة والمرافق والبرمجيات والخدمات، ثم أشياء أقل وضوحاً مثل المعلومات وسمعة الجهة وصورتها والمهارات والمعرفة. وتعريف NIST قريب منه. ولاحظ أن الأصل ليس جهازاً فقط: ملف العملاء أصل، والحساب الرسمي للشركة في منصات التواصل أصل، والموظف الوحيد الذي يعرف كيف يعمل نظام الفوترة أصل، وثقة العملاء أصل يضيع في يوم واحد إذا تسربت بياناتهم.

وأول خطوة عملية في أي برنامج أمن هي جرد الأصول Asset Inventory، ولهذا السبب جاء مكون إدارة الأصول 2-1 أول مكونات الدفاع في الضوابط الأساسية: لا تستطيع أن تحمي سيرفراً لا تعرف أنه موجود، ولا أن تحدث برنامجاً لا تعرف أنك تشغله. وتذكر أن شركة Equifax لم تحدث النظام المصاب لأنها لم تعرف أنه يستخدم البرنامج المصاب، أي أن فشل الجرد سبق فشل التحديث. والجرد في شركة صغيرة لا يحتاج أداة في البداية: جدول فيه كل جهاز وكل سيرفر وكل خدمة سحابية وكل حساب مهم، ومن يملكه، وما البيانات التي عليه، وما مدى أهميته.

الثغرة Vulnerability: أين يقع الضعف؟

الثغرة في تعريف الضوابط الأساسية هي ضعف في أي أصل تقني (مثل البرمجيات والأنظمة) أو في إجراء أو ضابط أو أي شيء آخر، يمكن استغلاله للتأثير سلباً على الأمن السيبراني. ولاحظ أن التعريف لا يحصر الثغرة في البرمجيات، وهذا مهم لأن الثغرات ثلاثة أنواع تقريباً:

• ثغرة تقنية: خطأ في كود برنامج له رقم CVE، أو إعداد خاطئ مثل قاعدة بيانات تقبل الاتصال من الإنترنت بكلمة مرور افتراضية، أو منفذ إدارة مفتوح لا داعي له.
• ثغرة في الإجراء Process: لا يوجد إجراء لإغلاق حسابات من يغادر الشركة، أو التحويلات المالية تتم بموافقة شخص واحد عبر البريد، أو لا أحد يختبر النسخ الاحتياطية.
• ثغرة بشرية: موظف لا يعرف شكل رسالة التصيد، أو يكتب كلمة المرور على ورقة بجوار الشاشة، أو يستخدم كلمة مرور بريده الشخصي نفسها في حساب العمل.

والثغرة وحدها لا تسبب ضرراً، فهي باب مفتوح في غرفة قد لا يمر بها أحد، لكنها تصبح خطراً حقيقياً حين يوجد من يعرف بالباب ويريد الدخول منه. وقد شرحنا في مقال مصطلحات الأمن السيبراني للمبتدئين كيف توصف الثغرات التقنية برقم CVE ودرجة CVSS وقائمة KEV، فلن نكرره هنا.

التهديد Threat: من أو ما الذي قد يسبب الضرر؟

التهديد في الضوابط الأساسية هو أي شيء يمكن أن يؤثر سلباً على الأمن السيبراني، وفي تعريف NIST أي ظرف أو حدث قد يضر بعمليات الجهة أو أصولها أو أفرادها عبر نظام معلومات، بالدخول غير المصرح به أو الإتلاف أو الإفصاح أو التعديل أو حجب الخدمة. والجهة التي تقف خلف التهديد تسمى مصدر التهديد Threat Source أو الفاعل Threat Actor، ويمكن أن تقسمها كما يلي:

والدرس من هذا الجدول أن أكثر ما يهدد شركة صغيرة ليس الجهات التي تدعمها الدول، وإنما المهاجم الانتهازي الذي يمسح الإنترنت كله بحثاً عن أي سيرفر لم يحدث، والخطأ الداخلي، والعطل. فمن يقرأ الأخبار يظن أن عدوه جهاز استخبارات، بينما عدوه الحقيقي سكربت آلي يجرب كلمات مرور شائعة على كل عنوان IP في العالم، وقرص لم يراقبه أحد.

الخطر Risk: الاحتمال في الأثر

الخطر هو الكلمة التي تجمع الثلاث السابقة، وهو في تعريف NIST مقياس لمدى تعرض الجهة لظرف أو حدث محتمل، ويحسب عادة من الأثر الضار إذا وقع الحدث، ومن احتمال وقوعه. وبالتالي فالمعادلة التي سوف تقابلها في كل مكان هي: الخطر = الاحتمال Likelihood × الأثر Impact. والاحتمال يرتفع إذا كانت الثغرة معروفة وسهلة الاستغلال والأصل مكشوفاً للإنترنت، والأثر يرتفع إذا كانت البيانات حساسة أو الخدمة لا تحتمل التوقف. ودليل NIST لتقييم المخاطر SP 800-30 يشرح هذه الطريقة بالتفصيل لمن يريد التعمق.

والفكرة التي تجعل هذه المعادلة مفيدة أنك تستطيع أن تخفض الخطر من طرفين: تخفض الاحتمال بإصلاح الثغرة أو بإبعاد الأصل عن الإنترنت أو بإضافة مصادقة ثنائية، وتخفض الأثر بالتشفير (فالبيانات المسروقة لا تقرأ) أو بالنسخ الاحتياطي (فالبيانات المحذوفة تستعاد). ولاحظ أن المعادلة تعطي صفراً إذا غاب أي طرف: سيرفر فيه ثغرة حرجة لكنه لا يحمل شيئاً له قيمة وغير متصل بأي شيء، خطره منخفض مهما بدت الثغرة مخيفة، وهذه الفكرة نفسها هي ما يجعل مقال إدارة الثغرات يرتب الإصلاح بالتعرض والاستغلال لا بدرجة الخطورة وحدها.

من القائمة إلى الأولويات: سجل المخاطر Risk Register

لنفرض أنك جلست ساعة وكتبت ما يمكن أن يسوء في بيانات العملاء والمتجر الذي يخدمهم، فخرجت بخمسة مخاطر، كل واحد منها يمس ضلعاً من الثلاثية. والخطوة التالية أن تعطي كل خطر رقماً من 1 إلى 5 للاحتمال ورقماً من 1 إلى 5 للأثر، وتضربهما، ثم ترتب. وهذا ما يسميه المجال سجل المخاطر Risk Register، ويكفي في البداية أن يكون جدولاً أو سكربتاً صغيراً مثل التالي:

# Small risk register: likelihood (1-5) x impact (1-5)
risks = [
  ("customer DB copied by an outsider",   "customers.csv / DB", "C", 3, 5),
  ("prices changed without notice",       "price list",         "I", 2, 4),
  ("store down during the sale",          "web store",          "A", 3, 4),
  ("laptop with files stolen",            "sales laptop",       "C", 2, 3),
  ("backup cannot be restored",           "backups",            "A", 2, 5),
]
level = lambda s: "high" if s >= 15 else "medium" if s >= 8 else "low"
print(f"{'risk':38} {'CIA':3} {'L':>2} {'I':>2} {'score':>5}  level")
for r, asset, cia, l, i in sorted(risks, key=lambda x: -x[3]*x[4]):
    print(f"{r:38} {cia:3} {l:>2} {i:>2} {l*i:>5}  {level(l*i)}")
# a control (encryption + MFA) lowers likelihood of the top risk from 3 to 1
l, i = 1, 5
print("\nafter control on the first risk: score", l*i, level(l*i))

نشغله في الـ Container نفسه بالأمر python3 risk.py، والمخرج سوف يكون كما يلي:

risk                                   CIA  L  I score  level
customer DB copied by an outsider      C    3  5    15  high
store down during the sale             A    3  4    12  medium
backup cannot be restored              A    2  5    10  medium
prices changed without notice          I    2  4     8  medium
laptop with files stolen               C    2  3     6  low

after control on the first risk: score 5 low

والصورة التالية تضع هذه المخاطر الخمسة على مصفوفة المخاطر Risk Matrix، وهي الشكل الذي سوف تراه في أغلب تقارير المخاطر:

في المخرج والمصفوفة أعلاه لاحظ التالي:

• الخطر الأعلى ليس أكثرها «إثارة»، وإنما الذي يجمع احتمالاً متوسطاً وأثراً كارثياً: نسخ قاعدة العملاء. وتوقف المتجر جاء ثانياً لأن احتماله أعلى من احتمال تعديل الأسعار.
• الخطر الثالث، النسخة الاحتياطية التي لا تستعاد، احتماله منخفض في ظنك لكن أثره 5، وهو بالضبط ما وقع في حادثة GitLab، لذلك لا تتركه في آخر القائمة لأن رقمه أقل من غيره.
• بعد الضابط (تشفير القاعدة ومصادقة ثنائية على حسابات الإدارة) بقي الأثر 5، لأن تسريب القاعدة ما زال كارثياً لو وقع، لكن الاحتمال نزل إلى 1، فنزل الخطر من 15 إلى 5. وما يبقى بعد الضابط يسمى الخطر المتبقي Residual Risk.
• الأرقام هنا تقديرية، والمهم ليس دقتها وإنما أن تقارن المخاطر ببعضها بالمقياس نفسه، فتصرف وقتك القليل على ما يهم أولاً.

وبعد ترتيب المخاطر يأتي القرار في كل خطر، وله أربعة خيارات فقط: أن تخففه Mitigate بضابط كما فعلنا، أو تنقله Transfer إلى غيرك بتأمين أو بعقد مع مزود خدمة، أو تتجنبه Avoid بأن تتوقف عن النشاط الذي يسببه (لا تحتفظ بأرقام البطاقات أصلاً)، أو تقبله Accept بقرار موثق من الإدارة لأن تكلفة تخفيفه أكبر من أثره. وقد شرحنا هذه الخيارات ومعها المصطلحات التي يستخدمها المدقق في مقال مصطلحات GRC للمبتدئين.

الضوابط Controls: ما الذي تضعه بين التهديد والأصل؟

الضابط في معجم NIST هو إجراء حماية أو تدبير مضاد يوضع لنظام معلومات أو جهة ليحمي السرية والسلامة والتوافر، وهذا التعريف يعيدنا إلى الثلاثية مرة أخرى. وبلغة أبسط: الضابط هو أي شيء تفعله لتخفض الاحتمال أو الأثر في خطر محدد. ويقسم المجال الضوابط بطريقتين في الوقت نفسه، بحسب متى تعمل، وبحسب نوعها، والصورة التالية تجمع الطريقتين:

• الوقائي Preventive: يمنع الحدث قبل أن يقع، مثل المصادقة الثنائية والتشفير والجدار الناري وإغلاق المنافذ غير المستخدمة. وهو أول ما يفكر فيه الناس، وأكثر ما يفشل وحده.
• الكاشف Detective: يكتشف الحدث أثناء وقوعه أو بعده، مثل تنبيه الدخول من مكان غريب وفحص البصمات ومراجعة السجلات. وفي حادثة Equifax كان الضابط الكاشف موجوداً لكنه متوقف بسبب شهادة منتهية، فبقي المهاجمون 76 يوماً.
• التصحيحي Corrective: يعيدك إلى الحالة السليمة بعد الحدث، مثل الاستعادة من نسخة احتياطية وتثبيت التحديث وخطة الاستجابة للحوادث.

ومن جهة النوع، الضابط الإداري Administrative هو سياسة أو إجراء أو تدريب يكتبه الناس وينفذونه، والتقني Technical هو ما تنفذه الأنظمة تلقائياً، والمادي Physical هو ما يحمي المكان والأجهزة نفسها مثل الأقفال وكاميرات المراقبة. ويجب أن تتذكر أن أي خطر مهم يحتاج أكثر من خانة واحدة في هذا الجدول، فالضابط الوقائي سوف يفشل يوماً ما، والسؤال حينها هل لديك ما يكتشف الفشل، وهل لديك ما يعيدك. وهذه الفكرة، طبقات من الضوابط بدل ضابط واحد، هي موضوع مقال الدفاع متعدد الطبقات Defense in Depth في هذا المسار.

ولاحظ أيضاً أن الضوابط الأساسية للهيئة الوطنية مكتوبة بهذا المنطق نفسه: كل مكون فيها يبدأ بضابط يطلب أن تحدد المتطلبات وتوثقها وتعتمدها (ضابط إداري)، ثم ضابط يطلب أن تطبقها (تقني في الغالب)، ثم ضابط يحدد الحد الأدنى منها، ثم ضابط يطلب أن تراجعها دورياً (كاشف). فإذا قرأت المكون 2-3 مثلاً ستجد في حده الأدنى الحماية من البرمجيات الضارة على الأجهزة والسيرفرات (2.3.3.1)، وإدارة حزم التحديثات والإصلاحات (2.3.3.3)، وهذه بالضبط ضوابط من الجدول أعلاه. وشرح طريقة قراءة الضوابط كاملة موجود في مقال الضوابط الأساسية NCA ECC بلغة بسيطة.

الأمن ليس منتجاً تشتريه: الناس والإجراءات والتقنية

إذا راجعت الحوادث الثلاث التي ذكرناها ستجد أن أياً منها لم يقع لأن الجهة لم تشتر منتجاً أمنياً. فشركة Equifax كانت تملك جهاز مراقبة لكنه متوقف، وكانت تعرف بالثغرة لكن إجراء التحديث لم يصل إلى النظام القديم. وفريق GitLab كان يملك خمس طرق للنسخ الاحتياطي، لكن أحداً لم يختبر الاستعادة منها بانتظام. وحادثة SolarWinds وقعت في مكان يثق به الجميع. وبالتالي فالأمن السيبراني يقوم على ثلاثة أشياء معاً يسميها المجال الناس والإجراءات والتقنية People, Process, Technology: موظف يعرف ما يفعل، وإجراء مكتوب يقول متى ومن، وأداة تنفذ وتسجل. وأي واحد منها دون الآخرين لا يعمل، فالأداة دون إجراء تبقى متوقفة كجهاز Equifax، والإجراء دون ناس يعرفونه يبقى ورقة في درج، والناس دون أدوات يتعبون في عمل يدوي ينسونه مع الوقت.

وقد يتساءل البعض: إذا كان الأمر كذلك، فلماذا تمتلئ السوق بالمنتجات الأمنية؟ والإجابة أن المنتجات تحل جزءاً حقيقياً من المشكلة، لكنها تباع أحياناً على أنها الحل كله، ولذلك خصصنا مقالاً لمقارنة حلول الأمن التجارية وبدائلها مفتوحة المصدر. والقاعدة التي تحتاجها الآن: لا تشتر أداة قبل أن تعرف أي خطر في سجلك تخفضه، ومن سوف يقرأ تنبيهاتها كل يوم.

أخطاء شائعة Common Mistakes عند من يبدأ

• اعتبار التشفير حلاً لكل شيء: رأينا في التجربة أن التشفير في نمط CBC دون ختم سلامة يسمح بتعديل محسوب، وأن التشفير لا يحمي التوافر بل قد يضره إذا ضاع المفتاح. اسأل عن كل أداة: أي ضلع تحمي بالضبط؟
• نسيان التوافر لأنه «ليس أمناً»: القرص الممتلئ والنسخة الاحتياطية التي لا تستعاد يوقفان العمل كما يوقفه برنامج الفدية، والضوابط الأساسية تخصص مكوناً كاملاً للنسخ الاحتياطي والاستعادة (2-9) ومكوناً لصمود الأمن السيبراني في استمرارية الأعمال (3-1).
• الخلط بين الثغرة والخطر: ثغرة بدرجة 9.8 في برنامج لا تشغله ليست خطراً عليك، وثغرة متوسطة في بوابة مكشوفة للإنترنت قد تكون أكبر خطر عندك. الخطر يحتاج أصلاً له قيمة وتهديداً قادراً معاً.
• البدء بالأدوات قبل الجرد: لا تستطيع أن تحمي ما لا تعرف أنه موجود، وأول سؤال يسأله أي مدقق: أين قائمة أصولك؟
• الاكتفاء بالضوابط الوقائية: من يبني جداراً عالياً دون كاميرا لا يعرف متى قفز أحدهم فوقه. ضع لكل خطر مهم ضابطاً يكتشف وضابطاً يعيد.
• تقدير المخاطر مرة واحدة ونسيانها: الأصول تتغير والتهديدات تتغير، وسجل المخاطر الذي كتب قبل سنتين لا يعرف عن السيرفر الذي أضفته الشهر الماضي. راجعه مرة كل ربع سنة على الأقل، وعند أي تغيير كبير.
• ظن أن الشركة الصغيرة لا يستهدفها أحد: أغلب الهجمات آلية لا تعرف اسم شركتك ولا يهمها، وإنما تبحث عن أي سيرفر ضعيف، والمسح يصل إلى عنوانك خلال دقائق من تشغيله.

جدول المفاهيم: سؤال واحد لكل مفهوم

قائمة تحقق لأول أسبوع

• اكتب جرداً بالأصول: الأجهزة والسيرفرات والخدمات السحابية والحسابات المهمة والبيانات الحساسة، ولكل منها مالك.
• صنف البيانات المهمة: لكل نوع اسأل أي ضلع من الثلاثية هو الأهم، وما أثر فقدانه من 1 إلى 5.
• اكتب خمسة إلى عشرة مخاطر، وأعطها احتمالاً وأثراً، ورتبها، واختر أعلى ثلاثة تعمل عليها هذا الشهر.
• تأكد أن الأقراص في الأجهزة المحمولة مشفرة، وأن النسخ الاحتياطية مشفرة وفي مكان منفصل.
• جرب استعادة ملف واحد من النسخة الاحتياطية اليوم، لا عند الحاجة.
• فعل التنبيه على امتلاء الأقراص وعلى الدخول إلى حسابات الإدارة.
• راجع الحسابات المشتركة، واستبدلها بحساب لكل شخص حيث تستطيع.

إلى أين بعد هذا المقال؟

هذا المقال هو الأساس الذي تبنى عليه بقية مرحلة البداية، فبعده تأتي قصة المصطلحات نفسها من أمن الحاسب في السبعينيات إلى الأمن السيبراني اليوم، ثم أشهر الهجمات التي تصيب المبتدئين والشركات الصغيرة وكيف تدافع عنها، ثم ما تحتاج أن تتعلمه قبل التخصص، ثم أول عشر خطوات لتأمين مؤسسة صغيرة. والمقالات التالية في المرحلة نفسها تعمق ما بدأناه هنا: المصطلحات التي تقابلها في كل عرض أمني، وطريقة تفكير المهاجم، ونمذجة التهديدات في تصميم التطبيقات، والأدوار الوظيفية في المجال:

دليلمصطلحات الأمن السيبراني للمبتدئين: من CVE إلى Purple Teamماذا تعني الكلمات التي تتكرر في كل عرض أمني، من رقم الثغرة وخطورتها إلى أدوات المراقبة SOC والفرق الحمراء والزرقاء.دليلMITRE ATT&CK: كيف يفكر المهاجم خطوة بخطوةلغة موحدة لسلوك المهاجمين مبنية على حوادث موثقة، نقرأ بها هجوم فدية حقيقياً مرحلة بمرحلة ونربط كل خطوة بالدفاع المقابل.دليلنمذجة التهديدات Threat Modeling للمبتدئينكيف تسأل ما الذي قد يسوء في تصميم تطبيقك قبل أن تكتب الكود، وتقرر لكل تهديد هل تصلحه أو تقبله، مع قالب جاهز للنسخ.دليلمصطلحات GRC للمبتدئين بمثال من شركة صغيرةما الذي يعنيه GRC فعلاً، وما الكلمات التي يستخدمها المدقق، وكيف تثبت له أن ضوابطك تعمل كما تقول.دليلالضوابط الأساسية للأمن السيبراني NCA ECC بلغة بسيطةكيف تقرأ الضوابط الأساسية ECC دون أن تضيع في أرقامها، وعلى من تنطبق، وما المطلوب من جهتك فعلاً في كل مكون.دليلأدوار الأمن السيبراني Careers: ماذا يعمل كل دور، ومن أين تبدأ؟تسعة أدوار في الأمن السيبراني من المراجع الرسمية: اليوم العادي والمهارات والأدوات، ومن أي مستوى يبدأ كل دور.

الخلاصة

وصلنا لنهاية الموضوع، وقد رأينا أن الأمن السيبراني ليس أداة ولا فريقاً، وإنما طريقة في التفكير تبدأ بسؤال ماذا أحمي ومن ماذا. وأهم ما يجب أن تتذكره:

• التعريف الرسمي في المملكة يحمي الشبكات والأنظمة والخدمات والبيانات من الاختراق والتعطيل والتعديل والاستخدام غير المشروع، ويشمل أمن المعلومات.
• السرية تعني أن لا يقرأ البيانات إلا من يحق له، والسلامة أن يكتشف أي تعديل غير مصرح به، والتوافر أن تصل إليها وقت الحاجة، والثلاثة تتنافس فاختر الأهم لكل نوع من البيانات.
• التشفير وحده لا يحمي السلامة: بايت واحد في ملف مشفر بنمط CBC غير الرصيد من 100 إلى 900 دون أي رسالة خطأ، والحل ختم HMAC أو تشفير موثق.
• التوافر يفشل دون أي مهاجم، والقرص الممتلئ يوقف التطبيق ويخفي سبب توقفه.
• الخطر = الاحتمال × الأثر، ولا خطر دون أصل له قيمة وثغرة فيه وتهديد قادر على استغلالها.
• لكل خطر مهم ضابط يمنع وآخر يكتشف وثالث يعيد، والأمن يقوم على الناس والإجراءات والتقنية معاً.

تدريب عملي Practice

• أعد تجربة الملف المشفر، ثم شفره بـ -aes-256-cbc بكلمة المرور نفسها مرة ثانية وقارن البايتات بعد كلمة Salted__، واكتب لماذا اختلف الملفان.
• عدل سكربت سجل المخاطر ليضيف عموداً لمالك كل خطر وعموداً للضابط المقترح، ثم أضف مخاطرك الحقيقية بدل الأمثلة الخمسة.
• اختر خدمة واحدة تعتمد عليها في عملك، واكتب لها: ما أهم ضلع من الثلاثية فيها، وما الضابط الوقائي والكاشف والتصحيحي الموجود لها اليوم، وما الخانة الفارغة.

سجل التحديثات

• أكتوبر 2026: كتابة المقال، وتشغيل التجربة على python:3.13.17-slim مع OpenSSL 3.5.7، ومراجعة التعريفات في ملحق المصطلحات في ECC-2:2024 ومعجم NIST.