Re: Security Updates

[kurt greaves]

Regarding security releases, nothing currently exists to notify users when
security related patches are released. At the moment I imagine
announcements would only be made in NEWS.txt or on the user mailing list...
but only if you're lucky.

On 31 January 2018 at 19:18, Michael Shuler  wrote:

> I should also mention the dev@ mailing list - this is where the [VOTE]
> emails are sent and you'd get an advanced heads up on upcoming releases,
> along with the release emails that are sent to both user@ and dev@. The
> dev@ traffic is generally lower than user@, so pretty easy to spot votes
> & releases.
>
> --
> Michael
>
> On 01/31/2018 01:12 PM, Michael Shuler wrote:
> > I usually install cron-apt for Ubuntu & Debian, forward and read root's
> > email to be notified of all system upgrades, including Cassandra.
> >
> > There are likely other utilities for other operating systems, or just a
> > cron script that checks for system update & emails would work, too.
> >
> > Also, it's possible to use something like urlwatch to look for changes
> > on http://cassandra.apache.org/download/ or any site, email out a
> > notification, etc. Maybe http://fetchrss.com/ or similar would work?
> >
> > I think there are a multitude of immediate ways to do this, until there
> > is a site patch submitted to JIRA for RSS addition.
> >
>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: user-h...@cassandra.apache.org
>
>

Re: Security Updates

[Michael Shuler]

I should also mention the dev@ mailing list - this is where the [VOTE]
emails are sent and you'd get an advanced heads up on upcoming releases,
along with the release emails that are sent to both user@ and dev@. The
dev@ traffic is generally lower than user@, so pretty easy to spot votes
& releases.

-- 
Michael

On 01/31/2018 01:12 PM, Michael Shuler wrote:
> I usually install cron-apt for Ubuntu & Debian, forward and read root's
> email to be notified of all system upgrades, including Cassandra.
> 
> There are likely other utilities for other operating systems, or just a
> cron script that checks for system update & emails would work, too.
> 
> Also, it's possible to use something like urlwatch to look for changes
> on http://cassandra.apache.org/download/ or any site, email out a
> notification, etc. Maybe http://fetchrss.com/ or similar would work?
> 
> I think there are a multitude of immediate ways to do this, until there
> is a site patch submitted to JIRA for RSS addition.
> 


-
To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
For additional commands, e-mail: user-h...@cassandra.apache.org

Re: Security Updates

[Michael Shuler]

I usually install cron-apt for Ubuntu & Debian, forward and read root's
email to be notified of all system upgrades, including Cassandra.

There are likely other utilities for other operating systems, or just a
cron script that checks for system update & emails would work, too.

Also, it's possible to use something like urlwatch to look for changes
on http://cassandra.apache.org/download/ or any site, email out a
notification, etc. Maybe http://fetchrss.com/ or similar would work?

I think there are a multitude of immediate ways to do this, until there
is a site patch submitted to JIRA for RSS addition.

-- 
Michael

On 01/31/2018 12:22 PM, Rob Oxspring wrote:
> Hi,
> 
> As a user of Cassandra I'd like to be able to get notified when there are 
> security releases so that I can get my installation patched ASAP. For feature 
> and patch releases I'm happy to come and look at the web page or trawl 
> through some mail archives, but I'd like for security releases to come and 
> find me.
> 
> Is there a dedicated mailing list for this?
> Or a dedicated list for just announcements without everyday chatter?
> An RSS / atom feed would work just as well.
> 
> Thanks,
> 
> Rob Oxspring
> 
> -
> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: user-h...@cassandra.apache.org
> 


-
To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
For additional commands, e-mail: user-h...@cassandra.apache.org

Re: Security assessment of Cassandra

[Jack Krupansky]

Just following up... Oleg, have you gotten a satisfactory level of feedback
from the community on the security assessment issues?

And if there is any sort of final assessment that can be publicly accessed,
that would be great.

-- Jack Krupansky

On Thu, Feb 11, 2016 at 3: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

[oleg yusim]

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 labels

[oleg yusim]

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

Re: Security assessment of Cassandra

[oleg yusim]

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

[oleg yusim]

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

Re: Security labels

[Dani Traphagen]

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
>>>
>>> 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 <
 dani.trapha...@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 

Re: Security labels

[oleg yusim]

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

 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 <
> dani.trapha...@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 

Re: Security labels

[Jack Krupansky]

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).
>>>
>>> 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 <
 dani.trapha...@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
> 

Re: Security labels

[oleg yusim]

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

 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 

Re: Security labels

[oleg yusim]

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: Security labels

[Jack Krupansky]

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: Security labels

[oleg yusim]

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

Re: Security labels

[Dani Traphagen]

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

>>>
>>
>
> --
> Sent from mobile -- apologizes for brevity or errors.
>


-- 
Sent from mobile -- apologizes for brevity or errors.

Re: Security labels

[oleg yusim]

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

Re: Security labels

[Dani Traphagen]

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

 

Re: Security labels

[Patrick McFadin]

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: Security labels

[oleg yusim]

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: Security?

[Hartzman, Leslie]

Thanks for the info.

So open-source Cassandra does not provide for auditing?

-Original Message-
From: Jeremy Hanna [mailto:jeremy.hanna1...@gmail.com] 
Sent: Thursday, September 05, 2013 9:47 AM
To: user@cassandra.apache.org
Subject: Re: Security?

For open-source Cassandra, there is a framework for security (see the security 
book-thing in the sidebar):
http://www.datastax.com/documentation/cassandra/1.2/webhelp/index.html

For those wanting additional things like auditing and other features, there's 
DataStax Enterprise: 
http://www.datastax.com/docs/datastax_enterprise3.1/security/index

Disclaimer - I work at DataStax, but hopefully the docs are helpful.

On 5 Sep 2013, at 17:36, Hartzman, Leslie leslie.d.hartz...@medtronic.com 
wrote:

 Does Cassandra have any security features to restrict access or does this 
 have to be done at the business tier?
  
 Thanks.
  
 Les
  
 [CONFIDENTIALITY AND PRIVACY NOTICE] Information transmitted by this email is 
 proprietary to Medtronic and is intended for use only by the individual or 
 entity to which it is addressed, and may contain information that is private, 
 privileged, confidential or exempt from disclosure under applicable law. If 
 you are not the intended recipient or it appears that this mail has been 
 forwarded to you without proper authority, you are notified that any use or 
 dissemination of this information in any manner is strictly prohibited. In 
 such cases, please delete this mail from your records. To view this notice in 
 other languages you can either select the following link or manually copy and 
 paste the link into the address bar of a web browser: 
 http://emaildisclaimer.medtronic.com
 

Re: Security?

[Jeremy Hanna]

For open-source Cassandra, there is a framework for security (see the security 
book-thing in the sidebar):
http://www.datastax.com/documentation/cassandra/1.2/webhelp/index.html

For those wanting additional things like auditing and other features, there's 
DataStax Enterprise: 
http://www.datastax.com/docs/datastax_enterprise3.1/security/index

Disclaimer - I work at DataStax, but hopefully the docs are helpful.

On 5 Sep 2013, at 17:36, Hartzman, Leslie leslie.d.hartz...@medtronic.com 
wrote:

 Does Cassandra have any security features to restrict access or does this 
 have to be done at the business tier?
  
 Thanks.
  
 Les
  
 [CONFIDENTIALITY AND PRIVACY NOTICE] Information transmitted by this email is 
 proprietary to Medtronic and is intended for use only by the individual or 
 entity to which it is addressed, and may contain information that is private, 
 privileged, confidential or exempt from disclosure under applicable law. If 
 you are not the intended recipient or it appears that this mail has been 
 forwarded to you without proper authority, you are notified that any use or 
 dissemination of this information in any manner is strictly prohibited. In 
 such cases, please delete this mail from your records. To view this notice in 
 other languages you can either select the following link or manually copy and 
 paste the link into the address bar of a web browser: 
 http://emaildisclaimer.medtronic.com
 

Re: Security?

[Jeremy Hanna]

Right so the auditing feature is one that is only in the DataStax Enterprise 
version.  This sub-topic in the DSE documentation describes what's in Apache 
Cassandra versus what's in DataStax Enterprise with respect to security: 
http://www.datastax.com/docs/datastax_enterprise3.1/security/security_features

On 5 Sep 2013, at 17:51, Hartzman, Leslie leslie.d.hartz...@medtronic.com 
wrote:

 Thanks for the info.
 
 So open-source Cassandra does not provide for auditing?
 
 -Original Message-
 From: Jeremy Hanna [mailto:jeremy.hanna1...@gmail.com] 
 Sent: Thursday, September 05, 2013 9:47 AM
 To: user@cassandra.apache.org
 Subject: Re: Security?
 
 For open-source Cassandra, there is a framework for security (see the 
 security book-thing in the sidebar):
 http://www.datastax.com/documentation/cassandra/1.2/webhelp/index.html
 
 For those wanting additional things like auditing and other features, there's 
 DataStax Enterprise: 
 http://www.datastax.com/docs/datastax_enterprise3.1/security/index
 
 Disclaimer - I work at DataStax, but hopefully the docs are helpful.
 
 On 5 Sep 2013, at 17:36, Hartzman, Leslie leslie.d.hartz...@medtronic.com 
 wrote:
 
 Does Cassandra have any security features to restrict access or does this 
 have to be done at the business tier?
 
 Thanks.
 
 Les
 
 [CONFIDENTIALITY AND PRIVACY NOTICE] Information transmitted by this email 
 is proprietary to Medtronic and is intended for use only by the individual 
 or entity to which it is addressed, and may contain information that is 
 private, privileged, confidential or exempt from disclosure under applicable 
 law. If you are not the intended recipient or it appears that this mail has 
 been forwarded to you without proper authority, you are notified that any 
 use or dissemination of this information in any manner is strictly 
 prohibited. In such cases, please delete this mail from your records. To 
 view this notice in other languages you can either select the following link 
 or manually copy and paste the link into the address bar of a web browser: 
 http://emaildisclaimer.medtronic.com
 
 
 
 

Re: security

[Brian O'Neill]

Not sure this is the standard approach, probably more what we came up
with. ;)

We plan to deploy Cassandra behind a firewall denying all traffic on all
ports other than 8080.  Access from applications will be limited to the
REST/HTTP layer, which we'll lock down with standard HTTP authentication
mechanisms. (using built-in apache or the servlet container)

Long term, we'll probably also introduce authorization/access control by
URL as well, whereby only certain users/apps will have access to certain
keyspaces and/or column families. (again... most likely using built-in
apache mechanisms, or the servlet container)

-brian


On Tue, Nov 8, 2011 at 6:30 PM, Guy Incognito dnd1...@gmail.com wrote:

 hi,

 is there a standard approach to securing cassandra eg within a corporate
 network?  at the moment in our dev environment, anybody with network
 connectivity to the cluster can connect to it and mess with it.  this would
 not be acceptable in prod.  do people generally write custom authenticators
 etc, or just put the cluster behind a firewall with the appropriate rules
 to limit access?




-- 
Brian ONeill
Lead Architect, Health Market Science (http://healthmarketscience.com)
mobile:215.588.6024
blog: http://weblogs.java.net/blog/boneill42/
blog: http://brianoneill.blogspot.com/

Re: security

[Sasha Dolgy]

Firewall with appropriate rules.

 On Tue, Nov 8, 2011 at 6:30 PM, Guy Incognito dnd1...@gmail.com wrote:

 hi,

 is there a standard approach to securing cassandra eg within a corporate
 network?  at the moment in our dev environment, anybody with network
 connectivity to the cluster can connect to it and mess with it.  this would
 not be acceptable in prod.  do people generally write custom authenticators
 etc, or just put the cluster behind a firewall with the appropriate rules to
 limit access?

Re: security

[Mohit Anchlia]

We lockdown ssh to root from any network. We also provide individual
logins including sysadmin and they go through LDAP authentication.
Anyone who does sudo su as root gets logged and alerted via trapsend.
We use firewalls and also have a separate vlan for datastore servers.
We then open only specific ports from our application servers to
datastore servers.

You should also look at Cassandra authentication as additional means
of securing your data.

On Wed, Nov 9, 2011 at 6:39 AM, Sasha Dolgy sdo...@gmail.com wrote:
 Firewall with appropriate rules.

 On Tue, Nov 8, 2011 at 6:30 PM, Guy Incognito dnd1...@gmail.com wrote:

 hi,

 is there a standard approach to securing cassandra eg within a corporate
 network?  at the moment in our dev environment, anybody with network
 connectivity to the cluster can connect to it and mess with it.  this would
 not be acceptable in prod.  do people generally write custom authenticators
 etc, or just put the cluster behind a firewall with the appropriate rules to
 limit access?

Re: security

[Guy Incognito]

ok, thx for the input!

On 09/11/2011 15:19, Mohit Anchlia wrote:

We lockdown ssh to root from any network. We also provide individual
logins including sysadmin and they go through LDAP authentication.
Anyone who does sudo su as root gets logged and alerted via trapsend.
We use firewalls and also have a separate vlan for datastore servers.
We then open only specific ports from our application servers to
datastore servers.

You should also look at Cassandra authentication as additional means
of securing your data.

On Wed, Nov 9, 2011 at 6:39 AM, Sasha Dolgysdo...@gmail.com  wrote:

Firewall with appropriate rules.


On Tue, Nov 8, 2011 at 6:30 PM, Guy Incognitodnd1...@gmail.com  wrote:

hi,

is there a standard approach to securing cassandra eg within a corporate
network?  at the moment in our dev environment, anybody with network
connectivity to the cluster can connect to it and mess with it.  this would
not be acceptable in prod.  do people generally write custom authenticators
etc, or just put the cluster behind a firewall with the appropriate rules to
limit access?