از تست نفوذ دست بردارید، برنامه نویسی را شروع کنید

از تست نفوذ دست بردارید، برنامه نویسی را شروع کنید

همانطور که در وبلاگم دربارۀ پیوستن به ProjectDiscovery توضیح دادم، من تا حد زیادی با یک پیش زمینۀ DevOps می آیم – هنگامی که در سال 2009، یعنی حدود 15 سال قبل، واژۀ DevOps ابداع شد، من به تازگی داشتم وارد حوزۀ توسعۀ نرم افزار به عنوان یک حرفه میشدم. و از این رو متوجه مشکلاتی شدم که در نوشتن و استقرار کدها به روش‌های قابل اعتماد، کارآمد و قابل تکرار وجود داشت.

DevOps مدعی است می تواند بسیاری از این مشکلات کلاسیک را حل نماید – و این امر در صورتی محقق می شود که دولوپرها و اپراتورها به شکل نزدیک تری با یکدیگر کار کرده و به جای هل دادن آسیب پذیری ها و کدها به دیوار یکدیگر، برای انجام دادن کارها روی سیستم ها متمرکز شوند. و پانزده سال بعد، ما انواع متعددی از پیاده‌سازی‌های “DevOps” را در گستره وسیعی دیده ایم – از یک تیم واحد با همه افراد گرفته تا ایجاد تیم های تخصصی که عبارت DevOps را در نام خود دارند. راه حل درست را تا زمان مرگ گرمایی جهان می توان مورد بحث قرار داد. هر چند که با نگاه به اصطلاح بعدی هنری که در حال استفاده (و سوءاستفاده) است یعنی DevSecOps، فکر می کنم هنوز درس هایی برای آموختن از این تاریخ وجود دارد.

بزرگترین نکاتی که از انقلاب DevOps یاد گرفتیم این است که تکرارپذیری و خودکارسازی (اتومیت کردن)، نکاتی کلیدی هستند که تیم ها را قادر می سازند بدون شکستن چیزهای زیادی به سرعت حرکت کنند. (خوشبختانه) گذشت آن روزهایی که در آن دولوپرها مستقیماً از لپ تاپشان مستقر می شدند یا اپراتورها از طریق SCP کردن فایل های JAR به سرورهای مختلف این کار را انجام می دادند. (یک بار از من راجع به گروهی که در آن کار می کردم بپرسید تا برایتان تعریف کنم که آن ها یک فایل ورد تک فاصلۀ 11 صفحه ای دربارۀ نحوۀ استقرار سیستم داشتند.)

DevOps روش هایی را به همراه داشت که بخش “Ops” جهان را قابل برنامه ریزی تر کرد: فقط کافی است نگاهی به تمام ابزاری داشته باشید که Hashicorp از زمان تاسیس خود در همان روزهای اولیۀ DevOps (سال 2012) به بازار وارد کرده است. Terraform امکان زیرساخت قابل برنامه نویسی را فراهم می نماید، Packer مدیریت ساخت را به شکلی خودکار در می آورد، Nomad مقیاس پذیری قابل برنامه ریزی را ممکن می سازد و این لیست همینطور ادامه دار است. این ابزار و بسیاری از ابزارهای دیگر (نظیر ابزار متنوع CI)، ابزارهایی اساسی هستند که این امکان را برایمان فراهم می کنند تا از یک محیط دستی مستعد خطا به محیطی با ساخت های تکرارپذیر، استقرارهای تکرارپذیر و تحویل مداوم حرکت نماییم.

گام بعدی: شروع DevSecOps

اگر چه در حال حاضر واژۀ DevSecOps بیش از حد توسط افراد متعدد استفاده می شود – حتی در حقیقت سریع تر از حالتی که در آن یاد گرفتیم بیش از حد از واژۀ DevOps استفاده کنیم – نحوۀ به وجود آمدن و اساس این کلمه می تواند بینشی مهم در خصوص این که چرا اولین بار از این واژه استفاده شد برایمان فراهم نماید.

امروزه امنیت اساساً به خط مقدم هر بحثی در مورد نرم افزار تبدیل شده است. درست مانند 15 سال پیش که موج دوم انقلاب اینترنت و انقلاب اپلیکیشن ها شکل گرفت و کسب و کارها متوجه شدند که برای رقابت با یکدیگر، می بایست بتوانند ساخت و استقرار نرم افزار را با سرعت بیشتری انجام دهند، امروزه نیز این نکته را درک کرده اند که مزیت رقابتی (یا بزرگترین تهدید)، ناشی از مسائل امنیتی است. جایی که قبلاً سرعت نکتۀ کلیدی بود، حال امنیت به عنوان خط مقدم و مسئله اصلی محسوب می شود.

در دنیایی که در آن به سختی پاندمیک را پشت سر گذاشتیم، بیشتر از قبل به فناوری تکیه کرده ایم تا ما را به هم متصل کرده، از ما محافظت نماید و اطرافمان را احاطه کند. همین مسئله منجر به یک تهدید روزافزون برای امنیت داده ها و اپلیکیشن های آنلاین ما شده است. کسب و کارها باید راهی برای پاسخگویی پیدا نمایند، و این راه چیزی نیست جز این که به دنبال همان کیفیت هایی بگردیم که در DevOps دنبال آن بودیم: قابلیت اطمینان، کارایی و تکرارپذیری.

وضعیت «فعلی» امنیت

متاسفانه اغلب مواقع ما برعکسِ قابلیت اطمینان، کارایی و تکرارپذیری را داریم. بسیاری از برنامه های امنیتی به شدت به انسان یا فرآیندهای انسانی به عنوان روش اصلی برای درک سطح حمله امنیتی و آسیب پذیری آن سطح حمله متکی هستند.

اگر ما دنبال آن چیزی باشیم که شخص را «سازگار و موافق» با امنیت نماید، به مواردی نظیر تست های نفوذ بر می خوریم. اما به راستی این تست ها چند وقت یک بار اجرا می شوند؟ یک بار در سال؟ یک بار در هر فصل؟ یا شاید اگر خود را بسیار حرفه ای بدانیم، یک بار در ماه؟ از سوی دیگر، مهاجمان چند وقت یک بار به دنبال به دست آوردن جای پا (جایگاه ثابت) در سازمان شما – به عنوان تهدید واقعی که می خواهید از آن جلوگیری نمایید – می گردند؟ شرط می بندم خیلی بیشتر، شاید حتی به صورت روزانه.

بیشتر سازمان های امنیتی بالغ ممکن است تکنیک های فعالانه تری نظیر برنامه های باگ بانتی یا تیم های امنیتی تهاجمی داخلی به کار گیرند. و این ها قطعات ضروری پازل هستند، اما مشکل اصلی هنوز به انسان ها و مجموعه دانش آن ها از محیطی که در آن فعالیت می کنند بر می گردد. آخرین باری که دامنه هر یک از این برنامه ها را دوباره ارزیابی کردید، چه زمانی بود؟ فکر می کنید آن ها چند درصد از سطح حملۀ خارجی را پوشش می دهند؟ 80، 90، 95 درصد؟ مهاجم به این که چند درصد از سطح حملۀ شما پوشش داده می شود توجهی نمی کند… کافی است فقط یک بار درست حدس بزند.

چیزی که لازم است

بنابراین آنچه در اینجا مورد نیاز است یک لایه حفاظتی اضافی است – و مجموعه ای اضافی از ابزارها که به ما این امکان را می دهد از زمانِ انسانی که صرف رسیدگی به این مشکلات می کنیم، بهتر استفاده نماییم. درست همانطور که DevOps جایگزین SRE یا توسعه دهنده نرم افزار نشد، بلکه ابزار مورد نیاز برای کارآمد و مؤثر بودن را در اختیار آنها قرار داد، به همین روش مهندسان امنیتی، تیم های امنیتی تهاجمی و CISOها نیز باید به دنبال اتوماسیون و خودکارسازی باشند تا برنامه های امنیتی تهاجمی خود را توسعه دهند.

و زمانی که به این توسعه نگاه می کنیم، می بایست دربارۀ تمامی جنبه های برنامۀ امنیتی تهاجمی خود فکر کرده و ابزاری را به کار بگیرید که به هر یک از زمینه های مورد توجه می پردازد:

بیایید نگاهی به این مسئله داشته باشیم که چگونه ایجاد یک برنامۀ خودکار دربارۀ هر یک از این جنبه ها برای نسل بعدی مهندسان امنیتی و CISOها حیاتی است.

کشف دارایی

اولین سوالی که وقتی می خواهیم سطح حمله خارجی خود را ایمن کنیم باید از خود بپرسیم این است: سطح حمله خارجی ما چیست؟ اغلب اوقات این مسئله به مقدار زیادی حدس زدن نیاز دارد – ممکن است بدانیم مالک چه دامنه هایی هستیم و شاید به خدمات و DNS ابری دسترسی داریم. اما باید آن داده ها را با داده هایی که در گوشه های مختلف اینترنت (جایی که مهاجم ممکن است دنبال آن بگردد) یافت می شود ترکیب نماییم.

پایگاه داده های عمومی DNS و رکوردهای DNS قبلی، اطلاعات آرشیو شده دربارۀ سطح حملۀ ما، نتایج موتورهای جستجو در سراسر اینترنت، و پایگاه دادۀ عمومی سرتیفیکیت ها جزو تمامی جاهایی هستند که می بایست آن ها را بررسی کرده تا مطمئن شویم که دید کاملی از سطح حملۀ خارجیمان داریم. این که بخواهیم این کار را فقط به صورت دستی انجام دهیم یا حتی اسکریپت های bash بیشماری بنویسیم که این کار را به صورت نیمه اتوماتیک انجام دهد، کارساز نخواهد بود. ما می بایست همان ابزارهایی که مهاجمان و تست نفوذگران استفاده می کنند را به کار گیریم تا کشف دارایی را به صورت کامل انجام دهیم.

و خب بله، ProjectDiscovery ابزارهایی برای این کار دارد که همۀ آن ها به صورت متن باز هستند. برای مثال: subfinder، tlsx، dnsx، Chaos و uncover

غنی سازی دارایی

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

این اطلاعات شامل شناسایی اندپوینت های HTTP/S (هر دو نوعی که مثبت و منفی پاسخ می دهند)، جستجو برای پورت های باز و تنیدن تار دور خاصیت های وبمان است تا سایر APIها و سرویس هایی که فراخوانی می شوند را درک کنیم.

این یک مورد عالی دیگر برای اتوماسیون و خودکارسازی است – هر چقدر بیشتر بتوانیم به طور مکرر روی آنچه در سطح حمله ما وجود دارد و آنچه در آنجا اجرا می شود، تکرار داشته باشیم، احتمال بیشتری وجود دارد بتوانیم با سرعت به یک محیط تهدیدِ در حال تغییر، واکنش نشان دهیم.

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

تشخیص آسیب پذیری قابل بهره برداری

شاید شلوغ ترین بخش روی تمامی فضای ابزار امنیتی، مربوط به تشخیص آسیب پذیری باشد. ده ها، اگر نه صدها، اگر نه هزاران ابزار وجود دارد که پس از نگاشت سطح حملۀ شما، ده ها، اگر نه صد ها، اگر نه هزاران «آسیب پذیری» را به شما گزارش می دهند.

اما حتی اگر تنها چند روز در حوزۀ امنیت بوده باشید، از قبل می دانید که همۀ آسیب پذیری ها به طور یکسان ایجاد نمی شوند. برخی از مواردی که به عنوان «آسیب پذیری ها» علامت گذاری می شوند، در حقیقت فقط هشدارها یا فلگ هایی هستند که شاید برای یک (مامور) بازرسی مهم باشند، اما احتمالاً نشان دهندۀ یک آسیب پذیری واقعی قابل بهره برداری در هر یک از سیستم هایتان نیستند.

انجام اسکن اتوماتیک، قابل تکرار و قابل سفارشی سازی برای یافتن آسیب پذیری های قابل بهره برداری از دید بیرونی، بهترین روشی است که می توانید با استفاده از آن به تیمتان کمک کنید تا از بین نویزهای مختلف، سیگنال و نشان آسیب پذیری هایی که شما واقعاً به آن ها اهمیت می دهید را بیابند. و مشکل زمانی پیش می آید که از ابزاری استفاده کنید که بیشتر شبیه یک «جعبه سیاه» بوده، شما از یک سمت دارایی ها را به آن می دهید و از سمت دیگر توده ای از «آسیب پذیری» دریافت می کنید.

این همان جایی است که محبوب ترین ابزار متن باز ProjectDiscovery یعنی Nuclei کارساز خواهد بود. Nuclei توسط یک ریپازیتوری متن باز بزرگ از قالب های ایجاد شده توسط کامیونیتی پشتیبانی می گردد. این بدان معنی است که این قالب ها توسط هزاران مهندس به منظور اجرای میلیون ها اسکن در ماه استفاده می شوند و بنابراین هم توسط ProjectDiscovery و هم توسط کامیونیتی ما، به خوبی برای جستجوی حیاتی ترین و قابل بهره برداری ترین آسیب پذیری ها تنظیم می شوند.

و این مسئله همین جا متوقف نمی شود. شما همچنین می توانید قالب های Nuclei خود را بسازید – آنها در قالب یک DSL ساده مبتنی بر YAML نوشته شده اند – و بنابراین روی چیزهایی تمرکز کنید که تیم شما واقعاً به آنها اهمیت می دهد. با ساخت قالب های Nuclei سفارشی، تیم شما کنترل موقعیت را به دست گرفته و این امکان را برایتان فراهم می نماید که بدون متکی بودن به یک «جعبه سیاه» ناشناخته، مالک پایپلاین اتوماسیون امنیتی تهاجمی خود باشید.

اصلاح و حفاظت از رگراسیون

برای بسیاری از مردم – به ویژه کسانی که به دنبال حمله به شما هستند – مشکل به همین جا ختم می شود. وقتی یک آسیب پذیری قابل بهره برداری پیدا شد، حتما قرار است بگوییم «مشکل شخص دیگری است»، نه؟

اشتباه است. اکثر تیم های امنیتی که با آن ها صحبت کرده ام، دربارۀ دشواری ادغام کردن یافته ها و بازخوردشان داخل چرخۀ عمر توسعه صحبت می کنند و همچنین از مرحلۀ بعدی سخن می گویند که در آن می بایست بفهمند چگونه می توانند اصلاح و برطرف شدن این یافته های مختلف را ردیابی و تایید نمایند. این همان جایی است که در آن، اتومیت کردن و خودکارسازی، دوباره می تواند به شدت در زمان صرفه جویی کرده و از نادیده شمردن چیزها جلوگیری نماید.

به محض این که سیستم های خودکار ما بفهمند که آسیب پذیری X در دارایی Y وجود داشته و با استفاده از مراحل A، B و C می توان آن را بازتولید کرد، در این صورت آن سیستم تا زمان برطرف شدن آسیب پذیری مربوطه می بایست آن را ردیابی نماید. علاوه بر این، فقط به دلیل این که آسیب پذیری مربوطه را تنها در یک سیستم پیدا کردیم به این معنی نیست که کارمان تمام شده است: ما باید قادر باشیم به سرعت و به شکلی کارآمد این مراحل را در برابر همۀ سیستم های مربوطه تست نماییم… یک استدلال دیگر برای یک برنامه امنیتی تهاجمی کاملاً خودکار.

و در نهایت، وقتی که آسیب پذیری مربوطه برطرف شد، می خواهیم تست رگرسیون انجام دهیم تا مطمئن شویم دوباره توسط همان باگ «گزیده» نخواهیم شد. این نیز جای دیگری است که اتومیت کردن و خودکارسازی می تواند نقش درخشانی ایفا نماید… با در نظر گرفتن این مورد در برنامۀ خود، ما اکسپلویت هایی را که قبلاً حل کردیم «هرگز فراموش نخواهیم کرد».

و این همان چیزی است که ProjectDiscovery در حال حاضر روی آن کار می کند. ما در حال حاضر بر روی نسخۀ بتای Nuclei Cloud قرار داریم، پلتفرمی که تمامی ابزارهایی را که تا کنون در مورد آن صحبت کردیم را به همراه تست مجدد خودکار، تست رگراسیون، و ادغام با سیستم هایی را که تیم های توسعۀ شما برای ردیابی موارد استفاده می کنند گرد هم می آورد.

برنامه نویسی را شروع کنید

ما طیف گسترده ای از گزینه های موجود را در مورد ساخت یک برنامه امنیتی تهاجمی خودکار دیده ایم. من مطمئنم همۀ ما با مسلح شدن به این دانش و ابزارها، قادر خواهیم بود با استفاده از اتومیت کردن و خودکارسازی، در جهت دموکراتیک کردن امنیت تلاش کنیم و به این طریق به عنوان مهندسان امنیتی کارآمدتر و مؤثرتری فعالیت نماییم. در عین حال، با توجه به تغییرات سطح حمله و روش های حمله، همواره می بایست تکرارپذیری و توانیمان برای تکرار برنامه را به خاطر داشته باشیم.

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

کشف آسیب پذیری نباید به عنوان روشی محافظتی شما در برابر (مامور) بازرسی باشد، بلکه می بایست شما را در مقابل یک مهاجم محافظت نماید.

برنامۀ امنیتی تهاجمی شما باید بتواند مقیاس بسیار بالاتری را نسبت به تعداد اعضای تیم قرمزتان و بودجۀ در نظر گرفته شده برای باگ بانتیتان داشته باشد.

اگر تصمیم بگیرید تست نفوذ را متوقف کرده و برنامه نویسی را آغاز نمایید، متوجه خواهید شد که ساخت یک برنامۀ امنیتی تهاجمی اتومیت شده، احتمالا بهترین سرمایه ای است که تا کنون انجام داده اید.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *