Re: Security assessment of Cassandra
Greetings, Matt brought to my attention that I shared the document at "view only" mode. My apologies for that. I corrected permissions and shared the document personally with everybody, who indicated he/she would review it. Thanks, Oleg On Fri, Feb 12, 2016 at 10:33 PM, oleg yusim wrote: > Greetings, > > Following Jack's and Matt's suggestions, I moved the doc to Google Docs > and added to it all the security gaps in Cassandra I was able to discover > (please, see second table below fist). > > Here is an updated link to my document: > > > https://docs.google.com/document/d/13-yu-1a0MMkBiJFPNkYoTd1Hzed9tgKltWi6hFLZbsk/edit?usp=sharing > > Thanks, > > Oleg > > On Thu, Feb 11, 2016 at 2:29 PM, oleg yusim wrote: > >> Greetings, >> >> Performing security assessment of Cassandra with the goal of generating >> STIG for Cassandra (iase.disa.mil/stigs/Pages/a-z.aspx) I ran across >> some questions regarding the way certain security features are implemented >> (or not) in Cassandra. >> >> I composed the list of questions on these topics, which I wasn't able to >> find definitive answer to anywhere else and posted it here: >> >> https://drive.google.com/open?id=0B2L9nW4Cyj41YWd1UkI4ZXVPYmM >> >> It is shared with all the members of that list, and any of the members of >> this list is welcome to comment on this document (there is a place for >> community comments specially reserved near each of the questions and my >> take on it). >> >> I would greatly appreciate Cassandra community help here. >> >> Thanks, >> >> Oleg >> > >
Re: Security assessment of Cassandra
Greetings, Following Jack's and Matt's suggestions, I moved the doc to Google Docs and added to it all the security gaps in Cassandra I was able to discover (please, see second table below fist). Here is an updated link to my document: https://docs.google.com/document/d/13-yu-1a0MMkBiJFPNkYoTd1Hzed9tgKltWi6hFLZbsk/edit?usp=sharing Thanks, Oleg On Thu, Feb 11, 2016 at 2:29 PM, oleg yusim wrote: > Greetings, > > Performing security assessment of Cassandra with the goal of generating > STIG for Cassandra (iase.disa.mil/stigs/Pages/a-z.aspx) I ran across some > questions regarding the way certain security features are implemented (or > not) in Cassandra. > > I composed the list of questions on these topics, which I wasn't able to > find definitive answer to anywhere else and posted it here: > > https://drive.google.com/open?id=0B2L9nW4Cyj41YWd1UkI4ZXVPYmM > > It is shared with all the members of that list, and any of the members of > this list is welcome to comment on this document (there is a place for > community comments specially reserved near each of the questions and my > take on it). > > I would greatly appreciate Cassandra community help here. > > Thanks, > > Oleg >
Re: Security labels
Jack, I updated my document with all the security gaps I was able to find and posted it there: https://docs.google.com/document/d/13-yu-1a0MMkBiJFPNkYoTd1Hzed9tgKltWi6hFLZbsk/edit?usp=sharing Thanks, Oleg On Thu, Feb 11, 2016 at 4:09 PM, oleg yusim wrote: > Jack, > > I asked my management, if I can share with community my assessment > spreadsheet (whole thing, with gaps and desired configurations). Let's wait > for their answer. I would definitely update the document I shared with the > rest of gaps, so you, guys, would have it for sure. > > Now, in case if my management would say no: > > 1) Here: http://iase.disa.mil/stigs/Pages/a-z.aspx the document titled > vRealize Operations STIG would be published. As part of it, there would be > Cassandra STIG (Cassadra is part of vRealize Operations VMware product). > This STIG would contain only suggestions on right (from the security point > of view) configuration, where it can be configured. > 2) Community would have a full list of gaps (things which are needed, but > can't be configured) after I would update my document > 3) The rest of the assessment are Not Applicable and Applicable - > Inherently Meet items, which nobody is interested at. > 4) Also, when STIG for vRealize Operations would be published, look at the > VMware site for Security Guidelines for vRealize Operations. They would be > posted open to public and you would be able to download them free of > charge. Those would include mitigation, which VMware implemented for some > of the Cassandra gaps. > > Thanks, > > Oleg > > On Thu, Feb 11, 2016 at 2:55 PM, Jack Krupansky > wrote: > >> Thanks for putting the items together in a list. This allows people to >> see things with more context. Give people in the user community a little >> time to respond. A week, maybe. Hopefully some of the senior Cassandra >> committers will take a look as well. >> >> Will the final assessment become a public document or is it strictly >> internal for your employer? I know there is a database of these >> assessments, but I don't know who controls what becomes public and when. >> >> -- Jack Krupansky >> >> On Thu, Feb 11, 2016 at 3:23 PM, oleg yusim wrote: >> >>> Hi Dani, >>> >>> As promised, I sort of put all my questions under the "one roof". I >>> would really appreciate you opinion on them. >>> >>> https://drive.google.com/open?id=0B2L9nW4Cyj41YWd1UkI4ZXVPYmM >>> >>> Thanks, >>> >>> Oleg >>> >>> On Fri, Jan 29, 2016 at 3:28 PM, Dani Traphagen < >>> dani.trapha...@datastax.com> wrote: >>> >>>> Hi Oleg, >>>> >>>> Thanks that helped clear things up! This sounds like a daunting task. I >>>> wish you all the best with it. >>>> >>>> Cheers, >>>> Dani >>>> >>>> On Fri, Jan 29, 2016 at 10:03 AM, oleg yusim >>>> wrote: >>>> >>>>> Dani, >>>>> >>>>> I really appreciate you response. Actually, session timeouts and >>>>> security labels are two different topics (first is about attack when >>>>> somebody opened, say, ssh window to DB, left his machine unattended and >>>>> somebody else stole his session, second - to enable DB to support what >>>>> called MAC access model - stays for mandatory access control. It is widely >>>>> used in the government and military, but not outside of it, we all are >>>>> used >>>>> to DAC access control model). However, I think you are right and I should >>>>> move all my queries under the one big roof and call this thread >>>>> "Security". >>>>> I will do this today. >>>>> >>>>> Now, about what you have said, I just answered the same to Jon, in >>>>> Session Timeout thread, but would quickly re-cap here. I understand that >>>>> Cassandra's architecture was aimed and tailored for completely different >>>>> type of scenario. However, unfortunately, that doesn't mean that Cassandra >>>>> is not vulnerable to the same very set of attacks relational database >>>>> would >>>>> be vulnerable to. It just means Cassandra is not protected against those >>>>> attacks, because protection against them was not thought of, when database >>>>> was created. I already gave the AAA and session's timeout example in Jon's >>>>> thread, and those are just one of many. >
Re: Session timeout
Jack, I updated my document with all the security gaps I was able to discover (see the second table, below the fist one). I also moved the document to Google Docs from Word doc, shared on Google Drive, following Matt's suggestion. Please, see the updated link: https://docs.google.com/document/d/13-yu-1a0MMkBiJFPNkYoTd1Hzed9tgKltWi6hFLZbsk/edit?usp=sharing Thanks, Oleg On Thu, Feb 11, 2016 at 3:52 PM, oleg yusim wrote: > Jack, > > This document doesn't cover all the areas where user will need to get > engaged in explicit mitigation, it only covers those, I wasn't sure about. > But - you are making a good point here. Let me update the document with the > rest of the gaps, so community would have a complete list here. > > Thanks, > > Oleg > > On Thu, Feb 11, 2016 at 3:38 PM, Jack Krupansky > wrote: > >> Thanks! A useful contribution, no matter what the outcome. I trust your >> ability to read of the doc, so I don't expect a lot of change to the >> responses, but we'll see. At a minimum, it will probably be good to have >> doc to highlight areas where users will need to engage in explicit >> mitigation efforts if their infrastructure does not implicitly effect >> mitigation for various security exposures. >> >> -- Jack Krupansky >> >> On Thu, Feb 11, 2016 at 3:21 PM, oleg yusim wrote: >> >>> Robert, Jack, Bryan, >>> >>> As you suggested, I put together document, titled >>> Cassandra_Security_Topics_to_Discuss, put it on Google Drive and shared it >>> with everybody on this list. The document contains list of questions I have >>> on Cassandra, my take on it, and has a place for notes Community would like >>> to make on it. >>> >>> Please, review. Any help would be appreciated greatly. >>> >>> https://drive.google.com/open?id=0B2L9nW4Cyj41YWd1UkI4ZXVPYmM >>> >>> Oleg >>> >>> On Fri, Jan 29, 2016 at 6:30 PM, Bryan Cheng >>> wrote: >>> >>>> To throw my (unsolicited) 2 cents into the ring, Oleg, you work for a >>>> well-funded and fairly large company. You are certainly free to continue >>>> using the list and asking for community support (I am definitely not in any >>>> position to tell you otherwise, anyway), but that community support is by >>>> definition ad-hoc and best effort. Furthermore, your questions range from >>>> trivial to, as Jonathan as mentioned earlier, concepts that many of us have >>>> no reason to consider at this time (perhaps your work will convince us >>>> otherwise- but you'll need to finish it first ;) ) >>>> >>>> What I'm getting at here is that perhaps, if you need faster, deeper >>>> level, and more elaborate support than this list can provide, you should >>>> look into the services of a paid Cassandra support company like Datastax. >>>> >>>> On Fri, Jan 29, 2016 at 3:34 PM, Robert Coli >>>> wrote: >>>> >>>>> On Fri, Jan 29, 2016 at 3:12 PM, Jack Krupansky < >>>>> jack.krupan...@gmail.com> wrote: >>>>> >>>>>> One last time, I'll simply renew my objection to the way you are >>>>>> abusing this list. >>>>>> >>>>> >>>>> FWIW, while I appreciate that OP (Oleg) is attempting to do a service >>>>> for the community, I agree that the flood of single topic, context-lacking >>>>> posts regarding deep internals of Cassandra is likely to inspire the >>>>> opposite of a helpful response. >>>>> >>>>> This is important work, however, so hopefully we can collectively find >>>>> a way through the meta and can discuss this topic without acrimony! :D >>>>> >>>>> =Rob >>>>> >>>>> >>>> >>>> >>> >> >
Re: Security labels
Jack, I asked my management, if I can share with community my assessment spreadsheet (whole thing, with gaps and desired configurations). Let's wait for their answer. I would definitely update the document I shared with the rest of gaps, so you, guys, would have it for sure. Now, in case if my management would say no: 1) Here: http://iase.disa.mil/stigs/Pages/a-z.aspx the document titled vRealize Operations STIG would be published. As part of it, there would be Cassandra STIG (Cassadra is part of vRealize Operations VMware product). This STIG would contain only suggestions on right (from the security point of view) configuration, where it can be configured. 2) Community would have a full list of gaps (things which are needed, but can't be configured) after I would update my document 3) The rest of the assessment are Not Applicable and Applicable - Inherently Meet items, which nobody is interested at. 4) Also, when STIG for vRealize Operations would be published, look at the VMware site for Security Guidelines for vRealize Operations. They would be posted open to public and you would be able to download them free of charge. Those would include mitigation, which VMware implemented for some of the Cassandra gaps. Thanks, Oleg On Thu, Feb 11, 2016 at 2:55 PM, Jack Krupansky wrote: > Thanks for putting the items together in a list. This allows people to see > things with more context. Give people in the user community a little time > to respond. A week, maybe. Hopefully some of the senior Cassandra > committers will take a look as well. > > Will the final assessment become a public document or is it strictly > internal for your employer? I know there is a database of these > assessments, but I don't know who controls what becomes public and when. > > -- Jack Krupansky > > On Thu, Feb 11, 2016 at 3:23 PM, oleg yusim wrote: > >> Hi Dani, >> >> As promised, I sort of put all my questions under the "one roof". I would >> really appreciate you opinion on them. >> >> https://drive.google.com/open?id=0B2L9nW4Cyj41YWd1UkI4ZXVPYmM >> >> Thanks, >> >> Oleg >> >> On Fri, Jan 29, 2016 at 3:28 PM, Dani Traphagen < >> dani.trapha...@datastax.com> wrote: >> >>> Hi Oleg, >>> >>> Thanks that helped clear things up! This sounds like a daunting task. I >>> wish you all the best with it. >>> >>> Cheers, >>> Dani >>> >>> On Fri, Jan 29, 2016 at 10:03 AM, oleg yusim >>> wrote: >>> >>>> Dani, >>>> >>>> I really appreciate you response. Actually, session timeouts and >>>> security labels are two different topics (first is about attack when >>>> somebody opened, say, ssh window to DB, left his machine unattended and >>>> somebody else stole his session, second - to enable DB to support what >>>> called MAC access model - stays for mandatory access control. It is widely >>>> used in the government and military, but not outside of it, we all are used >>>> to DAC access control model). However, I think you are right and I should >>>> move all my queries under the one big roof and call this thread "Security". >>>> I will do this today. >>>> >>>> Now, about what you have said, I just answered the same to Jon, in >>>> Session Timeout thread, but would quickly re-cap here. I understand that >>>> Cassandra's architecture was aimed and tailored for completely different >>>> type of scenario. However, unfortunately, that doesn't mean that Cassandra >>>> is not vulnerable to the same very set of attacks relational database would >>>> be vulnerable to. It just means Cassandra is not protected against those >>>> attacks, because protection against them was not thought of, when database >>>> was created. I already gave the AAA and session's timeout example in Jon's >>>> thread, and those are just one of many. >>>> >>>> Now what I'm trying to do, I'm trying to create a STIG - security >>>> federal compliance document, which will assess Cassandra against SRG >>>> concepts (security federal compliance recommendations for databases >>>> overall) and will highlight what is not met, and can't be in current design >>>> (i.e. what system architects should keep in mind and what they need to >>>> compensate for with other controls on different layers of system model) and >>>> what can be met either with configuration or with little enhancement (and >>>> how). >>>> >>>>
Re: Session timeout
Jack, This document doesn't cover all the areas where user will need to get engaged in explicit mitigation, it only covers those, I wasn't sure about. But - you are making a good point here. Let me update the document with the rest of the gaps, so community would have a complete list here. Thanks, Oleg On Thu, Feb 11, 2016 at 3:38 PM, Jack Krupansky wrote: > Thanks! A useful contribution, no matter what the outcome. I trust your > ability to read of the doc, so I don't expect a lot of change to the > responses, but we'll see. At a minimum, it will probably be good to have > doc to highlight areas where users will need to engage in explicit > mitigation efforts if their infrastructure does not implicitly effect > mitigation for various security exposures. > > -- Jack Krupansky > > On Thu, Feb 11, 2016 at 3:21 PM, oleg yusim wrote: > >> Robert, Jack, Bryan, >> >> As you suggested, I put together document, titled >> Cassandra_Security_Topics_to_Discuss, put it on Google Drive and shared it >> with everybody on this list. The document contains list of questions I have >> on Cassandra, my take on it, and has a place for notes Community would like >> to make on it. >> >> Please, review. Any help would be appreciated greatly. >> >> https://drive.google.com/open?id=0B2L9nW4Cyj41YWd1UkI4ZXVPYmM >> >> Oleg >> >> On Fri, Jan 29, 2016 at 6:30 PM, Bryan Cheng >> wrote: >> >>> To throw my (unsolicited) 2 cents into the ring, Oleg, you work for a >>> well-funded and fairly large company. You are certainly free to continue >>> using the list and asking for community support (I am definitely not in any >>> position to tell you otherwise, anyway), but that community support is by >>> definition ad-hoc and best effort. Furthermore, your questions range from >>> trivial to, as Jonathan as mentioned earlier, concepts that many of us have >>> no reason to consider at this time (perhaps your work will convince us >>> otherwise- but you'll need to finish it first ;) ) >>> >>> What I'm getting at here is that perhaps, if you need faster, deeper >>> level, and more elaborate support than this list can provide, you should >>> look into the services of a paid Cassandra support company like Datastax. >>> >>> On Fri, Jan 29, 2016 at 3:34 PM, Robert Coli >>> wrote: >>> >>>> On Fri, Jan 29, 2016 at 3:12 PM, Jack Krupansky < >>>> jack.krupan...@gmail.com> wrote: >>>> >>>>> One last time, I'll simply renew my objection to the way you are >>>>> abusing this list. >>>>> >>>> >>>> FWIW, while I appreciate that OP (Oleg) is attempting to do a service >>>> for the community, I agree that the flood of single topic, context-lacking >>>> posts regarding deep internals of Cassandra is likely to inspire the >>>> opposite of a helpful response. >>>> >>>> This is important work, however, so hopefully we can collectively find >>>> a way through the meta and can discuss this topic without acrimony! :D >>>> >>>> =Rob >>>> >>>> >>> >>> >> >
Re: Security labels
Thanks Dani. Oleg On Thu, Feb 11, 2016 at 2:27 PM, Dani Traphagen wrote: > Hi Oleg, > > I'm happy to take a look. Will update after review. > > Thanks, > Dani > > On Thu, Feb 11, 2016 at 12:23 PM, oleg yusim wrote: > >> Hi Dani, >> >> As promised, I sort of put all my questions under the "one roof". I would >> really appreciate you opinion on them. >> >> https://drive.google.com/open?id=0B2L9nW4Cyj41YWd1UkI4ZXVPYmM >> >> Thanks, >> >> Oleg >> >> On Fri, Jan 29, 2016 at 3:28 PM, Dani Traphagen < >> dani.trapha...@datastax.com> wrote: >> >>> Hi Oleg, >>> >>> Thanks that helped clear things up! This sounds like a daunting task. I >>> wish you all the best with it. >>> >>> Cheers, >>> Dani >>> >>> On Fri, Jan 29, 2016 at 10:03 AM, oleg yusim >>> wrote: >>> >>>> Dani, >>>> >>>> I really appreciate you response. Actually, session timeouts and >>>> security labels are two different topics (first is about attack when >>>> somebody opened, say, ssh window to DB, left his machine unattended and >>>> somebody else stole his session, second - to enable DB to support what >>>> called MAC access model - stays for mandatory access control. It is widely >>>> used in the government and military, but not outside of it, we all are used >>>> to DAC access control model). However, I think you are right and I should >>>> move all my queries under the one big roof and call this thread "Security". >>>> I will do this today. >>>> >>>> Now, about what you have said, I just answered the same to Jon, in >>>> Session Timeout thread, but would quickly re-cap here. I understand that >>>> Cassandra's architecture was aimed and tailored for completely different >>>> type of scenario. However, unfortunately, that doesn't mean that Cassandra >>>> is not vulnerable to the same very set of attacks relational database would >>>> be vulnerable to. It just means Cassandra is not protected against those >>>> attacks, because protection against them was not thought of, when database >>>> was created. I already gave the AAA and session's timeout example in Jon's >>>> thread, and those are just one of many. >>>> >>>> Now what I'm trying to do, I'm trying to create a STIG - security >>>> federal compliance document, which will assess Cassandra against SRG >>>> concepts (security federal compliance recommendations for databases >>>> overall) and will highlight what is not met, and can't be in current design >>>> (i.e. what system architects should keep in mind and what they need to >>>> compensate for with other controls on different layers of system model) and >>>> what can be met either with configuration or with little enhancement (and >>>> how). >>>> >>>> That document would be of great help for Cassandra as a product because >>>> it would allow it to be marketed as a product with existing security >>>> assessment and guidelines, performed according to DoD standards. It would >>>> also allow to move product in the general direction of improving its >>>> security posture. Finally, the document would be posted on DISA site ( >>>> http://iase.disa.mil/stigs/Pages/a-z.aspx) available for every >>>> security architect to utilize, which would greatly reduce the risk for >>>> Cassandra product to be hacked in a field. >>>> >>>> To clear things out - what I ask about are not my expectations. I >>>> really do not expect developers of Cassandra to run and start implementing >>>> security labels, just because I asked about it. :) My questions are to >>>> build my internal knowledge of DB current design, so that I can build my >>>> security assessment based of it, not more, not less. >>>> >>>> I guess, summarizing what I said on top, from what I'm doing Cassandra >>>> as a product would end up benefiting quite a bit. That is why I think it >>>> would make sense for Cassandra community to help me with my questions even >>>> if they sound completely of the traditional "grid". >>>> >>>> Thanks again, I really appreciate your response and conversation >>>> overall. >>>> >>>> Oleg >>>> >>>>
Security assessment of Cassandra
Greetings, Performing security assessment of Cassandra with the goal of generating STIG for Cassandra (iase.disa.mil/stigs/Pages/a-z.aspx) I ran across some questions regarding the way certain security features are implemented (or not) in Cassandra. I composed the list of questions on these topics, which I wasn't able to find definitive answer to anywhere else and posted it here: https://drive.google.com/open?id=0B2L9nW4Cyj41YWd1UkI4ZXVPYmM It is shared with all the members of that list, and any of the members of this list is welcome to comment on this document (there is a place for community comments specially reserved near each of the questions and my take on it). I would greatly appreciate Cassandra community help here. Thanks, Oleg
Re: Security labels
Hi Dani, As promised, I sort of put all my questions under the "one roof". I would really appreciate you opinion on them. https://drive.google.com/open?id=0B2L9nW4Cyj41YWd1UkI4ZXVPYmM Thanks, Oleg On Fri, Jan 29, 2016 at 3:28 PM, Dani Traphagen wrote: > Hi Oleg, > > Thanks that helped clear things up! This sounds like a daunting task. I > wish you all the best with it. > > Cheers, > Dani > > On Fri, Jan 29, 2016 at 10:03 AM, oleg yusim wrote: > >> Dani, >> >> I really appreciate you response. Actually, session timeouts and security >> labels are two different topics (first is about attack when somebody >> opened, say, ssh window to DB, left his machine unattended and somebody >> else stole his session, second - to enable DB to support what called MAC >> access model - stays for mandatory access control. It is widely used in the >> government and military, but not outside of it, we all are used to DAC >> access control model). However, I think you are right and I should move all >> my queries under the one big roof and call this thread "Security". I will >> do this today. >> >> Now, about what you have said, I just answered the same to Jon, in >> Session Timeout thread, but would quickly re-cap here. I understand that >> Cassandra's architecture was aimed and tailored for completely different >> type of scenario. However, unfortunately, that doesn't mean that Cassandra >> is not vulnerable to the same very set of attacks relational database would >> be vulnerable to. It just means Cassandra is not protected against those >> attacks, because protection against them was not thought of, when database >> was created. I already gave the AAA and session's timeout example in Jon's >> thread, and those are just one of many. >> >> Now what I'm trying to do, I'm trying to create a STIG - security federal >> compliance document, which will assess Cassandra against SRG concepts >> (security federal compliance recommendations for databases overall) and >> will highlight what is not met, and can't be in current design (i.e. what >> system architects should keep in mind and what they need to compensate for >> with other controls on different layers of system model) and what can be >> met either with configuration or with little enhancement (and how). >> >> That document would be of great help for Cassandra as a product because >> it would allow it to be marketed as a product with existing security >> assessment and guidelines, performed according to DoD standards. It would >> also allow to move product in the general direction of improving its >> security posture. Finally, the document would be posted on DISA site ( >> http://iase.disa.mil/stigs/Pages/a-z.aspx) available for every security >> architect to utilize, which would greatly reduce the risk for Cassandra >> product to be hacked in a field. >> >> To clear things out - what I ask about are not my expectations. I really >> do not expect developers of Cassandra to run and start implementing >> security labels, just because I asked about it. :) My questions are to >> build my internal knowledge of DB current design, so that I can build my >> security assessment based of it, not more, not less. >> >> I guess, summarizing what I said on top, from what I'm doing Cassandra as >> a product would end up benefiting quite a bit. That is why I think it would >> make sense for Cassandra community to help me with my questions even if >> they sound completely of the traditional "grid". >> >> Thanks again, I really appreciate your response and conversation overall. >> >> Oleg >> >> On Fri, Jan 29, 2016 at 11:20 AM, Dani Traphagen < >> dani.trapha...@datastax.com> wrote: >> >>> Also -- it looks like you're really asking questions about session >>> timeouts and security labels as they associate, would be more helpful to >>> keep in one thread. :) >>> >>> >>> On Friday, January 29, 2016, Dani Traphagen >>> wrote: >>> >>>> Hi Oleg, >>>> >>>> I understand your frustration but unfortunately, in the terms of your >>>> security assessment, you have fallen into a mismatch for Cassandra's >>>> utility. >>>> >>>> The eventuality of having multiple sockets open without the query input >>>> for long durations of time isn't something that was >>>> architected...because...Cassnadra was built to take massive quantities >>>> of queries b
Re: Session timeout
Robert, Jack, Bryan, As you suggested, I put together document, titled Cassandra_Security_Topics_to_Discuss, put it on Google Drive and shared it with everybody on this list. The document contains list of questions I have on Cassandra, my take on it, and has a place for notes Community would like to make on it. Please, review. Any help would be appreciated greatly. https://drive.google.com/open?id=0B2L9nW4Cyj41YWd1UkI4ZXVPYmM Oleg On Fri, Jan 29, 2016 at 6:30 PM, Bryan Cheng wrote: > To throw my (unsolicited) 2 cents into the ring, Oleg, you work for a > well-funded and fairly large company. You are certainly free to continue > using the list and asking for community support (I am definitely not in any > position to tell you otherwise, anyway), but that community support is by > definition ad-hoc and best effort. Furthermore, your questions range from > trivial to, as Jonathan as mentioned earlier, concepts that many of us have > no reason to consider at this time (perhaps your work will convince us > otherwise- but you'll need to finish it first ;) ) > > What I'm getting at here is that perhaps, if you need faster, deeper > level, and more elaborate support than this list can provide, you should > look into the services of a paid Cassandra support company like Datastax. > > On Fri, Jan 29, 2016 at 3:34 PM, Robert Coli wrote: > >> On Fri, Jan 29, 2016 at 3:12 PM, Jack Krupansky > > wrote: >> >>> One last time, I'll simply renew my objection to the way you are abusing >>> this list. >>> >> >> FWIW, while I appreciate that OP (Oleg) is attempting to do a service for >> the community, I agree that the flood of single topic, context-lacking >> posts regarding deep internals of Cassandra is likely to inspire the >> opposite of a helpful response. >> >> This is important work, however, so hopefully we can collectively find a >> way through the meta and can discuss this topic without acrimony! :D >> >> =Rob >> >> > >
Extensions
Greetings, Is it a way to find out (list or otherwise) if any extensions were installed with Cassandra base package? Thanks, Oleg
Re: Session timeout
Jeff, You mentioned that both Authentication and Authorization are pluggable. In relation to that, is logging pluggable as well? I.e. if I'm not happy with what logback has to provide and want to replace it with some alternative logging module, can I do it? Thanks, Oleg On Fri, Jan 29, 2016 at 11:42 AM, Jeff Jirsa wrote: > > > For instance, way AAA (authentication, authorization, audit) is done, > doesn't allow for centralized account and access control management, which > in reality translates into shared accounts and no hierarchy. > > Authentication and Authorization are both pluggable. Any organization can > write their own, and tie it to any AAA system they currently have. If they > were feeling generous, they could open source it for the community, and > perhaps bring it upstream. There’s nothing fundamentally preventing your > organization from writing an Authenticator ( > https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/auth/IAuthenticator.java > ) > or Authorizor ( > https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/auth/IAuthorizer.java > ) > if they were so inclined. > > Audit is something that’s being actively discussed ( > https://issues.apache.org/jira/browse/CASSANDRA-8844 ). > > It’s an open source project with a very small number of commercial > vendors. In general, that means there are 3 options: > >1. Wait for someone else to write it to fit their need, and hopefully >they open source it. >2. Write it yourself >3. Pay a vendor (such as Datastax), and let them know in advance it’s >a requirement to get it on their roadmap. This is really #2 with some >polish to make it easier to get through your legal/AP systems. > > > So far it doesn't work quite well, and from what you are saying, it > wouldn't, because of lack of knowledge and lack of motivation to get it. > What would be your suggestion? Who is capable of answering my questions? Is > there another community, I should turn to? > > The cassandra-user and cassandra-dev mailing lists are the primary sources > of knowledge outside of support contracts. For paid support, companies like > Datastax and The Last Pickle tend to be well respected options. Both of > those companies will probably answer some of your questions for free if you > post on these mailing lists. They’ll likely answer even more if you pay > them. > > > > From: oleg yusim > Reply-To: "user@cassandra.apache.org" > Date: Friday, January 29, 2016 at 9:16 AM > To: "user@cassandra.apache.org" > Subject: Re: Session timeout > > Jon, > > I suspected something like that. I did a bit of learning on Cassandra > before starting my assessment, and I understand that you are right, and it > is generally not used like that. > > However (taking off my developer hat and putting on my security architect > hat), from the security point of view the way Cassandra is used now is not > very secure. For instance, way AAA (authentication, authorization, audit) > is done, doesn't allow for centralized account and access control > management, which in reality translates into shared accounts and no > hierarchy. That in turn translates into situation when one person > compromising credentials means complete disaster - administrative access to > DB was just given up, with all the consequences. To top it all logging > currently implemented in horrible manner too. It doesn't even allow to log > username - basic requirement for any product, which would allow DBA or ISSO > to figure out who did what on DB and recover in case of attack or crash. In > general, logs the way they are today are targeted toward developer, making > changes in DB, not toward the DBA, using it, and doesn't make much sense in > my opinion. > > Now if you are interested in that subject, that document: > http://iasecontent.disa.mil/stigs/zip/Jan2016/U_Database_V2R3_SRG.zip > covers security concerns which should be taken in the account, when we are > designing database. It also explains why each of them is important and what > exactly would happen if it would be neglected. > > Jon, I would also appreciate suggestion. What I do right now is called > "writing a STIG".That is when somebody takes concepts from SRG (the > document I gave you link to above) and figures out how those are applied to > that particular product. What is met (and what configuration on product > leads to it, exactly), what is not met, but can be with little enhancement > (and again - what those would be exactly), and what is not met and can't be > met at current design. All that is combined into one document, called STIG > and published by government (
Re: Security labels
Thanks Dani! Oleg On Fri, Jan 29, 2016 at 3:28 PM, Dani Traphagen wrote: > Hi Oleg, > > Thanks that helped clear things up! This sounds like a daunting task. I > wish you all the best with it. > > Cheers, > Dani > > On Fri, Jan 29, 2016 at 10:03 AM, oleg yusim wrote: > >> Dani, >> >> I really appreciate you response. Actually, session timeouts and security >> labels are two different topics (first is about attack when somebody >> opened, say, ssh window to DB, left his machine unattended and somebody >> else stole his session, second - to enable DB to support what called MAC >> access model - stays for mandatory access control. It is widely used in the >> government and military, but not outside of it, we all are used to DAC >> access control model). However, I think you are right and I should move all >> my queries under the one big roof and call this thread "Security". I will >> do this today. >> >> Now, about what you have said, I just answered the same to Jon, in >> Session Timeout thread, but would quickly re-cap here. I understand that >> Cassandra's architecture was aimed and tailored for completely different >> type of scenario. However, unfortunately, that doesn't mean that Cassandra >> is not vulnerable to the same very set of attacks relational database would >> be vulnerable to. It just means Cassandra is not protected against those >> attacks, because protection against them was not thought of, when database >> was created. I already gave the AAA and session's timeout example in Jon's >> thread, and those are just one of many. >> >> Now what I'm trying to do, I'm trying to create a STIG - security federal >> compliance document, which will assess Cassandra against SRG concepts >> (security federal compliance recommendations for databases overall) and >> will highlight what is not met, and can't be in current design (i.e. what >> system architects should keep in mind and what they need to compensate for >> with other controls on different layers of system model) and what can be >> met either with configuration or with little enhancement (and how). >> >> That document would be of great help for Cassandra as a product because >> it would allow it to be marketed as a product with existing security >> assessment and guidelines, performed according to DoD standards. It would >> also allow to move product in the general direction of improving its >> security posture. Finally, the document would be posted on DISA site ( >> http://iase.disa.mil/stigs/Pages/a-z.aspx) available for every security >> architect to utilize, which would greatly reduce the risk for Cassandra >> product to be hacked in a field. >> >> To clear things out - what I ask about are not my expectations. I really >> do not expect developers of Cassandra to run and start implementing >> security labels, just because I asked about it. :) My questions are to >> build my internal knowledge of DB current design, so that I can build my >> security assessment based of it, not more, not less. >> >> I guess, summarizing what I said on top, from what I'm doing Cassandra as >> a product would end up benefiting quite a bit. That is why I think it would >> make sense for Cassandra community to help me with my questions even if >> they sound completely of the traditional "grid". >> >> Thanks again, I really appreciate your response and conversation overall. >> >> Oleg >> >> On Fri, Jan 29, 2016 at 11:20 AM, Dani Traphagen < >> dani.trapha...@datastax.com> wrote: >> >>> Also -- it looks like you're really asking questions about session >>> timeouts and security labels as they associate, would be more helpful to >>> keep in one thread. :) >>> >>> >>> On Friday, January 29, 2016, Dani Traphagen >>> wrote: >>> >>>> Hi Oleg, >>>> >>>> I understand your frustration but unfortunately, in the terms of your >>>> security assessment, you have fallen into a mismatch for Cassandra's >>>> utility. >>>> >>>> The eventuality of having multiple sockets open without the query input >>>> for long durations of time isn't something that was >>>> architected...because...Cassnadra was built to take massive quantities >>>> of queries both in volume and velocity. >>>> >>>> Your expectation of the database isn't in line with how our why it was >>>> designed. Generally, security solutions
Re: Session timeout
Jack, I have to note, Cassandra documentation the way it stays now, is not nearly detailed enough. For instance: https://docs.datastax.com/en/cassandra/2.1/cassandra/configuration/configLoggingLevels_r.html is all Cassandra has to say about logging. The reason why I bring my questions to the mailing list is, once again, I can't make security recommendations which would be followed across US, based of the lack of information. It is really not that difficult to confirm that such feature is not present. Besides, questions I ask might give some implementations ideas. Even from that particular discussion one has been raised already. https://issues.apache.org/jira/browse/CASSANDRA-11097 With that in mind, would you please be able to respond with definitive answers to questions I raised here? My assumption, answer would be "not supported" for all 5 not yet answered, but I need a confirmation from community. Thanks, Oleg On Fri, Jan 29, 2016 at 4:34 PM, Jack Krupansky wrote: > No offense, but my suggestion here is that you write up a preliminary list > of your own answers based on your own reading of the doc, specs, and white > papers (and source code) and post that list, like on Google Docs, for > people to review in bulk, rather than force all Cassandra users on this > list to participate in a full security review one item at a time. To > reiterate, you should be treating the doc as the definitive guide to what > is supported - given the importance that the Cassandra and DSE developers > placed on security features over the past couple of years, it really is > truly safe to say that if it isn't in the doc then it is definitively not > supported. Yes, it would be good to review your final list as a courtesy > check, but asking us to confirm what appears to be obvious (i.e., it is not > in the doc) seems more than a bit excessive to me. > > If there is any true confusion in the doc, of course let us know (or email > to d...@datastax.com), but there is no need for us to confirm that you > did not find something in the doc. > > -- Jack Krupansky > > On Fri, Jan 29, 2016 at 5:02 PM, oleg yusim wrote: > >> Jack, >> >> Appreciate the links. As I mentioned, I looked over both DSE and >> Cassandra sets of documentation, and ran some experiments on my Cassandra >> installation. What I'm bringing here is something I couldn't find >> definitive answer for in any of the above-mentioned sources. >> >> For instance, regarding logging, here are questions I have: >> >> 1) Identity-based logging (we investigated it in another thread and I >> got "not supported" as an answer) >> 2) Logging source and destinations (server and client IP) >> 3) Logging connections and disconnections - same >> 4) Logging hostname >> 5) Ability to automatically shut down in case if it ran out of space to >> store logs? >> 6) Ability to automatically overwrite audit logs in case if no more >> space is available (oldest first) ? >> >> Thanks, >> >> Oleg >> >> On Fri, Jan 29, 2016 at 3:47 PM, Jack Krupansky > > wrote: >> >>> There is some more detail on DSE Security in this white paper: >>> >>> http://www.datastax.com/wp-content/uploads/2014/04/WP-DataStax-Enterprise-SOX-Compliance.pdf >>> >>> It mentions auditing, for example. I think you were asking abut that >>> earlier. >>> >>> There may be some additional info or discussion related to security on >>> these main web site pages: >>> http://www.datastax.com/products/datastax-enterprise-security >>> >>> Security was given a reasonably high priority for DSE in releases 3.0 >>> and beyond, so that if something is not highlighted in those promotional >>> materials, then it probably isn't in the software. >>> >>> In general, if you see a feature in DSE, just do a keyword search in the >>> Cassandra doc to see if it is supported outside of DSE. >>> >>> -- Jack Krupansky >>> >>> On Fri, Jan 29, 2016 at 4:23 PM, oleg yusim wrote: >>> >>>> Alex, >>>> >>>> No offense are taken, your question is absolutely legit. As we used to >>>> joke in security world "putting on my black hat"/"putting on my white hat" >>>> - i.e. same set of questions I would be asking for hacking and protecting >>>> the product. So, I commend you for being careful here. >>>> >>>> Now, at that particular case I'm acting with my "white hat on". :) I'm >>>> hired by VMware, to help them improve security posture for their new >&g
Re: Session timeout
Jack, Appreciate the links. As I mentioned, I looked over both DSE and Cassandra sets of documentation, and ran some experiments on my Cassandra installation. What I'm bringing here is something I couldn't find definitive answer for in any of the above-mentioned sources. For instance, regarding logging, here are questions I have: 1) Identity-based logging (we investigated it in another thread and I got "not supported" as an answer) 2) Logging source and destinations (server and client IP) 3) Logging connections and disconnections - same 4) Logging hostname 5) Ability to automatically shut down in case if it ran out of space to store logs? 6) Ability to automatically overwrite audit logs in case if no more space is available (oldest first) ? Thanks, Oleg On Fri, Jan 29, 2016 at 3:47 PM, Jack Krupansky wrote: > There is some more detail on DSE Security in this white paper: > > http://www.datastax.com/wp-content/uploads/2014/04/WP-DataStax-Enterprise-SOX-Compliance.pdf > > It mentions auditing, for example. I think you were asking abut that > earlier. > > There may be some additional info or discussion related to security on > these main web site pages: > http://www.datastax.com/products/datastax-enterprise-security > > Security was given a reasonably high priority for DSE in releases 3.0 and > beyond, so that if something is not highlighted in those promotional > materials, then it probably isn't in the software. > > In general, if you see a feature in DSE, just do a keyword search in the > Cassandra doc to see if it is supported outside of DSE. > > -- Jack Krupansky > > On Fri, Jan 29, 2016 at 4:23 PM, oleg yusim wrote: > >> Alex, >> >> No offense are taken, your question is absolutely legit. As we used to >> joke in security world "putting on my black hat"/"putting on my white hat" >> - i.e. same set of questions I would be asking for hacking and protecting >> the product. So, I commend you for being careful here. >> >> Now, at that particular case I'm acting with my "white hat on". :) I'm >> hired by VMware, to help them improve security posture for their new >> products (vRealize package). I do that as part of the security team on >> VMware side, and working in conjunction with DISA ( >> http://iase.disa.mil/stigs/Pages/a-z.aspx) we are creating STIGs (I >> explained this term in details in this same thread above, in my response to >> Jon, so I wouldn't repeat myself here) for all the components vRealize >> suite of products has, including Cassandra, which is used in one of the >> products. This STIGs would be handed over to DISA, reviewed by their SMEs >> and published on their website, creating great opportunity for all the >> products covered to improve their security posture and advance on a market >> for free. >> >> For VMware purposes, we would harden our suite of products, based on >> STIGs, and create own overall Security Guideline, riding on top of STIGs. >> >> As I mentioned above, for both Cassandra and DSE, equally, this document >> would be very beneficial, since it would enable customers and help them to >> run hardening on the product and place it right on the system, surrounded >> by the correct set of compensation controls. >> >> Thanks, >> >> Oleg >> >> On Fri, Jan 29, 2016 at 1:10 PM, Alex Popescu wrote: >> >>> >>> On Fri, Jan 29, 2016 at 8:17 AM, oleg yusim wrote: >>> >>>> Thanks for encouraging me, I kind of grew a bit desperate. I'm security >>>> person, not a Cassandra expert, and doing security assessment of Cassandra >>>> DB, I have to rely on community heavily. I will put together a composed >>>> version of all my previous queries, will title it "Security assessment >>>> questions" and will post it once again. >>> >>> >>> Oleg, >>> >>> I'll apologize in advance if my answer will sound initially harsh. I've >>> been following your questions (mostly because I find them interesting), but >>> I've never jumped to answer any of them as I confess not knowing the >>> purpose of your research/report makes me caution (e.g. are you doing this >>> for your current employer evaluating the future use of the product? are you >>> doing this for an analyst company? are you planning to sell this report? >>> etc. etc). >>> >>> >>> -- >>> Bests, >>> >>> Alex Popescu | @al3xandru >>> Sen. Product Manager @ DataStax >>> >>> >> >
Re: Session timeout
Alex, No offense are taken, your question is absolutely legit. As we used to joke in security world "putting on my black hat"/"putting on my white hat" - i.e. same set of questions I would be asking for hacking and protecting the product. So, I commend you for being careful here. Now, at that particular case I'm acting with my "white hat on". :) I'm hired by VMware, to help them improve security posture for their new products (vRealize package). I do that as part of the security team on VMware side, and working in conjunction with DISA ( http://iase.disa.mil/stigs/Pages/a-z.aspx) we are creating STIGs (I explained this term in details in this same thread above, in my response to Jon, so I wouldn't repeat myself here) for all the components vRealize suite of products has, including Cassandra, which is used in one of the products. This STIGs would be handed over to DISA, reviewed by their SMEs and published on their website, creating great opportunity for all the products covered to improve their security posture and advance on a market for free. For VMware purposes, we would harden our suite of products, based on STIGs, and create own overall Security Guideline, riding on top of STIGs. As I mentioned above, for both Cassandra and DSE, equally, this document would be very beneficial, since it would enable customers and help them to run hardening on the product and place it right on the system, surrounded by the correct set of compensation controls. Thanks, Oleg On Fri, Jan 29, 2016 at 1:10 PM, Alex Popescu wrote: > > On Fri, Jan 29, 2016 at 8:17 AM, oleg yusim wrote: > >> Thanks for encouraging me, I kind of grew a bit desperate. I'm security >> person, not a Cassandra expert, and doing security assessment of Cassandra >> DB, I have to rely on community heavily. I will put together a composed >> version of all my previous queries, will title it "Security assessment >> questions" and will post it once again. > > > Oleg, > > I'll apologize in advance if my answer will sound initially harsh. I've > been following your questions (mostly because I find them interesting), but > I've never jumped to answer any of them as I confess not knowing the > purpose of your research/report makes me caution (e.g. are you doing this > for your current employer evaluating the future use of the product? are you > doing this for an analyst company? are you planning to sell this report? > etc. etc). > > > -- > Bests, > > Alex Popescu | @al3xandru > Sen. Product Manager @ DataStax > >
Re: Session timeout
Jeff, Understood. Thanks for your response. I would put together my questions in one thread here, will title it "Security". Then I will move whatever was not answered to the dev thread. Thanks, Oleg On Fri, Jan 29, 2016 at 11:42 AM, Jeff Jirsa wrote: > > > For instance, way AAA (authentication, authorization, audit) is done, > doesn't allow for centralized account and access control management, which > in reality translates into shared accounts and no hierarchy. > > Authentication and Authorization are both pluggable. Any organization can > write their own, and tie it to any AAA system they currently have. If they > were feeling generous, they could open source it for the community, and > perhaps bring it upstream. There’s nothing fundamentally preventing your > organization from writing an Authenticator ( > https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/auth/IAuthenticator.java > ) > or Authorizor ( > https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/auth/IAuthorizer.java > ) > if they were so inclined. > > Audit is something that’s being actively discussed ( > https://issues.apache.org/jira/browse/CASSANDRA-8844 ). > > It’s an open source project with a very small number of commercial > vendors. In general, that means there are 3 options: > >1. Wait for someone else to write it to fit their need, and hopefully >they open source it. >2. Write it yourself >3. Pay a vendor (such as Datastax), and let them know in advance it’s >a requirement to get it on their roadmap. This is really #2 with some >polish to make it easier to get through your legal/AP systems. > > > So far it doesn't work quite well, and from what you are saying, it > wouldn't, because of lack of knowledge and lack of motivation to get it. > What would be your suggestion? Who is capable of answering my questions? Is > there another community, I should turn to? > > The cassandra-user and cassandra-dev mailing lists are the primary sources > of knowledge outside of support contracts. For paid support, companies like > Datastax and The Last Pickle tend to be well respected options. Both of > those companies will probably answer some of your questions for free if you > post on these mailing lists. They’ll likely answer even more if you pay > them. > > > > From: oleg yusim > Reply-To: "user@cassandra.apache.org" > Date: Friday, January 29, 2016 at 9:16 AM > To: "user@cassandra.apache.org" > Subject: Re: Session timeout > > Jon, > > I suspected something like that. I did a bit of learning on Cassandra > before starting my assessment, and I understand that you are right, and it > is generally not used like that. > > However (taking off my developer hat and putting on my security architect > hat), from the security point of view the way Cassandra is used now is not > very secure. For instance, way AAA (authentication, authorization, audit) > is done, doesn't allow for centralized account and access control > management, which in reality translates into shared accounts and no > hierarchy. That in turn translates into situation when one person > compromising credentials means complete disaster - administrative access to > DB was just given up, with all the consequences. To top it all logging > currently implemented in horrible manner too. It doesn't even allow to log > username - basic requirement for any product, which would allow DBA or ISSO > to figure out who did what on DB and recover in case of attack or crash. In > general, logs the way they are today are targeted toward developer, making > changes in DB, not toward the DBA, using it, and doesn't make much sense in > my opinion. > > Now if you are interested in that subject, that document: > http://iasecontent.disa.mil/stigs/zip/Jan2016/U_Database_V2R3_SRG.zip > covers security concerns which should be taken in the account, when we are > designing database. It also explains why each of them is important and what > exactly would happen if it would be neglected. > > Jon, I would also appreciate suggestion. What I do right now is called > "writing a STIG".That is when somebody takes concepts from SRG (the > document I gave you link to above) and figures out how those are applied to > that particular product. What is met (and what configuration on product > leads to it, exactly), what is not met, but can be with little enhancement > (and again - what those would be exactly), and what is not met and can't be > met at current design. All that is combined into one document, called STIG > and published by government (DISA) on > http://iase.disa.mil/stigs/Pages/a-z.aspx page. Those
Re: Security labels
Dani, I really appreciate you response. Actually, session timeouts and security labels are two different topics (first is about attack when somebody opened, say, ssh window to DB, left his machine unattended and somebody else stole his session, second - to enable DB to support what called MAC access model - stays for mandatory access control. It is widely used in the government and military, but not outside of it, we all are used to DAC access control model). However, I think you are right and I should move all my queries under the one big roof and call this thread "Security". I will do this today. Now, about what you have said, I just answered the same to Jon, in Session Timeout thread, but would quickly re-cap here. I understand that Cassandra's architecture was aimed and tailored for completely different type of scenario. However, unfortunately, that doesn't mean that Cassandra is not vulnerable to the same very set of attacks relational database would be vulnerable to. It just means Cassandra is not protected against those attacks, because protection against them was not thought of, when database was created. I already gave the AAA and session's timeout example in Jon's thread, and those are just one of many. Now what I'm trying to do, I'm trying to create a STIG - security federal compliance document, which will assess Cassandra against SRG concepts (security federal compliance recommendations for databases overall) and will highlight what is not met, and can't be in current design (i.e. what system architects should keep in mind and what they need to compensate for with other controls on different layers of system model) and what can be met either with configuration or with little enhancement (and how). That document would be of great help for Cassandra as a product because it would allow it to be marketed as a product with existing security assessment and guidelines, performed according to DoD standards. It would also allow to move product in the general direction of improving its security posture. Finally, the document would be posted on DISA site ( http://iase.disa.mil/stigs/Pages/a-z.aspx) available for every security architect to utilize, which would greatly reduce the risk for Cassandra product to be hacked in a field. To clear things out - what I ask about are not my expectations. I really do not expect developers of Cassandra to run and start implementing security labels, just because I asked about it. :) My questions are to build my internal knowledge of DB current design, so that I can build my security assessment based of it, not more, not less. I guess, summarizing what I said on top, from what I'm doing Cassandra as a product would end up benefiting quite a bit. That is why I think it would make sense for Cassandra community to help me with my questions even if they sound completely of the traditional "grid". Thanks again, I really appreciate your response and conversation overall. Oleg On Fri, Jan 29, 2016 at 11:20 AM, Dani Traphagen < dani.trapha...@datastax.com> wrote: > Also -- it looks like you're really asking questions about session > timeouts and security labels as they associate, would be more helpful to > keep in one thread. :) > > > On Friday, January 29, 2016, Dani Traphagen > wrote: > >> Hi Oleg, >> >> I understand your frustration but unfortunately, in the terms of your >> security assessment, you have fallen into a mismatch for Cassandra's >> utility. >> >> The eventuality of having multiple sockets open without the query input >> for long durations of time isn't something that was >> architected...because...Cassnadra was built to take massive quantities >> of queries both in volume and velocity. >> >> Your expectation of the database isn't in line with how our why it was >> designed. Generally, security solutions are architected >> around Cassandra, baked into the data model, many solutions >> are home-brewed, written into the application or provided by using another >> security client. >> >> DSE has different security aspects rolling out in the next release >> as addressed earlier by Jack, like commit log and hint encryptions, as well >> as, unified authentication...but secuirty labels aren't on anyone's radar >> as a pressing "need." It's not something I've heard about as a >> priority before anyway. >> >> Hope this helps! >> >> Cheers, >> Dani >> >> On Friday, January 29, 2016, oleg yusim wrote: >> >>> Jack, >>> >>> Thanks for your suggestion. I'm familiar with Cassandra documentation, >>> and I'm aware of differences between DSE and Cassandra. >>> >>> Questions I ask here are t
Re: Session timeout
Jon, I suspected something like that. I did a bit of learning on Cassandra before starting my assessment, and I understand that you are right, and it is generally not used like that. However (taking off my developer hat and putting on my security architect hat), from the security point of view the way Cassandra is used now is not very secure. For instance, way AAA (authentication, authorization, audit) is done, doesn't allow for centralized account and access control management, which in reality translates into shared accounts and no hierarchy. That in turn translates into situation when one person compromising credentials means complete disaster - administrative access to DB was just given up, with all the consequences. To top it all logging currently implemented in horrible manner too. It doesn't even allow to log username - basic requirement for any product, which would allow DBA or ISSO to figure out who did what on DB and recover in case of attack or crash. In general, logs the way they are today are targeted toward developer, making changes in DB, not toward the DBA, using it, and doesn't make much sense in my opinion. Now if you are interested in that subject, that document: http://iasecontent.disa.mil/stigs/zip/Jan2016/U_Database_V2R3_SRG.zip covers security concerns which should be taken in the account, when we are designing database. It also explains why each of them is important and what exactly would happen if it would be neglected. Jon, I would also appreciate suggestion. What I do right now is called "writing a STIG".That is when somebody takes concepts from SRG (the document I gave you link to above) and figures out how those are applied to that particular product. What is met (and what configuration on product leads to it, exactly), what is not met, but can be with little enhancement (and again - what those would be exactly), and what is not met and can't be met at current design. All that is combined into one document, called STIG and published by government (DISA) on http://iase.disa.mil/stigs/Pages/a-z.aspx page. Those STIGs mean a great deal from the security point of view because they: - Allow to save a lot of time on re-assessment of the product every single time - Allow to know what are the products limitations are from the security point of view before hands (and as such, place it right on the system, implementing all right compensation controls around it) - Allow to automate, both configuration checks from the security point of view and hardening of the product - Give product pass to DoD framework because if product has STIG and was configured in accordance to it, it is secure by DoD definition So overall, it is to the great benefit for the product to have STIG written for it, since it advances it on security market quite a bit and at the end - improves product's security posture quite a bit as well. My initial idea was that I would bring on board my knowledge of security concepts, and when I would lack understanding of intricate details of DB, I would turn to the Cassandra community for support. So far it doesn't work quite well, and from what you are saying, it wouldn't, because of lack of knowledge and lack of motivation to get it. What would be your suggestion? Who is capable of answering my questions? Is there another community, I should turn to? Would really appreciate your input on that, Thanks, Oleg On Fri, Jan 29, 2016 at 10:24 AM, Jonathan Haddad wrote: > I think the reason why most of your queries aren't being answered is > because you're asking questions that most people don't have the answer to. > On the automatic disconnect, anyone using Cassandra in prod doesn't really > need to think about it because we're always running queries, perhaps > millions a second. Queries are multiplexed over a single connection. > Almost nobody ever actually runs into a case of leaving a socket open for > hours without a query, so to find out if it actually happens, someone would > have to look it up in the source. > > Your questions about auditing are geared more towards if you're using a > database that's built for multi user access. Cassandra was built to solve > a very different problem. In most cases, you don't have hundreds of people > connecting from a shell, leaving connections open, casually querying for BI > reports. This isn't how *most* people use Cassandra, it wasn't really > built for that. There's better support for users & roles nowadays but it's > relatively new and that's about all you have right now. > > I realize you're new to the community, and it can be frustrating to not > get answers to questions that seem completely basic and obvious, but you're > asking about areas that *most* people on this list don't have knowledge > a
Re: Security labels
Jack, Thanks for your suggestion. I'm familiar with Cassandra documentation, and I'm aware of differences between DSE and Cassandra. Questions I ask here are those, I found no mention about in documentation. Let's take security labels for instance. Cassandra documentation is completely silent on this regard and so is Google. I assume, based on it, Cassandra doesn't support it. But I can't create federal compliance security document for Cassandra basing it of my assumptions and lack of information solely. That is where my questions stem from. Thanks, Oleg On Fri, Jan 29, 2016 at 10:17 AM, Jack Krupansky wrote: > To answer any future questions along these same lines, I suggest that you > start by simply searching the doc and search the github repo for the source > code for the relevant keywords. That will give you the definitive answers > quickly. If something is missing, feel free to propose that it be added (if > you really need it). And feel free to confirm here if a quick search > doesn't give you a solid answer. > > Here's the root page for security in the Cassandra doc: > > https://docs.datastax.com/en/cassandra/3.x/cassandra/configuration/secureTOC.html > > Also note that on questions of security, DataStax Enterprise may have > different answers than pure open source Cassandra. > > -- Jack Krupansky > > On Thu, Jan 28, 2016 at 8:37 PM, oleg yusim wrote: > >> Patrick, >> >> Absolutely. Security label is mechanism of access control, utilized by >> MAC (mandatory access control) model, and not utilized by DAC >> (discretionary access control) model, we all are used to. In database >> content it is illustrated for instance here: >> http://www.postgresql.org/docs/current/static/sql-security-label.html >> >> Now, as per my goals, I'm making a security assessment for Cassandra DB >> with a goal to produce STIG on this product. That is one of the parameters >> in database SRG I have to assess against. >> >> Thanks, >> >> Oleg >> >> >> On Thu, Jan 28, 2016 at 6:32 PM, Patrick McFadin >> wrote: >> >>> Cassandra has support for authentication security, but I'm not familiar >>> with a security label. Can you describe what you want to do? >>> >>> Patrick >>> >>> On Thu, Jan 28, 2016 at 2:26 PM, oleg yusim wrote: >>> >>>> Greetings, >>>> >>>> Does Cassandra support security label concept? If so, where can I read >>>> on how it should be applied? >>>> >>>> Thanks, >>>> >>>> Oleg >>>> >>> >>> >> >
Re: Session timeout
Hi Carlos, Thanks for encouraging me, I kind of grew a bit desperate. I'm security person, not a Cassandra expert, and doing security assessment of Cassandra DB, I have to rely on community heavily. I will put together a composed version of all my previous queries, will title it "Security assessment questions" and will post it once again. As per the session timeout, my understanding, Cassandra currently doesn't support it. I didn't find any mention of it in documentation. Also, I just ran simple experiment on my installation (version 2.1.8, default settings): I opened two ssh sessions on my Linux server, hosting Cassandra DB. On one, I entered cqlsh, another was just left as is. Then I stepped away from computer and went for breakfast. Now here are the results: first session with cqlsh still sits there, 50 minutes into it. Second was terminated in 15 minutes (ssh session timeout). As per the mailing list, a little housekeeping suggestion if I may. Right now our mailing list allows to reply to user@cassandra.apache.org. That leads to a situation, when all the emails are getting filtered to the same folder at the recipients end (I have it setup such way, I'm sure everybody else have similar setup too). If we will introduce "Reply to All" option, which would allow to reply not only to mailing list, but to personal email addresses of guys, involved into this particular conversation, those emails would bypass filters and would end up in our personal emails space in Inbox. This way we would help correspondents, engaged into the conversation to notice those emails easily, understand that those are targeted to them and stay engaged in the conversation, until the issue would be resolved one way or another. Thanks, Oleg On Fri, Jan 29, 2016 at 8:27 AM, Carlos Alonso wrote: > I've been in this community and mailing list quite a while now and it's > hard to find questions without answer. There are lots of good experts > willing to help here. If you don't see you question answered I'd advice you > to send it again, because its also true that the mailing list has quite a > lot of activity and its easy sometimes to miss emails. > > About this session timeout thing, could you please reply to this thread if > you find a solution? I'm curious about it. > > Cheers! > > Carlos Alonso | Software Engineer | @calonso <https://twitter.com/calonso> > > On 29 January 2016 at 14:19, oleg yusim wrote: > >> Not a problem, Carlos, at least you tried :) I have overall a big problem >> with my queries to Cassandra community. Most of them are not getting >> answered. >> >> Oleg >> >> On Fri, Jan 29, 2016 at 8:03 AM, Carlos Alonso >> wrote: >> >>> Oh, I thought you meant read/write timeout, not session timeout due to >>> inactivity... >>> >>> Not sure there's such option. Sorry >>> >>> Carlos Alonso | Software Engineer | @calonso >>> <https://twitter.com/calonso> >>> >>> On 29 January 2016 at 13:35, oleg yusim wrote: >>> >>>> Carlos, >>>> >>>> I went through Java and Python drivers... didn't find anything like >>>> that. Can you bring me example from your Ruby driver? Let me also make sure >>>> we are on the same page - I'm talking about session timeout due to >>>> inactivity, not read timeout or something like that. >>>> >>>> Thanks, >>>> >>>> Oleg >>>> >>>> On Fri, Jan 29, 2016 at 7:23 AM, Carlos Alonso >>>> wrote: >>>> >>>>> I personally don't use the Java but the Ruby driver, but I'm pretty >>>>> sure you'll be able to find it in the docs: >>>>> https://github.com/datastax/java-driver >>>>> >>>>> Carlos Alonso | Software Engineer | @calonso >>>>> <https://twitter.com/calonso> >>>>> >>>>> On 29 January 2016 at 13:15, oleg yusim wrote: >>>>> >>>>>> Hi Carlos, >>>>>> >>>>>> Thanks for your anwer. Can you, please, get me a bit me information? >>>>>> What is the driver? JDBC? What is the name of configuration file? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Oleg >>>>>> >>>>>> On Fri, Jan 29, 2016 at 5:12 AM, Carlos Alonso >>>>>> wrote: >>>>>> >>>>>>> Hi Oleg. >>>>>>> >>>>>>> The drivers have builtin the timeout configurable functionality. >>>>>>> >>>>>>> Hope it helps. >>>>>>> >>>>>>> Carlos Alonso | Software Engineer | @calonso >>>>>>> <https://twitter.com/calonso> >>>>>>> >>>>>>> On 28 January 2016 at 22:18, oleg yusim wrote: >>>>>>> >>>>>>>> Greetings, >>>>>>>> >>>>>>>> Does Cassandra support session timeout? If so, where can I find >>>>>>>> this configuration switch? If not, what kind of hook I can use to >>>>>>>> write my >>>>>>>> out code, terminating session in so many seconds of inactivity? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Oleg >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
Re: Session timeout
Not a problem, Carlos, at least you tried :) I have overall a big problem with my queries to Cassandra community. Most of them are not getting answered. Oleg On Fri, Jan 29, 2016 at 8:03 AM, Carlos Alonso wrote: > Oh, I thought you meant read/write timeout, not session timeout due to > inactivity... > > Not sure there's such option. Sorry > > Carlos Alonso | Software Engineer | @calonso <https://twitter.com/calonso> > > On 29 January 2016 at 13:35, oleg yusim wrote: > >> Carlos, >> >> I went through Java and Python drivers... didn't find anything like that. >> Can you bring me example from your Ruby driver? Let me also make sure we >> are on the same page - I'm talking about session timeout due to inactivity, >> not read timeout or something like that. >> >> Thanks, >> >> Oleg >> >> On Fri, Jan 29, 2016 at 7:23 AM, Carlos Alonso >> wrote: >> >>> I personally don't use the Java but the Ruby driver, but I'm pretty sure >>> you'll be able to find it in the docs: >>> https://github.com/datastax/java-driver >>> >>> Carlos Alonso | Software Engineer | @calonso >>> <https://twitter.com/calonso> >>> >>> On 29 January 2016 at 13:15, oleg yusim wrote: >>> >>>> Hi Carlos, >>>> >>>> Thanks for your anwer. Can you, please, get me a bit me information? >>>> What is the driver? JDBC? What is the name of configuration file? >>>> >>>> Thanks, >>>> >>>> Oleg >>>> >>>> On Fri, Jan 29, 2016 at 5:12 AM, Carlos Alonso >>>> wrote: >>>> >>>>> Hi Oleg. >>>>> >>>>> The drivers have builtin the timeout configurable functionality. >>>>> >>>>> Hope it helps. >>>>> >>>>> Carlos Alonso | Software Engineer | @calonso >>>>> <https://twitter.com/calonso> >>>>> >>>>> On 28 January 2016 at 22:18, oleg yusim wrote: >>>>> >>>>>> Greetings, >>>>>> >>>>>> Does Cassandra support session timeout? If so, where can I find this >>>>>> configuration switch? If not, what kind of hook I can use to write my out >>>>>> code, terminating session in so many seconds of inactivity? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Oleg >>>>>> >>>>> >>>>> >>>> >>> >> >
Re: Session timeout
Carlos, I went through Java and Python drivers... didn't find anything like that. Can you bring me example from your Ruby driver? Let me also make sure we are on the same page - I'm talking about session timeout due to inactivity, not read timeout or something like that. Thanks, Oleg On Fri, Jan 29, 2016 at 7:23 AM, Carlos Alonso wrote: > I personally don't use the Java but the Ruby driver, but I'm pretty sure > you'll be able to find it in the docs: > https://github.com/datastax/java-driver > > Carlos Alonso | Software Engineer | @calonso <https://twitter.com/calonso> > > On 29 January 2016 at 13:15, oleg yusim wrote: > >> Hi Carlos, >> >> Thanks for your anwer. Can you, please, get me a bit me information? What >> is the driver? JDBC? What is the name of configuration file? >> >> Thanks, >> >> Oleg >> >> On Fri, Jan 29, 2016 at 5:12 AM, Carlos Alonso >> wrote: >> >>> Hi Oleg. >>> >>> The drivers have builtin the timeout configurable functionality. >>> >>> Hope it helps. >>> >>> Carlos Alonso | Software Engineer | @calonso >>> <https://twitter.com/calonso> >>> >>> On 28 January 2016 at 22:18, oleg yusim wrote: >>> >>>> Greetings, >>>> >>>> Does Cassandra support session timeout? If so, where can I find this >>>> configuration switch? If not, what kind of hook I can use to write my out >>>> code, terminating session in so many seconds of inactivity? >>>> >>>> Thanks, >>>> >>>> Oleg >>>> >>> >>> >> >
Re: Session timeout
Hi Carlos, Thanks for your anwer. Can you, please, get me a bit me information? What is the driver? JDBC? What is the name of configuration file? Thanks, Oleg On Fri, Jan 29, 2016 at 5:12 AM, Carlos Alonso wrote: > Hi Oleg. > > The drivers have builtin the timeout configurable functionality. > > Hope it helps. > > Carlos Alonso | Software Engineer | @calonso <https://twitter.com/calonso> > > On 28 January 2016 at 22:18, oleg yusim wrote: > >> Greetings, >> >> Does Cassandra support session timeout? If so, where can I find this >> configuration switch? If not, what kind of hook I can use to write my out >> code, terminating session in so many seconds of inactivity? >> >> Thanks, >> >> Oleg >> > >
Logging connect/disconnect
Greetings, What is the right way to configure Cassandra logging, so it would log all the connects and disconnects? Thanks, Oleg
Re: Security labels
Patrick, Absolutely. Security label is mechanism of access control, utilized by MAC (mandatory access control) model, and not utilized by DAC (discretionary access control) model, we all are used to. In database content it is illustrated for instance here: http://www.postgresql.org/docs/current/static/sql-security-label.html Now, as per my goals, I'm making a security assessment for Cassandra DB with a goal to produce STIG on this product. That is one of the parameters in database SRG I have to assess against. Thanks, Oleg On Thu, Jan 28, 2016 at 6:32 PM, Patrick McFadin wrote: > Cassandra has support for authentication security, but I'm not familiar > with a security label. Can you describe what you want to do? > > Patrick > > On Thu, Jan 28, 2016 at 2:26 PM, oleg yusim wrote: > >> Greetings, >> >> Does Cassandra support security label concept? If so, where can I read on >> how it should be applied? >> >> Thanks, >> >> Oleg >> > >
Security labels
Greetings, Does Cassandra support security label concept? If so, where can I read on how it should be applied? Thanks, Oleg
Session timeout
Greetings, Does Cassandra support session timeout? If so, where can I find this configuration switch? If not, what kind of hook I can use to write my out code, terminating session in so many seconds of inactivity? Thanks, Oleg
Logging configuration (security)
Greetings, I decided to put together a separate thread with logging configuration questions I have (I'm trying to figure out what from security best practices on logging Cassandra can and can't do): 1) Can Cassandra log IP and hostname of the host, DB resides at? 2) Can Cassandra log IP and hostname of the client? 3) Can Cassandra be configured to be automatically shut down in case if it ran out of space to store logs? 4) Can Cassandra be configured to automatically overwrite audit logs in case if no more space is available (oldest first) ? Thanks, Oleg
Re: Logging
Sam, Paulo,
One more question on logging. Can I add IP and hostname to the log message?
If it is possible, can you give me example of how I would need to
change %-5level %date{HH:mm:ss,SSS} %msg%n to add this
information?
Thanks,
Oleg
On Tue, Jan 26, 2016 at 4:42 PM, oleg yusim wrote:
> Sam, Paulo,
>
> Thank you very much for explanations and references.
>
> Oleg
>
> On Mon, Jan 25, 2016 at 10:08 AM, Sam Tunnicliffe wrote:
>
>> Paulo is correct in saying that C* doesn't have a direct equivalent of
>> SecurityContextHolder. Authenticated principal info is retrievable from the
>> QueryState during query execution but a) this isn't available to every
>> method in the call chain and b) its scope is limited to the coordinator for
>> the request. That is, it isn't serialized and included in the read/mutation
>> messages which the coordinator distributes to the replicas. So you could
>> produce a level of audit trail by providing a custom QueryHandler (See
>> CASSANDRA-6659) that logs each statement along with the principal. But if
>> the goal is indeed that "every log message in file should start with
>> username of the user, who initiated this action", it's isn't really
>> feasible right now
>>
>> On Mon, Jan 25, 2016 at 3:52 PM, Paulo Motta
>> wrote:
>>
>>> That would work, but afaik Cassandra doesn't have an equivalent of
>>> RequestContextHolder/SecurityContextHolder that is able to retrieve the
>>> user/session of a given thread/request (maybe I'm wrong as I'm no auth
>>> expert), so if these don't exist we'd need to add equivalent to those or do
>>> it via MDC (set the context when request arrives, propagate to down stream
>>> threads, cleanup), which can become quite messy as shown in CASSANDRA-7276.
>>>
>>> For CQL statements perhaps the query tracing infrastructure could be
>>> reused to provide that info, but that would require further investigation.
>>> See CASSANDRA-1123 for more details on that.
>>>
>>> 2016-01-25 12:30 GMT-03:00 oleg yusim :
>>>
>>>> Paulo,
>>>>
>>>> Ideally - all the actions (security purposes, preserving completness of
>>>> the audit trail). How about this approach:
>>>> http://www.codelord.net/2010/08/27/logging-with-a-context-users-in-logback-and-spring-security/
>>>> ?
>>>> Would that work? Or you would rather suggest to go MDC way?
>>>>
>>>> Thanks,
>>>>
>>>> Oleg
>>>>
>>>> On Mon, Jan 25, 2016 at 9:23 AM, Paulo Motta
>>>> wrote:
>>>>
>>>>> What kind of actions? nodetool/system actions or cql statements?
>>>>>
>>>>> You could probably achieve identity-based logging with logback Mapped
>>>>> Diagnostic Context (MDC - logback.qos.ch/manual/mdc.html), but you'd
>>>>> need to patch your own Cassandra jars in many locations to provide that
>>>>> information to the logging context, so not exactly a trivial thing to do.
>>>>> We tried using that to print ks/cf names on log messages but it became a
>>>>> bit messy due to the SEDA architecture as you need to patch executors to
>>>>> inherit identifiers from parent threads and cleanup afterwards. See
>>>>> CASSANDRA-7276 for more background.
>>>>>
>>>>> 2016-01-25 12:09 GMT-03:00 oleg yusim :
>>>>>
>>>>>> I want to try to re-phrase my question here... what I'm trying to
>>>>>> achieve is identity-based logging. I.e. every log message in file should
>>>>>> start with username of the user, who initiated this action. Would that be
>>>>>> possible to achieve? If so, can you give me a brief example?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Oleg
>>>>>>
>>>>>> On Thu, Jan 21, 2016 at 2:57 PM, oleg yusim
>>>>>> wrote:
>>>>>>
>>>>>>> Joel,
>>>>>>>
>>>>>>> Thanks for reference. What I'm trying to achieve, is to add the name
>>>>>>> of the user, who initiated logged action. I tried c{5}, but what I see
>>>>>>> is
>>>>>>> that;
>>>>>>>
>>>>>>> TRACE [GossipTasks:1] c{5} 2016-01-21 20:51:17,619 Gossiper.java:700
>>>>>>> - Performing status check ...
>>>>
Re: Logging
Sam, Paulo,
Thank you very much for explanations and references.
Oleg
On Mon, Jan 25, 2016 at 10:08 AM, Sam Tunnicliffe wrote:
> Paulo is correct in saying that C* doesn't have a direct equivalent of
> SecurityContextHolder. Authenticated principal info is retrievable from the
> QueryState during query execution but a) this isn't available to every
> method in the call chain and b) its scope is limited to the coordinator for
> the request. That is, it isn't serialized and included in the read/mutation
> messages which the coordinator distributes to the replicas. So you could
> produce a level of audit trail by providing a custom QueryHandler (See
> CASSANDRA-6659) that logs each statement along with the principal. But if
> the goal is indeed that "every log message in file should start with
> username of the user, who initiated this action", it's isn't really
> feasible right now
>
> On Mon, Jan 25, 2016 at 3:52 PM, Paulo Motta
> wrote:
>
>> That would work, but afaik Cassandra doesn't have an equivalent of
>> RequestContextHolder/SecurityContextHolder that is able to retrieve the
>> user/session of a given thread/request (maybe I'm wrong as I'm no auth
>> expert), so if these don't exist we'd need to add equivalent to those or do
>> it via MDC (set the context when request arrives, propagate to down stream
>> threads, cleanup), which can become quite messy as shown in CASSANDRA-7276.
>>
>> For CQL statements perhaps the query tracing infrastructure could be
>> reused to provide that info, but that would require further investigation.
>> See CASSANDRA-1123 for more details on that.
>>
>> 2016-01-25 12:30 GMT-03:00 oleg yusim :
>>
>>> Paulo,
>>>
>>> Ideally - all the actions (security purposes, preserving completness of
>>> the audit trail). How about this approach:
>>> http://www.codelord.net/2010/08/27/logging-with-a-context-users-in-logback-and-spring-security/
>>> ?
>>> Would that work? Or you would rather suggest to go MDC way?
>>>
>>> Thanks,
>>>
>>> Oleg
>>>
>>> On Mon, Jan 25, 2016 at 9:23 AM, Paulo Motta
>>> wrote:
>>>
>>>> What kind of actions? nodetool/system actions or cql statements?
>>>>
>>>> You could probably achieve identity-based logging with logback Mapped
>>>> Diagnostic Context (MDC - logback.qos.ch/manual/mdc.html), but you'd
>>>> need to patch your own Cassandra jars in many locations to provide that
>>>> information to the logging context, so not exactly a trivial thing to do.
>>>> We tried using that to print ks/cf names on log messages but it became a
>>>> bit messy due to the SEDA architecture as you need to patch executors to
>>>> inherit identifiers from parent threads and cleanup afterwards. See
>>>> CASSANDRA-7276 for more background.
>>>>
>>>> 2016-01-25 12:09 GMT-03:00 oleg yusim :
>>>>
>>>>> I want to try to re-phrase my question here... what I'm trying to
>>>>> achieve is identity-based logging. I.e. every log message in file should
>>>>> start with username of the user, who initiated this action. Would that be
>>>>> possible to achieve? If so, can you give me a brief example?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Oleg
>>>>>
>>>>> On Thu, Jan 21, 2016 at 2:57 PM, oleg yusim
>>>>> wrote:
>>>>>
>>>>>> Joel,
>>>>>>
>>>>>> Thanks for reference. What I'm trying to achieve, is to add the name
>>>>>> of the user, who initiated logged action. I tried c{5}, but what I see is
>>>>>> that;
>>>>>>
>>>>>> TRACE [GossipTasks:1] c{5} 2016-01-21 20:51:17,619 Gossiper.java:700
>>>>>> - Performing status check ...
>>>>>>
>>>>>> I think, I'm missing something here. Any suggestions?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Oleg
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Jan 21, 2016 at 1:30 PM, Joel Knighton <
>>>>>> joel.knigh...@datastax.com> wrote:
>>>>>>
>>>>>>> Cassandra uses logback as its backend for logging.
>>>>>>>
>>>>>>> You can find information about configuring logging in Cassandra by
&
Re: Logging
Paulo,
Ideally - all the actions (security purposes, preserving completness of the
audit trail). How about this approach:
http://www.codelord.net/2010/08/27/logging-with-a-context-users-in-logback-and-spring-security/
?
Would that work? Or you would rather suggest to go MDC way?
Thanks,
Oleg
On Mon, Jan 25, 2016 at 9:23 AM, Paulo Motta
wrote:
> What kind of actions? nodetool/system actions or cql statements?
>
> You could probably achieve identity-based logging with logback Mapped
> Diagnostic Context (MDC - logback.qos.ch/manual/mdc.html), but you'd need
> to patch your own Cassandra jars in many locations to provide that
> information to the logging context, so not exactly a trivial thing to do.
> We tried using that to print ks/cf names on log messages but it became a
> bit messy due to the SEDA architecture as you need to patch executors to
> inherit identifiers from parent threads and cleanup afterwards. See
> CASSANDRA-7276 for more background.
>
> 2016-01-25 12:09 GMT-03:00 oleg yusim :
>
>> I want to try to re-phrase my question here... what I'm trying to achieve
>> is identity-based logging. I.e. every log message in file should start with
>> username of the user, who initiated this action. Would that be possible to
>> achieve? If so, can you give me a brief example?
>>
>> Thanks,
>>
>> Oleg
>>
>> On Thu, Jan 21, 2016 at 2:57 PM, oleg yusim wrote:
>>
>>> Joel,
>>>
>>> Thanks for reference. What I'm trying to achieve, is to add the name of
>>> the user, who initiated logged action. I tried c{5}, but what I see is that;
>>>
>>> TRACE [GossipTasks:1] c{5} 2016-01-21 20:51:17,619 Gossiper.java:700 -
>>> Performing status check ...
>>>
>>> I think, I'm missing something here. Any suggestions?
>>>
>>> Thanks,
>>>
>>> Oleg
>>>
>>>
>>>
>>> On Thu, Jan 21, 2016 at 1:30 PM, Joel Knighton <
>>> joel.knigh...@datastax.com> wrote:
>>>
>>>> Cassandra uses logback as its backend for logging.
>>>>
>>>> You can find information about configuring logging in Cassandra by
>>>> searching for "Configuring logging" on docs.datastax.com and selecting
>>>> the documentation for your version.
>>>>
>>>> The documentation for PatternLayouts (the pattern string about which
>>>> you're asking) in logback is available in the logback manual under the
>>>> section for Conversion Words
>>>> http://logback.qos.ch/manual/layouts.html#conversionWord
>>>>
>>>>
>>>> On Thu, Jan 21, 2016 at 1:21 PM, oleg yusim
>>>> wrote:
>>>>
>>>>> Greetings,
>>>>>
>>>>> Guys, can you, please, point me to documentation on how to configure
>>>>> format of logs? I want make it clear, I'm talking about formatting i.e.
>>>>> this:
>>>>>
>>>>> %-5level %date{HH:mm:ss,SSS} %msg%n
>>>>>
>>>>> What if I want to add another parameters into this string? Is there a
>>>>> list of available parameters here and syntax?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Oleg
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> <http://www.datastax.com/>
>>>>
>>>> Joel Knighton
>>>> Cassandra Developer | joel.knigh...@datastax.com
>>>>
>>>> <https://www.linkedin.com/company/datastax>
>>>> <https://www.facebook.com/datastax> <https://twitter.com/datastax>
>>>> <https://plus.google.com/+Datastax/about>
>>>> <http://feeds.feedburner.com/datastax> <https://github.com/datastax/>
>>>>
>>>
>>>
>>
>
Re: Logging
I want to try to re-phrase my question here... what I'm trying to achieve
is identity-based logging. I.e. every log message in file should start with
username of the user, who initiated this action. Would that be possible to
achieve? If so, can you give me a brief example?
Thanks,
Oleg
On Thu, Jan 21, 2016 at 2:57 PM, oleg yusim wrote:
> Joel,
>
> Thanks for reference. What I'm trying to achieve, is to add the name of
> the user, who initiated logged action. I tried c{5}, but what I see is that;
>
> TRACE [GossipTasks:1] c{5} 2016-01-21 20:51:17,619 Gossiper.java:700 -
> Performing status check ...
>
> I think, I'm missing something here. Any suggestions?
>
> Thanks,
>
> Oleg
>
>
>
> On Thu, Jan 21, 2016 at 1:30 PM, Joel Knighton > wrote:
>
>> Cassandra uses logback as its backend for logging.
>>
>> You can find information about configuring logging in Cassandra by
>> searching for "Configuring logging" on docs.datastax.com and selecting
>> the documentation for your version.
>>
>> The documentation for PatternLayouts (the pattern string about which
>> you're asking) in logback is available in the logback manual under the
>> section for Conversion Words
>> http://logback.qos.ch/manual/layouts.html#conversionWord
>>
>>
>> On Thu, Jan 21, 2016 at 1:21 PM, oleg yusim wrote:
>>
>>> Greetings,
>>>
>>> Guys, can you, please, point me to documentation on how to configure
>>> format of logs? I want make it clear, I'm talking about formatting i.e.
>>> this:
>>>
>>> %-5level %date{HH:mm:ss,SSS} %msg%n
>>>
>>> What if I want to add another parameters into this string? Is there a
>>> list of available parameters here and syntax?
>>>
>>> Thanks,
>>>
>>> Oleg
>>>
>>>
>>
>>
>> --
>>
>> <http://www.datastax.com/>
>>
>> Joel Knighton
>> Cassandra Developer | joel.knigh...@datastax.com
>>
>> <https://www.linkedin.com/company/datastax>
>> <https://www.facebook.com/datastax> <https://twitter.com/datastax>
>> <https://plus.google.com/+Datastax/about>
>> <http://feeds.feedburner.com/datastax> <https://github.com/datastax/>
>>
>
>
Re: Logging
Joel,
Thanks for reference. What I'm trying to achieve, is to add the name of the
user, who initiated logged action. I tried c{5}, but what I see is that;
TRACE [GossipTasks:1] c{5} 2016-01-21 20:51:17,619 Gossiper.java:700 -
Performing status check ...
I think, I'm missing something here. Any suggestions?
Thanks,
Oleg
On Thu, Jan 21, 2016 at 1:30 PM, Joel Knighton
wrote:
> Cassandra uses logback as its backend for logging.
>
> You can find information about configuring logging in Cassandra by
> searching for "Configuring logging" on docs.datastax.com and selecting
> the documentation for your version.
>
> The documentation for PatternLayouts (the pattern string about which
> you're asking) in logback is available in the logback manual under the
> section for Conversion Words
> http://logback.qos.ch/manual/layouts.html#conversionWord
>
>
> On Thu, Jan 21, 2016 at 1:21 PM, oleg yusim wrote:
>
>> Greetings,
>>
>> Guys, can you, please, point me to documentation on how to configure
>> format of logs? I want make it clear, I'm talking about formatting i.e.
>> this:
>>
>> %-5level %date{HH:mm:ss,SSS} %msg%n
>>
>> What if I want to add another parameters into this string? Is there a
>> list of available parameters here and syntax?
>>
>> Thanks,
>>
>> Oleg
>>
>>
>
>
> --
>
> <http://www.datastax.com/>
>
> Joel Knighton
> Cassandra Developer | joel.knigh...@datastax.com
>
> <https://www.linkedin.com/company/datastax>
> <https://www.facebook.com/datastax> <https://twitter.com/datastax>
> <https://plus.google.com/+Datastax/about>
> <http://feeds.feedburner.com/datastax> <https://github.com/datastax/>
>
Logging
Greetings,
Guys, can you, please, point me to documentation on how to configure format
of logs? I want make it clear, I'm talking about formatting i.e. this:
%-5level %date{HH:mm:ss,SSS} %msg%n
What if I want to add another parameters into this string? Is there a list
of available parameters here and syntax?
Thanks,
Oleg
Re: max connection per user
Let me revive this thread a little. I see, it is possible to limit concurrent connections based on IP or client: # The maximum number of concurrent client connections. # The default is -1, which means unlimited. # native_transport_max_concurrent_connections: -1 # The maximum number of concurrent client connections per source ip. # The default is -1, which means unlimited. # native_transport_max_concurrent_connections_per_ip: -1 My question would be - what is the current recommendations Cassandra team has for those? How many database can handle for sure? Thanks, Oleg On Wed, Jan 13, 2016 at 9:04 PM, oleg yusim wrote: > Brian - absolutely. > > To give you are brief description of what I'm doing. I'm working for > VMware as security architect, and they tasked me with creating a STIG > (working with DISA ) for Cassandra DB. To create a STIG I would walk > through the Database SRG security controls and assess them against > Cassandra DB configuration. As the result, I would have to address all the > security controls in SRG, proposing mitigations where Cassandra can't meet > it by means of configuring and specifying desired configuration, where it > would be possible to do so. > > At this particular place, I'm dealing with following security control: > > The DBMS must limit the number of concurrent sessions to an > organization-defined number per user for all accounts and/or account types. > > Here is the brief dive into why it is needed: > > > Database management includes the ability to control the number of users > and user sessions utilizing a DBMS. Unlimited concurrent connections to the > DBMS could allow a successful Denial of Service (DoS) attack by exhausting > connection resources; and a system can also fail or be degraded by an > overload of legitimate users. Limiting the number of concurrent sessions > per user is helpful in reducing these risks. > > This requirement addresses concurrent session control for a single > account. It does not address concurrent sessions by a single user via > multiple system accounts; and it does not deal with the total number of > sessions across all accounts. > > The capability to limit the number of concurrent sessions per user must be > configured in or added to the DBMS (for example, by use of a logon > trigger), when this is technically feasible. Note that it is not sufficient > to limit sessions via a web server or application server alone, because > legitimate users and adversaries can potentially connect to the DBMS by > other means. > > The organization will need to define the maximum number of concurrent > sessions by account type, by account, or a combination thereof. In deciding > on the appropriate number, it is important to consider the work > requirements of the various types of users. For example, 2 might be an > acceptable limit for general users accessing the database via an > application; but 10 might be too few for a database administrator using a > database management GUI tool, where each query tab and navigation pane may > count as a separate session. > > (Sessions may also be referred to as connections or logons, which for the > purposes of this requirement are synonyms.) > > > Now with that in mind, typical way to DoS database would be open more > connections than database can support, bringing server to its knees. > Typical way to counter it is limiting number of concurrent user sessions to > two and number of concurrent administrator sessions to 10. > > With the answer Rob provided me with, I'm reduced to searching for > mitigation control. That might be limiting maximum amount of connections to > database, to the amount database for sure can support. I know JDBC driver > has such configuration switches, allowing to go for that. The question now > is - how many? What is the number of simultanious connections Cassandra > would be able to bare? > > Thanks, > > Oleg > > On Wed, Jan 13, 2016 at 8:40 PM, Bryan Cheng > wrote: > >> Are you actively exposing your database to users outside of your >> organization, or are you just asking about security best practices? >> >> If you mean the former, this isn't really a common use case and there >> isn't a huge amount out of the box that Cassandra will do to help. >> >> If you're just asking about security best-practices, >> http://www.datastax.com/wp-content/uploads/2014/04/WP-DataStax-Enterprise-Best-Practices.pdf >> has a brief blurb, and there are many resources online for securing >> Cassandra specifically and databases in general- the approaches are going >> to be largely the same. >> >> Can you describe what avenues you're expecting either intrusion or DOS? >
Re: Encryption in cassandra
Jack, thank you for the link, but I'm not sure what you are referring to by Cassandra API security. If you mean TLS connection, Cassandra establishing to client and between nodes, than keystore and truststore do not seem to participate in it at all because Cassandra is using certs and keys, extracted from keystore during this connection, not those which are stored in it (that is what made me so surprised and prompted to start this discussion). Now, TLS connection per say would be secure or not secure regardless of how you position you keys and certs. What would be important here is ciphers you use (and Cassandra is doing that) and ability to use CRL (I do not think Cassandra is doing that). Now if we are talking if positioning of certificates and keys matters for Cassandra as a system, than - of course it matters. Certificates and keys are credentials Cassandra presents during TLS, so harm is the same as leaving password in clear text. So, help me out here, what am I missing? Thanks, Oleg On Thu, Jan 14, 2016 at 6:10 PM, Jack Krupansky wrote: > Cassandra is definitely assuming that you, the user, are separately > assuring that no intruder gets access to the box/root/login. The keystore > and truststore in Cassandra having nothing to do with system security, they > are solely for Cassandra API security. > > System security and Cassandra API security are two completely separate > issues. The Cassandra doc on (Cassandra, not system) security is here: > > https://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/secureIntro.html > > > > -- Jack Krupansky > > On Thu, Jan 14, 2016 at 5:49 PM, oleg yusim wrote: > >> Jack, >> >> Thanks for your answer. I guess, I'm a little confused by general >> architecture choice. It doesn't seem to be consistent to me. I mean, if we >> are building the layer of database specific security (i.e. we are saying, >> let's assume intruder is on the box, and he is root, what we can do?), then >> it is perfectly logical to build keystore and truststore, hide our keys and >> certificates there, encrypt the file with passwords from these stores and >> keep the key of the box. That is great, and as a security architect I >> applaud this. >> >> Now, if we are saying - no, we are banking on the fact nobody will break >> into the box, and if root is lost - all bets are off, that is fine too. But >> in this case, what is the point to even have keystore and truststore? >> >> Thanks, >> >> Oleg >> >> On Thu, Jan 14, 2016 at 4:38 PM, Jack Krupansky > > wrote: >> >>> The point of encryption in Cassandra is to protect data in flight >>> between the cluster and clients (or between nodes in the cluster.) The >>> presumption is that normal system network access control (e.g., remote >>> login, etc.) will preclude bad actors from directly accessing the file >>> system on a cluster node. >>> >>> -- Jack Krupansky >>> >>> On Thu, Jan 14, 2016 at 5:16 PM, oleg yusim wrote: >>> >>>> Greetings, >>>> >>>> Guys, can you please help me to understand following: >>>> >>>> I'm reading through the way keystore and truststore are implemented, >>>> and it is all fine and great, but at the end Cassandra documentation >>>> instructing to extract all the keystore content and leave all certs and >>>> keys in a clear. >>>> >>>> Do I miss something here? Why are we doing it? What is the point to >>>> even have a keystore then? It doesn't look very secure to me... >>>> >>>> Another item - cassandra.yaml has passwords from keystore and >>>> truststore - clear text... what is the point to have these stores then, if >>>> passwords are out? >>>> >>>> Thanks, >>>> >>>> Oleg >>>> >>> >>> >> >
Re: Encryption in cassandra
Daemeon, Can you, please, give me a bit of beef to your idea? I'm not sure I'm fully on board here. Thanks, Oleg On Thu, Jan 14, 2016 at 4:52 PM, daemeon reiydelle wrote: > The keys don't have to be on the box. You do need a logi/password for c*. > > sent from my mobile > Daemeon C.M. Reiydelle > USA 415.501.0198 > London +44.0.20.8144.9872 > On Jan 14, 2016 5:16 PM, "oleg yusim" wrote: > >> Greetings, >> >> Guys, can you please help me to understand following: >> >> I'm reading through the way keystore and truststore are implemented, and >> it is all fine and great, but at the end Cassandra documentation >> instructing to extract all the keystore content and leave all certs and >> keys in a clear. >> >> Do I miss something here? Why are we doing it? What is the point to even >> have a keystore then? It doesn't look very secure to me... >> >> Another item - cassandra.yaml has passwords from keystore and truststore >> - clear text... what is the point to have these stores then, if passwords >> are out? >> >> Thanks, >> >> Oleg >> >
Re: Encryption in cassandra
Jack, Thanks for your answer. I guess, I'm a little confused by general architecture choice. It doesn't seem to be consistent to me. I mean, if we are building the layer of database specific security (i.e. we are saying, let's assume intruder is on the box, and he is root, what we can do?), then it is perfectly logical to build keystore and truststore, hide our keys and certificates there, encrypt the file with passwords from these stores and keep the key of the box. That is great, and as a security architect I applaud this. Now, if we are saying - no, we are banking on the fact nobody will break into the box, and if root is lost - all bets are off, that is fine too. But in this case, what is the point to even have keystore and truststore? Thanks, Oleg On Thu, Jan 14, 2016 at 4:38 PM, Jack Krupansky wrote: > The point of encryption in Cassandra is to protect data in flight between > the cluster and clients (or between nodes in the cluster.) The presumption > is that normal system network access control (e.g., remote login, etc.) > will preclude bad actors from directly accessing the file system on a > cluster node. > > -- Jack Krupansky > > On Thu, Jan 14, 2016 at 5:16 PM, oleg yusim wrote: > >> Greetings, >> >> Guys, can you please help me to understand following: >> >> I'm reading through the way keystore and truststore are implemented, and >> it is all fine and great, but at the end Cassandra documentation >> instructing to extract all the keystore content and leave all certs and >> keys in a clear. >> >> Do I miss something here? Why are we doing it? What is the point to even >> have a keystore then? It doesn't look very secure to me... >> >> Another item - cassandra.yaml has passwords from keystore and truststore >> - clear text... what is the point to have these stores then, if passwords >> are out? >> >> Thanks, >> >> Oleg >> > >
Encryption in cassandra
Greetings, Guys, can you please help me to understand following: I'm reading through the way keystore and truststore are implemented, and it is all fine and great, but at the end Cassandra documentation instructing to extract all the keystore content and leave all certs and keys in a clear. Do I miss something here? Why are we doing it? What is the point to even have a keystore then? It doesn't look very secure to me... Another item - cassandra.yaml has passwords from keystore and truststore - clear text... what is the point to have these stores then, if passwords are out? Thanks, Oleg
Re: max connection per user
Brian - absolutely. To give you are brief description of what I'm doing. I'm working for VMware as security architect, and they tasked me with creating a STIG (working with DISA ) for Cassandra DB. To create a STIG I would walk through the Database SRG security controls and assess them against Cassandra DB configuration. As the result, I would have to address all the security controls in SRG, proposing mitigations where Cassandra can't meet it by means of configuring and specifying desired configuration, where it would be possible to do so. At this particular place, I'm dealing with following security control: The DBMS must limit the number of concurrent sessions to an organization-defined number per user for all accounts and/or account types. Here is the brief dive into why it is needed: Database management includes the ability to control the number of users and user sessions utilizing a DBMS. Unlimited concurrent connections to the DBMS could allow a successful Denial of Service (DoS) attack by exhausting connection resources; and a system can also fail or be degraded by an overload of legitimate users. Limiting the number of concurrent sessions per user is helpful in reducing these risks. This requirement addresses concurrent session control for a single account. It does not address concurrent sessions by a single user via multiple system accounts; and it does not deal with the total number of sessions across all accounts. The capability to limit the number of concurrent sessions per user must be configured in or added to the DBMS (for example, by use of a logon trigger), when this is technically feasible. Note that it is not sufficient to limit sessions via a web server or application server alone, because legitimate users and adversaries can potentially connect to the DBMS by other means. The organization will need to define the maximum number of concurrent sessions by account type, by account, or a combination thereof. In deciding on the appropriate number, it is important to consider the work requirements of the various types of users. For example, 2 might be an acceptable limit for general users accessing the database via an application; but 10 might be too few for a database administrator using a database management GUI tool, where each query tab and navigation pane may count as a separate session. (Sessions may also be referred to as connections or logons, which for the purposes of this requirement are synonyms.) Now with that in mind, typical way to DoS database would be open more connections than database can support, bringing server to its knees. Typical way to counter it is limiting number of concurrent user sessions to two and number of concurrent administrator sessions to 10. With the answer Rob provided me with, I'm reduced to searching for mitigation control. That might be limiting maximum amount of connections to database, to the amount database for sure can support. I know JDBC driver has such configuration switches, allowing to go for that. The question now is - how many? What is the number of simultanious connections Cassandra would be able to bare? Thanks, Oleg On Wed, Jan 13, 2016 at 8:40 PM, Bryan Cheng wrote: > Are you actively exposing your database to users outside of your > organization, or are you just asking about security best practices? > > If you mean the former, this isn't really a common use case and there > isn't a huge amount out of the box that Cassandra will do to help. > > If you're just asking about security best-practices, > http://www.datastax.com/wp-content/uploads/2014/04/WP-DataStax-Enterprise-Best-Practices.pdf > has a brief blurb, and there are many resources online for securing > Cassandra specifically and databases in general- the approaches are going > to be largely the same. > > Can you describe what avenues you're expecting either intrusion or DOS? > > On Wed, Jan 13, 2016 at 6:01 PM, oleg yusim wrote: > >> OK Rob, I see what you saying. Well, let's dive into the long questions >> and answers at this case a bit: >> >> 1) Is there any other approach Cassandra currently utilizes to mitigate >> DoS attacks? >> 2) How about max connection per DB? I know, Cassandra has this parameter >> on JDBC driver configuration, but what be suggested value not to exceed? >> >> Thanks, >> >> Oleg >> >> On Wed, Jan 13, 2016 at 6:31 PM, Robert Coli >> wrote: >> >>> On Wed, Jan 13, 2016 at 1:41 PM, oleg yusim wrote: >>> >>>> Quick question, here: does Cassandra have a configuration switch to >>>> limit number of connections per user (protection of DoS attack, security)? >>>> >>> >>> Quick answer : no. >>> >>> =Rob >>> >>> >> >> >
Re: max connection per user
OK Rob, I see what you saying. Well, let's dive into the long questions and answers at this case a bit: 1) Is there any other approach Cassandra currently utilizes to mitigate DoS attacks? 2) How about max connection per DB? I know, Cassandra has this parameter on JDBC driver configuration, but what be suggested value not to exceed? Thanks, Oleg On Wed, Jan 13, 2016 at 6:31 PM, Robert Coli wrote: > On Wed, Jan 13, 2016 at 1:41 PM, oleg yusim wrote: > >> Quick question, here: does Cassandra have a configuration switch to limit >> number of connections per user (protection of DoS attack, security)? >> > > Quick answer : no. > > =Rob > >
max connection per user
Greetings, Quick question, here: does Cassandra have a configuration switch to limit number of connections per user (protection of DoS attack, security)? Thanks, Oleg
