Copyright Systech Information Technology Ltd - Assignment Example

SYSTECH Security Policy of the of the Copyright Systech Information Technology Ltd. Security today is the bottom line mechanism that is an absolute essential for the success and continuity of any computer or information technology related firm. In an age when most of our personal information has become public or lies behind an encryption program that may be its only line of defense in addition to a group of firewalls, it has become all the more necessary for any company worth its name to make foolproof and secure measures to ensure that sensitive corporate, business or personal information always remains protected. The following document outlines a total of 8 policies that have been considered most important by the Computer Security Program Manager of SYSTECH. 1. Networking and Router Security Policy Purpose This policy indicates the required minimal security configuration for all routers and switches connecting to a production network or used in production capacity at or on behalf of Systech. Scope All routers and switches connected to Systech production networks are covered. Routers and switches within internal, secured labs are not covered. (Routers and switches within DMZ areas fall under the Internet DMZ Equipment Policy). Policy Every router must meet the following configuration standards: 1. No local user accounts are configured on the router. Routers must use TACACS+ for all user authentication. 2. The enable password on the router must be kept in a secure encrypted form. Reversible encryption algorithms, such as the Cisco type 7 are unacceptable. The router must have the enable password set to the current production router password from the routers support organization. 3. The following services or features must be disabled: a. IP directed broadcasts b. TCP small services c. UDP small services d. All source routing e. All web services running on router f. Auto-configuration 4. The following services should be disabled unless a business need is provided: a. Cisco discovery protocol and other discovery protocols b. Dynamic Trunking c. Scripting environments, such as the TCL shell 5. The following services must be configured: a. Password-encryption b. NTP configured to a corporate standard source 6. Use corporate standardized SNMP community strings. Default strings, such as public or private must be removed. SNMP must be configured to use the most secure version of the protocol allowed for by the combination of the device and management systems. 7. Access control lists must be used to limit the source and type of traffic that can terminate on the device itself. 8. Access control lists for transiting the device are to be added as business needs arise. 9. The router must be included in the corporate enterprise management system with a designated point of contact (Cisco, 2005). 10. Each router must have the following statement presented for all forms of login whether remote or local: "UNAUTHORIZED ACCESS TO THIS NETWORK DEVICE IS PROHIBITED. You must have explicit permission to access or configure this device. All activities performed on this device may be logged, and violations of this policy may result in disciplinary action, and may be reported to law enforcement. There is no right to privacy on this device. Use of this system shall constitute consent to monitoring." 11. Telnet may never be used across any network to manage a router, unless there is a secure tunnel protecting the entire communication path. SSH version 2 is the preferred management protocol. 12. Dynamic routing protocols must use authentication in routing updates sent to neighbors. Password hashing for the authentication string must be enabled when supported. 13. A corporate standard will be created and reviewed at least annually to define items required but not defined in this policy, such as NTP servers. 14. The corporate router configuration standard will define the category of sensitive routing and switching devices, and require additional services or configuration on sensitive devices including: a. IP access list accounting b. Device logging c. Incoming packets at the router sourced with invalid addresses, such as RFC1918 addresses, or those that could be used to spoof network traffic shall be dropped d. Router console and modem access must be restricted by additional security controls Enforcement Employees found to have violated this policy will be subject to disciplinary action up to and including termination of employment (Sans Institute, 2006). 2. Disaster Recovery Policy Overview It is seen that management often ignores the disaster recovery planning process. Having a contingency plan in the event of a disaster gives Systech a competitive advantage. The policy requires management to financially support and diligently look at disaster contingency planning efforts. Disasters may not be limited to adverse weather conditions, but any event that could likely cause an extended delay of service should be considered a problem. Purpose This policy defines the need for management to support ongoing disaster planning for Systech. Scope This policy applies to the management and technical staff of Systech. Policy Contingency Plans The following contingency plans will need to be created by Systech: 1. Computer Emergency Response Plan: Relates to who is to be contacted, when, and how? What immediate action must be taken in the event of certain occurrences? 2. Succession Plan: This describes the flow of responsibility when normal staff is unavailable to perform their duties. 3. Data Study: Detail the data stored on the systems, its criticality, and its confidentiality. 4. Critical Service List: This lists all the services provided and their order of importance. It also explains the order of recovery in both short-term and long-term timeframes. 5. Data Backup and Restoration Plan: Details which data is to be backed up, the media to which it is saved, where that media is stored, and how often the backup is done. It should also describe how that data could be recovered. 6. Equipment Replacement Plan: Describe what equipment is required to begin to provide services, list the order in which it is necessary, and note where to purchase the equipment. 7. Mass Media Management: Who is in charge of giving information to the mass media? It will also provide some guidelines on what data is appropriate to be provided. Action Plan After creating the plans, it is important to practice them to the extent possible. Management should set aside time to test implementation of the disaster plan. During these tests, issues that may cause the plan to fail can be discovered and corrected in an environment that has few consequences (Sans Institute, 2006). Review/Update We will review all plans annually so changes in Systech’s situation can be incorporated. Enforcement Any employee that violates this policy may be subject to disciplinary action up to and including termination of employment. 3. Server Security Policy Purpose The purpose of this policy is to establish standards for the base configuration of internal server equipment that is owned and/or operated by Systech. Effective implementation of this policy will minimize unauthorized access to Systech proprietary information and technology. Scope The policy applies to server equipment owned and/or operated by Systech and to servers registered under any Systech-owned internal network domain. The policy is specifically for equipment on the internal Systech network. (For secure configuration of equipment external to Systech on the DMZ, refer to the Internet DMZ Equipment Policy). Policy Ownership and Responsibilities All internal servers deployed at Systech must be owned by an operational group that is responsible for system administration. Approved server configuration guides must be established and maintained by each operational group, based on business needs and approved by GDI. Operational groups should monitor configuration compliance and implement an exception policy tailored to their environment. Each operational group must establish a process for changing the configuration guides, which includes review and approval by GDI. Servers must be registered within the corporate enterprise management system. Configuration changes for production servers must follow the appropriate change management procedures. General Configuration Guidelines Operating System configuration should be in accordance with approved GDI guidelines. Services and applications that will not be used must be disabled where practical. Access to services should be logged and/or protected through access-control methods such as TCP Wrappers, if possible. The most recent security patches must be installed on the system as soon as practical, the only exception being when immediate application would interfere with business requirements. Trust relationships between systems are a security risk, and their use should be avoided. Do not use a trust relationship when some other method of communication will do. Always use standard security principles of least required access to perform a function. Do not use root account when a non-privileged account will do. If a methodology for secure channel connection is available (technically feasible), privileged access must be performed over secure channels, (e.g., encrypted network connections using SSH or IPSec). Servers should be physically located in an access-controlled environment. Servers are specifically prohibited from operating from uncontrolled cubicle areas. Monitoring All security-related events on critical or sensitive systems must be logged and audit trails saved as follows: All security related logs will be kept online for a minimum of 1 week. Daily incremental tape backups will be retained for at least 1 month. Weekly full tape backups of logs will be retained for at least 1 month. Monthly full backups will be retained for a minimum of 2 years. Security-related events will be reported to GDI, who will review logs and report incidents to IT management. Corrective measures will be prescribed as needed. Security-related events include, but are not limited to: Port-scan attacks Evidence of unauthorized access to privileged accounts Anomalous occurrences that are not related to specific applications on the host. 4. Internet DMZ Security Policy Purpose The purpose of the DMZ Internet Security policy is to define standards to be met by all equipment owned and/or operated by Systech located outside its corporate Internet firewalls. The standards are designed to minimize the potential exposure to Systech from the loss of sensitive or company confidential data, intellectual property, damage to public image etc., which may follow from unauthorized use of Systech resources. Devices that are Internet facing and outside the Systech firewall are considered part of the demilitarized zone (DMZ) and are subject to this policy. These devices (network or host) are particularly vulnerable to attack from the Internet when they reside outside the corporate firewalls. Scope All equipment or devices deployed in a DMZ owned and/or operated by Systech (including hosts, routers, switches, etc.) and/or registered in any Domain Name System (DNS) domain owned by Systech Any host device outsourced or hosted at external/third-party service providers if that equipment resides in the "Systech.com" domain or appears to be owned by Systech. All new equipment which falls under the scope of this policy Policy Ownership and Responsibilities Network interfaces must have appropriate Domain Name Server records (minimum of A and PTR records). Password groups must be maintained in accordance with the corporate wide password management system/process. Immediate access to equipment and system logs must be granted to members of GDI upon demand, per the Audit Policy. Changes to existing equipment and deployment of new equipment must follow and corporate governess or change management processes/procedures. To verify compliance with this policy, Systech will periodically audit GDI per its Audit Policy. General Configuration Policy Hardware, operating systems, services and applications must be approved by GDI as part of the pre-deployment review phase. Operating system configuration must be done according to the secure host and router installation and configuration standards All patches/hot-fixes recommended by the equipment vendor and GDI must be installed. This applies to all services installed, even though those services may be temporarily or permanently disabled. Administrative owner groups must have processes in place to stay current on appropriate patches/hotfixes. Services and applications not serving business requirements must be disabled. Services and applications not for general access must be restricted by access control lists. Remote administration must be performed over secure channels (e.g., encrypted network connections using SSH or IPSEC) or console access independent from the DMZ networks. Where a methodology for secure channel connections is not available, one-time passwords (DES/SofToken) must be used for all access levels. All host content updates must occur over secure channels. 5. Remote Access Tools Security Policy Overview Remote desktop software or remote access tools usually provide a way for computer users and support staff to share screens, access work computer systems from home etc. Examples of such software are VNC (Virtual Network Computing), GoToMyPC and Windows Remote Desktop (RDP).  While these tools can save significant time and money by eliminating travel and enabling collaboration, they also provide a back door into the Systech network that can be used for theft of, unauthorized access to, or destruction of assets. As a result, only monitored, approved and properly controlled remote access tools may be used on Systech computer systems. Purpose This policy defines the requirements for remote access tools used at Systech. Scope This policy applies to all remote access where either end of the communication terminates at a Systech computer device. Policy All remote access tools used to communicate between Systech assets and other systems must comply with the following policy requirements. Remote Access Tools 1. Systech provides mechanisms to collaborate between internal users, with external partners, and from non-Systech systems. The approved software list can be obtained from authorized persons. Because proper configuration is important for secure use of these tools, mandatory configuration procedures are provided for each of the approved tools. 2. The approved software list may change at any time, but the following requirements will be used for selecting approved products: a) All remote access tools or systems that allow communication to Systech resources from the Internet or external partner systems must require multi-factor authentication. Examples include authentication tokens and smart cards that require an additional PIN or password. b) The authentication database source must be Active Directory or LDAP, and the authentication protocol must involve a challenge-response protocol that is not susceptible to replay attacks. The remote access tool must mutually authenticate both ends of the session. c) Remote access tools must support the Systech application layer proxy rather than direct connections through the perimeter firewall(s). d) Remote access tools must support strong, end-to-end encryption of the remote access communication channels as specified in the Systech network encryption protocols policy. e) All Systech data loss prevention, antivirus and other security systems must not be disabled, interfered with, or circumvented in any way. 3. All remote access tools must be purchased through the standard Systech procurement process, and the information technology group must approve the purchase. Ramifications for Systech Failure to use secure, supported remote access tools may expose Systech to computer intrusion activity and could lead to loss of intellectual property, revenue, and/or reputation. It is the responsibility of each employee to protect the interests of Systech while utilizing Systech assets and information. Enforcement Any employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment. Planned malicious activity involving theft or damage of intellectual property will be liable to criminal prosecution. 6. Lab Anti-Virus Policy Purpose To establish requirements which must be met by all computers connected to Systech lab networks to ensure effective virus detection and prevention. Scope This policy applies to all Systech lab computers that are PC-based or utilize PC-file directory sharing. This includes, but is not limited to, desktop computers, laptop computers, file/ftp/tftp/proxy servers, and any PC based lab equipment such as traffic generators. Policy All Systech PC-based lab computers must have Systechs standard, supported anti-virus software installed and scheduled to run at regular intervals. In addition, the anti-virus software and the virus pattern files must be kept up-to-date. Virus-infected computers must be removed from the network until they are verified as virus-free. Lab Admin/Lab Managers are responsible for creating procedures that ensure anti-virus software is run at regular intervals, and computers are verified as virus-free. Any activities with the intention to create and/or distribute malicious programs into Systechs networks (e.g., viruses, worms, Trojan horses, e-mail bombs, etc.) are prohibited. Enforcement Any employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment. 7. Physical Security Policy Purpose The purpose of this policy document is to provide guidance for related administration and visitors to Systech premises, as well as dealing with employee relatives and friends coming to Systech for any purpose. Breach of security almost always involves some sort of physical breach, where a person and/ or equipment has been used to temporarily or permanently disable or malfunction security measures in place. Cancellation or Expiration This document is reviewed and updated on annual basis. Background Systech is an information technology data mining, warehousing and processing company, delivering quality information and secured data to its customers. Systech has a significant investment in Intellectual Property. Its warehousing facilities have areas that could be considered hazardous to untrained or unequipped personnel. This document provides the policy to protect both our visitors and the company, while still maintaining the goals of community education and participation. Scope This policy applies to all visitors to any premises of Systech and to employees who sponsor such visitors. Policy Statement Parking All visitors are expected to use designated parking spots. If all visitor parking spots have been used up, regular employee parking spots may be used. Check-In All visitors must access the premises through designated check-in entrance points or the main reception desk if available. All visitors must present Government-issued photo identification at checking in time. All visitors must be met by their sponsor at checking in time. No visitor may sponsor any other. Pets are strictly prohibited permitted, except for Seeing Eye Dogs for the blind. In these cases prior and proper arrangements must be made. Areas of work are not appropriate for animals under any circumstances. Visitors must read the Visitor Policy Rules posted at the gate or inside the main entrance of most access points. Visitors are required to read this before entering the premises and keep some relevant ID with them at all times. Visitors will be required to comply with Emergency Evacuation and Exit Inspection Plans as per company policy. All visitor electronics (laptops, other computer equipment, cell phones, etc.) will be checked in and out. Visitor Identification Visitor Badges must be worn at all times. Employees must immediately report anyone not wearing a visitor or employee badge. Visitors requiring access to areas controlled by swipe card access locks should arrange temporary cards with their sponsor. Departments that have swipe card access locks in their area must allow access only with the help of staff (Sans Institute, 2006). Photographs and Cameras Under no circumstances will any visitor be allowed to take photographs inside of Systech premises, unless discussed specifically with higher management. Photographs may sometimes be required for documentation purposes. In this case the sponsoring employees of the visitors should consult the Human Resources Department. Check-Out/ Exit All visitors and related equipment/luggage will usually check out at the same station where they arrived. 8. Warehousing and Information Security Policy Administrative and customer data captured and maintained at Systech are a valuable company resource. The data warehouse contains integrated data from multiple operational areas to support institutional research, business analysis, reporting, budget planning, personnel planning, and decision-making. The purpose of this policy is to establish uniform data management standards and to identify the shared responsibilities for assuring that the data warehouse provides security, protects privacy and has integrity while it efficiently and effectively serves the needs of Systech and its customers. Policy Statement Access to administrative information will be provided to employees for the support of their work functions. The breadth and depth of access is determined by the role of the individual and may be contingent upon training about applicable data policies and responsibilities. Security and privacy will be prioritized over access. Guiding Principles for Data Access, Security, and Privacy The overriding goal in Systech’s data management policy is to strike a balance among data access, data security and privacy. The value of data as a company resource is increased through its widespread and appropriate use; however, its value is diminished if misinterpreted, misused, or abused. Access can be expanded as needed, but privacy breaches can seldom be repaired and security once violated, can compromise the financial integrity, reputation, functionality, and stability of the company (Edwards & Lumpkin, 2005). As an institution with a mission to create and apply knowledge, Systech values accessibility to and the timeliness and accuracy of information while fully appreciating the basic security and privacy requirements involved. However, dissemination of company warehoused and maintained data should not be confused with dissemination of information and knowledge used to manage and operate the company. This latter class of operational data and information should be readily available within the company. Therefore, permission to view or query data contained in the Data warehouse should be granted to data users for legitimate purposes. Access for updating should be restricted as necessary, but granted to company employees at the location where data are initially received or originated whenever this is feasible. Information specifically protected by law or regulation or company policy must be rigorously protected from inappropriate access. However, as opportunities and requirements increase, access permissions must be able to adapt to new circumstances as authorized by appropriate company officials. All data warehouse information is derived from official records and is considered an official authoritative source of company data. Responsibility for the Data Policy is vested with the Company President who will rely on the recommendations of the Information Technology Executive Committee (ITEC) for most data related decisions. Both software and hardware resources need to be protected from viruses and other kinds of malware, brute force attacks, unauthorized access and related attacks that can sabotage the validity and reliability of its information and data. A combination of physical and administrative deterrents is in place to meet this end. References Cisco Corporation (2005). Network Security White Paper-Best Practices. Accessed on 28 Feb 2014 at www.cisco.com/c/en/us/support/docs/availability/.../13601-secpol.html‎ Edwards, K, B. & Lumpkin, G.(2005). Security and the Data Warehouse. Accessed on 28 Feb 2014 at http://www.oracle.com/technetwork/middleware/bi-foundation/twp-bi-dw-security-10gr1-0405-128087.pdf The Sans Institute (2006). Lab Antivirus Policy. Accessed on 28 Feb 2014 at http://www.sans.org/security-resources/policies/ The Sans Institute (2006). Physical Security Policy. Accessed on 28 Feb 2014 at http://www.sans.org/security-resources/policies/ The Sans Institute (2006). Disaster Recovery Policy. Accessed on 28 Feb 2014 at http://www.sans.org/security-resources/policies/ Read More