Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update waf rules to 1.5.0 version #2598

Merged
merged 2 commits into from
Feb 6, 2023
Merged

Conversation

GustavoCaso
Copy link
Member

@GustavoCaso GustavoCaso commented Feb 2, 2023

What does this PR do?

Update appsec waf rules to 1.5.0 version

  • The risky rules have been remove. I remove the file as well and all the mentions of risky in the code base
  • If a customer was using that level, we will automatically switch to :recommended and show a warning message

@GustavoCaso GustavoCaso requested a review from a team February 2, 2023 17:07
@github-actions github-actions bot added the appsec Application Security monitoring product label Feb 2, 2023
Comment on lines 105 to 109
@ruleset = case ruleset_setting
when :recommended, :risky, :strict
when :recommended, :strict
JSON.parse(Datadog::AppSec::Assets.waf_rules(ruleset_setting))
when String
JSON.parse(File.read(ruleset_setting))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in this way, this change seems like it can cause problems when upgrading -- a customer that previously used the risky ruleset will start getting an error when they upgrade between dd-trace-rb 1.9.0 and a later version.

Should we perhaps do something along the lines of: when customers pick risky, we instead choose the closest one for them (is that recommended or strict?), and also print a warning (maybe similar to this) saying that risky is now a no-op.

This way the upgrade experience is always smooth.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is a great point @ivoanjo

I'll ask the security folks for best closest alternative to risky and print a warning 😄

Thank for the feedback

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done b3465c9

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is a concern of me too.

@Taiki-San I think the removal of risky is a breaking change, which appears to run against the ruleset release SemVer 2.0 contract, WDYT?

@GustavoCaso GustavoCaso self-assigned this Feb 3, 2023
Copy link
Member

@ivoanjo ivoanjo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left a suggestion, but otherwise it LGTM 👍

Comment on lines 110 to 114
Datadog.logger.warn(
'Ignoring user-supplied ruleset `:risky`. That configuration value has been deprecated,'\
'selecting `:recommended`.'
)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Putting my user hat on, I think this message could be improved.


Imagine working on a rails app with a dozen other people. When you boot the app, there's a bunch of output scrolling: puma this, database that.

And then in between is this message:

WARN -- ddtrace: [ddtrace] Ignoring user-supplied ruleset :risky. That configuration value has been deprecated,selecting :recommended.

Would you know what to do, other than go read the ddtrace sources? Or maybe grepping by risky?

Here's a suggestion:

The :risky Application Security Management ruleset has been deprecated and no longer available. The :recommended ruleset will be used instead. Please remove the appsec.ruleset = :risky setting from your Datadog.configure block.

I think this message improves on the current one by:

  1. Identifying which component this is coming from. Helps googling, talking to support, etc.
  2. Documenting the next steps that customers should take to make this warning go away.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

has been deprecated

I feel this is incorrect, as usually "deprecation" would mean that it went through a grace period where it was still available.

An option would be to actually deprecate risky while keeping things at 1.4.2 for at least one ddtrace release. before we remove risky and move to 1.5.0 in a subsequent version.

This way there is no risk of breakage and users of risky can move towards either recommended or strict at their own discretion with due warning.

Copy link
Contributor

@lloeki lloeki left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm of two minds here, but I think I'd rather have a release with the deprecation warning about risky being removed in the next version, then update to 1.5.0 + remove risky and have that released.

So essentially:

  • open another PR that adds the deprecation warning
  • keep this PR up as "do not merge" until a release with the warning has been published

WDYT @ivoanjo @GustavoCaso ?

@ivoanjo
Copy link
Member

ivoanjo commented Feb 3, 2023

I think this is one case where the final decision is on your side.

My input is that I think these kinds of decisions should be done on a case-by-case basis, and on this specific case I think it's fine to go ahead with this PR. I think it's a plus that this PR gets customers on our current recommended configuration faster, vs having them stay for longer on an outdated version of the ruleset.

@GustavoCaso
Copy link
Member Author

@ivoanjo Thanks so much for the feedback on the error message. Now it is much better and actionable from the point of view of a customer 👍

@lloeki I'm on the same side as Ivo. I think we should be good to ship this PR. Is less work for us to maintain and the fact that customer might be using risky and is a list of rules unmaintained might lead to problems in the future.

Copy link
Contributor

@lloeki lloeki left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds fair enough. Approving.

@GustavoCaso GustavoCaso merged commit c3fbc20 into master Feb 6, 2023
@GustavoCaso GustavoCaso deleted the update-waf-rules-to-1.5.0 branch February 6, 2023 11:56
@github-actions github-actions bot added this to the 1.10.0 milestone Feb 6, 2023
@TonyCTHsu TonyCTHsu mentioned this pull request Mar 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
appsec Application Security monitoring product
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants