Townsend Security Data Privacy Blog

A Checklist for Meeting Compliance

What Information Do I Need to Protect with Strong Encryption?

Organizations starting an encryption project always have this question on their minds. It is a simple question, but can be hard to answer. Generally speaking, you should encrypt any information that alone, or when combined with other information, can identify a unique, individual person. This is called Personally Identifying Information, or PII. This should be your starting point, but you may need to address other information depending on the compliance regulations you must meet.

[For even more information on encrypting data in MongoDB, view our Definitive Guide to MongoDB Encryption & Key Management.]

---

Quicklinks:

Federal/State Laws and Personally Identifiable Information (PII)

EU General Data Protection Regulation (GDPR)

Educational Information Covered by FERPA

Federal Agencies and FISMA

Medical Information for Covered Entities and HIPAA/HITECH

Payment Card Data Security Standard (PCI DSS)

Financial Data for FFIEC Compliance

 

Federal/State Laws and Personally Identifiable Information (PII)

Federal and State laws vary in terms of what they consider Personally Identifiable Information (PII), but there is a lot of commonality between them. PII is any information which either alone or when combined with other information, which can identify an individual person. Start with this list of data items:

• Social security number
• Credit card number
• Bank account number
• First name
• Last name
• Address
• Zip code
• Email address
• Birth date
• Password or passphrase
• Military ID
• Passport
• Drivers license number
• Vehicle license number
• Phone and Fax numbers

 

EU General Protection Regulation (GDPR)

Under the GDPR youmust protect the personal data of an individual. The definition of “personal data” is quite broad and includes “any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person”. This includes, but is not limited to:

• Social security number
• Credit card number
• Bank account number
• First name
• Last name
• Address
• Zip code
• Email address
• Medical information
• Birth date
• Password or passphrase
  
• Military ID
  
• Passport
  
• Drivers license number
  
• Vehicle license number
  
• Phone and Fax numbers

Personal data is broadly defined so an excess of caution should be applied to protection of individual information.

 

 

Educational Information Covered by FERPA

Educational institutions who fall under the FERPA regulations must protect Personally Identifiable Information (see above) as well as the following information:

• Student name
• Student ID number
• Family member names
• Place of birth
• Mother’s maiden name
• Student educational records
• Immunization records
• Health records
• Individuals with Disabilities (IDEA) records
• Attendance

 

Federal Agencies and FISMA

Federal agencies must evaluate their systems for the presence of sensitive data and provide mechanisms to insure the confidentiality, integrity and availability of the information. Sensitive information is broadly defined, and includes Personally Identifiable Information (see above), as well as other information classified as sensitive by the Federal agency. Sensitive information might be defined in the following categories:

• Medical
  
• Financial
  
• Proprietary
  
• Contractor sensitive
  
• Security management
  
• And other information identified by executive order, specific law, directive, policy or regulation

 

Medical Information for Covered Entities and HIPAA/HITECH

The HIPAA / HITECH Act defines Protected Health Information to include Personally Identifying Information (see above) in addition to the following Protected Health Information (PHI):

• Patient diagnostic information (past, present, future physical or mental health)
• Patient treatment information
• Patient payment information
• Medical record numbers
• Name
• Street Address
• City
• Zip code
• County
• Health plan beneficiary numbers
• Fingerprints and other biometric identifiers
• Full facial photographs and images
• Device identifiers and serial numbers
• IP address numbers and web URLs
• Any other individual identifiable information

 

Payment Card Data Security Standard (PCI DSS)

The Payment Card Industry Data Security Standards (PCI DSS) require that merchants protect sensitive cardholder information from loss and use good security practices to detect and protect against security breaches.

 

If you accept or process credit card or other payment cards, you must encrypt the following data:

• Primary Account Number (PAN)

You must also NOT store, even in encrypted format:

• Track 1 and Track 2 data
• Security codes (CVV, CVV2, etc.)

 

Financial Data for FFIEC Compliance

Banks, credit unions, and other financial institutions must protect Non-public Personal Information (NPI) which includes personally identifying financial information (see above). In addition to Personally Identifying Information above, you should protect:

• Income
• Credit score
• Collection history
• Family member PII and NPI

 

Encrypting Data in MongoDB

Townsend Security is helping the MongoDB community encrypt sensitive data and properly manage encryption keys. Developers who need to protect sensitive data know that storing their encryption keys within MongoDB puts their data at risk for a breach. With Alliance Key Manager for MongoDB, administrators are now able to keep their encryption keys secure by storing them remotely and only accessing them when the encryption/decryption happens. 

Alliance Key Manager for MongoDB is an enterprise key management solution that allows you to easily encrypt sensitive data with NIST-validated AES encryption and securely retrieve and manage encryption keys from Townsend Security’s FIPS 140-2 compliant Alliance Key Manager. With an easy to use interface and certifications to meet compliance requirements, you can rest assured knowing your data is secure.

 

 

 

LIMIT OF LIABILITY/DISCLAIMER OF WARRANTY:

THE PUBLISHER, THE AUTHOR, AND ANYONE ELSE INVOLVED IN PREPARING THIS WORK MAKE NO REPRESENTATIONS OR WARRANTIES WITH RESPECT
TO THE ACCURACY OR COMPLETENESS OF THE CONTENTS OF THIS WORK AND SPECIFICALLY DISCLAIM ALL WARRANTIES, INCLUDING WITHOUT LIMITATION WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE. NO WARRANTY MAY BE CREATED OR EXTENDED BY SALES OR PROMOTIONAL MATERIALS. THE ADVICE

AND STRATEGIES CONTAINED HEREIN MAY NOT BE SUITABLE FOR EVERY SITUATION. THIS WORK IS SOLD WITH THE UNDERSTANDING THAT THE PUBLISHER IS NOT ENGAGED IN RENDERING LEGAL, ACCOUNTING,
OR OTHER PROFESSIONAL SERVICES. IF PROFESSIONAL ASSISTANCE IS REQUIRED, THE SERVICES OF A COMPETENT PROFESSIONAL PERSON SHOULD BE SOUGHT. NEITHER THE PUBLISHER NOR THE AUTHOR SHALL BE LIABLE FOR DAMAGES ARISING HEREFROM. THE FACT THAT AN ORGANIZATION OR WEBSITE IS REFERRED TO IN THIS WORK AS A CITATION AND/OR A POTENTIAL SOURCE OF FURTHER INFORMATION DOES NOT MEAN THAT THE AUTHOR OR THE PUBLISHER ENDORSES THE INFORMATION THE ORGANIZATION OR WEBSITE MAY PROVIDE OR RECOMMENDATIONS IT MAY MAKE. FURTHER, READERS SHOULD BE AWARE THAT INTERNET WEBSITES LISTED IN THIS WORK MAY HAVE CHANGED OR DISAPPEARED BETWEEN WHEN THIS WORK WAS WRITTEN AND WHEN IT IS READ.

IBM i (iSeries, AS/400) users can now meet PCI security recommendations for multi-factor authentication with a mobile-based solution.

Today Townsend Security announced a major enhancement to Alliance Two Factor Authentication for IBM i to fully support the new Payment Card Industry (PCI) recommendations for multi-factor authentication with Authy. Authy (A Twilio company) is one of the most popular mobile-based authentication solutions and is in wide use to protect web credentials.

Townsend Security’s support for Authy means that IBM i (iSeries, AS/400) users can now deploy a popular and low-cost two factor authentication product without the expense of back-end hardware servers and hardware tokens. The Authy application installs on your mobile device or in your browser and provides Time-based One Time Passwords (PIN codes) on demand. Since Authy TOTP codes do not require a mobile network connection or an Internet connection, they are immune from gaps in connectivity to the network. Authentication on the IBM i platform simply requires opening the Authy application on your phone, viewing the one time code, and entering it on your IBM i signon screen. Alliance Two Factor Authentication then verifies the code with the Authy service and allows access to the IBM i platform.

Alliance Two Factor Authentication also now implements multi-factor authentication that is compliant with the new PCI guidance which requires that a user enter a user ID and password (something they know) at the same time that they enter their one time code generated by Authy on the mobile device (something you have). The Townsend Security solution implements a secondary user ID and password to use with Authy authentication to meet this level of compliance. A failed authentication on the IBM i server never discloses whether the user ID and password were invalid, or whether the one time code was invalid. This logic prevents the disclosure of important credential information that is common in Two Step Verification. An additional benefit to using the Authy application is that recovery from the loss of a mobile phone is simple and straightforward.

Because Authy uses a secure, time-based one time code and does not use SMS text delivery, it is secure and meets security best practices for authentication. Townsend Security’s Alliance Two Factor Authentication solution continues to support SMS text delivery of one time codes, but the new Authy facility is the default for new installations.

“IBM i users need an affordable two factor authentication solution that removes the expense and headaches of hardware-based solutions. By using your mobile phone for the generation of one time codes, you never have to worry about administering a large number of hardware tokens,” said Patrick Townsend, CEO of Townsend Security “The Authy service is secure, extremely affordable, easy to administer, and highly performant. IBM i customers can install Alliance Two Factor Authentication in a few minutes, provision an Authy account on their web site, and be using two factor authentication very quickly. It’s a fast path to PCI compliance and better security.”

You can find the PCI guidance document here.

Alliance Two Factor Authentication is licensed on a per logical partition (LPAR) basis, with perpetual and subscription licensing options available. Existing Alliance Two Factor Authentication customers on a current maintenance contract can upgrade to the new version at no charge.

The IBM i DB2 database team implemented column level encryption through Field Procedures (FieldProc) in release 7.1 of the IBM i operating system. It was a great step forward for those IBM i customers who need to encrypt sensitive data to meet compliance regulations and to improve overall security. With release 7.1 it was now possible to implement DB2 encryption without modifying user applications.

Prior to this enhancement to DB2 in release 7.1, implementing encryption could be a laborious process of modifying applications and performing extensive regression testing. This approach did not work well with some types of fields (date, time, etc.) and many IBM and third-party query utilities just did not work correctly. So the DB2 enhancement for Field Procedures was a great step forward.

While FieldProc worked well with native SQL applications in release 7.1, there were limitations for older RPG and COBOL applications, and many IBM query utilities did not work correctly with encrypted indexes. Many IBM i customers use IBM and third-party query programs for rapid development of reports and displays of data. Some customers that I’ve talked to have thousands of queries in their application mix, so limitations of IBM query with FieldProc represented an insurmountable challenge for many. When FieldProc was used to encrypt an index or key field, queries just would not work correctly and data was missing or out of order in reports and displays.

But there is some good news!

Starting with the 7.2 release of the IBM i operating system, many of the IBM query applications were updated to work with the native DB2 SQL Query Engine (SQE) by default. The SQL Query Engine has never had a problem with encrypted indexes. This means that the IBM query applications now work seamlessly with data that is encrypted with FieldProc in DB2. You can fully deploy column level encryption across multiple index columns with FieldProc, and your queries will work fine.

Many IBM i customers experimented with FieldProc in the first release in version 7.1 of the operating system and decided to take a pass. If you had that experience it is time to take another look at DB2 FieldProc encryption. The current version of the IBM i operating system is 7.3 and most IBM i customers have upgraded to this release. You now have good support for IBM queries, the SQL Query Engine, and DB2 FieldProc encryption.

While some challenges remain for older OPM and ILE RPG applications, we’ve been able to help a number of customers meet these challenges.

Encryption of data is a core part of a defense-in-depth strategy. We have to do a lot of things to protect our IBM i data, and one of those things is to encrypt the data at rest with industry standard encryption algorithms. DB2 Field Procedures provides the path to achieving this.

To read more about IBM i support for SQL Query Engine in query applications such as RUNQRY, OPNQRYF, and others, see this link.

Our Alliance AES/400 Encryption solution provides full support for DB2 Field Procedures, is easy to deploy, and affordable for every IBM i customer. 

For industry standard encryption key management you can deploy our Alliance Key Manager solution which is seamlessly integrated with DB2 Field Procedure encryption.

Patrick

The European General Data Protection Regulation (GDPR) is a radical and transforming event in the information technology space. Due to go into full effect on May 25, 2018, it will require major changes to IT systems and they way organizations relate to their customers, employees, and external partners. It is hard to overstate the the impact of the regulation. Organizations of all sizes and types, and cloud service providers small and large, must adjust to the notion that people now fully own information about themselves - and companies outside of the EU zone are impacted, too.

Article 17 of the GDPR focuses on the “Right of erasure”, also known as the “Right to be forgotten”. Here is a link to that section.

Let’s talk about how we can use encryption and key management to help meet the requirements of the legislation. Since deploying encryption will also help meet the privacy requirements of GDPR, the same technology can be used to implement Right of Erasure.

First, let’s look at the technology landscape related to encryption:

Encryption is one of the most well understood mechanisms for data privacy. There are well-established, mature standards for encryption and the related key management technologies. Most companies will use encryption to meet GDPR privacy requirements, and will be deploying encryption key management to protect the keys. There are mature encryption technology solutions available on all major enterprise operating systems and on all major cloud platforms. Protecting encryption keys is also well understood. Many organizations have already deployed encryption in some parts of their organizations, and GDPR will speed this process and extend protections across all parts of the data landscape.

The hardest part of getting encryption right has to do with creating, protecting, and deploying encryption keys. It is probably the hardest part of getting an encryption strategy right - and there are a lot of ways to get key management wrong:

• Storing the unprotected encryption key with the protected data
• Using weak protection methods to secure encryption keys
• Storing the encryption key directly in application code
• Using a weak encryption key - a password is an example of a weak key
• Not using strong, industry standard methods of generating an encryption key
• Not providing separation of duties and dual control around key management

There are lots of ways to get encryption key management wrong - and bad key management practices will result in GDPR compliance failures.

Fortunately, it is fairly easy to deploy good encryption key management that is affordable, easy to install and configure, and easy to integrate with your encryption strategy. A number of professional key management solutions are available to serve every enterprise operating environment. We have one (Alliance Key Manager), and others are available.

Now that we have a good encryption and key management strategy in place, let’s use it to meet the GDPR Right to Erasure.

Under GDPR Article 17 a need to erase personal information can be triggered by a number of events:

• A Data Subject (usually a person) can request erasure of personal information
• The personal information is no longer relevant from a business perspective
• A Data Subject withdraws consent and there is no overriding need or requirement to retain the data
• A Data Subject withdraws consent for processing their information
• Personal data has been unlawfully obtained or processed

That covers a lot of ground! It is not as simple as just responding to a request for erasure, we have to be aware of our actual need for information. And erasure triggers some secondary requirements:

• The Data Controller must attempt to remove data that has been made publicly available
• The Data Controller must inform third party Data Processors of the need to erase data

We have a lot of responsibilities under GDPR Article 17. How can we use encryption and key management to meet this requirement?

A key management approach:

Imagine that you assign a unique encryption key to each Data Subject (employee, customer, and so forth) and that you encrypt that person’s personal data in your databases with that unique and specific key. The time comes when must meet your obligations under Right of Erasure. Rather than go through every database table and storage server to delete the data, you could just delete the encryption key. Assuming you have strong encryption keys and industry standard key deletion processes, the deletion of the key is an effective way to zero the protected data without actually modifying the database. Data that is encrypted is unrecoverable if the key is no longer available.

There is one more added benefit to this approach - it effectively erases all of the data on your backups! Managing compliance with GDPR is especially difficult when it comes to off site backups of sensitive data. The ability to effectively erase data by erasing the encryption key without having to pull those backups out of storage is a huge cost and administrative saving!

The strategy described above is only defensible if you are encrypting the Data Subject’s information, if you are assigning them a unique encryption key, and if you are using an encryption key management solution that provably meets industry standards for key zeroization. Our key management solution does and you can get more information here.

We’ve touched just one aspect of GDPR. We will be talking more about GDPR in the days ahead.

Patrick

The security vulnerabilities known as Meltdown and Spectre involving speculative execution logic in a variety of Intel and non-Intel architectures also affects the Townsend Security product Alliance Key Manager through the SUSE Linux operating system. Exploitation of this vulnerability is primarily accomplished through user access to the server environment. Alliance Key Manager does not provide user access to the server. Therefore, the risk of exploitation of this vulnerability is considered low. However, Townsend Security is providing a software update to address this issue.

If you wish to apply this update please contact Townsend Security support. 

A customer service representative will provide you with information on installing the update.

As has been widely noted, you may experience some performance degradation related to the resolution of the Meltdown/Spectre software fix. This will not affect most Alliance Key Manager customers. However, if you process a large number of keys (thousands or more) you may wish to apply the patch to a failover server first and test the performance. Townsend Security will assist you with any performance proof-of-concept if needed.

Please be advised that customers using Alliance Key Manager in virtualized environments (cloud, VMware, etc.) also run some risk related to any hypervisor that is subject to this vulnerability. Please contact your cloud service provider or virtualization software provider for more information.

This year we undertook a survey of organizations to determine how well they are doing in deploying encryption to protect sensitive digital assets. We were curious to see the level of progress organizations were making on this core part of a defense in depth strategy. Because we have information about both IBM i and non-IBM i users, we also wanted to see if there were differences based on the platform they used for their critical applications.

We received responses from over 300 technology users. We felt it was a large enough response to allow us to make some generalizations.

The results were shocking.

Approximately 80 percent of our Windows and Linux respondents had taken some concrete steps to implement encryption to protect sensitive data. In most cases they still had a ways to go to fully protect sensitive data, but that was a lot more progress than I would have imagined. We did not try to distinguish between the particular database in use to store data, but we know that it spanned commercial databases (SQL Server, Oracle, etc.) and open source databases such as MySQL, MongoDB and others.

More Windows and Linux users had made progress with encryption than I would have guessed (sorry).

The real shocker was how few IBM i organizations had made steps to deploy encryption. Only about 6 percent of IBM i users had made any progress in deploying encryption as a part of their security defense in depth. And many of these IBM i users said that they had no plans at all to use encryption for security.

My surprise arises from the fact that I think of IBM i users as generally being more diligent and deliberate around sound system management and security practices. But clearly this is not the case. So what could explain this lapse on the part of IBM i users?

We have some comment data from the survey that points to a general view that IBM i users think their systems are more secure than other platforms. This view is probably a result of IBM’s early investment in security on the platform, and historical messaging about this. Of course we know now that the IBM i platform is subject to data breaches in the same ways that Windows and Linux are, but I believe that this outdated view of the security of the platform now works against IBM i users and leads directly to avoidable data breaches.

Unfortunately, I think there is another source for this lag in security by IBM i customers. There are still too many IBM employees and IBM consultants carrying the message to customers that their systems are more secure than they actually are. I even read a recent comment by a senior IBM engineer that IBM customers should not give much attention to encryption of data on their systems. They should, instead, put more attention on access controls and system security.

This unfortunate message and the myth that the IBM i platform is so secure that you don’t need to worry about encryption is still an unfortunate reality in this community. We know that IBM i users have lost data in breaches. We know that the IBM i server can be breached through weaknesses and vulnerabilities in adjoining networked PCs and servers using classic hacking techniques. A poor implementation of a defense in depth strategy leaves IBM i customers exposed. Because the IBM i server often hosts many back-office applications with rich sources of sensitive data, it is an especially egregious lapse of security.

As a community, IBM i users must do better in deploying a proper defense in depth for their sensitive data. And hopefully thought-leaders inside IBM and outside IBM will recognize the danger of overstating the platform’s native security.

Patrick

Townsend Security, a MongoDB Technology Partner, achieves MongoDB Enterprise Certification for Alliance Key Manager.

Today Townsend Security, a leading authority in data privacy solutions, and MongoDB, the database for modern applications, today announced Alliance Key Manager has certified against MongoDB Enterprise.

MongoDB Enterprise simplifies data protection by providing native encryption of data at rest. When coupled with Townsend Security’s flagship encryption key management solution, Alliance Key Manager, meeting compliance (PCI DSS, HIPAA, etc.) and security standards is even easier and more affordable for large as well as small organizations.      

By centralizing the secure storage of encryption keys and governance with a FIPS 140-2 compliant solution, MongoDB users can easily generate a master encryption key and begin encrypting database keys using native command line operations with Alliance Key Manager.

“Alliance Key Manager for MongoDB gives organizations control of key management in a convenient and fast deployment option. With this joint solution it is simple for customers to encrypt their data in MongoDB Enterprise,” said Davi Ottenheimer, Product Security, MongoDB.

Encryption and key management have become a critical aspect of security and compliance management. Protecting encryption keys mitigates the risk of data breaches and cyber-attacks, as well as protects an organization’s brand, reputation and credibility. Alliance Key Manager addresses these needs by helping enterprises reduce risk, support business continuity, and demonstrate compliance with regulations like PCI DSS, HIPAA, GDPR, etc. 

“In the wake of some of the largest data breaches ever, data security is a top concern for businesses large and small. MongoDB has made it easier than ever for enterprises to secure private data with encryption and key management,” said Patrick Townsend, Founder & CEO, Townsend Security. “With Alliance Key Manager for MongoDB, MongoDB Enterprise customers have access to cost-effective, simplified encryption key management.”

Alliance Key Manager supports seamless migration and hybrid implementations, using the same FIPS 140-2 compliant technology. MongoDB users can deploy Alliance Key Manager as a hardware security module (HSM), VMware instance, or cloud-native Amazon Web Services (AWS) EC2 instance or Microsoft Azure virtual machine. Additionally, Alliance Key Manager supports hybrid and cross-cloud deployments. The solution is available for a free 30-day evaluation.

With mobile-based two factor authentication, Townsend Security offers customers an additional control to protect core security solutions from un-authorized access due to compromised credentials.

Today Townsend Security announces that its flagship Alliance Two Factor Authentication solution for the IBM i (AS/400, iSeries) has been enhanced to support SMS text delivery using the Twilio global cloud communications platform. Twilio’s self-service SMS text delivery platform makes it easy and affordable for customers to provision accounts under a SaaS model. IBM i customers only pay for what they use and can easily expand their use of the service over time.

“IBM i customers want security solutions that are affordable, easy to install, and easy to configure and administer. Our Alliance Two Factor Authentication solution requires no hardware or back-end internal infrastructure to deploy,” said Patrick Townsend, CEO of Townsend Security.

Two factor authentication is now a critical security control that every IBM i customer should be using to control access by highly privileged users. Customers can install Alliance Two Factor Authentication, provision the Twilio service online, and start using two factor authentication very quickly. The software will even identify your privileged users and help immediately enforce two factor authentication. The solution can be downloaded from www.townsendsecurity.com and includes a free 30-day evaluation.

“Many compliance regulations such as the PCI Data Security Standard (PCI-DSS) and others require or strongly recommend the use of two factor authentication (also called multi-factor authentication) to secure all non-console administrative access and all remote access regardless of privileges to core servers. A single IBM i server is often host to a large number of sensitive applications. It is common that IBM i customers run human resources, CRM, ERP and other applications on a small number of IBM i servers that then become a target for cyber criminals. The use of two factor authentication to protect highly privileged users is a security best practice. And it is now very easy to implement,” continued Townsend.

In addition to protecting the logins of highly privileged users, the Alliance Two Factor Authentication product also exposes a command interface to the Twilio SMS text service. This means that IBM i customers can now integrate SMS text authentication directly into their own applications. Need an out-of-band authentication for that multi-million dollar financial transaction? You can now do that directly from your business applications with the Send Text Message with Twilio (SNDTXTTWI) command and application program interfaces (APIs).

In addition to user authentication the new SMS text application support can be used for notification of significant application events. Your business applications can send a message when inventory runs low at a distribution center, when a business process has been delayed, or for any other critical business process. You can even embed links into the text messages to help users quickly solve problems and accomplish critical tasks.

Alliance Two Factor Authentication is licensed on a per logical partition (LPAR) basis, with perpetual and subscription licensing options available. Existing Alliance Two Factor Authentication customers on a current maintenance contract can upgrade to the new version at no charge.

I just got back from the first MongoDB regional conference in San Francisco and wanted to share a few impressions. I will be blogging more about MongoDB, but here are some first impressions from the conference:

We’ve had support for MongoDB encryption key management for some months now, and the conference in San Francisco last week was a real delight. This is an amazing community of developers and users who are innovating and creating new applications based on MongoDB at a rapid pace. I was happy to give the security session on encryption key management for MongoDB and it was a great success. You can find a replay here.

I spent time talking to some of the hundreds of attendees and learned a lot about how the use MongoDB. Here are just a few take-aways:

MongoDB is Easy to Use

Database development has the reputation of being difficult and requiring extensive expertise. But I met a lot of people who have developed MongoDB databases without much or any database administrative knowledge. For example, I talked to a young scientist (that was the title on her badge) who was not in an IT group at all. She had developed a MongoDB database to store and analyze genetics information from her genome sequencing project. I met a pair of IT administrators from a property management company who had developed three applications on MongoDB because their development team had a long backlog of projects. They were in the network administration group and did not have formal experience with database development, but they built applications in a short period of time. It’s truly amazing to see sophisticated applications being developed by users!

MongoDB is Replacing Traditional Relational Databases

Before last week I thought of MongoDB as a big data repository for documents and IoT data. It is that, but it is a lot more. Many of the professionals I talked to at the conference were using MongoDB the way you would use a normal relational database like SQL Server, Oracle, DB2 or MySQL. I had the definite sense that MongoDB has found a way to bridge the worlds of relational databases and unstructured big data repositories. MongoDB users told me that the APIs and toolsets let them do almost anything they wanted to do.

MongoDB Really Scales for Big Data Needs

Well, MongoDB really is a great repository for big data. I talked to a number of larger enterprises from the San Francisco Bay Area who are storing extremely large amounts of data in MongoDB databases. Medical, IoT sensor data, financial data, customer service data and other types of data from a variety of data sources are being collected in MongoDB for business operations support and business analytics. The scalability of MongoDB is truly impressive.

Sensitive Data is Going into Almost All MongoDB Databases!!!

The other thing I learned is that an awful lot of sensitive data is being stored in MongoDB. The database is very flexible, and so there tend to be a lot of data feeds into the database. And those database feeds can include sensitive data that the MongoDB developers do not know about. I heard stories about MongoDB developers being surprised to find credit card numbers, social security numbers, email addresses, medical data and a lot of personally identifiable information (PII) being stored in the database.

MongoDB developers are really aware of the risks of sensitive data in the database. And they were hungry for information on how to protect it. Fortunately MongoDB Enterprise makes it incredibly easy to implement encryption and key management. In my session I was able to show how you can enable encryption in MongoDB with just a few commands. Customers upgrading from the open source Community Edition of MongoDB get access to this encryption facility and it is a delight.

MongoDB is Doing Encryption and Key Management Right

I’ve been impressed with the MongoDB implementation of encryption and key management from the start. First, MongoDB stepped up and implemented encryption right in the MongoDB database. There is no need for any third party file or folder encryption product to sit under the database. The encryption in MongoDB is based on industry standards (256-bit AES) and is tuned for performance. This is exactly what you want - your database vendor taking responsibility for encryption and owning the performance profile.

MongoDB also got the encryption key management part right. They based the key management interface on the open OASIS standard Key Management Interoperability Protocol (KMIP) in order to immediately support a broader community of key management vendors. That made it easier for us to certify our key management solution, Alliance Key Manager, for the MongoDB Enterprise platform. We are happy to support both Intel and POWER chip architectures for MongoDB deployments.

Lastly, just a personal note. I met a lot of MongoDB staff and managers at the conference. What a great bunch of people. They were energized and positive about what they are doing. Every company has its own character, and I found myself happy that we were engaged with this group of people.

Patrick