Refine module return schema about sentinelautomationmodules HOT 9 CLOSED

Adding a description element to the return schema will make selecting the outputs easier:

from sentinelautomationmodules.

{
    "properties": {
        "OverallOOFStatus": {
            "type": "string",
            "description": "Overall OOF Status of all User Entities"
        },
        "PerUserStatus": {
            "description": "Array of OOF Status by User",
            "items": {
                "properties": {
                    "OOFStatus": {
                        "type": "string"
                    },
                    "UPN": {
                        "type": "string"
                    }
                },
                "type": "object"
            },
            "type": "array"
        }
    },
    "type": "object"
}

from sentinelautomationmodules.

@piaudonn keep this in mind for the return schemas

from sentinelautomationmodules.

Will do. And quite frankly, all names I have picked so far are tentative (even the modules' names). I am fully open to suggestions. Also it would be nice to have some consistency across modules for name and returns objects (especially when the type of data is similar).

from sentinelautomationmodules.

Completely agree, same with me as well

from sentinelautomationmodules.

Maybe we should have a generic property that is always return with a value.
Something like "RapidTriage": "true" or "false".
This property is also returned when there are no entities to parse, could be "true". The idea is to faciliate the handling of the return results. If it is "true" we can do a quick triage and discard the incident (or do the automation for non-risky situations). If it is "false" then no automatic triage but we can add in the comment the why and the caller can still do fine tuning. Anyhow, always having the generic property would be practical.
It doesn't have to replace the current schema. For example, for the OOFModule, we can still return OverallOOFStatus, but also the RapidTrige bool.

from sentinelautomationmodules.

I like that a lot, it may get a bit tricky in some modules so we'll need to think on how, but the consistency is important. One concern would be the Watchlist module... sometimes being on the watchlist is good.... sometimes not so if an item is on the watchlist how would we return it? I guess true could simply be that 'something' was found and it would be up to the caller to handle.

we'll also need to address consistency in errors, we should return a property in both success and error cases that is the same (so the JSON parse works for both cases), something like ResultStatus or ModuleStatus or... and then a simple success/fail string? Also do we send back a 4xx/5xx or a 200 in those error cases. I'm leaning towards some error code

from sentinelautomationmodules.

For the watchlist, we could use a trigger paramter that says if you want to check if the object is in the watchlist or not.

Let's talk soon!

from sentinelautomationmodules.

Each module will follow similar structure with the array of detailed data always being called DetailedResults,
Must have some form of EntitiesAnalyzed EntitiesMatching and EntitiesMatchingPercent

Sample Module return:

{
    "AllEntitiesHaveRelatedAlerts": false,
    "AnyEntitiesHaveRelatedAlerts": true,
    "DetailedResults": [],
    "EntitiesAnalyzed": 2,
    "EntitiesWithRelatedAlerts": 1,
    "EntitiesWithRelatedAlertsPercent": 0.5
}

from sentinelautomationmodules.