Network Policies and Procedures Presentation for DoE Office of Assurance Cybersecurity Review visit to SLAC August 2005

Written policies m/phone/phoneusersguide/PhoneUsersGu ide.htm#tamperhttp://www2.slac.stanford.edu/comp/teleco m/phone/phoneusersguide/PhoneUsersGu ide.htm#tamper No tampering with telephone, network cables or equipment –Disconnect equipment when found and may charge back labor to discover, rectify situation.

Multi-homed hosts cy/multi-homed.htmlhttp:// cy/multi-homed.html Outlines reason for multi-homed hosts and problem –Consult with net-admin –Do not turn on routing

Network devices inventory & access cy/device-inv.htmlhttp:// cy/device-inv.html Outlines reasons for needing a policy Devices must be in database Password must be available (escrow) Notification of testing new devices

Remote Access server policy y/csc-policies/remote-access.htmlhttp:// y/csc-policies/remote-access.html Why do we need to be concerned Policies: –Ways to access SLAC –How to add more remote access servers –How to admin RAS

Policy for Visitor & Wireless networks cy/visitor.htmlhttp:// cy/visitor.html General Guidelines for all SLAC subnets Define Visitor subnet and how it is to be used Wireless network and how it is to be used

Support Infrastructure Database of equipment – CANDO open to users, integrated with other processes (security, reports etc.) DNS registration forms Password escrow, password changed every 6 months, passwords chosen well Router & switch configuration –SSH access to routers with escrowed passwords, on a separate Internet Free subnet (accessible only from within SLAC) –SNMP access to routers/switches restricted – s if configuration changes –Router configurations archived in AFS, local disk and USB memory stick, restoration done when necessary Network topology knowledge: –Switch ports disabled by default –Twice daily automatically map network (CDP, ARP …) –Track what is connected to ports –Automatically look for duplicate IPs Firewalls, border & internal Migrate away from legacy protocols to focus on main needs (no Netware, AppleTalk, very limited DECnet …) Try to make easy for user to request switch ports, Wireless APs rather than “Do It Yourself” Close cooperation with security (shared person), systems (Linux, Windows) Network problems –reported to net-admin, from Unix Trouble Ticket System, and HelpTrack, & archived –Network monitoring automatically paging when detects problems (e.g. router/switch problems, system availability etc.)

Monitoring NetFlow –Enables characterization of SLAC traffic, top talkers, top applications, length of flows etc. –Look for anomalies for intrusions, misuse –Detailed results have restricted access Automated network discover and monitoring (switch/router SNMP, CDP, ARP, ping …) – guide.htmlhttp:// guide.html

Science Requirements Have to explain needs for security etc. to scientist, they need to be partners Collaborations worldwide –Most of traffic is with Europe (NOT with other DoE labs or even with US) –Access to data is with many countries Needs for high throughput –SLAC is one of the top production users of ESnet and one of the top users of Internet2 Connections via ESnet and CENIC/I2 currently 1Gbps ea soon to be 10Gbps

Terabytes/Month Fermilab (US)  WestGrid (CA) SLAC (US)  INFN CNAF (IT) SLAC (US)  RAL (UK) Fermilab (US)  MIT (US) SLAC (US)  IN2P3 (FR) IN2P3 (FR)  Fermilab (US) SLAC (US)  Karlsruhe (DE) Fermilab (US)  Johns Hopkins LIGO (US)  Caltech (US) LLNL (US)  NCAR (US) Fermilab (US)  SDSC (US) Fermilab (US)  Karlsruhe (DE) LBNL (US)  U. Wisc. (US) Fermilab (US)  U. Texas, Austin (US) BNL (US)  LLNL (US) Fermilab (US)  UC Davis (US) Qwest (US)  ESnet (US) Fermilab (US)  U. Toronto (CA) BNL (US)  LLNL (US) CERN (CH)  BNL (US) NERSC (US)  LBNL (US) DOE/GTN (US)  JLab (US) U. Toronto (CA)  Fermilab (US) NERSC (US)  LBNL (US) CERN (CH)  Fermilab (US) DOE Lab-International R&E Lab-U.S. R&E (domestic) Lab-Lab (domestic) Lab-Comm. (domestic) Recent Monthly ESnet usage

Network Speed Internet Land Speed Record (twice, in 2004 Guinness Book of Records) SuperComputing 2004 and 2004 Bandwidth Challenge winners for maximum BW util (102Gbits/s) Network research: –evaluate achieving hi-speed network performance, –measure and track network achievable bandwidth, –monitoring of all places wherever there are physicists (> 100 countries, > 3000 sites) Set expectations, find problems etc. –Worldwide collaborators, e.g. Pakistan, Russia

Visitor Network r_net.htmhttp://www2.slac.stanford.edu/comp/net/wireless/visito r_net.htm Large numbers of visitors, conferences, guest house, vendors etc. requires easy access, low management overhead Outside SLAC firewall, NOT in SLAC class B IP address space, separate AS and routing Users treated as if on any commercial or public ISP “Do not place mission critical applications on the Visitor network” Assigned via DHCP, a n.n IP address –No registration required

Wireless On visitor subnet In process of extending procedures for wireless network monitoring – –War walking (Kismet/GPS), identify APs and find rogues (non registered APs) –Locate with protocol analyzer with directional antenna (YellowJacket) Evaluating management system –Have about 90 APs, all Cisco –Use to automatically identify rogue APs as they appear

DHCP hcp.htmhttp://www2.slac.stanford.edu/comp/net/dhcp/d hcp.htm Connection logs archived so can track back abnormal utilization Internal network DHCP is 100% registration driven –Users & sys-admins required to keep machines patched –Machines are scanned daily for security updates Visitor network: –DHCP no registration, –separate infrastructure

Dialup Requires a dial-up account, password changed yearly –Accounts closed when people leave Use RADIUS for authentication In process of placing modem dial-up outside SLAC firewall (on visitor subnet) Guidelines on how to configure and use

Wireless Support for policy –War walking with Yellow Jacket etc. –Track APs offsite, and onsite, look for uknown