Item Comment summary
1
Encrypted data storage should be out of scope
2
3
4
5
6
7
8
“HoneyPot” systems by departmental admins should be prohibited.
Port mirroring/span ports/network taps by departmental admins should be prohibited.
Resource Custodian definition edit
Campus Application Software Security
Program funding and engagement
Core systems on mobile or wireless devices question
Campus provided 2-factor authentication question
Log correlation training and resources
Response
Defense-in-depth is required even for encrypted data.
Proposed out of scope clause not adopted. MSSEI change: remove “(except those listed as out of scope
below)” left over from earlier drafts [CISPC assigned action item to guideline development workgroup to address intended scenarios.]
Out of scope for MSSEI as not directly applicable to the management of covered data.
Out of scope for MSSEI as not directly applicable to the management of covered data.
MSSEI change: Role definitions will be changed from the text of IS-3 to the text from IS-2
MSSEI change: Details on SNS program will be linked to
MSSEI once they are made available
Core component (web, app, db servers, storage, authentication) not allowed on mobile/wireless.
Mobile/wireless clients OK.
2-factor authentication not required until campus solution available
Campus program provided
9
Missing SANS controls
10
Lack of specificity in controls
11
Value of controls compared to cost (2: software inventory)
12
Suggestion to provide OE services for each control
13
Request for examples of bulk access devices
14
Protected subnet interpretation
15
Encryption in transit requirements beyond wireless networks
Incremental improvement and prioritization defined scope of included controls
Resource Proprietor/department responsibility to define specifics, some campus programs provided, addl’ guidance forthcoming
[6/21/12 - CISPC upheld value of software inventory controls]
Some campus programs provided, addl’ guidance forthcoming
Computer used to read online reports or export spreadsheet reports of 500+ records (versus a device used for data entry of individual records).
[6/21/12 - CISPC instructed the guideline development workgroup to define controlled environments.]
15.1 requires that covered data moving through any network must use secure, authenticated, and industryaccepted encryption mechanisms

16
17
18
19
Credentials for accessing covered data included as covered data
Frequent uninstallation and reinstallation of software
Access to covered data through a network
Additional Training Requirement
[6/21/12 - CISPC decided to address credentials via the data classification process]
MSSEI change: Control 2.1’s example to be revised as:
“software required only for a short-term/^one-time^ solution…”
MSSEI change: Control 7.3 will be revised as
“Transmission of …”
MSSEI change: The reference to Office of the CIO training modules will be removed from control 8.
20
Non-NTP Network Time Synchronization MSSEI change: NTP-specific requirement will be
removed from Control 12.1.
21
MSSND Application Off-Campus MSSEI change: Control 17.1 will be revised to reinforce application off the campus network.
22
Enforcement of pre-purchase security review
[6/21/12 - CISPC instructed the guideline development workgroup to consider enforcement mechanisms.]
Item Comment summary
A
B
Definition of “campus data”[6/26 add: and “individually owned data”]
Classification of data types
C
D
Training
Institutional Data Council review
Response
Change: Add definition of campus data [and individually owned data]
Add requested definitions in guidelines [6/21/12: CISPC decided NOT to add the requested data types to the approved standard until data proprietors designated classifications.]
Training and communication resources will be developed
Erin Gore and Josh Blatt were given an overview
E
F
G
H
[6/26 add: Example of data protected by legal contract in PL1 and PL2]
[6/26 add: Opt Out Definition
Non-notice triggering but highly sensitive data in PL1
Non-repudiation best practices
[6/26: Change: Add examples to the Sample Data Type
Description section.]
[6/26: If a student has requested his or her directory information not be disclosed, this information should be treated as PL1 data.]
[6/26: High-impact/high-sensitivity data should be categorized as PL2 even if not notice-triggering. Lisa to contact commenter for specific examples.]
[6/26: Request to be handled outside the scope of
MSSEI and Data Classification.]
Comment: One commenter proposed that systems that only store strongly encrypted covered data should be out of scope.
Response: Reliance on a single administrative control (an encryption policy) to protect covered data violates the security principle of defense-in-depth. If an error (human or system) disrupted the encryption process,

the covered data would be left unprotected. The MSSEI control set is designed to provide multiple layers of protection while not imposing unreasonable burden to service providers beyond what is appropriate for managing the level of risk. The proposed scoping language was not adopted.
The following clarifying language from earlier drafts will be removed from the Scope and Background: Covered
Devices: Core System devices section: “(except those listed as out of scope below)”
Comment: One commenter proposed that departments should not be allowed to set up Honey Pot systems.
Response: Because the recommendation involves management of the campus network beyond the scope of covered data, the recommendations will be considered outside of the MSSEI context.
Comment: One commenter proposed that port mirroring/span ports/network taps should not be allowed by departmental admins.
Response: Because the comment involves management of the campus network beyond the scope of covered data, the recommendations will be considered outside of the MSSEI context.
Comment: One commenter proposed grammatical edits to the definition of the Resource Custodian role.
Response: For clarity and consistency role definitions will be changed to quote from the text of IS-2 rather than IS-3.
Comment: One commenter asked about funding, criteria, engagement process and cost for the "Campus
Application Software Security Program."
Response: The System and Network Security team has received funding to establish such a program.
(Proposal was reviewed at the March 2012 CISPC meeting .)
Details on program will be linked to MSSEI once they are made available.
Comment: One commenter requested clarification on 7.1 core systems on mobile or wireless devices, e.g., web browsing applications that run on mobile devices using the Berkeley mobile framework.
Response: Core system components as defined in the “Scope and Background: Covered Devices” section must not be implemented on mobile or wireless devices. i.e., “Database servers; application servers; web front-end servers; back-up and storage systems that store, process or transmit covered data; and any systems that provide authentication, authorization or configuration management for those systems. “ Mobile and wireless devices may be allowed to access covered data as clients if appropriate encryption is applied (as required by control 7.2 and 7.3).
Comment: One commenter asked whether a central 2-factor authentication service will be provided.
Response: The campus does not currently provide central 2-factor authentication services; for that reason, 2factor authentication is not required in this revision of the Minimum Standard. When campus 2-factor authentication services become available, the standard will be revised accordingly.
Comment: One commenter asked if campus would provide training and resources to assist with SIEM and log correlation tools and whether departments using IST services need to employ security analyst staff to evaluate logs.

Response: The System and Network Security team (SNS) is in the process of establishing a Security Event Audit
Logging Program. Campus units are encouraged to participate in this program to meet requirement 12.1. SNS will provide the staff to evaluate logs for all units participating in the campus program.
Comment: One commenter questioned why some SANS controls were not included.
Response: This MSSEI revision is intended to move the campus toward an industry-standard security posture in a way that is achievable within our campus environment. Because management of the campus network is fairly centralized, and the Networking group actively manages network security, implementation of controls specific to infrastructure services (e.g., DNS, NTP, Active Directory) and network infrastructure (e.g., switches/routers) were assigned a lower priority than others, and therefore were not included in this version of the standard.
Comment: One commenter felt the requirements (criteria, authorization and approval processes) lacked sufficient definition.
Response: MSSEI aligns with the UC Business Finance Bulletin IS-2 in placing responsibility for determining the level of risk and ensuring implementation of appropriate security controls to address that risk upon Resource
Proprietors, in consultation with Resource Custodians. MSSEI requires that departments/groups that runs systems with covered data define their own security plan, procedures and standards to implement the policy in a manner appropriate for their environment.
While the Resource Proprietor is ultimately responsible for managing the risk, in some cases, campuswide programs and services are available to help proprietors and custodians meet these obligations (e.g., participation in the System and Network Security provided campus vulnerability scanning program meets requirement 4.1). Additionally, following approval of MSSEI, a campus workgroup will be convened to draft implementation guidance.
Comment: One commenter questioned the value of a number of controls that will cost money, e.g., 2:
Managed Software Inventory for some installations performed with tar files and scripts that would require comparing every file on a server against a record.
Response:
Cost of implementation is an important factor to consider alongside the costs associated with a data breach.
Controls that would be most cost-effective if supported campuswide are candidates for campuswide program proposals. For managed software inventories, a number of packages exist that allow software inventory and integrity checks, including BigFix/TEM, tripwire, ossec.
Comment: One commenter suggested that OE services or standardization options should be provided to meet each control to encourage the adoption of centralized services, increase standardization across campus
(increasing depth and sharing of knowledge), and target OE priorities toward needed centralized services.
Response: Campuswide services are available for multiple controls (1: Annual Registration; 4.1, 4.2, 4.3:
Continuous Vulnerability Assessment and Remediation; 5: Malware Defenses; 6: Application Software
Security; 8: Security Training; 12: Audit Logging) and additional implementation guidelines will be developed for other controls.
Comment: One commenter requested specific examples of Bulk Access Devices.

Response: A bulk access device could be a desktop or laptop computer used to read online reports or export spreadsheet reports of 500 or more covered data records, such as SSNs (versus a device used for data entry of individual covered data records).
Comment: One commenter indicated that all of the new Webfarm hosts have network interfaces on the same
RFC 1918 subnet as their NetApp filer and asked whether control 11.2 could be interpreted to allow RDM applications on a Webfarm client, and whether RDM NAS clients could connect from other, publicly routed campus subnets (potentially using VLAN tagging)?
Response:
Comment: Once commenter indicated that there is currently no line encryption of data transmitted between the NetApp server and the Webfarm clients, prompting response from another commenter that the encryption in transit requirements of control 7.2 only covered confidentiality of data while in transit across wireless networks.
Response: Control 15.1 requires that covered data moving through any network must use secure, authenticated, and industry-accepted encryption mechanisms. A fiber-channel storage LUN with unencrypted covered data and a local disk with unencrypted covered data is acceptable on a core system device. CIFS from a fileserver to a web server without IPSec (or something similar) or NFSv3 or earlier from a fileserver to a web server is not a compliant method for transmitting unencrypted covered data on the network.
Comment: One commenter recommended that credentials that can be used to access notice-triggering data
(either to login to a system with them or to decrypt them on a system that isn't in scope) should also be covered data under MSSEI.
Response: Various controls in MSSEI are concerned with credentials that allow access to covered data. More explicit inclusion of credential in covered data may be considered in future revisions.
Comment: One commenter felt that the example given for 2.1 was not a good one because uninstalling and reinstalling software needed infrequently is risky -- it will often be better to turn it off than to un-install, reinstall frequently with the risk of misconfiguration associated.
Response: The example is not intended to promote frequent reinstallation of regularly used software
(indicated by use of the qualification “software required only for a short-term solution”). The example will be modified to read “software required only for a short-term/one-time solution…”
Comment: One commenter recommended revising 7.3: "Access to covered data through a network…" as
“Transmission of covered data on a network…”.
Response: The control will be revised as recommended.
Comment: One commenter recommended requiring additional appropriate training for sysadmin's, DBA's, programmers.
Response: The second sentence “The privacy and security learning modules provided by the Office of the CIO satisfy this training requirement.“ will be removed from this control.

Comment: One commenter recommended removing the NTP-specific requirement for network time synchronization.
Response: Control 12.1 will be revised to "All devices must use automatic time synchronization to ensure accurate time stamps for audit logs."
Comment: One commenter suggested adding, "as if they were on the campus network" to control 17.1.
Response: Control will be revised as: “Users, Resource Proprietors and Resource Custodians must ensure that all devices accessing covered data, regardless of their location, comply with the requirements defined in the
UC Berkeley Minimum Security Standard for Networked Devices as if they were on the campus network.
Comment: One commenter asked how pre-purchase review of application security requirements will be enforced.
Response: This is a valid question to be considered in policy implementation efforts and has been raised to IT management.
Comment: Two commenters recommended providing a clear definition of “Berkeley campus data” in the context of research data, and in contrast to individually-owned data.
Response: The following definition of “Berkeley Campus Data” will be added to the standard: “Berkeley
Campus Data is information prepared, owned, used, or retained by an operating unit or employee of the university relating to the activities or operations of the university. Berkeley Campus Data does not include individually-owned data, which is defined as an individual’s personal information that is not related to university business.”
Comment: Multiple commenters suggested classification of the following specific data types in the standard:
Applicant/Admissions data, intellectual property and copyrighted materials, research data sets protected by grant restrictions, business contracts, proposals, and pricing.
Response: Classification of the requested data types will be added to the standard. Applicant/Admissions:
PL1; IP, copyright, research: dependent on the data; business contracts, proposals, and pricing: _____. [CISPC decided NOT to add the requested data types to the approved standard until data proprietors designated classifications.]
Comment: One commenter asked whether training or a “roadshow” was planned.
Response: Yes, resources and communications will be developed to accompany roll-out of the standard.
Comment: One commenter asked whether the Institutional Data Council was consulted regarding the Data
Classification Standard.
Response: IDC leadership and staff were presented with an overview of the standard. The topic was slated for fall discussion.

[6/26:
Comment: One commenter asked for examples of “data protected by legal contract” in the PL1 and PL2 categories.
Response: Add the following examples to the Sample Data Type Description section: “PL1: Library resources, licensed software, software license keys, and related licensed documentation for which the campus pays for access, but for which use is limited to campus constituents. PL2: Data about human subject health information that is covered by a research grant that specifies required security protections.”]
[6/26:
Comment: One commenter asked for clarification regarding “opting-out” of the public directory.
Response: In accordance with FERPA regulation, Berkeley policy allows that designated directory information can be disclosed without prior student consent unless a student notifies UC Berkeley in writing or via an established electronic procedure that such information shall not be disclosed. If a student has designated that his or her directory information should not be disclosed, that data should be treated as Protection Level 1 information rather than Protection Level 0/general/public information.
[6/26:
Comment: One commenter noted that Protection Level 1 covers data that ranges from not-very sensitive to highly sensitive (while not notice triggering), and that it would be sensible to invest more in the protection of more sensitive data.
Response: The protection levels designate the level of sensitivity of data, therefore, data that is not noticetriggering but merits similar protection should be classified in Protection Level 2. Lisa to contact commenter for specific data examples.]
[6/26:
Comment: One commenter requested best practice recommendations for non-repudiation (per IS-2).
Response: Since non-repudiation is not addressed in MSSEI or the Data Classification Standard, the request will be handled outside of the MSSEI and Data Classification Standard review/approval process.]

Systems only storing encrypted covered data may be considered out of scope for MSSEI if, and only if, it has been validated that the system storing encrypted data does not have the means to decrypt that data. Industry best practices must be followed to put both physical and logical controls in place to ensure that complete access to the system by authorized users or by malicious users can not provide any access to any key capable of decrypting the data and that the data is strongly encrypted. Any vendor solution or technical implementation must be validated to verify that such controls are in place and working as intended.
If any system is excluded from scope for MSSEI by meeting the above requirements, then any key that allows decryption of that data is considered to be covered data, and any system that stores, transmits, accesses, or in any other way has the ability to compromise such a key is considered in scope for compliance with MSSEI.
What the proposal does not seem to address is the potential for abuse, mismanagement, information leaking, legal liability by departments wishing to duplicate at least two central campus security oversight mechanisms 1)The use of port mirroring/span ports/network taps to allow a departmental administrator to sniff traffic directly or with an IDS system with almost no audit trail 2)The provisioning of “HoneyPot” systems by departmental administrators.
1) The central campus network team should not allow any port mirroring/span ports/network taps to be used by departmental admins. This functionality should only be allowed by the central NS team for debugging and
SNS for security and IDS review. Only these teams have the proper peer review, ability to enforce background checks with the highest scrutiny, managerial oversight with appropriate subject matter expertise, and direct IT policy oversight and governance to insure the standards of university privacy and compliance are upheld.
This policy should also extend to virtual environments, because in some cases, certain network type raw capture could be implemented. The IST virtual environment does have sufficient peer review and oversight, and they commonly work with host IDS solutions, but to be consistent, any raw network capture involving multiple systems should be included. Most virtual hosts also have sufficient auditing, but uncontrolled, invasive technology with little auditing could be implemented if not checked. The IST virtual environment is controlled by oversight, and a simple policy can dictate they must allow SNS or other oversight if they feel a need to install one of the global virtual network IDS mechanisms for monitoring traffic. Departmental virtual installations should also be prevented from these types of network add-ons without SNS managing them.
Risks include: a)INSIDER HACKING: A departmental admin with this kind of access can sniff passwords and other security related data. I can testify that many network links are wrongly assumed safe in departmental data closets, and end-to-end encryption is not being used. Sometimes proxy devices, such as NLBs have been configured to offload SSL for sites using forms based authentication for example. Thousands of students, alumni, and prospective students may very well be sending passwords in the clear on “wrongly assumed safe” network links. Add the fact that most users probably use their yahoo email password when applying to business school for example and you understand this type of access extends beyond the university easily. Even CalnetIDs can be stolen because some departments do not understand proxy authentication and the risks, or comply with campus rules, and continue to use forms based authentication (e.g. .NET forms authentication to Active
Directory CalnetAD accounts) instead of CAS. That hole is hard to control with no real governance down to departments, and sometimes because of lack of vendor support, but you can easily stop the proliferation of

span ports and roll back any in existence at the department level. They do not provide any required function at the departmental level. Unlike other ways to exploit some of these holes, network monitoring has almost no conceivable audit trail of what an admin has logged into at a certain time or what information was read intentionally or unintentionally. Operating systems at least log when access logs have been tampered with, but some devices do not necessarily have this level of access auditing. Network level monitoring is much harder to oversee. b)PRIVACY LEAKS AND POTENTIAL FOR BLACKMAIL: All types of information that can be stolen or read, and often close interpersonal relationships exist at the departmental level creating an increased potential for conflict. NS and SNS have less chance for human nature problems to be introduced that could exploit this avenue because of the natural separation of work environments and personnel. The local aspect encourages intimidation and bullying by certain personalities, and that can result in costly hostile work environment suits.
Even the threat of using this technology can be as damaging to the university as using it. The UC community is also generally on the side of personal privacy over invasive initiatives like the Patriot Act. This is much worse than even that, because of the much more personal element of coworker relationships, and much less oversight and peer review. c)PUBLIC EMBARASSMENT AND PHYSICAL DAMAGE: The insider hacking could not only be used to read information, but it could actually be used to stage sabotage or impersonation attacks against the university once credentials are stolen with almost no audit trail, many of these credentials would be valid long after a departmental admin left employment.
2)The central campus should not allow departments to bring up HoneyPot systems, systems essentially used to entice hackers to exploit them. a)CRIMINAL INVESTIGATIONS: Obviously, there are criminal ramifications, and perhaps resulting Privacy, Civil or FERPA issues when setting up something that can in some cases be perceived as entrapment for serious criminal offences. The use of such a system in a university environment should only be handled by the central
SNS team with central campus policy oversight to insure legal and privacy issues are addressed with any implementation as well as appropriate support from UCPD since perhaps 25-50% of serious offenses may be students or other UC constituents. b)PUBLIC EMBARRASSMENT: You risk public embarrassment and other legal issues if a departmental admin proclaims him or herself constable for inside or outside hacking concerns. Any hacking or suspected hacking should be dealt with by SNS where they have IT policymakers, non-departmental IT professionals, and departmental managers on working groups to provide policy input and oversight as well as sufficient peer review. You open the risk for admins to take upon themselves to perform reverse hacking, or other inappropriate criminal investigation outside their area. They may also interfere with an existing SNS investigation of criminal actions.
With both items 1) and 2) any exceptions to the approved central campus implementations of IDS(from spanning/mirroring/taps) or other central campus network security programs should be managed only by SNS.
For any network segment that for some reason is deemed not sufficiently protected by the current central campus systems, then only SNS managed satellite feeders should be allowed. The information captured and the risks from possible scenarios are too great to leave this at the departmental level. Anything short of that allows for too many holes to the policies:

1)Position Blending: A departmental manager decides to blend an existing position into network security without abiding by university rules concerning job definition, duplication of effort, appropriate scrutiny of background checks, or other potentials of abuse. You must stop the use of this technology, to control this less tangible aspect.
2)Rights Escalation: A departmental admin could perhaps escalate rights to gain access to any network tapping systems, but more common, is the unchecked privileged sharing of UserX gives UserY an account without supervisor or campus approval, or UserX simply reveals a shared password where another admin can gain access. Network Devices and IDS or NLBs are especially prone to the use of shared admin credentials by their architecture. Again, you must stop the access in advance.
3)Device Change: You may allow an IDS system today, but when this type of access exists, anyone with data closet access can simply plug in a laptop at almost any time to completely capture data unaudited by campus oversight and then plug the IDS back in.
It is also gross duplication of effort from an OE perspective to allow expensive IDS systems to be purchased and installed or FTE time expended when these would serve the greater good if funding were used for campus wide systems. Perhaps, a recharge system for SNS managed satellite network IDS or Honeypots, if deemed required, could be established for departments and achieve greater economy of scale.
Under term, 'Resource Proprietor' instead of "The individual designated responsibility for the information and the processes supporting a specific University function." please consider re-wording such as "The individual designated as responsible for the information and the processes supporting a specific University function."
Have we been funded for a "Campus Application Software Security Program"? What are its security criteria?
How would a department engage the team's services? What would it cost?
In 7.1 it would help to clarify "Resource Custodian must not implement core systems on mobile or wireless devices". Does "implement" include "building web browsing applications that run on mobile devices using the
Berkeley mobile framework" for example?
In 10, is campus going to provide a central service similar to CAS that would support 2-factor authentication?
In 12.1 is campus going to provide training and resources to assist with "Industry-standard Security
Information and Event Management (SIEM) and log correlation tools are used to analyze audit logs on all core system devices"? We have our applications running in the IST data Center, on IST-managed databases. Does this mean our own department does not have to have "At least one full-time staff with explicit security analyst duties is responsible for daily log evaluation" but that IST must?
Issue 1: Why did they only use 16 of the SANS 20 list? We should be following the full 20 item list. Item 19 should not have been skipped (i.e. “Critical Control 19: Secure Network Engineering”).

Issue 2: The general format of the “Related Standards” section of the document provides a list of fluffy “Threat
Scenarios” and yet lacks any definition for the things that need to be done. Many references to checking against lists on a regular basis, but no information about who will create and maintain these lists of things against which things should be checked.
Issue 3: References to firewalls and management thereof reference “and established approval process based on clear criteria”. Lovely idea, but when will that become available. Current practice is “someone asks for something to be opened, open it up”. Generally some thought is applied to the process by the firewall manager, but since there is no clear approval process and no clear criteria in writing anywhere, it is really being left to best-personal-judgment as the “established approval process”.
All of the items in the “Related Standards” section share the same general weaknesses:
-References to needing things to be better defined without actually defining anything or indicating where the information will be made available
-Assigning responsibility for tasks without clearly defining the tasks. Reading the SANS links provided with most of the Standards provides some clarity. However, the document should clearly state that the SANS 20 list should be referenced when the local document fails to provide the required information (assuming that the
SANS 20 list is intended to be used that way with this document).
I would have liked to see some recommendations on how the Standards will be implemented, what new organizations or committees will be formed to manage and maintain it. Who will create the procedures and the lists of criteria referenced in them and so on.
I didn’t see anything that can’t be done, but a number of the things will cost money and time and probably won’t yield that much value.
As an example of what I mean, let¹s take Item 2: Managed Software Inventory.
Not difficult to track things that are installed by the System Administrators using the default package installation software for the OS.
However, I¹m not aware of any way to find things that were dropped onto a server via a “tar xf *” command.
Even some installations of Oracle are essentially done with tar and a few scripts and leave no OS-friendly indication that they are installed. So, to keep track of installed software, it becomes necessary to write or buy things that look at every file on a server and record what they find somewhere.
And, as with most requirements, it mentions criteria, in this case “authorization to use the software” but does not define how that authorization is established.
Most of the standards would benefit from the existence of some kind of standardized lists of criteria or descriptions of procedures related to the decision making that they imply needs to be done.
To improve the current document, I recommend aligning it with the OE initiative. By that I mean, for each control there should be an OE provided service that meets the goal. For example, Managed Software

Inventory would have a link to the IST managed Microsoft System Center Configuration Manager environment... so on and so forth. If there is not a centralized service, include a list of options to standardize on. So if Microsoft System Center Configuration Manager wasn't currently being provided, a link to OCS would be included ( http://www.ocsinventory-ng.org/ ). This will not only encourage the adoption of centralized services it will also informally standardize the software used here on campus. Should anyone run into an issue with their own deployment, they would be able to post the message to Micronet since others would be running the same software.
The final perk with this method is that it will shed light on areas where OE should provide centralized services.
"Bulk Access devices: Any device used with credentials that have access to 500 or more covered data records in bulk transactions or any device that stores 500 or more covered data records."
- Can you give a specific example of this?
- including a specific example in the document would be great.
I thought DCAT’s analysis of the controls in the draft MSSEI, as communicated by Karen Kato (6/18/12 07:43), was helpful in clarifying some issues the policy presents for IST storage and backup services. As Karen noted for Control 9.1, the policy seems intentionally non-prescriptive in many areas to allow as much flexibility as possible in implementation. At the same time, systems currently in development will benefit from our understanding of whether proposed features can be comfortably accommodated within policy requirements going forward. I think an example might be helpful, to illustrate.
The Unix team recently completed a replatform of the Webfarm application to Linux VM and NetApp NAS. In recognition of the concern the Network Operations and Services group has to limit high-volume data transfers through hardware firewalls, all of the new Webfarm hosts have network interfaces on the same RFC 1918 subnet as their NetApp filer. There is currently no line encryption of data transmitted between the NetApp server and the Webfarm clients (per Control 7.3), and there may be cases where customers want to operate
RDM applications on a Webfarm client. Can Control 11.2 be interpreted to allow sufficient latitude for this deployment, without a perpetual exception? The example could be extended to include the desire to support
RDM NAS clients connecting from other, publicly routed campus subnets (potentially using VLAN tagging). It seems less likely that this would be permitted under Control 11. One possible solution is to provide line encryption in these cases by implementing a “local area” VPN between the NetApp filers and campus clients, but this implies a potentially costly expansion of NOS ASA facilities.
---
It's important to note the difference between access control and confidentiality of data. The presence or absence of firewalls would not change the situation you are describing. The firewalls provide a mechanism for preventing unauthorized access to the hosts and other resources involved. Even if there were firewalls, there would still be the question of transmitting RDM data in the clear.
7.2 refers to wireless access - so basically it says don't put RDM data over AirBears (unencrypted over the air). Note that encryption of wifi does not imply that the data is still encrypted when it leaves the wireless portion of the network (it often is not).

To my reading, an RFC1918 subnet in the data center that only has the web farm hosts and their storage infrastructure connected to it does indeed meet 11.2. However again 11.2 really addresses access security, not confidentiality of data in transit.
I don't actually see anything in the MSSEI v2 that covers confidentiality of data while in transit across the network other than the above mentioned section on mobile/wireless access. I certainly don't see anything that mandates encryption of that data, but I may be missing something?
I believe that in addition to notice-triggering data MSSEI should also apply explicitly to credentials that can be used to access notice-triggering date (either to login to a system with them or to decrypt them on a system that isn't in scope).
2.1 I don't believe that the example is a good one. Uninstalling and reinstalling software needed infrequently is risky -- it will often be better to turn it off than to un-install, re-install frequently with the risk of misconfiguration associated.
7.3 "Access to covered data through a network" is not clear to me. Any transmission of covered data on a network?
8.1 I would recommend now or soon requiring some additional appropriate training for sysadmin's, DBA's, programmers
12.1 Does having domain members sync their time using Microsoft's domain protocols to domain controllers that use ntp comply with "All devices must use Network Time Protocols (NTP) to ensure accurate time synchronization."? (If not then I suggest a re-write to drop the ntp explicit reference and allow any automatic time syncronization designed to maintain syncronization to a small fraction of a second.)
17.1 Add "as if they were on the campus network" to make clear that this is adding something new (one interpretation I've heard is that this requirement doesn't add anything new -- it says you have to follow
MSSND, and MSSND only applies to devices on the campus network, so this item doesn't add any requirements to devices not on the campus network).
6.3 commercial software purchases must meet CASSP-like review before purchase. How can we enforce this?
“Under Scope there is the phrase 'Berkeley campus data'. This probably needs clarifying for research data, since the data may be shared with other campuses or commercial organizations, and may or may not originate with Berkeley.
It is an accepted practice, I believe, to handle data at the same or tighter controls than the originator specifies.
On that basis I think the phrase 'Berkeley campus data' needs to cover data used or stored on the Berkeley campus (which is a term of affiliation, not geography), even if it does not originate from the Berkeley campus.
Otherwise I see a chance of the policy being interpreted as not applying to certain data.”

“I think they need to be much more explicit on defining "Berkeley campus data" vs "Individually-owned data". I assume that what they mean by "Individually-owned data" is something like if I put a copy of my personal tax return on my work computer or work file share with my own personal info and has nothing to do with my work at Berkeley.
However, without clarification some people may interpret that erroneously to mean any file (or email) they personally create on their computer is their individually-owned data, e.g., if in the course of my university work I create my own spreadsheet that contains student info that the student's give me directly over the phone.”
[6/26/12 add: "Individually-owned data is out of scope."
- we assumed it was employee/faculty/student personal data, incidentally stored on UCB data storage resources.]
“It would be helpful to explicitly list Applicant/Admissions data on the Data Classification Standard. For example, we store transcripts, test scores, recommendation letters, and reviews/evaluations of graduate applicants. We understand that this data is not subject to FERPA, but it nonetheless might fall into Protection
Level 1. On the other hand, if it is Protection Level 0, it would be helpful to have this stated explicitly in the standard.”
“Here are a few examples that might also be worth including:
* intellectual property and copyrighted materials
* research data sets protected by grant restrictions
* business contracts, proposals, pricing, etc”
Training or a roadshow?
Has the institutional data council been notified/consulted with?
[6/26:
"Data protected by legal contract (depending on terms of contract)" an example or two would be great, especially since this spans L1-2.]
[6/26:
For L1 data for "all records for students who have opted-out of being included in the public directory" - what does "opting out" of the internal directory mean in this context? I know you can choose to show or hide information in the calnet directory, but does that impact / override decisions made for other applications somehow? I also am aware that some students are highly confidential, and don't show up in many systems
(children of royalty, etc.) - is that the level of opt-out here?]
[6/26: On: https://security.berkeley.edu/matching-data-with-it-services
L1 - Moderate - "in development"
- Are you interested in our feedback on the "Confidentiality Protection Profile" of L1 data? Are you working on that now, or is that a "next step"?

in brief- We felt that the breadth of L1 data was in a spectrum of not-very sensitive to highly sensitive (while not notice triggering) and we thought it would be sensible to invest more time in protection of more sensitive data.
On: http://www.ucop.edu/ucophome/policies/bfb/is2.pdf
"Non-repudiation ... " - do we have best practices for non-repudiation?