Clark Piercy

1
Network Enhancements for DID at ORNL National
Laboratories Information Technology SummitJune
2007

• Clark Piercy
• ORNL Task Lead for Networking and Telecomm

2
ORNL DID Project Level 1 Milestones

• 1. Network Information and Activity Segregation
• 2.0 System - Establish configuration standards
• 3.0 Property - Establish asset management
  (Software and Hardware)
• 4.0 Access - Establish strong authentication

3
ORNL DID Project Level 1 Milestones

• 1. Network Information and Activity Segregation
• 2.0 System - Establish configuration standards
• 3.0 Property - Establish asset management
  (Software and Hardware)
• 4.0 Access - Establish strong authentication

4
1. Network Information and Activity Segregation

• Segregate systems with different levels of data
  sensitivity into protection zones with
  appropriate network controls between PZes
• Create a method to quarantine/block systems not
  meeting security and configuration requirements
• Put systems that can't meet security and
  configuration requirements behind a managed
  firewall

5
Protection Zones (PZes)

• First had to define what different types of PZes
  were needed
• Cyber Security dudes used FIPS 199
  (confidentiality, availability, integrity) and
  other guidance to come up with first cut
• Initially Highly Sensitive PZ, Infrastructure
  PZ, Admin PZ, Controlled Research PZ, Open Public
  PZ, Open Research PZ
• Eventually settled on Moderate with Enhanced
  Controls (M/EC), Infrastructure, Admin/Controlled
  Research, Open Public, Open Research

6
Protection Zone Definitions
Have initial protection zones defined, working to
refine the rules and definitions

• Moderate with Enhanced Controls contains
  systems which process moderate information that
  ORNL has determined require additional (enhanced)
  controls to protect the information, including
  UCNI and C/FGI-Mod
• Controlled Research contains systems used by
  researchers to create, store and process
  proprietary, export controlled, protected CRADA,
  applied technology or similar information
• Infrastructure systems which provide laboratory
  infrastructure and general system support to
  other systems at ORNL
• Administrative systems which contains most of
  the general purpose desktop systems which create,
  access and process moderate information
• NCCS systems that comprise the National Center
  for Computational Sciences
• Open/Public  systems containing web and ftp
  servers hosting public information that is
  accessible via anonymous access for any person or
  system on the Internet
• Open Research systems used to conduct open
  research that creates, stores, and processes
  fundamental research information.

7
Protection Zones Where and How Many?

• Which devices need to go in which protection
  zones?
• How many devices in each protection zone type?
• Where are they located?

8
What Are Rules for Protection Zones?
9
Many Questions but initially few answers to
base network design on.
10
To NAC or Not to NAC?

• Well defined requirements (quaratine, PZes) as
  well as fuzzy requirements (how many systems in
  each PZ and where are they?) lead us to look
  toward Network Access Control (NAC) as possible
  solution
• ORNL network users are used to mobility on the
  wired network (known registered devices) wanted
  to preserve mobility
• NAC was big buzz in trade press last Spring, so
  we decided to survey market and evaluate what was
  available

11
NAC Solution Search

• Given the need to support multiple OSes (Windows,
  Mac, nix), and no COTS NAC solution had an agent
  for all OSes, looked for solutions that worked
  with and without agents
• Did not like in band solutions as they represent
  additional bottle necks and failure points
• Needed a solution that had an open database so we
  could interface it to our home grown network
  registration system
• Narrowed down to 2 solutions to test, Ciscos NAC
  (Perfigo), and Lockdown Enforcer

12
Home Grown NAC Solution

• It was decided that the Admin and Controlled
  Research systems required the same level of
  protection (CIA Admin MML, Applied MLL,
  therefore M for the protection zone), thus could
  be in the same protection zone
• The vast majority of systems (90) would be in
  the Admin/Applied Research protection zone
• Therefore, we could maintain the current mobility
  for most systems since they will mostly be in the
  admin/applied zone by making our current network
  into the admin/applied zone
• We then needed to add protection zones (read
  VLANs) for ME/C, Infrastructure, Open Research,
  and Open Public
• We hoped most Infrastructure, Open Research, and
  Open Public systems would be relocated into one
  of our datacenters or content consolidated into
  servers in our datacenters. For systems that
  arent wed create trunked VLANs up to the
  datacenter(s) for these protection zones.

13
Homegrown NAC (cont.)

• Develop own quasi NAC that will rely upon DHCP,
  secondary subnets for registration, and
  quarantine/remediation, as well as controlling
  layer 2 ports to either force a system to do a
  DHCP discovery by bouncing its port, or blocking
  the system by disabling its port
• It will rely upon polling of router ARP caches
  and layer 2 switch bridge tables frequently
  (every 3-5 minutes) so we know what port a device
  is connected and what IP address it is using.
• A scan will be performed of all systems that have
  been off the network for 4 or more hours. If
  found wanting, the devices will be quarantined or
  blocked

14
Homegrown Quarantine/Remediation

• Secondary subnets are being configured on each
  VLAN, one for Quarantine, one for Remediation
  (already have one for registration for unknown
  devices)
• A device is put into quarantine by changing its
  record in our DHCP server so it is given a dummy
  DNS server and a very short lease IP address in
  the quarantine subnet that is filtered so it can
  only get to a Quarantine splash page.
• The client the opens a browser and is directed to
  the splash page which indicates the device has
  been quarantined, the reason why, and how to fix
  the problem to get out of quarantine.
• The user clicks on an acknowledgement button and
  the next DHCP update it is given changes its DNS
  server to a real one and changes its IP address
  to one in a remediation range that is filtered to
  block highly desirable apps (email, SAP) to
  encourage quick remediation
• Once the user has fixed their problem, they click
  on button indicating so and device is moved to
  Parole (full network access but on a list to be
  double checked by IT)
• See James Calloway and Paige Stafford
  Presentations for more details on Quarantine and
  ORNL NacMGR

15
PZ Deployment design

• Based on assumption that numbers of systems in
  M/EC, Open Research, Open Public, and
  Infrastrcture will be relatively small and be
  mostly located in the datacenters, decided to
  deploy PZes by placing Cisco Firewall Service
  Modules (FWSMs) in Datacenter 6500 and use VLANs
  and trunking as needed to extend PZes/VLANs
• Rules applied on FWSMs to control traffic between
  PZs
• Installed a ASA5520 between M/EC and rest of
  network due to requirement to have One Time
  Password (OTP) for login to M/EC systems from
  outside M/EC.
• We now have a better idea of how many systems in
  each PZ type (M/EC 24 now w/potential for 500
  with Protected PII, OP 12 for now, OR 450,
  Infra 500, Admin/ContRes 10,000

16
Type 4 System Segregation

• Type 4 systems cannot meet cyber security
  baseline requirements
• Instruments that cant have autoupdates/reboots
• Non-standard OSes that cant be changed due to
  one of a kind software
• Etc.
• Will place type systems behind firewalls managed
  by IT
• Many instances of one device behine one firewall
• Some instances of many associated devices behind
  one firewall
• Looked at using Ciscos Private VLAN construct
  along with FWSMs in Cisco 6500 backbone routers,
  but would require Cisco switches at edge
  everywhere a type 4 existed and we didnt know
  how many type 4s there would be
• Elected to go with small ASA5505s for most
  systems and a few ASA5520s for a few situations
• Turns out to be about 200 type 4 systems thus far
• Working on determining which can be grouped
  behind one firewall, and which have to be solo

17
VPN NAC

• Currenlty evaluating again the Cisco NAC for use
  with VPN
• Testing it with IT folks at present
• Has agent for Windoze (Vista, XP, 2000) and Mac
• Windows agent working pretty well with a few
  glitches under Vista, Mac agent not working so
  well yet
• Can use Nessus to scan other OSes (including
  MAC). For ORNL machines that we have admin
  rights on, may be able to us privileges to see
  further into system past any personal firewall.

18
ORNL DID Network Segregation Design
19
ORNL DID Project Level 1 Milestones

• 1. Network Information and Activity Segregation
• 2.0 System - Establish configuration standards
• 3.0 Property - Establish asset management
  (Software and Hardware)
• 4.0 Access - Establish strong authentication

20
4.0 Access - Establish strong authentication

• All external access to sensitive info use one
  time passwords (OTP)
• Needed to OTP VPN, dial up, remote SSH, and
  remote SSL
• Had SecurID solution already in house working
  with VPN on small scale, so expanded to all VPN
  users
• Moved Dialup server so it was outside VPN and now
  require dialup users to open vpn session to get
  inside
• OTPed the SSH server
• Installed Whale reverse proxy and now working on
  reducing authenticated http/https rules in border
  firewall and forcing users to Whale or VPN

21
More In-Depth Presentations related to ORNLs
Defense in Depth Project

• Managing Unix/Linux at ORNL Brett Ellis
• Defense in Depth Reporting at ORNL Steve Parham
• Managing Macs in an Enterprise Brian Wallace
• Quarantine Controlling Network Access Using
  DHCPJames Calloway
• Network Access Control at ORNLPaige Stafford