[Owasp-leaders] email SOPs when employees are leaving OWASP

Timur 'x' Khrotko (owasp) timur at owasp.org
Wed Jul 2 00:33:10 UTC 2014


Ok, Tobias, I am convinced that distinguishing board members by this
tagging in the email id was a wrong idea.

Probably distinguishing between owasp community members and the staff this
way can still make sense. Consider tagging staff members by addresses like
samantha.groves at staff.owasp.org. It is easy to manage suborganizations like
'staff' within our Google Apps domain. If she (anyone) remains community
member, she can have/keep the @owasp.org email. On her exit from the staff
the staff account is suspended/deleted, thus blocking access to documents
is easily manged. In case a member becomes hired worker at the Foundation
(Samantha returns :), she receives the staff account (again).

Of course if the case of an employee becoming member of the community and
continue their participation in the community after leaving the staff is
not a significant case, than the ugly tagging like
john.malkovich.exemployee at owasp.org is still an option.
 On Jul 1, 2014 10:12 PM, "Tobias" <tobias.gondrom at owasp.org> wrote:

>  Hm, I don't think a special board member email account is necessary and
> really like to be clear on one point because it seems to be a common
> misconception for some people:
> Board members as individuals have _*no*_ special authority or powers.
>
> Only the board as a whole group has authority over our organisation.
> I think it is very important to really keep that fact in mind. Individual
> board members need to be seen and treated as any normal active member of
> our community. And in fact I would not want people to use email addresses
> with the word "board" in them as that might give others the false
> impression that an individual board member would have any special authority
> or be talking on behalf of the board. (Only under rare circumstances would
> this happen when one board member is effectively communicating the result
> of a vote taken by the board.)
>
> Therefore, I think separate emails for board members are not required and
> could in fact be misleading, communicating a false sense of authority.
>
> Also it is important to remember that the role of board member does not
> have any operational powers or duties, like our staff have.  So e.g. when
> people want to launch a project, have chapter questions, etc., our staff is
> in charge.
>
> Board members can help with information about finding the right contact
> person or help with advise on how OWASP works, or we can propose things to
> the board for consideration or vote. All these things are more based on
> knowledge, not on any special powers or authority of the individual. And
> that is pretty much it.
>
> So if you send an email to a board member you should see this as sending
> an email to any other OWASP leader with deep knowledge of our current
> community. Compared to when you are sending an email to a staff member, you
> expect certain operational things to happen.
>
> Small note: please note, that the board in our current restructuring may
> assign responsibilities to members of the community like in the form of the
> committees and leaders of the community (incl. board members) and also may
> appoint an temporary ED when Sarah our current ED will be leaving. In this
> case it is important to recognise that these responsibilities may be
> assigned to a person (incl. to a board member) by the board, but are only
> by assignment and not due to the mere aspect that a person is on the board.
> (With one exception, as following our bylaws, the chairman of the board
> does have some executive powers due to his role.)
>
> Best wishes, Tobias
>
>
>
>
>
> On 01/07/14 18:59, Timur 'x' Khrotko (owasp) wrote:
>
> Then probably the privileged accounts are to be signified as such:
> tobias.gondrom at board.owasp.org
>
> Gapps provides so called suborganizations. You will then have two
> accounts, one as OWASP member and one for your director role. Setting this
> up as alias in your Gmail client is easy. Sensitive documents will be
> shared with your director account then.
>
> Semantics is important in security, isn't it ,)
> On Jul 1, 2014 7:00 PM, "Tobias" <tobias.gondrom at owasp.org> wrote:
>
>>
>> On 01/07/14 16:59, Josh Sokol wrote:
>>
>>
>>  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.
>>
>>
>> Honestly, I don't see the point.
>>
>> To remove email access and set an auto-responder is common best practice
>> in most companies. And in this case it was definitely necessary to avoid
>> getting project leaders email requests being lost, delayed, not acted on or
>> misdirected and maintain confidentiality of data. And btw. this best
>> practice is common, irrespective of what great deeds an employee has done
>> for the organisation during their tenure.
>>
>> Samantha is not a member. She does not currently lead a project, chapter,
>> or other OWASP initiative, and she resigned as a member of our staff.
>> Therefore I do not see why she should be supplied with an OWASP email
>> address?
>>
>> Maybe the reason for Dennis to request such exception could be because
>> Samantha is his wife.
>> But IMHO nepotism is not a good reason for an organisation to grant
>> exceptions. And I am very much against that.
>>
>>
>>
>> On a technical solution basis, I definitely agree that we should look
>> into moving to a more role based approach (aka e.g.
>> "project-manager at owasp.org" <project-manager at owasp.org>) and possibly
>> combine that with groups. Please note that our ops team has already made
>> efforts in this direction by establishing the "Contact Us" form (which is
>> linked with a ticketing system) as the primary interface.
>>
>> Having said that, for the time being until we figured out all
>> mis-communication and data confidentiality questions, the default solution
>> should be following standard best practices:
>> 1. at end of employment remove email and system access and set an
>> ex-employees email to auto-respond.
>> 2. if the ex-employee is also a member or wants to become a new member,
>> we can provide a new email account with a slightly different name. (yes,
>> that is slightly inconvenient for the ex-employee, however necessary to
>> ensure that no requests or confidential data are being misdirected to
>> him/her email account under the false assumption that the person would
>> still be working for OWASP.)
>>
>> Best regards, Tobias
>>
>>
>>
>> _______________________________________________
>> 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 
accordingly.
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/20140702/44e70732/attachment.html>


More information about the OWASP-Leaders mailing list