We'd like to use ScoutSuite to collect and present Cloud findings in our Zero Trust report.

PDR

Problem statement

The problem currently is that we don't cover the Workloads and Orchestration pillars of Zero Trust and our report can generate more value to the users, especially enterprise ones.

The business value of this will be for the Enterprise cloud users and will be measured via download #s of this new version.

Scope

MH

• ScoutSuite findings show up in ZT report
• Minimal requirements added

NTH

• Extra documentation/enrichment on ScoutSuite findings

Out of scope

• Framework for integrating outside products (Infection Monkey as pen-testing framework)

Reference materials

https://github.com/nccgroup/ScoutSuite

Specific Components PDR

Information Gathering in the Monkeys

Functional requirements

Inputs: Collect Cloud info is configured. This will run ScoutSuite. The exact software boundaries between ScoutSuite and Infection Monkey will be discussed in the DDR including if and how to update our ScoutSuite fork.
Outputs: Telemetry, how many checks were performed, how many resources were found.
Logs + error logs

Quality Requirements

The setup MUST BE very clearly defined and documented so users can use this feature by adding the relevant AWS role to their EC2 machines. THIS MIGHT BE INSECURE.

Zero Trust Report

Functional requirements

Inputs: Cloud data from Monkeys via telemetries.
Outputs: Zero Trust Findings
Logs on telemetry parsing + errors

Quality Requirements

Performance must be unhindered with MANY findings. A 2000 findings report MUST be generated in under 7 seconds.

Checklist: Requirements

The requirements checklist contains a list of questions to ask yourself about your project’s requirements.

Use the list as a sanity check at construction time to determine how solid the ground that you’re standing on is—where you are on the requirements Richter scale. Not all of the checklist questions will apply to your project. If you’re working on an informal project, you’ll find some that you don’t even need to think about. You’ll find others that you need to think about but don’t need to answer formally. If you’re working on a large, formal project, however, you may need to consider every one.

Specific Functional Requirements

• Are all the inputs to the system specified, including their source, accuracy, range of values, and frequency?
• Are all the outputs from the system specified, including their destination, accuracy, range of values, frequency, and format?
• Are all output formats specified for Web pages, reports, and so on?
• Are all the external hardware and software interfaces specified?
• Are all the external communication interfaces specified, including handshaking, error-checking, and communication protocols?
• Are all the tasks the user wants to perform specified?
• Is the data used in each task and the data resulting from each task specified?

Specific Nonfunctional (Quality) Requirements

• Is the expected response time, from the user’s point of view, specified for all necessary operations?
• Are other timing considerations specified, such as processing time, datatransfer rate, and system throughput?
• Is the level of security specified?
• Is the reliability specified, including the consequences of software failure, the vital information that needs to be protected from failure, and the strategy for error detection and recovery?
• Are minimum machine memory and free disk space specified?
• Is the maintainability of the system specified, including its ability to adapt to changes in specific functionality, changes in the operating environment, and changes in its interfaces with other software?
• Is the definition of success included? Of failure?

Requirements Quality

• Are the requirements written in the user’s language? Do the users think so?
• Does each requirement avoid conflicts with other requirements?
• Are acceptable tradeoffs between competing attributes specified—for example, between robustness and correctness?
• Do the requirements avoid specifying the design?
• Are the requirements at a fairly consistent level of detail? Should any requirement be specified in more detail? Should any requirement be specified in less detail?
• Are the requirements clear enough to be turned over to an independent group for construction and still be understood? Do the developers think so?
• Is each item relevant to the problem and its solution? Can each item be traced to its origin in the problem environment?
• Is each requirement testable? Will it be possible for independent testing to determine whether each requirement has been satisfied?
• Are all possible changes to the requirements specified, including the likelihood of each change?

Requirements Completeness

• Where information isn’t available before development begins, are the areas of incompleteness specified?
• Are the requirements complete in the sense that if the product satisfies every requirement, it will be acceptable?
• Are you comfortable with all the requirements? Have you eliminated requirements that are impossible to implement and included just to appease your customer or your boss?