Primary tabs


HyTrust was founded in 2007 by veterans in the enterprise infrastructure and security space who recognized early on, not only that virtualization and the cloud were going to dramatically transform the data center, but also that security would be a critical inhibitor to cloud adoption.

The mission behind HyTrust has always been to mitigate the risk of catastrophic data center failure and data breaches — especially in light of the concentration of risk that occurs within virtualized and cloud environments. Organizations can now confidently expand virtualization to mission critical applications and take full advantage of the cloud.

Hytrust platform is structured around three pillars :

1 CloudControl – Private Cloud security for the virtualized infrastructure. Two Factor Authentication, Root Password Vaulting, deep Role Based Access Controls, Secondary Approval Workflows, Compliance Enforcement via key security frameworks. Essentially what would have prevented AWS recent 4.5 hour, $300M outage that was caused by “pilot error” of a virtual admin deleting some critical VM’s.

2 DataControl – Protection of the critical workloads across multiple clouds. Encryption and key management of VMware, Hyper-V and KVM VM’s for their entire lifecycle, no matter what cloud they migrate to. Hardware accelerated agent via integration with Intel AES-NI. Customers always own their own keys, even if VM’s move to a public cloud. Key Management that can deliver keys for any KMIP agent.

3 Boundary Controls – Uses CloudControl policy engine to assign critical cloud workloads to specific servers or server groups in specific locations, providing the industry’s first true hardware enforced geo-fencing. Integrated with Intel TXT Boundary Controls is a major part of compliance frameworks such as GDPR, NIS and others that require your critical workloads only execute where you want them to, and not anywhere else.

In relation to the first question of the EBA consultation, we believe that in the context of cloud outsourcing it’s critical to integrate specific recommendations regarding the impact of the General Data Protection Regulation (GDPR) and other related EU Directives, such as the ePrivacy Directive and the Network Information System Security Directive (NIS) on institutions and how it will affect use of cloud computing (private, hybrid and public deployment models as defined in NIST SP 800-145). The focus of the EBA recomendations is outsourced clouds (i.e. hybrid and public deployment models).

GDPR and the related directives will force organizations/institutions to rethink how they deal with personal, privacy-sensitive data, and Information Technology architectural recommendations (for example a GDPR stack recommendation) can help organizations comply with these regulations and the identified potential gap.

In the context of GDPR we think that it’s important to reinforce recommendations focused in ensuring that organizations are compliant and thus the recommendation must comprehensively consider how personal data is used:

• why it was collected?
• how it is processed?
• who has access to the personal, privacy-sensitive data?
• where and how it is stored, including back-ups and disaster recovery/business continuity copies?
• which third parties are involved and have access?
• what internal and external threats there are?

Enterprise architects have a uniquely broad and integrated view of their organization, and have the approach and tools at their disposal to assess, improve and assure data protection.
GDPR not only demands compliance, but also requires that the insitution demonstrates its compliance.

Information Technology (IT) Architecture and architecture models are the major source of this information, in particular when you need a coherent and connected view of everything related to personal data.

For example, a recommendation around the notion of privacy inventory has the potential to help institutions that are planning to outsource to:

a) Identify all data that counts as ‘personal’ according to the GDPR.

b) Classify such data with respect to its privacy-sensitivity. Make this a part of the regular security processes, where the insitition assigns other information security attributes such as the familiar ‘CIA’ (confidentiality, integrity, availability) to the data. These classification can also be associated with IT systems running in hybrid and public cloud via Tags, and remain with the system even through migrations to different physical data centers.

c) Describe the purpose for which this data was collected, and ensure it has obtained the consent of the data subjects to use it in that way.

d) Pay extra attention to special categories of personal data, such as data related to health, biometrics, politics, religion, ethnicity or trade union membership. Use of that data is explicitly prohibited by the GDPR, unless very specific circumstances apply.

e) Demonstrate that the institution has taken these steps to protect the data via granular administrator/privileged user access control, forensic level logging, and proof of configuration and access policy settings in virtual workloads that conform to data protection controls.
In the context of cloud outsourcing we think that specific recommendations around how to prioritize risks related to the cloud outsourcing strategy must be integrated, in order to provide Financial Institutions a framework/approach that will enable them to allocate budgets and plan the requisite changes and improvements:

a) Evaluate the cost of measures against the risks (the expected loss) to focus your budget on where it really counts;

b) Integrate this decision-making with your overall portfolio management and roadmaps. For example, you may avoid spending too much on fixing up an application that will be phased out soon, and you can combine security-related improvements with other changes.

In the context of cloud outsourcing we think that specific recommendations and example of heatmap focused on how to Assess risks related to sensitive data, in particular concerning the rights and freedoms of data subjects:

a) Where in your business and IT landscape do you see vulnerabilities?
b) What are common threats that could exploit these vulnerabilities?
c) What are the potential consequences?.

For example a heatmap focused on vulnerabilities and especially related to cloud outsourcing.

Last but not least in the context of cloud outsourcing we think recommendations around relationships and correlation between GDPR, PSD2 and Third Party Payment Service Providers (TPP’s) are critical for financial institutions. With the introduction of the PSD2 and access to financial services related user accounts, valuable financial information may reside outside the protected framework without sufficient supervision. The biggest risk with the introduction of the PSD2 will be the abuse and/or possible misuse of personal financial data.

For example :

Article 94 in the PSD2 there is a direct link between the PSD2 and the current data protection directive:

• In article 94, it is stated that the current data protection directive is applicable entirely. This will be continued when the GDPR comes into effect, since it will replace all legislation on data protection.

• Derived therefrom TPP’s will need to comply with the GDPR as well.

• IMPORTANT for TPP’s : the conscious opt-in consent by the customer, the introduction of the DPO, the data breach notification and the customers’right to be forgotten.

• Both the GDPR and the PSD2 refer to consent as an informed choice by customers.

• An informed choice implies two things:
i. Informed intends to make customers aware of the consequences of their choices, and to have customers clearly understand what data is being collected and how it will be used.
ii. Once they know that, they can either choose to accept or decline. Registering that choice in case of acceptance is the actual consent. The PSD2 and the GDPR are still very general about the information level a customer must have in order to be considered an informed customer that makes an informed choice.

As we know PSD2 lacks guidance on the right to be forgotten and therefore the consequences could be dramatic, hence recommendations around these consequences must be integrated as proposed hereunder:

• One consequence is that TPP’s will not be ready nor have the ability to erase the data when a user requests, and will most likely result in making the data of that user inaccessible — which is not the same as erasure — and allows companies to keep using it.

• Failure to comply to an individual request only could become a problem for the TPP including their other customers. A consequence of the failure to erase the data of a single user, could lead to the erasure of the data of all users. That also complies with the request only being far more extensive than necessary. This puts the TPP in a problematic position, because erasure of all data, would include the data of all customers. Also the ones that didn’t apply for erasure.

• Those customers could become victim of the inability of the TPP to act on this appropriately.

• So depending on the ability to act on the right to be forgotten, a TPP could render its services useless with a single erasure request affecting all customers, also customers that are not involved in this matter.