Mitesh Shah, Senior Product Manager for Security and Data Governance at MapR, describes an important concept in big data security: vulnerability management, which is a key layer in the trust model. He explains what is provided by the MapR Converged Data Platform, and what the customer’s role is in terms of maintaining a secure environment.
For more information:
Securing Files in Hadoop at the Right Levels Whiteboard Walkthrough 6 Elements of Securing Big Data ebook by Davi Ottenheimer Sharing Big Data Safely PDF of book by Ted Dunning and Ellen FriedmanHere’s the transcription:
Hi, this is Mitesh Shah, Product Manager for Security and Data Governance at MapR. Today, I’d like to talk to you about a very important concept in security known as Vulnerability Management. It’s an important concept when you’re thinking about securing your big data platform or really any other platform in your environment. We’ll talk more about that today. First, I’d like to talk about where that fits in to the overall trust framework and give you more context than what you see here.
This is our trust pyramid, and it really starts with people and goes into process and then lastly, technology. There is a people, process, and technology component to trusting your big data platform, and there is also an element here of aspects of security that the customer needs to handle and what the vendor needs to handle(in our case,MapR). There’s partnership in some of these components and we’ll talk more about that in the context of Vulnerability Management.
Let’s start with the bottom here at technology. You’ve got, potentially, network and systems protection in place with things like firewalls, for example. That certainly continues in the world of big data and with MapR. Maybe you’ve got some monitoring solutions in place where you’re looking for anomalies, for example, through aggregation and analysis of audit logs. That certainly still remains as well. Maybe you’ve got some identity management solutions―LDAP,Active Directory, Kerberos, KDC.We don’t bundle an identity management solution into our product; we typically tie in to those and leverage your existing user registries. So all of that remains, and that is really what you need to handle from a technology perspective. It’s not meant to be an all-inclusive list, but it’s certainly a good list.
From our perspective, we handle the four pillars of security. This is how we often like to talk about product security―there’s data protection, authorization, authentication, and auditing. We handle each of those in some very compelling ways. With data protection, for example, we allow for encryption at rest through the use of Lux and self-encrypting drives, and encryption on the wire as well when security is turned on.For authorization, we’ve got a great story there with access control expressions, which are basically Boolean expressions that allow for the most expressive assignment of permissions possible on your files, dataase, or Streams. This is really where MapR shines and stands out above the rest. We’ve got the most expressive permissions possible.From an authentication standpoint, we allow for Kerberos, or we allow for the choice of native authentication through tying in with your username and password registries if you would like. So we’ve got a flexible authentication scheme there. From an auditing perspective, we’ve got audit logs that cover access to your data, so anytime somebody accesses files or tables, for example, that action can be logged. Also, authentication requests are logged and administrative operations are logged as well. We’ve got you covered from the four pillar perspective in the technology area.
I’ll cover more about Vulnerability Management in just a second, but before I do that, there is obviously a people element and one thing to think about there is creating policies for things that are not covered by process or technology. Those are things like creating manuals that advise people on how to do things and when to do things. That’s an important component there as well that many customers have chosen to institute.
Now onto Vulnerability Management. By the way, these areas are covered in Davi Ottenheimer’s book, Six Elements of Securing Big Data . I had a webinar with him very recently. Davi is an expert in security, and many of these elements are covered by Davi in detail in his book. When asked which of these elements is most important in the world of big data, or just the most important in general, he does not equivocate. He very clearly states that Vulnerability Management is not only the most important, but potentially the most challenging in the world of big data. Now, why does he say it’s the most challenging? One thing he points to is that often times with big data platforms, we’re incorporating open source components that are often on different release trains and potentially have conflicting dependencies on different Java versions, for example. There is a sort of complexity there, but MapR addresses that with our MapR Converged Data Platform. We have our foundation here with the MapR File System, MapR-DB, and MapR Streams, and we also support ecosystem components like Spark, Drill, and many others.
We have this notion of MapR ecosystem components or MEPs for short, that allow us to say a specific version of Spark, a specific version of Drill, a specific version of Oozie, etc., are certified and compatible before we ship it to you. So you don’t have to worry about these dependencies and all these complexities. We take care of that complexity for you; we extract it out and say this is the version that is compatible.We do that there and obviously with the FS, DB and Streams, these are MapR’s sort of secret sauce, our foundation, our proprietary layer. We would handle vulnerabilities there extremely well. If anything is found here, we will triage the vulnerability, we will rectify it, and we will issue a patch.
Let’s talk more about that patch process now. This is Vulnerability Management. As you can see here, this is really about a partnership between the customer and MapR. From MapR’s perspective―when we find a vulnerability, whether it’s by looking at open JIRAs, via our process in place with third parties to look for vulnerabilities in our software, or we accept the vulnerabilities from you, the customer―no matter what the source, we will look at the vulnerability, we will look at the impact it might have on your data, and we will triage it and fix it in a timely matter. and we will issue the patch. Now, why do we have apartnership? When we issue a patch, we send you an e-mail, and you’ll see it as a notification on the Converge Community . You are then responsible for applying that patch. It’s not just enough for us to send that email. You obviously need to apply that fix in order to no longer be vulnerable to that vulnerability.The second piece here is maybe you have scanning systems in place where you’re looking for vulnerabilities in your other systems, your non big data platform. You should go ahead and feel free to point your scanning software to MapR as well, and if you find anything, let us know about it. We’ll treat it as we would any oth
