Nothing Common about the Common Criteria Security Certification

CYBERSECURITY

Nothing Common about the Common Criteria Security Certification

Needless to say, companies are starting to be more proactive about their approach to security, and choosing the right enterprise database is an important part of keeping data secure. Following up on the recent press release announcing MarkLogic’s Common Criteria security certification, I sat down with MarkLogic’s Lead Security Engineer, Tom Thomassen, to learn why the security certification is a big deal. Tom joined MarkLogic in 2015 and has over 20-years of experience working in tech, including over 10 years of experience at Symantec where he worked on product development and standards around security.


Matt Allen: MarkLogic just got a Common Criteria certification… What is that exactly?

Tom: Yes, we just finished the Common Criteria certification process for MarkLogic 8. The Common Criteria for Information Technology Security Evaluation is an international standard for security by which vendors demonstrate their commitment and ability to provide security to their customers.

Getting the certification is a rigorous process. The certifying authority runs through a battery of tests against the MarkLogic database security target to ensure they get the expected results. They test across various areas such as authorization, authentication, security vulnerabilities (e.g., cross-site request forgery), and the product does not pass the certification process unless it succeeds in each area. So, if we say we do authentication on a MarkLogic cluster when it’s setup in a certain way, they ensure that it works like our documentation says it does.


Matt Allen: So, why is the Common Criteria certification important?

Tom: The Common Criteria is the most widely recognized security certification for IT products in the world—including databases. There are 25 countries, including the United States, Canada, India, Japan, Australia, Malaysia, and many countries in the EU, that all mutually recognize the certification.

Other standards supported by MarkLogic are important as well, such as FIPS 140, but these are more narrowly scoped than Common Criteria which is widely recognized and is the standard that all major database vendors such as Oracle, Microsoft, and IBM continue to certify against, some of them even doing a certification every year. In total, there are only six database vendors that have earned a common criteria certification, and we’re proud that MarkLogic is one of them.

Common Criteria is also a certification which is specifically requested by customers. They know database security is critical, and they want to ensure that third-party experts have tested the product they are buying rather than them finding out about some security vulnerability down the road when the database is already in production.

Another element of testing is the evaluation of how the product is delivered—the process involved in getting the software delivered, installed, and running in a customer’s environment. This is often overlooked, but we think maintaining a high level of consistency in delivery is important, and we’re glad the Common Criteria looks at this aspect as well.


Matt Allen: And Common Criteria helps distinguish us from other NoSQL vendors, too, right?

Tom: Yes, absolutely. We were the first NoSQL database to get the certification with MarkLogic 4 and again with MarkLogic 6. We’re very proud to say that with this certification of MarkLogic 8, MarkLogic remains the only NoSQL database on the list of certified vendors. It’s a big differentiator. So, while it’s a common standard for the industry, it’s not common at all among NoSQL vendors.

Note: You can see a list of certified databases here.


Matt Allen: What differentiates MarkLogic security?

Tom: MarkLogic provides all the security capabilities customers expect from an enterprise-grade database. That sounds pretty straightforward, but the surprising thing is that most NoSQL databases actually lack a lot of the enterprise features that you would think would be quite standard.

One example is fine-grained authorization. MarkLogic provides fine-grained authorization with Role Based Access Control, or RBAC. To access documents stored in MarkLogic, a user has to have an authorized role. Essentially, there’s an ‘invisible query’ that runs in front of every query a user runs to ask the database whether that user has the correct role to see a particular document. This fine-grained access control is superior to the all-or-none-access mechanism typical of non-Enterprise Database vendors.


Matt Allen: I read that another feature, ACID transactions, is sometimes considered a security feature. How is that related to security?

Tom: Most people wouldn’t think of ‘ACID transactions’ as a security feature, but it is. The building blocks of security are “CIA”, which stands for “Confidentiality, Integrity, and Availability” (not the three letter agency based in Langley). Without ACID transactions, a database might lose data or run into race conditions that sacrifice data integrity. Transactional consistency is essential for ensuring highly available and accurate data, the “I” and “A” parts of the CIA security triad.

MarkLogic is the only leading NoSQL database vendor to provide support for ACID transactions. MarkLogic also has high availability and disaster recovery capabilities and great support for backup and recovery. In short, security means protecting and securing data across the board and MarkLogic has focused on the entire CIA trifecta for many years.


Matt Allen: What advice do you have for new ML customers regarding security?

Tom: We should never discount the role played in database security by the human element. This means having a keen understanding of how users interact with the technology, and not thinking that because the database has certain security and availability features, your organization’s data cannot be mismanaged. You have to consider the human aspects—how users put the software into use, how social engineering can compromise access controls, and other aspects such as physical and network security.

There have been plenty of reports about internet-facing NoSQL databases that were insecurely configured, leaving critical data exposed to the internet. But, in many cases, data was exposed because administrators did not take the time to properly configure security. We work hard to make MarkLogic security easy to configure and use, but some responsibility for maintaining good security always involves the user. In other words, we can provide a vault with an unbreakable lock, but the user still gets to decide who has the keys to get in.

It’s also important to look at a company’s general view towards security. There are some companies that may sacrifice security in the name of supporting data integrity and ease-of-use. This is a false dichotomy. MarkLogic, for example, has focused intently on having all of the key enterprise features from the start, and that’s one of the reasons why MarkLogic successfully powers ‘mission-critical’ applications in government and financial services, which generally have some of the most stringent security requirements.

Note: You can read more about MarkLogic security in our docs.

Sponsored by MarkLogic

You may also like...