Secondary DMZ: DMZ (2)

Similar documents
Achieving PCI-Compliance through Cyberoam

FIREWALL POLICY DOCUMENT

SonicWALL PCI 1.1 Implementation Guide

Locking down a Hitachi ID Suite server

Consensus Policy Resource Community. Lab Security Policy

74% 96 Action Items. Compliance

A Rackspace White Paper Spring 2010

Data Management Policies. Sage ERP Online

Approved 12/14/11. FIREWALL POLICY INTERNAL USE ONLY Page 2

Payment Card Industry Self-Assessment Questionnaire

Building A Secure Microsoft Exchange Continuity Appliance

UCIT INFORMATION SECURITY STANDARDS

CITY UNIVERSITY OF HONG KONG Network and Platform Security Standard

RSA Authentication Manager 7.1 Security Best Practices Guide. Version 2

TASK TDSP Web Portal Project Cyber Security Standards Best Practices

Computer Security CS 426 Lecture 36. CS426 Fall 2010/Lecture 36 1

PCI Requirements Coverage Summary Table

March

Did you know your security solution can help with PCI compliance too?

NETWORK SECURITY GUIDELINES

LAMAR STATE COLLEGE - ORANGE INFORMATION RESOURCES SECURITY MANUAL. for INFORMATION RESOURCES

PCI PA - DSS. Point BKX Implementation Guide. Version Atos Xenta, Atos Xenteo and Atos Yomani using the Point BKX Payment Core

Next Generation Network Firewall

PCI Requirements Coverage Summary Table

System Security Plan University of Texas Health Science Center School of Public Health

FIREWALL POLICY November 2006 TNS POL - 008

Innovative Defense Strategies for Securing SCADA & Control Systems

PCI PA - DSS. Point ipos Implementation Guide. Version VeriFone Vx820 using the Point ipos Payment Core

Computer and Network Security Policy

PCI Implementation Guide

Vendor Risk Assessment Questionnaire

modules 1 & 2. Section: Information Security Effective: December 2005 Standard: Server Security Standard Revised: Policy Ref:

Managed Services Agreement. Hilliard Office Solutions, Ltd. PO Box Phone: Midland, Texas Fax:

Security Policy for External Customers

Honeywell Industrial Cyber Security Overview and Managed Industrial Cyber Security Services Honeywell Process Solutions (HPS) June 4, 2014

MANAGED FIREWALL SERVICE. Service definition

IT Best Practices Audit TCS offers a wide range of IT Best Practices Audit content covering 15 subjects and over 2200 topics, including:

SITA Security Requirements for Third-Party Service Providers that Access, Process, Store or Transmit Data on Behalf of SITA

Recommended IP Telephony Architecture

Best Practices for PCI DSS V3.0 Network Security Compliance

MAXIMUM DATA SECURITY with ideals TM Virtual Data Room

Industrial Security for Process Automation

Introduction. PCI DSS Overview

WatchGuard XCSv Setup Guide

Question Name C 1.1 Do all users and administrators have a unique ID and password? Yes

Security Solutions to Meet NERC-CIP Requirements. Kevin Staggs, Honeywell Process Solutions

TEXAS AGRILIFE SERVER MANAGEMENT PROGRAM

Information Technology Security Procedures

1.3 Prohibit Direct Public Access - Prohibit direct public access between the Internet and any system component in the cardholder data environment.

California Department of Technology, Office of Technology Services WINDOWS SERVER GUIDELINE

1 Purpose Scope Roles and Responsibilities Physical & Environmental Security Access Control to the Network...

A Decision Maker s Guide to Securing an IT Infrastructure

State of New Mexico Statewide Architectural Configuration Requirements. Title: Network Security Standard S-STD Effective Date: April 7, 2005

1. Why is the customer having the penetration test performed against their environment?

How To Protect Decd Information From Harm

FIREWALL CHECKLIST. Pre Audit Checklist. 2. Obtain the Internet Policy, Standards, and Procedures relevant to the firewall review.

Global Partner Management Notice

Remote Deposit Terms of Use and Procedures

How To Control Vcloud Air From A Microsoft Vcloud (Vcloud)

Information Security Policy. Policy and Procedures

Automate PCI Compliance Monitoring, Investigation & Reporting

Customer Service Description Next Generation Network Firewall

How To Secure An Rsa Authentication Agent

Guideline on Auditing and Log Management

INTRUSION DETECTION SYSTEMS and Network Security

G/On. Basic Best Practice Reference Guide Version 6. For Public Use. Make Connectivity Easy

PCI DSS Requirements - Security Controls and Processes

Migration Project Plan for Cisco Cloud Security

Supplier Information Security Addendum for GE Restricted Data

Passing PCI Compliance How to Address the Application Security Mandates

Rule 4-004G Payment Card Industry (PCI) Remote and Mobile Access Security (proposed)

Enterprise Cybersecurity Best Practices Part Number MAN Revision 006

REDCENTRIC MANAGED ARCHIVE SERVICE SERVICE DEFINITION

Kenna Platform Security. A technical overview of the comprehensive security measures Kenna uses to protect your data

UMHLABUYALINGANA MUNICIPALITY PATCH MANAGEMENT POLICY/PROCEDURE

Supplier IT Security Guide

BAE Systems PCI Essentail. PCI Requirements Coverage Summary Table

How NETGEAR ProSecure UTM Helps Small Businesses Meet PCI Requirements

Network Access Control in Virtual Environments. Technical Note

Quick Setup Guide. 2 System requirements and licensing Kerio Technologies s.r.o. All rights reserved.

Central Agency for Information Technology

Firewalls. Securing Networks. Chapter 3 Part 1 of 4 CA M S Mehta, FCA

Client Security Risk Assessment Questionnaire

Effective Defense in Depth Strategies

Nessus Agents. October 2015

Company Co. Inc. LLC. LAN Domain Network Security Best Practices. An integrated approach to securing Company Co. Inc.

Verve Security Center

Larry Wilson Version 1.0 November, University Cyber-security Program Critical Asset Mapping

Achieving PCI Compliance Using F5 Products

SETTING UP AN LMADMIN LICENSE SERVER

Oracle Maps Cloud Service Enterprise Hosting and Delivery Policies Effective Date: October 1, 2015 Version 1.0

REDCENTRIC MANAGED FIREWALL SERVICE DEFINITION

1B1 SECURITY RESPONSIBILITY

Transcription:

Secondary DMZ: DMZ (2) Demilitarized zone (DMZ): From a computer security perspective DMZ is a physical and/ or logical sub-network that resides on the perimeter network, facing an un-trusted network or in most cases the internet. This zone holds all services that need to be accessed from the un-trusted network. The purpose of having a DMZ is to add an additional layer of security to the institutions internal network (in our case it will be the University s production network). We currently have a DMZ (1) which is being populated with services that need to be accessed from the internet. However, there is a growing need for services that are tangentially connected to the university that reside at the university, as well as users other than IT administrators to be able to setup, test and/or deploy custom or proprietary applications, systems that are not supported by Information Technology (IT). In order satisfy this requirement we are creating a second DMZ, DMZ (2). The idea here is to facilitate and enhance the academic environment by providing a zone which could be used by non-it administrators while not putting the institutions internal infrastructure at risk. This zone will have systems and applications that are not entirely supported by IT. There will be two categories into which all systems and services in this zone will be grouped. Some of the systems will be provided hardware and software (OS level only, no application level support). The remainder are supported and maintained by respective data owners. The details with regards to groupings are given in the following sections of this document. All systems and services regardless of the owner must always comply with the University s Acceptable Use Policy. The University s Acceptable Use Policy states that IT reserves the right to shut down or turn off services if any of the systems or services is found to be in violation of the acceptable use policy. Similar action will be taken if any of the services or systems are suspected to be or found to be the cause of being a part of any malicious activity. 1

2

Mapping Systems to DMZ: Taxonomy of systems DMZ (2): This zone will have systems that fall in one of the two categories below. IT will monitor these systems to look for any suspicious activity. IT also reserves the right to shutdown any and all services and/ or systems that are suspected to be part of any malicious activity or are in violation of the acceptable use policy. A: Systems in this zone under category A are those that will have hardware and software (up to OS level, web server level) support from IT. The applications will have to be installed, setup, patched and maintained by the data owner. All systems in this category must be compliant with the policy on IT authorized services. There will be no rate limiting. B: Systems in this zone under category B are those that will have to be procured, setup and maintained by the data owners. The data owners will be responsible for securing funding for purchase of hardware, software (including OS) and applications. There will be a limitation on Bandwidth usage (rate limiting of internet bandwidth). All systems in the DMZ (2) must be patched and must have Anti Virus (AV) software installed with the latest updates. They must have internal firewalls (Windows, Red Hat etc.) turned on. This will be monitored by performing periodic scans and audits. If the systems are found without the latest OS level patches and AV updates then those systems will be quarantined or taken offline until the required patches and AV have been installed. All systems in DMZ (2A and 2B) which are running Microsoft OS must be patched by the 3 rd Friday of every month. Patches are released by Microsoft on the second Tuesday of every month. This gives sufficient time to apply the latest OS level patches. It is important to apply patches ASAP since systems without patches are an easy target for being exploited and this will put the BSU infrastructure at risk. All applications must be patched as soon as patches are made available by individual vendors. All university affiliated websites with static web content will be hosted under the DMZ (2A) category. If the content on the websites is dynamic then the server will be hosted under the DMZ (2B) category and DMZ (2B) rules apply. The IT supported OS for systems in DMZ (2A) are Windows and Red Hat. The user will not be given administrator level access to any system in DMZ (2A). Application level access may be provided to systems that are running Red Hat. Systems in DMZ (2B) will not put on the BSU domain. Local accounts: All local accounts on servers must be disabled or password protected in accordance with BSU s complex password policy. All guest and unused accounts must be disabled. The administrator account must be renamed. No default credentials should be in use. Remote administration: All users who wish to manage their systems remotely will have to go through a VPN to gain access for administration. 3

All servers in the secondary DMZ are required to be rack mountable and must have a UPS to accommodate any possible interruption of power. SUPPORT Admin Network, DMZ (2A) DMZ (2B) DMZ (1) Hardware IT IT: VMWARE User OS IT IT User Application install IT User User Patching (OS) IT IT User AV IT IT User Administration Account Application update and patching IT User, IT User IT User User Monitoring IT IT IT Backup IT Case by Case User Remote access SSL VPN with RSA token SSL VPN with RSA token SSL VPN Web Server support IT IT (Static content) User (Dynamic content) Firewall IT IT User Network Drive mapping Allowed Not allowed Not allowed Physical access IT administrators only Limited (Escorted access) Limited (Escorted access) The networking rules for systems in DMZ (2) are as below: Summary of access rules: No direct access (inbound or outbound) is allowed between the DMZ (2) and the DMZ (1) or between the DMZ (2) and the admin network, unless otherwise specified. Changes to the access rules and or services will be decided on a case by case basis. To request a change, a business request is required with 4

sufficient justification. After submission of the change request a review process will be initiated by IT. Any change thus made must be in accordance with the acceptable use policy. From Internet to DMZ (2) Access to be given on a need to use/ request to use basis. A request has to be made by the user asking for the ports and services to be opened that they need. They will also have to justify the request by providing information on how and for what the requested ports and services will be used for. From DMZ (2) to internet Access to be given on a need to use/ request to use basis. A request has to be made by the user asking for the ports and services to be opened that they need. They will also have to justify the request by providing information on how and for what the requested ports and services will be used for. From Admin Network to DMZ (2) No direct access. There will be no services or ports available for traffic flow directly from admin network to the DMZ (2). If a system in the admin network needs to connect to a system in the DMZ (2), it will have to leave the perimeter firewall and re-enter as if coming from the internet. From DMZ (2) to Admin network No direct access. There will be no services or ports available for traffic flow from admin network to the DMZ (2). If a system in the DMZ (2) needs to connect to a system in the admin network, it will have to leave the perimeter firewall and re-enter as if coming from the internet. It will also have to conform to the firewall rules set by the firewall protecting the admin network. From DMZ (1) to DMZ (2) No direct access. There should be no services or ports available for traffic flow from admin network to the DMZ (2). If a system in the DMZ (1) needs to connect to a system in the DMZ (2), it will have to leave the perimeter firewall and re-enter as if coming from the internet From DMZ (2) to DMZ (1) No direct access. There should be no services or ports available for traffic flow from admin network to the DMZ (2). 5

If a system in the DMZ (2) needs to connect to a system in the DMZ (1), it will have to leave the perimeter firewall and re-enter as if coming from the internet. It will also have to conform to all inbound firewall rules. Physical access to all systems in the secondary DMZ Physical access to systems in the secondary DMZ is limited. System owners for servers in the secondary DMZ will have escorted physical access. Requests will have to be made in advance for gaining physical access. System owners will have to provide IT in advance a list of users who manage servers and who may need escorted access to the servers. Monitoring and violations: Data owners agree and understand that all systems and services within BSU infrastructure are monitored both actively and passively. This is required to maintain security of BSU infrastructure and for compliance purposes. All systems must be patched and must have Anti Virus installed with the latest updates. They must have internal firewalls (Windows server 2003 and later) turned on. All applications installed on these systems must also be patched with the latest updates that are made available by respective vendors. If systems are found to be lacking the latest application and OS level patches and AV updates then those systems will be quarantined or taken offline until the required patches and AV have been installed. Local accounts with default access credentials (username and password) are prohibited. IT reserves the right to power off or disable access to a system or server if found to be in violation of the acceptable use policy is detected. If a violation is detected due to necessary patches not being applied, a forty eight hour notice will be provided prior to disabling access or shutting a service off. However, immediate action will be taken if the malicious activity is detected. However, this is not guaranteed in some cases where we see malicious activity. The server (s) may be turned off and all services terminated if any incident or chances for the occurrence of an incident are detected. An incident is defined as harm or intent to cause harm to the interests of the institution or the institution s infrastructure. The owner will be notified after these actions have been completed. There is an appeal process for services to be re-instated. Service Level Agreement: I agree to perform the following functions to maintain the integrity of the servers in the secondary DMZ: 1) to comply with the University s Acceptable User Policy 2) to comply with the University s Confidential Data policy 3) to patch the OS on these servers on time, latest by the second Friday of every month 4) to make sure that all applications installed are patched up-to-date 5) make sure that there is a host based firewall installed and enabled 6) make sure anti-virus installed, enabled and up-to-date with the latest definitions 7) make sure that no confidential data, as defined by the Data Classification standard is stored and or used on servers in the secondary DMZ 6

8) be responsible for maintaining and administering the servers in secondary DMZ as listed below including but not limited to backing up, restoring and any and all other modifications to the servers 9) that I will have to submit a request to IT to open ports and services at the firewall, each time I need a change or need a new service I am also aware that IT will monitor network activity in the secondary DMZ and IT has the right to shutdown servers and services if it detects any malicious activity. I will fully cooperate with IT in case there is an investigation. By signing below I take full responsibility of the content and usage of the servers I manage in the secondary DMZ. I also acknowledge that I have read the Secondary DMZ document and agree to abide by the rules mentioned herein. I also release IT of any responsibility towards the maintenance and functioning of the systems mentioned below: Server Names: 1) NAME in DMZ(2B) (Signature) Printed Name: Date: 7