🤔 Product Requirement Document for Shift-Left
Salute,
Today I want to share with you my practice for project management (PMI), which allows me to see the conceptual picture and analyze the correctness of the DevSecOps processes, AppSec Toolchain integration and human resource management.
What is PRD and why is it needed?
Used to describe the project's current summary status and features. This is a general document/reference book that is essentially equally understandable to developers, analysts, support, managers and information security.
Structure
- a brief description of the functionality - we describe what we want to do in simple words (as, for example, if we were telling a colleague at the “cooler”)
Bad example: “Add a “Verification” button to the authorized part of 2FA, put log data about who logged in, because then you need to build graphs from them”
A good example: “Ensure the security of user accounts and prevent unauthorized access within the infrastructure in the event of an account compromise. With the help of integration, the client, as well as us, will have the opportunity to exercise control and guarantee a secure, legitimate connection” (you feel how complicated and unclear this is)
- why we do this - unfolds the meaning in the first paragraph. Then it is decomposed.
Bad example: “Because the solver requires this feature to meet the requirements”
A good example: “Because this can give us the opportunity to quickly verify and control users, secure the user story and be confident in the security of the data (link to experiment results/calculation/case)”
- expected result - we describe what kind of result we are expecting, our Win Condition.
Win Condition answers one simple question - how will we understand what we have achieved? This can be any quantitative or qualitative metric, evaluation event. The main quality criteria for Win Condition are measurability, clear interpretability and simplicity (Invest principle).
Fail Condition does not need to be specified separately. By default, we assume that if the Win Condition is not reached, we automatically end up in the Fail state.
- information security risks - we describe and evaluate what could cause it and direct/indirect damage that requires changes in architecture, functionality, etc. - as an example, the risk of cybercrime and we understand that the input attack surface is larger than we have covered and allow
- artifacts - research, results, requirements, evidence
- functional requirements - the solution itself, providing alternatives for selecting and finalizing cases, so we will provide service and optimize interaction
User Story: we describe what the user, information security, development team, etc. will receive and why, with examples and comments.
Hardcore FT: we describe all business logic step by step (applicable when working on complex cases.
- analytics - an important section that describes which events should go where, we also describe what evaluation metrics we have.
Total:
- The PRD is sufficient for the technical team to carry out the initial decomposition together.
- The logic of using PRD in information security is the integration of the Shift Left process into the development and recording of information security requirements, as well as control and collection of evidence.
- It is he (or a link to him) who makes up the description of the user story, which is then decomposed into tasks (tasks)
- After completing the work / describing the requirements or other additions to the tasks - the PRD becomes documentation of how it worked and why / why it was implemented.
- PRD is written for large and complex things, where there are many dependencies and it is very important to preserve for history how it worked.
#devsecop #pmi #specialty #pmcases