You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by oleg yusim <ol...@gmail.com> on 2016/02/11 21:23:53 UTC
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 <dani.traphagen@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 <ol...@gmail.com> 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.traphagen@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 <da...@datastax.com>
>>> 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 <ol...@gmail.com> 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 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 <
>>>>> jack.krupansky@gmail.com> 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 <ol...@gmail.com>
>>>>>> 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 <pmcfadin@gmail.com
>>>>>>> > 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 <ol...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Greetings,
>>>>>>>>>
>>>>>>>>> Does Cassandra support security label concept? If so, where can I
>>>>>>>>> read on how it should be applied?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Oleg
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Sent from mobile -- apologizes for brevity or errors.
>>>>
>>>
>>>
>>> --
>>> Sent from mobile -- apologizes for brevity or errors.
>>>
>>
>>
>
>
> --
> [image: datastax_logo.png] <http://www.datastax.com/>
>
> DANI TRAPHAGEN
>
> Technical Enablement Lead | dani.traphagen@datastax.com
>
> [image: twitter.png] <https://twitter.com/dtrapezoid> [image:
> linkedin.png] <https://www.linkedin.com/pub/dani-traphagen/31/93b/b85>
> <https://github.com/dtrapezoid>
>
Re: Security labels
Posted by oleg yusim <ol...@gmail.com>.
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 <ol...@gmail.com> 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 <ja...@gmail.com>
> 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 <ol...@gmail.com> 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.traphagen@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 <ol...@gmail.com>
>>>> 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.traphagen@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 <
>>>>>> dani.traphagen@datastax.com> 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 <ol...@gmail.com> 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 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 <
>>>>>>>> jack.krupansky@gmail.com> 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 <ol...@gmail.com>
>>>>>>>>> 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 <
>>>>>>>>>> pmcfadin@gmail.com> 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 <olegyusim@gmail.com
>>>>>>>>>>> > wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Greetings,
>>>>>>>>>>>>
>>>>>>>>>>>> Does Cassandra support security label concept? If so, where can
>>>>>>>>>>>> I read on how it should be applied?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> Oleg
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Sent from mobile -- apologizes for brevity or errors.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sent from mobile -- apologizes for brevity or errors.
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> [image: datastax_logo.png] <http://www.datastax.com/>
>>>>
>>>> DANI TRAPHAGEN
>>>>
>>>> Technical Enablement Lead | dani.traphagen@datastax.com
>>>>
>>>> [image: twitter.png] <https://twitter.com/dtrapezoid> [image:
>>>> linkedin.png] <https://www.linkedin.com/pub/dani-traphagen/31/93b/b85>
>>>> <https://github.com/dtrapezoid>
>>>>
>>>
>>>
>>
>
Re: Security labels
Posted by oleg yusim <ol...@gmail.com>.
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 <ja...@gmail.com>
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 <ol...@gmail.com> 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.traphagen@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 <ol...@gmail.com>
>>> 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.traphagen@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 <
>>>>> dani.traphagen@datastax.com> 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 <ol...@gmail.com> 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 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 <
>>>>>>> jack.krupansky@gmail.com> 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 <ol...@gmail.com>
>>>>>>>> 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 <
>>>>>>>>> pmcfadin@gmail.com> 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 <ol...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Greetings,
>>>>>>>>>>>
>>>>>>>>>>> Does Cassandra support security label concept? If so, where can
>>>>>>>>>>> I read on how it should be applied?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> Oleg
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sent from mobile -- apologizes for brevity or errors.
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Sent from mobile -- apologizes for brevity or errors.
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> [image: datastax_logo.png] <http://www.datastax.com/>
>>>
>>> DANI TRAPHAGEN
>>>
>>> Technical Enablement Lead | dani.traphagen@datastax.com
>>>
>>> [image: twitter.png] <https://twitter.com/dtrapezoid> [image:
>>> linkedin.png] <https://www.linkedin.com/pub/dani-traphagen/31/93b/b85>
>>> <https://github.com/dtrapezoid>
>>>
>>
>>
>
Re: Security labels
Posted by Jack Krupansky <ja...@gmail.com>.
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 <ol...@gmail.com> 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.traphagen@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 <ol...@gmail.com> 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.traphagen@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 <
>>>> dani.traphagen@datastax.com> 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 <ol...@gmail.com> 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 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 <
>>>>>> jack.krupansky@gmail.com> 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 <ol...@gmail.com>
>>>>>>> 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 <
>>>>>>>> pmcfadin@gmail.com> 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 <ol...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Greetings,
>>>>>>>>>>
>>>>>>>>>> Does Cassandra support security label concept? If so, where can I
>>>>>>>>>> read on how it should be applied?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Oleg
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Sent from mobile -- apologizes for brevity or errors.
>>>>>
>>>>
>>>>
>>>> --
>>>> Sent from mobile -- apologizes for brevity or errors.
>>>>
>>>
>>>
>>
>>
>> --
>> [image: datastax_logo.png] <http://www.datastax.com/>
>>
>> DANI TRAPHAGEN
>>
>> Technical Enablement Lead | dani.traphagen@datastax.com
>>
>> [image: twitter.png] <https://twitter.com/dtrapezoid> [image:
>> linkedin.png] <https://www.linkedin.com/pub/dani-traphagen/31/93b/b85>
>> <https://github.com/dtrapezoid>
>>
>
>
Re: Security labels
Posted by oleg yusim <ol...@gmail.com>.
Thanks Dani.
Oleg
On Thu, Feb 11, 2016 at 2:27 PM, Dani Traphagen <dani.traphagen@datastax.com
> 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 <ol...@gmail.com> 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.traphagen@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 <ol...@gmail.com>
>>> 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.traphagen@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 <
>>>>> dani.traphagen@datastax.com> 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 <ol...@gmail.com> 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 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 <
>>>>>>> jack.krupansky@gmail.com> 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 <ol...@gmail.com>
>>>>>>>> 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 <
>>>>>>>>> pmcfadin@gmail.com> 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 <ol...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Greetings,
>>>>>>>>>>>
>>>>>>>>>>> Does Cassandra support security label concept? If so, where can
>>>>>>>>>>> I read on how it should be applied?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> Oleg
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sent from mobile -- apologizes for brevity or errors.
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Sent from mobile -- apologizes for brevity or errors.
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> [image: datastax_logo.png] <http://www.datastax.com/>
>>>
>>> DANI TRAPHAGEN
>>>
>>> Technical Enablement Lead | dani.traphagen@datastax.com
>>>
>>> [image: twitter.png] <https://twitter.com/dtrapezoid> [image:
>>> linkedin.png] <https://www.linkedin.com/pub/dani-traphagen/31/93b/b85>
>>> <https://github.com/dtrapezoid>
>>>
>>
>>
>
>
> --
> [image: datastax_logo.png] <http://www.datastax.com/>
>
> DANI TRAPHAGEN
>
> Technical Enablement Lead | dani.traphagen@datastax.com
>
> [image: twitter.png] <https://twitter.com/dtrapezoid> [image:
> linkedin.png] <https://www.linkedin.com/pub/dani-traphagen/31/93b/b85>
> <https://github.com/dtrapezoid>
>
Re: Security labels
Posted by Dani Traphagen <da...@datastax.com>.
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 <ol...@gmail.com> 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.traphagen@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 <ol...@gmail.com> 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.traphagen@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 <
>>>> dani.traphagen@datastax.com> 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 <ol...@gmail.com> 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 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 <
>>>>>> jack.krupansky@gmail.com> 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 <ol...@gmail.com>
>>>>>>> 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 <
>>>>>>>> pmcfadin@gmail.com> 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 <ol...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Greetings,
>>>>>>>>>>
>>>>>>>>>> Does Cassandra support security label concept? If so, where can I
>>>>>>>>>> read on how it should be applied?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Oleg
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Sent from mobile -- apologizes for brevity or errors.
>>>>>
>>>>
>>>>
>>>> --
>>>> Sent from mobile -- apologizes for brevity or errors.
>>>>
>>>
>>>
>>
>>
>> --
>> [image: datastax_logo.png] <http://www.datastax.com/>
>>
>> DANI TRAPHAGEN
>>
>> Technical Enablement Lead | dani.traphagen@datastax.com
>>
>> [image: twitter.png] <https://twitter.com/dtrapezoid> [image:
>> linkedin.png] <https://www.linkedin.com/pub/dani-traphagen/31/93b/b85>
>> <https://github.com/dtrapezoid>
>>
>
>
--
[image: datastax_logo.png] <http://www.datastax.com/>
DANI TRAPHAGEN
Technical Enablement Lead | dani.traphagen@datastax.com
[image: twitter.png] <https://twitter.com/dtrapezoid> [image: linkedin.png]
<https://www.linkedin.com/pub/dani-traphagen/31/93b/b85>
<https://github.com/dtrapezoid>