jonrau1/syntheticsunإطار عمل أتمتة أمنية بدون خادم على AWS يستوعب معلومات التهديدات، ويطبق كشف الحالات الشاذة القائم على التعلم الآلي (RCF, IP Insights)، ويُثري بيانات القياس الأمنية في Kibana لأتمتة الوقاية من التهديدات، واكتشافها، والاستجابة لها.
SyntheticSun هو إطار عمل آلي ومراقب لأمن الدفاع العميق يستخدم معلومات التهديدات، والتعلم الآلي، وخدمات أمان AWS المدارة، والتقنيات غير الخادمية لمنع التهديدات واكتشافها والاستجابة لها بشكل مستمر.
أنت تنام في زجاج مكسور
مع انعكاساتك،
لكن هل تشعر أنك على قيد الحياة؟
نعم، دعني أسألك،
هل تشعر أنك على قيد الحياة؟
- Norma Jean, 2016
تم بناء SyntheticSun حول استخدام منصة مشاركة معلومات البرامج الضارة (MISP) و Anomali's LIMO، وهما منصتان لمعلومات التهديدات (TIPs) مدفوعة من المجتمع توفران أنواعًا مختلفة من مؤشرات الاختراق (IoC). يتم البحث عن معلومات التهديدات الطبيعية والمكررة في الوقت الفعلي تقريبًا لتحديد التهديدات المعروفة بسرعة في أنواع مختلفة من حركة مرور الشبكة. لإضافة ديناميكية إلى تحديد التهديدات المحتملة، يتم نشر نماذج IP Insights للعثور على حالات شاذة (والتهديدات المحتملة فيها) بين إقران عناوين IP والكيانات (مثل معرفات مبدأ IAM ووكلاء المستخدم، وما إلى ذلك)، كما تُستخدم كاشفات RCF الأصلية في Elasticsearch للعثور على حالات شاذة في القياسات الأمنية في الوقت الفعلي تقريبًا أثناء تدفقها إلى Kibana. لإضفاء الطابع الديمقراطي على استخدام وضبط نماذج التعلم الآلي داخل فرق الأمان، يتم توفير أدوات لتدريب نماذج IP Insights كإضافة للحل الأساسي.
لأداء كل من التنسيق والأتمتة بالإضافة إلى استخراج وتحويل وتحميل (ETL) القياسات الأمنية إلى Kibana، يتم استخدام تقنيات AWS بدون خادم مختلفة مثل AWS Lambda و Amazon DynamoDB و AWS CodeBuild. تُستخدم هذه التقنيات غير الخادمية لقابليتها للتوسع وسهولة الاستخدام والتكاليف الرخيصة نسبيًا مقارنة بالحلول الثقيلة القائمة على MapReduce أو Glue ETL. يتم نشر معظم الحل عبر CloudFormation مع نصوص مساعدة بلغة Python و shell في جميع المراحل المختلفة لتعزيز الاعتماد وإمكانية النشر في خطوط التكامل المستمر.
لجعل "جوهر" الحل نحيلًا قدر الإمكان، تقوم وحدات Python الأساسية مثل boto3 و requests و json و ipaddress و socket و re بأداء معظم عمليات الاستخراج والتحويل والتحميل (ETL) إلى الخدمات النهائية. نظرًا لأن جميع معلومات الموقع الجغرافي يتم توفيرها بواسطة ip-api.com، فإنها لا تتطلب حسابًا أو مستويات مدفوعة ولديها واجهة برمجة تطبيقات رائعة تتضمن معلومات التخفيض في رؤوس استجاباتها. كما يتم توفير معظم تبعيات Elasticsearch و Kibana في الكود (الفهارس، التعيينات، التصورات، إلخ) لتجنب التكوين اليدوي الثقيل.
يتم توزيع SyntheticSun عبر ثلاث مراحل نظرًا لحجم الحل والتبعيات المطلوبة. تعيش جميع تعليمات الهندسة والتركيب (وأسئلة وأجوبة حيثما كان ذلك مناسبًا) داخل مرحلتهم الخاصة. كما يتم توفير وحدات إضافية (تسمى ملحق) لتوسيع الوظائف، والتي تحتوي على تعليمات الهندسة والتركيب الخاصة بها محليًا.
SyntheticSun، بحكم كونه شيئًا وجدته على GitHub، هو إثبات مفهوم ولذلك لم أذهب إلى الميل الإضافي للإصدار الأول لتعزيز كل شيء بشكل مطلق. بشرط أن تقرأ هذا في وقت لم أقم فيه بإجراء التغييرات اللازمة، فكر في ما يلي قبل نشر هذا الحل في بيئة إنتاج (أو أي بيئة ذات احتياجات أمنية متزايدة). سأضع هذه العناصر على خارطة طريق وسأحدثها حسب الاقتضاء.
SyntheticSun هو طريقة سهلة لبدء استخدام معلومات التهديدات السيبرانية والتعلم الآلي لحالات استخدام أمان حافة الحماية لديك على سحابة AWS دون الحاجة إلى الاستثمار في أداة تجارية واحدة أو أكثر، أو توظيف عالم بيانات لفريق الأمان الخاص بك (على الرغم من أنه يجب عليك فعل ذلك من الناحية المثالية). هذا الحل، بعد التكوين الأولي، مؤتمت بالكامل، مما يسمح لك بتحديد التهديدات والاستجابة لها بسرعة الآلة. أخيرًا، يوفر هذا الحل تصورات أساسية لفريق الاستجابة للحوادث لاستخدامها في الاستجابة للتهديدات، مثل الاتصالات الواردة أو الصادرة المسموح بها أو استعلامات DNS إلى ومن عناوين IP أو نطاقات تعتبر ضارة. يعتمد جوهر الحل على أتمتة خفيفة الوزن وخطوط أنابيب هندسة بيانات، والتي يمكن نظريًا إعادة استخدامها لأغراض أخرى حيث تكون هناك حاجة إلى التطبيع والإثراء متعدد المراحل أو وظائف الدُفعات السريعة المجدولة.
أولاً، إذا كنت تستخدم Amazon GuardDuty و/أو AWS WAF، فقد يكون من المنطقي تقييم هذا الحل، ولكنه أيضًا مطلب. الشخصيات الواضحة التي يمكنها الاستفادة هي فرق المنتجات المسؤولة عن تأمين مجموعتها التقنية بالكامل وتفتقر إلى رأس المال أو الخبرة لنمذجة وتدريب ونشر خوارزميات التعلم الآلي أو تشغيل خلاصات معلومات التهديدات السيبرانية بشكل ذي معنى. من المحتمل أن تكون هذه الشخصيات المذكورة آنفًا هي مهندسو الأمان أو محللو SecOps / SOC أو مهندس DevSecOps؛ ومع ذلك، فإن هذه القائمة ليست شاملة، ولا يحتاجون إلى أن يكونوا محاذين للمنتج/التطبيق حيث يمكن للفرق المركزية استخدام هذا أيضًا. استخدام آخر هو تلك الشخصيات نفسها (SecOps، هندسة الأمان) التي تعمل لفريق مركزي وتريد إنشاء قائمة حظر ديناميكية لجدران الحماية وأنظمة منع الاختراق، يمكن إعادة استخدام مشاريع CodeBuild لإسقاط ملفات CSV أو ملفات مسطحة إلى أي مكان تقريبًا (مثل جدران حماية Palo Alto، ومرشحات URL لوكلاء Squid، إلخ).
يفتقر SyntheticSun حاليًا إلى تغطية كاملة لجميع مصادر السجلات الرئيسية - وهي سجلات وصول S3 وسجلات وصول CloudFront، والتي تعتبر جزءًا لا يتجزأ من الطريقة التي يقدم بها الكثير من الأشخاص الخدمات (خاصةً لتطبيقات الصفحة الواحدة على دلاء S3). لا يمتد اكتشاف الحالات الشاذة إلى ما بعد WAF أو سجلات وصول API Gateway أو CloudTrail بسبب هوسي بـ IP Insights والافتقار التام لأي تدريب في علوم البيانات (بجدية، لا أعرف حتى كيفية استخدام pandas أو numpy). لا يوجد أي تحليل متعمق لمؤشرات الاختراق الخام لمعلومات التهديدات بخلاف محاولة مطابقتها في السجلات.
أسهل طريقة لنشر هذا الحل لمؤسسة هي نشره في حساب خدمات أمان مركزي. بالنسبة للقياسات منخفضة المستوى مثل سجلات تدفق VPC وسجلات WAF، يجب أن تفكر في توفير نصوص مساعدة أو قوالب CloudFormation عبر AWS Service Catalog لتعزيز التمكين في البيئات الأدنى. ستحتاج إلى تقييد استهلاك القطع وتدوير فهرس Elasticsearch Service، بالإضافة إلى الأذونات، إذا كنت ستقوم بتدفق تسليمات Kinesis Data Firehose عبر الحسابات إلى موقع مركزي. لقد بنيت هذا الحل في حساب صندوق الرمل الشخصي الخاص بي، ولهذا السبب لم أخبز أيًا من الاعتبارات المذكورة أعلاه في الحل، سأكون سعيدًا بالعمل على طلب سحب بهذا المعنى وقد أقوم بذلك بنفسي في المستقبل.
اعتبارًا من 31 يوليو 2020، تدعم سياسات AWS Firewall Manager تجميع تسجيل WAF عبر الحسابات المتعددة مما يقرّبك خطوة واحدة من جعل هذا أقل إيلامًا...
تحذيرات: أنا لست عالم بيانات وهذه ستكون إجابة طويلة. باختصار: إنها مكتشفة شذوذ وأعتقد ذلك؟
نظرًا لأنني لست قريبًا من عالم بيانات أو لدي أي تدريب، فأنت أفضل حالًا قراءة الوثائق حول هذا الموضوع. ومع ذلك، إليك محاولتي البسيطة: IP Insights هي خوارزمية تعلم آلي غير خاضعة للإشراف تتعلم العلاقة بين عنوان IPv4 وكيان (مثل رقم الحساب واسم المستخدم ووكيل المستخدم). تحاول IP Insights بعد ذلك تحديد مدى احتمالية استخدام الكيان لعنوان IPv4 هذا. وراء كواليس IP Insights توجد شبكة عصبية تتعلم تمثيل المتجه الكامن لهذه الكيانات وعناوين IPv4. المسافة بين هذه التمثيلات المتجهة هي رمزية لمدى الشذوذ (أو عدمه) لارتباط الكيان بـ (مثل إرسال طلب من) عنوان IPv4.
الشبكات العصبية تشبه تمامًا ما تبدو عليه؛ فهي تشكل نظام تعلم آلي مصمم للتصرف بشكل مشابه للدماغ البشري، مكتمل بالخلايا العصبية والمشابك الحاسوبية. في التعلم الآلي غير الخاضع للإشراف، يمكن للخوارزمية استخلاص شكل "الجيد" (أي سلبي حقيقي) مقابل "السيئ" (أي إيجابي حقيقي) من خلال النظر في الارتباط بين جميع عناوين IPv4 والكيانات المقترنة بها. يتم تقييم هذا الارتباط لتحديد المتجهات المشابهة للآخرين من خلال "المسافة" بينها. في حالة IP Insights، يتم توفير مشفر مسبق البناء يبحث عن عناوين IPv4 ثم يقوم بتجزئة جميع الكيانات إلى مجموعات. ثم يتكرر عليها باستخدام التوجيه المتجه. التوجيه المتجه هو طريقة لإجراء العمليات الحسابية كمصفوفة بدلاً من التكرار عليها (فكر في حلقة "For" لقائمة تحتوي على عشرات الملايين من القيم).
عند تدريب نموذج IP Insights، فإنه سيخلق في الواقع نتائج إيجابية خاطئة لنفسه عن طريق إقران عناوين IPv4 بكيانات لها مسافة بعيدة (أي شديدة الشذوذ) ومن غير المرجح أن تحدث في الواقع؛ يمكن للنموذج الآن التمييز بين الإيجابيات الحقيقية والإيجابيات الخاطئة والسلبيات الحقيقية. يتم ذلك لمنع مصطلح مجنون آخر يسمى "الانتروبيا المتقاطعة" (AKA "فقدان السجل" كما لو كان ذلك يحسن الأمر)، ويقدم مصطلحًا آخر، التصنيف الثنائي. تسأل IP Insights بشكل أساسي، "ما هي فرصة أن يكون عنوان IP هذا مقترنًا بهذا الكيان شاذًا؟" هذا ما يجعله ثنائيًا، على ما أعتقد، لذا "نعم إنه سيئ" أو "لا ليس كذلك". يتم تمثيل الاحتمال كقيمة بين 0 و 1، هدف جميع نماذج التعلم الآلي هو جعل هذا أقرب ما يمكن إلى 0، لذا فإن التنبؤ بقيمة 0.01 لشيء هو في الواقع 1 (إيجابي حقيقي معروف) سيؤدي إلى فقدان سجل مرتفع جدًا. لذا، مع كل ما قيل، من خلال صنع بيانات قمامة عن قصد، يساعد IP Insights في تقليل فقدان السجل هذا (أي التنبؤات السيئة) أثناء التدريب.
يقودنا ذلك إلى المخرجات من نقطة النهاية. عندما تستعلم عنها (إما عبر دفعات أو في الوقت الفعلي تقريبًا باستخدام واجهة برمجة التطبيقات InvokeEndpoint)، تكون الاستجابة عبارة عن عائم غير محدود يمكن أن يكون سالبًا أو موجبًا. كلما كان أعلى من 0، زادت احتمالية كونه شاذًا، وهنا يبدأ عملك. لهذا الحل اخترت أي شيء فوق 0.03، وهو إلى حد كبير افتراضي، للاقتراب من الحقيقة يجب عليك توفير إيجابيات حقيقية لنقطة النهاية ومعرفة ما هي استجابتك. بناءً على هذه النتائج، يمكنك تكوين نهج متدرج حيث قد يصدر تطبيقك تحديًا بعامل ثانٍ، أو يثير تنبيهًا أو يحظره تمامًا اعتمادًا على الدرجة. الإجابة على الجزء الثاني من السؤال هي "نعم، أعتقد ذلك"، تدريب النموذج مع وكلاء المستخدم المقترنين بعنوان IP هو في الواقع أمر مشكوك فيه إلى حد ما. الآن بالنسبة للكيانات الأخرى الأقل تقلبًا (رقم الحساب، اسم المستخدم، مستخدم IAM)، يبدو أنه الاستخدام المقصود.
في الحل أقدم بعض خلاصات الأمثلة التي يجب أن تستخدمها، بعضها واضح جدًا مثل خلاصة نطاق الجرائم الإلكترونية و Emerging Threats و CI-badguys. في وظيفتي الحقيقية أعمل مع واحدة من أكثر المتخصصين في معلومات التهديدات السيبرانية موهبة في العالم كله (بدون مزاح، إنها رائعة!)، والتي أثرت أيضًا على الخيارات. مثل نماذج التعلم الآلي وأي شيء آخر ستبنيه، يجب عليك تخصيص خلاصات معلومات التهديدات وتجميعها لتتناسب مع بيئة التهديد الحالية لديك. يتم تحديد التكرارات في MISP ويتم تحديد مفتاح تجزئة فقط في جداول DynamoDB لفرض التفرد، لذلك حتى إذا كان هناك 5 خلاصات تبلغ عن نفس عنوان IPv4، فسيصل واحد فقط إلى الجدول.
يمكنك أيضًا إحضار منصات وخلاصات معلومات التهديدات التجارية الخاصة بك مثل InfoBlox أو Recorded Future إلى هذا الحل عن طريق توجيهها إلى جداول DynamoDB بصيغة مماثلة.
معظم تسليم السجلات من AWS هو "أفضل جهد"، لذلك لا يوجد مستوى خدمة SLA رسمي منشور؛ ومع ذلك، أفترض أنه حوالي 99.5 - 99.9%، حيث لن يتم تسليم أي شيء في آخر 0.5 - 0.1%. حركة مرور "الإنتاج" هي أيضًا من الدرجة الأولى في AWS؛ إذا كانت هناك قيود على عرض النطاق الترددي للشبكة، فستعطي الأولوية لتوصيل الاتصال بالعملاء بدلاً من إرسال السجلات. الحدث الأكثر احتمالاً هو أن ملف السجل الخام كان كبيرًا جدًا بحيث لا يمكن لـ Lambda معالجته بالكامل في الوقت المحدد؛ ترى هذا كثيرًا عندما تتعرض لهجوم DOS أو زاحف من نفس عنوان IP للعميل. تقوم WAF و ALB بتجميع ملفات السجل حسب المتصل (بقدر ما أستطيع)، لذلك إذا امتصصت مئات الطلبات، يمكن أن يكون ملف السجل كبيرًا جدًا.
نعم، ومع ذلك ستحتاج إلى القيام بأحد الإجراءات التالية:
هناك تكاليف إضافية لهذا. Lambda في VPC، خاصةً لعشرات الاستدعاءات المتزامنة، من المحتمل أن يؤدي إلى المزيد من المشاكل من ENIs التي تبقى وتستهلك مساحة RFC1918 الخاصة بك.除非 كان عليك قطعًا عزل كل حركة المرور داخل VPC لتلبية متطلبات الامتثال، لن أسلك هذا الطريق.
نعم، هذا ممكن عن طريق تعديل الحل لنشر السجلات المنسقة النهائية إلى Kinesis Data Firehose وتوجيهها إلى Splunk.
آمل أن يكون لدي دعم لسجلات DNS لـ Route 53، وسجلات وصول S3، وسجلات وصول CloudFront وسجلات وصول API Gateway وربما بعض السجلات المستندة إلى المضيف في المستقبل.
بصراحة كنت أفضل استخدام Kinesis Data Agent، لكنني وجدت الكثير من المشكلات معه: لا يتم تضمينه افتراضيًا في Amazon Linux 2 والآن بعد أن تأتي صور Ubuntu 18.04 LTS AMI مع Java 11 مثبتة مسبقًا، كنت أواجه مشكلات توافق عكسي مع الوكيل لأنه يفشل في البناء ما لم يكن لديك OpenJDK 8 أو 9. كان من الأسهل بكثير تثبيت CloudWatch Agent حيث يتم تحديثه بشكل متكرر بميزات جديدة وهناك دعم لمستند Systems Manager للتكوين؛ حتى أنه يحتوي على معالج للتثبيت. إذا قامت AWS يومًا ما بدعم Kinesis Data Agent بنفس جدية CloudWatch Agent، فقد أتحول إليه لأنني أفضل كثيرًا النشر إلى Kinesis Data Firehose مباشرة لبعض السجلات المستندة إلى المضيف (Suricata و Squid و Nginx و Apache) بدلاً من استخدام CloudWatch Logs كوسيط.
يسعدني قبول طلبات السحب للعناصر الموسومة بـ "مطلوب مساعدة" في المشكلات أو لوحة المشروع. سأراجع أي طلبات سحب أخرى مقترحة أيضًا إذا كانت تتناسب مع روح المشروع.
شكر خاص لـ David Dorsey و Ryan Nolette اللذين قدما ملاحظات قيمة واختبارات ومساهمات للمساعدة في ضبط SyntheticSun.
هذه المكتبة مرخصة بموجب رخصة GNU General Public License v3.0 (GPL-3.0). راجع ملف LICENSE.
