🥶 Information security risk analysis: why do we need risks?

So let's get started

This process - Risk Analysis, describes the practice of Shift Left (early involvement) at the design stages (we'll also see how this works later?), developing a technical solution and making changes to the architecture already at the operation stage.

Risk Analysis serves as a source of requirements for the team within the Lean-Agile approach when developing a product or project. This approach is especially useful and relevant when assessing the impact of features on business logic.

It allows:

• Control the scaling of the product and resulting problems in incidents (oh no), additional costs for urgency, regulatory requirements, sanctions and other

• Timely identify and cover problems with direct, collateral damage to the business, as well as unacceptable events

• Work out risk mitigation measures

• Determine the minimum sufficient amount of input and output data

One of the most frequently asked questions on projects:

“How can we explain to businesses that our AppSec is needed and not just slowing down releases?”

The answer is simple - through the influence of these information security risks on the final product and reducing its final value to the consumer. But if you just throw in your face “the vulnerability is critical, it needs to be fixed,” you will hear the eternal: “there is no budget,” “let’s get into technical debt,” “we don’t consider this a problem,” “we have never experienced problems,” “it won’t affect us.”

This is why information security risk analysis is needed - a language that is equally understood by developers, business, and us as engineers.

Basic steps:

1. Identify where it can arrive: feature, change in infrastructure specification, change in processes, new people.

2. Classify - describe (vulnerability description), by source of occurrence (threat description), impact (scenario impact description).

If necessary, group, determine the implementation vector, to what extent the vulnerability is sane for the product, and then work out PRE-measures (mandatory conditions before delivery to the production environment - namely critics, blockers), POST-measures (which can be eliminated subsequently)3. Rate - probability (0 to 1) × damage × elimination × impact = level of risk. Predictive metrics (for example, % of closed findings before release) and classic legging metrics (primary and base approach) help here.

4. Compare with business functions that are either changes to a technical solution, or affecting components, functions, API endpoints, etc.

5. Make a decision depending on the principle of working with risks: acceptance, refusal, delegation, minimization

What does it give:

1. Conversation with business in clear terms (“losses”, “TTM”, “stop factor”)

2. Prioritization (we don’t fix everything, but what really matters in terms of money/time)

3. Transparency: the team understands why fixing these particular tasks is important

The mistake of many companies is the lack of competent and understandable monitoring, namely the grouping of vulnerabilities and the impact on product risks.

Working approach: map of risks of the Critical, Medium level with assessment and measures to reduce them.

Conceptual example: devops needs to monitor a critical service, for this they need to understand what and when can fail in order to track a denial of service incident in time. Consequently, a very cool thought appears: “let’s send notifications to ourselves in a common chat like a cart?” The idea is very powerful and cool, but for example, for the fintech sector there may be reasonable risks caused, such as.. (see picture of the post). We need to think about what measures will reduce the risks of information security, this could be a link to an internal proxy with 2fa, cleaning logs in the channel, moderating with a bot, using channel encryption (WSO2? We’ll look at it), DAM, depersonalizing/masking sensitive data, preparing predefined templates, etc. This approach either reduces risks or gives the business insight for real responsibility.

Conclusion: this is why it is important to evaluate the correct use of certain features and give them an assessment of the impact of the resulting information security risks.

#riskanalys #pmi #compliance #pmcases #techsolution