Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Cloud

2/13/2019
10:30 AM
Jaspreet Singh
Jaspreet Singh
Commentary
Connect Directly
LinkedIn
Twitter
RSS
E-Mail vvv
50%
50%

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.

Jaspreet Singh, Founder and CEO of Druva, brings a combination of product vision and general manager experience that has allowed Druva to be one of the fastest-growing companies in the $28 billion data protection and management market. His entrepreneurial spirit enabled him ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Data Privacy Protections for the Most Vulnerable -- Children
Dimitri Sirota, Founder & CEO of BigID,  10/17/2019
Sodinokibi Ransomware: Where Attackers' Money Goes
Kelly Sheridan, Staff Editor, Dark Reading,  10/15/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
2019 Online Malware and Threats
2019 Online Malware and Threats
As cyberattacks become more frequent and more sophisticated, enterprise security teams are under unprecedented pressure to respond. Is your organization ready?
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-18214
PUBLISHED: 2019-10-19
The Video_Converter app 0.1.0 for Nextcloud allows denial of service (CPU and memory consumption) via multiple concurrent conversions because many FFmpeg processes may be running at once. (The workload is not queued for serial execution.)
CVE-2019-18202
PUBLISHED: 2019-10-19
Information Disclosure is possible on WAGO Series PFC100 and PFC200 devices before FW12 due to improper access control. A remote attacker can check for the existence of paths and file names via crafted HTTP requests.
CVE-2019-18209
PUBLISHED: 2019-10-19
templates/pad.html in Etherpad-Lite 1.7.5 has XSS when the browser does not encode the path of the URL, as demonstrated by Internet Explorer.
CVE-2019-18198
PUBLISHED: 2019-10-18
In the Linux kernel before 5.3.4, a reference count usage error in the fib6_rule_suppress() function in the fib6 suppression feature of net/ipv6/fib6_rules.c, when handling the FIB_LOOKUP_NOREF flag, can be exploited by a local attacker to corrupt memory, aka CID-ca7a03c41753.
CVE-2019-18197
PUBLISHED: 2019-10-18
In xsltCopyText in transform.c in libxslt 1.1.33, a pointer variable isn't reset under certain circumstances. If the relevant memory area happened to be freed and reused in a certain way, a bounds check could fail and memory outside a buffer could be written to, or uninitialized data could be disclo...