When investigating the security of various products used on-site, in the cloud, or for clouds, I tend to ask the same set of questions. These focus on identity, compliance, logging, and the like. Specifically, I want to know how the product will integrate with security policy and requirements, as well as with other tools and services in use. Unfortunately, not many pass muster even with regard to these basic questions. Because of this, it is time to define why I ask them, why they are needed, and why you need to consider them as you move forward with your own hybrid cloud products.
The list of basic questions is pleasantly short, yet packed with both security and business requirements. The following table is the one I use for most products these days:
[table id=3 filter=’Security Functions’ filter_columns=’Product’] Let us start at the beginning.

Directory Service Authentication

Integration with a directory service, whether via LDAP or Active Directory, is a major requirement for today’s environments. Maintaining authentication and authorization data in a single place improves overall security. In addition, many directory services have additional integration with identity management platforms, federated identity across clouds, two-factor authentication services, mobile, and other aspects of user, machine, and system identities. This is a nonstarter for many companies. If your product offerings do not integrate with a directory service, then many enterprises will move to someone whose products do. In addition, directory service authentication provides a way to track users outside of the actual application. There are so many benefits, and no drawbacks.
No system administrator, security administrator, or technician wants to manage multiple identities in multiple systems. It is bad enough that many systems do not have centralized role-based access control (RBAC) or definitions of roles. We need centralized identity systems within a hybrid cloud.

RBAC

There are two forms of RBAC. The first, which is far too limited, comprises the typical three roles available on many hardware devices, such as switches. The second, which is more useful, comprises multiple definable roles. Roles define what an identity can access, whether that identity is that of a user, system, or machine. In too many cases, in-depth roles based on storage pools, system tags, and machine groups are severely limited. However, those that have these capabilities often excel, as they have thought more about how users and systems will access their product offerings. It is not an add-on at a gross level, but is embedded at every level.
Access control, and security, cannot be afterthoughts. I would rather have access control at many levels than at one that is too limited. What your security policy allows will dictate which you choose. However, there are tools to compensate for a missing robust RBAC. The real question is, do you want to manage more than one tool?

Encryption

Encryption is a huge issue these days. Protecting privacy as well as confidential material requires good encryption. This implies use of good keys, ways to share keys, and ways to control encryption. There are two forms of encryption that most worry about using. The first is encryption at rest. Encryption at rest does not need to be part of a product, but it does need to be part of the underlying storage (the 5 in the table above). Where you encrypt is just as important as encrypting. Too low, and everything is unencrypted above; too high, and you end up taking too much overhead to encrypt unless hardware is involved.
Encryption in motion is the next form of encryption. This is a requirement for all data transfer over any network—most importantly, between hybrid cloud endpoints. Some protocols have such encryption built (https) but can also be very weak if not configured properly. There are also ways to impose encryption on various networks by using virtual private networks (VPN) technology or even SD-WAN technologies.
The real key to encryption is management and simplicity. However, today it appears as though encryption is not easy to do, so many let it be done by others. I am looking for how to manage encryption, and how they keep it strong instead of weak. Simplicity is key; that takes a good UI. If it is not provided by the tool, the vendor should understand how it can be added and by whom. The other items for which I am looking are partnerships in this area, integration testing, and understanding of the actual need.

Namespaces

Namespaces is another term for multi-tenancy. If a product says it is multi-tenant, I am trying to determine how it isolates tenants: different encryption keys, a namespace added to each record, etc. How does the product keep Tenant A from seeing Tenant B’s data? Tied to this is how, if you are working in Tenant A as the service provider, you cannot manipulate or even see any other tenants. This is a very important aspect of multi-tenancy.
Included within this is how logs are tagged, how users are tagged, and every other aspect of the code. This can lend itself to some fairly interesting discussions. Just a UI that splits logins and views is not enough these days. It needs to go all the way through the product. Once more, this tells us how much the company believes in security measures.

Jurisdictional Control

This is like namespaces at a much higher level: the country level. Data in one country cannot migrate to another country. It is also possible for this to be regional: whatever the jurisdiction is for the data used within the product.

Compliance and Reporting

These are really two halves of the same thing. We are looking for products that know they are regulated in some fashion and can report upon it. We also need reports related to audit logs (who logged in as administrator as well as who did what when where and how). These are higher-level reports that can be presented to management to show how well the investment meets their compliance requirements and security policies. These questions tend to lead towards in-depth discussions on what reporting is minimally required and what reporting is needed for the future. Often, the reporting framework exists, but the actual reports are missing. We need to think about how these reports could be used to improve security and to show compliance with regulation or policy.
If the compliance reports are not available, we often have to find other ways to generate them. Perhaps using our log analysis tools.

Data Tokenization

Data tokenization is incredibly important. It allows privacy to be protected, as well as customer networks. In effect, is data anonymized on egress via logging methods, or export in some fashion? This is the key to the future of hybrid cloud. We need to tokenize data to make it abstract enough to protect our networks, systems, and other elements from the bad actors. All products should have a means to minimally anonymize data sent to support, third parties, and for anything written to disk or port.

Final Thoughts

There is quite a bit here. The security questions let us determine how important security is to the vendor and its salespeople, and how well it will support secure environments.The questions also reveal what we will need to do to compensate for missing bits. This list is far from complete, but it is a good start when we discuss the hybrid cloud. We need to protect our data. The tools we use must start somewhere.
What questions do you ask when looking at vendor products with respect to security?