revised Windows Store

windows/device-security/applocker/packaged-apps-and-packaged-app-installer-rules-in-applocker.md

@@ -17,7 +17,7 @@ author: brianlic-msft
 
 This topic explains the AppLocker rule collection for packaged app installers and packaged apps.
 
-Universal Windows apps can be installed through the Windows Store or can be sideloaded using the Windows PowerShell cmdlets. Universal Windows apps can be installed by a standard user unlike some Classic Windows applications that sometimes require administrative privileges for installation.
+Universal Windows apps can be installed through the Microsoft Store or can be sideloaded using the Windows PowerShell cmdlets. Universal Windows apps can be installed by a standard user unlike some Classic Windows applications that sometimes require administrative privileges for installation.
 Typically, an app consists of multiple components – the installer used to install the app and one or more exes, dlls or scripts. With Classic Windows applications, not all those components always share common attributes such as the publisher name, product name and product version. Therefore, AppLocker has to control each of these components separately through different rule collections – exe, dll, script and Windows Installers. In contrast, all the components of a Universal Windows app share the same attributes: Publisher name, Package name and Package version. It is therefore possible to control an entire app with a single rule.
 
 AppLocker enforces rules for Universal Windows apps separately from Classic Windows applications. A single AppLocker rule for a Universal Windows app can control both the installation and the running of an app. Because all Universal Windows apps are signed, AppLocker supports only publisher rules for Universal Windows apps. A publisher rule for a Universal Windows app is based on the following attributes of the app:

windows/device-security/applocker/understand-applocker-policy-design-decisions.md

@@ -38,7 +38,7 @@ You might need to control a limited number of apps because they access sensitive
 | - | - |
 | Control all apps | AppLocker policies control applications by creating an allowed list of applications by file type. Exceptions are also possible. AppLocker policies can only be applied to applications installed on computers running one of the supported versions of Windows. For specific operating system version requirements, see [Requirements to use AppLocker](requirements-to-use-applocker.md).|
 | Control specific apps | When you create AppLocker rules, a list of allowed apps are created. All apps on that list will be allowed to run (except those on the exception list). Apps that are not on the list will be prevented from running. AppLocker policies can only be applied to apps installed on computers running any of the supported versions of Windows. For specific operating system version requirements, see [Requirements to use AppLocker](requirements-to-use-applocker.md).|
-|Control only Classic Windows applications, only Universal Windows apps, or both| AppLocker policies control apps by creating an allowed list of apps by file type. Because Universal Windows apps are categorized under the Publisher condition, Classic Windows applications and Universal Windows apps can be controlled together. AppLocker policies for Universal Windows apps can be applied only to apps that are installed on PCs that support the Windows Store, but Classic Windows applications can be controlled with AppLocker on all supported versions of Windows. The rules you currently have configured for Classic Windows applications can remain, and you can create new ones for Universal Windows apps.<br/>For a comparison of Classic Windows applications and Universal Windows apps, see [Comparing Classic Windows applications and Universal Windows apps for AppLocker policy design decisions](#bkmk-compareclassicmetro) in this topic.|
+|Control only Classic Windows applications, only Universal Windows apps, or both| AppLocker policies control apps by creating an allowed list of apps by file type. Because Universal Windows apps are categorized under the Publisher condition, Classic Windows applications and Universal Windows apps can be controlled together. AppLocker policies for Universal Windows apps can be applied only to apps that are installed on PCs that support the Microsoft Store, but Classic Windows applications can be controlled with AppLocker on all supported versions of Windows. The rules you currently have configured for Classic Windows applications can remain, and you can create new ones for Universal Windows apps.<br/>For a comparison of Classic Windows applications and Universal Windows apps, see [Comparing Classic Windows applications and Universal Windows apps for AppLocker policy design decisions](#bkmk-compareclassicmetro) in this topic.|
 | Control apps by business group and user | AppLocker policies can be applied through a Group Policy Object (GPO) to computer objects within an organizational unit (OU). Individual AppLocker rules can be applied to individual users or to groups of users.|
 | Control apps by computer, not user | AppLocker is a computer-based policy implementation. If your domain or site organizational structure is not based on a logical user structure, such as an OU, you might want to set up that structure before you begin your AppLocker planning. Otherwise, you will have to identify users, their computers, and their app access requirements.|
 |Understand app usage, but there is no need to control any apps yet | AppLocker policies can be set to audit app usage to help you track which apps are used in your organization. You can then use the AppLocker event log to create AppLocker policies.|
@@ -59,7 +59,7 @@ You might need to control a limited number of apps because they access sensitive
  
 ### <a href="" id="bkmk-compareclassicmetro"></a>Comparing Classic Windows applications and Universal Windows apps for AppLocker policy design decisions
 
-AppLocker policies for Universal Windows apps can only be applied to apps that are installed on computers running Windows operating systems that support Windows Store apps. However, Classic Windows applications can be controlled in Windows Server 2008 R2 and Windows 7, in addition to those computers that support Universal Windows apps. The rules for Classic Windows applications and Universal Windows apps can be enforced together. The differences you should consider for Universal Windows apps are:
+AppLocker policies for Universal Windows apps can only be applied to apps that are installed on computers running Windows operating systems that support Microsoft Store apps. However, Classic Windows applications can be controlled in Windows Server 2008 R2 and Windows 7, in addition to those computers that support Universal Windows apps. The rules for Classic Windows applications and Universal Windows apps can be enforced together. The differences you should consider for Universal Windows apps are:
 
 -   All Universal Windows apps can be installed by a standard user, whereas a number of Classic Windows applications require administrative credentials to install. So in an environment where most of the users are standard users, you might not need numerous exe rules, but you might want more explicit policies for packaged apps.
 -   Classic Windows applications can be written to change the system state if they run with administrative credentials. Most Universal Windows apps cannot change the system state because they run with limited permissions. When you design your AppLocker policies, it is important to understand whether an app that you are allowing can make system-wide changes.

windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md

@@ -116,7 +116,7 @@ Catalog files can be very useful for unsigned LOB applications that cannot easil
 
 To obtain signed applications or embed signatures in your in-house applications, you can choose from a variety of methods:
 
-- Using the Windows Store publishing process. All apps that come out of the Microsoft Store are automatically signed with special signatures that can roll-up to our certificate authority (CA) or to your own.
+- Using the Microsoft Store publishing process. All apps that come out of the Microsoft Store are automatically signed with special signatures that can roll-up to our certificate authority (CA) or to your own.
 
 - Using your own digital certificate or public key infrastructure (PKI). ISV's and enterprises can sign their own Classic Windows applications themselves, adding themselves to the trusted list of signers.
 
@@ -124,7 +124,7 @@ To obtain signed applications or embed signatures in your in-house applications,
 
 To use catalog signing, you can choose from the following options:
 
-- Use the Windows Defender Device Guard signing portal available in the Windows Store for Business. The portal is a Microsoft web service that you can use to sign your Classic Windows applications. For more information, see [Windows Defender Device Guard signing](https://technet.microsoft.com/itpro/windows/manage/device-guard-signing-portal).
+- Use the Windows Defender Device Guard signing portal available in the Microsoft Store for Business. The portal is a Microsoft web service that you can use to sign your Classic Windows applications. For more information, see [Windows Defender Device Guard signing](https://technet.microsoft.com/itpro/windows/manage/device-guard-signing-portal).
 
 - Create your own catalog files, which are described in the next section. For information about how creating catalog files fits into Windows Defender Device Guard deployment, see [Planning and getting started on the Windows Defender Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md).
 

windows/device-security/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices.md

@@ -292,8 +292,8 @@ Device Guard policy into the UpdateSigner section.
 
 On computers with Device Guard, Microsoft proposes to move from a world where unsigned apps can be run without restriction to a world where only signed and trusted code is allowed to run on Windows 10.
 
-With Windows 10, organizations will make line-of-business (LOB) apps available to members of the organization through the Windows Store infrastructure. More specifically, LOB apps will be available in a private store within the public Windows Store. Windows Store signs and distributes Universal 
-Windows apps and Classic Windows apps. All apps downloaded from the Windows Store are signed.
+With Windows 10, organizations will make line-of-business (LOB) apps available to members of the organization through the Microsoft Store infrastructure. More specifically, LOB apps will be available in a private store within the public Microsoft Store. Microsoft Store signs and distributes Universal 
+Windows apps and Classic Windows apps. All apps downloaded from the Microsoft Store are signed.
 
 In organizations today, the vast majority of LOB applications are unsigned. Code signing is frequently viewed as a tough problem to solve for a variety of reasons, like the lack of code signing expertise. Even if code signing is a best practice, a lot of internal applications are not signed.
 

windows/device-security/windows-10-mobile-security-guide.md

@@ -2,7 +2,7 @@
 title: Windows 10 Mobile security guide (Windows 10)
 description: This guide provides a detailed description of the most important security features in the Windows 10 Mobile operating system—identity access and control, data protection, malware resistance, and app platform security.
 ms.assetid: D51EF508-699E-4A68-A7CD-91D821A97205
-keywords: data protection, encryption, malware resistance, smartphone, device, Windows Store
+keywords: data protection, encryption, malware resistance, smartphone, device, Microsoft Store
 ms.prod: w10
 ms.mktglfcycl: manage
 ms.sitesec: library
@@ -183,7 +183,7 @@ The table below outlines how Windows 10 Mobile mitigates specific malware threat
 </tr>
 <tr class="odd">
 <td align="left"><p>An unauthorized app or malware attempts to start on the device.</p></td>
-<td align="left"><p>All Windows 10 Mobile apps must come from Windows Store or Windows Store for Business. Device Guard enforces administrative policies to select exactly which apps are allowed to run.</p></td>
+<td align="left"><p>All Windows 10 Mobile apps must come from Microsoft Store or Microsoft Store for Business. Device Guard enforces administrative policies to select exactly which apps are allowed to run.</p></td>
 </tr>
 <tr class="even">
 <td align="left"><p>User-level malware exploits a vulnerability in the system or an application and owns the device.</p></td>
@@ -286,7 +286,7 @@ Because this solution can detect and prevent low-level malware that may be extre
 
 Device Guard is a feature set that consists of both hardware and software system integrity–hardening features. These features revolutionize Windows operating system security by moving the entire operating system to a trust-nothing model.
 
-All apps on Windows 10 Mobile must be digitally signed and come from Windows Store or a trusted enterprise store. Device Guard implements policies that further restrict this. By default, Device Guard supports all apps from Windows Store. You can create policies that define the apps that can and cannot run on the Windows 10 Mobile device. If the app does not have a digital signature, is prevented by policy, or does not come from a trusted store, it will not run on Windows 10 Mobile.
+All apps on Windows 10 Mobile must be digitally signed and come from Microsoft Store or a trusted enterprise store. Device Guard implements policies that further restrict this. By default, Device Guard supports all apps from Microsoft Store. You can create policies that define the apps that can and cannot run on the Windows 10 Mobile device. If the app does not have a digital signature, is prevented by policy, or does not come from a trusted store, it will not run on Windows 10 Mobile.
 
 Advanced hardware features, described above, drive these security offerings. By integrating these hardware features further into the core operating system, Windows 10 Mobile can use them in new ways. To deliver this additional security, Device Guard requires UEFI with Secure Boot.
 
@@ -339,10 +339,10 @@ A set of default permissions are granted to all AppContainers, including access
 
 The AppContainer concept is advantageous because it provides:
 -	**Attack surface reduction.** Apps can access only those capabilities that are declared in the application code and needed to perform their functions.
--	**User consent and control.** Capabilities that apps use are automatically published to the app details page in the Windows Store. App access to capabilities that may expose sensitive information automatically prompt the user to acknowledge and provide consent.
+-	**User consent and control.** Capabilities that apps use are automatically published to the app details page in the Microsoft Store. App access to capabilities that may expose sensitive information automatically prompt the user to acknowledge and provide consent.
 -	**App isolation.** Communication between Windows apps is tightly controlled. Apps are isolated from one another and can communicate only by using predefined communication channels and data types.
 
-Apps receive the minimal privileges they need to perform their legitimate tasks. This means that even if a malicious attacker exploits an app, the potential damage is limited because the app cannot elevate its privileges and is contained within its AppContainer. Windows Store displays the permissions that the app requires along with the app’s age rating and publisher.
+Apps receive the minimal privileges they need to perform their legitimate tasks. This means that even if a malicious attacker exploits an app, the potential damage is limited because the app cannot elevate its privileges and is contained within its AppContainer. Microsoft Store displays the permissions that the app requires along with the app’s age rating and publisher.
 
 The combination of Device Guard and AppContainer help to prevent unauthorized apps from running. In the event malware slips into the app ecosystem, the AppContainer helps to constrain the app and limit potential damage. The Windows 10 Mobile trust-nothing model doesn’t assume that any component is perfect. However, potential vulnerabilities in apps, AppContainers, and Windows 10 Mobile itself could give an attacker a chance to compromise a system. For this reason, redundant vulnerability mitigations are needed. The next several topics describe some of the redundant mitigations in Windows 10 Mobile.