این وبلاگ توسط محمد اقبال تألیف شده است و بخشی از یک مجموعه چهار بخشی درباره DevSecOps است .
گرایش به سمت توسعه سریع برنامه و به روزرسانی منظم یک معماری از طریق یک روش چابک ، اثربخشی و اثربخشی مدل تهدید نقطه به زمان را کاهش می دهد. این شناخت ما را بر آن داشت تا روشهای مداوم و پویا تهدید مدل معماری برنامه در زمان اجرا را کشف و استراتژی کنیم.
امروزه ، به لطف یک محیط قوی DevOps ، توسعه دهندگان می توانند بدون نیاز به پشتیبانی از یک مدیر شبکه یا پایگاه داده ، یک ساختار پیچیده را در یک ابر عمومی مانند خدمات وب آمازون (AWS) یا Google Cloud Platform استقرار دهند. یک توسعه دهنده می تواند کد را توسعه دهد ، یک زیرساخت را از طریق کد در یک ابر عمومی مستقر کند ، گروه های امنیتی را از طریق کد ایجاد کند و از طریق خط لوله ادغام مداوم / تحویل مداوم (CI / CD) برنامه ای را در محیط حاصل از آن مستقر کند . در حالی که این سرعت استقرار را امکان پذیر می کند ، همچنین چندین کنترل و تعادل را از بین می برد. در سیسکو ، خطرات ناشی از چنین روش هایی را شناختیم و تصمیم گرفتیم استراتژی هایی را بررسی کنیم تا به طور مداوم ارزیابی کنیم که چگونه یک معماری در زمان تولید برای جلوگیری از رانش معماری تکامل می یابد.
مدل سازی تهدید پویا باید با یک مدل تهدید اساسی پایه شروع شود که در زمان واقعی انجام می شود. این می تواند به نوبه خود برای رانش معماری کنترل شود. روش ما برای دستیابی به چنین دیدگاهی در زمان واقعی استفاده از تکنیک های پویا است که به تیم های امنیتی اجازه می دهد به جای دیاگرام فقط روی کاغذ یا تخته های سفید ، محیط های زنده مدل را تهدید کنند.
مدل سازی تهدید پویا چگونه کار می کند؟
مدل سازی تهدید عملی است برای شناسایی جریان داده ها از طریق سیستم ها و سازه های مختلف درون معماری که شکاف امنیتی یا آسیب پذیری را نشان می دهد. یک عنصر مهم که امکان مدل سازی تهدید را فراهم می کند ، تولید نوع نمایشی صحیح از یک معماری معین به روشی دقیق است. این روش می تواند بر اساس زمینه و از یک تیم به تیم دیگر متفاوت باشد. در سیسکو ، ما در عوض بر روی عناصر و ویژگی هایی تمرکز کردیم که باید وجود داشته باشد تا به یک تیم امکان انجام پویایی یک تمرین مدل سازی تهدید را بدهد. این عناصر شامل توانایی:
- برای تبدیل نمای عملیاتی از یک معماری به یک مدل تهدید
- برای زمینه سازی یک نیاز
- برای نظارت بر معماری برای رانش بر اساس یک نیاز
از نمای عملیاتی تا مدل تهدید
ابزارهای زیادی وجود دارد که می تواند نمای عملیاتی از یک معماری را ارائه دهد. با این حال ، یک دید عملیاتی از یک معماری همان مدل تهدید نیست. در عوض ، یک نمای عملیاتی باید متحول شود تا یک مدل تهدید از یک معماری ایجاد کند. برای این اتفاق ، حداقل باید راه حل راهی برای فیلتر کردن و گروه بندی نمایش داده ها در یک معماری فراهم کند تا فقط داده های مربوطه بصری ارائه شوند.
به عنوان مثال ، موردی را در نظر بگیرید که یک پیشنهاد عمومی ابر میزبان AWS از دو نوع سطل S3 تشکیل شده است (شکل 1). یک نوع سطل S3 برای دسترسی مستقیم مشتریان به آنها در نظر گرفته شده است. هر مشتری سطل S3 منحصر به فرد خود را برای دسترسی پیدا می کند. انواع دیگر سطل های S3 برای اهداف اداری داخلی خاص سازمان مستقر می شوند. هر دو نوع سطل S3 از طریق برچسب های AWS (به ترتیب “مشتری” و “مدیر”) شناسایی می شوند. یک پرسش مبتنی بر فیلتر که برای معماری از این نوع اعمال می شود ، می تواند به س questionsالاتی از قبیل “آیا در این معماری سطل S3 با برچسب:” مشتری “یا” مدیر “وجود دارد ، پاسخ دهد؟
شکل 1. نماهای عملیاتی با و بدون فیلتر یا گروه بندی اعمال شده
اگرچه گروه بندی مانند فیلتر کردن است ، اما تفاوت آن به این دلیل است که به یک مدیر اجازه می دهد تا معماری را با این سال جستجو کند: “آیا سطلهای S3 با برچسب مشتری یا مدیر در این معماری وجود دارد؟ در این صورت ، این دارایی ها را بر اساس برچسب های آنها گروه بندی کنید و منطقاً آنها را بر اساس برچسب هایشان نشان دهید »(شکل 2).
شکل 2. نمای عملیاتی با گروه بندی اعمال شده توسط برچسب های مدیر یا مشتری
متن سازی یک الزام به چه معناست؟
با استفاده از مدل تهدید پویا ، متناسب سازی یک نیاز به تیم اجازه می دهد تا یک طرح اصلاح متنی برای یک منطقه خاص از معماری را تجویز کند تا بتواند از نظر رانش معماری کنترل شود. این رویداد گام بعدی در جهت ایمن سازی معماری از تهدیدهای خاص در سطح دانه دارتر است پس از استفاده از محافظ های امنیتی خط پایه مناسب برای یک محیط.
برای ایجاد مثالی از بالا ، بهترین روشهای استاندارد صنعت در جهت ایمن سازی سطل S3 ، پیکربندی سطلهای S3 را غیرعمومی توصیف می کند. همانطور که در بالا ذکر شد ، اولین نوع سطل S3 برای دسترسی به مشتریان (برای خواندن یا نوشتن) به آنها ارائه می شود. علاوه بر این ، هر مشتری سطل S3 منحصر به فرد خود را دریافت می کند. نوع دوم سطل S3 توسط اهداف اداری داخلی سازمان مورد استفاده قرار می گیرد. هنگامی که حفاظ های استاندارد نسبت به دو نوع سطل S3 اجرا شد ، مرحله بعدی تعیین نوع مجوز دسترسی است که باید برای دو نوع سطل S3 براساس اهداف آنها اعمال شود (شکل 3).
شکل 3:
توانایی نظارت بر معماری برای رانش بر اساس شرایط
همانطور که قبلا ذکر شد ، هدف از مدل سازی تهدید پویا نظارت بر معماری است که تهدید در زمان واقعی برای رانش معماری مدل شده است. این نباید با توانایی نظارت بر یک شبکه برای آسیب پذیری اشتباه گرفته شود. برای نظارت بر آسیب پذیری ها ، در حال حاضر ابزارهای بی شماری در صنعت وجود دارد که به یک تیم DevSecOps کمک می کند تا زمینه های خطرات را تعیین کند. برای نظارت بر رانش معماری ، یک راه حل باید بتواند توالی رویدادها را با هم گره بزند تا تعیین کند که آیا زمینه مناسب برای حوادث به عنوان رانش در نظر گرفته شده است. برای ادامه مثال ما از شکل 3 ، شکل 4 زیر مناطقی را در معماری S3 مشخص می کند که باید پس از اعمال نیازهای متنی برای راندگی معماری کنترل شوند.
شکل 4. مانیتورینگ اعمال شده بر روی سطل های مشتری و سرپرست بر اساس الزامات
چالش ها و آنچه در آینده وجود دارد
با فعال کردن مدل تهدید پویا ، DevSecOps می تواند به طور مداوم یک محیط را در زمان واقعی برای هرگونه رانش معماری رصد کند. با این حال ، DevSecOps باید چالش های زیر را برطرف کند:
- برای تبدیل دید عملیاتی به مدل تهدید ، از تکنیک های تبدیل بهتر استفاده کنید
- راهبردهای بهتری را برای تدوین الزامات متنی مبتنی بر انسان در قوانین واقعی تدوین کنید
- یک استراتژی امنیتی پایه را دنبال کنید که می تواند براساس معماری های مختلف ارزیابی شود
امنیت سفری است که مستلزم تأثیرگذاری و توانایی در تیم ها برای اتخاذ و استفاده از بهترین شیوه ها و کنترل ها برای معماری خود است. با ادامه ارتقا این استراتژی و پرداختن به چالش های ذکر شده در بالا ، ما تصویب گسترده و پذیرش مدل تهدید مداوم و پویا از محیط های زنده را برای نظارت بر هرگونه رانش معماری و کاهش فعالانه خطرات در دنیای سریع DevSecOps پیش بینی می کنیم.
ما امیدواریم که این مجموعه به شما کمک کرده باشد تا بتوانید به سرعت امنیت را برای قابلیت توسعه دهنده ادغام کنید و خطرات تجاری خود را مدیریت کنید. شکل 5 نشان می دهد آنچه که ما در Cisco موفق شده ایم تا تلاش کنیم امنیت و اعتماد مشتریان خود را افزایش دهیم.
شکل 5. اتوماسیون امنیتی سیسکو برای ویژگی های DevSecOps
This blog is co-authored by Mohammad Iqbal and is part four of a four-part series about DevSecOps.
The trend towards accelerated application development, and regular updates to an architecture through an agile methodology, reduces the efficacy and effectiveness of point-in-time threat modeling. This recognition led us to explore and strategize ways to continuously, and dynamically, threat model an application architecture during runtime.
Today, thanks to a robust DevOps environment, developers can deploy a complex architecture within a public cloud such as Amazon Web Services (AWS) or Google Cloud Platform without requiring support from a network or database administrator. A single developer can develop code, deploy an infrastructure through code into a public cloud, construct security groups through code, and deploy an application on the resulting environment all through a continuous integration/continuous delivery (CI/CD) pipeline. While this enables deployment velocity, it also eliminates multiple checks and balances. At Cisco, we recognized the risks introduced by such practices and decided to explore strategies to continuously evaluate how an architecture evolves in production runtime to guard against architecture drift.
Dynamic threat modeling must begin with a solid baseline threat model that is done in real-time. This can in turn be monitored for architecture drift. Our approach to obtain such a real-time view is to use dynamic techniques to allow security and ops teams to threat model live environments instead of diagraming on paper or whiteboards alone.
How Does Dynamic Threat Modeling Work?
Threat modeling is the practice of identifying data flows through systems and various constructs within an architecture that exhibit a security gap or vulnerabilities. A crucial element that enables the practice of threat modeling is generating the right kind of visual representation of a given architecture in an accurate manner. This approach can differ based on context and from one team to another. At Cisco, we instead focused on elements and features that need to exist to allow a team to dynamically perform a threat modeling exercise. These elements include the ability:
- To transform an operational view of an architecture to a threat model
- To contextualize a requirement
- To monitor the architecture for drift based on a requirement
From Operational View to Threat Model
Numerous tools exist that can render an operational view of an architecture. However, an operational view of an architecture is not the same as a threat model. Instead, an operational view must undergo a transformation to create a threat model view of an architecture. For this to occur, the solution should at a minimum provide a way to filter and group queries within an architecture so that only relevant data is visually rendered.
As an example, consider a case where an AWS hosted public cloud offer consists of two types of S3 buckets (Figure 1). One type of S3 buckets is deployed for customers for them to access directly. Each customer gets their own unique S3 bucket to access. Other types of S3 buckets are deployed for organization-specific internal administrative purposes. Both types of S3 buckets are identified through their AWS tags (“Customer” and “Admin” respectively). A filter-based query applied to an architecture of this type can answer questions such as “Are there S3 buckets with Tag: ‘Customer’ or ‘Admin’ in this architecture?”
Figure 1. Operational Views with and Without Filtering or Grouping Applied
Even though grouping is like filtering, it differs because it allows an administrator to query an architecture with the question: “Are there S3 buckets with the Customer or Admin tag in this architecture? If so, group these assets by their tags and logically represent them by their tags” (Figure 2).
Figure 2. Operational View with Grouping Applied by Admin or Customer Tags
What Does it Mean to Contextualize a Requirement?
With dynamic threat modeling, contextualizing a requirement allows a team to prescribe a contextualized remediation plan for a specific area of the architecture so that it can be monitored for architecture drift. This event is the next step towards securing an architecture from specific threats at a more granular level once the appropriate base line security guardrails have been applied towards an environment.
To build on the example from above, industry standard best practices towards securing a S3 bucket prescribes configuring S3 buckets as non-public. As mentioned above, the first type of S3 bucket is offered to customers for them to access (for read or write). Furthermore, each customer gets their own unique S3 bucket. The second type of S3 bucket is used by the organization’s internal administrative purposes. Once the standard guardrails have been implemented towards the two types of S3 buckets, the next step is to determine the type of access authorization that should be applied towards the two types of S3 buckets based on the purposes they serve (Figure 3).
Figure 3:
Ability to Monitor the Architecture for Drift Based on Requirements
As previously mentioned, the goal of dynamic threat modeling is to monitor the architecture that has been threat modeled in real-time for architecture drift. This should not be confused with the ability to monitor a network for vulnerabilities. To monitor for vulnerabilities, there are already numerous tools within the industry to help a DevSecOps team determine areas of risks. To monitor for architecture drift, a solution must be able to tie together a sequence of events to determine if the appropriate context exists for the events to be considered as drift. To continue our example from Figure 3, Figure 4 below outlines the areas within the S3 architecture that should be monitored for architecture drift once the contextualized requirement has been applied.
Figure 4. Monitoring Applied to Customer and Admin Buckets Grouped Based on Requirements
Challenges and What the Future Holds
By enabling dynamic threat modeling, DevSecOps can continuously monitor an environment in real-time for any architecture drift. However, the following challenges must be addressed by DevSecOps:
- Apply better conversion techniques to transform an operational view to a threat model
- Develop better strategies to codify human-based contextual requirements into actual rules
- Drive a consistent baseline security strategy that can be evaluated based on various architectures
Security is a journey that requires influencing and enabling teams to adopt and employ best practices and controls for their architectures. By continuing to enhance this strategy and addressing the challenges mentioned above, we anticipate wide adoption and acceptance of continuous and dynamic threat modeling of live environments to monitor for any architecture drift and proactively mitigate the risks in the fast-paced world of DevSecOps.
We hope this series has helped you in your journey to swiftly integrate security for developer enablement and to manage your business risks. Figure 5 illustrates what we’ve accomplished at Cisco as we strive to raise the bar on security and the trust of our customers.
Figure 5. Cisco Security Automation for DevSecOps Features
