[Owasp-leaders] email SOPs when employees are leaving OWASP
Timur 'x' Khrotko (owasp)
timur at owasp.org
Wed Jul 2 20:33:19 UTC 2014
(let me dwell on the topic for one more lap)
We have at least 2 bodies: OWASP community and OWASP Foundation. The latter
may be extended to the notion of OWASP Corp. Well you may find labeling the
charity this way inappropriate, but during our recent conversations here I
found it typical that most of my fellow members refer to the best practice
from their corporate experience as readily applicable to the functioning of
OWASP. And obviously the functioning of OWASP Foundation is similar to
corporate: The operation of the Foundation is by default closed, while as
community we operate by open/public discussions (like this public mailing
list). Foundation is a legal body which is to comply with regulations,
Foundation has contracts, budget and employees. Etc. (Our Board exists in
the both worlds, in some situations as part of the closed regulated
operation, and most times as part of the normal member ecosystem, as Tobias
My basic approach to the enterprise security is that on the organizational
level of security management significant things (principals, processes,
roles, resources, etc.) has to be named (labeled) in meaningful manner.
When one principal belongs to OWASP Foundation/Corp it means she represents
her role thereof and hence authority and responsibility -- then let's make
it visible. It should not be implicit knowledge do I communicate with my
fellow community member or with the
The question of access/authorization is pretty much related to the
semantics of the principals' identification also. In general
(automatically) sensitive documents of the Foundation shall belong to the
domain of the Foundation and be connected with Identificators thereof.
Mixing domain of the Foundation with that of community results in
confusion, and maybe security and compliance problems.
So my proposal is to establish the corp.owasp.org domain and redefine the
identificators of those who belong there. And transfer all sensitive
*john.malkovich at corp.owasp.org <john.malkovich at corp.owasp.org>*
PS: I am convinced by Tobias, that board members use their community domain
id-s. However I am not convinced with the concept that board members
communicate with their special status only when explicitly assigned to that
particular action to represent the Board (again a third body in our
organizational structure btw). Board members actively participate in the
functioning of the corp.owasp.org, and are guided by the rules of that
organization when they behave in that context. For example they has to
comply with the general rule of keeping information in that closed circle.
It is situational wisdom for us to interpret messages and opinions of board
members as coming from their boardish context or independant individual.
I may made mistakes in my judgement due to being rather outsider, sorry for
On Wed, Jul 2, 2014 at 2:33 AM, Timur 'x' Khrotko (owasp) <timur at owasp.org>
> 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
>>> and staff. 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. 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
>> 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ő.
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...
More information about the OWASP-Leaders