![]() |
![]() ![]() archive ![]() ![]() ![]() |
A vision for hardware
|
On the internet all devices are just an IP addressWe've written previously on the importance of ensuring that a computer is operating correctly on behalf of a user. There are a wide range of examples of that, from a smartphone-initiated personal banking transaction to a web server accessing a database server within the confines of a datacenter. Before any enterprise allows critical data onto a device, the device must be well identified and secured from attack.Modern business requirements are such that employees and partners throughout the world expect ready access to data from a wide range of devices. IT professionals must ensure timely responses while preventing data loss due to sophisticated attacks and enterprise security policy drift. However, even devices behind an enterprise firewall are being regularly hacked. Web application servers are a notorious example. Each hacked web server becomes a Trojan Horse within the walls of the IT fortress. How do we prevent the bad guys from getting inside the fortress that is our datacenter? Furthermore, given the standard security guidance of assume breach, how do we prevent the bad guys from pouring out, once inside, and taking over the whole place? Proofing of data access requests that arrive at each individual server is critical. Threats against data include spoofing the user or the device requesting access, modification or denial of timely response to the user, and unauthorized disclosure of the plaintext data. Sensitive content must not only be protected with strong encryption. It must also be exposed only to strong identities and high-integrity systems, whether they are remote or within the datacenter. Enforcing protection for such a model requires that data only be accessible to systems that are known to have been good when issued and remain secure during use. We recommend data protection based on a foundation of hardware-protected device identity. Then, built on that foundation, the following capabilities are required:
Where most IT departments are todayCurrent commercial technologies are inadequate to mitigate attacks that come from within the enterprise trusted ecosystem. There are several reasons for this:
Where we want to take youMost commercial operating system and hardware platform combinations support virtualization and secure execution. However, integration of these capabilities into a system that enforces continuous authorization based on hardware root of trust is the novel capability of JW Secure StrongNet. We recommend that the following technologies be employed in concert:
Users need ready access to business data content over on-again/off-again connectivity. However, that need must be balanced with business continuity, intellectual property protection, and reputation needs. In other words, service high-availability must not come at the expense of data protection. Data should only be exposed to authorized users on known-good hardware in a secure state. First, for managed devices, the ability to ensure that hardware remains in a secure state is diminished when the device is disconnected from the management network. Downloaded plaintext data is vulnerable. Therefore, first off, we need to limit by policy the period of time during which downloaded plaintext data remains accessible. Second, whenever any secure app is suspended, any protected content that is contained in its cache will be cleared and must be decrypted again after the app is activated. Example scenarios include the laptop of a business executive left in a hotel room. Third, device software should decrypt content only when authorization conditions have been met. The service should determine the integrity of the software on the device continuously. To this is added the information about user identity, device identity, and whatever additional context is relevant to the authorization decision. The combination of device integrity and authentication data for the user and project parameters, such as time and location, are used to create wrappers for the content decryption keys. Note that content decryption keys can be included in several key wrappers with different users and projects, where projects should be interpreted broadly to include groupings like physical locations or even device types. Fourth, a render engine (for example, for DOCX, XLSX, and PDF documents) must be selected that supports the standard document encryption technology. It's important to protect the decryption key in use by putting the render engine in a space that cannot be accessed by any other application. Several technologies are available to place the render engine in an isolated environment. We propose to show hardware virtualization performing this function. The display image is eliminated whenever the device power cycles, requiring renewed authorization and decryption.
In summary, decryption of new content must not be possible until the user and the device are successfully authenticated. JW Secure can show you how binding hardware-protected cryptographic keys to environmental measurements such as time and behavior. We call the technique Measurement Bound Keys (MBK). An MBK can then be used in any scenario that calls for asymmetric cryptography and/or PKI without modification of the host application. Any change in measurement forces the key to be reauthorized. Therefore, as long as the key remains usable, the data owner knows that the host is provably secure.
|
![]()
|