From 18c713ad648256fc2448b52304e2615e821d1f8c Mon Sep 17 00:00:00 2001 From: Jon Gadsden Date: Mon, 12 Jan 2026 09:28:57 +0000 Subject: [PATCH] rearrange files for section design/threat-modeling --- .github/pull_request_template.md | 6 +- ...olkit.md => 01-threat-modeling-project.md} | 4 +- .../01-threat-modeling/05-linddun-go.md | 9 +- .../06-threat-model-library.md | 16 ++ ...ing.md => 07-practical-threat-modeling.md} | 6 +- .../01-threat-modeling/04-cornucopia.md | 4 +- .../01-threat-modeling/05-linddun-go.md | 4 +- .../01-threat-modeling/06-toolkit.md | 4 +- .../01-security-fundamentals.md | 177 ------------ .../02-foundations/02-secure-development.md | 215 --------------- .../02-foundations/03-security-principles.md | 198 -------------- .../hi/02-foundations/04-crypto-principles.md | 252 ------------------ docs/hi/02-foundations/05-top-ten.md | 208 --------------- docs/hi/02-foundations/index.md | 26 -- docs/index.md | 25 +- mkdocs-pdf-en.yaml | 5 +- mkdocs-pdf-es.yaml | 9 +- mkdocs-pdf-fa.yaml | 5 +- mkdocs-pdf-pt-br.yaml | 5 +- mkdocs.yaml | 7 +- 20 files changed, 69 insertions(+), 1116 deletions(-) rename docs/en/04-design/01-threat-modeling/{06-toolkit.md => 01-threat-modeling-project.md} (96%) create mode 100644 docs/en/04-design/01-threat-modeling/06-threat-model-library.md rename docs/en/04-design/01-threat-modeling/{01-threat-modeling.md => 07-practical-threat-modeling.md} (98%) delete mode 100644 docs/hi/02-foundations/01-security-fundamentals.md delete mode 100644 docs/hi/02-foundations/02-secure-development.md delete mode 100644 docs/hi/02-foundations/03-security-principles.md delete mode 100644 docs/hi/02-foundations/04-crypto-principles.md delete mode 100644 docs/hi/02-foundations/05-top-ten.md delete mode 100644 docs/hi/02-foundations/index.md diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index ff1fdee7..232603d6 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -19,7 +19,11 @@ Thanks for submitting a pull request, please make sure: - [ ] content meets the [license](../blob/main/license.txt) for this project - [ ] you have read the [contribution guide](../blob/main/contributing.md) and agree to the [Code of Conduct](../blob/main/code_of_conduct.md) -- [ ] any [use of AI](../blob/main/contributing.md#use-of-ai) has been declared in this pull request +- [ ] *either* no AI-generated content has been used in this pull request +- [ ] *or* any [use of AI](../blob/main/contributing.md#use-of-ai) in this pull request has been disclosed below: + - AI Tools: `[e.g. GitHub CoPilot, ChatGPT, JetBrains Junie, etc]` + - LLMs and versions: `[e.g. GPT-4.1, Claude Haiku 4.5, Gemini 2.5 Pro, etc]` + - Prompts: `[Summarize the key prompts or instructions given to the AI tools]` **Other info** : diff --git a/docs/en/04-design/01-threat-modeling/06-toolkit.md b/docs/en/04-design/01-threat-modeling/01-threat-modeling-project.md similarity index 96% rename from docs/en/04-design/01-threat-modeling/06-toolkit.md rename to docs/en/04-design/01-threat-modeling/01-threat-modeling-project.md index 88a8cd16..c22cf09a 100644 --- a/docs/en/04-design/01-threat-modeling/06-toolkit.md +++ b/docs/en/04-design/01-threat-modeling/01-threat-modeling-project.md @@ -48,8 +48,8 @@ then [submit an issue][issue060106] or [edit on GitHub][edit060106]. [4QFW]: https://github.com/adamshostack/4QuestionFrame [asacs]: https://cheatsheetseries.owasp.org/cheatsheets/Attack_Surface_Analysis_Cheat_Sheet [cstm]: https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet -[issue060106]: https://github.com/OWASP/DevGuide/issues/new?labels=content&template=request.md&title=Update:%2004-design/01-threat-modeling/06-toolkit -[edit060106]: https://github.com/OWASP/DevGuide/blob/main/docs/en/04-design/01-threat-modeling/06-toolkit.md +[edit060106]: https://github.com/OWASP/DevGuide/blob/main/docs/en/04-design/01-threat-modeling/01-threat-modeling-project.md +[issue060106]: https://github.com/OWASP/DevGuide/issues/new?labels=content&template=request.md&title=Update:%2004-design/01-threat-modeling/01-threat-modeling-project [toolkit]: https://www.youtube.com/watch?v=KGy_KCRUGd4 [tmpb]: https://owasp.org/www-project-threat-modeling-playbook/ [tmproject]: https://owasp.org/www-project-threat-modeling/ diff --git a/docs/en/04-design/01-threat-modeling/05-linddun-go.md b/docs/en/04-design/01-threat-modeling/05-linddun-go.md index c4f16544..301048ca 100644 --- a/docs/en/04-design/01-threat-modeling/05-linddun-go.md +++ b/docs/en/04-design/01-threat-modeling/05-linddun-go.md @@ -1,5 +1,4 @@ LINNDUN GO is a card game used to help derive privacy requirements during the software development life cycle. -The LINNDUN GO card set can be [downloaded][linddun-go-cards] as a PDF and then printed out. #### What is LINDDUN GO? @@ -44,7 +43,7 @@ The advice from the LINDDUN GO 'getting started' instructions is that this team The application should have already been described by an architecture diagram or data flow diagram so that the players have something to refer to during the game. -[Download][linddun-go-cards] and printout the deck of cards. +The LINNDUN GO card set can be [downloaded][linddun-go-cards] as a PDF and the deck of cards printed out. Follow the [set of rules][linddun-go-rules] to structure the game session, record the outcome and act on it. The outcome of the game is to identify possible privacy threats and propose remediations; @@ -53,11 +52,11 @@ as well as having a good time of course. ---- The OWASP Developer Guide is a community effort; if there is something that needs changing -then [submit an issue][issue060105] or [edit on GitHub][edit060105]. +then [submit an issue][issue040105] or [edit on GitHub][edit040105]. [cornucopia]: https://owasp.org/www-project-cornucopia/ -[edit060105]: https://github.com/OWASP/DevGuide/blob/main/docs/en/04-design/01-threat-modeling/05-linddun-go.md -[issue060105]: https://github.com/OWASP/DevGuide/issues/new?labels=content&template=request.md&title=Update:%2004-design/01-threat-modeling/05-linddun-go +[edit040105]: https://github.com/OWASP/DevGuide/blob/main/docs/en/04-design/01-threat-modeling/05-linddun-go.md +[issue040105]: https://github.com/OWASP/DevGuide/issues/new?labels=content&template=request.md&title=Update:%2004-design/01-threat-modeling/05-linddun-go [linddun]: https://linddun.org/ [linddun-go]: https://linddun.org/go/ [linddun-go-cards]: https://downloads.linddun.org/linddun-go/default/latest/go.pdf diff --git a/docs/en/04-design/01-threat-modeling/06-threat-model-library.md b/docs/en/04-design/01-threat-modeling/06-threat-model-library.md new file mode 100644 index 00000000..336ed635 --- /dev/null +++ b/docs/en/04-design/01-threat-modeling/06-threat-model-library.md @@ -0,0 +1,16 @@ +The Threat Model Library is a collection of threat models which provide examples of best practice, +and have been donated to the public domain. + +#### What is the Threat Model Library? + +#### Why use these models? + +#### How to view the models + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue040106] or [edit on GitHub][edit040106]. + +[edit040106]: https://github.com/OWASP/DevGuide/blob/main/docs/en/04-design/01-threat-modeling/06-threat-model-library.md +[issue040106]: https://github.com/OWASP/DevGuide/issues/new?labels=content&template=request.md&title=Update:%2004-design/01-threat-modeling/06-threat-model-library diff --git a/docs/en/04-design/01-threat-modeling/01-threat-modeling.md b/docs/en/04-design/01-threat-modeling/07-practical-threat-modeling.md similarity index 98% rename from docs/en/04-design/01-threat-modeling/01-threat-modeling.md rename to docs/en/04-design/01-threat-modeling/07-practical-threat-modeling.md index a69eab81..146f5a60 100644 --- a/docs/en/04-design/01-threat-modeling/01-threat-modeling.md +++ b/docs/en/04-design/01-threat-modeling/07-practical-threat-modeling.md @@ -244,7 +244,7 @@ then that is also a perfectly good choice. ---- The OWASP Developer Guide is a community effort; if there is something that needs changing -then [submit an issue][issue060101] or [edit on GitHub][edit060101]. +then [submit an issue][issue040107] or [edit on GitHub][edit040107]. [4QFW]: https://github.com/adamshostack/4QuestionFrame [asacs]: https://cheatsheetseries.owasp.org/cheatsheets/Attack_Surface_Analysis_Cheat_Sheet @@ -255,8 +255,8 @@ then [submit an issue][issue060101] or [edit on GitHub][edit060101]. [cstm]: https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet [culturetm]: https://owasp.org/www-project-security-culture/stable/6-Threat_Modelling/ [eop]: https://shostack.org/games/elevation-of-privilege -[edit060101]: https://github.com/OWASP/DevGuide/blob/main/docs/en/04-design/01-threat-modeling/01-threat-modeling.md -[issue060101]: https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%2004-design/01-threat-modeling/01-threat-modeling +[edit040107]: https://github.com/OWASP/DevGuide/blob/main/docs/en/04-design/01-threat-modeling/07-practical-threat-modeling.md +[issue040107]: https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%2004-design/01-threat-modeling/07-practical-threat-modeling [linddun]: https://linddun.org/ [nist-cvss]: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator [pasta]: https://versprite.com/blog/what-is-pasta-threat-modeling/ diff --git a/docs/es/04-design/01-threat-modeling/04-cornucopia.md b/docs/es/04-design/01-threat-modeling/04-cornucopia.md index d57214b1..d023c517 100644 --- a/docs/es/04-design/01-threat-modeling/04-cornucopia.md +++ b/docs/es/04-design/01-threat-modeling/04-cornucopia.md @@ -1,7 +1,7 @@ ![WIP logo](../../../assets/images/dg_wip.png "Trabajo en curso"){ align=right width=180 } -No hay traducción de esta página, consulte [versión original en inglés][en060104]. +No hay traducción de esta página, consulte [versión original en inglés][en040104]. ---- -[en060104]: https://devguide.owasp.org/en/04-design/01-threat-modeling/04-cornucopia/ +[en040104]: https://devguide.owasp.org/en/04-design/01-threat-modeling/04-cornucopia/ diff --git a/docs/es/04-design/01-threat-modeling/05-linddun-go.md b/docs/es/04-design/01-threat-modeling/05-linddun-go.md index b6b41128..5159cad6 100644 --- a/docs/es/04-design/01-threat-modeling/05-linddun-go.md +++ b/docs/es/04-design/01-threat-modeling/05-linddun-go.md @@ -1,7 +1,7 @@ ![WIP logo](../../../assets/images/dg_wip.png "Trabajo en curso"){ align=right width=180 } -No hay traducción de esta página, consulte [versión original en inglés][en060105]. +No hay traducción de esta página, consulte [versión original en inglés][en040105]. ---- -[en060105]: https://devguide.owasp.org/en/04-design/01-threat-modeling/05-linddun-go/ +[en040105]: https://devguide.owasp.org/en/04-design/01-threat-modeling/05-linddun-go/ diff --git a/docs/es/04-design/01-threat-modeling/06-toolkit.md b/docs/es/04-design/01-threat-modeling/06-toolkit.md index 456bf4a7..f2fd1a13 100644 --- a/docs/es/04-design/01-threat-modeling/06-toolkit.md +++ b/docs/es/04-design/01-threat-modeling/06-toolkit.md @@ -1,7 +1,7 @@ ![WIP logo](../../../assets/images/dg_wip.png "Trabajo en curso"){ align=right width=180 } -No hay traducción de esta página, consulte [versión original en inglés][release060106]. +No hay traducción de esta página, consulte [versión original en inglés][release040106]. ---- -[release060106]: hhttps://devguide.owasp.org/04-design/01-threat-modeling/06-toolkit/ +[release040106]: https://devguide.owasp.org/en/04-design/01-threat-modeling/06-toolkit/ diff --git a/docs/hi/02-foundations/01-security-fundamentals.md b/docs/hi/02-foundations/01-security-fundamentals.md deleted file mode 100644 index f5f828c1..00000000 --- a/docs/hi/02-foundations/01-security-fundamentals.md +++ /dev/null @@ -1,177 +0,0 @@ -The fundamental principles of application security rely on the security concepts referenced in this developer guide. -This section aims to provide an introduction to fundamental principles that any development team must be familiar with. - -#### Software Assurance Maturity Model - -![SAMM logo](../../assets/images/logos/samm.png "OWASP SAMM"){ align=right width=250 } - -The Software Assurance Maturity Model ([SAMM][samm]) provides context for the scope of software security -and the foundations of good security practice: - -* [Governance][sammg] -* [Design][sammd] -* [Implementation][sammi] -* [Verification][sammv] -* [Operations][sammo] - -The SAMM model describes these foundations of software security as Business Functions, -which are further divided into Business Practices. -The OWASP Software Assurance Maturity Model ([SAMM][samm]) is used throughout this Developer Guide; -most of the sections in the Developer Guide reference at least one of the Business Functions or Practices from SAMM. - -#### CIA triad - -Security is simply about controlling who can interact with your information, -what they can do with it, and when they can interact with it. -These characteristics of security can be described using the CIA triad. - -CIA stands for Confidentiality, Integrity and Availability, -and it is usually depicted as a triangle representing the strong bonds between its three tenets. -This triad is considered the pillars of application security, -often Confidentiality, Integrity or Availability are used as a properties of data or processes within a given system. -The CIA triad can be extended with the AAA triad: Authorization, Authentication and Auditing. - -#### Confidentiality - -Confidentiality is the protection of data against unauthorized disclosure; -it is about ensuring that only those with the correct authorization can access the data -and applies to both data at rest and to data in transit. -Confidentiality is also related to the broader concept of data privacy. - -#### Integrity - -Integrity is about protecting data against unauthorized modification, or assuring data trustworthiness. -The concept contains the notion of data integrity (data has not been changed accidentally or deliberately) -and the notion of source integrity (data came from or was changed by a legitimate source). - -#### Availability - -Availability is about ensuring the presence of information or resources. -This concept relies not just on the availability of the data itself, for example by using replication of data, -but also on the protection of the services that provide access to the data, for example by using load balancing. - -#### AAA triad - -The CIA triad is often extended with Authentication, Authorization and Auditing as these are closely linked to CIA concepts. -CIA has a strong dependency on Authentication and Authorization; -the confidentiality and integrity of sensitive data can not be assured without them. -Auditing is added as it can provide the mechanism to ensure proof of any interaction with the system. - -#### Authentication - -[Authentication][csauthn] is about confirming the identity of the entity that wants to interact with a secure system. -For example the entity could be an automated client or a human actor; -in either case authentication is required for a secure application. - -#### Authorization - -[Authorization][csauthz] is about specifying access rights to secure resources (data, services, files, applications, etc). -These rights describe the privileges or access levels related to the resources that are being secured. -Authorization is usually preceded by successful authentication. - -#### Auditing - -Auditing is about keeping track of implementation-level events, as well as domain-level events taking place in a system. -This helps to provide non-repudiation, which means that changes or actions on the protected system are undeniable. -Auditing can provide not only technical information about the running system, -but also proof that particular actions have been performed. -The typical questions that are answered by auditing are "Who did What, When and potentially How?" - -#### Vulnerabilities - -NIST defines a [vulnerability][nistvuln] as 'Weakness in an information system, system security procedures, -internal controls, or implementation that could be exploited or triggered by a threat source.' - -There are many weaknesses or bugs in every large application, but the term vulnerability is generally reserved -for those weaknesses or bugs where there is a risk that a threat actor could exploit it using a threat vector. - -Well known security vulnerabilities are : - -* [Clickjacking][csclick] -* [Credential Stuffing][cscreds] -* [Cross-site leaks][csxsleaks] -* [Denial of Service][csdos] (DoS) attacks -* DOM based [XSS attacks][csdom] including [DOM Clobbering][csdomclub] -* [IDOR][csidor] (Insecure Direct Object Reference) -* [Injection][csinjection] including [OS Command injection][csosinjection] and [XXE][csxxe] -* LDAP specific [injection attacks][csldap] -* [Prototype pollution][csproto] -* [SSRF][csssrf] attacks -* [SQL injection][cssql] and the use of [Query Parameterization][csquery] -* [Unvalidated redirects and forwards][csredirect] -* [XSS attacks][csxss] and [XSS Filter Evasion][csxssevade] - -#### HTTP and HTML - -Although not a security fundamental as such, web applications rely on HTTP communications and HTML. -Both application developers and security engineers should have a good understanding of HTTP -and the HTML language along with their various security controls. - -Most application development teams will be familiar with HTTP communications and the HTML standard, -but if necessary refer to the training from the [W3 Consortium][w3consortium] or the [W3 Schools][w3schools]. -The OWASP [Cheat Sheet Series][cheatsheets] provide web application developers with the information -needed to produce secure software : - -* The [HTML5 Security][cshtml5] cheat sheet describes a wide range of controls, - aligned with the current [HTML Living Standard][htmlliving] -* Refer to the [Securing Cascading Style Sheets][cscss] cheat sheet for CSS -* The HTTP headers need to be secure, see the [HTTP Security Response Headers][csheaders] cheat sheet -* Strongly consider [HTTP Strict Transport Security][csstrict] -* If the application has a file upload feature, follow the [File Upload][csfile] cheat sheet -* Ensure content security policy is in place with the [Content Security Policy][cscsp] cheat sheet -* Using JWTs for a Java application? Refer to the [JSON Web Token][csjwt] cheat sheet -* Storing or sending objects? Check out the [Deserialization][csserial] cheat sheet - -#### References - -* [WHATWG][whatwg] [HTML Living Standard][htmlliving] -* OWASP [Cheat Sheet Series][cheatsheets] -* OWASP [Software Assurance Maturity Model][samm] (SAMM) - ----- - -The OWASP Developer Guide is a community effort; if there is something that needs changing -then [submit an issue][issue0401] or [edit on GitHub][edit0401]. - -[cheatsheets]: https://cheatsheetseries.owasp.org/ -[csclick]: https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet -[cscreds]: https://cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet -[cscsp]: https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet -[cscss]: https://cheatsheetseries.owasp.org/cheatsheets/Securing_Cascading_Style_Sheets_Cheat_Sheet -[csdom]: https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet -[csdomclub]: https://cheatsheetseries.owasp.org/cheatsheets/DOM_Clobbering_Prevention_Cheat_Sheet -[csdos]: https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet -[csidor]: https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet -[csinjection]: https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet -[csosinjection]: https://cheatsheetseries.owasp.org/cheatsheets/OS_Command_Injection_Defense_Cheat_Sheet -[csldap]: https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet -[csproto]: https://cheatsheetseries.owasp.org/cheatsheets/Prototype_Pollution_Prevention_Cheat_Sheet -[csauthn]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet -[csauthz]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet -[csfile]: https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet -[csheaders]: https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet -[cshtml5]: https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet -[csjwt]: https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet -[csredirect]: https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet -[csserial]: https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet -[cssql]: https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet -[csquery]: https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet -[csssrf]: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet -[csstrict]: https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet -[csxss]: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet -[csxsleaks]: https://cheatsheetseries.owasp.org/cheatsheets/XS_Leaks_Cheat_Sheet -[csxssevade]: https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet -[csxxe]: https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet -[edit0401]: https://github.com/OWASP/DevGuide/blob/main/docs/en/02-foundations/01-security-fundamentals.md -[htmlliving]: https://html.spec.whatwg.org/multipage/ -[issue0401]: https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%2002-foundations/01-security-fundamentals -[nistvuln]: https://csrc.nist.gov/glossary/term/vulnerability -[samm]: https://owaspsamm.org/about/ -[sammd]: https://owaspsamm.org/model/design/ -[sammg]: https://owaspsamm.org/model/governance/ -[sammi]: https://owaspsamm.org/model/implementation/ -[sammo]: https://owaspsamm.org/model/operations/ -[sammv]: https://owaspsamm.org/model/verification/ -[w3consortium]: https://www.w3.org/ -[w3schools]: https://www.w3schools.com/html/ -[whatwg]: https://whatwg.org/ diff --git a/docs/hi/02-foundations/02-secure-development.md b/docs/hi/02-foundations/02-secure-development.md deleted file mode 100644 index c4dc1a61..00000000 --- a/docs/hi/02-foundations/02-secure-development.md +++ /dev/null @@ -1,215 +0,0 @@ -Secure development is described in the OWASP Software Assurance Maturity Model [(SAMM)][samm] -[Design][sammd], [Implementation][sammi] and [Verification][sammv] business functions. -Also refer to the [Security Culture][culturewhy] for a good explanation -on why adding security into the software development lifecycle is important. - -#### Prelude - -The best introduction to practical secure software development is the -OWASP [Application Security Fragmentation][sdlc] article : - -_Or how I worried less and stood on the shoulders of giants._ - Spyros Gasteratos, Elie Saad - -Much of the material in this section is drawn from this OWASP [Integration Standards][intstand] project. - -#### Overview - -Almost all modern software is developed in an iterative manner passing through phase to phase, -such as identifying customer requirements, implementation and test. -These phases are revisited in a cyclic manner throughout the lifetime of the application. -A notional Software Development LifeCycle (SDLC) is shown below, in practice there may be more or less phases -according to the processes adopted by the organization. - -![SDLC Lifecycle](../../assets/images/sdlc_diag.png "notional SDLC lifecycle"){ align=right width=180 } - -With the increasing number and sophistication of exploits against almost every application or business system, -most companies have adopted a secure Software Development LifeCycle (SDLC). -The secure SDLC should never be a separate lifecycle from an existing software development lifecycle, -it must always be the same development lifecycle as before but with security actions built into each phase, -otherwise security actions may well be set aside by busy development teams. -Note that although the Secure SDLC could be written as 'SSDLC' it is almost always written as 'SDLC'. - -DevOps integrates and automates many of the SDLC phases and implements Continuous Integration (CI) -and Continuous Delivery/Deployment (CD) pipelines to provide much of the SDLC automation. - -DevOps and pipelines have been successfully exploited with serious large scale consequences -and so, in a similar manner to the SDLC, much of the DevOps actions have also had security built in to them. -Secure DevOps, or DevSecOps, builds security practices into the DevOps activities to guard against attack -and to provide the SDLC with automated security testing. - -Examples of how DevSecOps is 'building security in' is the provision of -Interactive, Static and Dynamic Application Security Testing (IAST, SAST & DAST) -and implementing supply chain security, and there are many other security activities that can be applied. -Refer to the [CI/CD Security Cheat Sheet][cscicd] for the latest DevSecOps security controls. - -#### Secure development lifecycle - -Referring to the OWASP [Application Security Wayfinder][intstand] development cycle -there are four iterative phases during application development: Requirements, Design, Implementation and Verification. -The other phases are done less iteratively in the development cycle but these form an equally important -part of the SDLC: Gap Analysis, Metrics, Operation and Training & Culture Building. - -All of these phases of the SDLC should have security activities built into them, -rather than done as separate activities. If security is built into these phases then the overhead becomes much less -and the resistance from the development teams decreases. The goal is for the secure SDLC to become as familiar -a process as before, with the development teams taking ownership of the security activities within each phase. - -There are many OWASP tools and resources to help build security into the SDLC. - -* **Requirements**: this phase determines the functional, non-functional and security requirements for the application. - Requirements should be revisited periodically and checked for completeness and validity, - and it is worth considering various OWASP tools to help with this; - * the [Application Security Verification Standard (ASVS)][asvs] provides developers - with a list of requirements for secure development, - * the [Mobile Application Security project][masproject] provides a security standard for mobile applications - and [SecurityRAT][srat] helps identify an initial set of security requirements. - -* **Design**: it is important to design security into the application - it is never too late to do this - but the earlier the better and easier to do. OWASP provides two tools, [Pythonic Threat Modeling][pytm] - and [Threat Dragon][tdtm], for threat modeling along with security gamification using [Cornucopia][cornucopia]. - -* **Implementation**: the OWASP [Top 10 Proactive Controls][proactive10] project states that they are - "the most important control and control categories that every architect and developer should absolutely, - 100% include in every project" and this is certainly good advice. Implementing these controls can provide - a high degree of confidence that the application or system will be reasonably secure. - OWASP provides two libraries that can be incorporated in web applications, - the [Enterprise Security API (ESAPI)][esapi-project] security control library - and [CSRFGuard][csrfguard] to mitigate the risk of [Cross-Site Request Forgery][cscsrf] (CSRF) attacks, - that help implement these proactive controls. In addition the OWASP [Cheat Sheet Series][csproject] - is a valuable source of information and advice on all aspects of applications security. - -* **Verification**: OWASP provides a relatively large number of projects that help with testing and verification. - This is the subject of a section in this Developer Guide, and the projects are listed at the end of this section. - -* **Training**: development teams continually need security training. - Although not part of the inner SDLC iterative loop training should still be factored into the project lifecycle. - OWASP provides many training environments and materials - see the list at the end of this section. - -* **Culture Building**: a good security culture within a business organization will help greatly in keeping - the applications and systems secure. There are many activities that all add up to create the - security culture, the OWASP [Security Culture][culture] project goes into more detail on these activities, - and a good Security Champion program within the business is foundational to a good security posture. - The OWASP [Security Champions Guide][champions] provides guidance and material to create security champions - within the development teams - ideally every team should have a security champion that has - a special interest in security and has received further training, enabling the team to build security in. - -* **Operations**: the OWASP [DevSecOps Guideline][devsecops] explains how to best implement a secure pipeline, - using best practices and automation tools to help 'shift-left' security issues. - Refer to the DevSecOps Guideline for more information on any of the topics within DevSecOps - and in particular sections on Operations. - -* **Supply chain**: attacks that leverage the supply chain can be devastating - and there have been several high profile of products being successfully exploited. - A Software Bill of Materials (SBOM) is the first step in avoiding these attacks and - it is well worth using the OWASP [CycloneDX][cyclone] full-stack Bill of Materials (BOM) standard - for [risk reduction in the supply chain][cschain]. - In addition the OWASP [Dependency-Track][deptrack] project is a Continuous SBOM Analysis Platform - which can help prevent these supply chain exploits by providing control of the SBOM. - -* **Third party dependencies**: keeping track of what third party libraries are included in the application, - and what vulnerabilities they have, is easily automated. Many public repositories such as [github][github] - and [gitlab][gitlab] offer this service along with some commercial vendors. - OWASP provides the [Dependency-Check][depcheck] Software Composition Analysis (SCA) tool - to track external libraries. - -* **Application security testing**: there are various types of security testing that can be automated on pull-request, - merge or nightlies - or indeed manually but they are most powerful when automated. Commonly there is - Static Application Security Testing (SAST), which analyzes the code without running it, - and Dynamic Application Security Testing (DAST), which applies input to the application while running it in a sandbox - or other isolated environments. - Interactive Application Security Testing (IAST) is designed to be run manually as well as being automated, - and provides instant feedback on the tests as they are run. - -#### Further reading from OWASP - -* [Cheat Sheet Series][csproject] -* [CI/CD Security Cheat Sheet][cscicd] -* [Cornucopia][cornucopia] -* [CycloneDX][cyclone] Bill of Materials (BOM) standard -* [DevSecOps Guideline][devsecops] -* [Security Champions Guide][champions] -* [Security Culture project][culture] -* [Top 10 Proactive Controls][proactive10] - -#### OWASP verification projects - -* [Application Security Verification Standard][asvs] (ASVS) -* [Amass project][amass] -* [Code Pulse][pulse] -* [Defect Dojo][defectdojo] -* [Mobile Application Security][masproject] (MAS) -* [Nettacker][net] -* [Offensive Web Testing Framework][owtf] (OWTF) -* [Web Security Testing Guide][wstg] (WSTG) - -#### OWASP training projects - -* [API Security Project][apisec] (API Top 10) -* [Juice Shop][juice] -* [Mobile Top 10][mobile10] -* [Security Shepherd][sec-shep] -* [Snakes And Ladders][snakes] -* [Top Ten Web Application security risks][top10] -* [WebGoat][webgoat] - -#### OWASP resources - -* [CSRFGuard library][csrfguard] -* [Dependency-Check Software Composition Analysis (SCA)][depcheck] -* [Dependency-Track Continuous SBOM Analysis Platform][deptrack] -* [Enterprise Security API][esapi-project] (ESAPI) -* [Integration Standards project Application Security Wayfinder][intstand] -* [Mobile Application Security][mas] (MAS) -* [Pythonic Threat Modeling][pytm] -* [Threat Dragon][tdtm] -* [SecurityRAT][srat] (Requirement Automation Tool) - ----- - -The OWASP Developer Guide is a community effort; if there is something that needs changing -then [submit an issue][issue0402] or [edit on GitHub][edit0402]. - -[amass]: https://owasp.org/www-project-amass/ -[apisec]: https://owasp.org/API-Security/ -[asvs]: https://owasp.org/www-project-application-security-verification-standard/ -[champions]: https://owasp.org/www-project-security-champions-guidebook/ -[cscicd]: https://cheatsheetseries.owasp.org/cheatsheets/CI_CD_Security_Cheat_Sheet -[cornucopia]: https://owasp.org/www-project-cornucopia/ -[cschain]: https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet -[cscsrf]: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet -[csproject]: https://owasp.org/www-project-cheat-sheets/ -[csrfguard]: https://owasp.org/www-project-csrfguard/ -[culture]: https://owasp.org/www-project-security-culture/ -[culturewhy]: https://owasp.org/www-project-security-culture/stable/2-Why_Add_Security_In_Development_Teams/ -[cyclone]: https://owasp.org/www-project-cyclonedx/ -[depcheck]: https://owasp.org/www-project-dependency-check/ -[deptrack]: https://dependencytrack.org/ -[devsecops]: https://owasp.org/www-project-devsecops-guideline/ -[defectdojo]: https://defectdojo.com/community -[edit0402]: https://github.com/OWASP/DevGuide/blob/main/docs/en/02-foundations/02-secure-development.md -[esapi-project]: https://owasp.org/www-project-enterprise-security-api/ -[github]: https://github.com/ -[gitlab]: https://about.gitlab.com/ -[issue0402]: https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%2002-foundations/02-secure-development -[juice]: https://owasp.org/www-project-juice-shop/ -[mas]: https://mas.owasp.org/ -[masproject]: https://owasp.org/www-project-mobile-app-security/ -[mobile10]: https://owasp.org/www-project-mobile-top-10/ -[net]: https://owasp.org/www-project-nettacker/ -[owtf]: https://owasp.org/www-project-owtf/ -[proactive10]: https://top10proactive.owasp.org/ -[pulse]: https://owasp.org/www-project-code-pulse/ -[pytm]: https://owasp.org/www-project-pytm/ -[samm]: https://owaspsamm.org/about/ -[sammd]: https://owaspsamm.org/model/design/ -[sammi]: https://owaspsamm.org/model/implementation/ -[sammv]: https://owaspsamm.org/model/verification/ -[sdlc]: https://owasp.org/www-project-integration-standards/writeups/owasp_in_sdlc/ -[sec-shep]: https://owasp.org/www-project-security-shepherd/ -[snakes]: https://owasp.org/www-project-snakes-and-ladders/ -[srat]: https://owasp.org/www-project-securityrat/ -[tdtm]: https://owasp.org/www-project-threat-dragon/ -[top10]: https://owasp.org/Top10/ -[intstand]: https://owasp.org/www-project-integration-standards/ -[webgoat]: https://owasp.org/www-project-webgoat/ -[wstg]: https://owasp.org/www-project-web-security-testing-guide/ diff --git a/docs/hi/02-foundations/03-security-principles.md b/docs/hi/02-foundations/03-security-principles.md deleted file mode 100644 index e32934da..00000000 --- a/docs/hi/02-foundations/03-security-principles.md +++ /dev/null @@ -1,198 +0,0 @@ -This section is a very brief introduction to some concepts used within the software security domain, -as these may not be familiar to many application developers. -The OWASP [Cheat Sheet Series][csproject] provides more in depth explanations for these security principles, -see the further reading at the end of this section. - -#### Overview - -There are various concepts and terms used in the security domain that are fundamental -to the understanding and discussion of application security. -Security architects and security engineers will be familiar with these terms and development teams -will also need this understanding to implement secure applications. - -#### Security by Design - -Security should not be an afterthought or add-on. When developing systems, you should begin with identifying relevant -security requirements and treat them as an integral part of the overall process and system design. Begin with -establishing and adopting relevant principles and policies as a foundation for your design, then build security -into your development life cycle. Keep also in mind that the system you are building also will be needing maintenance -and that system operators will need to securely manage and even shutdown and dispose of the system. Therefore, commit -to secure operations by developing secure "operational management"[^1] principles and practices. - -#### Security by Default - -Secure by default means that the default configuration settings are the most secure settings possible. This is not -necessarily the most user-friendly settings. Evaluate what the settings should be, based on both risk analysis and -usability tests. As a result, the precise meaning is up to you to decide. Nevertheless, configure the system to only -provide the least functionality and to specifically prohibit and/or restrict the use of all other functions, ports, -protocols, and/or services. Also configure the defaults to be as restrictive as possible, according to best practices, -without compromising the "Psychological acceptability" and "Usability and Manageability" of the system. - -#### No security guarantee - -One of the most important principles of software security is that no application or system is totally -100% guaranteed to be secure from all attacks. This may seem an unusually pessimistic starting point -but it is merely acknowledging the real world; given enough time and enough resources any system can be compromised. -The goal of software security is not '100% secure' but to make it hard enough and the rewards small enough -that malicious actors look elsewhere for systems to exploit. - -#### Defense in Depth - -Also known as layered defense, [defense in depth][did] is a security principle where defense against attack -is provided by multiple security controls. -The aim is that single points of complete compromise are eliminated or mitigated -by the incorporation of a series or multiple layers of security safeguards and risk-mitigation countermeasures. - -If one layer of defense turns out to be inadequate then, if diverse defensive strategies are in place, -another layer of defense may prevent a full breach and if that one is circumvented then -the next layer may block the exploit. - -#### Fail Safe - -This is a security principle that aims to maintain confidentiality, integrity and availability -when an error condition is detected. -These error conditions may be a result of an attack, or may be due to design or implementation failures, -in any case the system / applications should default to a secure state rather than an unsafe state. - -For example unless an entity is given explicit access to an object, -it should be denied access to that object by default. -This is often described as 'Fail Safe Defaults' or 'Secure by Default'. - -In the context of software security, the term 'fail secure' is commonly used interchangeably with fail safe, -which comes from physical security terminology. -Failing safe also helps software resiliency in that the system / application can rapidly recover -upon design or implementation flaws. - -#### Least Privilege - -A security principle in which a person or process is given only the minimum level of access rights (privileges) -that is necessary for that person or process to complete an assigned operation. -This right must be given only for a minimum amount of time that is necessary to complete the operation. - -This helps to limits the damage when a system is compromised by minimizing the ability of an attacker -to escalate privileges both laterally or vertically. -In order to apply this [principle of least privilege][elp] proper granularity -of privileges and permissions should be established. - -#### Compartmentalize - -The principle of least privilege works better if access rights are not an "all or nothing" access model. -Instead, compartmentalize the access to information on a "need-to-know" basis in order to perform certain tasks. -The compartmentalization principle helps in minimizing the impact of a security breach in case of a successful -breach attempt but must be used in moderation in order to prevent the system from becoming unmanageable. -Therefore, follow also the principle of "Economy of Mechanism". - -#### Separation of Duties - -Also known as [separation of privilege][sop], separation of duties is a security principle which requires that -the successful completion of a single task -is dependent upon two or more conditions that are insufficient, individually by themselves, for completing the task. - -There are many applications for this principle, -for example limiting the damage an aggrieved or malicious insider can do, or by limiting privilege escalation. - -#### Economy of Mechanism - -Also known as 'keep it simple', if there are multiple implementations then the simplest -and most easily understood implementation should be chosen. - -The likelihood of vulnerabilities increases with the complexity of the software architectural design and code, -and increases further if it is hard to follow or review the code. -The attack surface of the software is reduced by keeping the software design -and implementation details simple and understandable. - -#### Complete Mediation - -A security principle that ensures that authority is not circumvented in subsequent requests of an object by a subject, -by checking for authorization (rights and privileges) upon every request for the object. - -In other words, the access requests by a subject for an object are completely mediated every time, -so that all accesses to objects must be checked to ensure that they are allowed. - -#### Open Design - -The open design security principle states that the implementation details of the design -should be independent of the design itself, -allowing the design to remain open while the implementation can be kept secret. -This is in contrast to security by obscurity where the security of the software -is dependent upon the obscuring of the design itself. - -When software is architected using the open design concept, -the review of the design itself will not result in the compromise of the safeguards in the software. - -#### Least Common Mechanism - -The security principle of least common mechanisms disallows the sharing of mechanisms that are common -to more than one user or process if the users or processes are at different levels of privilege. -This is important when defending against privilege escalation. - -#### Psychological acceptability - -A security principle that aims at maximizing the usage and adoption of the security functionality in the software -by ensuring that the security functionality is easy to use and at the same time transparent to the user. -Ease of use and transparency are essential requirements for this security principle to be effective. - -Security controls should not make the resource significantly more difficult to access -than if the security control were not present. -If a security control provides too much friction for the users then they may look for ways -to defeat the control and “prop the doors open”. - -#### Usability and Manageability - -Is a principle related to psychological acceptability, but goes beyond just the perceived psychological -acceptability to also include the design, implementation and operation of security controls. -The configuration, administration and integration of security components should not be overly complex or -obscure. Therefore, always use open standards for portability and interoperability, use common language -in developing security requirements, design security to allow for regular adoption of new technology, -ensure a secure and logical upgrade process exist, automate security management activities and strive for -operational ease of use. - -#### Secure the Weakest Link - -This security principle states that the resiliency of your software against hacker attempts will depend heavily -on the protection of its weakest components, be it the code, service or an interface. Therefore, identifying the -weakest component and addressing the most serious risk first, until an acceptable level of risk is attained, is -considered good security practice. - -#### Leveraging Existing Components - -This is a security principle that focuses on ensuring that the attack surface is not increased -and no new vulnerabilities are introduced by promoting the reuse of existing -software components, code and functionality. - -Existing components are more likely to be tried and tested, and hence more secure, -and also should have security patches available. -In addition components developed within the open source community have the further benefit of 'many eyes' -and are therefore likely to be even more secure. - -#### References - -* OWASP Cheat Sheet series - * [Authentication Cheat Sheet][csauthn] - * [Authorization Cheat Sheet][csauthz] - * [Secure Product Design Cheat Sheet][spdcs] -* OWASP Top 10 Proactive Controls - * [C5: Secure by Default Configurations](https://top10proactive.owasp.org/the-top-10/c5-secure-by-default/) -* Other - * [Compartmentalization (information security)](https://en.wikipedia.org/wiki/Compartmentalization_(information_security)), -(Wikipedia) - * [Least Functionality](https://csf.tools/reference/nist-sp-800-53/r5/cm/cm-7/), (NIST) - * [Security by Design](https://pubs.opengroup.org/security/o-esa/#_Toc291061712), (Open Group) - * [Usability and Manageability](https://pubs.opengroup.org/security/o-esa/#_Toc291061714), (Open Group) - ----- - -The OWASP Developer Guide is a community effort; if there is something that needs changing -then [submit an issue][issue0403] or [edit on GitHub][edit0403]. - -[^1]: [Operational Management](https://owaspsamm.org/model/operations/operational-management/), (SAMM) - -[csauthn]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet -[csauthz]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet -[csproject]: https://owasp.org/www-project-cheat-sheets/ -[did]: https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet.html#2-the-principle-of-defense-in-depth -[edit0403]: https://github.com/OWASP/DevGuide/blob/main/docs/en/02-foundations/03-security-principles.md -[elp]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html#enforce-least-privileges -[issue0403]: https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%2002-foundations/03-security-principles -[sop]: https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet.html#1-the-principle-of-least-privilege-and-separation-of-duties -[spdcs]: https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet diff --git a/docs/hi/02-foundations/04-crypto-principles.md b/docs/hi/02-foundations/04-crypto-principles.md deleted file mode 100644 index 3df8c4ed..00000000 --- a/docs/hi/02-foundations/04-crypto-principles.md +++ /dev/null @@ -1,252 +0,0 @@ -Cryptography is fundamental to the Confidentiality and Integrity of applications and systems. -The OWASP [Cheat Sheet][csproject] series describes the use of cryptography and some of these are -listed in the further reading at the end of this section. - -#### Overview - -This section provides a brief introduction to cryptography (often simply referred to as "crypto") and the terms used. -Cryptography is a large subject and can get very mathematical, -but fortunately for the majority of development teams a general understanding of the concepts is sufficient. -This general understanding, with the guidance of security architects, should allow implementation -of cryptography by the development team for the application or system. - -#### Uses of cryptography - -Although cryptography was initially restricted primarily to the military and the realm of academia, -cryptography has become ubiquitous in securing software applications. -Common every day uses of cryptography include mobile phones, passwords, SSL VPNs, smart cards, and DVDs. -Cryptography has permeated through everyday life, and is heavily used by many web applications. - -Cryptography is one of the more advanced topics of information security, -and one whose understanding requires the most schooling and experience. -It is difficult to get right because there are many approaches to encryption, -each with advantages and disadvantages that need to be thoroughly understood by solution architects. - -The proper and accurate implementation of cryptography is extremely critical to its efficacy. -A small mistake in configuration or coding will result in removing most of the protection -and rending the crypto implementation useless. - -A good understanding of crypto is required to be able to discern between solid products and snake oil. -The inherent complexity of crypto makes it easy to fall for fantastic claims from vendors about their product. -Typically, these are "a breakthrough in cryptography" or "unbreakable" or provide "military grade" security. -If a vendor says "trust us, we have had experts look at this," chances are they weren't experts! - -#### Confidentiality - -For the purposes of this section, confidentiality is defined as "no unauthorized disclosure of information". -Cryptography addresses this via encryption of either the data at rest or data in transit by -protecting the information from all who do not hold the decryption key. -Cryptographic hashes (secure, one way hashes) to prevent passwords from disclosure. - -#### Authentication - -[Authentication][csauthn] is the process of verifying a claim that a subject is who it says it is -via some provided corroborating evidence. -Cryptography is central to authentication: - -1. to protect the provided corroborating evidence (for example hashing of passwords for subsequent storage) -2. in authentication protocols often use cryptography to either directly authenticate entities - or to exchange credentials in a secure manner -3. to verify the identity one or both parties in exchanging messages, - for example identity verification within [Transport Layer Security][tls] (TLS) - -OpenID Connect is widely used as an identity layer on top of the OAuth 2.0 protocol, -see the [OAuth 2.0 Protocol][csoauth] Cheat Sheet. - -#### Integrity - -Integrity ensures that even authorized users have performed no accidental or malicious alternation of information. -Cryptography can be used to prevent tampering by means of Message Authentication Codes (MACs) or digital signatures. - -The term 'message authenticity' refers to ensuring the integrity of information, -often using symmetric encryption and shared keys, -but does not authenticate the sending party. - -The term 'authenticated encryption' also ensures the integrity of information, -and, if asymmetric encryption is used, can authenticate the sender. - -#### Non-repudiation - -Non-repudiation of sender ensures that someone sending a message should not be able to deny later that they have sent it. -Non-repudiation of receiver means that the receiver of a message should not be able to deny that they have received it. -Cryptography can be used to provide non-repudiation by providing unforgeable messages or replies to messages. - -Non-repudiation is useful for financial, e-commerce, and contractual exchanges. -It can be accomplished by having the sender or recipient digitally sign some unique transactional record. - -#### Attestation - -Attestation is the act of "bearing witness" or certifying something for a particular use or purpose. -Attestation is generally discussed in the context of a Trusted Platform Module (TPM), -Digital Rights Management (DRM), and UEFI Secure Boot. - -For example, Digital Rights Management is interested in attesting that your device -or system hasn't been compromised with some back-door to allow someone to illegally copy DRM-protected content. - -Cryptography can be used to provide a chain of evidence that everything is as it is expected to be, -to prove to a challenger that everything is in accordance with the challenger's expectations. -For example, remote attestation can be used to prove to a challenger that -you are indeed running the software that you claim that you are running. -Most often attestation is done by providing a chain of digital signatures starting with -a trusted (digitally signed) boot loader. - -#### Cryptographic hashes - -Cryptographic hashes, also known as message digests, are functions that map arbitrary length bit strings -to some fixed length bit string known as the 'hash value' or 'digest value'. -These hash functions are many-to-one mappings that are compression functions. - -Cryptographic hash functions are used to provide data integrity (i.e., to detect intentional data tampering), -to store passwords or pass phrases, and to provide digital signatures in a more efficient manner -than using asymmetric ciphers. -Cryptographic hash functions are also used to extend a relatively small bit of entropy -so that secure random number generators can be constructed. - -When used to provide data integrity, cryptographic functions provide two types of integrity: -keyed hashes, often called 'message authentication codes', and unkeyed hashes called 'message integrity codes'. - -#### Ciphers - -A cipher is an algorithm that performs encryption or decryption. -Modern ciphers can be categorized in a couple of different ways. -The most common distinctions between them are: - -* Whether they work on fixed size number of bits (block ciphers) or on a continuous stream of bits (stream ciphers) -* Whether the same key is used for both encryption and decryption (symmetric ciphers) - or separate keys for encryption and decryption (asymmetric ciphers) - -#### Symmetric Ciphers - -Symmetric ciphers encrypt and decrypt using the same key. -This implies that if one party encrypts data that a second party must decrypt, -those two parties must share a common key. - -Symmetric ciphers come in two main types: - -1. Block ciphers, which operate on a block of characters (typically 8 or 16 octets) at a time. - An example of a block cipher is AES -2. Stream ciphers, which operate on a single bit (or occasionally a single byte) at a time. - Examples of a stream ciphers are RC4 (aka, ARC4) and Salsa20 - -Note that all block ciphers can also operate in 'streaming mode' by selecting the appropriate cipher mode. - -#### Cipher Modes - -Block ciphers can function in different modes of operations known as "cipher modes". -This cipher mode algorithmically describes how a cipher operates to repeatedly -apply its encryption or decryption mechanism to a given cipher block. -Cipher modes are important because they have an enormous impact on both the confidentiality -and the message authenticity of the resulting ciphertext messages. - -Almost all cryptographic libraries support the four original DES cipher modes of ECB, CBC (Cipher Block Chaining) -OFB (Output Feedback), and CFB (Cipher Feedback). Many also support CTR (Counter) mode. - -#### Initialization vector - -A cryptographic initialization vector (IV) is a fixed size input to a block cipher's encryption / decryption primitive. -The IV is recommended (and in many cases, required) to be random or at least pseudo-random. - -#### Padding - -Except when they are operating in a streaming mode, block ciphers generally operate on fixed size blocks. -These block ciphers must also operate on messages of any size, -not just those that are an integral multiple of the cipher's block size, -and so the message can be padded to fit into the next fixed-size block. - -#### Asymmetric ciphers - -Asymmetric ciphers encrypt and decrypt with two different keys. -One key generally is designated as the private key and the other is designated as the public key. -Generally the public key is widely shared and the private key is kept secure. - -Asymmetric ciphers are several orders of magnitude slower than symmetric ciphers. -For this reason they are used frequently in hybrid cryptosystems, which combine asymmetric and symmetric ciphers. -In such hybrid cryptosystems, a random symmetric session key is generated -which is only used for the duration of the encrypted communication. -This random session key is then encrypted using an asymmetric cipher and the recipient's private key. -The plaintext data itself is encrypted with the session key. -Then the entire bundle (encrypted session key and encrypted message) is all sent together. -Both [TLS][tls] and S/MIME are common cryptosystems using hybrid cryptography. - -#### Digital signature - -Digital signatures are a cryptographically unique data string that is used to ensure data integrity -and prove the authenticity of some digital message, and that associates some input message with an originating entity. -A digital signature generation algorithm is a cryptographically strong algorithm that is used -to generate a digital signature. - -#### Key agreement protocol - -Key agreement protocols are protocols whereby N parties (usually two) can agree on a common key -without actually exchanging the key. -When designed and implemented properly, key agreement protocols prevent adversaries -from learning the key or forcing their own key choice on the participating parties. - -#### Application level encryption - -Application level encryption refers to encryption that is considered part of the application itself; -it implies nothing about where in the application code the encryption is actually done. - -#### Key derivation - -A key derivation function (KDF) is a deterministic algorithm to derive a key of a given size from some secret value. -If two parties use the same shared secret value and the same KDF, they should always derive exactly the same key. - -#### Key wrapping - -Key wrapping is a construction used with symmetric ciphers to protect cryptographic key material -by encrypting it in a special manner. -Key wrap algorithms are intended to protect keys while held in untrusted storage -or while transmitting keys over insecure communications networks. - -#### Key exchange algorithms - -Key exchange algorithms (also referred to as key establishment algorithms) are protocols -that are used to exchange secret cryptographic keys -between a sender and receiver in a manner that meets certain security constraints. -Key exchange algorithms attempt to address the problem of securely sharing a common secret key with two parties -over an insecure communication channel in a manner that no other party can gain access to a copy of the secret key. - -The most familiar key exchange algorithm is Diffie-Hellman Key Exchange. -There are also password authenticated key exchange algorithms. -RSA key exchange using PKI or webs-of-trust or trusted key servers are also commonly used. - -#### Key transport protocols - -Key Transport protocols are where one party generates the key and sends it securely to the recipient(s). - -#### Key agreement protocols - -Key Agreement protocols are protocols whereby N parties (usually two) can agree on a common key -with all parties contributing to the key value. -These protocols prevent adversaries from learning the key or forcing their own key choice on the participating parties. - -#### References - -* OWASP Cheat Sheet series - * [Authentication][csauthn] - * [Authorization][csauthz] - * [Cryptographic Storage][cscs] - * [Key Management][kmcs] - * [OAuth 2.0 Protocol][csoauth] - * [SAML Security][sscs] - * [Secure Product Design][spdcs] - * [User Privacy Protection][uppcs] - ----- - -The OWASP Developer Guide is a community effort; if there is something that needs changing -then [submit an issue][issue0404] or [edit on GitHub][edit0404]. - -[csauthn]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet -[csauthz]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet -[csoauth]: https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet -[csproject]: https://owasp.org/www-project-cheat-sheets/ -[cscs]: https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet -[edit0404]: https://github.com/OWASP/DevGuide/blob/main/docs/en/02-foundations/04-crypto-principles.md -[issue0404]: https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%2002-foundations/04-crypto-principles -[kmcs]: https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet -[sscs]: https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet -[spdcs]: https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet -[tls]: https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet -[uppcs]: https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet diff --git a/docs/hi/02-foundations/05-top-ten.md b/docs/hi/02-foundations/05-top-ten.md deleted file mode 100644 index c9191346..00000000 --- a/docs/hi/02-foundations/05-top-ten.md +++ /dev/null @@ -1,208 +0,0 @@ -![Top 10 logo](../../assets/images/logos/top10.png "OWASP Top 10"){ align=right width=180 } - -The OWASP Top Ten is a very well known list of web application security risks, -and is included by the OWASP Software Assurance Maturity Model [(SAMM)][samm] -in the Education & Guidance practice within the Governance business function. - -#### Overview - -The OWASP [Top 10 Web Application Security Risks][top10project] project is probably the most well known security concept -within the security community, achieving wide spread acceptance and fame soon after its release in 2003. -Often referred to as just the 'OWASP Top Ten', it is a list that identifies the most important threats -to web applications and seeks to rank them in importance and severity. - -The list has changed over time, with some threat types becoming more of a problem to web applications -and other threats becoming less of a risk as technologies change. -The [latest version][top10] was issued in 2021 and each category is summarized below. - -Note that there are various 'OWASP Top Ten' projects, for example the 'OWASP Top 10 for Large Language Model Applications', -so to avoid confusion the context should be noted when referring to these lists. - -#### A01:2021 Broken Access Control - -Access control involves the use of protection mechanisms that can be categorized as: - -* Authentication (proving the identity of an actor) -* Authorization (ensuring that a given actor can access a resource) -* Accountability (tracking of activities that were performed) - -Broken Access Control is where the product does not restrict, or incorrectly restricts, access to a resource -from an unauthorized or malicious actor. -When a security control fails or is not applied then attackers can compromise the security of the product -by gaining privileges, reading sensitive information, executing commands, evading detection, etc. - -Broken Access Control can take many forms, such as path traversal or elevation of privilege, -so refer to both the [Common Weakness Enumeration CWE-284][cwe284] and [A01 Broken Access Control][a01] -and also follow the various [OWASP Cheat Sheets][a01cs] related to access controls. - -#### A02:2021 Cryptographic Failures - -Referring to [OWASP Top 10 A02:2021][a02], sensitive data should be protected when at rest and in transit. -Cryptographic failures occur when the cryptographic security control is either broken or not applied, -and the data is exposed to unauthorized actors - malicious or not. - -It is important to protect data both at rest, when it is stored in an area of memory, -and also when it is in transit such as being transmitted across a communication channel or being transformed. -A good example of protecting data transformation is given by [A02 Cryptographic Failures][a02] -where sensitive data is properly encrypted in a database, but the export function automatically -decrypts the data leading to sensitive data exposure. - -Crypto failures can take many forms and may be subtle - a security control that looks secure may be easily broken. -Follow the crypto [OWASP Cheat Sheets][a02cs] to get the basic crypto controls in place -and consider putting a crypto audit in place. - -#### A03:2021 Injection - -A lack of input validation and sanitization can lead to injection exploits, -and this risk has been a constant feature of the OWASP Top Ten since the first version was published in 2003. -These vulnerabilities occur when hostile data is directly used within the application -and can result in malicious data being used to subvert the application; see [A03 Injection][a03] for further explanations. - -The security control is straight forward: all input from untrusted sources should be sanitized and validated. -See the [Injection Cheat Sheets][a03cs] for the various types of input and their controls. - -#### A04:2021 Insecure Design - -It is important that security is built into applications from the beginning and not applied as an afterthought. -The [A04 Insecure Design][a04] category recognizes this and advises that -the use of threat modeling, secure design patterns, and reference architectures -should be incorporated within the application design and architecture activities. - -In practice this involves establishing a secure development lifecycle that encourages -the identification of security requirements, the periodic use of threat modeling -and consideration of existing secure libraries and frameworks. -This category was introduced in the 2021 version and for now the supporting cheat sheets only cover [threat modeling][cstm]; -as this category becomes more established it is expected that more supporting information will become available. - -#### A05:2021 Security Misconfiguration - -Systems and large applications can be configurable, and this configuration is often used to secure the system/application. -If this configuration is misapplied then the application may no longer be secure, -and instead be vulnerable to well-known exploits. The [A05 Security Misconfiguration][a05] page contains -a common example of misconfiguration where default accounts and their passwords are still enabled and unchanged. -These passwords and accounts are usually well-known and provide an easy way for malicious actors to compromise applications. - -Both the [OWASP Top 10 A05:2021][a05] and the linked [OWASP Cheat Sheets][a05cs] provide strategies to establish -a concerted, repeatable application security configuration process to minimize misconfiguration. - -#### A06:2021 Vulnerable and Outdated Components - -Perhaps one of the easiest and most effective security activities -is keeping all the third party software dependencies up to date. -If a vulnerable dependency is identified by a malicious actor during the reconnaissance phase of an attack -then there are databases available, such as [Exploit Database][exploit], that will provide a description of any exploit. -These databases can also provide ready made scripts and techniques for attacking a given vulnerability, -making it easy for vulnerable third party software dependencies to be exploited . - -Risk [A06 Vulnerable and Outdated Components][a06] underlines the importance of this activity, -and recommends that fixes and upgrades to the underlying platform, frameworks, and dependencies -are based on a risk assessment and done in a 'timely fashion'. -Several tools can used to analyze dependencies and flag vulnerabilities, refer to the [Cheat Sheets][a06cs] for these. - -#### A07:2021 Identification and Authentication Failures - -Confirmation of the user's identity, authentication, and session management is critical -to protect the system or application against authentication related attacks. -Referring to risk [A07 Identification and Authentication Failures][a07], authorization can fail in several ways -that often involve other OWASP Top Ten risks: - -* broken access controls (A01) -* cryptographic failure (A02) -* default passwords (A05) -* out-dated libraries (A06) - -Refer to the [Cheat Sheets][a07cs] for the several good practices that are needed for secure authorization. -There are also third party suppliers of Identity and Access Management (IAM) that will provide this as a service, -consider the cost / benefit of using these (often commercial) suppliers. - -#### A08:2021 Software and Data Integrity Failures - -Software and data integrity failures relate to code and infrastructure that does not protect against integrity violations. -This is a wide ranging category that describes [supply chain attacks][cschain], -compromised auto-update and use of untrusted components for example. -[A07 Software and Data Integrity Failures][a08] was a new category introduced in 2021 -so there is little information available from the [Cheat Sheets][a08cs], -but this is sure to change for such an important threat. - -#### A09:2021 Security Logging and Monitoring Failures - -Logging and monitoring helps detect, escalate, and respond to active breaches; without it breaches will not be detected. -[A09 Security Logging and Monitoring Failures][a09] lists various logging and monitoring techniques that should be familiar, -but also others that may not be so common; -for example monitoring the DevOps supply chain may be just as important as monitoring the application or system. -The [Cheat Sheets][a09cs] provide guidance on sufficient logging and also provide for a common logging vocabulary. -The aim of this common vocabulary is to provide logging that uses a common set of terms, formats and key words; -and this allows for easier monitoring, analysis and alerting. - -#### A10:2021 Server-Side Request Forgery - -Referring to [A10 Server-Side Request Forgery (SSRF)][a10], these vulnerabilities can occur -whenever a web application is fetching a remote resource without validating the user-supplied URL. -These exploits allow an attacker to coerce the application to send a crafted request to an unexpected destination, -even when protected by a firewall, VPN, or another type of network access control list. -Fetching a URL has become a common scenario for modern web applications and as a result the incidence of SSRF is increasing, -especially for [cloud services][cscloud] and more complex application architectures. - -This is a new category introduced in 2021 with a single (for now) [Cheat Sheet][a10cs] that deals with SSRF. - -#### OWASP top tens - -There are various 'Top 10' projects created by OWASP that, depending on the context, -may also be referred to as 'OWASP Top 10'. Here is a list of the stable 'OWASP Top 10' projects: - -* [API Security Top 10][apisec] -* [Citizen Development Top 10][cd10] -* [Data Security Top 10][data10] -* [Mobile Top 10][mobile10] -* [Serverless Top 10][serverless10] -* [Top 10 CI/CD Security Risks][cicd10] -* [Top 10 for Large Language Model Applications][llm10] -* [Top 10 Privacy Risks][privacy10] -* [Top 10 Proactive Controls][proactive10] -* [Top 10 Web Application Security Risks][top10] - -Other OWASP Top 10s are 'incubator' projects, which are work in progress, so this list will change over time. - ----- - -The OWASP Developer Guide is a community effort; if you see something that needs changing -then [submit an issue][issue0405] or [edit on GitHub][edit0405]. - -[a01]: https://owasp.org/Top10/A01_2021-Broken_Access_Control/ -[a01cs]: https://cheatsheetseries.owasp.org/IndexTopTen.html#a012021-broken-access-control -[a02]: https://owasp.org/Top10/A02_2021-Cryptographic_Failures/ -[a02cs]: https://cheatsheetseries.owasp.org/IndexTopTen.html#a022021-cryptographic-failures -[a03]: https://owasp.org/Top10/A03_2021-Injection/ -[a03cs]: https://cheatsheetseries.owasp.org/IndexTopTen.html#a032021-injection -[a04]: https://owasp.org/Top10/A04_2021-Insecure_Design/ -[a05]: https://owasp.org/Top10/A05_2021-Security_Misconfiguration/ -[a05cs]: https://cheatsheetseries.owasp.org/IndexTopTen.html#a052021-security-misconfiguration -[a06]: https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/ -[a06cs]: https://cheatsheetseries.owasp.org/IndexTopTen.html#a062021-vulnerable-and-outdated-components -[a07]: https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/ -[a07cs]: https://cheatsheetseries.owasp.org/IndexTopTen.html#a072021-identification-and-authentication-failures -[a08]: https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/ -[a08cs]: https://cheatsheetseries.owasp.org/IndexTopTen.html#a082021-software-and-data-integrity-failures -[a09]: https://owasp.org/Top10/A09_2021-Security_Logging_and_Monitoring_Failures/ -[a09cs]: https://cheatsheetseries.owasp.org/IndexTopTen.html#a092021-security-logging-and-monitoring-failures -[a10]: https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/ -[a10cs]: https://cheatsheetseries.owasp.org/IndexTopTen.html#a102021-server-side-request-forgery-ssrf -[apisec]: https://owasp.org/API-Security/ -[cd10]: https://owasp.org/www-project-citizen-development-top10-security-risks/ -[cicd10]: https://owasp.org/www-project-top-10-ci-cd-security-risks/ -[cschain]: https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet -[cscloud]: https://cheatsheetseries.owasp.org/cheatsheets/Secure_Cloud_Architecture_Cheat_Sheet -[cstm]: https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet -[cwe284]: https://cwe.mitre.org/data/definitions/284.html -[data10]: https://owasp.org/www-project-data-security-top-10/ -[edit0405]: https://github.com/OWASP/DevGuide/blob/main/docs/en/02-foundations/05-top-ten.md -[exploit]: https://www.exploit-db.com/ -[issue0405]: https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%2002-foundations/05-top-ten -[mobile10]: https://owasp.org/www-project-mobile-top-10/ -[privacy10]: https://owasp.org/www-project-top-10-privacy-risks/ -[proactive10]: https://top10proactive.owasp.org/ -[samm]: https://owaspsamm.org/about/ -[serverless10]: https://owasp.org/www-project-serverless-top-10/ -[top10project]: https://owasp.org/www-project-top-ten/ -[top10]: https://owasp.org/Top10/ -[llm10]: https://owasp.org/www-project-top-10-for-large-language-model-applications/ diff --git a/docs/hi/02-foundations/index.md b/docs/hi/02-foundations/index.md deleted file mode 100644 index 221808f6..00000000 --- a/docs/hi/02-foundations/index.md +++ /dev/null @@ -1,26 +0,0 @@ -![Developer guide logo](../../assets/images/dg_logo.png "OWASP Developer Guide"){ align=right width=180 } - -There are various foundational concepts and terminology that are commonly used in software security. -Although many of these concepts are complex to implement and are based on heavy-duty theory, -the principles are often fairly straight forward and are accessible for every software engineer. - -A reasonable grasp of these foundational concepts allows development teams to understand and implement -software security for the application or system under development. -This Developer Guide can only give a brief overview of these concepts, -for in-depth knowledge refer to the many texts on security such as the [The Cyber Security Body Of Knowledge][cbok]. - -If changes are being introduced to the security culture of an organization -then make sure there is management buy-in and clear goals to achieve. -Without these then attempts to improve the security posture will probably fail - see the -[Security Culture][culturegoal] project for the importance of getting management, -security and development teams working together. - ----- - -The OWASP Developer Guide is a community effort; if you see something that needs changing -then [submit an issue][issue0400] or [edit on GitHub][edit0400]. - -[cbok]: https://www.cybok.org/ -[culturegoal]: https://owasp.org/www-project-security-culture/stable/3-Goal_Setting_and_Security_Team_Collaboration/ -[edit0400]: https://github.com/OWASP/DevGuide/blob/main/docs/en/02-foundations/index.md -[issue0400]: https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%2002-foundations/index diff --git a/docs/index.md b/docs/index.md index a92ef501..b9fe778c 100644 --- a/docs/index.md +++ b/docs/index.md @@ -7,14 +7,7 @@ that works to improve the security of software. It is an open community dedicated to enabling organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted. -Along with the OWASP Top Ten, the Developer Guide is one of the original resources -published soon after the OWASP foundation was formed in 2001. -Version 1.0 of the Developer Guide was released in 2002 -and since then there have been various [releases][versions] culminating in version 2.0 in 2005. -Since then the guide has been revised extensively to bring it up to date. -The latest versions are 4.x because version 3.0 was never released. - -The purpose of this guide is to provide an introduction to security concepts +The purpose of this Developer Guide is to provide an introduction to security concepts and a handy reference for application / system developers. Generally it describes security practices using the advice given in the OWASP Software Assurance Maturity Model ([SAMM][samm]) and describes the OWASP projects @@ -23,7 +16,7 @@ referenced in the OWASP [Application Security Wayfinder][intstand] project. This guide does not seek to replicate the many excellent sources on specific security topics; it rarely tries to go into detail on a subject and instead provides links for greater depth on these security topics. Instead the content of the Developer Guide aims to be accessible, introducing practical security concepts -and providing enough detail to get developers started on various OWASP tools and documents. +and providing just enough detail to get developers started on various OWASP tools and documents. All of the OWASP projects and tools described in this guide are free to download and use. All OWASP projects are open source; please do get involved if you are interested in improving application security. @@ -31,8 +24,7 @@ All OWASP projects are open source; please do get involved if you are interested #### Audience Developers should use this OWASP Developer Guide to help write applications that are more secure. -The guide has been written by the security community to help software developers write solid, -safe and secure applications. +The guide has been written by the security community to help software developers write solid, safe and secure applications. Most of the contributors to this guide are also software developers as well as security engineers, and this helps to keep the focus developer-centric. @@ -55,6 +47,17 @@ projects and documents within OWASP and the Developer Guide provides some 'wordy [![AppSec Wayfinder](assets/images/owasp-wayfinder.png "OWASP Application Security Wayfinder")][intstand] +#### A bit of history + +Along with the OWASP Top Ten, the Developer Guide is one of the original resources +published soon after the OWASP foundation was formed in 2001. +The latest 4.x versions of the guide have been revised extensively to bring it up to date. + +Version 1.0 of the Developer Guide was released in 2002 +under the title 'A Guide to Building Secure Web Applications and Web Services'. +There were various subsequent [releases][versions] culminating in version 2.0 in 2005. +After that there was an attempt to bring the Developer Guide to a version 3.0 but this was never released. + ---- The OWASP Developer Guide is a community effort; if there is something that needs changing diff --git a/mkdocs-pdf-en.yaml b/mkdocs-pdf-en.yaml index b03d4c94..8f414b65 100644 --- a/mkdocs-pdf-en.yaml +++ b/mkdocs-pdf-en.yaml @@ -54,12 +54,13 @@ nav: - Overview: en/04-design/index.md - Threat modeling: - Overview: en/04-design/01-threat-modeling/index.md - - Threat modeling in practice: en/04-design/01-threat-modeling/01-threat-modeling.md + - Threat modeling: en/04-design/01-threat-modeling/01-threat-modeling-project.md - pytm: en/04-design/01-threat-modeling/02-pytm.md - Threat Dragon: en/04-design/01-threat-modeling/03-threat-dragon.md - Cornucopia: en/04-design/01-threat-modeling/04-cornucopia.md - LINDDUN GO: en/04-design/01-threat-modeling/05-linddun-go.md - - Threat Modeling toolkit: en/04-design/01-threat-modeling/06-toolkit.md + - Threat Model Library: en/04-design/01-threat-modeling/06-threat-model-library.md + - Threat modeling in practice: en/04-design/01-threat-modeling/07-practical-threat-modeling.md - Web application checklist: - Overview: en/04-design/02-web-app-checklist/index.md - Secure by Default: en/04-design/02-web-app-checklist/01-secure-by-default.md diff --git a/mkdocs-pdf-es.yaml b/mkdocs-pdf-es.yaml index 86a3e8c8..d00378f0 100644 --- a/mkdocs-pdf-es.yaml +++ b/mkdocs-pdf-es.yaml @@ -59,12 +59,13 @@ nav: - Descripción: es/04-design/index.md - Modelado de amenazas: - Descripción: es/04-design/01-threat-modeling/index.md - - Modelado de amenazas en la práctica: es/04-design/01-threat-modeling/01-threat-modeling.md + - Threat modeling: en/04-design/01-threat-modeling/01-threat-modeling-project.md - pytm: es/04-design/01-threat-modeling/02-pytm.md - Threat Dragon: es/04-design/01-threat-modeling/03-threat-dragon.md - - Cornucopia: es/04-design/01-threat-modeling/04-cornucopia.md - - LINDDUN GO: es/04-design/01-threat-modeling/05-linddun-go.md - - Threat Modeling toolkit: es/04-design/01-threat-modeling/06-toolkit.md + - Cornucopia: en/04-design/01-threat-modeling/04-cornucopia.md + - LINDDUN GO: en/04-design/01-threat-modeling/05-linddun-go.md + - Threat Model Library: en/04-design/01-threat-modeling/06-threat-model-library.md + - Modelado de amenazas en la práctica: es/04-design/01-threat-modeling/01-threat-modeling.md - Lista de verificación para aplicaciones web: - Descripción: es/04-design/02-web-app-checklist/index.md - Definir Requisitos de Seguridad: es/04-design/02-web-app-checklist/01-define-security-requirements.md diff --git a/mkdocs-pdf-fa.yaml b/mkdocs-pdf-fa.yaml index d5e52a12..de1514c0 100644 --- a/mkdocs-pdf-fa.yaml +++ b/mkdocs-pdf-fa.yaml @@ -54,12 +54,13 @@ nav: - Overview: en/04-design/index.md - Threat modeling: - Overview: en/04-design/01-threat-modeling/index.md - - Threat modeling in practice: en/04-design/01-threat-modeling/01-threat-modeling.md + - Threat modeling: en/04-design/01-threat-modeling/01-threat-modeling-project.md - pytm: en/04-design/01-threat-modeling/02-pytm.md - Threat Dragon: en/04-design/01-threat-modeling/03-threat-dragon.md - Cornucopia: en/04-design/01-threat-modeling/04-cornucopia.md - LINDDUN GO: en/04-design/01-threat-modeling/05-linddun-go.md - - Threat Modeling toolkit: en/04-design/01-threat-modeling/06-toolkit.md + - Threat Model Library: en/04-design/01-threat-modeling/06-threat-model-library.md + - Threat modeling in practice: en/04-design/01-threat-modeling/07-practical-threat-modeling.md - Web application checklist: - Overview: en/04-design/02-web-app-checklist/index.md - Secure by Default: en/04-design/02-web-app-checklist/01-secure-by-default.md diff --git a/mkdocs-pdf-pt-br.yaml b/mkdocs-pdf-pt-br.yaml index 9f627564..88e20e3a 100644 --- a/mkdocs-pdf-pt-br.yaml +++ b/mkdocs-pdf-pt-br.yaml @@ -57,12 +57,13 @@ nav: - Overview: en/04-design/index.md - Threat modeling: - Overview: en/04-design/01-threat-modeling/index.md - - Threat modeling in practice: en/04-design/01-threat-modeling/01-threat-modeling.md + - Threat modeling: en/04-design/01-threat-modeling/01-threat-modeling-project.md - pytm: en/04-design/01-threat-modeling/02-pytm.md - Threat Dragon: en/04-design/01-threat-modeling/03-threat-dragon.md - Cornucopia: en/04-design/01-threat-modeling/04-cornucopia.md - LINDDUN GO: en/04-design/01-threat-modeling/05-linddun-go.md - - Threat Modeling toolkit: en/04-design/01-threat-modeling/06-toolkit.md + - Threat Model Library: en/04-design/01-threat-modeling/06-threat-model-library.md + - Threat modeling in practice: en/04-design/01-threat-modeling/07-practical-threat-modeling.md - Web application checklist: - Overview: en/04-design/02-web-app-checklist/index.md - Secure by Default: en/04-design/02-web-app-checklist/01-secure-by-default.md diff --git a/mkdocs.yaml b/mkdocs.yaml index 5b4eabd2..4d52201e 100644 --- a/mkdocs.yaml +++ b/mkdocs.yaml @@ -48,6 +48,8 @@ plugins: - redirects: redirect_maps: 'en/04-design/02-web-app-checklist/01-define-security-requirements.md': 'en/04-design/02-web-app-checklist/01-secure-by-default.md' + 'en/04-design/01-threat-modeling/06-toolkit.md': 'en/04-design/01-threat-modeling/01-threat-modeling-project.md' + 'en/04-design/01-threat-modeling/01-threat-modeling.md': 'en/04-design/01-threat-modeling/07-practical-threat-modeling.md' nav: - 'Developer Guide': @@ -72,12 +74,13 @@ nav: - Overview: en/04-design/index.md - Threat modeling: - Overview: en/04-design/01-threat-modeling/index.md - - Threat modeling in practice: en/04-design/01-threat-modeling/01-threat-modeling.md + - Threat modeling: en/04-design/01-threat-modeling/01-threat-modeling-project.md - pytm: en/04-design/01-threat-modeling/02-pytm.md - Threat Dragon: en/04-design/01-threat-modeling/03-threat-dragon.md - Cornucopia: en/04-design/01-threat-modeling/04-cornucopia.md - LINDDUN GO: en/04-design/01-threat-modeling/05-linddun-go.md - - Threat Modeling toolkit: en/04-design/01-threat-modeling/06-toolkit.md + - Threat Model Library: en/04-design/01-threat-modeling/06-threat-model-library.md + - Threat modeling in practice: en/04-design/01-threat-modeling/07-practical-threat-modeling.md - Web application checklist: - Overview: en/04-design/02-web-app-checklist/index.md - Secure by Default: en/04-design/02-web-app-checklist/01-secure-by-default.md