PCI DSS 4.0 برای API به چه معناست

PCI DSS 4.0 برای امنیت API چه معنایی دارد؟ از هادار فریلینگ، مهندس راه حل اصلی در می پرسد امنیت نمک.

در مارس 2022، شورای استانداردهای امنیتی PCI (PCI SSC) چهارمین تکرار استاندارد امنیت داده PCI (PCI DSS) را صادر کرد. PCI DSS یک استاندارد جهانی است که هر نهادی که داده‌های کارت اعتباری را ارسال، ذخیره، مدیریت یا قبول می‌کند باید به آن پایبند باشد. از آنجایی که APIها به طور فزاینده ای نقش مهمی در پرداخت های آنلاین ایفا می کنند، معرفی PCI DSS 4.0 مقررات امنیتی سخت گیرانه تری را با پیامدهای گسترده ای برای امنیت API به همراه داشت.

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

6.2 – نرم افزارهای سفارشی و سفارشی به صورت ایمن توسعه یافته اند

در سال‌های اخیر، کارشناسان صنعت به طور فزاینده‌ای از توسعه نرم‌افزار امن سایبری – که در زبان محاوره‌ای به عنوان “shift left” شناخته می‌شود، حمایت کرده‌اند. الزام 6.2 بازتابی از این است. در اصل، شورا از سازمان‌ها می‌خواهد که آسیب‌پذیری‌ها را هر چه زودتر در مرحله توسعه ریشه کن کنند تا خطر به خطر افتادن را کاهش دهند. سازمان‌ها باید یک برنامه چرخه حیات نرم‌افزار امن (SLC) را برای دستیابی به این هدف پیاده‌سازی کنند و از تولید آسیب‌پذیری‌ها جلوگیری کنند.

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

زبان کنترلی فوق الزامی را برای سازمانها بیان می کند که قبل از رسیدن به مرحله توسعه، بازبینی کد – از جمله APIها را انجام دهند. در حالی که این دقیقاً یک ایده جدید نیست، بسیاری از سازمان‌ها هنوز مطمئن نمی‌شوند که فایل‌های Swagger آن‌ها استاندارد Open API (OAS) را رعایت کنند. متأسفانه، عدم اطمینان از صحت و انطباق فایل های API Swagger یک مشکل بزرگ برای توسعه دهندگان API معاصر است.

برای اطمینان از اینکه همه چیز درست است، به دنبال ابزارهای امنیتی خاص API باشید که فایل های Swagger شما را در برابر PCI DSS 4.0 ارجاع می دهند. بهترین ابزارها اختلافات بین محتویات فایل‌های Swagger و ترافیک API را مشخص می‌کنند.

6.2.4 – تکنیک‌های مهندسی نرم‌افزار یا سایر روش‌ها توسط پرسنل توسعه نرم‌افزار برای جلوگیری یا کاهش حملات نرم‌افزاری رایج و آسیب‌پذیری‌های مربوطه در نرم‌افزارهای سفارشی و سفارشی تعریف شده و مورد استفاده قرار می‌گیرند، از جمله موارد زیر:
حملات تزریقی، از جمله SQL، LDAP، XPatch، یا سایر دستورات، پارامترها، شیء، خطا، یا نقص‌های نوع تزریق.
حملات به داده ها و ساختارهای داده، از جمله تلاش برای دستکاری بافرها، اشاره گرها، داده های ورودی یا داده های مشترک.
حملات به استفاده از رمزنگاری، از جمله تلاش برای بهره‌برداری از پیاده‌سازی‌های رمزنگاری ضعیف، ناامن یا نامناسب، الگوریتم‌ها، مجموعه‌های رمز، یا حالت‌های عملکرد.
حملات به منطق تجاری، از جمله تلاش برای سوء استفاده یا دور زدن ویژگی‌ها و عملکردهای برنامه از طریق دستکاری APIها، پروتکل‌ها و کانال‌های ارتباطی، عملکرد سمت کلاینت، یا دیگر توابع و منابع سیستم/برنامه. این شامل برنامه نویسی متقابل سایت (XSS) و جعل درخواست بین سایتی (CSRF) است.
حملات به مکانیسم‌های کنترل دسترسی، از جمله تلاش برای دور زدن یا سوء استفاده از مکانیسم‌های شناسایی، احراز هویت، یا مجوز، یا تلاش برای بهره‌برداری از نقاط ضعف در اجرای چنین مکانیزم‌هایی.
حملات از طریق هر گونه آسیب پذیری “پرخطر” شناسایی شده در فرآیند شناسایی آسیب پذیری، همانطور که در الزامات 6.3.1 تعریف شده است.

قابل توجه ترین عنصر مورد نیاز 6.2.4 گنجاندن حملات منطقی تجاری است – افزودنی که مقررات قبلاً ندیده اند. این به احتمال زیاد بازتابی از تعداد فزاینده حملات منطق تجاری است – به ویژه حملاتی که شامل API ها می شوند.

طبق گزارش اخیر، APIها سریعتر از همیشه به روز می شوند – 11٪ از پاسخ دهندگان گفتند که API های خود را روزانه به روز می کنند، در حالی که 31٪ آنها را به صورت هفتگی به روز می کنند. این یک مشکل ایجاد می کند زیرا نقص های منطق تجاری API را می توان هم هنگام استقرار API ها و هم در زمان به روز رسانی آنها معرفی کرد. هرچه API های بیشتری به روز شوند، خطر نقص منطق تجاری بیشتر می شود.

همانطور که ضرب المثل قدیمی می گوید – مشکلات مدرن به راه حل های مدرن نیاز دارند. همراهی با نقص‌های منطق کسب‌وکار و در نتیجه PCI DSS 4.0 به یک راه‌حل خودکار و مداوم نیاز دارد که بتواند آسیب‌پذیری‌های منطق تجاری خاص API را کشف کند.

6.4 برنامه های کاربردی وب در معرض دید عموم در برابر حملات محافظت می شوند

برنامه‌های کاربردی که در معرض دید عموم قرار دارند، طبیعتاً در معرض خطر بیشتری نسبت به همتایان غیر عمومی خود هستند. به همین دلیل، بخش 6.4 PCI DSS برخی از کنترل‌های اضافی را برای محافظت از آنها تعیین می‌کند.

6.4.1 برای برنامه‌های کاربردی وب عمومی، تهدیدها و آسیب‌پذیری‌های جدید به‌طور مداوم بررسی می‌شوند و این برنامه‌ها در برابر حملات دانش به شرح زیر محافظت می‌شوند:
بررسی برنامه های کاربردی وب عمومی از طریق روش ها یا ابزارهای امنیتی آسیب پذیری برنامه های دستی یا خودکار به شرح زیر است:
حداقل هر 12 ماه یک بار و پس از تغییرات قابل توجه
توسط نهادی که در امنیت برنامه ها تخصص دارد
حداقل شامل تمام حملات نرم افزاری رایج در شرط 6.2.4
تمامی آسیب پذیری ها مطابق با الزام 6.3.1 رتبه بندی می شوند
تمام آسیب پذیری ها اصلاح می شوند
برنامه پس از اصلاحات مجدداً ارزیابی می شود

یا

نصب راه حل(های) فنی خودکار که به طور مستمر حملات مبتنی بر وب را شناسایی و از آنها جلوگیری می کند به شرح زیر:
برای شناسایی و جلوگیری از حملات مبتنی بر وب در مقابل برنامه های کاربردی وب عمومی نصب شده است
به طور فعال در حال اجرا و به روز در صورت لزوم
تولید آرم حسابرسی
پیکربندی شده برای مسدود کردن حملات مبتنی بر وب یا ایجاد یک هشدار که بلافاصله بررسی می شود

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

6.4.1 یک کنترل جدید است که بر برنامه های کاربردی وب در معرض دید عموم تمرکز دارد و سازمان ها را ملزم می کند از این برنامه ها در برابر تهدیدها و آسیب پذیری های جدید محافظت کنند. برای کاهش خطر حمله، PCI DSS دو گزینه را به سازمان ها ارائه می دهد: بررسی آسیب پذیری های برنامه یا پیاده سازی چیزی که این حملات را شناسایی و از آن جلوگیری کند. آنها همچنین فایروال برنامه های کاربردی وب (WAF) را به عنوان “راه حل فنی که حملات مبتنی بر وب را شناسایی و از آن جلوگیری می کند” پیشنهاد می کنند. همانطور که قبلاً ذکر شد، این تحت “راه حل فنی خودکار” قرار می گیرد.

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

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

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