3 Things CISO’s expect from Tech Companies in a Cloudy World

Adding new software to an enterprise is a difficult process.  In the past, choosing new software only required budget approval before it could be adopted.  Today’s enterprises have adopted processes that require security approval before a new product is approved for purchase.  On the surface, it seems like more bureaucracy, but software has changed. Software is becoming more interconnected and companies are adopting more cloud-based platforms.  The normal methodology to keep software internal no longer applies to cloud platforms.  Security is no longer localized to a corporate infrastructure.  Instead, companies are deeply reliant on the vendor’s security practices to protect their data.  If the company’s vendor has weak security, it exposes the company to additional risk.  The distribution of security responsibilities requires companies to scrutinize their vendor’s security and forces their vendors to meet their own corporate security controls before they allow the usage of new products.

CISO organizations are typically seen as conservative and risk averse due to the rigor they use to evaluate new products. Sometimes the process takes many months — answering questionnaires, security meeting, and running various penetration tests. In my experience of being on both sides of the fence — buyer of enterprise software products and seller of enterprise software — I believe CISOs are evaluating at three critical dimensions of your security program:

1. Trust
2. Technology
3. Transparency

1. Trust

It requires a company to have collateral and a strong relationship with the vendor’s security team.  Trust is not immediately earned.  Customers trust leaders who have experience working with enterprise security teams.  Leaders who have contributed to the security community, either by publications or participation in the security community, immediately earn more trust from customers.  Other areas where customers gain more trust is with the maturity of the company’s security program.   A mature security program will have good security collateral and a long history of certifications.

The collateral should have a detailed description of the product.  Not just the highlights in a white paper with security keywords, but comprehensive white papers that explain the security methodology, security architecture, and the product's security controls. This document must be catered to a security professional in specific domains.  For example, there should be an application security section that discusses the vendor’s secure software development lifecycle and ensures the product addresses the OWASP top vulnerabilities.  Data handling must be defined from the client to where it is stored in the service.  The documentation is the first component required to gain customer trust.  The vendor must share third-party audit reports.

Vendors must have some third-party attestations to confirm security controls are in place.  The vendor can say they are performing security, but a third party audit report validates that the vendor has the controls in place. Here are some types of control validation: ISO 27001 certification or SOC2 audit attestation.  If there are some regulatory requirements (i.e. GDPR, HIPAA, GLBA), these must be addressed in forms of an additional audit report focused on specific controls. In some cases, these controls are incorporated in ISO or SOC2 controls.  At a minimum, vendors must have an audit report that contains audit data showing more than six months of control data.  A SOC2 Type 2 report is an example of an acceptable report.

2. Technology

Choosing technology requires a deep understanding of the platform.  Just choosing a product simply to meet a compliance requirement doesn’t necessarily protect a platform.  It is important to consider the environment before choosing the tools to monitor and protect it.  An example is purchasing a traditional IDS that worked well in the data center but will not be effective in a public cloud platform like Amazon Web Services (AWS).  In AWS there is no way to get complete access to the low-level network traffic using traditional Intrusion Detection System (IDS) detection methods.  Instead, an AWS specific service that has access to the AWS control plane is more effective.  Only an AWS native platform will work be able to have visibility to anomalies across the infrastructure.

Infrastructure monitoring is a requirement for effective protection.  Monitoring must be in place that watches the network, systems, and logs.  All the data should be delivered to a protected centralized platform designed to correlate these actions and is tuned to alert on specific types of events.  A properly configured system will be tuned for normal behavior and anything outside normal behavior will alert the security team.

Using logical segregation is an effective way to ensure data isolation.  Data isolation protects data from being shared with another customer preventing accidental exposure.  To properly isolate customers, vendors can configure a separate environment for each customer where their data is stored.  In AWS, a VPC can be configured per customer.  Any connection to VPCs can be accomplished by either VPC peering, VPN, or a Direct Connect.  Having multiple options is ideal, because one type of connection may not meet some company’s security requirements.

Encryption must be leveraged across the platform, especially in a public cloud environment.  In a public cloud environment, there are many shared resources and encryption is the only way that you can adequately protect important data from being exposed.  This applies to data in transit and data that is stored.  Data in transit must be protected by an encrypted channel like TLS.  This applies to both the connection from the client to the service and connections between services inside the infrastructure.

Data stored in a public cloud must be encrypted at a minimum using a file system level encryption.  In AWS, a Key Management System (KMS) is used for file level encryption. KMS has the flexibility to have the encryption key owned by the customer or by the service provider.  The advantage of allowing the customer to control their key is that they can have the confidence if they delete the key, that their data is not retrievable — especially if the storage is repurposed for another customer.

3. Transparency

Telling a customer that their data is safe without sharing how it is protected quickly deters a customer.  Sharing the methodology will give them the assurance that their data is protected.  A mature security program should run under an information security management system (ISMS).  This system should clearly define the way security is practiced in the company.  The ISMS should have provisions to share information with the customer in forms of audit reports and scan reports.  Here is what should be shared:

Penetration test results — Making third-party penetration test results available to the customer will gain the trust of most corporate security teams.  Third-party penetration tests must be performed more than once a year.  In addition to sharing a vendor-sponsored third-party penetration test, the customer should perform tests on the vendor’s platform with the agreed-upon scope.

Dynamic and static code scans — Vendors must perform dynamic and static code scans on their product on a regular cadence using an industry-recognized tool.  These reports should be shared no less than semi-annually.

Vulnerability scan results — Frequent network and system scans should be made available to customers.  These scans should be performed no less than quarterly.

Architecture details — There must be details to the environment shared with the customers. The details should be high-level to where the customer can understand how the product is put together.  This includes high-level diagrams of the services and physical and logical divisions.

Data flow and persistence —  Share how the customer data flows through the vendor’s infrastructure.  The documentation must detail where, what, and how data is stored.

Access — The vendor must provide clear documentation and visibility to who has access to their data and the safeguards to prevent any unauthorized users from accessing company data.

Building a Security Program Around the 3Ts — Trust, Technology, and Transparency allows technology companies to partner with CISOs to extend their security model and protect their customers.