Lessons Learned from a Hard-Hitting Security Review
Information security is a corporate posture and must be managed at all levels: systems, software, personnel, and all the key processes.
About two years ago, our company found itself in late-stage service contract negotiations, and a mandatory security review as part of the process, with a Fortune 500 technology company in the Bay Area. This engagement turned out to have a significant influence on our thinking about security. At the time, Druva already had undergone almost all major cloud security compliance and certifications, including ISAE 3402 and the infamous FedRAMP (FedRAMP has authorized only slightly over 30 software-as-a-service products). However, this experience changed our outlook on security.
Information security is of increasing importance not only to all industries but the nation. If recent breaches have taught us anything, it's that security is all about the weakest link. Even if you're confident in your own technology, security can be a challenging learning experience and raise questions you've never thought about before. After being in such situations with some of the largest Fortune 500 companies, I've also learned it can be an opportunity to build a long-term competitive advantage.
Most security reviews consist of very similar (and sometimes rudimentary) questions around encryption, penetration testing, and compliance. In short, I was not worried about the extensive security review we were asked to undergo.
But when this particular review took longer than expected to complete, I started to get personally involved and was pleasantly surprised to see some really thorough questions. Some of them I still vividly remember:
Who has the authority to delete customer data?
How do you prioritize customer patching for zero-day attack?
What systems does the CEO have access to?
How many AWS region failures can your software tolerate?
How can you guarantee data durability over five years? How do you handle bit-rotting?
Security is all about the weakest link. And clearly, this customer had gone through practice challenges around security and was asking questions beyond the usual ones relegated to software.
While we had accounted for most of these situations in our product architecture, it was a great learning curve for us and helped improve our thinking. We went through almost 100 of these questions and then discovered that doing so just meant we had qualified for the real test. For the next phase, we met with the security team, which tested us thoroughly on software architecture.
There was one conversation that I distinctly remember:
Security expert: What information can I get if I physically access memory of Druva’s servers?
Druva rep: We run on AWS and any physical access is not possible.
Security expert: What if I use liquid nitrogen to freeze memory?
Druva rep: Not possible.
Security expert: What if I show you?
Druva rep: Sure … I will give up all my Star Wars collection.
Security expert: Show me the process to handle Linux kernel dumps, and if they are encrypted.
[Weird, awkward silence.]
Druva rep: You win.
Finally, when we thought we were done, we got a surprising call from the company's purchasing department. The team told us further review and validation were needed. We tried to explain that we had just passed the security test, but they insisted we meet them regarding some of their findings.
I would admit that we were slightly arrogant going into the meeting, but what we saw surprised us again. They had done a detailed analysis (through third-party software) of Druva's corporate security and had some tough feedback and questions:
Druva Wi-Fi needs to be secured by radius/identify access.
Why do some of the execs have weak personal passwords?
Do you have endpoint security?
What processes do you have to guard against phishing?
Is there a background check in place for most employees?
What did we learn from this experience? It crystalized the idea that security is a corporate posture and must be managed at all levels: systems, software, personnel, and all the key processes. This customer truly took control of its security through an extensive vetting process, and applied the same principles to all its vendors.
A company that does not approach security holistically as part of its corporate culture will continue to put itself, its technology, its customers, and its partners at risk. At Druva, we manage hundreds of petabytes of customer data, and as a result of all the lessons, we have improved over the years. The main lesson? Security should be a part of every organization's corporate DNA, and we've tried to live up to that.
This still does not mean we think that Druva can never be hacked. As former FBI Director Robert Mueller said, "There are only two types of companies: those that have been hacked, and those that will be." But checks and balances build the corporate immunity toward external and internal threats and greatly limits the exposure of any one such incident.
Related Content:
Join Dark Reading LIVE for two cybersecurity summits at Interop 2019. Learn from the industry's most knowledgeable IT security experts. Check out the Interop agenda here.
About the Author
You May Also Like
Unleashing AI to Assess Cyber Security Risk
Nov 12, 2024Securing Tomorrow, Today: How to Navigate Zero Trust
Nov 13, 2024The State of Attack Surface Management (ASM), Featuring Forrester
Nov 15, 2024Applying the Principle of Least Privilege to the Cloud
Nov 18, 2024The Right Way to Use Artificial Intelligence and Machine Learning in Incident Response
Nov 20, 2024