شما یک ستاره راک توسعه‌دهنده در تیمی از نینجاهای کدنویسی با مهارت مشابه، بدون نقص و بدون نقص هستید. تیم شما چند ماه گذشته را صرف کدنویسی، بستن داستان ها و حماسه ها، ساختن نسل بعدی، عملکردی الهام بخش و مخل صنعت برای مشتریان تجاری شما کرده است. چند روزی تا آزادی فاصله دارید و نوزادتان را برای آزمایش به تیم امنیتی تحویل می دهید.
شما با یک گزارش ارزیابی امنیتی 20، 30 صفحه ای ضربه می خورید. برنامه شما مملو از نقص های امنیتی است. کودک عاشق زمانی زیبا، خالص و بی نقص شما به یک کودک نوپای جیغ، مشت کوبنده و عصبانی تبدیل شده است که نیاز مبرم به چرت زدن دارد.
پنج مرحله غم و اندوه: انکار مدل کوبلر راس را شروع کنید. خشم. چانه زنی. افسردگی. پذیرش – پذیرفته شدن.
اکنون می بینید که بین یک سنگ و یک مکان سخت گیر کرده اید. آیا برنامه خود را طبق برنامه با نقص های امنیتی شناخته شده منتشر می کنید و وضعیت امنیتی و شهرت شرکت خود را به خطر می اندازید؟ یا اینکه یک برنامه سخت‌شده را وصله می‌کنید، دوباره آزمایش می‌کنید و منتشر می‌کنید، اما از تاریخ وعده اولیه خود گذشته‌اید، هزینه‌های پروژه افزایش می‌یابد و خطر از دست دادن دلار برای کسب‌وکار وجود دارد؟
درک اینکه چرا توسعه دهندگان InfoSec را به عنوان مانعی برای اهداف و اهداف پروژه خود می بینند دشوار نیست. این «ما» در مقابل «آنها»، آدم‌های خوب در برابر آدم‌های بد هستیم. در واقع، InfoSec به طور منظم به عنوان یک مانع در مسیر رسیدن به سرزمین موعود تکمیل پروژه در نظر گرفته می شود.
نباید اینطور باشد. این نباید «ما در برابر آنها» باشد، بلکه باید «ما، با هم» باشد.
بیایید با بررسی شش موردی که توسعه‌دهندگان از تیم‌های امنیت اطلاعات خود می‌خواهند، از این وضعیت جلوگیری کنیم:
1. توانمندسازی
نه، منظورم قدرت مانند دسترسی مستقیم به سرور پایگاه داده تولید نیست، منظورم این است که تیم‌های DevOps می‌خواهند به تنهایی از قدرت عالی در امنیت برخوردار باشند. تیم‌های امنیتی هنوز باید در زمینه امنیت عالی باشند، اما توسعه‌دهندگان نمی‌خواهند دست نگه‌داشتن و آزاری را که گاهی از سوی افراد خوش‌نیت امنیتی می‌آیند، نداشته باشند.
برای رفع این مشکل، متخصصان امنیتی می‌توانند تیم‌های DevOps خود را به روش‌های زیر تقویت کنند:
آموزش های امنیتی ارائه دهید و به آنها فرصت یادگیری بدهید.
یک فرهنگ امنیتی قوی و خوشایند در شرکت خود ایجاد کنید که ایجاد روابط، پرسیدن سوال و اندازه گیری با معیارهای مثبت را تشویق می کند.
به آنها مالکیت بدهید تا بخواهند تعداد آسیب پذیری های امنیتی را کاهش دهند و از اصلاحات یا استراتژی های کاهش لازم حمایت کنند.
دست از سر راه آنها بردارید – آنها را کوچک مدیریت نکنید! ابزارهایی را که برای موفقیت نیاز دارند به آنها بدهید و اعتماد کنید که کار درست را انجام خواهند داد.
2. ابزار و ادغام
توسعه دهندگان ابزارها و ادغام ها را دوست دارند، به خصوص اگر استفاده از آنها آسان باشد و با پشته فناوری موجود خود کار کنند. اگر ابزار منبع باز یا رایگان باشد، امتیاز جایزه! توسعه دهندگان، مانند هر کس دیگری، می خواهند در هنگام انجام کار خود تا حد امکان دردسر کمتری داشته باشند.
هنگامی که تیم‌های DevOps به ابزار امنیتی جدیدی نیاز دارند، این فرصت عالی را برای تیم‌های امنیتی فراهم می‌کند تا با دنبال کردن این مراحل، روابط خود را با آنها به سطح بعدی برسانند:
ابزارهای تحقیق و ادغام های موجود در بازار، مقایسه کل هزینه مالکیت، ویژگی های اصلی و سایر مزایا و معایب برای هر یک.
قابلیت استفاده را بالاتر از هر چیز دیگری قرار دهید—مطمئن شوید که استفاده از توصیه های شما آسان است و زمان زیادی به چرخه ساخت آنها اضافه نمی کند.
3. مثال ها
توسعه دهندگان نمونه های زیادی می خواهند! شما باید به آنها نشان دهید که کد خوب چگونه به نظر می رسد، اما فراتر از تکه کدهای آینه ای، ارائه آن را در نظر بگیرید:
تست های واحد امنیتی،
کتابخانه ها،
فیلترها و الگوهای regex
باهاشون ادم کن! فراتر از اینکه به آنها اجازه دهید بر آنچه که به آنها داده اید بسازند، باید آنها را تشویق کنید تا این کار را انجام دهند. پایگاهی را برای عملیات آنها فراهم کنید و اطلاعات را فهرست بندی کنید تا توسعه دهندگان دیگر بتوانند به راحتی آن را پیدا کرده و به آن دسترسی داشته باشند.
4. خاص بودن
هنگام ارائه یک نیاز امنیتی یا رسیدگی به یک باگ یا آسیب پذیری امنیتی خاص باشید. آنها را رها نکنید که به تنهایی معنی را از لغات بیش از حد فنی جدا کنند – به بسته، کلاس، روش، خط کد و آسیب پذیری اشاره کنید. به آنها بگویید اگر آسیب‌پذیری اصلاح نشده باقی بماند، چه خطری دارد، و از به اشتراک گذاشتن داستان‌هایی درباره آنچه ممکن است اتفاق بیفتد یا در گذشته در موارد مشابه رخ داده است، نترسید تا زمینه را برای آنها فراهم کنید.
5. انجام ارزیابی های امنیتی خودشان
می‌دانم، می‌دانم – این به نظر یک تضاد منافع ضد شهودی است. اما به من گوش کنید: توسعه دهندگان می خواهند امنیت با هر کاری که انجام می دهند یکپارچه باشد، درست است؟ بنابراین امنیت داخلی برای چرخه عمر توسعه آنها ضروری است.
در اینجا چند ایده در مورد چگونگی انجام این کار وجود دارد:
برگه های تقلب امنیتی و چک لیست هایی را به توسعه دهندگان بدهید تا در اسرع وقت هر گونه آسیب پذیری را کشف کنند.
وظایف امنیتی را به صورت خودکار به داستان های فنی اضافه کنید تا به توسعه دهندگان کمک کنید آنها را به خاطر بسپارند.
اگر در دنیای آنها با آنها هستید، با همان ابزارهایی که آنها از آنها استفاده می کنند و به همان زبان صحبت می کنند، واقعاً به از بین بردن شکاف بین تیم های شما کمک می کند و درک مشترکی از آنچه دقیقاً از آنها می خواهید انجام دهند را ارتقا می دهد. .
6. اعتماد کنید
همه ما حرفه ای هستیم و توسعه دهندگان نیز مانند دیگران می خواهند مورد اعتماد باشند. آنها می دانند که چگونه وظایف خود را انجام دهند و شما می خواهید به توسعه دهندگان خود برای ایجاد امنیت در برنامه های خود اعتماد کنید. به آنها فضای لازم برای انجام این کار را بدهید!
اعتماد به مرور زمان ایجاد می شود، پس عجله نکنید. با پرسیدن سؤالات خاص از تیم های DevOps خود از وارد شدن به علف های هرز نترسید و آنها را تشویق کنید که همین کار را با تیم امنیتی انجام دهند. ایجاد آن محیط ارتباطی در دراز مدت برای همه مفید خواهد بود.
امنیت یک خدمت برای کسب و کار است – نه یک همسر آزاردهنده. اعتماد به تیم‌های DevOps برای عالی بودن در امنیت یک گام اساسی در ایجاد آن رابطه ضروری بین توسعه‌دهندگان و تیم‌های امنیتی است.
