Workflows

RAWRR has been based on the workflows proposed by the SAFETAG methodology. These are intended to provide a structure capable of including multiple types of security interventions through stages, some of which may be optional. The only steps that are required during the assessment are the pre-assessment activities, the development of recommendations, and the preparation of a report.

These stages are briefly described below with the aim of offering people who wish to use RAWRR a broader context based on the methodological basis that was used to develop the program. For more information on workflows and, in general, on how to carry out security audits or interventions under the SAFETAG methodology, we recommend visiting https://safetag.org/.

Pre-assessment activities may include the selection of the organization, initial interviews, investigation of the context, logistics, planning and, especially, definition of the activities to be carried out during the intervention. This step is necessary for all assessment interventions, even if the depth and breadth changes from case to case. These activities may or may not be loaded into RAWRR, but it is often impossible to do an intervention without doing pre-assessment activities.

During this activity, the evaluator models the “base structure”, which we define as the initial set of items from which the rest of the intervention can emerge. Some examples of base structures may include:

• Basic Threat List: threats identified by the organization and the evaluator.
• Risk matrix: Threats mapped with probability of occurrence and potential impact.
• Security objectives: initial objectives of the intervention, such as “securing the organization’s communications” or “protecting the website”.
• List of assets: hardware, software and other resources used by the organization that may be susceptible to being compromised.

Our primary focus has been to use the base structure of the “risk matrix”, as we have found that it works best to identify the priorities of the organization. This step is recommended, but not required.

During this step, activities are carried out in order to collect information from the organization. These may include in-depth interviews with area coordinators, additional data / asset / adversary mapping, and technical scans. The results of these activities are documented and serve as input for the next step. This step is recommended, but not required.

From the modeling of the base structure and the execution of evaluation activities, a series of vulnerabilities can be obtained. During this step, they are specified, referenced, and linked to the activities that generated them and the related core structure elements (such as threats / risks). This step is recommended, but not required.

During this step, the evaluator develops a series of suggested actions for the organization to take to increase its security. They can be very specific (“update plugin x on website”) or very vague (“Write and implement a security policy regarding X”), depending on the style of the tester and the nature of the organization. This step is mandatory. Security interventions can be performed without recommendations, but our position is that the goal should always be to have an impact on the security of the organization and recommendations are one of the best ways to achieve this.

During this step the evaluator orders and prioritizes the recommendations from step 5 in a manner consistent with predefined criteria such as impact, ease of implementation, organizational objectives, and personal preference. This step is recommended, but not required.

During this step the document or documents to be delivered to the organization are developed. Options such as the number of reports, the target audiences and the information to include are made here. This step is mandatory, as a report is the main way of communicating the results of an assessment. This does not preclude questioning, oral presentations, or other ways of transmitting information.