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 security aspects of some NoSQL DB’s (MongoDB, Cassandra,
Neo4J)
 Best practices of implementing security in NoSQL
 Is Not:
 A NoSQL security vulnerabilities talk
 Comprehensive coverage of security features
 Is:
 Focus on app security: authentication, authorization, logging & monitoring
 Security best practices in applications when accessing a NoSQL Database
 Code Examples on Security aspects (Java based)
 Target Audience:
 Application & Data Architects and Database Developers
 Format:
 45 min presentation + 5 min Q&A
 Demo’s (Java) 2

3. ABOUT ME
 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 responsible for managing data
security?
 How many are responsible for managing security in
NoSQL DB space?
 Regulatory Compliance (Federal, State, Local, or
Finance related)
4

5. BACKGROUND
 Financial Services
 J2EE security model
 Agile software development
 Regulatory compliance and its impact on IT
 Software Architecture
5

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

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

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

9. NOSQL DATA SECURITY CONCERNS
 NoSQL Data Security Breaches?
 Growth in research and hacker activity targeting NoSQL
databases1
 FourSquare outage2
 Software running behind a firewall with inadequate
security
 Poor Secure Design and Coding
9
(1) Source:TeamSHATTER
(2) http://mashable.com/2010/10/07/mongodb-foursquare/

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

11. SECURITY ASPECTS
 Authentication
 Role Based Access Control (RBAC)
 ACLs for Transactional as well as Batch Processes
 Encryption
 Data at Rest
 Data in Transit
 Data in Use
 Logging
 Monitoring
 Security Vulnerabilities* 11
*Not covered in this session

12. NOSQL, NO SECURITY? - CURRENT STATE
 Authentication support
 No comprehensive RBAC
 Data encryption support is limited
 Data security
 No Object level security (Collection, Column)
12

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

14. APPLICATION FRAMEWORKS
 NoSQL Data Access
 Spring Data
 Spring Data Document (for MongoDB) (v1.0.0 M3)
 Spring Data Neo4J (v1.1.0)
 Redis, Riak
 Security
 Spring Security
 Spring Roo (support for Neo4J and Spring Security)
 JPA on NoSQL (for Domain Object Security)
 Hibernate Object Mapping (OGM)
 DataNucleus
 Deployment
 Cloud Foundry
 Supports MongoDB, Redis and MySQL 14
 Polyglot persistence / Cross-store persistence

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

16. SAMPLE APPLICATION
 Tools:
 JDK 1.7
 Eclipse
 MongoDB/Cassandra/Neo4J
 Spring Data Framework
 Spring Security
 Neoclipse
 Security scanner (OWASP LAPSE+)
16

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

18. 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
18

19. MONGODB SECURITY
 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
19
http://www.mongodb.org/display/DOCS/Security+and+Authentication

20. MONGODB SECURITY (2)
 Authorization:
 Normal user (full read and write access)
 Read-only user (read access) (v1.3.2+)
 No table level access control
20

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

22. AUTHENTICATION COMMANDS
 Add User:
 db.addUser("testuser", "testpassword")
 db.addUser("testreadonly", "testpassword",
true)
 Login:
 db.auth("testuser", "testpassword")
 Logout:
 db.logout("testuser")
22

23. DEMO
23

24. CASSANDRA SECURITY
 Package: org.apache.cassandra.auth
 Authentication:
 IAuthenticator interface
 AllowAllAuthenticator (default)
 SimpleAuthenticator (cassandra.yaml)
 Custom Authentication Provider
 Login operation (added in v0.7)
 Authorization:
 IAuthority interface
 AllowAllAuthority
24
 SimpleAuthority
http://wiki.apache.org/cassandra/ExtensibleAuth

25. CASSANDRA SECURITY (2)
 How to Enable Security
 JVM Options
JAVA_OPTS=%JAVA_OPTS% -
Dpasswd.properties=C:/dev/dbservers/apache-
cassandra-0.8.1/conf/passwd.properties
-Daccess.properties=C:/dev/dbservers/apache-
cassandra-0.8.1/conf/access.properties
25

26. DEMO
26

27. NEO4J SECURITY
 No Security at the data level1
 No security on the REST access layer
 Run Neo4J server behind a proxy (mod_proxy)
 Access Control:
 ACL (graph data pattern)2
 Custom Authentication and Authorization Provider
 Spring Data Graph
 Spring Security
27
1) http://docs.neo4j.org/chunked/stable/operations-security.html
2) http://static.springsource.org/spring-data/data-graph/docs/current/reference/html/

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

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

30. ENCRYPTION
 No Data Encryption
 Communication with database is not encrypted
 MD5 Hashing (Cassandra)
30

31. ENCRYPTION BEST PRACTICES
 Symmetric Key Algorithms
 AES with minimum 128 bit key length
 Hash Functions
 SHA-256
 Always use a salt value (salted SHA, SSHA) esp. for passwords to
defend against rainbow table attacks
 Asymmetric or Public Key Algorithms
 rDSA with 1024 bit minimum key length
 Data Integrity
 HMAC (hash function-based message authentication code)
 Secure Network Communication
 SSLv3 or TLS
 Security Standards Java API
 OWASP’s ESAPI library 31

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

33. SECURITY LOGGING AND AUDITING
 Logging
 MongoDB Logger
 Spring Data (MongoLog4jAppender)
 Custom Appender for secure logging
 Security Analytics
 Security BI
 Security Information & Event Management (SIEM)
33

34. NOSQL FOR SECURITY LOGGING
 NoSQL is perfect for security logging
 Files: Easy to store but difficult to read and analyze
 RDBMS: Easy to read but lot of overhead to store
 NoSQL Data Store: Best of both worlds
 Mongo DB demo – logging
 Hashing - tamper proof
34

35. DEMO
 Custom MongoDB Security Logger
35

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

37. MONITORING
 Standards:
 JMX
 Remote JMX
 Tools:
 JConsole/VisualVM
37

38. MONITORING
 MongoDB
 MongoDB JMX Support
 Cassandra
 JMX
 Integrating JMX
 MX4J
 Neo4J
 JMX support*
38
*Available in Advanced and Enterprise editions

39. DEMO
 Monitoring of NoSQL DB Components
 MongoDB
 Neo4J
 Cassandra
 Custom Security Logger
 ActiveMQ Message Broker
39

40. SECURITY ENFORCEMENT USING AOP
 AOP techniques for implementing and enforcing
security policies in NoSQL DB based applications
 Architecture
 Separate security event logic from application and business
logic
 Tools & Technologies
 ActiveMQ
 MongoDB
 Esper
 AspectJ and SpringAOP
40

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

42. ARCHITECTURE AND DESIGN CONSIDERATIONS
 Data Security Strategy and Standards
 Data Classification
 Separate persistence layer to apply Authentication
and ACL's in a standard and centralized fashion
 Batch jobs and other utility scripts that access
database outside the applications
 Data Services (SOA)
 Defense In Depth
 NoSQL DB Servers behind Firewall and Proxy
42

43. 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
43
 Apply security in the right layer

44. FUTURE ROAD MAP
 Pluggable authentication modules
 SAML
 PKI
 Group/Role based access control
 More granularity of access control (e.g. collection level
privileges)
 Data Encryption
 Encryption of wire protocol
44

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

46. CONCLUSIONS
 Security Features in NoSQL
 "One Size Fits All" Fits Nothing
 Involve security early in application development
process (SDLC or Agile)
 Risk based strategy
 Cross-Store Persistence
 Hybrid approach (Polyglot Data Storage)
46

47. Q&A
47

48. 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
48

49. THANK YOU
 Thank you for your attention
49

50. 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
50

51. BONUS SLIDES

52. 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)
52

53. 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?). 53
(1) http://architects.dzone.com/articles/couchdb-moving-cloud?mz=36885-nosql
(2) https://mongohq.com/home

54. 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.
54

55. 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
Cassandra DoS
55

56. BEST PRACTICES
 Input Validation
 Encoding/Escaping
 Error Handling:
 Application Errors v. Security related errors
56

57. COUCHDB SECURITY
 Apache project
 Written in Erlang
 HTTP communication (REST+JSON)
 Current stable version (1.1.0) has native 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) 57

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

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

60. 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.
60

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

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

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

64. 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)?
64

65. OTHER SECURITY USE CASES FOR NOSQL
 MongoDB for Logging
 Capped collections
 Cassandra for Logging
 Neo4J
 Semantic Web for Security
 Security Ontology
*http://static.springsource.org/spring-data/data- 65
graph/docs/current/reference/html/

66. 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 66
 WATOBO
http://resources.infosecinstitute.com/owasp-top-10-tools-and-tactics/