IT Policy at LBL, Berkeley Lab

Blogging is hard.

noreply@blogger.com (IT Policy) — Tue, 08 Jul 2008 15:47:00 +0000

My new FY resolution is more consistent blogging.
In the meantime, by way of an update, I am working on:
1. Access without consent policy and procedure
2. Rewrite of 1.01 and 5.0X of the RPM.
3. Campus Calnet/Cal1 integration issues
4. FY09 PEMP Contract Measure Negotiations
5. PII Training

Denial of Service

noreply@blogger.com (IT Policy) — Fri, 23 May 2008 00:56:00 +0000

The largest and most sophisticated denial of service attack I am aware of occupied the National Laboratories yesterday. Would you care to guess who did it?

Live from the NSF Large Facilities Conference

noreply@blogger.com (IT Policy) — Wed, 07 May 2008 17:28:00 +0000

I'm in DC for the NSF Large Facilities Security conference. Excellent keynotes this morning (if a little depressing) and an enjoyable roundtable going on now. More on these a bit later, but in the meantime, here is the entirety of the NSF regulation on cyber security:

54.
Information Security
Security for all information technology (IT) systems employed in the performance of this award, including equipment and information, is the awardee’s responsibility. Within a time mutually agreed upon by the awardee and the cognizant NSF Program Officer, the awardee shall provide a written Summary of the policies, procedures, and practices employed by the awardee’s organization as part of the organization’s IT security program, in place or planned, to protect research and education activities in support of the award.
The Summary shall describe the information security program appropriate for the project including, but not limited to: roles and responsibilities, risk assessment, technical safeguards, administrative safeguards, physical safeguards, policies and procedures, awareness and training, and notification procedures in the event of a cyber-security breach. The Summary shall include the institution’s evaluation criteria that will measure the successful implementation of the IT Security Program.
In addition, the Summary shall address appropriate security measures
required of all subawardees, subcontractors, researchers and others who will have access to the systems employed in support of this award.
The Summary will be the basis of a dialog which NSF will have with the awardee, directly or through community meetings. Discussions will address a number of topics, such as, but not limited to, evolving security concerns and concomitant cyber-security policy and procedures within the government and at awardees' institutions, available education and training activities in cyber-security, and coordination activities among NSF awardees.

Why can't DOE have this?

Random Bits

noreply@blogger.com (IT Policy) — Sat, 26 Apr 2008 19:21:00 +0000

Upcoming:
Co-facilitating with Aaron from PSC the "Building an Effective Security Program" breakout at the NSF Large Facilities conference. It's nice that the topic is so clearly defined and narrow (!).

At NLIT 2008, something about federated identity management - but I haven't exactly figured out what yet.

Speaking of NLIT, we have way too many things that begin with NL now, most of them unpronounceable. NLDC, NLCC, NLCIO, NLIT, NLCRO, NLCOO.. they need to take some lessons from DOD on pronounceable (and badass) acronyms.

Random Bits:
I really enjoyed the discussion here about blocking outbound SMTP. When you get halfway through the UC people really come out in force against the trend towards locking things down in a research setting. Mother May I is not a good game to play with researchers, unless you can make it extraordinarily transparent and simple.

Finally, all of our colleagues in both R&E and .gov are struggling with what to do about new rounds of highly targeted phishing. It isn't clear to me where this ends. You can train people to avoid paypal phishing, but this new stuff isn't nearly so straightforward. And as we found the last time we really stepped up awareness on this issue, making people overly fearful of email doesn't exactly do the institution any favors either. As in all things security, it's a delicate balance - but the risk is clearly shifting again.

NIST it by that much redux.

noreply@blogger.com (IT Policy) — Fri, 22 Feb 2008 16:49:00 +0000

Steve Lau and my talk at Internet2, NIST It By That Much, is looking more perceptive by the day. The Department of Energy Office of the CIO has released hundreds of page of new draft policy which, in my opinion, misunderstands NIST in precisely the way we described: it fails to recognize that the NIST documents create a baseline of controls from which you as the system owner are supposed to tailor your set of controls, NIST 800-53 is a baseline, not a set of minimum security standards for all systems.

The critical step in the NIST C&A process is "Tailoring the Baseline". This is where NIST moves from a set of well founded but ultimately arbitrary checklists, to something of value. When you tailor the baseline you start with the prescribed NIST baseline, then use scoping guidance, compensating controls, and parameterization to created an initial tailored baseline. These three activities allow you to customize the set of controls for your environment. With that tailored baseline in mind, you assess the remaining residual risk. If that risk is unacceptable, you go back to tailoring the baseline again.

The new DOE CIO Policies attempt to turn 800-53 into a set of Minimum Security Standards across the Department of Energy. The problem is that 800-53 is not a set of Minimum Standards, it's a catalog of controls from which you adopt the ones that are right for your system and its level of risk. Unfortunately, the concept of a tailored baseline doesn't exist in these new documents.

More on tailoring:

A hundred small conservative decisions, and the impact on science.

noreply@blogger.com (IT Policy) — Thu, 17 Jan 2008 21:53:00 +0000

Yesterday, I played a bit with some lightweight coding (which is neither my job nor my expertise). I was quite unsuccessful in getting my little project to work, but about half way through I realized that while I might be able to get the program to work, my code was certainly not going to be secure. I realized that even if I got it working, I wouldn't put it on an LBL server because of the off chance that it might be hacked.

You may think this is a morality tale about the importance of thinking about security, but in fact, it's almost the reverse. The truth is that my insecure code would have posed a very limited risk to the Lab, and if it had been exploited (unlikely) it would have done almost no damage to turn it off and clean it up. Yet, because of the attention to security, the perceptual risk is far greater then the real one.

Every day, a few thousand scientists - those the organization selects for their ability to ask new questions in new ways and to develop new tools to ask those questions - are faced with this same issue. And every day, perhaps a few small decisions are made to be conservative and not attempt to create the tool, try the new thing, or play with something interesting because of these kinds of worries. The losses from this behavior are unknown to us, they may be imperceptible, or they may be substantial. What we know is that the great research institutions in history have valued an atmosphere of open expression and freedom to explore the new, the unproven, and the risky.

Will the next World Wide Web or Cyclotron go unbuilt because a researcher feared what might happen if they didn't implement it securely?

First Quarter Preliminary Reportcards

noreply@blogger.com (IT Policy) — Thu, 17 Jan 2008 21:43:00 +0000

We are now publishing our quarterly scorecards for the UC/DOE Contract for both IT and Cyber-Security. You can find the first quarter reports under the Assurance section.

Current policy projects include: revisiting non-consensual access, improving our assurance-crosswalk, and updating 9.02.

Current audit-management projects include the Internal Audit of data centers (ongoing), and continued response to both the draft IG Websites audit (see blog post) and related impacts from the previously published IG IT Hardware Audit (which we vehemently disagree with).

Current DOE policy projects include RevCom for the newly released 200.1A.

Current Contract-Management task: negotiation around the incorporation of the DOE Privacy Reporting directive, which we believe is duplicative with State Law (SB1386) and in conflict with other prime contract clauses.

Current Process Improvement Goals: Business Continuity Planning

Winter Reading List

noreply@blogger.com (IT Policy) — Wed, 19 Dec 2007 14:59:00 +0000

After some recent discussions with a colleague, I was prompted to compose the following:

Required Reading List for Those Working at LBL
(best for those in operations and management, but useful for all).

Number 1
Objective: Gain an understanding of the core governance problems between the National Laboratories and the Department of Energy
Reading: Galvin Report
Focus On: Governance issues, oversight issues, Directives.
Location: http://www.lbl.gov/LBL-PID/Galvin-Report/Galvin-Report.html

Number 2
Objective: Gain an appreciation for the history of LBL vis a vis DOE / Manhattan Project / etc.
Reading: Brotherhood of the Bomb
Focus On: Historical administration, relationship between DOE precursors and National Labs, Development of Military Industrial Science Complex
Location: Library

Number 3
Objective: Understand LBL Position on Management Challenges and Improvement Opportunities Between DOE and M&O Contractors
Reading: LBL/DOE Best Practices Study
Focus On: Alternative Governance Models, NCAR
Location: http://www.lbl.gov/Workplace/Ops/assets/docs/best_practices.pdf

Number 4
Objective: Understand How Organizational Responses to Regulation and Oversight in National Laboratories Impact Compliance and Assurance
Reading: Regulatory Ecology: Strategy, Compliance, and Assurance in Complex Organizations
Focus On: Motivation of Internal Regulator Proxies, Communication Challenges
Location: Forthcoming (my dissertation).

Audit of the Department's Websites

noreply@blogger.com (IT Policy) — Thu, 13 Dec 2007 21:17:00 +0000

The OIG has a draft out of their Audit of the Department's websites. Unfortunately, the cover letter asks that the draft not be shared. However, our response to the draft report can be shared (or in this case summarized).

LBL requires that all systems, whether they are workstations, servers, devices, microscopes, PDAs, or webservers, be managed in an appropriate, secure manner which integrates security into the lifecycle.

This approach is consistent with the philosophy that line management owns security - we want to push responsibility for appropriate configuration to the person responsible for using and managing the machine. This approach is also consistent with how most large research Universities manage websites (many servers, run at the Department or project level).

It is not consistent with the view that consolidation is always superior to decentralization.

This is a test.

noreply@blogger.com (IT Policy) — Tue, 11 Dec 2007 20:07:00 +0000

This is a test of some new monitoring ideas we have been working on. XXX Viagra
We now return you to your regularly scheduled blog and apologize for the spammy words.

UC Trust

noreply@blogger.com (IT Policy) — Tue, 04 Dec 2007 04:11:00 +0000

UC Trust is an identity federation for the University of California, based on InCommon. Since it is becoming more a part of UCOP's central services plans, this post is really designed to be a googleable thing for people in Ops (or elsewhere) who might need to know who to contact. Answer: cppm

Reminder: Credit Card Numbers Are Account Numbers (and thus not permitted in non-business systems).

noreply@blogger.com (IT Policy) — Wed, 28 Nov 2007 18:34:00 +0000

A quick reminder that credit card numbers are protected PII at LBNL. This means that credit card numbers, and devices which collect them, are only permitted in the web-facing Institutional Business Systems. You may not attach a credit card terminal to any LBNL network, nor collect credit card numbers of LBNL workstations or servers (except those managed as part of the Business Systems). More info: http://www.lbl.gov/CIO/Privacy/

Impact of HIPAA on US Medical / Public Health Research

noreply@blogger.com (IT Policy) — Sun, 18 Nov 2007 20:22:00 +0000

Interesting article in Science this week reporting on a study in JAMA on the impact of the HIPAA Privacy Rule on Epidemiological researchers:

About 68% said the Privacy Rule has made research a great deal more difficult; half reported major delays; and nearly 40% faced much higher costs (see table). Only one-quarter said the rule has greatly improved confidentiality. Of those who modified a protocol to comply with HIPAA, two-thirds said it was much harder to recruit subjects.

The article goes on to talk about how the impacts come not just from the actual rule, but from uncertainty about how to apply the rule and, of course, cautiousness (risk-aversion).

For those who follow the micro-level of cyber security policy, this is not surprising but is always worth paying attention to. The impact of cyber security policy is not just felt in the rule itself, but in uncertainty regarding how far to take it and the over-cautiousness some rules and organizational relationships seem to impart.

Obviously, we want end users and developers to be aware of the risks they face, but in a research environment, the impact of this kind of uncertainty can lead to direct impacts on innovation and effective research.

RPM 5.02 Updated

noreply@blogger.com (IT Policy) — Fri, 09 Nov 2007 19:37:00 +0000

We have updated RPM 5.02 on scientific and technical publications, mostly for readability and clarification. As you may or may know, the policy on division review (that is, review of published work within divisions) was modified after almost a year of discussion. The final version was approved by the SLC. That modification clarified the expectations for internal review of published work as follows:

E. REVIEW OF SCIENTIFIC AND TECHNICAL PUBLICATIONS

LBNL values the role of peer review in ensuring the integrity of scientific research. Researchers are expected to seek ongoing internal review of their work before publication. It is expected that employees will adhere to the highest ethical standards in their publishing, including those detailed in the University’s Statement of Ethical Values, especially as regards to the integrity and originality of work, and the recognition of the contributions of colleagues. Researchers must ensure that any information of a nonpublishable nature (such as that protected by human subjects protocol or a nondisclosure agreement) is excluded from publication. Per Section 5.03 of the RPM, researchers must identify potentially patentable discoveries to the Technology Transfer and Intellectual Property Management prior to any form of publication.

All publications must be reviewed within a division before receiving an LBNL/PUB or LBID number. Each division will ensure that (1) a reasonable scientific process has been followed, (2) papers include proper crediting of affiliations and acknowledgments as required by DOE, and (3) any other requirements indicated by their Division Director have been met. Divisional procedures must ensure that the review is fair and unbiased, and that freedom of scientific inquiry is not unfairly constrained.

Basically, this policy statement set the minimum expectation for internal division review; a brief review for scientific process, ensuring citations and credit line are correct, and any other expectations set by the Division Director. It's important to understand that the role previously played by RCO, which attempted to provide assurance of some of these things, will now entirely be the responsibility of the divisions.

There are some potential pitfalls to avoid with regards to the internal division procedures. Specifically, it's important to avoid any potential discriminatory biases in the review, as well as avoid the appearance of any kind of review for certain kinds of content. This is further explained here.

Further guidance is also forthcoming on the RCO Website.

Internet2 Report

noreply@blogger.com (IT Policy) — Fri, 12 Oct 2007 15:19:00 +0000

I was at the Internet2 conference in San Diego this week, presenting on the R&E view of the Federal Cyber Security Picture. While it wasn't clear that this was the right audience for this talk (note to program committee), the other talks I attended were excellent and a stark contrast to the somewhat gloomy federal picture.

In particular, it's inspiring to see the the cyberinfrastructure that is starting to appear for next generation science applications. At the keynote, a 9.8gig virtual circuit was deployed between Fermi and U. Wisconsin as the prototype for the LHC data flows. The virtual circuit crossed Internet2, ESnet, and the RON that serves U. Wisconsin. The technology underlying this was developed by the R&E networks (ESnet, I2, and I2 members) and the institutions themselves (Fermi, for instance, helped to develop the scheduler). This is a remarkable achievement and is a testament to the power of self-organization within the research community.

It also stands in stark contrast to Federal efforts to consolidate and separate federal networks from other networks. While this may or may not work well for traditional parts of the government, for the research community (DOE Labs, NASA, parts of NIH) it would be an unmitigated disaster. This is because the underlying assumption (that components of government agencies talk to each other and that this needs to be protected) is not the reality of science collaboration. The DOE labs talk to each other, but they mostly talk to external Universities and International Collaborators. And of course, when I say "talk" I mean at speeds and data flows that dwarf nearly all commercial and government data traffic in this country. (streaming video of keynote here)

Some of the proposals assume a world that would be equivalent to the UC campuses trusting each other completely across a regional optical network. This setup is bad for security and even worse for actual mission, because the underlying assumption - that we mostly talk to each other - is wrong. It's not just wrong because I say so either - ESnet is a net exporter of data: that is, more data flows between the labs and the R&E community then flows between the labs themselves.

Other useful stuff from the I2 meeting included discussions with Incommon, which Berkeley Lab is in the process of joining. Incommon is an R&E identity federation based on Shibboleth, which also forms the basis of the UCTrust federation. Incommon will eventually allow LBL researchers to authenticate to a variety of resources, perhaps most importantly, NIH Grant Administration tools. I am generally skeptical of arguments that "having multiple passwords" is a problem worth solving, but this one turns out to be a real issue with some very unique characteristics - it is a problem worth solving. It will take some time for us to modify some our IDM policies and practices to complete our federation, and this must be prioritized, but we are moving in that direction barring unforeseen technical problems. (Note to Fed readers: it's not that we are a government institution and need to interact with NIH, it's that we are a research institution that needs to interact with NIH - that is, the critical thing is that we are like any other grantee institution of NIH and need to interact with them as a University grantee does).

ATO Granted

noreply@blogger.com (IT Policy) — Wed, 26 Sep 2007 17:58:00 +0000

The DOE through its DAA, the Manager of the BSO, has granted all five lbl enclaves new Authorities to Operate good for three years. This was the penultimate step in what was basically a two year long process throughout the Office of Science, led by SC SIME Mike Robertson, to not only improve cyber security throughout the DOE Office of Science, but to improve it in a way that truly takes advantage of the unique risks, capabilities, and missions of the various Office of Science sites, while still maximizing the similarities of the approach to documentation and risk-assessment.

The Certification and Accreditation process is described further here.

The new ATOs are good through September of 2010.

Getting this done in a way that actually reflects what we do here is no small feat. The security teams of the enclaves did an amazing job, as did oversight group at BSO, supported by Oak Ridge and Headquarters - in particular Mike Robertson.

By the way, I say penultimate because, of course, the process doesn't end with the granting of the ATO. The continued operation, management, and improvement of LBNL's cyber security program is what the DAA accepts, and that is where the actual productive work of the LBNL cyber security teams resides.

Security Test and Evaluation Complete

noreply@blogger.com (IT Policy) — Tue, 11 Sep 2007 17:00:00 +0000

The ST&E vendor completed our external security test and evaluation and we received high marks. There were four issues, two of which were previously identified, which we are now tracking as corrective actions. The Site Office currently has the full results of our ATO package and we are briefing the site office this week. More soon.

Contract Measures and C&A

noreply@blogger.com (IT Policy) — Sun, 12 Aug 2007 23:01:00 +0000

Certification and Accreditation process is proceeding apace. The external auditors are completing their assessment and our documentation is nearly done.

It's also summer which means its contract performance measures time (PEMP-o-Rama). We'll be adding our own assurance section to the CIO blog as soon as these are finalized. Right now, it looks like we'll have a new leadership metric for communication to senior management about cyber security risks and threats, as well as "Section 8" cyber metrics and a new, albeit small, scorecard for IT successes at LBL.

On the policy front, UCOP issued a whole new set of requirements which are quite well conceived, especially the new IS-3. We'll be evaluating what, if anything, needs to be done to update our community-facing (RPM) or internal facing (CSPP) policies to reflect the new UC policies in the coming weeks.

As a final note, the word for the week is: Burdensomeness.

Update, C&A, FISMA

noreply@blogger.com (IT Policy) — Sun, 05 Aug 2007 21:51:00 +0000

The auditors we hired to perform our external Security Test and Evaluation for our C&A were onsite last week for the second phase of their testing. Things seem good and we await their final report.

I was at the University of California Information Technology Policy and Security in Santa Cruz last week. Among other interesting topics, some early discussion about the security and policy implications of dedicated on-demand connections of the kind being proposed throughout the R&E community turned out to be very interesting. Steve Lau and I gave a presentation about NIST and did some theorizing about the misapplication of FISMA to University grants and government partnerships. If you listen to my interview at Educause 2005, you can hear the outline of the problem we are seeing.

Basically, as agencies like the VA get into trouble you see broader (and improper) reading of the FISMA "on behalf of" and "government information" definitions, which are so overly broad as to trigger the FISMA requirements in pretty much any situation in which the government is involved (including research grants). This presents a situation where you might end up doing Certification and Accreditation type processes under small University research environments simply because they receive Federal funds. Not good.

e-discovery

noreply@blogger.com (IT Policy) — Wed, 01 Aug 2007 21:26:00 +0000

Since it doesn't appear anywhere else, Nancy Ware is the e-discovery coordinator for LBL. We have a process in place to analyze and respond to possible e-discovery requests.

Disaster Recovery Testing

noreply@blogger.com (IT Policy) — Thu, 05 Jul 2007 15:43:00 +0000

LBL completed its Contingency Planning / Disaster Recovery testing cycle for the year. This involved multiple technical tests and several large scale tabletops. Results were reported on July 4, 2007 to BSO and SC-CIO.

Revised Stewardship "Policy"

noreply@blogger.com (IT Policy) — Fri, 29 Jun 2007 18:56:00 +0000

UCOP has released a new website (draft?) on the Management of Electronic Information Resources which contains what they used to call stewardship requirements and which we still do. Excerpt:

The University of California is committed to high standards of excellence for management of its electronic information resources and therefore endorses information technology management practices that uphold principles of academic freedom, shared governance, open access, and privacy.

Consistent with the University Statement of Ethical Values and Standards of Ethical Conduct, all members of the University community are accountable for compliance with University policies and procedures for management of electronic information resources over which they have jurisdiction or control.

The website contains useful links to all sorts of policies/guidance appropriate to LBNL >>

Small update to 9.02

noreply@blogger.com (IT Policy) — Thu, 28 Jun 2007 23:24:00 +0000

While looking at what guidance we had on electronic signatures, we discovered (IAS really) that the RPM seemed to assign a line responsibility to them to certify control sufficiency for applications which use electronic signatures. No one seems to be quite sure where this requirement came from, but it seems outside the scope of UC IAS to certify as to sufficiency. We revised 9.02(D)(10)(e)(ii) to reflect the assignment of this responsibility to the application owner (and by extension, their line management).

http://www.lbl.gov/Workplace/RPM/R9.02.html#RTFToC40

Welcome to the IT Policy Blog

noreply@blogger.com (IT Policy) — Sat, 23 Jun 2007 23:43:00 +0000

Well, this is just kind of an experiment. Given that we're in the middle of certification and accreditation seasons for the cyber security programs, this blog is unlikely to get very much attention at the moment. Nevertheless, here's a quick update on IT Policy issues at LBNL right now.

1. C&A for Cyber Systems
We're in the midst of the Certification and Accreditation of the Cyber Security Program at LBNL. This is a big exercise in which we triannually certify to DOE that everything is working correctly, and they, in turn, accept the unmitigated residual risks associated with the program. We just recently completed our peer readiness review, and soon we'll have an external consulting firm provide independent verification and validation of our security test and evaluation program.

2. 9.01 Updated.
After a few years with just minor updates, RPM 9.01 was updated to reflect new requirements and expectations - especially the notion of stewardship of IT assets which is the foundational concept of the newly proposed UC Stewardship Policy. Coming up next, 9.02-9.05 get updated.

Test

noreply@blogger.com (IT Policy) — Sat, 23 Jun 2007 23:43:00 +0000

Post