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.

Sign up for GitHub

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

[SIEM] Adds ECS link to help menu #57104

Merged
merged 6 commits into from
Feb 10, 2020
Merged

[SIEM] Adds ECS link to help menu #57104

Changes from 2 commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
282b124
Adds ECS link to help menu
spong Feb 7, 2020
6d9c231
Open all help links in new window
spong Feb 7, 2020
ef981b7
Fixing siem/ecs version mismatch in doc url
spong Feb 7, 2020
d56c8f8
Merge branch 'master' into add-ecs-help-link
elasticmachine Feb 7, 2020
bdd4c33
Merge branch 'master' into add-ecs-help-link
elasticmachine Feb 7, 2020
5d98b2b
Merge branch 'master' into add-ecs-help-link
elasticmachine Feb 10, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 14 additions & 0 deletions x-pack/legacy/plugins/siem/public/components/help_menu/index.tsx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,10 +24,24 @@ export const HelpMenu = React.memo(() => {
href: docLinks.links.siem.guide,
iconType: 'documents',
linkType: 'custom',
target: '_blank',
rel: 'noopener',
},
{
content: i18n.translate('xpack.siem.chrome.helpMenu.documentation.ecs', {
defaultMessage: 'ECS documentation',
}),
href: `${docLinks.ELASTIC_WEBSITE_URL}guide/en/ecs/${docLinks.DOC_LINK_VERSION}/index.html`,
Copy link

Choose a reason for hiding this comment

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

What's the value of DOC_LINK_VERSION here? If this is the stack version, this will 404. If you're maintaining a mapping between SIEM versions and ECS versions, I still think this is risky.

I think the simplest approach would likely be best, here, and simply link to "current".

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's right! Forgot about that 🤦‍♂ Thanks @webmat! Will update to just be current.

As an aside, is there anywhere we maintain a mapping to what the current ECS version is at the time of Kibana/SIEM releases?

Copy link

@webmat webmat Feb 7, 2020 •
edited
Loading

Choose a reason for hiding this comment

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

is there anywhere we maintain a mapping to what the current ECS version is at the time of Kibana/SIEM releases?

Short answer: not that I know of.

Long answer :-)

I don't necessarily think it's a good idea to even try to track a mapping between different versions. Here's why:

Right now Beats declares globally an ECS version for all sources at every product version, and puts that in all event's ecs.version field. This happens in libbeat, whether or not a given source was adjusted to recent additions in ECS.

From the beginning I've tried to advocate for setting the appropriate ECS version per source, and adjust it only when the source is modified to adjust to new developments in ECS. It was deemed too much maintenance initially, but the current "global ECS version" has been causing confusion. So the discussion is on the table again: elastic/beats#16089.

If we go the direction of declaring a more precise ECS version per source, then mapping between a product version and an ECS version becomes moot.

All of this complexity would be unnecessary if we upgraded all sources in lockstep with new developments in ECS. But that hasn't been happening so far.

For similar reasons to Beats, I'm not sure I'd try to maintain a mapping between Elastic SIEM and ECS.

Perhaps SIEM upgrading all visualizations and queries in lockstep with ECS is easier than the Beats situation, I don't know. If so, then we could maintain that and publish it somehow.

I actually don't know if there's already such a mapping anywhere in SIEM.

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks for the details + history @webmat -- this is helpful 🙂

Upgrading our visualizations/queries in lockstep with ECS sounds like the right path forward, and feels in line with what we did during initial development. There were often ECS fields that visualizations were using that beats hadn't been updated to utilize yet (asn comes to mind), and so that field would just be empty till the beat supported it, but the visualization would at least be in sync with ECS and ready to ship.

As for any such version mapping within SIEM itself, I don't believe there is. We do however maintain a few ECS field mappings like here and here though, which is a process that could probably use a revisit to ensure we're staying in sync with each ECS release as they happen.

iconType: 'documents',
linkType: 'custom',
target: '_blank',
rel: 'noopener',
},
{
linkType: 'discuss',
href: 'https://discuss.elastic.co/c/siem',
target: '_blank',
rel: 'noopener',
},
],
});
Expand Down