ترس و نفرت از DevSecOps

ما 2 تحلیلگر کد، 4 ابزار تست پویا، صنایع دستی خود و 250 اسکریپت داشتیم. نه اینکه همه اینها در فرآیند فعلی مورد نیاز بود، اما زمانی که پیاده‌سازی DevSecOps را شروع کردید، باید تا انتها بروید.

منبع. شخصیت هایی که توسط جاستین رویلند و دن هارمون خلق شده اند.

SecDevOps چیست؟ در مورد DevSecOps چطور؟ چه تفاوت هایی دارند؟ امنیت برنامه - در مورد چیست؟ چرا رویکرد کلاسیک دیگر جواب نمی دهد؟ همه این سوالات جواب را می دانند یوری شابالین از امنیت اره ماهی. یوری به همه چیز با جزئیات پاسخ خواهد داد و مشکلات انتقال از مدل کلاسیک Application Security به فرآیند DevSecOps را تجزیه و تحلیل می کند: چگونه می توان به درستی به ادغام فرآیند توسعه ایمن در فرآیند DevOps نزدیک شد و چیزی را خراب نکرد، چگونه مراحل اصلی را طی کرد. در مورد تست امنیت، از چه ابزارهایی می توان استفاده کرد، چگونه آنها را با هم متفاوت کرد و چگونه آنها را به درستی پیکربندی کرد تا از مشکلات جلوگیری شود.

درباره سخنران: یوری شابالین - معمار ارشد امنیت در شرکت امنیت اره ماهی. مسئول اجرای SSDL، برای ادغام کلی ابزارهای تحلیل برنامه در یک اکوسیستم توسعه و آزمایش واحد. 7 سال سابقه در زمینه امنیت اطلاعات در Alfa-Bank، Sberbank و Positive Technologies که نرم افزار توسعه می دهد و خدمات ارائه می دهد، کار کرده است. سخنران کنفرانس های بین المللی ZeroNights، PHDays، RISSPA، OWASP.

امنیت برنامه: در مورد چیست؟

امنیت برنامه بخش امنیتی است که مسئولیت امنیت برنامه را بر عهده دارد. این در مورد زیرساخت یا امنیت شبکه نیست، بلکه در مورد آنچه ما می نویسیم و توسعه دهندگان روی آن کار می کنند - اینها نقص ها و آسیب پذیری های خود برنامه است.

جهت SDL یا SDLC - چرخه عمر توسعه امنیت - توسعه یافته توسط مایکروسافت. این نمودار مدل متعارف SDLC را نشان می دهد که وظیفه اصلی آن مشارکت امنیت در هر مرحله از توسعه است، از الزامات، تا انتشار و انتشار تا تولید. مایکروسافت متوجه شد که باگ‌های زیادی در جشن برگزار می‌شود، تعداد آنها بیشتر است و باید کاری در مورد آن انجام شود، و آنها این رویکرد را پیشنهاد کردند که متعارف شد.

Application Security و SSDL همانطور که معمولاً تصور می شود با هدف شناسایی آسیب پذیری ها نیستند، بلکه هدف آنها جلوگیری از وقوع آنها است. با گذشت زمان، رویکرد متعارف مایکروسافت بهبود یافته، توسعه یافته است، و دارای جزئیات عمیق تری است.

SDLC متعارف در روش‌های مختلف بسیار دقیق است - OpenSAMM، BSIMM، OWASP. روش ها متفاوت هستند، اما به طور کلی مشابه هستند.

ایجاد امنیت در مدل سررسید

من آن را بیشتر دوست دارم BSIMM - ایجاد امنیت در مدل سررسید. اساس این روش، تقسیم فرآیند امنیت برنامه به 4 حوزه است: حاکمیت، اطلاعات، نقاط تماس SSDL و استقرار. هر دامنه دارای 12 عمل است که به صورت 112 فعالیت نمایش داده می شود.

هر یک از 112 فعالیت دارای 3 سطح بلوغ: مبتدی، متوسط ​​و پیشرفته. شما می توانید تمام 12 تمرین را در بخش ها مطالعه کنید، مواردی را که برای شما مهم هستند انتخاب کنید، نحوه پیاده سازی آنها را بیابید و به تدریج عناصری را اضافه کنید، به عنوان مثال، تجزیه و تحلیل کد استاتیک و پویا یا بررسی کد. شما به عنوان بخشی از اجرای فعالیت های انتخاب شده، برنامه ای را ترسیم می کنید و با آرامش طبق آن کار می کنید.

چرا DevSecOps

DevOps یک فرآیند کلی بزرگ است که در آن باید از امنیت مراقبت شود.

در ابتدا DevOps شامل بررسی های امنیتی در عمل، تعداد تیم های امنیتی بسیار کمتر از الان بود و آنها نه به عنوان شرکت کننده در فرآیند، بلکه به عنوان یک نهاد کنترل و نظارت عمل می کردند که از آن مطالبات می کند و کیفیت محصول را در پایان عرضه بررسی می کند. این یک رویکرد کلاسیک است که در آن تیم‌های امنیتی پشت دیواری از توسعه بودند و در این فرآیند شرکت نکردند.

مشکل اصلی این است که امنیت اطلاعات از توسعه جداست. معمولاً این نوعی مدار IB است و شامل 2-3 ابزار بزرگ و گران قیمت است. هر شش ماه یک بار، کد منبع یا برنامه برای آزمایش می رسد و سالی یک بار پنتست ها. همه اینها به این واقعیت منجر می شود که تاریخ انتشار این صنعت به تعویق می افتد و تعداد زیادی آسیب پذیری از ابزارهای خودکار بر روی توسعه دهنده قرار می گیرد. جدا کردن و تعمیر همه اینها غیرممکن است، زیرا حتی در شش ماه گذشته نتایج برچیده نشده است و در اینجا یک دسته جدید است.

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

انتقال به DevSecOps

مهمترین کلمه در چرخه حیات توسعه امنیت این است "روند". قبل از اینکه به خرید ابزار فکر کنید باید این را درک کنید.

فقط گنجاندن ابزارها در فرآیند DevOps کافی نیست - ارتباط و درک بین شرکت کنندگان در فرآیند مهم است.

مردم مهمتر از ابزار هستند

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

یک مورد رایج زمانی است که بخش امنیتی یک ابزار خوب و گران قیمت با طیف وسیعی از ویژگی‌ها را انتخاب کرده و به سراغ توسعه‌دهندگان می‌رود تا آن را در فرآیند ایجاد کند. اما کار نمی کند - این فرآیند به گونه ای طراحی شده است که محدودیت های یک ابزار از قبل خریداری شده در پارادایم فعلی نمی گنجد.

ابتدا توضیح دهید که چه نتیجه ای می خواهید و فرآیند چگونه خواهد بود. این به درک نقش ابزار و امنیت در فرآیند کمک می کند.

با آنچه در حال حاضر در حال استفاده است شروع کنید

قبل از خرید ابزارهای گران قیمت، به آنچه در حال حاضر دارید نگاه کنید. هر شرکت دارای الزامات امنیتی است که برای توسعه اعمال می شود، بررسی ها، تست های نفوذ وجود دارد - چرا همه اینها را به شکلی قابل درک و راحت برای همه تبدیل نکنید؟

معمولاً مورد نیاز یک تلمود کاغذی است که روی یک قفسه قرار دارد. موردی بود که ما به شرکت آمدیم تا فرآیندها را بررسی کنیم و از آنها بخواهیم الزامات امنیتی نرم افزار را نشان دهند. متخصصی که این کار را انجام داد مدت ها به دنبال این بود:

- حالا در جایی در یادداشت ها مسیری وجود داشت که این سند در آن قرار دارد.

در نتیجه یک هفته بعد سند را دریافت کردیم.

برای الزامات، بررسی ها و موارد دیگر، یک صفحه ایجاد کنید، به عنوان مثال در تلاقی - برای همه راحت است.

قالب بندی مجدد آنچه در حال حاضر وجود دارد و استفاده از آن برای شروع آسان تر است.

از Security Champions استفاده کنید

معمولاً، در یک شرکت متوسط ​​برای 100-200 توسعه دهنده، یک افسر امنیتی وجود دارد که چندین کار را انجام می دهد و از نظر فیزیکی وقت ندارد همه چیز را بررسی کند. حتی اگر تمام تلاش خود را بکند، به تنهایی تمام کدهایی را که توسعه تولید می کند بررسی نمی کند. برای چنین مواردی، یک مفهوم توسعه داده شده است - قهرمانان امنیتی.

Security Champions فردی در تیم توسعه است که به امنیت محصول شما علاقه مند است.

Security Champion یک نقطه ورود به تیم توسعه و یک مبشر امنیتی است که همه در یک گروه قرار دارند.

معمولاً وقتی یک افسر امنیتی به تیم توسعه می‌آید و خطایی در کد را گوشزد می‌کند، پاسخی متعجب دریافت می‌کند:

- و تو کی هستی؟ من برای اولین بار شما را می بینم. همه چیز با من خوب است - دوست ارشد من "اعمال" را در بررسی کد قرار داد، ما ادامه می دهیم!

این یک وضعیت معمولی است، زیرا اعتماد به افراد ارشد یا فقط هم تیمی‌هایی که توسعه‌دهنده دائماً در محل کار و بررسی کد با آنها تعامل دارند، بیشتر است. اگر قهرمان امنیت به جای نگهبان به خطا و عواقب آن اشاره کند، حرف او وزن بیشتری خواهد داشت.

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

بنابراین اجرای Security Champions و گسترش نفوذ تیم امنیتی را در نظر بگیرید. برای خود قهرمان، این نیز مفید است: توسعه حرفه ای در یک زمینه جدید، گسترش افق های فنی، پمپاژ مهارت های فنی، مدیریتی و رهبری، افزایش ارزش بازار. این برخی از عناصر مهندسی اجتماعی، "چشم" شما در تیم توسعه است.

مراحل تست

پارادایم 20 در 80 می گوید 20 درصد تلاش ها 80 درصد نتیجه را می دهد. این 20 درصد شیوه های تحلیل برنامه هستند که می توانند و باید خودکار شوند. نمونه هایی از این فعالیت ها تجزیه و تحلیل استاتیک - است SASTتجزیه و تحلیل پویا - DAST، и کنترل منبع باز. من در مورد فعالیت‌ها و همچنین ابزارها، با چه ویژگی‌هایی که معمولاً هنگام معرفی آنها در فرآیند با آن‌ها مواجه می‌شویم، و نحوه انجام صحیح آن، بیشتر به شما خواهم گفت.

مشکلات اصلی ابزار

من مشکلات مربوط به همه سازهایی را که نیاز به توجه دارند برجسته خواهم کرد. من آنها را با جزئیات بیشتری تجزیه و تحلیل خواهم کرد تا بیشتر تکرار نشود.

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

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

بدون ادغام با ابزارهای موجود. به ابزارها از نظر ادغام با آنچه قبلاً استفاده می کنید نگاه کنید. به عنوان مثال، اگر جنکینز یا تیم سیتی دارید، ادغام ابزارها را با این نرم افزار بررسی کنید، نه با GitLab CI که از آن استفاده نمی کنید.

فقدان یا پیچیدگی بیش از حد سفارشی سازی. اگر ابزار دارای API نیست، پس چرا به آن نیاز است؟ هر کاری که می توان در رابط انجام داد باید از طریق API در دسترس باشد. در حالت ایده‌آل، ابزار باید قابلیت سفارشی‌سازی چک‌ها را داشته باشد.

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

ویژگی های فرآیند

علاوه بر ویژگی های ابزار، ویژگی های فرآیند توسعه را در نظر بگیرید. به عنوان مثال، دخالت در توسعه یک اشتباه معمولی است. بیایید ببینیم چه ویژگی های دیگری باید در نظر گرفته شود و تیم امنیتی باید به چه مواردی توجه کند.

به منظور ایجاد اختلال در توسعه و مهلت انتشار، ایجاد کنید قوانین مختلف و متفاوت توپ را نشان دهید - معیارهای توقف فرآیند ساخت در صورت وجود آسیب پذیری ها - برای محیط های مختلف. به عنوان مثال، ما درک می کنیم که شعبه فعلی به یک غرفه توسعه یا UAT می رود، بنابراین متوقف نمی شویم و نمی گوییم:

- شما اینجا آسیب پذیری دارید، جایی جلوتر نمی روید!

در این مرحله، مهم است که به توسعه دهندگان بگوییم که مسائل امنیتی وجود دارد که باید مراقب آنها باشند.

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

- بچه ها، شما مشکل دارید، لطفا به آنها توجه کنید.

در مرحله UAT، ما دوباره هشدارهایی را در مورد آسیب پذیری ها نشان می دهیم، و در مرحله خروج در پروم می گوییم:

"بچه ها، ما چندین بار به شما هشدار دادیم، شما کاری انجام ندادید - ما شما را با این کار رها نمی کنیم.

اگر در مورد کد و پویایی صحبت می کنیم، لازم است که آسیب پذیری ها را فقط در مورد آن ویژگی ها و کدهایی که به تازگی در این ویژگی نوشته شده است نشان داده و هشدار دهیم. اگر توسعه‌دهنده دکمه را 3 پیکسل جابه‌جا کرده باشد و به او بگوییم که در آنجا تزریق SQL دارد و بنابراین باید فوراً تعمیر شود، این اشتباه است. فقط به آنچه اکنون نوشته شده است و به تغییری که در برنامه ایجاد می شود نگاه کنید.

فرض کنید نقص عملکردی داریم - روشی که برنامه نباید کار کند: پول منتقل نمی شود، وقتی روی دکمه کلیک می کنید، هیچ انتقالی به صفحه بعدی وجود ندارد یا محصول بارگیری نمی شود. نقص های امنیتی - اینها همان نقص ها هستند، اما نه در زمینه برنامه، بلکه امنیت.

همه مسائل مربوط به کیفیت نرم افزار مسائل امنیتی نیستند. اما تمام مشکلات امنیتی مربوط به کیفیت نرم افزار است. شریف منصور، اکسپدیا.

از آنجایی که همه آسیب‌پذیری‌ها نقص‌های یکسانی هستند، باید در همان مکان همه نقص‌های توسعه قرار گیرند. پس گزارش ها و پی دی اف های ترسناکی که هیچ کس نمی خواند را فراموش کنید.

زمانی که برای یک شرکت توسعه کار می کردم، گزارشی از ابزارهای تحلیل استاتیک دریافت کردم. آن را باز کردم، وحشت کردم، قهوه درست کردم، 350 صفحه را ورق زدم، بستم و به کارم ادامه دادم. گزارش های بزرگ، گزارش های مرده هستند. معمولاً آنها به جایی نمی‌روند، ایمیل‌ها حذف می‌شوند، فراموش می‌شوند، گم می‌شوند، یا کسب‌وکار می‌گوید ریسک می‌کند.

چه باید کرد؟ ما به سادگی نقص های تأیید شده ای را که پیدا کردیم به فرمی مناسب برای توسعه تبدیل می کنیم، به عنوان مثال، آن را به بک لاگ در Jira اضافه می کنیم. عیوب به ترتیب اولویت در کنار عیوب عملکردی و عیوب آزمایشی اولویت بندی و رفع می شوند.

تجزیه و تحلیل استاتیک - SAST

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

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

منفی عدم پشتیبانی از زبان های مورد نیاز است.

ادغام های مورد نیاز، که به نظر ذهنی من باید در ابزار باشد:

• ابزار یکپارچه سازی: Jenkins، TeamCity و Gitlab CI.
• محیط توسعه: Intellij IDEA، Visual Studio. برای یک توسعه‌دهنده راحت‌تر است که وارد یک رابط نامفهوم نشود که هنوز باید به خاطر بسپارد، بلکه تمام ادغام‌ها و آسیب‌پذیری‌های لازم را که درست در محل کار در محیط توسعه خودش پیدا کرده است، ببیند.
• بررسی کد: SonarQube و بررسی دستی.
• ردیاب های نقص: جیرا و بوگزیلا.

تصویر برخی از بهترین نمایندگان تجزیه و تحلیل استاتیک را نشان می دهد.

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

منبع باز SAST تعداد زیادی آسیب‌پذیری یا DataFlow پیچیده را پیدا نمی‌کند، اما می‌توان و باید از آن‌ها هنگام ساخت یک فرآیند استفاده کرد. آنها کمک می کنند تا بفهمیم فرآیند چگونه ساخته می شود، چه کسی به اشکالات پاسخ می دهد، چه کسی گزارش می دهد، چه کسی گزارش می دهد. اگر می خواهید مرحله اولیه ایجاد امنیت کد خود را انجام دهید، از راهکارهای منبع باز استفاده کنید.

اگر در ابتدای سفر هستید و چیزی ندارید: نه CI، نه جنکینز و نه تیم سیتی، چگونه می توان این را ادغام کرد؟ ادغام فرآیند را در نظر بگیرید.

ادغام در سطح CVS

اگر Bitbucket یا GitLab دارید، می توانید یکپارچه سازی را در سطح انجام دهید سیستم نسخه های همزمان.

بر اساس رویداد درخواست کشیدن، متعهد شدن شما کد را اسکن می کنید و در وضعیت ساخت نشان می دهید که بررسی امنیتی انجام شده یا ناموفق بوده است.

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

ادغام با سیستم بررسی کد

یک بار، کاربر فنی AppSec را به عنوان بازبینی کننده پیش فرض در تعدادی از پروژه های مهم تعیین کردیم. بسته به اینکه آیا خطا در کد جدید پیدا شده است یا هیچ خطایی وجود ندارد، بازبین وضعیت را در درخواست کشش به عنوان "پذیرفتن" یا "نیاز به کار" قرار می دهد - یا همه چیز خوب است، یا باید نهایی کنید و به چه چیزی دقیقاً پیوند دهید. برای پایان دهی. برای ادغام با نسخه ای که منتشر می شود، در صورت عدم موفقیت در آزمون IS، ادغام را غیرفعال کرده ایم. ما این را در بررسی کد دستی گنجانده‌ایم، و بقیه شرکت‌کنندگان در فرآیند وضعیت‌های امنیتی این فرآیند خاص را مشاهده کردند.

ادغام با SonarQube

خیلی ها دارند دروازه با کیفیت از نظر کیفیت کد اینجا هم همینطور است - شما می توانید همان دروازه ها را فقط برای سازهای SAST بسازید. همان رابط، همان دروازه با کیفیت وجود خواهد داشت، فقط آن را فراخوانی خواهد کرد دروازه امنیتی. و همچنین، اگر فرآیندی را با استفاده از SonarQube تنظیم کنید، می‌توانید به راحتی همه چیز را در آنجا ادغام کنید.

ادغام در سطح CI

در اینجا نیز همه چیز بسیار ساده است:

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

این همه در یک دنیای صورتی کامل است. در زندگی واقعی اینطور نیست، اما ما تلاش می کنیم. نتیجه انجام بررسی های امنیتی باید مشابه نتایج تست های واحد باشد.

به عنوان مثال، ما یک پروژه بزرگ گرفتیم و تصمیم گرفتیم که اکنون آن را با SAST اسکن کنیم - OK. ما این پروژه را به SAST انتقال دادیم، 20 آسیب پذیری به ما داد و با اراده قوی تصمیم گرفتیم که همه چیز خوب است. 000 آسیب پذیری بدهی فنی ماست. ما بدهی را در یک جعبه قرار می دهیم، به آرامی آن را جمع می کنیم و باگ هایی را در ردیاب های نقص ایجاد می کنیم. شرکتی را استخدام کنید، همه کارها را خود انجام دهید یا از Security Champions به ما کمک کنید و بدهی فنی کاهش می یابد.

و تمام آسیب‌پذیری‌های تازه ظاهر شده در کد جدید باید به همان روشی که خطاهای یک واحد یا در تست‌های خودکار حذف شوند. به طور نسبی، مونتاژ شروع شد، دور شد، دو تست و دو تست امنیتی سقوط کردند. خوب - ما رفتیم، به آنچه اتفاق افتاد نگاه کردیم، یکی را تصحیح کردیم، دومی را اصلاح کردیم، دفعه بعد رانندگی کردیم - همه چیز خوب است، هیچ آسیب پذیری جدیدی ظاهر نشده است، آزمایش ها شکست نخورده اند. اگر این کار عمیق‌تر است و باید آن را به خوبی درک کنید، یا رفع آسیب‌پذیری‌ها بر لایه‌های بزرگی از آنچه در زیر کاپوت قرار دارد تأثیر می‌گذارد: یک اشکال به ردیاب نقص وارد می‌شود، اولویت‌بندی و رفع می‌شود. متأسفانه دنیا کامل نیست و آزمایش ها گاهی اوقات با شکست مواجه می شوند.

نمونه‌ای از گیت امنیتی، آنالوگ یک گیت با کیفیت، از نظر وجود و تعداد آسیب‌پذیری‌ها در کد است.

ما با SonarQube ادغام می شویم - افزونه نصب شده است، همه چیز بسیار راحت و جالب است.

یکپارچه سازی محیط توسعه

گزینه های یکپارچه سازی:

• شروع اسکن از محیط توسعه حتی قبل از commit.
• مشاهده نتایج
• تجزیه و تحلیل نتایج.
• همگام سازی با سرور

نتیجه گرفتن از سرور اینگونه به نظر می رسد.

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

متن باز

این موضوع مورد علاقه من است. همه از کتابخانه های متن باز استفاده می کنند - چرا وقتی می توانید یک کتابخانه آماده که همه چیز در آن پیاده سازی شده است، یک دسته عصا و دوچرخه بنویسید؟

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

تجزیه و تحلیل منبع باز - OSA

این ابزار شامل سه مرحله اصلی است.

یافتن آسیب پذیری در کتابخانه ها برای مثال، این ابزار می‌داند که ما از نوعی کتابخانه استفاده می‌کنیم و در CVE یا در ردیاب‌های باگ آسیب‌پذیری‌هایی وجود دارد که مربوط به این نسخه از کتابخانه است. اگر سعی کنید از آن استفاده کنید، ابزار به شما هشدار می دهد که کتابخانه آسیب پذیر است و به شما توصیه می کند از نسخه دیگری استفاده کنید که در آن هیچ آسیب پذیری وجود ندارد.

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

تجزیه و تحلیل اجزای مورد استفاده در یک محیط صنعتی. یک موقعیت فرضی را تصور کنید که ما در نهایت توسعه را کامل کرده ایم و آخرین نسخه میکروسرویس خود را برای صنعت عرضه کرده ایم. او به طرز شگفت انگیزی در آنجا زندگی می کند - یک هفته، یک ماه، یک سال. ما آن را جمع آوری نمی کنیم، ما بررسی های امنیتی انجام نمی دهیم، به نظر می رسد همه چیز خوب است. اما ناگهان، دو هفته پس از انتشار، یک آسیب‌پذیری مهم در کامپوننت منبع باز ظاهر می‌شود که ما در این مجموعه خاص، در محیط صنعتی از آن استفاده می‌کنیم. اگر آنچه و کجا استفاده می کنیم را ثبت نکنیم، این آسیب پذیری به سادگی دیده نمی شود. برخی از ابزارها توانایی نظارت بر آسیب پذیری های موجود در کتابخانه ها را دارند که در حال حاضر در پروم استفاده می شوند. این بسیار کاربردی است.

ویژگی ها:

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

چند نمونه از رهبران این حوزه که درگیر تجزیه و تحلیل متن باز هستند.

تنها رایگان است بررسی وابستگی از OWASP. می توانید در مراحل اول آن را روشن کنید، ببینید چگونه کار می کند و از چه چیزی پشتیبانی می کند. اساساً، اینها همه محصولات ابری یا داخلی هستند، اما در پشت پایه آنها همچنان به اینترنت می روند. آنها کتابخانه های شما را ارسال نمی کنند، بلکه هش ها یا مقادیر آنها را که محاسبه می کنند و اثر انگشت را به سرور خود ارسال می کنند تا اخبار وجود آسیب پذیری ها را دریافت کنند.

یکپارچه سازی فرآیند

کنترل کتابخانه محیطیکه از منابع خارجی دانلود می شوند. ما مخازن خارجی و داخلی داریم. برای مثال، ما Nexus را در مرکز رویداد داریم و می‌خواهیم مطمئن شویم که هیچ آسیب‌پذیری با وضعیت «بحرانی» یا «بالا» در مخزن ما وجود ندارد. می‌توانید پروکسی را با استفاده از ابزار چرخه حیات فایروال Nexus تنظیم کنید تا چنین آسیب‌پذیری‌هایی قطع شده و در مخزن داخلی گنجانده نشود.

ادغام CI. در همان سطح با تست های خودکار، تست های واحد و تقسیم به مراحل توسعه: توسعه، تست، تولید. در هر مرحله، می توانید هر کتابخانه ای را دانلود کنید، از هر چیزی استفاده کنید، اما اگر چیزی سخت با وضعیت "بحرانی" وجود دارد، احتمالاً باید توجه توسعه دهندگان را در مرحله ورود به پروم به این موضوع جلب کنید.

ادغام مصنوعات: Nexus و JFrog.

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

یکپارچه سازی سی دی. این یک ویژگی جالب است که من واقعاً آن را دوست دارم و قبلاً در مورد آن صحبت کرده ام - نظارت بر ظهور آسیب پذیری های جدید در یک محیط صنعتی. اینجوری کار میکنه

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

• هنگام ساخت، ما بررسی می کنیم که هیچ کس چیز بدی نداشته باشد، همه اجزا سالم هستند و هیچ کس چیز خطرناکی روی درایو فلش نیاورده است.
• ما فقط مؤلفه های قابل اعتماد در مخزن داریم.
• هنگام استقرار، ما یک بار دیگر خود بسته را بررسی می کنیم: war، jar، DL یا Docker image برای اینکه با خط مشی مطابقت دارد.
• هنگام ورود به محیط صنعتی، آنچه را که در محیط صنعتی اتفاق می افتد نظارت می کنیم: آسیب پذیری های بحرانی ظاهر می شوند یا ظاهر نمی شوند.

تجزیه و تحلیل دینامیک - DAST

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

همین سیستم به شما امکان می دهد آسیب پذیری های قالب را در متن باز بررسی کنید. از آنجایی که DAST نمی‌داند از کدام منبع باز استفاده می‌کنیم، به سادگی الگوهای "مخفف" را پرتاب می‌کند و پاسخ‌های سرور را تجزیه و تحلیل می‌کند:

- بله، اینجا مشکل سریال زدایی وجود دارد، اما اینجا نه.

خطرات بزرگی در این زمینه وجود دارد، زیرا اگر این تست امنیتی را روی همان پایه ای که آزمایش کننده ها با آن کار می کنند انجام دهید، ممکن است اتفاقات ناخوشایندی رخ دهد.

• بار زیاد در شبکه سرور برنامه
• بدون ادغام
• امکان تغییر تنظیمات برنامه تحلیل شده.
• هیچ پشتیبانی از فناوری های لازم وجود ندارد.
• سختی تنظیم.

زمانی که بالاخره AppScan را راه اندازی کردیم، شرایطی داشتیم: برای مدت طولانی دسترسی به برنامه را از دست دادیم، 3 حساب دریافت کردیم و خوشحال شدیم - در نهایت، همه چیز را بررسی خواهیم کرد! ما یک اسکن راه‌اندازی کردیم و اولین کاری که AppScan انجام داد این بود که وارد پنل مدیریت شد، همه دکمه‌ها را سوراخ کرد، نیمی از داده‌ها را تغییر داد و سپس سرور را به طور کامل با خودش کشت. فرم پستی-درخواست ها. توسعه با تست گفت:

"بچه ها، آیا با من شوخی می کنید؟! ما به شما حساب دادیم و شما ایستاده اید!

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

شایان ذکر است که می توانید از آن به عنوان آنالوگ تست بار استفاده کنید. در مرحله اول، می توانید اسکنر پویا را در 10-15 رشته روشن کنید و ببینید چه اتفاقی می افتد، اما معمولا، همانطور که تمرین نشان می دهد، هیچ چیز خوبی نیست.

چند منبع که ما معمولا از آنها استفاده می کنیم.

ارزش برجسته کردن را دارد سوئیت Burp "چاقوی سوئیسی" برای هر حرفه ای امنیتی است. همه از آن استفاده می کنند و بسیار راحت است. نسخه آزمایشی جدیدی از نسخه سازمانی اکنون منتشر شده است. اگر قبلاً فقط یک ابزار مستقل با افزونه ها بود، اکنون توسعه دهندگان بالاخره یک سرور بزرگ می سازند که از طریق آن می توان چندین عامل را مدیریت کرد. عالیه، پیشنهاد میکنم امتحانش کنید

یکپارچه سازی فرآیند

ادغام بسیار خوب و ساده است: پس از نصب موفقیت آمیز اسکن را شروع کنید برنامه های کاربردی روی پایه و اسکن پس از آزمایش موفقیت آمیز یکپارچه سازی.

اگر ادغام ها کار نکنند یا خرد و توابع ساختگی وجود داشته باشد، بی معنی و بی فایده است - مهم نیست که چه الگوی ارسال کنیم، سرور همچنان به همان روش پاسخ می دهد.

• در حالت ایده آل، یک میز تست جداگانه.
• قبل از تست، توالی ورود را یادداشت کنید.
• تست سیستم مدیریت فقط دستی است.

روند

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

هر فرآیندی نیاز به کنترل دارد.

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

هر گونه اطلاعات مفید است. لازم است در بخش‌های مختلف به بررسی این موضوع بپردازیم که از این یا آن ابزار بهتر استفاده می‌شود، جایی که فرآیند به طور خاص کاهش می‌یابد. شاید ارزش آن را داشته باشد که زمان پاسخ توسعه را بررسی کنیم تا ببینیم کجا می توان فرآیند را بر اساس زمان بهبود بخشید. هر چه داده ها بیشتر باشد، برش های بیشتری را می توان از سطح بالا تا جزئیات هر فرآیند ایجاد کرد.

از آنجایی که همه تحلیلگرهای استاتیک و دینامیک دارای API، روش های راه اندازی، اصول خاص خود هستند، برخی زمان بندی دارند، برخی دیگر ندارند - ما در حال نوشتن یک ابزار هستیم. AppSec Orchestrator، که به شما امکان می دهد یک نقطه ورودی واحد به کل فرآیند از محصول ایجاد کنید و آن را از یک نقطه مدیریت کنید.

مدیران، توسعه‌دهندگان و مهندسین امنیت یک نقطه ورودی دارند که از آنجا می‌توانند ببینند چه چیزی در حال اجرا است، اسکن‌ها را پیکربندی و اجرا کنند، نتایج اسکن را دریافت کنند و الزامات را ارسال کنند. ما سعی می‌کنیم از تکه‌های کاغذ فاصله بگیریم، همه چیز را به انسانی تبدیل کنیم که توسعه استفاده می‌کند - صفحاتی در Confluence با وضعیت و معیارها، نقص در Jira یا در ردیاب‌های مختلف نقص، یا جاسازی در یک فرآیند همزمان / ناهمزمان در CI / CD.

گیرنده های کلیدی

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

کیفیت محصول - هدف مشترک هم امنیت و هم توسعه. ما یک کار را انجام می دهیم، سعی می کنیم اطمینان حاصل کنیم که همه چیز به درستی کار می کند و خطرات اعتباری و ضرر مالی وجود ندارد. به همین دلیل است که ما رویکرد DevSecOps، SecDevOps را به منظور برقراری ارتباط و بهتر کردن محصول ترویج می کنیم.

با چیزی که از قبل وجود دارد شروع کنید: الزامات، معماری، بررسی های جزئی، آموزش ها، دستورالعمل ها. لازم نیست فوراً همه اقدامات را برای همه پروژه ها اعمال کنید - به صورت تکراری حرکت کنید. استاندارد واحدی وجود ندارد آزمایش و رویکردها و راه حل های مختلف را امتحان کنید.

علامت مساوی بین نقص IS و نقص عملکردی.

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

اگر اندازه تیم IB کوچک است - از Security Champions استفاده کنید.

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

ابزار مورد نیاز

• مثبت کاذب کم.
• زمان تجزیه و تحلیل کافی
• سهولت استفاده
• در دسترس بودن ادغام ها
• درک نقشه راه توسعه محصول
• امکان سفارشی سازی ابزار.

گزارش یوری به عنوان یکی از بهترین ها در DevOpsConf 2018 انتخاب شد. برای آشنایی با ایده های جالب تر و موارد کاربردی، در 27 و 28 می به Skolkovo بیایید. DevOpsConf در داخل جشنواره RIT++. حتی بهتر است، اگر مایل به اشتراک گذاری تجربه خود هستید، پس درخواست دادن گزارش خود را تا 21 آوریل ارسال کنید.

منبع: www.habr.com