Security Considerations in NoSQL Data Access

4,653 views

Published on

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

Published in: Technology

Security Considerations in NoSQL Data Access

  1. 1. SECURITY CONSIDERATIONS INNOSQL DATA ACCESSNoSQL Now 2011 ConferenceSrini Penchikala08.25.11
  2. 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. 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. 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. 5. BACKGROUND Financial services organization J2EE security architecture model Agile software development Regulatory compliance impact on IT Architecture 5
  6. 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. 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. 8. WHATS IN A NAME (NOSQL)? Is not:  “No SQL”  "Never SQL“  "No Way SQL“ Is:  "Not Only SQL“  "Non-Relational DBMS" (NRDBMS) 8
  9. 9. NOSQL, CAP THEOREM AND CIA CAP Theorem  Consistency  Availability  Partition Tolerance NoSQL impls are based on the “AP” part of CAP. Availability component can also be tied to Security (“A” in CIA) 9
  10. 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. 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. 12. NOSQL DBS DISCUSSED IN THIS SESSION  MongoDB  Cassandra  Neo4J  CouchDB*  Redis*  Hadoop/Hbase* 12*Time permitting
  13. 13. WHICH ONE TO USE? MongoDB:  Modeling rich domain objects. Apache Cassandra:  Highly scalable second-generation distributed database  Dynamos fully distributed design and Bigtables 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. 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. 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) Gartners Hype Cycle for Data Management, 2011
  16. 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. 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. 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. 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. 20. NOSQL DATABASES – SUPPORT FOR AUTHNAND AUTHZNoSQL DB Version Authentication AuthorizationMongoDB 1.9.1 Y YCassandra 0.8.1 Y YNeo4J 1.4CouchDB 0.11 (Win 1.0.1) Y YHadoop* 0.20.203.0 Y (Kerberos) Y 20*No installation
  21. 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. 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. 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. 24. SAMPLE APPLICATION Tools:  JDK 1.7  Eclipse  Neoclipse  MongoDB/Cassandra/Neo4J  DBExplorer (using MongoDB JDBC Driver?)  Security scanner (OWASP LAPSE+) 24
  25. 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. 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. 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. 28. DEMO 1 28
  29. 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. 30. DEMO 2 30
  31. 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. 32. DEMO 3 32
  33. 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. 34. DATA PROTECTION Data Loss Prevention (DLP):  Data at Rest  Data in Transit  Data in Use Cryptography  Encryption  Decryption  Hashing 34
  35. 35. DATABASE SECURITY DB Level Security Table Level Row Level 35
  36. 36. COMMUNICATION LAYER SECURITY Transport Layer Security Message Security 36
  37. 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. 38. SECURITY LOGGING AND AUDITING Logging  Log4J  Custom Appender for secure logging Security Analytics  Security BI  SIEM 38
  39. 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. 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. 41. MONITORING Standards:  JMX - JSR??  Remote JMX - JSR?? Tools:  JConsole/VisualVM 41
  42. 42. MONITORING MongoDB  MongoDB Data Profiler Cassandra  JMX  Integrating JMX  MX4J Neo4J  JMX support 42
  43. 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. 44. ACLS - THE GRAPH DATABASE WAY 44Source: http://wiki.neo4j.org/content/ACL
  45. 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. 46. NOSQL - POTENTIAL SECURITYVULNERABILITIESNoSQL DB Security Vulnerability NotesMongoDB SQL injection In PHPMongoDB Blind SQL injectionMongoDB Null Byte InjectionMongoDB/ DOSSpiderMonkeyCouchDB / XSS Admin interfaceFutonCouchDB String comparison, Timing Attack Authentication 46
  47. 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. 48. BEST PRACTICES Input Validation Output Validation (Encoding/Escaping) 48
  49. 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. 50. DATA ARCHITECTURE CONSIDERATIONS Data Security Strategy and Standards Data Classification Separation of Concerns Defense In Depth 50
  51. 51. DESIGN CONSIDERATIONS Separate persistence layer to apply Authentication and ACLs 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. 52. RECOMMENDED APPROACH Define your use cases. Categorize use cases to see where NoSQL is a good solution and where its 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. 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. 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. 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. 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. 57. Q&A 57
  58. 58. THANK YOU Thank you for your attention Feedback survey 58
  59. 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. 60. BONUS SLIDES
  61. 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. 62. COUCHDB SECURITY (2) Authorization:  Three types of users  database readers  database admins  server admins 62
  63. 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. 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. 65. HADOOP/HBASE SECURITY (3) No encryption on the wire. Protection again DoS attacks 65
  66. 66. REDIS SECURITY Even the security will be handled through Redis rather than the container HttpSession (?) 66
  67. 67. RIAK SECURITY Built-in REST server Webmachine pre-commit hooks 67

×