Table of Contents Executive Summary 3

3.8Security

We continued our efforts to improve the OSG security program. The security officer asked for an external peer evaluation of the OSG security program which was conducted by the EGEE and TeraGrid security officers and a senior security person from University of Wisconsin. The committee produced a report of their conclusions and suggestions, according to which we are currently adjusting our current work. This peer evaluation proved so successful that we have received requests from EGEE and TeraGrid officers to join an evaluation of their security programs.

In collaboration with ESNet Authentication and Trust Fabric Team, we have organized two security workshops: 1) the Living in an Evolving Identity World Workshop brought technical experts together to discuss security systems; and, 2) the OSG Identity Management Requirements Gathering Workshop brought the user communities together to discuss usage of the security systems. Usability has surfaced as a key element in both workshops. Historically, we have understood that ease-of-use of the PKI infrastructure greatly affects the security of our environment: a too complex security environment forces users to circumvent security all together or increases the barriers of entry into the grid world. We have conducted a detailed user survey with our VO contacts to pinpoint problem areas; the workshop reports are available at https://twiki.grid.iu.edu/bin/view/Security/OsgEsnetWorkshopReport). Accordingly, we have added priority to improve these problem areas in the next year.

During the past year, we increased our preparations for the LHC re-start of data taking:

• 
  We conducted a risk assessment of our infrastructure and held a 2-day blueprint meeting with our executive team. We identified the risks over our authentication infrastructure that could significantly affect OSG operations. We subsequently met with ESNet management since they provide the backbone of our authentication infrastructure. We jointly developed mitigation plans for the identified risks and have been implementing the plans. For example, we completed a tool to monitor suspicious behavior in ESNet certificate issuance infrastructure.
  
• 
  We identified that our software distribution mechanism is a high-risk attack target and thus we decided to use signed software packages that can be automatically validated by site administrators during software updates.
  
• 
  In order to increase the security quality of VDT software, we reached out to our external software providers and exchanged our security practices such as vulnerability announcement, patching policies, update frequencies and such.
  
• 
  With the help of Professor Barton Miller of University of Wisconsin, we organized a “Secure Programming Workshop” in conjunction with the OGF. The tutorial taught the software providers the secure coding principles with hands-on code evaluation. A similar tutorial was also given at EGEE'09 conference to reach out to European software providers, which forms a significant part of the VDT code.
  
• 
  We formed a software vulnerability process with the help of VDT team. The security team watches the security bulletin boards on a daily basis and triggers the vulnerability evaluation process if a possible vulnerability is suspected that could affect the VDT code.
  
• 
  To measure LHC Tier-2s ability to respond to an ongoing incident, we conducted an incident drill. The drill included all LHC Tier-2 sites and a LIGO site, 19 sites in total. Each site has been tested one-on-one; a security team member generated a non-malicious attack and assessed sites responses. In general the sites performed very well with only a handful of site needing minor assistance or support in implementing the correct response actions. Our next goal is to conduct an incident drill to measure the preparedness of our user community and the VOs.
  

• 
  We focused on Tier-3s at the OSG Site Administrators Workshop. Before the workshop, we individually contacted each site, asked for their needs and encouraged participation. Their feedback helped shaping our preparation significantly.
  
• 
  After the workshop, we have continued our efforts by meeting with a Tier-3 site admin one-on-one each week. The summaries of our meetings can be found at https://twiki.grid.iu.edu/bin/view/Security/FY10SecuritySupport and this effort continues in coming year.
  
• 
  We give special guidance to our Tier 3 sites during security vulnerabilities. So far, we have had two high-risk root-level kernel vulnerabilities. In addition to our regular response process, we contacted each Tier-3 site individually, and helped them test and patch their systems. There is a clear need for this type of support at least until Tier3s become more familiar with site management. However, individualized care for close to 20 sites is not sustainable due to our existing effort level and we are investigating automated tools to relieve this burden. In addition, we want to build a security community, where each site admin is an active contributor and can work with his/her peers. We have started a security blog and a ticketing system to accommodate information sharing and we plan to increase awareness of these tools to create an active community.
  

During the last year, we identified a problem with updating OSG-recommended security configurations at sites; we identified the need for an administrative update tool to solve the issue and this tool is now in testing for a future release. To provide better monitoring, the security team wrote a suite of security probes which allow a site administrator to compare local security configurations against OSG-suggested values; these monitoring probes have been released with OSG 1.2. In the next year, we plan to focus more on monitoring efforts which we consider a critical element of our risk assessment and mitigation plans.