NoSQL's weak security can have a negative impact on organizations, says Amichai Shulman, founder and CTO of Imperva. In the new year, more organizations will undoubtedly begin or plan to deploy NoSQL, and the security issues that will come to light once the solution is in place will make it the right choice to prepare for them early.　　As an alternative to traditional relational databases, NoSQL does not use SQL in queries and allows users to change data attributes at any time. Such databases are known for scaling well and can excel in transaction processing tasks that require a large number of applications to interact with the database itself in real time, explains James Phillips, founder and senior vice president of product at Couchbase: "NoSQL is centered on transactional business. It's more focused on real-time processing capabilities and excels at manipulating data directly, which has contributed significantly to the development of interactive software systems," Phillips noted. One of the biggest advantages is the ability to change at any time (in terms of attributes), due to the weakening of structure, the modification process is very convenient.　　NoSQL's Biggest Strengths Impact Its Security One of the key features of NoSQL is its dynamic data model, Shulman explains. I can add new attribute records during its operation. So a security model that matches this structure must have some forward planning. That is, it must be able to understand what changes will be triggered by new attributes introduced to the database and what permissions the newly added attributes have. Yet security concepts at this level do not currently exist, and no such solution exists at all.　　According to Phillips, certain NoSQL developers are already working on security mechanisms that are at least attempting to protect the integrity of the data. In the realm of relational databases, if our data is not composed correctly, it will not work in parallel with the structure, in other words, the data insertion operation will fail as a whole. Various validation rules and integrity checks are now well established, and it turns out that these validation mechanisms work in NoSQL. Similar to the solutions that others have introduced, we trigger the insertion of a new record or document-based rule, and ensure that the inserted data is correct during execution.　　Shulman expects that new users will soon have a hard time with configuration, not because of IT staff negligence, but because NoSQL is a new technology that most people don't have the knowledge base to understand," said Alex Rothacker, manager of Application Security's R&D division, TeamSHATTER. Rothacker echoed these sentiments. He points out that one of the major problems with training is that most NoSQL practitioners tend to be new generations of IT professionals who know a lot about the technology but often lack sufficient experience in security management.　　If they start with traditional relational databases, then they can learn by using them due to the completeness of mandatory security mechanisms. But with NoSQL, only a connoisseur can draw the right conclusions through observation and find a complete security solution after a lot of research work. So probably 90% of the practitioners are not able to do this due to their knowledge base, security experience, or time constraints of their work.　　NoSQL Needs to be Optimized for Security While Phillips agrees that there are differences between new technologies and old experiences, the increased focus on security when promoting NoSQL can have a largely positive effect. He believes that this type of data storage mechanism contains less sensitive information than traditional relational databases and has much less exposure to other applications within the corporate network.　　They don't use the new technology as a database, just as we tend to think of it as a corporate data storage mechanism when we're collecting and organizing large amounts of business data from other applications, he added. Of course, if I'm developing a social network, a social game, or a particular web application with a particular set of features, I'm likely to deploy it under the firewall. That way it's not only tightly integrated with the application, but it's also out of the reach of the rest of the organization.　　But Rothacker also says that such over-reliance on perimeter security for database systems can be extremely dangerous. Once a system is fully dependent on the perimeter security model, authentication mechanisms must be relatively weak and lack security protections for multi-user management and data access. With an elevated privilege account, we can access almost anything in the storage mechanism. For example, Brian Sullivan demonstrated at last year's Black Hat conference how to list and even export information about data without knowing exactly what it is.　　And according to Tim ?TK? Keanini, CTO of nCircle, NoSQL is likely to be exposed to the Internet even when associated with a limited number of applications. In the absence of tight network segmentation, it could be a weak point for attackers to snoop on stored data. Because NoSQL is designed to be used primarily for Internet-scale deployments, it is likely to be directly connected to the Internet and thus exposed to a large number of attacks.　　One of the attacks with the highest chance of occurring is injection attacks, which has been public enemy number one ravaging the relational database space. Just because NoSQL doesn't use SQL as a query language doesn't mean it's immune to the threat of injection attacks. While many claim that SQL injection doesn't work on the NoSQL side, the principle is exactly the same. All an attacker needs to do is change the syntactic form of what they're injecting, Rothacker explained. That means that while SQL injections won't show up, JavaScript injections or JSON injections can be just as much of a security threat.　　It's also likely that attackers will further optimize their tools as they plan their assault on such databases. Immature security technologies often present the dilemma that it takes a lot of time to learn how to secure them, but almost every IT person can quickly learn how to organize an attack campaign. So I think attackers will always be ahead of security deployments, Shulman said. Unfortunately, it's always easier to wreak havoc than to take precautions, and we've already seen a number of public vulnerabilities in NoSQL technology, especially the current hotly debated attacks in the form of JSON injections.　　NoSQL Security Is Not a Hindrance However, none of this should be a hindrance to the use of NoSQL in the enterprise, he concluded. I think at the end of the day, it should be considered a business decision. As long as that choice presents an attractive business opportunity, there's a certain amount of risk to be taken, Shulman explained. But there are steps that should be taken to minimize that risk.　　For example, given the dependence of databases on external security mechanisms, Rothacker recommends that organizations actively consider introducing encryption schemes. He warns that organizations must scrutinize the application code that interfaces with NoSQL. In other words, organizations must be rigorous in selecting the people responsible for the deployment of such projects to ensure that the best talent is used in this area of affairs, Shulman said. When people write applications based on NoSQL, it's important to enable experienced programmers, as the client software is the first barrier against security issues. Realistically allow time and budget for the deployment of additional buffers, which will give employees the time to reflect on what they are doing and try to take security considerations into account. In summary, this is probably no different than deploying a traditional relational database.　　Ironically, the security improvements in database applications in recent years have had little to do with the databases themselves, says Oliver Lavery, director of security research and development at nCircle.