NoSQL databases have been gaining popularity in the recent years. These solutions offer great flexibility and scalability compared to the traditional relational databases. It's critical to manage the security aspects of the data throughout its life cycle. In this session, I will discuss the security considerations when using NoSQL database solutions, including application (authentication and authorization) and data encryption aspects. Following items will be covered in the presentation: Data Security considerations and requirements in NoSQL world Authentication Role Based Access Control (RBAC) Data Encryption Security Logging and Auditing Monitoring Sample Application with code examples

1. SECURITY CONSIDERATIONS IN
NOSQL DATA ACCESS
NoSQL Now 2011 Conference
Srini Penchikala
08.25.11

2. GOALS AND SCOPE
 Goals:
 Overview of application security aspects of NoSQL DBs
 Best practices of implementing security in NoSQL
 Is Not:
 A NoSQL Security Vulnerabilities talk
 Is:
 Security best practices in applications when using a NoSQL
Database as backend
 Code Examples on Security aspects (Java based)
 Format:
 45 min presentation + 5 min Q&A
2
 Demo’s (Java)

3. ABOUT THE SPEAKER
 Security Architect
 Certified Scrum Master
 Author, Editor (InfoQ)
 IASA Austin Chapter Leader
 Detroit Java User Group Leader (past)
 Working with Java since 1996, JEE (2000), SOA (2006),
Security (2007) & PPT since 01/2011
 Current: Agile Security Architectures, NoSQL Security,
Domain-Driven Design, Architecture Enforcement, MDD
 Future: Role of DSL in Architecture Enforcement, NoSQL
Security Tools and Frameworks 3

4. BEFORE WE START
 How many are currently using some kind of NoSQL
DB to store data?
 How many are currently working as a security
architect or in a related position?
 How many are responsible for managing security in
NoSQL DB space?
 Any regulatory Compliance (Federal, State, Local, or
Finance related)?
4

5. BACKGROUND
 Financial services organization
 J2EE security architecture model
 Agile software development
 Regulatory compliance impact on IT
 Architecture
5

6. AGENDA
 Introduction
 NoSQL and Security
 Current State of NoSQL Security
 Application Frameworks
 Sample Application
 Authentication and Authorization
 Encryption
 Logging
 Monitoring
 Best Practices
6
 Conclusions

7. AGENDA
 Introduction
 NoSQL and Security
 Current State of NoSQL Security
 Application Frameworks
 Sample Application
 Authentication and Authorization
 Encryption
 Logging
 Monitoring
 Best Practices
7
 Conclusions

8. WHAT'S IN A NAME (NOSQL)?
 Is not:
 “No SQL”
 "Never SQL“
 "No Way SQL“
 Is:
 "Not Only SQL“
 "Non-Relational DBMS" (NRDBMS)
8

9. NOSQL, CAP THEOREM AND CIA
 CAP Theorem
 Consistency
 Availability
 Partition Tolerance
 NoSQL impl's are based on the “AP” part of CAP.
 Availability component can also be tied to Security
(“A” in CIA)
9

10. NOSQL – RELATED TOPICS
 Cloud Computing
 NoSQL as a Service (NoSQL on the Cloud)
 NoSQL, Cloud and Security
 CouchDB Moving Into the Cloud (1)
 MongoHQ: Hosted (Cloud) database solution for getting
applications up and running on MongoDB (2)
 Mobile Computing
 Mobile Couchbase for iOS and Android
 Social Computing
 Most of social networking apps use some type of NoSQL DB as
the backend data store.
 Some NoSQL DBs were developed by social computing companies
(e.g. Cassandra by Facebook?). 10
(1) http://architects.dzone.com/articles/couchdb-moving-cloud?mz=36885-nosql
(2) https://mongohq.com/home

11. NOSQL CATEGORIES
 Key Value Stores:
 Data Model: Collection of K-V Pairs
 Voldemort, Riak, Redis, Membase
 BigTable Based/Column Stores:
 Data Model: Column Families
 Cassandra, HBase, Hypertable
 Document Based:
 Document is the basic unit of data
 Data Model: Collection of K-V Collections
 MongoDB, CouchDB
 Map-Reduce
 Hadoop
 Graph Based:
 Data Model: Nodes, Relations, K-V on both elements
11
 Neo4J

12. NOSQL DB'S DISCUSSED IN THIS SESSION
 MongoDB
 Cassandra
 Neo4J
 CouchDB*
 Redis*
 Hadoop/Hbase*
12
*Time permitting

13. WHICH ONE TO USE?
 MongoDB:
 Modeling rich domain objects.
 Apache Cassandra:
 Highly scalable second-generation distributed database
 Dynamo's fully distributed design and Bigtable's Column Family-based data
model.
 Neo4J
 Fully transactional
 Redis:
 Open source advanced key/value store
 Riak:
 Dynamo based key/value store with a distributed database network platform
 Built-in REST server
 Extensible
 Hadoop:
 Distributed data processing, natural language processing, data mining 13
 “Cloud Enterprise Data Warehouse (EDW)”*
*Forrester

14. AGENDA
 Introduction
 NoSQL and Security
 Current State of NoSQL Security
 Application Frameworks
 Sample Application
 Authentication and Authorization
 Encryption
 Logging
 Monitoring
 Best Practices
14
 Conclusions

15. NOSQL AND SECURITY
 Requirement: Provide necessary validation and
security constraints to prevent bad data from getting
into NoSQL data store
 Usage Growth
 Level of security and privacy of data
 noSQL Database Management Systems (At the Peak)
(1)
 Database Platform as a Service (dbPaaS):
 noSQL DB as a Service
15
(1) Gartner's Hype Cycle for Data Management, 2011

16. NOSQL DATA SECURITY
 Data Security: NoSQL v. RDBMS
 NoSQL Data Security Breaches?
 Growth in research and hacker activity targeting NoSQL
databases (1).
 FourSquare outage (MongoDB) (2)
 Software running behind a firewall with inadequate
security
 (In)Secure Design and Coding
16
(1) Source:TeamSHATTER
(2) http://mashable.com/2010/10/07/mongodb-foursquare/

17. AGENDA
 Introduction
 NoSQL and Security
 Current State of NoSQL Security
 Application Frameworks
 Sample Application
 Authentication and Authorization
 Encryption
 Logging
 Monitoring
 Best Practices
17
 Conclusions

18. NOSQL DB SECURITY - CURRENT STATE
 Security Standards:
 Application Security:
 Authentication and Authorization
 Encryption
 Message Level Security
 Database Security:
 Table, Row, Column Level Security
18

19. NOSQL, NO SECURITY?
 Authentication
 Role Based Access Control (RBAC)
 ACLs for Transactional as well as Batch processes/jobs
 Encryption
 Logging
 Monitoring
 Security Vulnerabilities*
19
*We will briefly look at this.

20. NOSQL DATABASES – SUPPORT FOR AUTHN
AND AUTHZ
NoSQL DB Version Authentication Authorization
MongoDB 1.9.1 Y Y
Cassandra 0.8.1 Y Y
Neo4J 1.4
CouchDB 0.11 (Win 1.0.1) Y Y
Hadoop* 0.20.203.0 Y (Kerberos) Y
20
*No installation

21. AGENDA
 Introduction
 NoSQL and Security
 Current State of NoSQL Security
 Application Frameworks
 Sample Application
 Authentication and Authorization
 Encryption
 Logging
 Monitoring
 Best Practices
21
 Conclusions

22. APPLICATION FRAMEWORKS
 NoSQL Data Access:
 Spring Data
 Spring Data Graph for Neo4J (RC Status)
 Spring Redis
 Spring Data – Riak
 Spring Security
 Spring Roo
 Cloud Foundry
 Persistence Layer:
 Hibernate Object Mapping (OGM) for NoSQL Datastores:
 Full-blown JPA engine
 DataNucleus has persistence (JDO/JPA) to MongoDB, HBase,
Cassandra, BigTable etc.
22
 Polyglot persistence

23. AGENDA
 Introduction
 NoSQL and Security
 Current State of NoSQL Security
 Application Frameworks
 Sample Application
 Authentication and Authorization
 Encryption
 Logging
 Monitoring
 Best Practices
23
 Conclusions

24. SAMPLE APPLICATION
 Tools:
 JDK 1.7
 Eclipse
 Neoclipse
 MongoDB/Cassandra/Neo4J
 DBExplorer (using MongoDB JDBC Driver?)
 Security scanner (OWASP LAPSE+)
24

25. AGENDA
 Introduction
 NoSQL and Security
 Current State of NoSQL Security
 Application Frameworks
 Sample Application
 Authentication and Authorization
 Encryption
 Logging
 Monitoring
 Best Practices
25
 Conclusions

26. MONGODB SECURITY
 Listens on all interfaces (by default)
 Authentication:
 Turned off by default (“trusted environment”)
 User passwords are hashed using MD5
 Basic authentication (user name + password in a DB context)
 Per connection authentication
 User in “admin” database: super user
 Authentication with sharding (v1.9.1+)
 Replica Set Authentication
 Authorization:
 Normal user (full read and write access)
 Read-only user (read access)
 No table level access control
 Encryption:
 No database encryption
 Communication with database is not encrypted 26

27. MONGODB SECURITY (2)
 Enable Security:
 “--auth” command line option
 “--keyFile” for replica sets and sharding
 Pre-requisite: Add a user to the admin db.
 Trusted environment
 “--bindip” option (IP based control)
 Administration Interface Security:
 “--nohttpinterface” option
 Server-side JavaScript execution
 “--noscripting” option
27

28. DEMO 1
28

29. CASSANDRA SECURITY
 Package: org.apache.cassandra.auth
 Authentication:
 IAuthenticator interface
 AllAuthenticator (default)
 SimpleAuthenticator (cassandra.yaml)
 Custom Authentication Provider
 Login operation (added in v0.7)
 Authorization:
 IAuthority interface
 SimpleAuthority
 AllowAllAuthority
 Encryption:
29
 Uses MD5 Encryption

30. DEMO 2
30

31. NEO4J SECURITY
 No Security at the data level
 No security on the REST access layer
 Run Neo4J server behind a proxy (mod_proxy)
31

32. DEMO 3
32

33. AGENDA
 Introduction
 NoSQL and Security
 Current State of NoSQL Security
 Application Frameworks
 Sample Application
 Authentication and Authorization
 Encryption
 Logging
 Monitoring
 Best Practices
33
 Conclusions

34. DATA PROTECTION
 Data Loss Prevention (DLP):
 Data at Rest
 Data in Transit
 Data in Use
 Cryptography
 Encryption
 Decryption
 Hashing
34

35. DATABASE SECURITY
 DB Level Security
 Table Level
 Row Level
35

36. COMMUNICATION LAYER SECURITY
 Transport Layer Security
 Message Security
36

37. AGENDA
 Introduction
 NoSQL and Security
 Current State of NoSQL Security
 Application Frameworks
 Sample Application
 Authentication and Authorization
 Encryption
 Logging
 Monitoring
 Best Practices
37
 Conclusions

38. SECURITY LOGGING AND AUDITING
 Logging
 Log4J
 Custom Appender for secure logging
 Security Analytics
 Security BI
 SIEM
38

39. LOGGING BEST PRACTICES
 What data needs to be logged for security analytics
purposes?
 What should be the log format for business v. security
logs?
 Do we need to store the security logs in a different file
(a new log4j appender) so only authorized users
(admin) will have access to it?
 How would the logs work with SIEM tool (if
applicable)?
39

40. AGENDA
 Introduction
 NoSQL and Security
 Current State of NoSQL Security
 Application Frameworks
 Sample Application
 Authentication and Authorization
 Encryption
 Logging
 Monitoring
 Best Practices
40
 Conclusions

41. MONITORING
 Standards:
 JMX - JSR??
 Remote JMX - JSR??
 Tools:
 JConsole/VisualVM
41

42. MONITORING
 MongoDB
 MongoDB Data Profiler
 Cassandra
 JMX
 Integrating JMX
 MX4J
 Neo4J
 JMX support
42

43. OTHER SECURITY USE CASES FOR NOSQL
 MongoDB for Logging
 Capped collections
 Cassandra for Logging
 Neo4J
 ACL (graph data pattern)
 Semantic Web for Security
 Security Ontology
43

44. ACLS - THE GRAPH DATABASE WAY
44
Source: http://wiki.neo4j.org/content/ACL

45. SECURITY VULNERABILITIES
 Connection Pollution
 JSON Injection
 Key Brute Force
 HTTP/REST based attacks
 Server-side JavaScript (SSJS):
 Integral to many NoSQL databases such as MongoDB and
Neo4j.
45

46. NOSQL - POTENTIAL SECURITY
VULNERABILITIES
NoSQL DB Security Vulnerability Notes
MongoDB SQL injection In PHP
MongoDB Blind SQL injection
MongoDB Null Byte Injection
MongoDB/ DOS
SpiderMonkey
CouchDB / XSS Admin interface
Futon
CouchDB String comparison, Timing Attack Authentication
46

47. AGENDA
 Introduction
 NoSQL and Security
 Current State of NoSQL Security
 Application Frameworks
 Sample Application
 Authentication and Authorization
 Encryption
 Logging
 Monitoring
 Best Practices
47
 Conclusions

48. BEST PRACTICES
 Input Validation
 Output Validation (Encoding/Escaping)
48

49. TOOLS AND TECHNIQUES
 NoSQL Development:
 Neoclipse
 Spring Tool Suite (STS) for Spring Data projects
 Security:
 Static and Dynamic (Blackbox) Scanners for NoSQL
 LAPSE+: Security scanner for detecting vulnerabilities in Java EE
Applications.
 w3af (Web Application Attack and Audit Framework)
 Fuzzing: hzzp
 SQL InjectMe
 ZAP
 HackBar
 Test HackBar
 Burp Suite
 Tamper Data 49
 WATOBO
http://resources.infosecinstitute.com/owasp-top-10-tools-and-tactics/

50. DATA ARCHITECTURE CONSIDERATIONS
 Data Security Strategy and Standards
 Data Classification
 Separation of Concerns
 Defense In Depth
50

51. DESIGN CONSIDERATIONS
 Separate persistence layer to apply Authentication
and ACL's in a standard and centralized fashion
 Schema Validator
 Do not store sensitive data in remote storage NoSQL.
 Build the interface with security from day one
 Batch jobs or other utility scripts that access database
outside of typical application interface
51

52. RECOMMENDED APPROACH
 Define your use cases.
 Categorize use cases to see where NoSQL is a good
solution and where it's not
 Separate security requirements out of core business
and data requirements
 Review security requirements and assess if NoSQL is
still a good solution
 Based on security requirements, decide if you should
host your database(s) in your own Data Center or on
the Cloud
52

53. FUTURE ROAD MAP
 MongoDB:
 Encryption/Compression of wire protocol
 stronger password authentication scheme
 Hadoop:
 Pluggable authentication modules
 SAML
 PKI
 Better authorization for Hive and Hbase
53

54. AGENDA
 Introduction
 NoSQL and Security
 Current State of NoSQL Security
 Application Frameworks
 Sample Application
 Authentication and Authorization
 Encryption
 Logging
 Monitoring
 Best Practices
54
 Conclusions

55. CONCLUSIONS
 "One Size Fits All" Fits Nothing
 Involve security early in application development
process (SDLC or Agile)
 Risk based strategy
 RDBMS is not a four letter word
 Hybrid approach (Polyglot Data Storage)
55

56. RESOURCES
 MongoDB: The Definitive Guide
 Cassandra: The Definitive Guide
 CouchDB: http://wiki.apache.org/couchdb/Security_Features_Overview
 Spring Data:
 http://www.springsource.org/spring-data/mongodb
 http://static.springsource.org/spring-data/data-document/docs/current/reference/html/
 http://www.springsource.org/spring-data/neo4j
 http://static.springsource.org/spring-data/data-
graph/docs/current/reference/html/#tutorial_security
 http://www.springsource.org/spring-data/hadoop
 Redis:
 https://github.com/dmajkic/redis
 Authentication
 http://www.mongodb.org/display/DOCS/Security+and+Authentication
 Security Testing Tools:
 http://w3af.sourceforge.net/
 http://www.fiddler2.com/Fiddler2/version.asp
 http://www.sensepost.com/labs/tools/pentest/wikto
 http://sourceforge.net/apps/mediawiki/watobo/index.php?title=Main_Page
56

57. Q&A
57

58. THANK YOU
 Thank you for your attention
 Feedback survey
58

59. CONTACT ME
 Domain-Driven Design, Security and Enterprise
Architecture articles on InfoQ
 website: http://www.infoq.com
 srinipenchikala@gmail.com
 @srinip
 http://srinip2007.blogspot.com
59

60. BONUS SLIDES

61. COUCHDB SECURITY
 Apache project
 Written in Erlang
 HTTP communication (REST+JSON)
 No SSL support
 Only listens on 127.0.0.1 IP Address (by default)
 Authentication Handlers:
 Oauth
 Cookie based
 Default handler
 “Admin party” mode startup (by default)
 Passwords: SHA1 hashing (128-bits UUID salt) 61

62. COUCHDB SECURITY (2)
 Authorization:
 Three types of users
 database readers
 database admins
 server admins
62

63. HADOOP/HBASE SECURITY
 Enabled by default
 Kerberos (v5) based authentication*
 org.apache.hadoop.hbase.security
 Classes:
 HadoopUser
 SecureHadoopUser
 User
 Server authentication is bi-directional
63
*CDH3b3

64. HADOOP/HBASE SECURITY (2)
 RPC Connection Security: SASL “GSSAPI”
 HDFS: Permissions Model
 Job Control: ACL based; includes a View ACL
 Web Interfaces: OOTB Kerberos SSL support
 HDFS and MapReduce modules should have their own
users.
 Middle Tier: Act as broker in interacting with Hadoop
server
 Apache Hive, Oozie etc.
64

65. HADOOP/HBASE SECURITY (3)
 No encryption on the wire.
 Protection again DoS attacks
65

66. REDIS SECURITY
 Even the security will be handled through Redis
rather than the container HttpSession (?)
66

67. RIAK SECURITY
 Built-in REST server
 Webmachine pre-commit hooks
67