Implement default, description, title, minimum, maximum and schema validation where appropriate

If the graph call fails for a user for any reason it is presently unhandled

Check entity type for related alerts in Sentinel, input entities, entity type to check, incident arm id (to filter out linked alerts) and timeframe to look back

Leverage the FileProfile() function from Defender to return the prevalance of a file (as well as other meta data).

Allow for deploying all modules from one template

I tried calling some of the modules and when I parsed the output using parse json it wasn't obvious what properties were in an array.

We need to see if we can add some descriptions to the schema to make it more clear, if not perhaps make the names more obvious

Build a shared module to handle entity processing to provide consistent results. This is particularly important for the account entity where UPN and/or Azure AD Id are not always included in the entity, but are needed by much of the automation.

Proposed sample return:

{
    "AccountsAllValid": false,
    "AccountsInput": 4,
    "AccountsValid": 3,
    "Accounts": [
        {
            "AADId": "",
            "DistinguishedName": "",
            "objectSID": "",
            "UserPrincipalName": ""
        }
    ],
    "IPsAllValid": true,
    "IPsInput": 1,
    "IPsValid": 1,
    "IPs": [
        {
            "Address": ""
        }
    ],
    "HostsAllValid": true,
    "HostsInput": 0,
    "HostsValid": 0,
    "Hosts": []
}

title and description need to be reversed.

On the key vault Get MCAS API secret step, set that logic app step to Secure Outputs... otherwise the API key will be logged in the logic app run history

As I am rewrite the MCAS and MDE modules, I wonder. Would the goal to use it in every Module? Or before calling a any module?

I guess it would make sense to call it before calling any module as it would avoid duplicate work. But then it changes the input for the existing modules (well the existing module have to change anyway, whether it is to add the call to the shared module or to change the input parameter in the trigger).

I see pro and cons for both.

The current logic is very cumbersome. It can be redone with the foolowing assumption:

• There are nearly never account entities with only the aadUserId
• Most of account entities will have an AccountName

Should we switch to user assigned managed identity? Sharing one identity across all the modules has some benefit in that it would simplify permissions assignment as the identity is shared but there could also be downsides.

Get-MCASInvestigationPriority
Input

• The username or userid and look up the Investigation priority in MCAS as well as the Investigation priority history
• ARM Incident ID to add results into an comment

Requirements

• URL of the API (depends on the location and tenant name)
• Token API
• Key Vault to safely store the Token

Evaluate the risk of the users signin activity, considering risk status, named locations, MFA, Conditional Access, etc

Build module to check watchlists, inputs will include entity data, entity type to check, watchlist name, watchlist column

The logic app resource is missing a dependency on the API connection.
I suggest adding:

"dependsOn": [ "[resourceId('Microsoft.Web/connections', variables('AzureSentinelConnectionName'))]" ],

Add schema for the returned JSON to make it easier to use with Parse JSON step in calling logic app

@briandelmsft Should we add the status of the user such as "IsEnabled" : true or something of the sort? It's not used on other module (yet?) but it could be usefull I guess. Nope?

If we are not successful in the first attempt we stop, despite the entity potentially succeeding via another method. For example if an email is provided as a upn and the do not match it will fail

Ensure minimum return schema is passed by module

{
	"AnalyzedEntities": 0,
	"DetailedResults": [],
	"RapidTriage": "Passed/Failed"
}

Ensure minimum return schema is passed by module

{
	"AnalyzedEntities": 0,
	"DetailedResults": [],
	"RapidTriage": "Passed/Failed"
}

Implement default, description, title, minimum, maximum and schema validation where appropriate

Implement default, description, title, minimum, maximum and schema validation where appropriate

Document the return schema so it is easier to work with in calling logic app

Ensure minimum return schema is passed by module

{
	"AnalyzedEntities": 0,
	"DetailedResults": [],
	"RapidTriage": "Passed/Failed"
}

• Add Incident ARM Id to return Schema
• Workspace Id

Ensure minimum return schema is passed by module

{
	"AnalyzedEntities": 0,
	"DetailedResults": [],
	"RapidTriage": "Passed/Failed"
}

Get the level of risk of devices onbaorded in MDE where the accounts have logged-in in the last x days.

Implement default, description, title, minimum, maximum and schema validation where appropriate

Ensure minimum return schema is passed by module

{
	"AnalyzedEntities": 0,
	"DetailedResults": [],
	"RapidTriage": "Passed/Failed"
}

Ensure minimum return schema is passed by module

{
	"AnalyzedEntities": 0,
	"DetailedResults": [],
	"RapidTriage": "Passed/Failed"
}

Build a sample showing how to use multiple modules together

If no accounts are present in the entities list it needs to be handled