Microsoft Windows Common Criteria Evaluation Microsoft Windows 10 (Anniversary Update) Microsoft Windows Server 2016
Yüklə 0,57 Mb.
|
- Bu səhifədəki naviqasiya:
- FPT_TUD_EXT.1, FPT_TUD_EXT.2
- Ctrl+Alt+Del
- 25.7.1SFR Summary FTA_TAB.1
- 25.8.1SFR Summary FTP_ITC_EXT.1(TLS), FTP_ITC_EXT.1(DTLS)
- 25.9Security Response Process
- 26.Protection Profile Conformance Claim
- 27.Rationale for Modifications to the Security Requirements
- Table Rationale for Operations
- 27.2Security Assurance Requirements
- 27.3Rationale for the TOE Summary Specification
- Table Requirement to Security Function Correspondence
FPT_ACF_EXT.1: Windows provides a Discretionary Access Control policy to limit modification and reading of objects by non-authorized users. FPT_ASLR_EXT.1: Windows randomizes user-mode process address spaces and kernel-mode address space. FPT_SBOP_EXT.1: Windows binaries are compiled with stack overflow protection (compiled using the /Gs option for native applications). FPT_SRP_EXT.1: Windows 10 Enterprise and Windows Server 2016 can restrict program execution based on the file path for the executable, a digital signature for the executable, a version number for the executable, or a hash of the executable file. FPT_TST_EXT.1: Windows checks the integrity of the Windows boot loader, OS loader, kernel, and system binaries and all application executable code, i.e., Windows Store Applications and updates to Windows and Windows Store Applications. FPT_TUD_EXT.1, FPT_TUD_EXT.2: Windows provides a means to identify the current version of the Windows software, the hardware model, and installed applications. Windows has update mechanisms to deliver updated operating system and application binaries and a means for a user to confirm that the digital signatures, which ensure the integrity of the update, are valid for both the operating system, applications, and Windows Store Applications. 25.7TOE Access Windows provides the ability for a user to lock their interactive logon session at their own volition or after a user-defined inactivity timeout. Windows also provides the ability for the administrator to specify the interval of inactivity after which the session will be locked. This policy will be applied to either the local machine or the computers within a domain using either local policy or group policy respectively. If both the administrator and a standard user specify an inactivity timeout period, Windows will lock the session when the shortest time period expires. Once a user has a desktop session, they can invoke the session locking function by using the same key sequence used to invoke the trusted path (Ctrl+Alt+Del). This key sequence is captured by the TSF and cannot be intercepted or altered by any user process. The result of that key sequence is a menu of functions, one of which is to lock the workstation. The user can also lock their desktop session by going to the Start screen, selecting their logon name, and then choosing the “Lock” option. Windows constantly monitors the mouse, keyboard, touch display, and the orientation sensor for inactivity in order to determine if they are inactive for the specified time period. After which, Windows will lock the workstation and execute the screen saver unless the user is streaming video such as a movie. Note that if the workstation was not locked manually, the TSF will lock the display and start the screen saver program if and when the inactivity period is exceeded, as well any notifications from applications which have registered to publish the application’s badge or the badge with associated notification text to the locked screen. The user has the option to not display any notifications, or choose one Windows Store Application to display notification text, and select other applications display their badge. After the computer was locked, in order to unlock their session, the user either presses a key or swipes the display. The user must provide the Ctrl+Alt+Del key combination if the Interactive Logon: Do not required CTRL+ALT+DEL policy is set to disabled. Either action will result in an authentication dialog. The user must then re-enter their authentication data, which has been cached by the local system from the initial logon, after which the user’s display will be restored and the session will resume. Alternately, an authorized administrator can enter their administrator identity and password in the authentication dialog. If the TSF can successfully authenticate the administrator, the user will be logged off, rather than returning to the user’s session, leaving the workstation ready to authenticate a new user. As part of establishing the interactive logon session, Windows can be configured to display a logon banner, which is specified by the administrator, that the user must accept prior to establishing the session. 25.7.1SFR Summary
25.8Trusted Channels Windows provides trusted network channels to communicate with supporting IT infrastructure or applications:
In order to establish a trusted channel, these communications are protected as described above in section 25.2.2. The remote access can be performed through the following methods:
Both methods use TLS (1.2) protocol for establishing the remote connection. 25.8.1SFR Summary
25.9Security Response Process Microsoft utilizes industry standard practices to address reported product vulnerabilities. This includes a central email address (secure@microsoft.com) to report issues (as described at https://technet.microsoft.com/en-us/security/ff852094), timely triage and root cause analysis, and responsible resolution of the report which may result in the release of a binary update. If a binary update is required, it is made available through automated channels to all customers following the process described at https://technet.microsoft.com/en-us/security/dn436305. If the sender wishes to send secure email, there is a public PGP key for S/MIME at https://technet.microsoft.com/en-us/security/dn606155.aspx. Security updates for Microsoft products – operating system, firmware, and applications – are delivered as described in section 25.6.4 and 25.6.5. 26.Protection Profile Conformance Claim This section provides the protection profile conformance claim and supporting justifications and rationale. 26.1Rationale for Conformance to Protection Profile This Security Target is in compliance with the For all of the content incorporated from the protection profile, the corresponding rationale in that protection profile remains applicable to demonstrate the correspondence between the TOE security functional requirements and TOE security objectives. Moreover, as demonstrated in this security target Windows runs on a wide variety of hardware ranging from tablets, convertibles, notebooks, desktop, and server computers and so it is a general purpose operating system. The requirements in the protection profile are assumed to represent a complete set of requirements that serve to address any interdependencies. All the functional requirements in this security target have been copied from the protection profile so that all dependencies between SFRs are satisfied by the inclusion of the relevant component (or one that is hierarchical to it) with the following exceptions, for which a rationale is given:
27.Rationale for Modifications to the Security Requirements This section provides a rationale that describes how the Security Target reproduced the security functional requirements and security assurance requirements from the protection profile. 27.1Functional Requirements This Security Target includes security functional requirements (SFRs) that can be mapped to SFRs found in the protection profile along with SFRs that describe additional features and capabilities. The mapping from protection profile SFRs to security target SFRs along with rationale for operations is presented in Table Rationale for Operations. SFR operations left incomplete in the protection profile have been completed in this security and are identified within each SFR in section 5.1 TOE Security Functional Requirements. Table Rationale for Operations
27.2Security Assurance Requirements The statement of security assurance requirements (SARs) found in section Error: Reference source not found Error: Reference source not found, is in strict conformance with the 27.3Rationale for the TOE Summary Specification This section, in conjunction with section 25, the TOE Summary Specification (TSS), provides evidence that the security functions are suitable to meet the TOE security requirements. Each subsection in section 25, TOE Security Functions (TSFs), describes a Security Function (SF) of the TOE. Each description is followed with rationale that indicates which requirements are satisfied by aspects of the corresponding SF. The set of security functions work together to satisfy all of the functional requirements. Furthermore, all the security functions are necessary in order for the TSF to provide the required security functionality. The set of security functions work together to provide all of the security requirements as indicated in Table . The security functions described in the TOE Summary Specification and listed in the tables below are all necessary for the required security functionality in the TSF. Table Requirement to Security Function Correspondence
Yüklə 0,57 Mb. Dostları ilə paylaş:
|