-
-
Notifications
You must be signed in to change notification settings - Fork 433
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Translation of chapter 0x06 to Persian (#4)
* Update and rename 0x06-V1-Architecture_design_and_threat_modelling_requireme.md to 0x06 - translation into Persian * Rename 0x06 - translation into Persian to 0x06-V1-Architecture_design_and_threat_modelling_requireme.md Co-authored-by: MahsaOmidvar <62174900+MahsaOmidvar@users.noreply.github.com>
- Loading branch information
1 parent
1f46d9c
commit fdedfc3
Showing
1 changed file
with
34 additions
and
31 deletions.
There are no files selected for viewing
65 changes: 34 additions & 31 deletions
65
Document-fa/0x06-V1-Architecture_design_and_threat_modelling_requireme.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,38 +1,41 @@ | ||
# V1: Architecture, Design and Threat Modeling Requirements | ||
<div dir="rtl" markdown="1"> | ||
|
||
## Control Objective | ||
# V1: نیازمندیهای معماری، طراحی و مدلسازی تهدید | ||
|
||
In a perfect world, security would be considered throughout all phases of development. In reality however, security is often only a consideration at a late stage in the SDLC. Besides the technical controls, the MASVS requires processes to be in place that ensure that the security has been explicitly addressed when planning the architecture of the mobile app, and that the functional and security roles of all components are known. Since most mobile applications act as clients to remote services, it must be ensured that appropriate security standards are also applied to those services - testing the mobile app in isolation is not sufficient. | ||
## هدف کنترل | ||
|
||
The category “V1” lists requirements pertaining to architecture and design of the app. As such, this is the only category that does not map to technical test cases in the OWASP Mobile Testing Guide. To cover topics such as threat modelling, secure SDLC or key management, users of the MASVS should consult the respective OWASP projects and/or other standards such as the ones linked below. | ||
در دنیای بینقص، امنیت در تمام مراحل توسعه برنامه باید در نظر گرفته شود. اما در واقعیت، امنیت اغلب در مرحلۀ آخر چرخۀ حیات توسعۀ نرمافزار موردتوجه قرار میگیرد. علاوه بر کنترلهای فنی، استاندارد وارسی امنیت برنامۀ کاربردی موبایل، نیاز به ایجاد فرایندهایی دارد که بتوان از موردتوجه بودن امنیت در زمان برنامهریزی معماری برنامۀ موبایل و شناخت وظیفهمندیهای اصلی و امنیتی مؤلفهها اطمینان حاصل نمود. ازآنجاییکه بسیاری از برنامههای موبایل بهعنوان سرویسدهنده از راه دور عمل میکنند، باید از اعمال استانداردهای امنیتی مناسب برای آن سرویسها اطمینان حاصل نمود - تست برنامه موبایل در محیط ایزوله کافی نیست. | ||
|
||
## Security Verification Requirements | ||
دستهبندی "V1"، نیازمندیهای مرتبط با فاز معماری و طراحی برنامۀ کاربردی موبایل را فهرست مینماید. بهاینترتیب، این تنها دستهبندیای است که به موارد آزمون فنی در راهنمای آزمودن برنامۀ کاربردی موبایل OWASP نگاشت نمیشود. برای پوشش موضوعاتی مانند مدلسازی تهدید، چرخه حیات توسعه امن نرمافزار، مدیریت کلید، خوانندگان MASVS باید به پروژههای مرتبط با OWASP و یا سایر استانداردهای ارائهشده در زیر مراجعه نمایند. | ||
|
||
The requirements for MASVS-L1 and MASVS-L2 are listed below. | ||
## نیازمندیهای وارسی امنیت | ||
|
||
| # | MSTG-ID | Description | L1 | L2 | | ||
نیازمندیهای سطح یک و دو استاندارد وارسی امنیت برنامههای کاربردی موبایل بصورت زیر فهرست شده اند. | ||
|
||
| # | شناسه-آزمون امنیتی برنامۀ کاربردی موبایل | شرح | سطح یک | سطح دو | | ||
| -- | -------- | ---------------------- | - | - | | ||
| **1.1** | MSTG-ARCH-1 | All app components are identified and known to be needed. | ✓ | ✓ | | ||
| **1.2** | MSTG-ARCH-2 | Security controls are never enforced only on the client side, but on the respective remote endpoints. | ✓ | ✓ | | ||
| **1.3** | MSTG-ARCH-3 | A high-level architecture for the mobile app and all connected remote services has been defined and security has been addressed in that architecture. | ✓ | ✓ | | ||
| **1.4** | MSTG-ARCH-4 | Data considered sensitive in the context of the mobile app is clearly identified. | ✓ | ✓ | | ||
| **1.5** | MSTG-ARCH-5 | All app components are defined in terms of the business functions and/or security functions they provide. | | ✓ | | ||
| **1.6** | MSTG-ARCH-6 | A threat model for the mobile app and the associated remote services has been produced that identifies potential threats and countermeasures. | | ✓ | | ||
| **1.7** | MSTG-ARCH-7 | All security controls have a centralized implementation. | | ✓ | | ||
| **1.8** | MSTG-ARCH-8 | There is an explicit policy for how cryptographic keys (if any) are managed, and the lifecycle of cryptographic keys is enforced. Ideally, follow a key management standard such as NIST SP 800-57. | | ✓ | | ||
| **1.9** | MSTG-ARCH-9 | A mechanism for enforcing updates of the mobile app exists. | | ✓ | | ||
| **1.10** | MSTG-ARCH-10 | Security is addressed within all parts of the software development lifecycle. | | ✓ | | ||
| **1.11** | MSTG-ARCH-11 | A responsible disclosure policy is in place and effectively applied. | | ✓ | | ||
| **1.12** | MSTG-ARCH-12 | The app should comply with privacy laws and regulations. | ✓ | ✓ | | ||
|
||
## References | ||
|
||
For more information, see also: | ||
|
||
- OWASP Mobile Top 10: M10 (Extraneous Functionality) - <https://owasp.org/www-project-mobile-top-10/2016-risks/m10-extraneous-functionality> | ||
- OWASP Security Architecture cheat sheet - <https://www.owasp.org/index.php/Application_Security_Architecture_Cheat_Sheet> | ||
- OWASP Threat modelling - <https://www.owasp.org/index.php/Application_Threat_Modeling> | ||
- OWASP Secure SDLC Cheat Sheet - <https://www.owasp.org/index.php/Secure_SDLC_Cheat_Sheet> | ||
- Microsoft SDL - <https://www.microsoft.com/en-us/sdl/> | ||
- NIST SP 800-57 - <http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf> | ||
- security.txt - <https://securitytxt.org/> | ||
| **1.1** | آزمون امنیت برنامۀ کاربردی موبایل-فاز معماری-1 | تمامی مؤلفههای برنامۀ کاربردی موردنیاز شناسایی و شناختهشدهاند. | ✓ | ✓ | | ||
| **1.2** | آزمون امنیت برنامۀ کاربردی موبایل-فاز معماری-2 | اعمال کنترلهای امنیتی نه فقط در سمت مشتری بلکه در نقاط انتهایی از راه دور مرتبط نیز صورت میگیرد. | ✓ | ✓ | | ||
| **1.3** | آزمون امنیت برنامۀ کاربردی موبایل-فاز معماری-3 | یک معماری سطح بالا در برنامۀ کاربردی موبایل و تمامی سرویسهای متصل به آن تعریف شده است و امنیت در آن معماری در نظر گرفته شده است. | ✓ | ✓ | | ||
| **1.4** | آزمون امنیت برنامۀ کاربردی موبایل-فاز معماری-4 | دادههای حساس در برنامۀ کاربردی موبایل، بهصراحت مشخص شدهاند. | ✓ | ✓ | | ||
| **1.5** | آزمون امنیت برنامۀ کاربردی موبایل-فاز معماری-5 | تمامی مؤلفههای برنامۀ کاربردی موبایل بر اساس عملکرد امنیتی و یا تجاری که ارائه میکنند، مشخص شدهاند. | | ✓ | | ||
| **1.6** | آزمون امنیت برنامۀ کاربردی موبایل-فاز معماری-6 | مدلسازی تهدیدی که برای برنامۀ کاربردی موبایل و تمامی سرویسهای مرتبط از راه دور ایجاد شده است، تهدیدات بالقوه و اقدامات متقابل را شناسایی مینماید. | | ✓ | | ||
| **1.7** | آزمون امنیت برنامۀ کاربردی موبایل-فاز معماری-7 | تمامی کنترلهای امنیتی بهصورت متمرکز پیادهسازی شدهاند. | | ✓ | | ||
| **1.8** | آزمون امنیت برنامۀ کاربردی موبایل-فاز معماری-8 | یک خطمشی صریح برای نحوه مدیریت کلیدهای رمزنگاری (در صورت وجود) و چرخه عمر کلیدهای رمزنگاری اعمال میشود. در حالت ایده آل، از یک استاندارد مدیریت کلید همانند NIST SP 800-57 پیروی نمایید. | | ✓ | | ||
| **1.9** | آزمون امنیت برنامۀ کاربردی موبایل-فاز معماری-9 | یک سازوکار برای اجرای بروز رسانی برنامۀ کاربردی موبایل وجود دارد. | | ✓ | | ||
| **1.10** | آزمون امنیت برنامۀ کاربردی موبایل-فاز معماری-10 | امنیت در تمامی مراحل چرخۀ حیات توسعۀ نرمافزار در نظر گرفته شده است. | | ✓ | | ||
| **1.11** | آزمون امنیت برنامۀ کاربردی موبایل-فاز معماری-11 | یک سیاست افشای مسئولیتپذیرانهٔ (آسیبپذیری) در حال اجرا است و بهطور مؤثری اعمال میشود. | | ✓ | | ||
| **1.12** | آزمون امنیت برنامۀ کاربردی موبایل-فاز معماری-12 | برنامۀ کاربردی موبایل باید با قوانین و مقررات حفظ حریم خصوصی مطابقت داشته باشد. | ✓ | ✓ | | ||
|
||
## مراجع | ||
|
||
برای دریافت اطلاعات بیشتر به آدرسهای زیر مراجعه نمایید: | ||
|
||
- ده تهدید برتر موبایل OWASP - تهدید رتبه دهم (وظیفهمندی فرعی) - <https://owasp.org/www-project-mobile-top-10/2016-risks/m10-extraneous-functionality> | ||
- OWASP راهنمای معماری امن - <https://www.owasp.org/index.php/Application_Security_Architecture_Cheat_Sheet> | ||
- OWASP مدلسازی تهدید - <https://www.owasp.org/index.php/Application_Threat_Modeling> | ||
- OWASP راهنمای چرخۀ حیات توسعۀ امن نرمافزار - <https://www.owasp.org/index.php/Secure_SDLC_Cheat_Sheet> | ||
- راهنمای چرخۀ حیات توسعۀ نرمافزار مایکروسافت - <https://www.microsoft.com/en-us/sdl/> | ||
- NIST SP 800-57 استاندارد- <http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf> | ||
- security.txt - <https://securitytxt.org> | ||
</div> |