We frequently get asked about our competitors and, more specifically, about the security implications of those competitors. Our response always consists of two facts. First, you don’t decide overnight to be trustworthy, transparent and accountable. Second, security, trust, data protection and privacy have been strategic Cisco priorities for many years. We weave them into everything that we do. We’ve been put under the microscope by our customers, media, and the industry. We encourage and embrace that scrutiny. There should be no such thing as implicit trust in today’s world. In fact, we believe the standards should be set higher, not only for Cisco but for all technology providers around the globe, to shift the role from a vendor to a trusted partner.
We have listened to our customers’ cybersecurity priorities and concerns as a guide to help shape our company, all with a goal of being a trusted partner at every step. It is not enough for a vendor to say their products are technically secure or to say their company behaves in a trustworthy way. Vendors must explicitly demonstrate a range of behaviors that prove they are a trusted partner and integrate those behaviors consistently throughout their operations.
Being a trusted partner is not a guarantee that things will never go wrong – no one is perfect. However, it does mean taking precautions to help avoid things from going wrong and acting with integrity when something does go wrong. To further the point, we’d like to share a few things we’ve learned along the way and the actions we have taken to strive for and maintain trusted partner status.
A Secure Development Lifecycle (SDL) is a must do. A SDL is a documented, repeatable, and measurable process to ensure security is built into solutions by design and that security policy is implemented consistently. It ingrains end-to-end integrity across solutions and ensures that security requirements evolve based on the threat landscape. Our SDL has roots back to 2002 and was formally established in 2009. We’ve been through this process for 4,600 releases across more than 400 Cisco product families. We also report our product security metrics to the Cisco Board of Directors. We take it very seriously, with an entire organization dedicated to the proper execution and enforcement of our SDL.
The core of any SDL must consist of secure and consistent coding. From our new developers to our veterans, all levels are tasked with following secure coding standards and best practices that help ensure threat-resistant code and rigorous control of our development environment. In doing this, we know exactly where certain pieces of code are, when and where to patch bugs, and who is ultimately accountable for the security of the code that has been developed. We use Cisco vetted and maintained security modules to reduce security issues, such as excluding known vulnerabilities, while enhancing the engineers’ ability to confidently deploy security features. For example, six years ago we realized how important it was to control encryption related code in our products. Today, CiscoSSL is embedded in over 425 product families we ship today.
Even with a strong SDL, Cisco acquires new technology, consumes software that we don’t develop, and continues to push our own innovation forward. Ultimately, this means bugs and vulnerabilities can still happen. Becoming a trusted partner not only means having a mechanism in place to pinpoint when and where bugs or vulnerabilities pop up – it also means that when you fix them, you fix them in all impacted solutions. This applies to our own and third-party code, and it means transparently disclosing them to all our customers simultaneously when they do. To meet this need, Cisco was one of the first technology companies to address Third-Party Software (TPS) and implement an TPS tracking system for all products we build. For the past ten years, we have continuously improved a system that requires our engineering teams to govern the risks of all TPS used in hardware and software that Cisco distributes. Today, we’re proud to say, a solution cannot ship or go live unless all TPS has been disclosed and all identified security and legal requirements are addressed. In terms of disclosure, we report vulnerabilities found externally and we also report those we find ourselves, internally. Transparency is a critical element in operating as a trusted partner; this is one of the ways we demonstrate the act of transparency to our customers.
Certification and attestation are necessary milestones on the journey to explicit trust. One of the ways we showcase the trustworthiness of our solutions is by achieving global certifications. We work with global governments and regulatory bodies to ensure our solutions meet the latest requirements as well as provide input on how to improve those requirements and help secure the many markets we do business in. In fact, earlier this month one of our cloud services received an attestation report meeting the BSI Cloud Computing Compliance Controls Catalogue (BSI C5). Due to our consistent development process, and aligning our security engineering standards to global standards, we’ve been able to build our solutions to pass multiple verification checkpoints along the way. These verification checkpoints are often necessary, but not sufficient to win the trust of our customers. We often work with customers to validate explicitly, with targeted assessments that go above and beyond these standard checkpoints. This is a critical ‘trust but verify’ step.
The path to earning and maintaining the position of trusted partner is a privilege, and one which never fully ends. Most of these practices take years to fully incorporate into a vendor’s operations. It takes time, investment, the right talent and an overall cultural commitment. Trust is not a light switch you flip on to respond to competition or a media cycle. It takes years to build an organization that systemically thinks about – and implements – Security and Trust with a commitment to continual improvement and company-wide innovation.
We encourage you to be vigilant as you evaluate your vendors. Do not make another ICT purchasing decision without demanding that your vendors prove themselves with explicit trust. Get them to show, not just tell, how they’re incorporating trusted partner elements into every facet of their business.