deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-06-15 02:13:43 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

updates

Browse Source
This commit is contained in:
Paolo Matarazzo
2024-04-09 17:06:21 -04:00
parent 119cad446a
commit d547ad62b0
2 changed files with 43 additions and 101 deletions
Download Patch File Download Diff File Expand all files Collapse all files

136
windows/security/book/operating-system-security.md
View File

@ -31,125 +31,52 @@ Learn more: [Secure Boot and Trusted Boot](../operating-system-security/system-s
### Cryptography
Cryptography is designed to protect user and
system data. The cryptography stack in
Windows 11 extends from the chip to the cloud, enabling Windows, applications, and services
to protect system and user secrets. For example, data can be encrypted so that only a specific
reader with a unique key can read it. As a basis for data security, cryptography helps prevent
anyone except the intended recipient from reading data, performs integrity checks to ensure
data is free of tampering, and authenticates identity to ensure that communication is secure.
Windows 11 cryptography is certified to meet the Federal Information Processing Standard
(FIPS) 140. FIPS 140 certification ensures that US government-approved algorithms are
correctly implemented.
Cryptography is designed to protect user and system data. The cryptography stack in Windows 11 extends from the chip to the cloud, enabling Windows, applications, and services to protect system and user secrets. For example, data can be encrypted so that only a specific reader with a unique key can read it. As a basis for data security, cryptography helps prevent anyone except the intended recipient from reading data, performs integrity checks to ensure data is free of tampering, and authenticates identity to ensure that communication is secure. Windows 11 cryptography is certified to meet the Federal Information Processing Standard (FIPS) 140. FIPS 140 certification ensures that US government-approved algorithms are correctly implemented.
Learn more: FIPS 140 validation
Windows cryptographic modules provide low-level primitives such as:
* Random number generators (RNG)
* Support for AES 128/256 with XTS, ECB, CBC, CFB, CCM, and GCM modes of operation;
RSA and DSA 2048, 3072, and 4096 key sizes; ECDSA over curves P-256, P-384, P-521
* Hashing (support for SHA1, SHA-256, SHA-384, and SHA-512)
* Signing and verification (padding support for OAEP, PSS, and PKCS1)
* Key agreement and key derivation (support for ECDH over NIST-standard prime curves
P-256, P-384, P-521 and HKDF)
- Random number generators (RNG)
- Support for AES 128/256 with XTS, ECB, CBC, CFB, CCM, and GCM modes of operation; RSA and DSA 2048, 3072, and 4096 key sizes; ECDSA over curves P-256, P-384, P-521
- Hashing (support for SHA1, SHA-256, SHA-384, and SHA-512)
- Signing and verification (padding support for OAEP, PSS, and PKCS1)
- Key agreement and key derivation (support for ECDH over NIST-standard prime curves P-256, P-384, P-521 and HKDF)
Application developers can use these cryptographic modules to perform low-level cryptographic operations (Bcrypt), key storage operations (NCrypt), protect static data (DPAPI), and securely share secrets (DPAPI-NG).
Application developers can use these cryptographic modules to perform low-level
cryptographic operations (Bcrypt), key storage operations (NCrypt), protect static data
(DPAPI), and securely share secrets (DPAPI-NG).
Learn more: Cryptography and certificate management
Developers can access the modules on Windows through the Cryptography Next Generation
API (CNG), which is powered by Microsoft's open-source cryptographic library, SymCrypt.
SymCrypt supports complete transparency through its open-source code. In addition,
SymCrypt offers performance optimization for cryptographic operations by taking advantage
of assembly and hardware acceleration when available.
SymCrypt is part of Microsoft's commitment to transparency, which includes the global
Microsoft Government Security Program that aims to provide the confidential security
information and resources people need to trust Microsoft's products and services. The
program offers controlled access to source code, threat and vulnerability information
exchange, opportunities to engage with technical content about Microsoft's products and
services, and access to five globally distributed Transparency Centers.
Developers can access the modules on Windows through the Cryptography Next Generation API (CNG), which is powered by Microsoft's open-source cryptographic library, SymCrypt. SymCrypt supports complete transparency through its open-source code. In addition, SymCrypt offers performance optimization for cryptographic operations by taking advantage of assembly and hardware acceleration when available.
SymCrypt is part of Microsoft's commitment to transparency, which includes the global Microsoft Government Security Program that aims to provide the confidential security information and resources people need to trust Microsoft's products and services. The program offers controlled access to source code, threat and vulnerability information
exchange, opportunities to engage with technical content about Microsoft's products and services, and access to five globally distributed Transparency Centers.
### Certificates
To help safeguard and authenticate information, Windows provides comprehensive support
for certificates and certificate management.
The built-in certificate management command-line utility (certmgr.exe) or MMC snap-in
(certmgr.msc) can be used to view and manage certificates, certificate trust lists (CTLs), and
certificate revocation lists (CRLs). Whenever a certificate is used in Windows, we validate
that the leaf certificate and all the certificates in its chain of trust have not been revoked or
compromised. The CTLs and CRLs on the machine are used as a reference for PKI trust and
are updated monthly by the Microsoft Trusted Root program. If a trusted certificate or root
is revoked, all global devices will be updated, meaning users can trust that Windows will
automatically protect against vulnerabilities in public key infrastructure.
For cloud and enterprise deployments, Windows also offers users the ability to auto-enroll
and renew certificates in Active Directory with Group Policy to reduce the risk of potential
outages due to certificate expiration or misconfiguration. Additionally, enterprise certificate
pinning can be used to help reduce man-in-the-middle attacks by enabling users to protect
their internal domain names from chaining to unwanted certificates. A web application's
server authentication certificate chain is checked to ensure it matches a restricted set of
certificate authorities. Any web application triggering a name mismatch will start event
logging and prevent user access from Microsoft Edge.
To help safeguard and authenticate information, Windows provides comprehensive support for certificates and certificate management. The built-in certificate management command-line utility (certmgr.exe) or MMC snap-in (certmgr.msc) can be used to view and manage certificates, certificate trust lists (CTLs), and
certificate revocation lists (CRLs). Whenever a certificate is used in Windows, we validate that the leaf certificate and all the certificates in its chain of trust have not been revoked or compromised. The CTLs and CRLs on the machine are used as a reference for PKI trust and are updated monthly by the Microsoft Trusted Root program. If a trusted certificate or root is revoked, all global devices will be updated, meaning users can trust that Windows will automatically protect against vulnerabilities in public key infrastructure. For cloud and enterprise deployments, Windows also offers users the ability to auto-enroll and renew certificates in Active Directory with Group Policy to reduce the risk of potential outages due to certificate expiration or misconfiguration. Additionally, enterprise certificate pinning can be used to help reduce man-in-the-middle attacks by enabling users to protect their internal domain names from chaining to unwanted certificates. A web application's server authentication certificate chain is checked to ensure it matches a restricted set of certificate authorities. Any web application triggering a name mismatch will start event logging and prevent user access from Microsoft Edge.
### Code signing and integrity
To ensure that Windows files have not been tampered with, the Windows Code Integrity
process verifies the signature of each file in Windows. Code signing is core to establishing
the integrity of firmware, drivers, and software across the Windows platform. Code signing
creates a digital signature by encrypting the hash of the file with the private key portion of
a code-signing certificate and embedding the signature into the file. The Windows code
integrity process verifies the signed file by decrypting the signature to check the integrity of
the file and confirm that it is from a reputable publisher, ensuring that the file hasn't been
tampered with.
The digital signature is evaluated across the Windows environment on Windows boot code,
Windows kernel code, and Windows user mode applications. Secure Boot and Code Integrity
verify the signature on bootloaders, Option ROMs, and other boot components to ensure
that it is trusted and from a reputable publisher. For drivers not published by Microsoft,
Kernel Code Integrity verifies the signature on kernel drivers and requires that drivers be
signed by Windows or certified by the Windows Hardware Compatibility Program (WHCP).
This program ensures that third-party drivers are compatible with various hardware and
Windows and that the drivers are from vetted driver developers.
To ensure that Windows files have not been tampered with, the Windows Code Integrity process verifies the signature of each file in Windows. Code signing is core to establishing the integrity of firmware, drivers, and software across the Windows platform. Code signing creates a digital signature by encrypting the hash of the file with the private key portion of a code-signing certificate and embedding the signature into the file. The Windows code integrity process verifies the signed file by decrypting the signature to check the integrity of the file and confirm that it is from a reputable publisher, ensuring that the file hasn't been tampered with.
The digital signature is evaluated across the Windows environment on Windows boot code, Windows kernel code, and Windows user mode applications. Secure Boot and Code Integrity verify the signature on bootloaders, Option ROMs, and other boot components to ensure that it is trusted and from a reputable publisher. For drivers not published by Microsoft, Kernel Code Integrity verifies the signature on kernel drivers and requires that drivers be signed by Windows or certified by the Windows Hardware Compatibility Program (WHCP). This program ensures that third-party drivers are compatible with various hardware and Windows and that the drivers are from vetted driver developers.
### Device health attestation
The Windows device health attestation process supports a Zero Trust paradigm that shifts the
focus from static, network-based perimeters to users, assets, and resources.
The attestation process confirms the device, firmware, and boot process are in a good
state and have not been tampered with before they can access corporate resources. These
determinations are made with data stored in the TPM, which provides a secure root-of-trust.
The information is sent to an attestation service such as Azure Attestation to verify that the
device is in a trusted state. Then a modern device management (MDM) tool like Microsoft
Intune<sup>9</sup> reviews device health and connects this information with Microsoft Entra ID<sup>9</sup> for
conditional access.
Windows includes many security features to help protect users from malware and attacks.
However, security components are trustworthy only if the platform boots as expected
and is not tampered with. As noted above, Windows relies on Unified Extensible Firmware
Interface (UEFI) Secure Boot, ELAM, DRTM, Trusted Boot, and other low-level hardware and
firmware security features to protect your PC from attacks. From the moment you power
on your PC until your antimalware starts, Windows is backed with the appropriate hardware
configurations that help keep you safe. Measured Boot, implemented by bootloaders and
BIOS, verifies and cryptographically records each step of the boot in a chained manner. These
events are bound to the TPM, that functions as a hardware root-of-trust. Remote attestation
is the mechanism by which these events are read and verified by a service to provide a
verifiable, unbiased, and tamper-resilient report. Remote attestation is the trusted auditor of
your system's boot, allowing reliant parties to bind trust to the device and its security.
The Windows device health attestation process supports a Zero Trust paradigm that shifts the focus from static, network-based perimeters to users, assets, and resources. The attestation process confirms the device, firmware, and boot process are in a good state and have not been tampered with before they can access corporate resources. These
determinations are made with data stored in the TPM, which provides a secure root-of-trust. The information is sent to an attestation service such as Azure Attestation to verify that the device is in a trusted state. Then a modern device management (MDM) tool like Microsoft Intune<sup>9</sup> reviews device health and connects this information with Microsoft Entra ID<sup>9</sup> for conditional access.
A summary of the steps involved in attestation and Zero-Trust on a Windows device are
as follows:
Windows includes many security features to help protect users from malware and attacks. However, security components are trustworthy only if the platform boots as expected and is not tampered with. As noted above, Windows relies on Unified Extensible Firmware Interface (UEFI) Secure Boot, ELAM, DRTM, Trusted Boot, and other low-level hardware and firmware security features to protect your PC from attacks. From the moment you power on your PC until your antimalware starts, Windows is backed with the appropriate hardware configurations that help keep you safe. Measured Boot, implemented by bootloaders and BIOS, verifies and cryptographically records each step of the boot in a chained manner. These events are bound to the TPM, that functions as a hardware root-of-trust. Remote attestation is the mechanism by which these events are read and verified by a service to provide a verifiable, unbiased, and tamper-resilient report. Remote attestation is the trusted auditor of your system's boot, allowing reliant parties to bind trust to the device and its security.
A summary of the steps involved in attestation and Zero-Trust on a Windows device are as follows:
- During each step of the boot process—such as a file load, update of special variables, and more—information such as file hashes and signature(s) are measured in the TPM Platform Configuration Register (PCRs). The measurements are bound by a Trusted Computing Group specification that dictates which events can be recorded and the format of each event. The data provides important information about device security from the moment it powers on
- Once Windows has booted, the attestor (or verifier) requests the TPM get the measurements stored in its PCRs alongside the Measured Boot log. Together, these form the attestation evidence that's sent to the Microsoft Azure Attestation Service
- The TPM is verified by using the keys or cryptographic material available on the chipset with an Azure Certificate Service
- The above information is sent to the Azure Attestation Service to verify that the device is in a trusted state.
* During each step of the boot process—such as a file load, update of special variables, and
more—information such as file hashes and signature(s) are measured in the TPM Platform
Configuration Register (PCRs). The measurements are bound by a Trusted Computing
Group specification that dictates which events can be recorded and the format of each
event. The data provides important information about device security from the moment it
powers on.
* Once Windows has booted, the attestor (or verifier) requests the TPM get the
measurements stored in its PCRs alongside the Measured Boot log. Together, these form
the attestation evidence that's sent to the Microsoft Azure Attestation Service.
* The TPM is verified by using the keys or cryptographic material available on the chipset
with an Azure Certificate Service.
* The above information is sent to the Azure Attestation Service to verify that the device is
in a trusted state.
Learn more: Control the health of Windows devices
### Windows security policy settings and auditing
@ -201,5 +128,12 @@ Learn more:
- [Windows security settings](https://support.microsoft.com/windows/stay-protected-with-windows-security-2ae0363d-0ada-c064-8b56-6a39afb6a963)
- [Windows Security](../operating-system-security/system-security/windows-defender-security-center/windows-defender-security-center.md)
## Encryption and data protection
## Network security
## Virus and threat protection
> [!div class="nextstepaction"]
> [Chapter 3: Application security >](application-security.md)