 It's probably a little bit too early in the morning. Hopefully, this presentation will be helpful to you guys to give an idea where we are with the NoSQL database security. Again, this is mainly focused towards application developers. Like we were talking just earlier, the database security is not there where we want it to be for the NoSQL databases. But that should not stop us being application developers or architects or even DBAs to do whatever we can outside a database layer to control the, to put in the security rules in place. So we're going to talk about that, what we can do and where the most of the NoSQL database are today in the security space. Again, forgot to say my name. So my name is Srinni Penjikala. And the scope of this talk is mainly for application developers. Like I mentioned, we look at what's there right now and what's coming up. And if we, this is a 45 minute talks, so not much time for, I usually, I talk about these topics for hour and a half or at least an hour. So we have some time to do demos. I try to do a lot of demos in my class because that's the best way to learn the concepts. But we may have time for one or two. And some of the database we look at them or those, but again, that doesn't mean that these are the only databases that are out there or these are the only ones that, like I'm recommending or something, these are the ones I tried and all these are open source, you can download and try it out. So that's always the best thing to do when you're looking for new databases. So how many of you are like developers or architects versus? Okay, two, three, okay. And other than you, any like DVAs or DevOps, project managers? Okay, yes, right, right. Platform, okay. Yeah, I think I should use that word new as more of a kind of loosely used term because I mean, if you know databases, you know database, right? Right, right, exactly. You can notice equal database in most of the sense, it's like it's not much different from any database. Usually you have to do your data modeling, database design, security, put all that in place. It is defined those first requirements and then find a solution that fits those requirements, right? Don't let the solution drive your requirements, right? We're going to look at basically talk about, we're not going to look at this security vulnerabilities today. That's like SQL injections, cross-site scripting. That's a completely different talk. I'm going to focus more on the application security side, authentication, authorization, encryption, kind of thing. Format is kind of more, because it's a small group, so we can make it more interactive. So about the presentation and demos, about 40 minutes and maybe five minutes for Q&A. But if you have any questions during the talk, just raise your hand or share your experience on any of these topics. About myself, I work as a software architect for a, does it look okay? So I work as a software architect for a payment processing company in Austin, Texas. So when a customer swipes their credit card, we are one of the several processing vendors that are trying to make a few cents of a dollar in the payment processing business. I wrote a book last year called Spring Review in Action, and I'm working on NoSQL database patterns right now, which is coming, which is going really slowly. I'm also a lead editor at infoq.com, so I write a lot of articles, write about the conference like these. But again, my background has been all financial services, so security is a necessary evil for us. We have to do it, right? And also I had my own experience with agile versus architecture and agile under architecture. Are they complementary or contradictory? All those interesting stuff. So let's go ahead and get started. So these are the different topics. Again, time permitting, we may have to rush through some of the slides. I have 50 slides, usually they say, have one slide for about two minutes. So we may have only time for 25 slides, so I have to rush through some of the use case slides. But I did put the use case slides because I wanted to kind of show you guys which database is good for what kind of use cases. So let's go get started. Again, this is at a high level, this is the NoSQL database landscape. I did put, oh, I actually put it twice. So I did put relation database on the list because I would like to, at least from my view, we want to see all these new databases as an addition to the options we have rather than replacement to relational. They all bring their own patterns, document type or graph. None of them are saying, okay, document type is going to replace the relational type database or graph. They all just bring additional options for the specialized data types. So now we have five, six, 10 more options than only one option we had, which was relational before, right? And the big data is also related, technologies are happening. It's not really about storing the data. It's about the processing the data, but we should still look at that as part of the overall change that's happening. And same thing with the in-memory data grids. These are more data stored in the memory rather than the disk to make it faster access and other requirements. So it's not really a NoSQL database, but it definitely fits into the overall NoSQL database technologies. These are some NoSQL database examples. I'm sure you've already heard enough of this during the last couple of days. MongoDB, Neo4j, React and Redis are key value databases. Cassandra is a columnar database. Hazelcast is an in-memory data grid. Elasticsearch is more of a search framework like Lucene or Solar, if you guys are used to that. It helps to search the unstructured data in the databases. We have a lot of text content, website content or anything else. You can use this tool to search based on the keywords. And Oracle NoSQL database, it started as a key value database, but now I heard yesterday they are starting to support graph and document as well. Don't. Yes. How is it different from the Oracle Timestand? Oracle Timestand, I think it's more close to Oracle coherence, Terracotta coherence. We have what else, memcached kind of top things off. Timestand is more of a database. This is more of an in-memory data grid. They may be close, but it falls into more coherence categories. So let's look at security, right? We always want to look at a security by architectural layer. So this is what it's like. It's what's kind of interesting. Whenever we hear about NoSQL databases, there is this cap theorem. Consistency, availability, and partition tolerance. And a lot of this NoSQL database only offer two of those aspects. Like Cassandra is a AP database. Its focus is on availability and partition tolerance, not so much on the consistency. So when it comes to security, we have to also look at this new theorem or new acronym called the CIA. I mean, it was new to us probably, not new to the security folks. So the CIA stands for confidentiality, integrity, and availability. So cap is good for performance and scalability, but CIA is also needed for the security side of any database, including NoSQL databases. So confidentiality is basically are the right users, authorized users, getting access to the right data, or unauthorized users are trying to get to the access. The integrity is basically about the data itself. Is it being tampered when we transfer the data from one system to another system? Is it being modified by unauthorized users? And availability is basically availability of the systems. Bless you. Availability of the systems where unauthorized users are not bringing down the systems. So with NoSQL being related to other technologies like cloud, mobile, and social, and all the other technologies. So there's a lot of data, it's always in motion. A lot of data is being moved from one system to another system. So definitely confidentiality, integrity, and availability are very important, even more important in NoSQL databases. Because in relational database you store in one database, you may extract it and send it to other system once in a while, but it's not as constant as it is in NoSQL. It's always, data is always moving from one place to another place. Also sometimes we take data from no relational database, put it into MongoDB for analytics. So the data is moving a lot and we want to make sure that it's being done in a secure way. So some of the security concerns, some of these are probably already familiar to you. So when it comes to data security, we have to consider three different scenarios. So data at rest, which is when data is stored in the database and it kind of states static there. So that is the data at rest. So we want to make sure that data is secured when it is in the database. So no one is unauthorized users are not able to access the database. So this is where the encryption comes into picture. And data in motion is basically when you take a data extract from a database and then send it to a different system, whether internal or external. We do that a lot in the financial services industry, banks and credit card processing companies. We have a lot of data files coming in. We have a lot of data files going out, especially ACH, which is how the money transfers the entities. There's a lot of batch files. We still use a lot of batch file processing, not real time in most of the companies. So a lot of these data is like going back and forth. So you want to make sure that it is encrypted and actually in security industry, they also have what they call tagging. So each data type needs to be tagged. Is it confidential or high, medium, low kind of security levels? So just like when you send a package, if there's a dangerous material, you put a tag on that, biohazard, whatever. So just like that, there are these tags that we need to use for data sets. And data in use is basically when you are using the data in the application. You go to the database, you get the data out and you display on the screen. So the user is actually viewing the data and modifying the data, so that's the data in use. And this is where you have to decrypt the data so the authorize user can view the real data. And when they make any changes and when you store it, again, you have to encrypt that in the database. So those are the three scenarios. When you're working in the security industry, these are very familiar terms we use. And authentication is basically, are you who you say you are, right? When a user logs in, there are multiple levels of authentication, either user-ready password combination or user-ready password and some third parameter, it's called multi-factor authentication. So that's authentication, just a login. And access control is basically, are you allowed, you are authenticated in the system you were logged in, but are you allowed to perform this operation or are you allowed to view this data? You may be allowed to view some other data but on this specific data, right? So that is the users and roles and permissions model. And then finally, the data encryption is, we talked about that already, how do you encrypt data so it's not viewed by unauthorized users in the system or outside the system. For that, the key management is very important. There are some companies that offer key management services or you can create your own keys, you know so. Yeah, that's a good question. So some products have what they call vault, VAULT, I don't know how you pronounce. So you can actually purchase those products. So it's basically a wallet type of secure vault type of thing, you know so. You get a key out, you use it and it expires and then when you need one you get one more, you know so. So there are some products. Mostly commercial products, I don't know if there are any open source products. The way we do it in my company, we have done this long time ago because we started several years ago before any of this took off. So we have our own key management system which is not pretty but it works. There is some lot of manual work to be done because we communicate with MasterCard and Visa. So every transaction has to have a key. So we both need to know the key. So the way it works right now is not automated but it works, you know so it's secured but it can be more automated so. And that's the one key note yesterday Adrian was talking about HSMs, right? HSMs, okay. And I have a couple of names I can, I don't want to mention the commercial product names since in the talk but I can talk to you after the session we can mention a couple of names. And the auditing is also very important, you know we are doing all this authentication, access control and encryption. But who is doing it? Who is accessing what data at what time? You know in case the system gets into a situation where there is a fraud activity, the auditing will always help after the event happens. So you want auditing available out of any product you select. You don't want to write auditing capabilities on these products because that will be a full time job and you won't have time to do the real job you are supposed to do. So I wanted to kind of talk to you guys about this. You know NoSQL database security holistic view, right? You know we keep, you know this conference is mainly about NoSQL databases probably a little bit about big data. But NoSQL database is only part of the overall data management lifecycle. So I wanted to kind of show you guys this and discuss this one right here. So NoSQL DBs security are definitely important. But let's look at other similar activities that happen in the data management lifecycle. So NoSQL DBs are used mainly for storage but we are not going to just store the data and leave it there forever, right? We're going to process that for whatever queries or search or data mining purposes. And we also want to have faster access, you know so that's where the in-memory data grids come into picture, right? If it's in the disk, you know it's always going to be slower to access. And we have the hosting options now. You know previously we used to have only probably five years ago we used to have only buy versus build. You know when we have a new product idea do we build it or do we buy it from outside? But now we have a third option buy versus build versus host on the cloud. Definitely the hosting is also part of the security considerations. Then we have interaction between the data or users of data. This is where the social comes into picture whether it's Facebook or the graph relationships. So definitely the data is being used by users to interact with each other. So that's another concern we need to keep in mind. And finally the end user devices in all this data is being used by users on their devices, right? Whether it's a laptop which is probably become extinct pretty soon. Smartphones and tablets are main end users. So all those concerns are very important. Just the storage is one thing. You can make it as secured as you want on this box. But how about the other ones? When the data is being used, it's being processed, it's being hosted, you know so. So that's where all the other hexagons. I just put the concerns here first. We always want to start with the concerns and requirements and then look at the technologies. So this slide actually shows those corresponding technologies. So we have NoSQL DB, a database on the top and then big data, in-memory data grids, cloud, social computing and mobile at the end so. So when you think about security or NoSQL security, think about all these other areas as well. Because you can have as secure database as you want but if whoever is using that is not, it's not secure, that's going to be a concern, right? So any other comments on this slide? So, have anything like a social or mobile security, I guess, look in there, yeah, go ahead. Yeah, that's definitely a good concern even without NoSQL databases. Also, with the cloud, you have a lot of different scenarios. You may be running your application in the cloud and by the database is in your data center. That's more secured type of approach. But maybe you have database and application running on the cloud. So they're all different scenarios, right? So definitely, I think cloud security is a big topic. I haven't, I don't have a lot of experience on that because right now at my company, everything is in-house. We have our own data centers, which I am not a big fan of. We definitely want to go to the cloud in order to be cost effective. But yeah, we can probably talk about that after the session. So how do you do it? Okay, I also want to talk about this, the term polyglot persistence. We're going to hear about this a lot. Again, going back to his question, we have relational databases. They're not going anywhere and we have new database now. So if we were having challenges with one database, type in the past, now multiply that by 10 times, 20 times, right? So not only from how do we access the data, but also how do we secure the data, right? So that's where the cross-store persistence or polyglot persistence techniques are going to help us a little bit. Now they're also going to add more downside as well, but on the good side, you will have one database, the one data access layer. So you just write, let's say you are a Java developer. However, you are using right now to persist. Let's say you are using JPA technology, Java persistence API, to persist into a relational database. You can use a very similar approach to persist your objects, whether they are graph of objects, or document type object, or key value object, or column or whatever the data type, right? Or something new in the future. You can persist them into the respect you know, SQL databases using very similar API. So you don't have to learn document API or MongoDB API or Neo4j API, because they're all very different. They have their own API right now. Either you can learn 10 different API, which definitely are going to change really fast. So keeping up, up to speed with the... Keeping them up to date is always going to be difficult. So how do we do that, right? So polyglot persistence is definitely going to help us. Basically the idea is we want to store different types of data in different SQL databases. We want to have a common data access layer. And again, security is going to be more critical, because now we have multiple databases. How do you manage the security on all those databases? So one option is manage the security in the service or domain layer. So where you have your application logic running. So that's where you can say, if a user comes to the service layer and say I need access to this data set, and the user is not authorized, you can block the user right there, right? Instead of sending the query all the way to database, which may be too late sometimes in protecting the data. So domain service layer or application layer is one choice. But again, with security you always want to secure in all layers as much as possible. So when I say secure, put the security in application layer, I don't mean ignore the security in other layers. So you need security in all layers as applicable. I think my view on that is basically you always want to have a data services model. So even databases, whether they are no SQL or flat file or relational or something else, they're never accessed directly by your clients. You want to have a service layer in between service model, like data services, right? Yeah, so in the model I'm talking about, there will be a data services layer in between. So company A, company B, company Z, they always have to call this service. They cannot access the database directly. Well, I mean that's a security incident, right? But ideally API contact wise, your partners, trading partners should be talking to a service. And that's where you actually manage the security and then only when that passes or checks out, you let them go to the database. Oh, you still need security on the data store layer, right? So you can always say, okay, my database is running on this IP address. My service is running on this IP address. So only allow access to this IP address from this IP address. If someone tries to go by pass, they won't, they will be denied, right? So there are different options, you know? So I mean, a lot of those things are very similar to how relational database works. I mean, that hasn't changed much. Again, the hackers are out there, you know, so probably getting in a really bad, really big every day and that is the same discipline applies for that, okay? Just wanted to show you this diagram. Again, this is kind of illustrate the same concept. So we have an application on top with all these different types of data, graph data, document data, key value. And we need to save that into all these multiple different databases. So how do we go about that? Without having to learn a lot of different languages and techniques. And then this goes back to your question on different layers. So you want to have, as an organization, you want to have security at these different levels. You want to protect the data record, but you also want to protect the application via protocol level, like HTTP or HTTPS. And you also want to secure the server. You want to secure the network and you want to secure the location, physical security, right? So a lot of times you may have the best computer technology, computer security in place. But if someone can just walk into a building and take your backup tape, and then they're able to decrypt that, so you just lost your, you know, you just had a security incident. So all those things are very important, so. How many of you guys, like, have to deal with security compliance requirements? FISMA, PCI, HIPAA, exactly. I definitely, you kind of know what those different security levels mean. And this is, again, I just want to show you guys this diagram. This is the relationship model, relationship database world, I guess. Now where we had these simple layers to manage, everything was, you know, pretty cool. And then once we got into NoSQL database world, one database became multiple databases and one or two APIs became, you know, several different APIs. But we still want to have this data access layer that we can use to manage all this complexity. And the frameworks like Spring Data is one framework I talked about a couple of days ago. Spring Data framework is exactly does that. It basically has support for all the NoSQL databases, almost all of them. So you can say, this is my Java object. I want to pass this into MongoDB. You can do that using just Java API, same consistent API. You don't have to use different APIs for that. And let's look at the, again, these slides are basically security-wise architectural layer. So one layer you want to control security is domain layer. So when you have a customer object and when you instantiate that, someone is calling the customer object. You want to make sure that the client is authorized to call that object in that context. So Spring Security is one framework that does this pretty good. Also, you can use any other framework that has access control list support. So we are controlling the domain level security here. And also, there's a service layer security you want to consider. So when you have a customer object and order object, and then there is a process order service calls those objects, you want to make sure that they're calling in the right context for the right parameters from a security standpoint. So that's the method level security. Again, in Java world, you can annotate that method. So giving like a roles allowed, only allow these roles to call this method. And I'll show you an example on that. And this is also a standard in Java world for this type of annotations. It's JSR250, Java specification request. So it's a standard basically. If you're in Java, this makes sense. If you're not a Java developer, then there might be other standards. So these are some of the annotations that you can use to secure the methods. Roles allowed, secured, pre-authorized. Pre-authorized means this has to happen before they can call this method. Let's quickly look at the demo. So I'm sure you guys are a bit bored with the slides. So for example, one way that I have done in my past life is how do we enforce these security rules? There are a lot of security rules. How do we enforce them with the developers? If someone writes a Java method without the security layer, let me see if I can... How do we create a framework that will notify them that that's not the right way to... So let's go ahead and create. Let's say I'm a Java developer. I'm working on this loan service. Again, this is a test class. There's not much logic here. But I'm going to create a new method. Process, loan, approval with conditions. So when you apply for a loan, either it's approved or it's denied or it's approved with conditions. Now I need this additional documentation only then I can, I will approve this. So let's say I'm working on that method. So now I create this new method and so far so good and I'm going to save this. So it should have flagged me. It should have flagged me with this role not allowed. Let's see why it's not doing that. Let's try this again real quick. Yeah, something is definitely, it's probably not working. Let me try to clean this. Oh, yeah, okay, that was off. So it was not compiling online. So now if it compiles, okay, okay. So you guys see that marker right there? So when I hover my mouse over there, it says all public business methods in a service class must have role annotation. So what we are doing was we are enforcing the developers to make sure that whenever they create a public method in a service class, we want it to be secured, right? So I am doing this with a custom framework that I wrote to enforce the security rules. So now the developer knows that they need to add an annotation, I mean, secure this method. Let's say this particular method needs to be, can only be called by a user who is logged in as, who is a underwriting manager? Because this is with conditions. So once I add that and save it, so if everything goes well, it should, the error flag should go away. This should go away. So let's wait for that. Yeah, just a lot of projects open here. That's why it's compiling all the projects, taking a little extra time. And I think, because the demos are taking a long time, so we're going to probably skip demos and just go to the slides next. Okay, there it is now. So the error is gone. So you can basically see how this works. So if I again take comment out, the error comes back. So this is one way to, I mean, again, this is not directly related to NoSQL database security, but this is the way you can build security into your applications. So let's jump to demos, I mean, skip demos because you don't have time. Again, we talked about service layer, a control layer is the same way. A lot of these NoSQL databases, they expose their database as a, through REST web service, REST-based interface. So REST is the common way to access databases. And the earlier, I mentioned about data services. We implemented a data service model based on the REST technology. So that's the best, the most common way to access and update the data. So we want to make sure that we secure those URLs. And you can do that by using security frameworks like OASP or Spring Security. I have a quick example here to show you guys how it's done. This is not a demo, I'm just going to show the file here. Okay, right here. So this is a Spring Security XML file. If you look at here, you can see the, I don't know if that is clear. So you can see the intercept URL. You basically give a pattern of the URL. And you say, what kind of HTTP method is it delete or post or update? I'm sorry, get or post. And you say, whoever is calling this URL has to have this role, like a role admin or role student in this example. So you can control like any URL you have to your database tables. You can control that using a framework like this. So if some user is logged in, but he's not an admin, when they try to call this URL from browser or from other framework or from other company, it will throw an error. Like I think it will throw 403. You can catch and display different message. So definitely it will say you are not allowed to perform this operation. And the data encryption, like I said, we need that for interest and in motion. We want to do the encryption in real time. You don't want to, bless you. You don't want to store the data and then encrypt it tomorrow. If you wait till tomorrow to encrypt, someone might get the data today and then use it in plain text. Again, one option to encrypt the data is in the application layer because you know that's when you create the data or modify the data. So that's the best place to encrypt as well. And some databases, especially in the relational databases, they offer encryption, built-in encryption in the database itself. But if you want to use any Java frameworks, these are some of the examples. All of them are open source. OASP, ESAPI, Shiro, or JASPT. And I have used all these three in my previous projects. So let's quickly jump into each of the database types. We have 10 minutes left for the session. So let's quickly go through this. So document database use cases, you must have already seen this several times. They're good for content management systems. Logging is another use case. From security-wise, I took MongoDB as an example. They do provide authentication. They recently added a Kerberos authentication. They also provide access control. They recently added a role-based privileges for the access control. These two actually came in version 2.4. And then they're actually working with a, oh, there you go, commercial product vendor. They're working with a company called Gazang to encrypt and secure sensitive database in Mongo. So they have a partnership with, at least I mean, I think it's good to see the NoSQL database vendors who have their hands full improving their product are at least working with the security vendors to get the security into, right? So if they can create security, if they can develop security features, they can work with other companies to integrate security. So that's a document database. So again, probably MongoDB is probably more matured in that sense. Again, not compared to, not where it should be, but then the Gazang product is called Z Encrypt. They have transparent data encryption. They also have good key management, process-based controls, so each access, data access request is verified based on the process, based on the user. And they support these NoSQL databases. So if you are looking at any of these and want to secure them, one option is to talk to these guys. And they also support the security for cloud platforms. So with the database, we heard about this in other talks as well. So NoSQL database support, most of them support the sharding, the partitioning. So when you have one database, physical database you are storing the data, you only have to protect that single instance. But when you partition, you basically end up having multiple instances of the database with different sets of data. Different parts of the same database, basically. So now you have multiple instances to secure. So sharding, whether it good or bad, that's a different discussion, but sharding definitely makes security a bit more complex because now you have multiple entry points into your data layer, database layer. Again, one option to manage this is in the application layer as well. And also you can use security logging and auditing is another aspect where you can use MongoDB to store secure logging into a separate table versus the regular logging. If you have a, and we have some companies have a requirement like this. All the security related, the logging has to go into a different file or different database. So only security team can view that. So you can use MongoDB as a, provides a, MongoDB is a good database for the logging and Spring Data provides a built-in appender to do that, lock-forge appender. And also with all the big data and no SQL databases in the security space, we're going to hear a lot about security analytics. How do we find fraud faster than we are able to do today? So all this data mining and it's going to be even more used in the security, BI, business intelligence, as well as security information and event management areas. So this is like how fast you can find if a fraud occurred or if a security event occurred. Okay, like I said, we probably skip the demos. Graph databases, they're good for social networking, data center management, fraud detection. I took Neo4j as an example for graph security. So again, they don't have data level security. They're probably not, even not there, computers, other MongoDB or Cassandra, because they say, you always want to protect Neo4j from security-wise by fronting a Apache web server or server container. They do have some security rules for more authorization, but it's not a black box when it comes to security. Keyvalid data stores, this is the Redis and React databases. They can be used as a cache. Messaging systems are mobile data storage. And in this area, I looked at two different databases. Accumulo is from Apache. It's based on the big data model. I think this is probably one of the new databases that has more security compared to other database products. So they provide what they call cell-level security. So the security is down to the record level, you know, so each, you know, so not even record is a cell level. So if I run a query and if someone else runs a query, and if we both have different privileges, the records I get horizontally and vertically. The columns and records I get, columns and rows I get are would be different from the columns and rows the other user gets. So there is a vertical and horizontal restriction on the queries, which is the best way to do it, right? And then the basically data, this is the same thing. Data of security, different security levels can be stored in the same row. So you don't have to create multiple different databases to address the security requirements. And the other database I looked at is called Redis. Again, this is one of those databases that expects us to run in a trusted environment. So you have to have that IP restriction. So the database server can only respond to the application server, no one else outside of that. So you want to create those IP level restrictions. And you can enable authentication from this conference configuration file. They don't have access control, they don't have encryption. But again, I think they're probably working towards those. Column databases, again, use cases are content management, analytics, logging. Cassandra, I think they have probably better security API compared to the other ones. They provide their own API for security, but they're also working with Gazang on providing encryption and key management as well. Big data, quickly let's look at the Hadoop security. They have good authentication and authorization model. FileMap permissions are there. You can also, because with Hadoop, you are running a lot of jobs. So you can create the job tokens to secure those as well. So only authorized users are running the jobs. And also there's the delegation tokens for subsequent authentication. So if you authenticate and then you come back again, so there are tokens to kind of more like remember me type of scenario. In-memory data grids, I looked at a HazelCast, has definitely decent security support. They have a native client security, which includes authentication, authorization, and also cluster member security. Because with the HazelCast, you are running multiple instances in the cluster. So security becomes also important. And the other in-memory data grid, I looked at is called the grid gain, which also has authentication and connectivity security. Emerging trends, again some of these are happening in the new SQL space now. There are these multi-model databases coming out that actually support more than one SQL database type. So for example, ORI and DB supports document type as well as graph data type. So if you use ORI and DB, you already have those two capabilities. But now with that comes the security as well. Like now how do I secure document type data? How do I secure graph data? So multi-model databases are going to help us in one way, but also if they don't support security out of the box, then it's going to be a challenge. Same thing with polyglot persistence stores, we will see more database in the future, database products that will start supporting pretty much, if not all, most of the data, no SQL data types. So we may have one database in the future that will support all no SQL data types. And also the other emerging trend I'm seeing is the big data analytics. How can we do that in real time? So usually big data analytics, like you store the data and then you do a lot of processing and then you get the results after the fact. But how can we do those queries and how can we do that processing while the data is being created and modified? So we're going to hear a lot about this in the future. It's probably happening, I guess, with all the recent stories about tracking our data, you know, whatever we do. And the security standards is something I would like to see more progress in this. There are no standard groups or anything right now in no SQL. They're just trying to catch up with other products in terms of features. So security is not getting as much, security standards are not getting as much attention as they should. And I see in the future, you're going to see Omni SQL type of concept where one database will support all the database types, all the data types. And also we also talked about this, all the other technologies you want to look at. So I just put this, like if you're using no SQL databases for any security use cases, because in a lot of the security use cases, I have worked on this in my previous projects, but I always had to work with a relational database and I ran into a lot of challenges because my data was unstructured. But relationship database doesn't work it, you know. So now I can, for the same use case, I can use these new database type, no SQL databases. Security logging and SIEM, I can use document database, managing the UI profiles, graph is the best way to go, LDAP and creating multiple different tables in Oracle are not probably the best solutions. And any session management, we always had to create our own custom solutions for this. Now we can use a key value database. And like I said earlier, analytics, big data is there to provide you faster analytics and faster fraud detection capabilities. Quickly, we're already running over, actually. So quickly, best practices, you always want to do the defense in depth. Make sure that you restrict the security at network level, specify the IP addresses so no one else can access them from outside. Think about securing the data itself, the tables or collections. And what to look for in a vendor, make sure that they support security, ask them as many questions as you should about security itself. Don't pick a database and then realize that it doesn't have any security that you need or you have to write from scratch. Also monitoring and auditing is also important. That's it. The last slide is like always, one size fits all, fits nothing. So analyze your requirements first and make sure that your requirements are helping you to get to the solution. Don't pick a solution and then let the solution or the vendor change your requirements. Think about the security throughout the data management life cycle because as soon as you start the data modeling, the data security should be thought about. So I always tell my team like a build security into the solution, not bolt it on later. You don't want to bolt it on later because it's not an afterthought you know it should be thought about. That's why what we do is like when we work on the new projects, we always document all the security requirements along with business requirements and they are part of the requirements set that need to be prioritized. Now when the business says why is this high priority? We explain to them why security is a high priority. And that's it, my contact information, sorry I took a few more minutes but if you have any questions, later send me an email. Other than that, do you have any questions right now? Any questions or comments? Security, where do you guys see? Yes, I'll give it to them. I made some few changes from the previous question but I'll give it to the organizers and so on. Cool. I'm enjoying the rest of the day and hopefully you'll be able to use some of this database when you go back to work. Thank you.