jonrau1/syntheticsunसर्वरलेस AWS सुरक्षा ऑटोमेशन फ्रेमवर्क जो खतरा इंटेलिजेंस को इन्जेस्ट करता है, ML-आधारित विसंगति पहचान (RCF, IP Insights) लागू करता है, और स्वचालित खतरा रोकथाम, पहचान और प्रतिक्रिया के लिए Kibana में सुरक्षा टेलीमेट्री को समृद्ध करता है।
SyntheticSun एक रक्षा-गहराई (defense-in-depth) सुरक्षा ऑटोमेशन और निगरानी ढांचा (framework) है जो खतरा खुफिया (threat intelligence), मशीन लर्निंग, प्रबंधित AWS सुरक्षा सेवाओं और सर्वरलेस प्रौद्योगिकियों का उपयोग करके लगातार खतरों को रोकता, पहचानता और उनका जवाब देता है।
आप टूटे हुए कांच में सोते हैं
अपने प्रतिबिंबों के साथ,
लेकिन क्या आप जीवित महसूस कर रहे हैं?
हाँ, मुझे आपसे पूछने दीजिए,
क्या आप जीवित महसूस कर रहे हैं?
- Norma Jean, 2016
SyntheticSun Malware Information Sharing Platform (MISP) और Anomali के LIMO के उपयोग के आसपास बनाया गया है, जो सामुदायिक संचालित खतरा खुफिया प्लेटफॉर्म (TIPs) हैं जो विभिन्न प्रकार के समझौता संकेतक (IoC) प्रदान करते हैं। सामान्यीकृत और डुप्लिकेट रहित खतरा इंटेल को लगभग वास्तविक समय में खोजा जाता है ताकि विभिन्न प्रकार के नेटवर्क ट्रैफ़िक में ज्ञात खतरों की तुरंत पहचान की जा सके। संभावित खतरों की पहचान में गतिशीलता जोड़ने के लिए, IP Insights मॉडल तैनात किए जाते हैं ताकि IP पतों और संस्थाओं (जैसे IAM प्रिंसिपल ID, user-agent, आदि) के युग्मन के बीच विसंगतियों (और उनमें संभावित खतरों) का पता लगाया जा सके; Elasticsearch में मूल RCF डिटेक्टरों का भी उपयोग किया जाता है ताकि निकट-वास्तविक समय की सुरक्षा टेलीमेट्री में विसंगतियां पाई जा सकें, जैसे ही वे Kibana में स्ट्रीम होती हैं। सुरक्षा टीमों के भीतर ML मॉडल के उपयोग और फाइन-ट्यूनिंग को लोकतांत्रिक बनाने के लिए, मुख्य समाधान के अतिरिक्त IP Insights मॉडल को प्रशिक्षित करने की उपयोगिताएं प्रदान की जाती हैं।
सुरक्षा टेलीमेट्री के ऑर्केस्ट्रेशन और ऑटोमेशन के साथ-साथ निष्कर्षण, परिवर्तन और लोडिंग (ETL) को Kibana में करने के लिए, विभिन्न AWS सर्वरलेस प्रौद्योगिकियों जैसे AWS Lambda, Amazon DynamoDB, और AWS CodeBuild का उपयोग किया जाता है। ऐसी सर्वरलेस प्रौद्योगिकियों का उपयोग उनकी स्केलेबिलिटी, उपयोग में आसानी, भारी MapReduce या Glue ETL-आधारित समाधानों की तुलना में अपेक्षाकृत सस्ती लागत के लिए किया जाता है। समाधान का अधिकांश भाग CloudFormation के माध्यम से तैनात किया जाता है, जिसमें विभिन्न चरणों में Python और शेल में सहायक स्क्रिप्ट प्रदान की जाती हैं ताकि अपनाने और सतत एकीकरण पाइपलाइनों में संभावित तैनाती को बढ़ावा दिया जा सके।
समाधान को यथासंभव पतला रखने के लिए, बुनियादी Python मॉड्यूल जैसे boto3, requests, json, ipaddress, socket और re अधिकांश निष्कर्षण, परिवर्तन और लोडिंग (ETL) को डाउनस्ट्रीम सेवाओं में करते हैं। चूंकि सभी भू-स्थान जानकारी ip-api.com द्वारा प्रदान की जाती है, इसलिए इसमें खाते या भुगतान स्तर की आवश्यकता नहीं है और इसका एक बेहतरीन API है जिसमें उनके प्रतिक्रिया हेडर में थ्रॉटलिंग जानकारी शामिल है। Elasticsearch और Kibana की अधिकांश निर्भरताएं भी कोड में प्रदान की जाती हैं (इंडेक्स, मैपिंग, विज़ुअलाइज़ेशन, आदि) ताकि भारी मैन्युअल कॉन्फ़िगरेशन से बचा जा सके।
SyntheticSun समाधान के आकार और आवश्यक निर्भरताओं के कारण तीन चरणों में फैला हुआ है। सभी आर्किटेक्चर और स्थापना निर्देश (और जहां उपयुक्त हो, FAQ) अपने स्वयं के चरण में रहते हैं। विस्तारित कार्यक्षमता के लिए ऐड-ऑन मॉड्यूल (जिसे परिशिष्ट कहा जाता है) भी प्रदान किए जाते हैं, जिनके अपने स्वयं के आर्किटेक्चर और स्थानीयकृत स्थापना निर्देश हैं।
SyntheticSun, GitHub पर मिलने वाली चीज़ होने के कारण, एक प्रूफ-ऑफ-कॉन्सेप्ट है और इसलिए मैंने पहली रिलीज़ के लिए हर चीज़ को पूरी तरह से सख्त करने की अतिरिक्त मेहनत नहीं की। यदि आप इसे ऐसे समय में पढ़ रहे हैं जब मैंने आवश्यक परिवर्तन नहीं किए हैं, तो इस समाधान को उत्पादन वातावरण (या उच्च सुरक्षा आवश्यकताओं वाले किसी भी वातावरण) में तैनात करने से पहले निम्नलिखित पर विचार करें। मैं इन वस्तुओं को एक रोडमैप पर रखूंगा और उचित समय पर अपडेट करूंगा।
SyntheticSun AWS Cloud पर आपके एज प्रोटेक्शन सुरक्षा उपयोग मामलों के लिए साइबर थ्रेट इंटेलिजेंस और मशीन लर्निंग का उपयोग शुरू करने का एक आसान तरीका है, बिना एक या अधिक वाणिज्यिक उपकरणों में निवेश किए, या आपकी सुरक्षा टीम के लिए डेटा वैज्ञानिक को काम पर रखे (हालाँकि आदर्श रूप से आपको बाद वाला करना चाहिए)। यह समाधान, प्रारंभिक कॉन्फ़िगरेशन के बाद, पूरी तरह से स्वचालित है, जिससे आप मशीन की गति से खतरों की पहचान कर सकते हैं और उनका जवाब दे सकते हैं। अंत में, यह समाधान आपकी घटना प्रतिक्रिया टीम को खतरे के जवाब के लिए उपयोग करने के लिए बुनियादी विज़ुअलाइज़ेशन प्रदान करता है, जैसे कि दुर्भावनापूर्ण माने जाने वाले IP पतों या डोमेन के लिए अनुमत इनबाउंड या आउटबाउंड कनेक्शन या DNS क्वेरी। समाधान का मूल बहुत हल्के ऑटोमेशन और डेटा इंजीनियरिंग पाइपलाइनों पर निर्भर करता है, जिनका सैद्धांतिक रूप से उन उद्देश्यों के लिए पुनः उपयोग किया जा सकता है जहाँ बहु-चरण सामान्यीकरण और संवर्धन या निर्धारित, तेज़-गति वाले बैच कार्यों की आवश्यकता होती है।
सबसे पहले, यदि आप Amazon GuardDuty और/या AWS WAF का उपयोग कर रहे हैं, तो इस समाधान का मूल्यांकन करना समझ में आ सकता है, लेकिन यह एक आवश्यकता भी है। स्पष्ट व्यक्तित्व जो इसका लाभ उठा सकते हैं, वे उत्पाद टीमें हैं जो अपने पूरे स्टैक को सुरक्षित करने के लिए जिम्मेदार हैं और उनके पास मशीन लर्निंग एल्गोरिदम को मॉडल, प्रशिक्षित और तैनात करने या साइबर थ्रेट इंटेलिजेंस फीड को सार्थक रूप से संचालित करने के लिए पूंजी या विशेषज्ञता की कमी है। वे उल्लिखित व्यक्तित्व संभवतः सुरक्षा इंजीनियरिंग, SecOps / SOC विश्लेषक और इंजीनियर, या एक DevSecOps इंजीनियर हैं; हालाँकि, यह सूची संपूर्ण नहीं है, और उन्हें उत्पाद/एप्लिकेशन-संरेखित होने की आवश्यकता नहीं है क्योंकि केंद्रीय टीमें भी इसका उपयोग कर सकती हैं। एक और उपयोग वही व्यक्तित्व (SecOps, सुरक्षा इंजीनियरिंग) हैं जो एक केंद्रीकृत टीम के लिए काम करते हैं और फ़ायरवॉल और घुसपैठ रोकथाम प्रणालियों के लिए एक गतिशील ब्लॉक सूची बनाना चाहते हैं; CodeBuild प्रोजेक्ट्स को CSV या फ्लैट फ़ाइलों को लगभग किसी भी स्थान पर छोड़ने के लिए पुनः उपयोग किया जा सकता है (जैसे Palo Alto फ़ायरवॉल, Squid फ़ॉरवर्ड प्रॉक्सी URL फ़िल्टर, आदि)।
SyntheticSun में वर्तमान में सभी मुख्य लॉग स्रोतों - विशेष रूप से S3 एक्सेस लॉग और CloudFront एक्सेस लॉग - पर पूर्ण कवरेज का अभाव है, जो कई लोगों द्वारा सेवाएँ प्रदान करने के तरीके का अभिन्न अंग हैं (विशेषकर S3 बकेट पर SPAs के लिए)। विसंगति पहचान IP Insights के साथ मेरे जुनून और डेटा साइंस प्रशिक्षण की पूर्ण कमी के कारण WAF, API Gateway एक्सेस लॉग, या CloudTrail से आगे नहीं बढ़ती है (गंभीरता से, मैं pandas या numpy का उपयोग करना भी नहीं जानता)। लॉग में इसका मिलान करने का प्रयास करने के अलावा कच्चे खतरा खुफिया IoCs का कोई गहन विश्लेषण नहीं है।
किसी संगठन के लिए इस समाधान को तैनात करने का सबसे आसान तरीका इसे एक केंद्रीकृत सुरक्षा सेवा खाते में तैनात करना है। निचले स्तर की टेलीमेट्री जैसे VPC फ़्लो लॉग और WAF लॉग के लिए, आपको AWS Service Catalog के माध्यम से सहायक स्क्रिप्ट या CloudFormation टेम्पलेट प्रदान करने पर विचार करना चाहिए ताकि निचले वातावरण में सक्रियण को बढ़ावा दिया जा सके। आपको Elasticsearch Service की अपनी शार्ड खपत और इंडेक्स रोटेशन का मूल्यांकन करने की आवश्यकता होगी, साथ ही अनुमतियाँ, यदि आप क्रॉस-अकाउंट Kinesis Data Firehose डिलीवरी स्ट्रीम को एक केंद्रीकृत स्थान पर प्रकाशित कर रहे होंगे। मैंने यह समाधान अपने व्यक्तिगत सैंडबॉक्स खाते में बनाया है, इसलिए मैंने उपरोक्त किसी भी विचार को समाधान में शामिल नहीं किया है, मैं इस ध्यान में एक PR पर काम करके खुश होऊंगा और भविष्य में इसे स्वयं कर सकता हूं।
31 जुलाई 2020 तक, AWS Firewall Manager Policies WAF लॉगिंग के बहु-खाता एकत्रीकरण का समर्थन करती हैं, जो आपको इसे बहुत कम दर्दनाक बनाने के एक कदम और करीब लाता है…
सावधानियाँ: मैं डेटा वैज्ञानिक नहीं हूं और यह एक लंबा उत्तर होने वाला है। संक्षेप में: यह एक विसंगति खोजक है और मुझे लगता है?
यह देखते हुए कि मैं डेटा वैज्ञानिक के करीब भी नहीं हूं या मेरे पास कोई प्रशिक्षण नहीं है, आप दस्तावेज़ पढ़ने में बेहतर महसूस करेंगे। यह कहते हुए, यहाँ मेरा आम आदमी का प्रयास है: IP Insights एक अनुपरिवेक्षित मशीन लर्निंग एल्गोरिदम है जो एक IPv4 पते और एक इकाई (जैसे खाता संख्या, उपयोगकर्ता नाम, user-agent) के बीच संबंध सीखता है। IP Insights यह निर्धारित करने का प्रयास करता है कि इकाई के उस IPv4 पते का उपयोग कितनी संभावना है। IP Insights के पर्दे के पीछे एक तंत्रिका नेटवर्क है जो इन संस्थाओं और IPv4 पतों का अव्यक्त वेक्टर प्रतिनिधित्व सीखता है। इन वेक्टरकृत प्रतिनिधित्वों के बीच की दूरी इस बात का प्रतीक है कि किसी इकाई के लिए किसी IPv4 पते के साथ जुड़ना (जैसे उससे अनुरोध भेजना) कितना विसंगतिपूर्ण (या नहीं) है।
तंत्रिका नेटवर्क लगभग वैसे ही हैं जैसे वे सुनाई देते हैं; वे मानव मस्तिष्क के समान व्यवहार करने के लिए डिज़ाइन की गई एक मशीन लर्निंग प्रणाली बनाते हैं, जिसमें कम्प्यूटरीकृत न्यूरॉन्स और सिनैप्स पूर्ण होते हैं। अनुपरिवेक्षित मशीन लर्निंग में, एल्गोरिदम "अच्छा" (यानी True Negative) कैसा दिखता है, बनाम "बुरा" (यानी True Positive) कैसा दिखता है, सभी IPv4 पतों और उनकी युग्मित संस्थाओं के बीच संबंध को देखकर पता लगा सकता है। इस संबंध का मूल्यांकन यह पहचानने के लिए किया जाता है कि उनकी "दूरी" से कौन से वेक्टर दूसरों के समान हैं। IP Insights के मामले में, एक पूर्व-निर्मित एन्कोडर प्रदान किया जाता है जो IPv4 पतों की खोज करता है और फिर सभी संस्थाओं को क्लस्टर में हैश करता है। फिर यह वेक्टरकरण का उपयोग करके उन पर पुनरावृत्ति करता है। वेक्टरकरण गणना करने का एक तरीका है जो उन पर लूप करने के बजाय एक मैट्रिक्स के रूप में होता है (एक सूची के लिए "For" लूप के बारे में सोचें जिसमें करोड़ों मान हैं)।
जब आप एक IP Insights मॉडल को प्रशिक्षित कर रहे होते हैं, तो यह वास्तव में दूर की दूरी वाले IPv4 पतों के साथ संस्थाओं को जोड़कर (यानी अत्यधिक विसंगतिपूर्ण) और जो वास्तविकता में घटित होने की संभावना कम है, स्वयं को गलत सकारात्मक बनाएगा; मॉडल अब True Positives, False Positives और True Negatives के बीच अंतर कर सकता है। यह एक और पागल शब्द "क्रॉस एन्ट्रॉपी" (उर्फ "लॉग लॉस" जैसे कि यह बेहतर बनाता है) को रोकने के लिए किया जाता है, और एक और शब्द, बाइनरी वर्गीकरण का परिचय देता है। IP Insights मूल रूप से पूछ रहा है, "इस IP पते के इस इकाई के साथ युग्मित होने की संभावना क्या है कि यह विसंगतिपूर्ण है?" यही इसे बाइनरी बनाता है, मुझे लगता है, तो "हाँ यह खराब है" या "नहीं यह नहीं है"। संभावना को 0 और 1 के बीच एक मान के रूप में दर्शाया जाता है, सभी मशीन लर्निंग मॉडलों का लक्ष्य इसे जितना संभव हो 0 के करीब बनाना है, इसलिए किसी ऐसी चीज़ के लिए 0.01 का मान अनुमान लगाना जो वास्तव में 1 है (ज्ञात True Positive) के परिणामस्वरूप बहुत अधिक लॉग लॉस होगा। तो, इन सबके साथ, जानबूझकर कचरा डेटा बनाकर IP Insights प्रशिक्षण के दौरान उस लॉग लॉस (यानी खराब भविष्यवाणियां) को कम करने में मदद करता है।
यह हमें एंडपॉइंट से आउटपुट पर लाता है। जब आप इसे क्वेरी करते हैं (या तो बैचों में या निकट-वास्तविक समय में InvokeEndpoint API का उपयोग करके) तो प्रतिक्रिया एक असीमित फ़्लोट है जो नकारात्मक या सकारात्मक हो सकती है। यह जितना 0 से ऊपर है, उतना ही अधिक विसंगतिपूर्ण होने की संभावना है, जहाँ आपका काम शुरू होता है। इस समाधान के लिए मैंने 0.03 से ऊपर कुछ भी चुना, जो काफी हद तक काल्पनिक है, सच्चाई के करीब जाने के लिए आपको एंडपॉइंट को True Positives प्रदान करना चाहिए और देखना चाहिए कि आपकी प्रतिक्रिया क्या है। उन निष्कर्षों के आधार पर, आप एक स्तरीय दृष्टिकोण कॉन्फ़िगर कर सकते हैं जहाँ आपका एप्लिकेशन स्कोर के आधार पर दूसरा कारक चुनौती जारी कर सकता है, एक अलर्ट उठा सकता है या इसे पूरी तरह से ब्लॉक कर सकता है। प्रश्न के दूसरे भाग का उत्तर "हाँ, मुझे ऐसा लगता है" है, user-agents को IP के साथ जोड़कर मॉडल को प्रशिक्षित करना वास्तव में काफी संदिग्ध है। अब कम अस्थिर संस्थाओं (खाता संख्या, उपयोगकर्ता नाम, IAM उपयोगकर्ता) के लिए ऐसा लगता है कि यह इच्छित उपयोग है।
समाधान में मैं कुछ उदाहरण फीड प्रदान करता हूं जिनका आपको उपयोग करना चाहिए, कुछ काफी स्पष्ट हैं जैसे साइबरक्राइम डोमेन फीड, Emerging Threats और CI-badguys। अपनी वास्तविक नौकरी में मैं दुनिया के सबसे प्रतिभाशाली साइबर थ्रेट इंटेलिजेंस विशेषज्ञों में से एक के साथ काम करता हूं (कोई मजाक नहीं, वह अद्भुत है!), जिन्होंने विकल्पों को भी प्रभावित किया। मशीन लर्निंग मॉडल और आपके द्वारा बनाई जाने वाली किसी भी अन्य चीज़ की तरह, आपको अपनी खतरा इंटेल फीड और एकत्रीकरण को अपने वर्तमान खतरे के वातावरण से मेल खाने के लिए तैयार करना चाहिए। डुप्लिकेट को MISP में पहचाना जाता है और विशिष्टता को लागू करने के लिए DynamoDB तालिकाओं में केवल एक हैश कुंजी निर्दिष्ट की जाती है, इसलिए भले ही समान IPv4 पते पर 5 फीड रिपोर्ट कर रही हों, केवल एक ही तालिका में पहुंचेगा।
आप अपने स्वयं के वाणिज्यिक खतरा खुफिया प्लेटफॉर्म और फीड जैसे InfoBlox या Recorded Future को भी इस समाधान में ला सकते हैं, उन्हें समान सिंटैक्स के साथ DynamoDB तालिकाओं पर इंगित करके।
AWS से अधिकांश लॉग डिलीवरी "सर्वोत्तम प्रयास" है, इसलिए कोई आधिकारिक SLA प्रकाशित नहीं है; हालाँकि, मैं मान लूंगा कि यह लगभग 99.5 - 99.9% है, जहाँ अंतिम 0.5 - 0.1% में कुछ भी वितरित नहीं किया जाएगा। "उत्पादन" ट्रैफ़िक भी AWS में प्रथम श्रेणी का है; यदि नेटवर्क बैंडविड्थ बाधाएं हैं तो यह लॉग भेजने के बजाय ग्राहकों को कनेक्टिविटी वापस देने को प्राथमिकता देगा। अधिक संभावित घटना यह है कि कच्ची लॉग फ़ाइल Lambda के लिए पूरी चीज़ को समय पर संसाधित करने के लिए बहुत बड़ी थी; जब आप उसी क्लाइंट IP से DOS या क्रॉलर द्वारा पीड़ित हो रहे हों तो आप इसे बहुत देखते हैं। WAF और ALB कॉलर द्वारा लॉग फ़ाइलों को बंडल करते हैं (जहाँ तक मैं बता सकता हूं), इसलिए यदि आप सैकड़ों अनुरोधों को अवशोषित करते हैं, तो लॉग फ़ाइल बहुत बड़ी हो सकती है।
हाँ, हालाँकि आपको निम्नलिखित में से एक करने की आवश्यकता होगी:
इसके लिए अतिरिक्त लागतें हैं। VPC में Lambda, विशेष रूप से दर्जनों समवर्ती आमंत्रणों के लिए, ENI के आसपास रहने और आपकी RFC1918 स्पेस खाने से अधिक समस्याएं पैदा करने की संभावना है। जब तक अनुपालन आवश्यकताओं को पूरा करने के लिए आपको अपने VPC के भीतर सभी ट्रैफ़िक को अलग करना बिल्कुल आवश्यक नहीं है, मैं उस रास्ते पर नहीं जाऊंगा।
हाँ, यह अंतिम स्वरूपित लॉग को Kinesis Data Firehose में प्रकाशित करने और उन्हें Splunk पर इंगित करने के लिए समाधान को संशोधित करके प्राप्त किया जा सकता है।
मुझे भविष्य में Route 53 DNS Logs, S3 Access Logs, CloudFront Access Logs और API Gateway Access Logs और शायद कुछ अन्य होस्ट-आधारित लॉग के लिए समर्थन की उम्मीद है।
मैं ईमानदारी से Kinesis Data Agent का उपयोग करना पसंद करता, लेकिन मुझे इसके साथ बहुत सारी समस्याएं मिलीं: यह Amazon Linux 2 में डिफ़ॉल्ट रूप से शामिल नहीं है और अब जब Ubuntu 18.04 LTS AMI Java 11 के साथ पूर्व-स्थापित आते हैं, तो मैं Agent के साथ पिछड़ी संगतता समस्याओं में भाग रहा था क्योंकि यह बिल्ड को विफल करता है जब तक कि आपके पास OpenJDK 8 या 9 न हो। CloudWatch Agent को स्थापित करना बहुत आसान था क्योंकि इसे नई सुविधाओं के साथ बार-बार अपडेट किया जाता है और कॉन्फ़िगरेशन के लिए Systems Manager Document समर्थन है; इसमें स्थापना के लिए एक विज़ार्ड भी है। यदि AWS कभी Kinesis Data Agent समर्थन को CloudWatch Agent जितना गंभीरता से लेता है, तो मैं इस पर स्विच कर सकता हूं क्योंकि मैं कुछ होस्ट-आधारित लॉग (Suricata, Squid, Nginx, Apache) के लिए CloudWatch Logs को मध्यस्थ के रूप में उपयोग करने के बजाय सीधे Kinesis Data Firehose पर प्रकाशित करना पसंद करूंगा।
मैं मुद्दों या प्रोजेक्ट बोर्ड में "Help Wanted" के रूप में टैग किए गए आइटम के लिए PRs स्वीकार करने में खुश हूं। मैं किसी भी अन्य प्रस्तावित PRs की भी समीक्षा करूंगा यदि वह परियोजना की भावना को पूरा करता है।
David Dorsey और Ryan Nolette को विशेष धन्यवाद जिन्होंने SyntheticSun को बेहतर बनाने के लिए मूल्यवान प्रतिक्रिया, परीक्षण और योगदान प्रदान किया।
यह लाइब्रेरी GNU जनरल पब्लिक लाइसेंस v3.0 (GPL-3.0) लाइसेंस के तहत लाइसेंस प्राप्त है। LICENSE फ़ाइल देखें।
