cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From oleg yusim <olegyu...@gmail.com>
Subject Re: Security labels
Date Fri, 29 Jan 2016 23:30:07 GMT
Thanks Dani!

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

Mime
View raw message