Thanks Dani! 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 <olegyu...@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.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 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 <olegyu...@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.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 <olegyu...@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 <pmcfa...@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 <olegyu...@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.trapha...@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> >
