Second Line of Defense Virtual Private Network Guidance for Deployed and New CAS Systems



Similar documents
Measurement of BET Surface Area on Silica Nanosprings

Situated Usability Testing for Security Systems

Drupal Automated Testing: Using Behat and Gherkin

Penetration Testing of Industrial Control Systems

Dynamic Vulnerability Assessment

Risk D&D Rapid Prototype: Scenario Documentation and Analysis Tool

Early Fuel Cell Market Deployments: ARRA and Combined (IAA, DLA, ARRA)

Optical Blade Position Tracking System Test

Laser Safety Audit and Inventory System Database

IDC Reengineering Phase 2 & 3 US Industry Standard Cost Estimate Summary

Automated Transportation Management System

Improving a Gripper End Effector

The Production Cluster Construction Checklist

A Systems Approach to HVAC Contractor Security

The purpose of this policy is to provide guidelines for Remote Access IPSec or Virtual Private

Secure SCADA Communication Protocol Performance Test Results

This document was prepared in conjunction with work accomplished under Contract No. DE-AC09-96SR18500 with the U. S. Department of Energy.

NEAMS Software Licensing, Release, and Distribution: Implications for FY2013 Work Package Planning

Network Services Internet VPN

Regional Field Verification Operational Results from Four Small Wind Turbines in the Pacific Northwest

Elastomer Compatibility Testing of Renewable Diesel Fuels

Remote Access Procedure. e-governance

A New Empirical Relationship between Thrust Coefficient and Induction Factor for the Turbulent Windmill State

Energy Systems Integration

Derived Intervention Levels for Tritium Based on Food and Drug Administration Methodology Using ICRP 56 Dose Coefficients (U)

Remote Firewall Deployment

Small PV Systems Performance Evaluation at NREL's Outdoor Test Facility Using the PVUSA Power Rating Method

FIREWALL POLICY DOCUMENT

Patch Management Marvin Christensen /CIAC

Department of Information Technology Remote Access Audit Final Report. January promoting efficient & effective local government

Table of Contents. Introduction

IREBOX X. Firebox X Family of Security Products. Comprehensive Unified Threat Management Solutions That Scale With Your Business

Putting Web Threat Protection and Content Filtering in the Cloud

PART D NETWORK SERVICES

CITY UNIVERSITY OF HONG KONG Network and Platform Security Standard

W. C. Reinig. Savannah River Laboratory E. I. du Pent de Nemours and Company Aiken, South Carolina 298o1

The Cisco ASA 5500 as a Superior Firewall Solution

Case Study for Layer 3 Authentication and Encryption

Radius Integration Guide Version 9

SafeEnterprise SSL igate Managing Central Access to Resources with VPX Technology

Configuring Outlook 2010 for Windows

Solution Recipe: Improve PC Security and Reliability with Intel Virtualization Technology

Configuring Outlook 2016 for Windows

Configuring Apple Mail for Mac OS X (Mountain Lion)

MSP Service Matrix. Servers

Proactive IT Solutions More Reliable Networks Are Our Business

Proven LANDesk Solutions

Climate-Weather Modeling Studies Using a Prototype Global Cloud-System Resolving Model

Internet Content Provider Safeguards Customer Networks and Services

State of Texas. TEX-AN Next Generation. NNI Plan

NETWORK AND CERTIFICATE SYSTEM SECURITY REQUIREMENTS

PROTECTING INFORMATION SYSTEMS WITH FIREWALLS: REVISED GUIDELINES ON FIREWALL TECHNOLOGIES AND POLICIES

Cisco ASA. Implementation Guide. (Version 5.4) Copyright 2011 Deepnet Security Limited. Copyright 2011, Deepnet Security. All Rights Reserved.

INSTANT MESSAGING SECURITY

CONTROL SYSTEM VENDOR CYBER SECURITY TRENDS INTERIM REPORT

MANAGED SECURITY SERVICES

Service. Strategic Technology Solutions for DNA Technology Solutions and Services That Help You Optimize System Performance, Security and Availability

IPSec VPN Client Installation Guide. Version 4

BlackBerry 10.3 Work and Personal Corporate

Secure Access into Industrial Automation and Control Systems Industry Best Practice and Trends. Serhii Konovalov Venkat Pothamsetty Cisco

Rethinking Schools Limited Institutional Site License

Cyberoam Configuration Guide for VPNC Interoperability Testing using DES Encryption Algorithm

Installing the Shrew Soft VPN Client

The Advantages of a Firewall Over an Interafer

How To Extend Security Policies To Public Clouds

HughesNet Broadband VPN End-to-End Security Enabled by the HN7700S-R

Simphony v2 Antivirus Recommendations

Computing Services Helpdesk

Configuring IPsec VPN with a FortiGate and a Cisco ASA

HughesNet Broadband VPN End-to-End Security Using the Cisco 87x

nwstor Storage Security Solution 1. Executive Summary 2. Need for Data Security 3. Solution: nwstor isav Storage Security Appliances 4.

E-Sign Disclosure & E-Statements Terms and Conditions

Responsible Administrative Unit: Computing, Communications & Information Technologies. Information Technology Appropriate Use Policy

Achieving PCI-Compliance through Cyberoam

Windows 7, Enterprise Desktop Support Technician Course 50331: 5 days; Instructor-led

Wind Forecasting stlljectives for Utility Schedule and Energy Traders

SSL VPN 1H03 Magic Quadrant Evaluation Criteria

NREL Job Task Analysis: Crew Leader

SSL VPN Client Installation Guide Version 9

Trust Operational Policy. Information Security Department. Third Party Remote Access Policy

Managed Security Services for Data

Cisco Cloud Web Security Key Functionality [NOTE: Place caption above figure.]

HOSTING SERVICES AGREEMENT

Managed IT Solutions. More Reliable Networks Are Our Business

UMHLABUYALINGANA MUNICIPALITY IT PERFORMANCE AND CAPACITY MANAGEMENT POLICY

MANAGED SECURITY SERVICES RESPONSIBILITIES GUIDE July 2013

Transcription:

PNNL-19266 Prepared for the U.S. Department of Energy under Contract DE-AC05-76RL01830 Second Line of Defense Virtual Private Network Guidance for Deployed and New CAS Systems SV Singh AI Thronas January 2010

DISCLAIMER This report was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor any agency thereof, nor Battelle Memorial Institute, nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial product, process, or service by trade name, trademark, manufacturer, or otherwise does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or any agency thereof, or Battelle Memorial Institute. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or any agency thereof. PACIFIC NORTHWEST NATIONAL LABORATORY operated by BATTELLE for the UNITED STATES DEPARTMENT OF ENERGY under Contract DE-ACO5-76RL01830 Printed in the United States of America Available to DOE and DOE contractors from the Office of Scientific and Technical Information, P.O. Box 62, Oak Ridge, TN 37831-0062; ph: (865) 576-8401 fax: (865) 576 5728 email: reports@adonis.osti.gov Available to the public from the National Technical Information Service, U.S. Department of Commerce, 5285 Port Royal Rd., Springfield, VA 22161 ph: (800) 553-6847 fax: (703) 605-6900 email: orders@nits.fedworld.gov online ordering: http://www.ntis.gov/ordering.htm

Acronyms AT CAS SLAT SLD VPN Acceptance Test Central Alarm Station System Level Acceptance Testing Second Line of Defense Virtual Private Network

Contents 1.0 Overview... 1 2.0 Background... 1 3.0 Requirements... 1 3.1 Assumptions... 1 3.2 Hardware/Software... 1 3.3 Client Software... 2 3.4 Help Desk Requirement... 2 4.0 Deployment... 2 5.0 Maintenance... 2 6.0 Sustainability... 3 Appendix A Functional Requirements... 4

1.0 Overview This paper discusses the importance of remote access via virtual private network (VPN) for the Second Line of Defense (SLD) Central Alarm System (CAS) sites, the requirements for maintaining secure channels while using VPN and implementation requirements for current and future sites. 2.0 Background There has been no standardized method of establishing remote access for sites currently participating in the SLD program. Many sites that are installed with VPN are vendor controlled, which can constitute a conflict of interest between a paid vendor having control of both the installed systems and access to those systems to repair them. Other sites have not established a method for remote access. Additionally, at some sites the remote access is enabled but is not secured properly, possibly allowing malicious attackers originating from the internet to gain access to information without a legitimate need to know. The attacker could also install viruses or other control software on attacked machines, which typically run in a non-patched state, causing them to distribute virus code, send spam out and perform slowly, frustrating the sites and causing an increase in the number of SLD Helpdesk Service Requests received. Finally, the implementation of VPN is not done with consistency at each site, making support and sustainability more complex, increasing costs over the supported lifetime of the system. The program needs to be able to implement a consistent VPN solution that is robust, upgradeable and replicable, increasing uptime for our customers and reducing costs. 3.1 Assumptions 3.0 Requirements Country is allowing remote access for SLD staff members or vendors Country has a working infrastructure to maintain an internet connection 3.2 Hardware/Software Consistent hardware is paramount to being able to have a supportable and sustainable solution that can be implemented for all sites. Also, the hardware should not interrupt normal operations for the site. The hardware should function in a secure manner and not require frequent updating in order to maintain remote functionality. The hardware should be configurable to match the needs of the site, should that be a simple, secure remote connection or two-factor authentication. The hardware should also be able to maintain a log of the user who used a remote access capability to include user identifiable information, time the system was accessed, and duration of the access. The hardware and software should accommodate a large number of users. 1

The recommended hardware to be implemented is the Cisco ASA 5500 series appliance as it offers firewall, router, VPN, and comprehensive logging capability in one device. Available in different sizes, Cisco ASA appliances can be pre-configured and distributed to the SLD sites. 3.3 Client Software A consistent software base, supported by the manufacturer, is also necessary from a supportability standpoint. The software should be able to accommodate installation of multiple profiles because of the likelihood that an SLD staff member or a vendor will be supporting sites totaling more than one. The client recommendation, if using a client-to-site VPN model, is Cisco IPSEC VPN client. This client allows us to enforce a full tunnel between the end points. This means that all traffic when using VPN is routed between the two computers only and no other network traffic is allowed (i.e., a computer that is connecting with VPN will not be able to access local resources like shares and printers or the internet, only remote resources). Using a third party client can lead to a possible split tunnel, which allows access to local and remote resources and the internet, creating a possible security vulnerability. 3.4 Help Desk Requirement It is recommended that the SLD Helpdesk serve as the single point of contact for all account operations regarding SLD sites with VPN access. Working in close coordination with DOE-HQ, the SLD Helpdesk can serve as the clearinghouse for all VPN requests and will grant or revoke access requests from vendors and SLD staff members. The SLD Helpdesk will maintain records of access requests and be able to provide reporting on remote access usage when necessary. The SLD Helpdesk will also require renewal of all VPN access requests once per year for SLD staff members and vendors. The SLD Helpdesk will also control two-factor authentication token distribution and keep records of who has two-factor authentication tokens and request their return upon a staff member or vendor no longer requiring the token. Finally, the SLD Helpdesk will maintain VPN profile information for all sites and be able to distribute the profile information when it is deemed necessary. 4.0 Deployment Hardware and software deployment details are to be determined by site and schedule requirements. Complete deployment should be reasonably completed within one year. New sites should have a contingency written for System Level Acceptance Testing (SLAT)/Acceptance Test (AT) that requires remote VPN access be implemented following this guidance document. All sites, if capable, will have VPN remote access capability. 5.0 Maintenance Updates to VPN hardware operating systems will be coordinated by the SLD Helpdesk and deployed by an SLD Helpdesk Service Request Manager or a knowledgeable delegate. 2

Updates to VPN client software will be coordinated by the SLD Helpdesk and communicated via e- mail. The SLD Helpdesk will maintain a share or website with current software for deployment to SLD staff members or vendors. Users having outdated client software will not be able to connect via VPN until after the update to supported software is complete. The SLD Helpdesk will not support VPN software on outdated operating systems or on recently deployed operating systems for which a client may not be available from the VPN hardware/software vendor. 6.0 Sustainability Upgrades to standardized equipment and software will be coordinated through the SLD Helpdesk via a Service Request. Testing of software and hardware upgrades will also be done by the SLD Helpdesk in an offline testing prior to deployment on other SLD systems. Communication will be done via e-mail prior to deploying any updates. Sites will allow for remote upgrades of equipment or take responsibility for deployed equipment and its hardware or software maintenance. 3

REQ 1 Remote access will be secure. REQ 2 Remote access will be reliable. Appendix A Functional Requirements REQ3 Remote access will not impede bandwidth to a point that it is unusable. REQ4 Remote access will be able to be controlled, managed and tracked from a central location. REQ5 Remote access software will not adversely affect normal operations of client or remote client systems. 4