cisco_asa: add handling of AAA operations

[efd6]

What does this PR do?

This adds handling of authentication fields for Cisco ASA AAA message types.

Checklist

• I have reviewed tips for building integrations and this pull request is aligned with them.
• I have verified that all data streams collect metrics or logs.
• I have added an entry to my package's changelog.yml file.
• I have verified that Kibana version constraints are current according to guidelines.

Author's Checklist

• [ ]

How to test this PR locally

Related issues

• Updates Filebeat Cisco ASA module - add ECS authentication fields for SIEM beats#32257
• Closes cisco_asa: vpn authentication rejected messages #3852

Screenshots

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2022-08-02T22:36:18.019+0000

• Duration: 19 min 57 sec

Test stats 🧪

Test	Results
Failed	0
Passed	29
Skipped	0
Total	29

🤖 GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

[elasticmachine]

🌐 Coverage report

Name	Metrics % (covered/total)	Diff
Packages	100.0% (1/1)	💚
Files	100.0% (1/1)	💚 2.868
Classes	100.0% (1/1)	💚 2.868
Methods	94.444% (17/18)	👍 5.2
Lines	65.161% (1197/1837)	👎 -25.438
Conditionals	100.0% (0/0)	💚

[elasticmachine]

Pinging @elastic/security-external-integrations (Team:Security-External Integrations)

[leweafan]

@efd6 seems like even.outcome always "success" but for failed authentications it should be "failure".

[efd6]

@leweafan Yeah, this can be confusing. Success is always a contextual thing; from the perspective of the attempting authenticator, a failure to auth is a failure, but if this entity is malicious it is a success for the people who matter. So in the ECS definition you can see

event.outcome simply denotes whether the event represents a success or a failure from the perspective of the entity that produced the event.

The entity that produced the event is the device and it must have confidence in its decisions, so all authentications that have a definitive answer are successful. If there were a failure due to a network or identity store problem, those would be failures.

You can use event.type and event.action to determine whether the login was successful.

It looks like there is some confusion/ambiguity around this. I am looking into it further.

[leweafan]

@efd6 event.outcome is very important for SIEM cause if we go to Sercurity -> Hosts -> Authentications there is a graph for successful and failed attempts and a table representation with users their 'Successes'/'Failures'/'Last failure'/'Last failed source'/'Last failed destination' that depend on event.outcome = "failure". Please find screenshots in attachments.
Also according to ECS documentation https://www.elastic.co/guide/en/security/current/siem-field-reference.html

[efd6]

Yes, having had a look at the background discussion, this appears to be the original intention. I will make this change.

[efd6]

@leweafan Please also take a look at #3750.

[leweafan]

@efd6 answered a minute before to andrewkroh about checkpoint version in another issue elastic/beats#32230

[efd6]

@leweafan Thanks for that, I was also thinking you might like to confirm the orientation of success/failure in that PR.

[leweafan]

@efd6 looks good

[efd6]

/test