Live from the NSF Large Facilities Conference

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

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.

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.

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

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

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

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.