Главная страница Случайная страница КАТЕГОРИИ: АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника |
WPBT publisher ⇐ ПредыдущаяСтр 6 из 6
· OEMs that include a firmware WPBT publisher should have agreements in place with solution providers to service this component post release. This may require that OEMs ship a firmware update to remediate vulnerabilities in the WPBT publisher. · The authenticated device owner should have the ability to disable or remove this functionality if desired. Note that device owner in this case could mean that it’s not the user that is using the device. For example in a corporate environment the owner maybe the IT admin but not the end user using the device. · Ensure that update channels are only available to the OEM or solution provider that is responsible for that software. Ensure that an attacker cannot tamper with, block, or manipulate the update channel or the payloads that is distributes. Ensuring the integrity of the update channel can be accomplished in many ways for an example of how to leverage code signing or certificate pinning as potential solutions please see the Introductions to code signing MSDN page. Client Side Application and Firmware Considerations · Solutions must be security reviewed and not contain vulnerabilities that allow an attacker to elevate privileges, leak data, or weakens or bypasses security features provided by the OS. · All components provided in the solution should require strong digital signing (code signing) and integrity checks. Please visit the Microsoft code-signing best practices guide for more information. · Communication from the client side applications to backend severs should be encrypted. Please visit What is TLS/SSL? on TechNet for more information. · The solution must not tamper with or disable Windows Update. · The solution must not weaken the integrity of Windows security features. · Operations that only apply to a subset of devices, should include this targeting information inside a signed payload. For example, per-device-unique identifiers would be placed inside a signed file such that it cannot be used to modify an unintended system. · Operations that require freshness should include a random nonce inside the signed payload. For example, a payload that locks a device would use a nonce to ensure that the payload could not be reused to lock the device at a future date when it has not been requested. · Data consumed by the firmware from the OS is considered untrusted. The data must either be authenticated (by way of a digital signature) or input validated if authentication is not required (i.e. check for buffer overflows or invalid requests) · All client side software must be updateable and is the sole responsibility of the OEM or solution provider to provide updates when security issues are identified in their product. · Scrutiny should be used when adding certificates to the windows certificate store. < Research key management practices> < add verbiage on cert revocation>
Removal of Malware
|