Security issue findings and the impact of third-party services

In this article:

Summary

When looking at a company’s digital footprint, SecurityScorecard is assessing the full risk profile of that company, not just a slice of that company’s assets. Assets listed on the Digital Footprint are attributed to an organization by many methods of detection, as documented in our IP Attribution Process (Digital Footprint Mapping) Help Center article. These assets can include third party managed "marketing sites" as well as web assets that could reflect production and / or development test environments. 

Background

In some scenarios, as part of a company’s core product offering, a software service may be delivered. In the course of any Vendor Risk Management program, a company’s software service is usually the subject of vendor investigations and assessments. For example, SecurityScorecard offers our ratings platform as a SaaS delivery and this product is the subject of our vendors’ third party assessments. Given the above scenario, one may ask, why are other assets apart from platform.securityscorecard.io included in the digital footprint and issue generation for the scorecard? The answer is that security risk for the SecurityScorecard organization does not stop at the SaaS offering we provide. The entire attack surface extends far beyond our platform offering and includes things like endpoint patching, third party services like our corporate website, and even the support portal we leverage for service delivery.

Detail

Take a very specific example of our service and support portal. SecurityScorecard currently leverages Zendesk as our platform for support and external knowledge management. The portal is available at support.securityscorecard.com. Currently, Zendesk allows for the setting of HSTS headers via an admin interface on their platform. This is not enabled by default, so if the Zendesk admin does not enable this feature, it will undoubtedly pose a security risk for SecurityScorecard, not Zendesk. Simply by working with the vendor and leveraging their documentation on the feature, we are able to mitigate this risk and enable the setting to allow HSTS headers to be set correctly.

Conversely, sometimes a vendor may not have such a facility to enable a specific security control, and this will adversely affect your security posture. Taking Zendesk as an example again, this vendor does not have the ability to set a CSP header in their product. Because of this, specific workarounds in the product should be explored (like enabling CSP meta tags).

That being said, if the security control is simply abandoned, the risk is present and either needs to be accepted by the organization, or mitigated by searching for a vendor that has the appropriate controls in place. This does not mean that the security risk goes away.

As a Security champion in your organization, we understand that validating the application security stack of your own product offerings is important. That being said, the entire public attack surface of your organization is what is being surfaced on your scorecard, not just that SaaS application.