Section 7 – Design a strategy for data and applications – Specify security requirements for applications and design a strategy for securing data

And there you have it, this is the last section in my study guide. This time made longer posts, hopefully they weren’t too long to read.

Stay tuned for more!

• Specify priorities for mitigating threats to applications.
• Specify a security standard for onboarding a new application.
• Specify a security strategy for applications and APIs.
• Specify priorities for mitigating threats to data.
• Design a strategy to identify and protect sensitive data.
• Specify an encryption standard for data at rest and in motion.

Specify priorities for mitigating threats to applications

Classify applications

Risk	Mitigation	Examples
High Potential Impact	Identify applications that would have a significant impact on the business if compromised.	Business critical data: Applications that process or store information, which would cause significant negative business or mission impact if assurance of confidentiality, integrity, or availability is lost.
		Regulated data: Applications that handle monetary instruments and sensitive personal information are regulated by standards. For example, the payment card industry (PCI) and Health Information Portability and Accountability Act (HIPAA).
		Business critical availability: Applications whose functionality is critical to the organization’s business mission, such as production lines generating revenue, devices or services critical to life and safety, and other critical functions.
		Significant Access: Applications that have access to systems with a high potential impact through technical means such as Stored Credentials or Permissions granted via access control lists or other means.
High exposure to attacks	Applications that are easily accessible to attackers, such as web applications on the open Internet.

Microsoft Security Development Lifecycle uses STRIDE.

Stride model

Category	Description
Spoofing	Involves illegally accessing and then using another user's authentication information, such as username and password
Tampering	Involves the malicious modification of data. Examples include unauthorized changes made to persistent data, such as that held in a database, and the alteration of data as it flows between two computers over an open network, such as the Internet
Repudiation	Associated with users who deny performing an action without other parties having any way to prove otherwise—for example, a user performs an illegal operation in a system that lacks the ability to trace the prohibited operations. Non-Repudiation refers to the ability of a system to counter repudiation threats. For example, a user who purchases an item might have to sign for the item upon receipt. The vendor can then use the signed receipt as evidence that the user did receive the package
Information Disclosure	Involves the exposure of information to individuals who are not supposed to have access to it—for example, the ability of users to read a file that they were not granted access to, or the ability of an intruder to read data in transit between two computers
Denial of Service	Denial of service (DoS) attacks deny service to valid users—for example, by making a Web server temporarily unavailable or unusable. You must protect against certain types of DoS threats simply to improve system availability and reliability
Elevation of Privilege	An unprivileged user gains privileged access and thereby has sufficient access to compromise or destroy the entire system. Elevation of privilege threats include those situations in which an attacker has effectively penetrated all system defenses and become part of the trusted system itself, a dangerous situation indeed

OWASP

NIST Secure Software Development Framework (SSDF)

Microsoft Threat Modeling Tool

What it is?

The Microsoft Threat Modeling Tool 2018 was released as GA in September 2018 as a free click-to-download. The change in delivery mechanism allows us to push the latest improvements and bug fixes to customers each time they open the tool, making it easier to maintain and use. This article takes you through the process of getting started with the Microsoft SDL threat modeling approach and shows you how to use the tool to develop great threat models as a backbone of your security process.

Download here https://aka.ms/threatmodelingtool and install

Once done, the application main page will open

Choose create a model you will see templates that can be used

Analyzing threats

Once he clicks on the analysis view from the icon menu selection (file with magnifying glass), he is taken to a list of generated threats the Threat Modeling Tool found based on the default template, which uses the SDL approach called STRIDE (Spoofing, Tampering, Info Disclosure, Repudiation, Denial of Service and Elevation of Privilege). The idea is that software comes under a predictable set of threats, which can be found using these 6 categories.

Web Application Security Framework

Category	Description
Auditing and Logging	Who did what and when? Auditing and logging refer to how your application records security-related events
Authentication	Who are you? Authentication is the process where an entity proves the identity of another entity, typically through credentials, such as a user name and password
Authorization	What can you do? Authorization is how your application provides access controls for resources and operations
Communication Security	Who are you talking to? Communication Security ensures all communication done is as secure as possible
Configuration Management	Who does your application run as? Which databases does it connect to? How is your application administered? How are these settings secured? Configuration management refers to how your application handles these operational issues
Cryptography	How are you keeping secrets (confidentiality)? How are you tamper-proofing your data or libraries (integrity)? How are you providing seeds for random values that must be cryptographically strong? Cryptography refers to how your application enforces confidentiality and integrity
Exception Management	When a method call in your application fails, what does your application do? How much do you reveal? Do you return friendly error information to end users? Do you pass valuable exception information back to the caller? Does your application fail gracefully?
Input Validation	How do you know that the input your application receives is valid and safe? Input validation refers to how your application filters, scrubs, or rejects input before additional processing. Consider constraining input through entry points and encoding output through exit points. Do you trust data from sources such as databases and file shares?
Sensitive Data	How does your application handle sensitive data? Sensitive data refers to how your application handles any data that must be protected either in memory, over the network, or in persistent stores
Session Management	How does your application handle and protect user sessions? A session refers to a series of related interactions between a user and your Web application

Reports

After you finish changing priorities and updating the status of each generated threat, you can save the file and/or print out a report. Go to Report > Create Full Report.

Threat model section

Component	Details
Feedback, Suggestions and Issues Button	Takes you the MSDN Forum for all things SDL. It gives you an opportunity to read through what other users are doing, along with workarounds and recommendations. If you still can’t find what you’re looking for, email tmtextsupport@microsoft.com for our support team to help you
Create a Model	Opens a blank canvas for you to draw your diagram. Make sure to select which template you’d like to use for your model
Template for New Models	You must select which template to use before creating a model. Our main template is the Azure Threat Model Template, which contains Azure-specific stencils, threats and mitigations. For generic models, select the SDL TM Knowledge Base from the drop-down menu. Want to create your own template or submit a new one for all users? Check out our Template Repository GitHub Page to learn more
Open a Model	Opens previously saved threat models. The Recently Opened Models feature is great if you need to open your most recent files. When you hover over the selection, you’ll find 2 ways to open models:Open From this Computer – classic way of opening a file using local storageOpen from OneDrive – teams can use folders in OneDrive to save and share all their threat models in a single location to help increase productivity and collaboration
Getting Started Guide	Opens the Microsoft Threat Modeling Tool main page

Security services from Microsoft

Infrastructure & Network
Azure Firewall	A cloud-native and intelligent network firewall security service that provides threat protection for your cloud workloads running in Azure. It’s a fully stateful firewall as a service with built-in high availability and unrestricted cloud scalability. Azure Firewall is offered in two SKUs: Standard and Premium.
Azure Service Bus	A fully managed enterprise message broker with message queues and publish-subscribe topics. Service Bus is used to decouple applications and services from each other.
Web Application Firewall	Provides centralized protection of your web applications from common exploits and vulnerabilities. WAF can be deployed with Azure Application Gateway and Azure Front Door.
Azure Policy	Helps to enforce organizational standards and to assess compliance at-scale. Through its compliance dashboard, it provides an aggregated view to evaluate the overall state of the environment, with the ability to drill down to the per-resource, per-policy granularity. It also helps to bring your resources to compliance through bulk remediation for existing resources and automatic remediation for new resources.

Specify a security standard for onboarding a new application

DevOps

What is DevOps?

DevOps is a continuous model that discards the old Waterfall model. It uses continuous integration and continuous delivery (CI/CD) pipelines, deployment is done with Infrastructure as code (IaC)

What is CI?

Continuous integration (CI) is the process of automatically building and testing code every time a team member commits code changes to version control. A code commit to the main or trunk branch of a shared repository triggers the automated build system to build, test, and validate the full branch. CI encourages developers to share their code and unit tests by merging their changes into the shared version control repository every time they complete a task.

What is CD?

Continuous delivery (CD) is the process of automating build, test, configuration, and deployment from a build to a production environment. A release pipeline can create multiple testing or staging environments to automate infrastructure creation and deploy new builds. Successive environments support progressively longer-running integration, load, and user acceptance testing activities.

What is IaC?

Infrastructure as code (IaC) uses DevOps methodology and versioning with a descriptive model to define and deploy infrastructure, such as networks, virtual machines, load balancers, and connection topologies. Just as the same source code always generates the same binary, an IaC model generates the same environment every time it deploys.

Why should you use DevOps?

When you use DevOps process, you will get the following benefits:

• Shift to Agile mindset
• You can deploy to a test environment and once done, deploy the same code to production.
• You are deploying small pieces of code not everything all the the time.
• Easier debugging
• Faster fixes for issues because of Continuous Testing
• Using what you want to the code, example with Bicep you can get more for less, see below for a example between ARM and Bicep.

ARM-teplate

Bicep-template

DevSecOps

When building a DevOps process, build it secure from the get go. There is a lot of components that could provide a interface for attackers and because all is automated, you don’t even necessarily find out compromised services or accounts quite easily and fast.

Specify a security strategy for applications and APIs

Best practices

When registering an application in Azure Active Directory (Azure AD), security is a key concept and a crucial component of the application’s business use in the organization. Any application misconfiguration might lead to downtime or security breaches. An application’s permissions settings may have an organization-wide impact.

Microsoft has made a collection of the best practices for applications and APIs

Why do applications integrate with Azure AD?

Add applications to Azure AD to leverage one or more of the services it provides, including:

• Application authentication and authorization.
• User authentication and authorization.
• Single sign-on (SSO) using federation or password.
• User provisioning and synchronization.
• Role-based access control: Use the directory to define application roles to perform role-based authorization checks in an application.
• OAuth authorization services: Used by Microsoft 365 and other Microsoft applications to authorize access to APIs/resources.
• Application publishing and proxy: Publish an application from a private network to the internet.
• Directory schema extension attributes: Extend the schema of service principal and user objects to store additional data in Azure AD.

Who can sign in to your app?

Audience	Single/multi-tenant	Who can sign in
Accounts in this directory only	Single tenant	All user and guest accounts in your directory can use your application or API. Use this option if your target audience is internal to your organization.
Accounts in any Azure AD directory	Multi-tenant	All users and guests with a work or school account from Microsoft can use your application or API. This includes schools and businesses that use Microsoft 365. Use this option if your target audience is business or educational customers.
Accounts in any Azure AD directory and personal Microsoft accounts (such as Skype, Xbox, Outlook.com)	Multi-tenant	All users with a work or school, or personal Microsoft account can use your application or API. It includes schools and businesses that use Microsoft 365 as well as personal accounts that are used to sign in to services like Xbox and Skype. Use this option to target the widest set of Microsoft accounts.

What are service principals and where do they come from?

You can manage service principals in the Azure portal through the Enterprise Applications experience. Service principals govern an application connecting to Azure AD and can be considered the instance of the application in your directory. Any given application can have at most one application object (which is registered in a “home” directory) and one or more service principal objects representing instances of the application in every directory in which it acts.

What are application objects and where do they come from?

You can manage application objects in the Azure portal through the App Registrations experience. Application objects define and describe the application to Azure AD, enabling Azure AD to know how to issue tokens to the application based on its settings. The application object will only exist in its home directory, even if it’s a multi-tenant application supporting service principals in other directories. 

Prerequisites

• An Azure account that has an active subscription. Create an account for free.
• The Azure account must have permission to manage applications in Azure Active Directory (Azure AD). Any of the following Azure AD roles include the required permissions:
  • Application administrator
  • Application developer
  • Cloud application administrator

Licensing

Free and basic Azure AD pricing tiers allow You to register 10 applications.

Azure AD Premium 1 and 2 allows registering unlimited apps per user.

Tenants to choose from

The app can be registered inside Azure AD and You have the tenant options.

• Work and school (Azure AD) accounts or Microsoft accounts (such as Outlook.com and Live.com)
• Social and local (Azure AD B2C) accounts

Limitations

• A maximum of 100 users and service principals can be owners of a single application.
• A user, group, or service principal can have a maximum of 1,500 app role assignments. The limitation is on the service principal, user, or group across all app roles and not on the number of assignments on a single app role.
• An app configured for password-based single sign-on can have a maximum of 48 groups assigned with credentials configured.
• A user can have credentials configured for a maximum of 48 apps using password-based single sign-on. This limit only applies for credentials configured when the user is directly assigned the app, not when the user is a member of a group which is assigned.
• A maximum of 1,200 entries can be added to the application manifest.

Validation differences by supported account types

When registering an application with the Microsoft identity platform for developers, you’re asked to select which account types your application supports. In the application object and manifest, this property is signInAudience.

The options include the following values:

• AzureADMyOrg: Only accounts in the organizational directory where the app is registered (single-tenant).
• AzureADMultipleOrgs: Accounts in any organizational directory (multi-tenant).
• AzureADandPersonalMicrosoftAccount: Accounts in any organizational directory (multi-tenant) and personal Microsoft accounts (for example, Skype, Xbox, and Outlook.com)

Validation differences for different property’s

Property	AzureAD MyOrg	AzureAD Multiple Orgs	AzureAD PersonalMicrosoftAccount and  Personal MicrosoftAccount
Application ID URI (identifierURIs)	Must be unique in the tenant urn:// schemes are supported Wildcards aren’t supported Query strings and fragments are supported Maximum length of 255 characters No limit* on number of identifierURIs	Must be globally unique urn:// schemes are supported Wildcards aren’t supported Query strings and fragments are supported Maximum length of 255 characters No limit* on number of identifierURIs	Must be globally unique urn:// schemes aren’t supported Wildcards, fragments, and query strings aren’t supported Maximum length of 120 characters Maximum of 50 identifierURIs
Certificates (keyCredentials)	Symmetric signing key	Symmetric signing key	Encryption and asymmetric signing key
Client secrets (passwordCredentials)	No limit*	No limit*	If liveSDK is enabled: Maximum of two client secrets
Redirect URIs (replyURLs)	See Redirect URI/reply URL restrictions and limitations for more info.
API permissions (requiredResourceAccess)	No more than 50 APIs (resource apps) from the same tenant as the application, no more than 10 APIs from other tenants, and no more than 400 permissions total across all APIs.	No more than 50 APIs (resource apps) from the same tenant as the application, no more than 10 APIs from other tenants, and no more than 400 permissions total across all APIs.	Maximum of 50 resources per application and 30 permissions per resource (for example, Microsoft Graph). Total limit of 200 per application (resources x permissions).
Scopes defined by this API (oauth2Permissions)	Maximum scope name length of 120 characters No limit* on the number of scopes defined	Maximum scope name length of 120 characters No limit* on the number of scopes defined	Maximum scope name length of 40 characters Maximum of 100 scopes defined
Authorized client applications (preAuthorizedApplications)	No limit*	No limit*	Total maximum of 500 Maximum of 100 client apps defined Maximum of 30 scopes defined per client
appRoles	Supported No limit*	Supported No limit*	Not supported
Front-channel logout URL	https://localhost is allowed http scheme isn’t allowed Maximum length of 255 characters	https://localhost is allowed http scheme isn’t allowed Maximum length of 255 characters	https://localhost is allowed, http://localhost fails http scheme isn’t allowed Maximum length of 255 characters Wildcards aren’t supported
Display name	Maximum length of 120 characters	Maximum length of 120 characters	Maximum length of 90 characters
Tags	Individual tag size must be between 1 and 256 characters (inclusive) No whitespaces or duplicate tags allowed No limit* on number of tags	Individual tag size must be between 1 and 256 characters (inclusive) No whitespaces or duplicate tags allowed No limit* on number of tags	Individual tag size must be between 1 and 256 characters (inclusive) No whitespaces or duplicate tags allowed No limit* on number of tags

Implement application registrations

Search for App registration

In this page You can register the application or show Your own endpoints that can be used for connecting to Your published applications.

When You create an application You can choose from different options.

These are supported account types that You can use. If You want to publish the app to Your own users, choose “In this directory only” and if You want to allow any external users, select “Any organizational directory.

Supported account types	Description
Accounts in this organizational directory only	Select this option if you’re building an application for use only by users (or guests) in your tenant. Often called a line-of-business (LOB) application, this app is a single-tenant application in the Microsoft identity platform.
Accounts in any organizational directory	Select this option if you want users in any Azure Active Directory (Azure AD) tenant to be able to use your application. This option is appropriate if, for example, you’re building a software-as-a-service (SaaS) application that you intend to provide to multiple organizations. This type of app is known as a multitenant application in the Microsoft identity platform.
Accounts in any organizational directory and personal Microsoft accounts	Select this option to target the widest set of customers. By selecting this option, you’re registering a multitenant application that can also support users who have personal Microsoft accounts.
Personal Microsoft accounts	Select this option if you’re building an application only for users who have personal Microsoft accounts. Personal Microsoft accounts include Skype, Xbox, Live, and Hotmail

Redirect URI

A redirect URI is the location where the Microsoft identity platform redirects a user’s client and sends security tokens after authentication.

In a production web application, for example, the redirect URI is often a public endpoint where your app is running, like https://cloudpartnerdemo.fi/auth-response. During development, it’s common to also add the endpoint where you run your app locally, like https://127.0.0.1/auth-response or http://localhost/auth-response.

So now You app could look like this.

Configure application permissions

App scope

In the Expose and API You can add permissions for the application.

Application ID URI 

The App ID URI acts as the prefix for the scopes you’ll reference in your API’s code, and it must be globally unique. You can use the default value provided, which is in the form api://<application-client-id>, or specify a more readable URI like https://cloudpartnerdemo.fi/api.

Add a scope

From add a scope You can add permissions and who can consent to the permissions. Default is Admin only.

Once created, the scope will show in the page.

Client app

Next You will create a Client Demo app, This app will connect to the DemoApp we created in the earlier steps.

Then API permissions and Add a permissions

Go to My APIs to find the API we created in the earlier steps.

And You will see the Exposed permissions we created.

But You will see there is no consent for the app, click Grant admin consent

And select yes

ut if You don’t have Admin rights the Grant admin consent button is disabled if you aren’t an admin or if no permissions have been configured for the application. If you have permissions that have been granted but not yet configured, the admin consent button prompts you to handle these permissions. You can add them to configured permissions or remove them.

Platforms

Depending on the platform or device this application is targeting, additional configuration may be required such as redirect URIs, specific authentication settings, or fields specific to the platform.

Platform	Configuration settings
Web	Enter a Redirect URI for your app. This URI is the location where the Microsoft identity platform redirects a user’s client and sends security tokens after authentication. Select this platform for standard web applications that run on a server.
Single-page application	Enter a Redirect URI for your app. This URI is the location where the Microsoft identity platform redirects a user’s client and sends security tokens after authentication. Select this platform if you’re building a client-side web app by using JavaScript or a framework like Angular, Vue.js, React.js, or Blazor WebAssembly.
iOS / macOS	Enter the app Bundle ID. Find it in Build Settings or in Xcode in Info.plist. A redirect URI is generated for you when you specify a Bundle ID.
Android	Enter the app Package name. Find it in the AndroidManifest.xml file. Also generate and enter the Signature hash. A redirect URI is generated for you when you specify these settings.
Mobile and desktop applications	Select one of the Suggested redirect URIs. Or specify a Custom redirect URI. For desktop applications using embedded browser, we recommend https://login.microsoftonline.com/common/oauth2/nativeclient For desktop applications using system browser, we recommend http://localhost Select this platform for mobile applications that aren’t using the latest Microsoft Authentication Library (MSAL) or aren’t using a broker. Also select this platform for desktop applications.

Microsoft Graph

If You go browse App a permission again, You will see lot’s of different APIs. From here You could add permissions for Microsoft Graph.

You have to options to add permissions.

On-Behalf-Of flow (OBO)

OAuth 2.0 On-Behalf-Of-Flow (OBO) provides a use case where an application needs to call a service / Web API and then another service / Web API. The idea is to propagate the delegated user ID and permissions to the request chain. In order for the middle tier service to send authenticated requests to downstream services, it must protect the access token from the Microsoft ID platform on behalf of the user.

1. The client application makes a request to API A with token A (with an aud claim of API A).
2. API A authenticates to the Microsoft identity platform token issuance endpoint and requests a token to access API B.
3. The Microsoft identity platform token issuance endpoint validates API A’s credentials along with token A and issues the access token for API B (token B) to API A.
4. Token B is set by API A in the authorization header of the request to API B.
5. Data from the secured resource is returned by API B to API A, then to the client.

Specify priorities for mitigating threats to data

The Cyber Kill Chain®

Excellent read to understand what a Kill chain attack is the Cyber Kill Chain® which was developed by Lockheed Martin,  framework is part of the Intelligence Driven Defense® model for identification and prevention of cyber intrusions activity. The model identifies what the adversaries must complete in order to achieve their objective.

Parts of the chain:

• Reconnaissance
  The attacker selects a target, investigates it, and hunts for weaknesses.
• Weaponization
  Intruder creates malware intended to take advantage of the flaw
• Delivery
  The hacker uses a phishing email or another method to spread the software.
• Exploitation
  The target system sees the malware start to run.
• Installation
  The malware sets up a backdoor or other entrance that the attacker can use.
• Control and command
  The attacker gains ongoing access to the victim’s network and systems.
• Actions on the Goal
  End-goal actions, such as data theft, data manipulation, or data destruction, are started by the intruder.

More technical approach

The more technical approach comes from Nestori Syynimaa, who has been in the top Security researchers in Microsoft Security Response Center (MSRC) ranks.

Data protection with Microsoft products

Did you know that OneDrive and SharePoint can protect you against attackers content encryption?

Migrate your organization to the cloud

• Move user data to cloud solutions like OneDrive/SharePoint to take advantage of versioning and recycle bin capabilities.
• Educate users on how to recover their files by themselves to reduce delays and cost of recovery.
• Designate Protected Folders.

Review your permissions

• Discover broad write/delete permissions on file shares, SharePoint, and other solutions.
• Broad is defined as many users having write or delete permissions for business-critical data.
• Reduce broad permissions while meeting business collaboration requirements.
• Audit and monitor to ensure broad permissions don’t reappear.

Defender for Cloud

Detect cloud threats, compromised accounts, malicious insiders, and ransomware

Best practice: Tune Anomaly policies, set IP ranges, send feedback for alerts
Detail: Anomaly detection policies provide out-of-the-box user and entity behavioral analytics (UEBA) and machine learning (ML) so that you can immediately run advanced threat detection across your cloud environment.

Anomaly detection policies are triggered when there are unusual activities performed by the users in your environment. Defender for Cloud Apps continually monitors your users activities and uses UEBA and ML to learn and understand the normal behavior of your users. You can tune policy settings to fit your organizations requirements, for example, you can set the sensitivity of a policy, as well as scope a policy to a specific group.

• Tune and Scope Anomaly Detection Policies: As an example, to reduce the number of false positives within the impossible travel alert, you can set the policy’s sensitivity slider to low. If you have users in your organization that are frequent corporate travelers, you can add them to a user group and select that group in the scope of the policy.
• Set IP Ranges: Defender for Cloud Apps can identify known IP addresses once IP address ranges are set. With IP address ranges configured, you can tag, categorize, and customize the way logs and alerts are displayed and investigated. Adding IP address ranges helps to reduce false positive detections and improve the accuracy of alerts. If you choose not to add your IP addresses, you may see an increased number of possible false positives and alerts to investigate.
• Send Feedback for alertsWhen dismissing or resolving alerts, make sure to send feedback with the reason you dismissed the alert or how it’s been resolved. This information assists Defender for Cloud Apps to improve our alerts and reduce false positives.

For more information:

• Get instantaneous behavioral analytics and anomaly detection
• Working with IP ranges and tags
• Monitor alerts in Defender for Cloud Apps

Best practice: Detect activity from unexpected locations or countries
Detail: Create an activity policy to notify you when users sign in from unexpected locations or countries/regions. These notifications can alert you to possibly compromised sessions in your environment so that you can detect and remediate threats before they occur.
For more information:

• Threat protection policies

Best practice: Create OAuth app policies
Detail: Create an OAuth app policy to notify you when an OAuth app meets certain criteria. For example, you can choose to be notified when a specific app that requires a high permission level was accessed by more than 100 users.
For more information:

• OAuth app policies

Use the audit trail of activities for forensic investigations

Best practice: Use the audit trail of activities when investigating alerts
Detail: Alerts are triggered when user, admin, or sign-in activities don’t comply with your policies. It is important to investigate alerts to understand if there is a possible threat in your environment.

You can investigate an alert by selecting it on the Alerts page and reviewing the audit trail of activities relating to that alert. The audit trail gives you visibility into activities of the same type, same user, same IP address and location, to provide you with the overall story of an alert. If an alert warrants further investigation, create a plan to resolve these alerts in your organization.

When dismissing alerts, it’s important to investigate and understand why they are of no importance or if they are false positives. If there is a high volume of such activities, you may also want to consider reviewing and tuning the policy triggering the alert.
For more information:

• Activities

Secure IaaS services and custom apps

Best practice: Connect Azure, AWS and GCP
Detail: Connecting each of these cloud platforms to Defender for Cloud Apps helps you improve your threat detections capabilities. By monitoring administrative and sign-in activities for these services, you can detect and be notified about possible brute force attack, malicious use of a privileged user account, and other threats in your environment. For example, you can identify risks such as unusual deletions of VMs, or even impersonation activities in these apps.
For more information:

• Connect Azure to Microsoft Defender for Cloud Apps
• Connect AWS to Microsoft Defender for Cloud Apps
• Connect GCP to Microsoft Defender for Cloud Apps (Preview)

Best practice: Review security configuration assessments for Azure, AWS and GCP
Detail: Integrating with Microsoft Defender for Cloud provides you with a security configuration assessment of your Azure environment. The assessment provides recommendations for missing configuration and security control. Reviewing these recommendations helps you identify anomalies and potential vulnerabilities in your environment, and navigate directly in the relevant location in the Azure Security portal to resolve them.

AWS and GCP give you the ability to gain visibility into your security configurations recommendations on how to improve your cloud security.

Use these recommendations to monitor the compliance status and security posture of your entire organization, including Azure subscriptions, AWS accounts, and GCP projects.
For more information:

• Security configuration for Azure
• Security configuration for AWS
• Security configuration for GCP

Best practice: Onboard custom apps
Detail: To gain additional visibility into activities from your line-of-business apps, you can onboard custom apps to Defender for Cloud Apps. Once custom apps are configured, you see information about who’s using them, the IP addresses they are being used from, and how much traffic is coming into and out of the app.

Additionally, you can onboard a custom app as a Conditional Access App Control app to monitor their low-trust sessions.
For more information:

• Add custom apps to Cloud Discovery
• Onboard and deploy Conditional Access App Control for any app

Collection of services

Service	Description
Microsoft Defender for Cloud	Brings advanced, intelligent, protection of your Azure and hybrid resources and workloads. The workload protection dashboard in Defender for Cloud provides visibility and control of the cloud workload protection features for your environment.
Microsoft Sentinel	A scalable, cloud-native, security information event management (SIEM) and security orchestration automated response (SOAR) solution. Sentinel delivers intelligent security analytics and threat intelligence across the enterprise, providing a single solution for alert detection, threat visibility, proactive hunting, and threat response.
Identity & Access Management
Microsoft 365 Defender	A unified pre- and post-breach enterprise defense suite that natively coordinates detection, prevention, investigation, and response across endpoints, identities, email, and applications to provide integrated protection against sophisticated attacks.
	Microsoft Defender for Endpoint is an enterprise endpoint security platform designed to help enterprise networks prevent, detect, investigate, and respond to advanced threats.
	Microsoft Defender for Identity is a cloud-based security solution that leverages your on-premises Active Directory signals to identify, detect, and investigate advanced threats, compromised identities, and malicious insider actions directed at your organization.

Design a strategy to identify and protect sensitive data

Establish security baselines

M365

• All Office applications from creating child processes
• Executable content from email client and webmail
• Executable files from running unless they meet a prevalence, age, or trusted list criterion
• Execution of potentially obfuscated scripts
• JavaScript or VBScript from launching downloaded executable content
• Office applications from creating executable content
• Office applications from injecting code into other processes
• Office communication application from creating child processes
• Untrusted and unsigned processes that run from USB
• Persistence through Windows Management Interface (WMI) event subscription
• Credential stealing from the Windows local security authority subsystem (lsass.exe)
• Process creations originating from PSExec and WMI commands

Exchange

• Enable Microsoft Defender Antivirus email scanning.
• Use Microsoft Defender for Office 365 for enhanced phishing protection and coverage against new threats and polymorphic variants.
• Check your Office 365 email filtering settings to ensure you block spoofed emails, spam, and emails with malware. Use Defender for Office 365 for enhanced phishing protection and coverage against new threats and polymorphic variants. Configure Defender for Office 365 to recheck links on click and delete delivered mails in response to newly acquired threat intelligence.
• Review and update to the latest recommended settings for EOP and Defender for Office 365 security.
• Configure Defender for Office 365 to recheck links on click and delete delivered mails in response to newly acquired threat intelligence.

Locate your sensitive information

Identify the types and locations

The first task is to identify the types and locations of sensitive information in your tenant, which can include the following types:

• Sensitive
• Proprietary or intellectual property
• Regulated, such regional regulations that specify protection of personally identifying information (PII)
• IT recovery plans

For each type of sensitive information, determine the following:

• The use of the information to your organization
• A relative measure of its monetary value if it were held for ransom (such as high, medium, low)
• Its current location, such as a OneDrive or SharePoint folder or collaboration venue such as a Microsoft Teams team
• The current permissions, which consist of:
  • The user accounts who have access
  • The actions that are allowed to each account that has access

Implement strict permissions

Once a ransomware attacker has infiltrated your tenant, they try to escalate their privileges by compromising the credentials of user accounts with wider scopes of permissions across your tenant, such as administrator role accounts or user accounts that have access to sensitive information.

Based on this typical attacker behavior, there are two levels of difficulty for the attacker:

• Low: An attacker can use a low-permission account and discover your sensitive information because of broad access throughout your tenant.
• Higher: An attacker can’t use a low-permission account and discover your sensitive information because of strict permissions. They must escalate their permissions by determining and then compromising the credentials of an account that has access to a location with sensitive information, but then may only be able to do a limited set of actions.

For sensitive information, you must make the level of difficulty as high as you can.

You can ensure strict permissions in your tenant with these steps:

1. From the effort to locate your sensitive information, review the permissions for the locations of sensitive information.
2. Implement strict permissions for the sensitive information while meeting collaboration and business requirements and inform the users that are affected.
3. Perform change management for your users so that future locations for sensitive information are created and maintained with strict permissions.
4. Audit and monitor the locations for sensitive information to ensure that broad permissions aren’t being granted.

See Set up secure file sharing and collaboration with Microsoft Teams for detailed guidance. An example of a communication and collaboration venue with strict permissions for sensitive information is a team with security isolation.

Protect your sensitive information

To protect your sensitive information in case a ransomware attacker obtains access to it:

• Use controlled folder access to make it more difficult for unauthorized applications to modify the data in controlled folders.
• Use Microsoft Purview Information Protection and sensitivity labels and apply them to sensitive information. Sensitivity labels can be configured for additional encryption and permissions with defined user accounts and allowed actions. A file labeled with this type of sensitivity label that is exfiltrated from your tenant will only be useable to a user account defined in the label.
• Use Microsoft Purview Data Loss Prevention (DLP) to detect, warn, and block risky, inadvertent, or inappropriate sharing of data containing personal or confidential information based on sensitivity labels, both internally and externally.
• Use Microsoft Defender for Cloud Apps to block downloads of sensitive information such as files. You can also use Defender for Cloud Apps anomaly detection policies to detect a high rate of file uploads or file deletion activities.

See my example on Secure Teams with three tiers of protection example

Microsoft services for protecting data

Data & Application
Azure Backup	Provides simple, secure, and cost-effective solutions to back up your data and recover it from the Microsoft Azure cloud.
Azure Storage Service Encryption	Automatically encrypts data before it is stored and automatically decrypts the data when you retrieve it.
Azure Information Protection	A cloud-based solution that enables organizations to discover, classify, and protect documents and emails by applying labels to content.
API Management	A way to create consistent and modern API gateways for existing back-end services.
Azure confidential computing	Allows you to isolate your sensitive data while it’s being processed in the cloud.

Specify an encryption standard for data at rest and in motion

Data encryption could be needed based on regulations from the data used or from the sector that the organization is doing business in or both.

Healthcare have different compliance requirements than banking but both have one mutual requirement. No data can be leaked outside, there will be serious consequences for organizations that doesn’t fulfill this requirement.

So encryption is needed and Microsoft does it for you by default.

Data at rest

Microsoft’s approach to enabling two layers of encryption for data at rest is:

• Encryption at rest using customer-managed keys. You provide your own key for data encryption at rest. You can bring your own keys to your Key Vault (BYOK – Bring Your Own Key), or generate new keys in Azure Key Vault to encrypt the desired resources.
• Infrastructure encryption using platform-managed keys. By default, data is automatically encrypted at rest using platform-managed encryption keys.

Data in transit

Microsoft’s approach to enabling two layers of encryption for data in transit is:

• Transit encryption using Transport Layer Security (TLS) 1.2 to protect data when it’s traveling between the cloud services and you. All traffic leaving a datacenter is encrypted in transit, even if the traffic destination is another domain controller in the same region. TLS 1.2 is the default security protocol used. TLS provides strong authentication, message privacy, and integrity (enabling detection of message tampering, interception, and forgery), interoperability, algorithm flexibility, and ease of deployment and use.
• Additional layer of encryption provided at the infrastructure layer. Whenever Azure customer traffic moves between datacenters– outside physical boundaries not controlled by Microsoft or on behalf of Microsoft– a data-link layer encryption method using the IEEE 802.1AE MAC Security Standards (also known as MACsec) is applied from point-to-point across the underlying network hardware. The packets are encrypted and decrypted on the devices before being sent, preventing physical “man-in-the-middle” or snooping/wiretapping attacks. Because this technology is integrated on the network hardware itself, it provides line rate encryption on the network hardware with no measurable link latency increase. This MACsec encryption is on by default for all Azure traffic traveling within a region or between regions, and no action is required on customers’ part to enable.

Services available for encryption

Azure Key Vault (Standard Tier)

A FIPS 140-2 Level 1 validated multi-tenant cloud key management service that can also be used to store secrets and certificates. Keys stored in Azure Key Vault are software-protected and can be used for encryption-at-rest and custom applications. Key Vault provides a modern API and the widest breadth of regional deployments and integrations with Azure Services. For more information, see About Azure Key Vault.

Azure Key Vault (Premium Tier)

A FIPS 140-2 Level 2 validated multi-tenant HSM offering that can be used to store keys in a secure hardware boundary. Microsoft manages and operates the underlying HSM, and keys stored in Azure Key Vault Premium can be used for encryption-at-rest and custom applications. Key Vault Premium also provides a modern API and the widest breadth of regional deployments and integrations with Azure Services. For more information, see About Azure Key Vault.

Azure Managed HSM

A FIPS 140-2 Level 3 validated single-tenant HSM offering that gives customers full control of an HSM for encryption-at-rest, Keyless SSL, and custom applications. Customers receive a pool of three HSM partitions—together acting as one logical, highly available HSM appliance–fronted by a service that exposes crypto functionality through the Key Vault API. Microsoft handles the provisioning, patching, maintenance, and hardware failover of the HSMs, but does not have access to the keys themselves, because the service executes within Azure’s Confidential Compute Infrastructure. Managed HSM is integrated with the Azure SQL, Azure Storage, and Azure Information Protection PaaS services and offers support for Keyless TLS with F5 and Nginx. For more information, see What is Azure Key Vault Managed HSM?

Azure Dedicated HSM

A FIPS 140-2 Level 3 validated bare metal HSM offering, that lets customers lease a general-purpose HSM appliance that resides in Microsoft datacenters. The customer has complete and total ownership over the HSM device and is responsible for patching and updating the firmware when required. Microsoft has no permissions on the device or access to the key material, and Dedicated HSM is not integrated with any Azure PaaS offerings. Customers can interact with the HSM using the PKCS#11, JCE/JCA, and KSP/CNG APIs. This offering is most useful for legacy lift-and-shift workloads, PKI, SSL Offloading and Keyless TLS (supported integrations include F5, Nginx, Apache, Palo Alto, IBM GW and more), OpenSSL applications, Oracle TDE, and Azure SQL TDE IaaS. For more information, see What is Azure Key Vault Managed HSM?

Azure Payments HSM (public preview)

A FIPS 140-2 Level 3, PCI HSM v3, validated bare metal offering that lets customers lease a payment HSM appliance in Microsoft datacenters for payments operations, including payment processing, payment credential issuing, securing keys and authentication data, and sensitive data protection. The service is PCI DSS and PCI 3DS compliant. Azure Payment HSM offers single-tenant HSMs for customers to have complete administrative control and exclusive access to the HSM. Once the HSM is allocated to a customer, Microsoft has no access to customer data. Likewise, when the HSM is no longer required, customer data is zeroized and erased as soon as the HSM is released, to ensure complete privacy and security is maintained. This offering is currently in public preview. For more information, see About Azure Payment HSM.

Encryption types

Microsoft has different options to encrypt your data.

Client-side encryption

Client-side encryption is performed outside of Azure. It includes:

• Data encrypted by an application that’s running in the customer’s datacenter or by a service application.
• Data that is already encrypted when it is received by Azure.

With client-side encryption, cloud service providers don’t have access to the encryption keys and cannot decrypt this data. You maintain complete control of the keys.

Server-side encryption

The three server-side encryption models offer different key management characteristics, which you can choose according to your requirements:

• Service-managed keys: Provides a combination of control and convenience with low overhead.
• Customer-managed keys: Gives you control over the keys, including Bring Your Own Keys (BYOK) support, or allows you to generate new ones.
• Service-managed keys in customer-controlled hardware: Enables you to manage keys in your proprietary repository, outside of Microsoft control. This characteristic is called Host Your Own Key (HYOK). However, configuration is complex, and most Azure services don’t support this model.

Encryption models

And here a list of the supported services for each RSA key size. The size is the one that is defined, not lower or higher.

Product, Feature, or Service	Server-Side Using Service-Managed Key	Server-Side Using Customer-Managed Key	Client-Side Using Client-Managed Key
AI and Machine Learning
Azure Cognitive Search	Yes	Yes	-
Azure Cognitive Services	Yes	Yes	-
Azure Machine Learning	Yes	Yes	-
Content Moderator	Yes	Yes	-
Face	Yes	Yes	-
Language Understanding	Yes	Yes	-
Personalizer	Yes	Yes	-
QnA Maker	Yes	Yes	-
Speech Services	Yes	Yes	-
Translator Text	Yes	Yes	-
Power BI	Yes	Yes, RSA 4096-bit	-
Analytics
Azure Stream Analytics	Yes	Yes**, including Managed HSM	-
Event Hubs	Yes	Yes	-
Functions	Yes	Yes	-
Azure Analysis Services	Yes	-	-
Azure Data Catalog	Yes	-	-
Azure HDInsight	Yes	All	-
Azure Monitor Application Insights	Yes	Yes	-
Azure Monitor Log Analytics	Yes	Yes	-
Azure Data Explorer	Yes	Yes	-
Azure Data Factory	Yes	Yes, including Managed HSM	-
Azure Data Lake Store	Yes	Yes, RSA 2048-bit	-
Containers
Azure Kubernetes Service	Yes	Yes, including Managed HSM	-
Container Instances	Yes	Yes	-
Container Registry	Yes	Yes	-
Compute
Virtual Machines	Yes	Yes, including Managed HSM	-
Virtual Machine Scale Set	Yes	Yes, including Managed HSM	-
SAP HANA	Yes	Yes	-
App Service	Yes	Yes**, including Managed HSM	-
Automation	Yes	Yes	-
Azure Functions	Yes	Yes**, including Managed HSM	-
Azure portal	Yes	Yes**, including Managed HSM	-
Logic Apps	Yes	Yes	-
Azure-managed applications	Yes	Yes**, including Managed HSM	-
Service Bus	Yes	Yes	-
Site Recovery	Yes	Yes	-
Databases
SQL Server on Virtual Machines	Yes	Yes	Yes
Azure SQL Database	Yes	Yes, RSA 3072-bit, including Managed HSM	Yes
Azure SQL Managed Instance	Yes	Yes, RSA 3072-bit, including Managed HSM	Yes
Azure SQL Database for MariaDB	Yes	-	-
Azure SQL Database for MySQL	Yes	Yes	-
Azure SQL Database for PostgreSQL	Yes	Yes	-
Azure Synapse Analytics	Yes	Yes, RSA 3072-bit, including Managed HSM	-
SQL Server Stretch Database	Yes	Yes, RSA 3072-bit	Yes
Table Storage	Yes	Yes	Yes
Azure Cosmos DB	Yes (learn more)	Yes (learn more)	-
Azure Databricks	Yes	Yes	-
Azure Database Migration Service	Yes	N/A*	-
Identity
Azure Active Directory	Yes	-	-
Azure Active Directory Domain Services	Yes	Yes	-
Integration
Service Bus	Yes	Yes	Yes
Event Grid	Yes	-	-
API Management	Yes	-	-
IoT Services
IoT Hub	Yes	Yes	Yes
IoT Hub Device Provisioning	Yes	Yes	-
Management and Governance
Azure Managed Grafana	Yes	-	N/A
Azure Site Recovery	Yes	-	-
Azure Migrate	Yes	Yes	-
Media
Media Services	Yes	Yes	Yes
Security
Microsoft Defender for IoT	Yes	Yes	-
Microsoft Sentinel	Yes	Yes	-
Storage
Blob Storage	Yes	Yes, including Managed HSM	Yes
Premium Blob Storage	Yes	Yes, including Managed HSM	Yes
Disk Storage	Yes	Yes, including Managed HSM	-
Ultra Disk Storage	Yes	Yes, including Managed HSM	-
Managed Disk Storage	Yes	Yes, including Managed HSM	-
File Storage	Yes	Yes, including Managed HSM	-
File Premium Storage	Yes	Yes, including Managed HSM	-
File Sync	Yes	Yes, including Managed HSM	-
Queue Storage	Yes	Yes, including Managed HSM	Yes
Data Lake Storage Gen2	Yes	Yes, including Managed HSM	Yes
Avere vFXT	Yes	-	-
Azure Cache for Redis	Yes	N/A*	-
Azure NetApp Files	Yes	Yes	-
Archive Storage	Yes	Yes	-
StorSimple	Yes	Yes	Yes
Azure Backup	Yes	Yes	Yes
Data Box	Yes	-	Yes
Data Box Edge	Yes	Yes	-

Limits for Key vault

When you use Key vault for your keys, you will have limits for it.

For RSA 2,048-bit software keys, 4,000 GET transactions per 10 seconds are allowed. For RSA 2,048-bit HSM-keys, 2,000 GET transactions per 10 seconds are allowed.

In a given 10-second interval, an Azure Key Vault client can do only one of the following operations before it encounters a 429 throttling HTTP status code:

• 4,000 RSA 2,048-bit software-key GET transactions
• 2,000 RSA 2,048-bit HSM-key GET transactions
• 250 RSA 4,096-bit HSM-key GET transactions
• 248 RSA 4,096-bit HSM-key GET transactions and 16 RSA 2,048-bit HSM-key GET transactions

It’s eight times more expensive to use 4,096-bit keys compared to 2,048-bit keys and there is a limits for different key types.

Key type	HSM key CREATE key	HSM key All other transactions	Software key CREATE key	Software key All other transactions
RSA 2,048-bit	10	2,000	20	4,000
RSA 3,072-bit	10	500	20	1,000
RSA 4,096-bit	10	250	20	500
ECC P-256	10	2,000	20	4,000
ECC P-384	10	2,000	20	4,000
ECC P-521	10	2,000	20	4,000
ECC SECP256K1	10	2,000	20	4,000

Limits for Managed HSM

Each Managed HSM instance constitutes three load balanced HSM partitions. The throughput limits are a function of underlying hardware capacity allocated for each partition. The tables below show maximum throughput with at least one partition available. Actual throughput may be up to 3x higher if all three partitions are available.

Throughput limits noted assume that one single key is being used to achieve maximum throughput. For example, if a single RSA-2048 key is used the maximum throughput will be 1100 sign operations. If you use 1100 different keys with one transaction per second each, they will not be able to achieve the same throughput.

Number of operations per second per HSM instance for RSA keys.

Operation	2048-bit	3072-bit	4096-bit
Create Key	1	1	1
Delete Key (soft-delete)	10	10	10
Purge Key	10	10	10
Backup Key	10	10	10
Restore Key	10	10	10
Get Key Information	1100	1100	1100
Encrypt	10000	10000	6000
Decrypt	1100	360	160
Wrap	10000	10000	6000
Unwrap	1100	360	160
Sign	1100	360	160
Verify	10000	10000	6000

Infrastructure encryption

Microsoft also provides a solution for Blob storage for Double encryption, Microsoft encrypts and you will, with our own keys.

Certificates

Microsoft updated Azure services to use TLS certificates from a different set of Root Certificate Authorities (CAs) on February 15, 2021, to comply with changes set forth by the CA/Browser Forum Baseline Requirements. Some services may not finalize these updates until 2022.

Things to remember

How to classify applications?

Learn Stride, OWASP and SSDF frameworks.

How DevOps works and what are the bit ‘n pieces?

Different types on tenants and user accounts.

How App registrations and their API permissions work?

What is a kill chain and to protect against it?

How discover and protect sensitive data and why to build a baseline

Differences between encryption for Data in Rest and Data in Transit.

Encryption models and different services to use them and their limitations.

Thank you!

For this last post I will like to thank you all for reading and supporting. All the feedback is more than welcome from my audience because you are the ones that this these post are for. Raising the community, because the community raised me!

Then moving to the next one, still didn’t decide which one, could be one of the following or not, let’s see what’s coming!

In the meantime you can book time with me for MVP or technical mentoring, many have already done so. See here for more info.

#Azure #Identity #Security #sharingiscaring #Neverstoplearning

Link to main post