1. Terri Lahey LCLS Facility Advisory Committee lahey@slac.stanford.edu 20 April 2006 LCLS Network Security Terri Lahey

2. LCLS Facility Advisory Committee lahey@slac.stanford.edu 20 April 2006 Outline Engineering Teams Apply experience and new architectures Integrated Security at SLAC Servers & desktops Network security Other security practices Ethernet Architecture What’s Next?

3. Terri Lahey LCLS Facility Advisory Committee lahey@slac.stanford.edu 20 April 2006 Engineering Teams SCCS: (network and security) Gary Buhrmaster, Antonio Ceseracciu, Charles Granieri, Fred Hooker LCLS: Doug Murray CPE: Ken Brobeck, Jim Knopf, Terri Lahey, Jingchen Zhou

4. Terri Lahey LCLS Facility Advisory Committee lahey@slac.stanford.edu 20 April 2006 Apply Experience from PEP and Implement New Architectures Protect accelerator components and access to the control system Control number of connections Control who connects Meet Users needs Physicists, operators, engineers need access to control system and components so they can do their job Security issues exist for the networks and hosts on the network

5. Terri Lahey LCLS Facility Advisory Committee lahey@slac.stanford.edu 20 April 2006 Integrated Security Work with SCCS security team to help us run 24x7. SCCS security: actively participates in & monitors main security forums, including CIAC, SANS & FIRST email, inter-lab communication, & represents SLAC to DOE Has knowledge of new security flaws Tracks break-ins Scans our networks for security risks via daily and scheduled scans Advises us on security practices (problems found, reviews our plans and helps create new architectures) OA scans at SLAC Site Assistance Visits Participate in Computing Security Committee

6. Terri Lahey LCLS Facility Advisory Committee lahey@slac.stanford.edu 20 April 2006 Hosts: System Administrators Take security seriously in design, implementation and maintenance of hosts Work with users and security teams at SCCS Use SCCS-supported versions of operating systems & applications where possible Patch operating systems and update Reduce maintenance load and improve security by using taylor where possible Automate maintenance of production hosts Centralized Log server & security monitoring Use existing servers where possible (e.g. elog)

7. Terri Lahey LCLS Facility Advisory Committee lahey@slac.stanford.edu 20 April 2006 Networks SCCS Networking configures the network switches and routers & manages the physical layer. Controls Software coordinates control system and user needs, and works closely with SCCS. Production accelerator network is controlled and protected. Greater attention to security by both SCCS and Controls Run accelerator disconnected from the rest of SLAC; For use if there is a security problem at SLAC. Isolation of Wireless network: Wireless and Accelerator switches are never combined. Wireless is visitornet that resides outside SLAC firewall. Users tunnel into SLAC the same way they tunnel from internet: ssh, citrix, vpn

8. Terri Lahey LCLS Facility Advisory Committee lahey@slac.stanford.edu 20 April 2006 Networks CISCO switches and routers Patch network firmware and upgrade versions. Plan for and upgrade hardware components to avoid end- of-life Implement Redundancy in core switches and routers, for reliability. Use hot spares for device switches, but increased use of VLANs will likely require some configuration. SLAC-wide Network monitoring systems send alarms: components go offline (e.g.. power outage or failure) ports get disabled due to too many collisions

9. Terri Lahey LCLS Facility Advisory Committee lahey@slac.stanford.edu 20 April 2006 Other Practices Account management Authenticate to control access to hosts Authorize access to control system functions Personal accounts, with limited locked-down group accounts in the control room No clear-text passwords X access control Network Practices: ports disabled by default IP addresses allocated and tracked centrally in CANDO. DNS generated from CANDO IFZ and private networks. Both still require patching and good security. DHCP is controlled & no leases on accelerator networks

10. Terri Lahey LCLS Facility Advisory Committee lahey@slac.stanford.edu 20 April 2006 SCCS Managed services Central management of servers that require a high level of security improves security and reduces effort: ORACLE WEB servers

11. Terri Lahey LCLS Facility Advisory Committee lahey@slac.stanford.edu 20 April 2006 Network Architecture Production accelerator network is isolated: Protect IOCs that often require insecure services like telnet/rsh or have less secure tcp/ip stacks Control access to accelerator components so that systems do not get overloaded Use private addresses Multiple VLANs to separate traffic Ports disabled by default 1gigabit to the end devices. Currently 1gigabit uplinks to MCC DMZ is only access to private network (login servers, web servers, PV gateways). MCC and SLC-aware IOC uses PEP proxy server have tested with PEP running 9 SAIOCs for injector more testing to confirm that PEP & LCLS will not impact each other. path to SCCS data silos & other required sevices

12. Terri Lahey LCLS Facility Advisory Committee lahey@slac.stanford.edu 20 April 2006

13. Terri Lahey LCLS Facility Advisory Committee lahey@slac.stanford.edu 20 April 2006 What’s next Additional tests of SLCaware IOC and improve monitoring of traffic to avoid interference between PEP & LCLS programs Review and implement VLANs needed Filtering Router or Firewall? Complete design and design review of production hosts and networks & documents Full schedule for hosts & network Integration of plans with other networks (timing, MPS, feedback, etc.)