[Owasp-leaders] My expectation is that nobody is reading my @owasp.org emails

Timur 'x' Khrotko (owasp) timur at owasp.org
Tue Jul 1 17:00:43 UTC 2014


* If documents eq google drive documents then withdraw rights for an active
user is difficult, or maybe I am underinformed. An admin can takeover the
ownership of documents owned by the now unprivileged user, this allows for
full management of those. But this does not solve the problem of the access
of that user to the documents, those remain in place. There is no generic
method to withdraw the access to sensitive documents unless you strictly
maintain folder structure with sharing set on the root/subroot folders,
comply with such conventions is not realistic imo, there always will be
some exceptions. Probably there is a tool to search for documents
accessible by specific users, that may solve this problem easily. Probably
there is a solution based on suborganizations. I can take the task of
researching this matter if no one here knows the solution.

Of course it would be better to draft the overall target. Probably the
lightest definition can be that we (someone and maybe me) invest some time
to prepare an overview on possible implementation of access control at
OWASP google apps facility with respect to the common situations, including
the case of users getting unprivileged.

* Yes Samantha is an exception, I believe. The policy must be simple, but
there always must be some air for exceptions, in my subjective approach. We
are a community here, not a corporation, so we have to solve our conflicts
with high respect to everyone who significantly contributed to the
community, especially if that figure played such a visible role in the
current history of the community, like it or not. I would approach this
case much more from some soft social angle than from the
formalistic/pragmatic corporate logic.

*OWASP *chapter leader - Hungary
+36-309225777; skype: live:timurx; timur at owasp.org

On Tue, Jul 1, 2014 at 5:59 PM, Josh Sokol <josh.sokol at owasp.org> wrote:

> Timur,
> That's a good point.  Forwarding mail from a proxy account, as Achim
> suggested, still does not solve the issue of access to sensitive documents
> still being in the hands of an ex-employee.  It sounds like, with some
> effort, the groups functionality may be the right solution here.  If
> someone would like to volunteer to take that ball to Sarah and jointly run
> with it, I'm in full support.  To me, this clearly falls out of the scope
> of the OWASP Board and into the scope of our ED and Operations Team.
> Regarding specifically what Dennis requested with respect to Samantha's @
> owasp.org e-mail account, policies indicates that these e-mail accounts
> are a privilege for OWASP members
> <https://www.owasp.org/index.php/Individual_Member>, leaders
> <https://www.owasp.org/index.php/Chapter_Handbook/Chapter_4:_Chapter_Administration#Owasp.org_Email_Accounts>,
> and staff.  Samantha is not a member
> <https://docs.google.com/a/owasp.org/spreadsheet/ccc?key=0Ag5ZloRZ0SmjdEhnSDBEVVd0cVctb3d6c1RFUkJOeXc&hl=en#gid=1>,
> she does not currently lead a project, chapter, or other OWASP initiative,
> and she resigned as a member of our staff.  Are we suggesting that we
> should make Samantha an exception to our policies?  I am personally open to
> this, given her past service to our community, but we should be clear that
> this is not a right, but rather, something nice that we'd do to honor her
> contributions.  And, of course, it would be pending a volunteer effort to
> address the access control issues that were previously identified.
> ~josh
> On Tue, Jul 1, 2014 at 10:35 AM, Timur 'x' Khrotko (owasp) <
> timur at owasp.org> wrote:
>> As far as I know, there is no support/feature in Gapps for proxy email
>> addresses or technical users.
>> a) You can create normal users, treat them as technical on your logical
>> level, switch off all other services than email. But you apparently won't
>> be able to reroute their mail to another @owasp.org account, so reading
>> their mail will be client side headache ever. And of course there are all
>> the risks of phantom/logical user accounts.
>> b) You can associate the technical user/label as alias with one specific
>> account. (That user can create a rule to forward all mail addressed to that
>> alias to other users, if needed.) In this case owasp will not be able to
>> accumulate the mail addressed to that technical address separately. User
>> will be able to send mail on behalf of the alias.
>> c) You can create technical users as groups, and manage their membership.
>> Even with single member in a group this solution is the less hackish and
>> the most straight manageable. (Though the initial setup of such group is
>> 10+ minutes of configuration and review.)
>> d) There may be a feature or a gapps app that solves all this properly.
>> In our company we use the 'c' method for technical accounts (eg.
>> santa at cloudbreaker.co)).
>> PS1: We use the 'c' method for forwarding our ex-colleagues mail as well
>> (after a few months or a year of their leaving).
>> PS2: I also propose to resolve the case of Samantha's @owasp.org email
>> address the same way, by routing her email to her private address. Ok, it
>> is not a solution for the problem, but some sort of reinstitution of
>> courtesy.
>> PSS. Dinis, on your original question, whether or not it is technically
>> possible to read your mail without you noticing it. Yes. In the Gapps admin
>> console admins can set up email routing (read forking) for any account
>> individually. Just tested it on myself.)) (the target address can not be
>> google's or gapps.)
>> PSSS: Gapps have full featured groups (aka mailing lists) facility, we
>> may consider to use it instead of the mailman server, probably, at some
>> future point.
>> On Tue, Jul 1, 2014 at 4:34 PM, Josh Sokol <josh.sokol at owasp.org> wrote:
>>> Sounds perfectly reasonable to me.  Can someone take the task of working
>>> with Sarah to come up with those e-mail addresses and update any references
>>> that point to individuals rather than the proxy e-mail address?  The staff
>>> could certainly use some volunteer assistance to make this happen.
>>> ~josh
>>> On Tue, Jul 1, 2014 at 9:18 AM, Achim <achim at owasp.org> wrote:
>>>> Am 01.07.2014 15:44, schrieb Josh Sokol:
>>>> > To say that OWASP's Human Resources processes are immature is an
>>>> > understatement.  But, to Eoin's point, HR is not the responsibility
>>>> of the
>>>> > Board of Directors, but rather, the Executive Director and the
>>>> Operations
>>>> > Team.  As with most things at OWASP, as a volunteer, if you see a
>>>> problem
>>>> > with the way things are done and have ideas for improvement, you are
>>>> > welcome to put forth a plan to fix it.
>>>> Ok, you want a plan:
>>>> First I'd highly appreciate if we setup a list of e-mail addresses for
>>>> technical use, like contact at owasp.org, project-staff at owasp.org, and
>>>> many more.
>>>> Then assign these to the apropriate persons. Then there's hopefully no
>>>> longer
>>>> the need to disable/bann someone's e-mail adress from OWASP.
>>>> This makes things easy:
>>>>   * the technical e-mail address can remain on all websites
>>>>   * if the human behind that address changes, for whatever reason, just
>>>> the
>>>>     assignment to the technical e-mail address needs to be chanched
>>>>   * post the list of these addresses at owasp.org
>>>> Does this sound reasonable?
>>>> Achim
>>> _______________________________________________
>>> OWASP-Leaders mailing list
>>> OWASP-Leaders at lists.owasp.org
>>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>> Email us to enforce secure link with your mail servers (domain).
>> This message may contain confidential information - you should handle it
>> accordingly.
>> Ez a levél bizalmas információt tartalmazhat, és ekként kezelendő.

Email us to enforce secure link with your mail servers (domain).
This message may contain confidential information - you should handle it 
Ez a levél bizalmas információt tartalmazhat, és ekként kezelendő.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20140701/827613e1/attachment-0001.html>

More information about the OWASP-Leaders mailing list