IT Policy Committee (ITPC)

The purpose of the Information Technology Policy Committee (ITPC), established in 2018, is to oversee the process of researching, creating, and updating IT policy and standards at Penn. The ITPC advises the CIO concerning decisions about new policies, policy revisions, and variance requests. ITPC members include representatives from across the University's Schools and Centers and staff from Information Security and ISC.

 

IT Policy Committee (ITPC) Policies
Process for the Creation, Review, and Enactment of Policies

Each policy should go through a number of steps before it can be presented formally to the ITPC and then to other committees on campus. The following process lists what is required to get a policy discussion started, and if/where a proposed policy's status is at each step along the way to approval. Anyone is invited to participate in authoring a policy, however, the proposed policy will be put into a queue and given the appropriate priority setting by the ITPC if any members are required to be a primary author. The ITPC authorizes the status of each policy.

Step 1: Identification

Any member of the University community may identify an issue for which policy discussion may be warranted. While we expect that this most often will be a provider of service within a School or Center or within ISC, we see no reason why the identification step couldn't happen from within the user community.

  1. Compose a summary and purpose of the proposed policy and email this summary to the ITPC at network-policy@isc.upenn.edu. Include the policy author(s) and if any assistance is required by IT members.
  2. The ITPC will review the proposal for feasibility. The review may involve further explanation via email, or possibly the requester's attendance at the next ITPC meeting.
  3. The ITPC will decide if the proposal gets on the next successive meeting's agenda.
  4. The proposal will either be granted or denied at the next successive ITPC meeting or 30 days after submission to the ITPC.
  5. If the policy is feasible ITPC will set the appropriate priority level and schedule this new policy into the draft queue.

Step 2: Draft Policy

Once a policy issue is identified, a draft policy should be generated. The person who originally identified the need could write a policy draft or could invite participation from other interested parties. These draft policy sponsors are responsible for writing up a thorough treatment of the issue and a proposed policy for review by the IT Policy Committee. Note that blank policy templates can be found at:

https://www.isc.upenn.edu/ITPC/template

The policy status now becomes proposed and is posted up on the ITPC website as Scheduled for Review by the ITPC.

Step 3: Discussion at ITPC meeting

The proposed policy is presented for review to the ITPC at which time a more detailed presentation and discussion of the policy will take place. The policy may pass on unchanged to the next step, it may continue with modifications, or it may be thrown out if it is considered not worthy of further consideration. If the policy continues with modifications, then it will be on the ITPC meeting agenda until it goes to the next step or it gets thrown out.

The policy is posted up on the ITPC website as a Draft Policy. The status remains proposed until such time that the ITPC approves to the next step.

Step 4: Review Period

Those draft policies that make it to this step would be published on the web as a draft policy for public review for a period of 30 days. Announcements would be made to distribution lists most directly impacted by the policy topic (e.g., SUG, MacNet, PCNet). Any member of the University would be able to comment on the proposal during the review period. Policy comments can be reviewed in their entirety at http://www.net.isc.upenn.edu/policy/archive-list.html

The ITPC and the draft sponsors would be responsible for taking this input forward to the next step or taking this back to the previous step.

During the review period, the following tasks should take place:

  1. The policy author and/or interested parties should agree on who should answer the email comments.
  2. All feedback via email should be answered within 3 business days.
  3. All comments and feedback are reviewed in detail at the following ITPC Meeting.
  4. The ITPC will decide if the feedback results in a significant change to the policy and if the policy should be reworked, posted for another 30-day review, moved onto the next step, or thrown out.

The policy status now becomes under review and is posted up on the ITPC website as being in a 30 Day Review Period.

Step 5: Final Policy Draft

At the end of the review period, the ITPC decides whether to take the proposal forward to a final form or to throw it out. If the policy is to be taken forward, specific changes may be agreed upon by the ITPC and before allowing the policy to move to the final stage.

The policy status remains under review and is posted up on the ITPC website as being a Draft Policy until such time that it can be presented to other committees.

Step 6: Policy Approval

The policy is recommended for approval by the ITPC and enactment and is presented to IT Roundtable. IT Roundtable either recommends the policy be forwarded to the Vice Provost for ISC and/or the Provost, or it rejects the policy. Once the policy is approved at this level, it gets an official policy number and date and is published in final form on the web and perhaps the Almanac.

The policy status now becomes approved and is posted up on the ITPC website as being an Approved and Enacted Policy.

If the policy is not approved, then it can be returned to any step of this process or it may be thrown out entirely.

Conclusion

This process can be viewed as a cycle, as any policy may be revisited and returned to step 1 as needed. Policies that are thrown out or obsolete will be archived at the ITPC website and given the status of rejected or obsolete. Existing policies that are brought back into the process will be given the appropriate status as listed above in each step.

IT Policy Development Process

Approved and Enacted Policies
Policies Under Review

IT Security Policy

6.2.2.7 Interactive Authentication

6.2.2.7.1  Devices and services that use passwords for authentication
must be protected by strong passwords or passphrases as specified in the
Password Complexity Standard so that they are resistant to modern-day
attacks.

6.2.2.7.2  Devices and services that access "High" risk data as
specified in Penn's Data Risk Classification must use strong
authentication as specified in the Strong Authentication Standard.

6.2.2.7.3  Passwords for devices and services must be encrypted in
transit and in storage.

6.2.2.7.4  Wherever possible, use PennKey for user authentication,
detailed in the Web Application section of this policy. In cases where
it is not, passwords must be cryptographically hashed and salted, in
concordance with industry standards.

6.2.2.8 Non-interactive Authentication

6.2.2.8.1 Secrets used for non-interactive authentication (e.g. API
credentials, SSH private key, client key, or password) for any service
managed by a Penn staff member or their designee must be handled as follows:

     6.2.2.8.1.1 All secrets must be encrypted in transit.

     6.2.2.8.1.2 Unencrypted secrets must not be hard coded into the
source code of the application or stored in the application source code
repository, unless the application handles only Low-Risk Data (e.g.
Content Management Systems that store a database password in plain-text
in a configuration file).

     6.2.2.8.1.3 All application integration points must require
authentication using a Strong Password [link to standards], client
certificate, SSH public key, Kerberos principal, or equivalently strong
method (consulting with OIS for any assistance assessing the strength of
a different method). This includes but is not limited to database
connections, RESTful and SOAP web services, and SSH/SFTP calls to a
platform.

     6.2.2.8.1.4 Secrets must be encrypted at rest wherever possible
(e.g . within the Centralized Identity and Access Management System
[link to definitions] designated for the application’s runtime
environment). Otherwise, they must be appropriately secured on the file
system per the platform security standards.

Centralized Identity and Access Management System:
a system where a single environment manages both the principals (e.g.
users, computing resources) as well as the subjects (e.g. services and
data they access), so that authentication secrets are not handled
directly by users, developers, or system administrators. Examples may
include, but are not limited to, AWS IAM Roles, Microsoft Entra Workload
ID, and GCP Workload Identity.

Retired Policies
Variance Requests

To request a variance to IT policy, please contact the ITPC representative from your School or Center.  If your School or Center does not have a representative on ITPC, or if you have any questions about the variance process or ITPC, please contact  IT-POLICY-ADM@lists.upenn.edu.

Two Factor Variance Risk Mitigation

Using multi-factor authentication (MFA) to secure your O365 account is highly recommended. However, if you cannot use MFA for some reason, there are still several mitigating controls you can implement to secure your account. Here are some options:

  1. Strong Password Policy: Ensure that you have a strong password that is unique and difficult to guess. Consider using a password manager to generate and store complex passwords.
  2. Conditional Access: Use conditional access policies to restrict access to your O365 account based on location, device, and other factors. This will help prevent unauthorized access to your account.
  3. Limited Access: Limit access to your O365 account to only the necessary users and roles. This will help reduce the risk of a compromise.
  4. Audit Logging: Enable audit logging to monitor activity on your O365 account. This will help you detect and respond to suspicious activity.
  5. Regular Security Awareness Training: Regularly educate yourself and your team on the latest security threats and best practices for protecting your O365 account.

It is important to note that while these mitigating controls can help reduce the risk of a compromise, they are not foolproof. Therefore, enabling MFA as soon as possible is recommended to further secure your O365 account.

Back to ISC Computing Policies

https://www.isc.upenn.edu/computing-policies