Security Considerations in NoSQL Data Access
 

Security Considerations in NoSQL Data Access

on

  • 3,600 views

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

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

Statistics

Views

Total Views
3,600
Slideshare-icon Views on SlideShare
3,600
Embed Views
0

Actions

Likes
7
Downloads
128
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Security Considerations in NoSQL Data Access Security Considerations in NoSQL Data Access Presentation Transcript

    • SECURITY CONSIDERATIONS INNOSQL DATA ACCESSNoSQL Now 2011 ConferenceSrini Penchikala08.25.11
    • 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)
    • 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
    • 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
    • BACKGROUND Financial services organization J2EE security architecture model Agile software development Regulatory compliance impact on IT Architecture 5
    • AGENDA Introduction NoSQL and Security Current State of NoSQL Security Application Frameworks Sample Application Authentication and Authorization Encryption Logging Monitoring Best Practices 6 Conclusions
    • AGENDA Introduction NoSQL and Security Current State of NoSQL Security Application Frameworks Sample Application Authentication and Authorization Encryption Logging Monitoring Best Practices 7 Conclusions
    • WHATS IN A NAME (NOSQL)? Is not:  “No SQL”  "Never SQL“  "No Way SQL“ Is:  "Not Only SQL“  "Non-Relational DBMS" (NRDBMS) 8
    • 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
    • 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
    • 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
    • NOSQL DBS DISCUSSED IN THIS SESSION  MongoDB  Cassandra  Neo4J  CouchDB*  Redis*  Hadoop/Hbase* 12*Time permitting
    • 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
    • AGENDA Introduction NoSQL and Security Current State of NoSQL Security Application Frameworks Sample Application Authentication and Authorization Encryption Logging Monitoring Best Practices 14 Conclusions
    • 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
    • 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/
    • AGENDA Introduction NoSQL and Security Current State of NoSQL Security Application Frameworks Sample Application Authentication and Authorization Encryption Logging Monitoring Best Practices 17 Conclusions
    • NOSQL DB SECURITY - CURRENT STATE Security Standards:  Application Security:  Authentication and Authorization  Encryption  Message Level Security  Database Security:  Table, Row, Column Level Security 18
    • 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.
    • 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
    • AGENDA Introduction NoSQL and Security Current State of NoSQL Security Application Frameworks Sample Application Authentication and Authorization Encryption Logging Monitoring Best Practices 21 Conclusions
    • 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
    • AGENDA Introduction NoSQL and Security Current State of NoSQL Security Application Frameworks Sample Application Authentication and Authorization Encryption Logging Monitoring Best Practices 23 Conclusions
    • SAMPLE APPLICATION Tools:  JDK 1.7  Eclipse  Neoclipse  MongoDB/Cassandra/Neo4J  DBExplorer (using MongoDB JDBC Driver?)  Security scanner (OWASP LAPSE+) 24
    • AGENDA Introduction NoSQL and Security Current State of NoSQL Security Application Frameworks Sample Application Authentication and Authorization Encryption Logging Monitoring Best Practices 25 Conclusions
    • 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
    • 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
    • DEMO 1 28
    • 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
    • DEMO 2 30
    • NEO4J SECURITY No Security at the data level No security on the REST access layer Run Neo4J server behind a proxy (mod_proxy) 31
    • DEMO 3 32
    • AGENDA Introduction NoSQL and Security Current State of NoSQL Security Application Frameworks Sample Application Authentication and Authorization Encryption Logging Monitoring Best Practices 33 Conclusions
    • DATA PROTECTION Data Loss Prevention (DLP):  Data at Rest  Data in Transit  Data in Use Cryptography  Encryption  Decryption  Hashing 34
    • DATABASE SECURITY DB Level Security Table Level Row Level 35
    • COMMUNICATION LAYER SECURITY Transport Layer Security Message Security 36
    • AGENDA Introduction NoSQL and Security Current State of NoSQL Security Application Frameworks Sample Application Authentication and Authorization Encryption Logging Monitoring Best Practices 37 Conclusions
    • SECURITY LOGGING AND AUDITING Logging  Log4J  Custom Appender for secure logging Security Analytics  Security BI  SIEM 38
    • 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
    • AGENDA Introduction NoSQL and Security Current State of NoSQL Security Application Frameworks Sample Application Authentication and Authorization Encryption Logging Monitoring Best Practices 40 Conclusions
    • MONITORING Standards:  JMX - JSR??  Remote JMX - JSR?? Tools:  JConsole/VisualVM 41
    • MONITORING MongoDB  MongoDB Data Profiler Cassandra  JMX  Integrating JMX  MX4J Neo4J  JMX support 42
    • 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
    • ACLS - THE GRAPH DATABASE WAY 44Source: http://wiki.neo4j.org/content/ACL
    • 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
    • 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
    • AGENDA Introduction NoSQL and Security Current State of NoSQL Security Application Frameworks Sample Application Authentication and Authorization Encryption Logging Monitoring Best Practices 47 Conclusions
    • BEST PRACTICES Input Validation Output Validation (Encoding/Escaping) 48
    • 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/
    • DATA ARCHITECTURE CONSIDERATIONS Data Security Strategy and Standards Data Classification Separation of Concerns Defense In Depth 50
    • 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
    • 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
    • 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
    • AGENDA Introduction NoSQL and Security Current State of NoSQL Security Application Frameworks Sample Application Authentication and Authorization Encryption Logging Monitoring Best Practices 54 Conclusions
    • 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
    • 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
    • Q&A 57
    • THANK YOU Thank you for your attention Feedback survey 58
    • 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
    • BONUS SLIDES
    • 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
    • COUCHDB SECURITY (2) Authorization:  Three types of users  database readers  database admins  server admins 62
    • 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
    • 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
    • HADOOP/HBASE SECURITY (3) No encryption on the wire. Protection again DoS attacks 65
    • REDIS SECURITY Even the security will be handled through Redis rather than the container HttpSession (?) 66
    • RIAK SECURITY Built-in REST server Webmachine pre-commit hooks 67