For a PDF version, click here to download
1.1 REN-ISAC is a private community composed of trusted representatives of member institutions. The fundamental underpinning of REN-ISAC is shared trust among its members. Trust is critical to the activities conducted within the organization.
1.2 REN-ISAC membership is divided into two tiers: General and XSec. The tiers differ in the criteria for membership, the degree of trust assurance, and in the types of information and services that are shared within the tier.
1.3 An institution or organization is the REN-ISAC "member", and is represented by a "management representative" and one or more "member representatives". The individual member representative(s) are either General or XSec. An institution may have both XSec and General member representatives.
1.4 The management representative nominates individuals to become member representatives, and is responsible for timely maintenance of the institution's membership roster.
1.5 Member representatives participate in the sensitive information sharing. The Information Sharing Policy document describes what, how, and to whom, a member representative may redistribute information that was shared in REN-ISAC. Certain sensitive information cannot be redistributed under any circumstance. Rather, the member representative analyzes the information and formulates protection and response measures accordingly.
1.6 The management representative and member representatives must familiarize themselves with the following documents:1. this Membership document
2. REN-ISAC Information Sharing Policy
3. REN-ISAC Membership Terms and Conditions
4. REN-ISAC Charter
5. REN-ISAC Disclaimer
1.7 When an institution joins REN-ISAC, the management representative must explicitly agree to the Membership Terms and Conditions, and the Information Sharing Policy.
1.8 When a prospective member representative joins REN-ISAC, he or she must explicitly agree to the Information Sharing Policy.
1.9 A special class of participation, Referred Trust, provides for cases in which individuals who would not normally be eligible to participate as a member representative, to have formal relationship to REN-ISAC for specific and highly controlled purposes.
1.10 The identities of member institutions can be publicly disclosed. Name and contact information of individual member representatives is shared within the membership, but is not to be publicly disclosed, either by the REN-ISAC organization or by members, except by self-identification. Names and institutional associations of advisory group and analysis team members, and members of certain project teams can be publicly disclosed.
2.0 The benefits of membership
2.1 Receive and share practical defense information in a private trust community
2.2 Establish relationships with known and trusted peers
2.3 Have access to direct security services
2.4 Benefit from information sharing relationships in the broad security community
2.5 Benefit from vendor relationships, such as the REN-ISAC and Microsoft Security Cooperation Program relationship
2.6 Participate in technical educational security webinars
2.7 Participate in REN-ISAC meetings, workshops, & training
2.8 Have access to the 24x7 REN-ISAC Watch Desk
2.9 Have access to threat information resources ("data feeds") that can be used for IP address and DNS block lists, sensor signatures, identification of local compromised machines, etc.
3.0 The requirement for trust among members
3.1 REN-ISAC is a private trust community for sharing sensitive information regarding cybersecurity threat, incidents, response, and protection.
3.2 The private and trusted character of the community permits members to safely share information on such things as incident experiences, methods, sources, and infected systems -- without concern that the information draw unwanted attention to the institution or abet our adversaries.
3.3 Strong trust among members is required for a community in which members and external partners are willing to share sensitive security threat and experience information.
3.4 Individuals participating in the REN-ISAC community are required to accurately represent themselves, reliably act in the interests of their organizations and community, and earnestly abide the REN-ISAC Information Sharing Policy and Membership Terms and Conditions.
4.0 A tiered membership organization
4.1 Short of conducting costly background checks, trust can be established through personal knowledge. Scaling strong trust to a large community requires trust in a process rather than complete n-way personal relationships. Communities often rely on trusted member vouches for prospective members.
4.2 The two objectives, reach of service to the entire higher education and research community, and maintenance of a strong trust community, are difficult bedfellows. Scaling strong trust to a community of thousands of members encounters difficulties of process, organization, and cost. The process of vouching is ineffective for reaching institutions at which prospective members are not well known in the community.
4.3 In order to achieve the two objectives of reach and strong trust, REN-ISAC employs a tiered membership model. Two member classes, the basic trust General member and strong trust XSec member, differ in criteria for membership and in the types of information sharing and services the member may participate.
5.0 Benefits matrix for the General and XSec tiers:
|Receive information classified as:|
|Use of the mailing lists:|
|Use of other communication channels, e.g. IRC|
|Receive Information Products|
|Daily Watch Report|
|Threat Information Resources||limited|
|Use of direct services||limited|
|Participate in advisory groups and analysis teams|
|Participate in Special Interest Groups||limited|
|Sponsor Referred-Trust Associates|
6.0 Is an institution or an individual the "member"?
6.1 The institution is the member, and is eligible, through a management representative, to nominate one or more member representatives. The member representative must meet membership criteria, pass vetting requirements, and abide policies and trust requirements.
6.2 Information is shared to the member representative. The member representative participates in information sharing - the institution does not. Certain classes of shared information cannot be further disseminated within the institution. Rather, the member representative analyzes shared information and formulates protection and response actions for the institution. This important distinction places limits on the dissemination of information. Refer to Information Sharing Policy for details.
7.0 How is an institution represented in REN-ISAC?
7.1 An institution must have a management representative, and one or more member representatives. There are two classes of member representative: General and XSec. An institution can have any combination of General and XSec representation. The class of an individual member representative's participation is determined according to the capabilities, needs, and choice of the institution and individual, and by vouched trust.
7.2 Management representative:
7.2.1 As the steward of membership, the management representative is responsible for nominating member representatives (section 16.0), for the timely maintenance of membership changes, withdrawals, and terminations (section 10.0), and for all other administrative actions.
7.2.2 The management representative must be: (A) a CIO, vice president, associate VP, or chancellor, who has been verified by the Membership Committee; (B) a similarly verified CISO who reports directly to A; or (C) a Membership Committee-accepted delegate of A. The delegate must be a manager, with the security function in the subordinate reporting chain. Delegates are identified when A performs institutional registration.
7.2.3 The management representative can also be, but is not expected to be, a General or XSec member representative. Unless established as a member representative, the management representative does not participate in operational information sharing. The management representative should be a member representative only if it's appropriate for that individual to participate operationally.
7.2.4 The management representative receives quarterly reports on REN-ISAC activities, has access to a management representative mailing list, and is eligible to participate in management advisory groups and committees.
7.3 Member representative - General:
7.3.1 Referred to as "General member", these individuals represent their institutions in the information sharing and services community at a security classification of Privileged Use. The General class provides a level of participation in the community for those individuals whose job function doesn't require access to the additional XSec resources, or who don't meet XSec criteria.
7.4 Member representative - XSec:
7.4.1 Referred to as "XSec member", these individuals represent their institutions in the information sharing and services community at a security classification of Restricted Use (highest level). XSec membership provides access to additional sensitive data and information sources, and levels of participation in the community.
8.0 Membership criteria:
8.1 General and XSec:
8.1.1 The institution must be a college or university, teaching hospital, research and education network provider, or government-funded research organization.
8.1.2 The individual must be full-time permanent staff and have or share principal responsibility for security protection and response at the institution.
8.1.3 The individual must have institution or organization-wide responsibility, that is, the individual must represent security for the institution. Responsibility for a single campus of a multi-campus system is okay. Individuals with responsibility within a division, such as a department or school, don't qualify for membership unless by exception (section 8.4).
8.1.4 The individual must agree to abide the REN-ISAC Information Sharing Policy.
8.1.5 The individual's participation must conform to the frameworks established by the Charter, the Membership Terms and Conditions, and the Information Sharing Policy.
8.2.1 Prospective General member representatives must be accepted for membership by existing member representatives of the REN-ISAC trust community. Existing member representatives are not required to positively vouch, but are given the opportunity to express concern regarding the fitness or trustworthiness of the prospect. See Vouching, Dissent, and Reproach (section 9.0).
8.3.1 The prospective XSec member representative must be a General member representative in good standing, for a minimum of six weeks.
8.3.2 The prospective XSec member representative must receive two vouches from active XSec member representatives. One vouch must come from an external institution. A vouch must affirm that the prospect meets membership criteria, and importantly, must explicitly express personal trust in the individual. Guidance for proper vouching is provided in Vouching, Dissent, and Reproach (section 9.0).
8.3.3 The prospective XSec member representative must have responsibilities dedicated to operational security protection and response, or to a combination of networking and security with security responsibilities at minimum 50% assignment.
8.3.4 The prospective XSec member representative must have organizational responsibility to assess threat and incident, and to develop plans of action that have impact to the organization. The prospective XSec member representative must have the authority to independently carry out these responsibilities with nominal management oversight.
8.3.5 The institution must have the capability to actively defend against known threats, identify and remediate compromised machines, and must respond to compromised machines in a timely manner.
8.4.1 Requests for membership in which the institution, organization, or individual doesn't meet membership criteria are reviewed by the Membership Committee and REN-ISAC directors. For example, if an institution has no central IT security function, consideration for departmental memberships might be made on a case-by-case basis.
8.4.2 Ex officio memberships may be granted at the discretion of REN-ISAC directors for persons in relationship to the community, such as members of advisory groups or analysis teams, directors of sponsoring organizations, etc.
9.0 Vouching, Dissent, and Reproach
9.1.1 Vouches must be sent to mailing list on which the vouch request originated. Vouches sent privately to the Membership Committee or REN-ISAC staff are not accepted.
9.1.2 The reliability of a member's vouch for a prospective member is crucial to the trustworthiness of the REN-ISAC community. To vouch is not a trivial undertaking - it is an exercise of foundational principle for the community, and highlights how security comes down to individual decisions and actions.
9.1.3 There are two parts to a proper vouch: (1) an assertion that the individual meets the membership criteria, and (2) an expression of your personal trust in the individual.
9.1.4 Vouches must be independent sources of information, based on your own first-hand knowledge and personal experience with a candidate. Don't vouch for a candidate because someone you trust has recommended the individual to you.
9.1.5 When vouching, include as much relevant information as you can. A simple "vouch!" is insufficient. Include, at minimum, the following:1. How long you've known the person.2. How you know the person, specifically concerning work relationships (e.g. worked incidents together, work in other trusted communities), and how you've communicated (in-person, phone, e-mail).3. Confirmation of the applicant's position and responsibilities, if known.4. An explicit statement of trustworthiness - your personal trust in the individual.
9.1.6 Members are encouraged to ask questions about a candidate. Questions can be communicated to the mailing list, or privately to the Membership Committee.
9.2.1 Members are encouraged to express concern or dissent regarding the fitness or trustworthiness of a candidate. Although concern and dissent can be expressed on the mailing list, we encourage dissent to be expressed in confidence directly to the Membership Committee. The Committee will investigate all cases of dissent, and make recommendation regarding disposition.
9.3.1 In order to maintain a sound and trusted community, the membership must police itself. At any time, one member may call to question the fitness of another member, based on consideration of the membership criteria or trustworthiness. Challenges are encouraged by REN-ISAC management, and should be communicated in private to the Membership Committee.
10.0 Change, withdrawal, and termination
10.1 An individual's participation in REN-ISAC is directly linked to representation of the institutional membership, role at the institution, and trust of the community.
10.2 The management representative and individual member are responsible for timely communication to the Membership Committee regarding changes of employment or other changes in an individual's status that relate to membership eligibility.
10.3 In the event of institutional disciplinary suspension or termination, or other cause for doubt regarding an individual's trustworthiness, it's important -and required- for the management representative to immediately notify the REN-ISAC Membership Committee. If the management representative is unable to immediately notify, a peer member representative from the same institution should communicate to the Committee.
10.4 Emergency notification of member status change should be made by phoning the 24x7 REN-ISAC Watch Desk. Normal priority changes can be made by contacting the Membership Committee.
10.5 REN-ISAC reserves the right to unilaterally terminate the membership of an individual or institution without notice.
10.6 Actions of the Membership Committee will be reported to the member and management representative, and new status information will be reported to the membership.
10.7 The requirements for controlling the dissemination of received information, described in this document, survive the expiration or termination of membership.
11.0 Maintenance of the member roster
11.1 Management and member representative status will be confirmed on a periodic basis by the Membership Committee. Members are required to promptly respond to status inquiries.
11.2 REN-ISAC may at its discretion reissue vouch requests, either privately or to the membership mailing list, to confirm a member's standing.
12.0 Functional Accounts
12.1 Functional accounts can be created for automated access to the REN-ISAC data feeds. Functional accounts have only the assigned data feed permissions - that is, they have no other rights in REN-ISAC. When automated scripts are used to access REN-ISAC data feeds, we recommend the use of a functional account, rather than a personal credential.
12.2 Functional account credentials cannot be shared. If a member representative creates an account, it is for that member representative's use only.
12.3 Functional account credentials must be protected. If the credentials (or data downloaded using the account) will be exposed to additional persons (e.g. other root users on the same machine), those individuals must be REN-ISAC member representatives, or permissioned via the Data Feed Referred Trust.
13.0 Referred Trusts
13.1 General description
13.1.1 At times, it may be necessary for REN-ISAC to establish formal association with certain individuals at member institutions who are not eligible for REN-ISAC membership. Depending on the purpose of the association, it may be of a specific duration or standing. For example, a short-term association could be established with mail system administrators during the development phase of a project aimed at spam-fighting. A standing association might be established with DNS administrators who can sinkhole bad actor domain names. The participating individuals are called associates. Associates are organized under a structure called a Referred Trust. A unique Referred Trust is established for each uniquely-scoped purpose.
13.2 General Policies
13.2.1 A set of general policies guide all Referred Trusts, and each Trust will have additional unique policies that further describe behaviors and participation for that Trust.
13.2.2 Referred Trusts are defined and established by the REN-ISAC Technical Director. Associate participation is under the purview of the Membership Committee.
13.2.3 Referred-Trust Associates are not full REN-ISAC members, but have relationship to REN-ISAC exclusively for the purpose of the Referred-Trust. Associates do not have any other privileges or benefits of REN-ISAC membership.
13.2.4 The prospective associate must be a trusted individual who meets role-based, appointment, and other requirements noted in the particular Referred Trust definition. Appointments are subject to Membership Committee review.
13.2.5 At a change in tenure of the appointing individual, past appointments made by that individual must be confirmed by someone at the institution who meets the appointer criteria of the specific Referred Trust. A grace period of three weeks permits the appointments to continue unimpeded.
13.2.6 Appointments must be reconfirmed on a periodic basis, determined by REN-ISAC Technical Director.
13.2.7 In the event of any conflict between the Referred Trust General Policies, and the more specific policies unique to a particular Referred Trust, the latter is the policy in force.
13.3 Data Feed Referred-Trust
13.3.1 The Data Feed Referred Trust is a standing Referred Trust, with the purpose to provide data access to individuals at a member institution, who have specific role-based responsibilities, when those individuals would not normally be eligible to be a REN-ISAC membership representative.
13.3.2 REN-ISAC provides data feeds regarding active sources of threat. Member institutions can use the feeds to identify local compromised machines, and to block known threats. Access to, and use of the data is controlled by the Information Sharing Policy. At some organizations, the REN-ISAC member representative may not be in a position to apply the data, and the person(s) with that access may not be eligible for REN-ISAC membership. Or, use of the data by a REN-ISAC member representative might expose the data on machines that REN-ISAC-ineligible individuals have access to.
13.3.3 When it's not possible for an organization to address the underlying access issues, a management representative, can sponsor trusted persons to become Data Feed Referred-Trust Associates - permitting access to the data. In order to protect sensitive data, the number of persons designated should be kept to the minimum necessary to achieve operational protection.
13.3.4 In order to qualify for a Data Feed Referred Trust appointment, there must be a clearly defined operational protection and response requirement for the data, the use must involve protection for the entire institution or organization, and existing operational structures must dictate the data access by someone other than a REN-ISAC member representative.
13.3.5 The Data Feed Referred-Trust Associate:1. Must be nominated by a management representative at the involved institution.2. Must be a full-time, permanent staff member.3. Must have institution or organization-wide operational responsibilities. Responsibility for a single campus of a multi-campus system is okay. Individuals with responsibility within a division, such as a department or school, don't qualify.4. Must agree to abide the REN-ISAC Information Sharing Policy.5. Must conform to the frameworks established by the Charter, Membership Terms and Conditions, and the Information Sharing Policy.6. Must be accepted by existing REN-ISAC member representatives and the Membership Committee. Member representatives are not required to vouch for the prospective Associate, but are given opportunity to express concern regarding the fitness or trustworthiness of the prospect. See Vouching, Dissent, and Reproach (section 9.0). The Membership Committee holds final decision making authority.
14.0 Member information
14.1 The identities of member institutions can be publicly represented in REN-ISAC communications, such as papers, presentations, and marketing materials. Representation other than the fact of membership, such as endorsement or work within REN-ISAC, cannot be made without written permission from the management representative of that institution, except as noted in section 14.4
14.2 Contact and registration information for all institutions, member and management representatives, and referred-trust associates is made available to member and management representatives.
14.3 Contact and registration information, including the fact of membership, may not be disclosed outside the membership, either by REN-ISAC employees or its members, other than with the exclusive and case-by-case permission of the member, except as noted in section 14.4.
14.4 Name and institution of Advisory Group, Analysis Team, Membership Committee, and certain project team members may be publicly represented on REN-ISAC web pages and communicated in papers, publications, or marketing materials.
15.0 Membership Committee
15.1 A standing Membership Committee conducts all membership business. Details, and how to contact the Committee are on the Membership Committee web page.
16.0 Membership application and processing
16.1 The management representative and prospective member representative(s) must familiarize themselves with:1. this Membership document2. REN-ISAC Information Sharing Policy3. REN-ISAC Membership Terms and Conditions4. REN-ISAC Charter5. REN-ISAC Disclaimer
Questions can be directed to the Membership Committee.
16.2 Institutional first-time registrations, and all member representative nominations, are made by the management representative.
16.3 All new member representatives enter as General members. After six weeks, if appropriate, and as needed, a General member may request XSec privileges, by e-mailing the Membership Committee.
16.4 Member representative nominations are vetted by the full REN-ISAC membership, and the Membership Committee. The vetting period is a minimum of six business days, during which member representatives may express dissent or request additional information regarding the nominee (section 9.0 Vouching, Dissent, and Reproach).
16.5 XSec requests are vetted by the current XSec member representatives and Membership Committee. The vetting period is a minimum of six business days, during which member representatives may vouch, express dissent, or request additional information regarding the applicant. (section 9.0 Vouching, Dissent, and Reproach). The Membership Committee holds final decision making authority.
16.6 Member representatives who leave REN-ISAC and reenter when transitioning employment may carry forward time accrued toward XSec eligibility, as long as (1) prior employment was terminated in good standing, and (2) time away from REN-ISAC did not exceed six calendar weeks.
16.7 Suggestions on how to develop the individual and the institution, in order to qualify for XSec status, are provide in Appendix B.
16.8 Membership Application
Follow the above link to begin the member application process.
17.0 Technical Liaison
17.1.1 The Technical Liaison (TL) class provides for REN-ISAC participation of trusted persons who do not meet membership eligibility criteria but whose participation would bring substantial and continuing value to the broad REN-ISAC community. The TL class is not a path for member institutions to gain participation of general staff who don't meet membership eligibility criteria. Persons at member institutions are not excluded, however all TL candidates must meet the requirement to have specific expertise or capacities that widely benefit the REN-ISAC community.
1. The candidate may represent a private, commercial, or governmental organization or interest, from nations considered eligible for REN-ISAC membership.
2. The candidate must have specific expertise or capacities that widely benefit the REN-ISAC community.
3. There must not be a conflict of interest, as determined by the Membership Committee, concerning a candidate's occupation or avocation and the needs of a trusted information sharing community; for example, someone whose occupation is to publicly report incidents would likely not be eligible.
4. The candidate must pass admittance requirements as stated below.
17.3.1 A Technical Liaison must be nominated and sponsored by an XSec member in good standing. Nominations are submitted to the Membership Committee which deliberates along with the REN-ISAC Executive and Technical Directors.
17.3.2 The Committee may also consult with the Technical Advisory Group or Board at its choosing. A decision on the nomination is made by the Membership Committee, Executive Director, and Technical Director. A two-thirds majority vote is required to pursue, with each Committee member and Director holding a single vote. Active nominations are then submitted to the membership for trust vouching according to the standards required for General membership.
17.3.3 In submitting a nomination the XSec member must provide: a short description of the person's background and current roles, a description of value the community will derive from the Liaison, and a statement of personal trust in the person. Nominations may be made privately to the Membership Committee or openly (including the membership). If a nomination is made privately and is voted down notification of the results will be private. Private nominations that are voted up will be openly disclosed to the membership including identification of who made the nomination.
17.4 Maintenance of Status
17.4.1 The Technical Liaison must always have an XSec member sponsor. Obligations of the Sponsor are identified below. In the event of an unforeseen lapse in sponsorship the Membership Committee will temporarily serve.
17.4.2 The Membership Committee can, at any time without explanation, revoke a Technical Liaison. Members may request for the Membership Committee to review the status of a Technical Liaison or petition for revocation.
17.4.3 Technical Liaisons are reviewed by the Membership Committee at least annually and are subject to renewal or cancellation at each review. The review process looks for ongoing and consistent value in the relationship, changes in the status or position of the person, and feedback from the membership.
17.5 Obligations of the Technical Liaison
17.5.1 Technical Liaisons are expected to actively contribute to REN-ISAC.
17.5.2 Technical Liaisons must diligently abide the Information Sharing Policy and, unless modified by this document, the policies and guidelines for membership outlined in the Membership Guide and Terms and Conditions.
17.5.3 If the circumstances under which the Technical Liaison was admitted into REN-ISAC, such as title, job responsibilities, or events which may affect trust considerations change, the Technical Liaison is obligated to notify the Membership Committee. The Membership Committee will then re-evaluate eligibility.
17.5.4 Membership fees are waived for Technical Liaisons in view of the substantial and exceptional value brought to membership.
17.6 Rights and Limitations of the Technical Liaison
17.6.1 Technical Liaisons will have the full rights as REN-ISAC General Members, except for the following limitations:1. No access to bulk threat indicator data in SES (does have singleton query access, pending a SES role-based feature request)2. Eligibility to apply for XSec membership is determined by the Membership Committee3. May serve and participate only on technical committees, mailing lists, and other technical forums serving the membership4. No voting rights and not eligible to hold voting seats
17.7 Obligations of the Sponsor1. Nominate and vouch for the Technical Liaison; advocate for the nomination (see Admittance).2. Advocate for the annual renewal of the Technical Liaison; assist the Membership Committee as-required for renewal evaluation.3. Identify a replacement sponsor as-needed.
18.0 Appendix A - Membership Eligibility Examples
18.1 Brian is the lead systems administrator for institutional servers supporting the primary financial and student systems of the university. He is specifically tasked with security for the systems. Although he has explicit security responsibilities in his job description, he doesn't meet the requirement 8.1.3 to "represent security for the institution." Brian is not eligible for membership.
18.2 Melody is an IT support provider in the College of Arts and Sciences at the University, concentrating on security matters for the College. The University has a central IT organization including a central security team. Melody is not eligible because she doesn't meet the requirement 8.1.3 of having security duties of "institution or organization-wide responsibility"
18.3 Kyle is part of a three-person team handling security incidents for the University. The team is composed of students who rotate duty according to their class schedules. Kyle is not eligible for membership because he doesn't meet the requirement 8.1.2 for full-time permanent staff.
18.4 John is a network engineer in the central networking group. He's responsible for wired and wireless campus infrastructure, DHCP, DNS, he provides assistance to the security team for network taps, NetFlow data, and he maintains the campus firewall. John and the member institution would benefit from John having access to feed data as well as critical news about vulnerabilities in core services like recent DNS bugs. John actively participates in technical discussions about security but ultimately works at the direction of the security team to disable access to compromised systems, alter the firewall policy, or establish new sensor taps.
John is not eligible for membership, because he doesn't meet the requirement 8.1.2 to have a principal responsibility in security protection and response. Rather, he conducts tasks at the direction of the security team. However, the institution would benefit by sponsoring John as a Data Feed Referred-Trust Associate - so that he can employ specific REN-ISAC data feeds, in conjunction with NetFlow and DNS, to block active threats and identify infected systems. Additionally, the security team would be able to share DNS-related vulnerability information with John, as long as the information is classified privileged-use or below, and the sharing meets guidelines (see Information Sharing Policy, Sensitivity Classification).
18.5 Meryl is a senior network engineer in the NOC. Meryl spends 50% of her time working on security matters. Although the University has a separate IT Security Office, formal responsibility for security is split between the security and network offices. Meryl is tasked to work independently and in conjunction with the Security Office for network security matters. Meryl is eligible for membership because she shares principal responsibility for security protection and response.
18.6 MrX is the sole security engineer for a university. MrX meets all the role-based criteria for membership. MrX has been known to disclose confidences given him regarding incident experiences at other institutions. MrX should not be granted membership because he has demonstrated untrustworthiness.
19.0 Appendix B - On Becoming XSec
19.1 In order for an individual to gain XSec status, the individual must receive two vouches of personal trust from existing XSec member representatives - at least one from outside the member's own institution. Garnering the vouches is often difficult for persons who don't have strong peer relationships outside their institution. Personal networking and community engagement are key to developing the necessary relationships. Fertile areas for developing those relationships include:as an active REN-ISAC General member, communicating on the mailing list and IRC, participating in project groups, etc. inter-organizational incident handling at EDUCAUSE conferences, and security working groups at Internet2 conferences, and security working groups at state and regional security conferences and working groups at InfraGard meetings follow our Meet Us web page for details on our travels and events The relationship experience required for an XSec member to give a vouch of personal trust can't come from just a few hallway conversations at a conference. Persistent engagement in the community will develop the needed relationships.