IT SECURITY POLICY SAMPLE

No Comment Yet

IT SECURITY POLICY

Department: IT          

Document Number: ABCD-POL-0005-00

Prepared By:

Document Owner(s)Project/Organization Role
abcdIT Manager
  
  

File Status Report Version Control

RevisionDateAuthorChange Description
0Jun 18, 2021abcdDocument created
    
    

PURPOSE

The following policy has as main purpose to establish standards on protection and use of IT assets and resources within the company to ensure integrity, confidentiality and availability of data and assets.

SCOPE

The following policy is applied to factories, workhouses, facilities, stores and every working place set as such by YOUR COMPANY NAME.

RESPONSIBLE

The responsible for the effective execution of this procedure are the IT Administrators and company users.

POLICY ACCEPTANCE

  1. The following policy is mandatory and requires strict adherence to its rules and statements. Any infraction thereof could result in disciplinary action(s), which may range from verbal warnings to termination as per company’s policy on the severity of the misbehavior.

  2. It is understood by the users that even where cyber security measures have been implemented by IT department to protect all IT assets, they shall remain vigilant and act on the best interest of the company, by timely informing IT department in order to take corrective measures.

    IT SECURITY POLICY

Physical Security

  1. All servers, mainframes and other network assets must be secured and restricted to IT staff only.

  2. Users are responsible to ensure the asset is kept safely at all times.

  3. Users’ personal equipment (PCs, laptops, mobiles, etc) is not allowed to be used for corporative purposes and subject on punishment as per violation; exceptions are only accepted upon Top management explicit and written communication (email, request form, etc)
  • In the event of loss or damage of a company’s IT asset(s), the following rules shall be followed:
  1. Department or user responsible of the asset(s). shall immediately notify IT department and provide all relevant Information relating to the incident.

    1. IT department is solely responsible of performing an assessment and determine if the department or user responsible will be required to cover the repairing or replacement costs associated with the asset(s).
  • All IT assets under IT department custody shall be secured by keeping under lock in cabinets, rooms or any other space managed by the department.

  • Users are responsible for exercising good judgment regarding the reasonableness of personal use.

  • Users should take all necessary steps to prevent unauthorized access to confidential data in their assigned IT assets. Example: PCs, laptops, mobiles, etc.

  • If out of company’s premises, users shall ensure that IT assets under their custody are used and setup in secured network locations.

Information Security

  1. All relevant data shall be backed up and kept in data storages as per IT department’s backup policy.

  2. All PCs and laptops assigned to users shall have the official anti-virus software managed by IT Department and ensure that this software remains up to date.
  • All information managed by users, shall be considered company’s property and be handled as per company’s privacy and confidentiality requirements. Any employee breaching this will be penalized as per company’s assessment.

Users and Password Security

Users and Password Security as well as all other Access related scope is covered by the company’s Users and Password Security policy (ABCD-POL-0004-00).

Internet and Email Security

Internet and Email Security as well as usage is covered by the company’s Users and Email Usage policy (ABCD-POL-0002-00).

Software Security

  1. All software owned by the company shall be secured by keeping under lock in cabinets, rooms or any other space managed by the department
  2. License keys, serial numbers and any other information must be registered on the {insert where these records are to be kept}. It is the responsibility of {insert relevant job title here} to ensure that this registered is maintained. The register must record the following information:

•           What software is installed on every machine

•           What licence agreements are in place for each software package

•           Renewal dates if applicable.

{insert relevant job title here} is responsible for the maintenance and management of all service agreements for the business technology. Any service requirements must first be approved by {insert relevant job title here}.

{insert relevant job title here} is responsible for maintaining adequate technology spare parts and other requirements including {insert specific technology requirements here, such as toners, printing paper etc.}

A technology audit is to be conducted {insert frequency here e.g. annually} by {insert relevant job title here} to ensure that all information technology policies are being adhered to.

Any unspecified technology administration requirements should be directed to {insert relevant job title here}

Network Security

6.12.     Physical & Environmental Security

6.13.     Responsible departments (ICT for the core ICT network) will maintain up to date network diagrams (both logical and physical) that define the network topology, ‘boundaries’, IP addresses, core network equipment etc for all networks that they are responsible.

6.14.     Core network computer equipment will be housed in controlled and secure environments. 

6.15.     Critical or sensitive network equipment will be protected by a secure perimeter, with appropriate security barriers and entry controls (including intruder alarms), fire suppression systems and in an environment that is monitored for temperature, humidity and power supply quality. Such protection will normally be for the whole room; where this is not possible protection for individual equipment should be provided.

6.16.     Entry to secure areas housing critical or sensitive network equipment will be restricted to those whose job requires it.  The ICT security team will maintain and periodically review a list of those with unsupervised access to core Trust network/computer rooms.  Detailed lists of those with approved access will be displayed at the entrances to such areas.

6.17.     The ICT security team are responsible for ensuring that door lock codes for core Trust computer/network rooms are changed periodically, following a compromise of the code, if they suspect the code has been compromised. 

6.18.     Where servers are housed in non-ICT controlled/operated computer rooms such controls as described in 6.16 and 6.17 are to be exercised by the individual responsible for supporting such equipment(s).

6.19.     Smoking, eating and drinking is forbidden in areas housing critical or sensitive network equipment.

6.20.     All visitors to areas housing core critical or sensitive network equipment must be authorised by the ICT security team and must be made aware of network security requirements.  All visitors to these areas must be logged in and out.  The log will contain name, organisation, purpose of visit, date, and time in and out.  Visitors to rooms/areas that contain ICT switches and hubs are to be controlled by the ICT network team.   Responsible staff are to ensure that all relevant are made aware of procedures for visitors and that visitors are escorted, when necessary.

6.21.     Access Control to the Network

6.22.     Access to the network resources will be via a secure log-on procedure, designed to minimise the opportunity for unauthorised access.  Remote access to the network will conform to the Trust’s Remote Access Policy.

6.23.     There will be a formal, documented user registration and de-registration procedure for access to the network/resouces.

6.24.     Departmental line managers and the ICT service desk must approve user access in accordance with this policy and relevant local guidance/process. 

6.25.     Access rights to the network will be allocated on the requirements of the user’s role, rather than on a status basis.

6.26.     Security privileges (i.e. ‘superuser’ or network administrator rights) to the network will be allocated on the requirements of the user’s role, rather than on a status basis (detailed local guidance for the ICT department is produced by the ICT security team).

6.27.     Access will not be granted until the ICT service desk registers a user.  All users on the network will have their own individual user identification and password.

6.28.     Users are responsible for ensuring their password is kept secret (see User Responsibilities).

6.29.     User access rights will be immediately removed or reviewed for those users who have left the Trust or changed roles; line managers must report all such occurrences to the ICT department promptly.

6.30.     Connecting Equipment or Providing New Services to the Network

6.31.     No equipment is to be connected to any ICT network without the approval of those that manage/operate the ICT network concerned.  Where new equipment or services are to be hosted on the network appropriate Risk Assessments (as outlined in section 6.8) are to be conducted prior to any such connection.

6.32.     Wired Connection and Connection Points

In principle all network points are to be disabled unless they are actually in use or enabled to allow approved equipment to connected in the near term.  Where areas are to be left unoccupied for periods in excess of a few days then network connectivity to the particular area is to be disabled until it is to be occupied again.

6.33.     Wireless Connection and Wireless Access Point

New wireless connections should always be implemented with approved protocols and relevant security standards as defined by the ICT department.  Where Trust devices are permitted to access wireless networks rather than wired networks they are to be controlled in the same way that wired connections are.

6.34.     Where ‘guest’ wireless services are offered on Trust premises devices provided by the Trust are not permitted to make use of them and should be configured to prevent these users from ‘joining’ guset networks.

6.35.     ‘Guest’ devices/services should always have appropriate controls configured to ensure proper separation of  ‘business’ and ‘non-business’ data.  Where provided these services are to maintain appropriate control of access to all resources and sufficient records to provide evidence of usage.

6.36.     Security Standards for Wired or Wireless Devices

The ICT department are to maintain seperate security (build) standards for all devices they are responsible for.  These standards are to be applied to all equipments permitted to access the Trust network(s) whomever supports the equipment.

6.37.     Where appropriate the ICT department are to implement appropriate technical measures to provide Network Access Control on the Trust network.

6.38.     Third Party Access Control to the Network

6.39.     Third party access to the ICT network(s) will be based on a formal contract and a separate Memorandum of Understanding (MoU) that both governs access and satisfies necessary NHS security conditions.

6.40.     All third party access to the network must be logged, either as an individual one-off access or for more regular access in support of hosted applications/equipment.  In the case of the later a register of such access is to be kept detailing the nature of the access.

6.41.     Third party access is to be strictly limited to the equipment and functionality required to provide the contracted support required.

6.42.     External Network Connections

6.43.     All external connections to the core Trust ICT network(s) are to be mediated by appropriate access controls that protect against unauthorised or inappropriate access to the network and/or resources hosted on it.  Such mediation will also control access and scan all authorised traffic via appropriate technical measures in order to protect the hosted resources.

6.44.     Where external ‘connections’ are considered to be ‘trusted’ such as in Micosoft’s Active Directory Trusted Domains then the ‘scope’ of the approved trust and valid security assumptions on which Risk Assessments are based are to be documented in a Code of Connection (CoCo) between the relevant system/network ‘owners/stakeholders’ of all affected organisations.  All new such connections are to be risk assessed prior to connection to ensure that they do not invalidate previous risk assessments on which controls and/or countermeasures are based.

6.45.     All connections to external networks and systems have documented and approved System Security Policies.

6.46.     Ensure that all connections to external networks and systems conform to the NHS-wide Network Security Policy, Statement of Compliance/Code of Connection and supporting guidance.

6.47.     In principle unsolicited network ‘traffic’ (excluding email traffic or approved 3rd party support access) that originates from outside the network boundaries should not be permitted to directly enter the internal network either to transit or to terminate.  Appropriate technical measures should be implemented to ensure adequate separation of internal and external ‘traffic’.

6.48.     The IT security team must approve all connections to external networks and systems before they commence operation.

6.49.     Maintenance Contracts

6.50.     The ICT department will ensure that appropriate maintenance contracts are maintained and periodically reviewed for all core network equipment.  All contract details will constitute part of the ICT departments Information Asset register.

6.51.     Data and Software Exchange

6.52.     Formal agreements for the exchange of data and software between organisations must be established and approved by the relevant Information Asset Owner in consultation with the SIRO/Information Governance Manager/ICT security team.

6.53.     Fault Logging

6.54.     The ICT department is responsible for ensuring that a log of all faults on the core ICT network is maintained and reviewed.  A written procedure to report faults and review countermeasures will be produced.

6.55.     Security Operating Procedures (SyOps)

6.56.     Systems owners are required to produce Security Operating Procedures (SyOps) and security contingency plans that reflect the Network Security Policy.

6.57.     Changes to operating procedures must be authorised by the IT security team.

6.58.     Network Operating Procedures

6.59.     Documented operating procedures will be prepared for the operation of the network, to ensure its correct, secure operation.

6.60.     Changes to operating procedures must be authorised by the ICT department Technical Services Manager.

6.61.     Data Backup and Restoration

6.62.     The ICT departments’ Technical Services Manager is responsible for ensuring that backup copies of all data including the network configuration are taken regularly in accordance with ICT local procedures and relevant SLAs such that services and data can be restored in accordance with requirements.

6.63.     Documented procedures for the backup process and storage of backup tapes will be produced and communicated to all relevant staff.

6.64.     All backup tapes will be stored securely and a copy will be stored in a separate location to the systems they originate from, preferably off-site but where this is not possible in a location that is a ‘safe’ distance from the originating systems themselves.

6.65.     Where on line backups have been implemented in place of backuip tapes then similar separation between originating and backup locations must be implemented; under no cuircumstances are backups and original data to be kept in the same physical location(s).

6.66.     Documented procedures for the safe and secure disposal of backup media will be produced and communicated to all relevant staff.

6.67.     Users are responsible for ensuring that they save data to appropriate network shares where it is to be subject to centrally managed backup processes.

6.68.     User Responsibilities, Awareness & Training

6.69.     The Trust will ensure that all users of the network are provided with the necessary security guidance, awareness and where appropriate training to discharge their security responsibilities.

6.70.     All users of the ICT network must be made aware of the contents and implications of relevant IT Security Policies and specific SyOps.

6.71.     Irresponsible or improper actions by users may result in disciplinary action(s).

6.72.     Accreditation of Network Systems

6.73.     Ensure that the ICT network is approved by the SIRO/Information Asset Owner before it commences operation.  In this role the IT security team will support the SIRO/IAO. The IT security team is responsible for ensuring that the core ICT network does not pose an unacceptable security risk to the organisation. 

6.74.     Security Standards and Security Audits

6.75.     Wherever possible use should always be made of secure IT protocols over insecure legacy protocals ie Secure Shell (SSH) rather than ‘Telnet’, Secure File Transfer Protocol (SFTP instead of File Transfer Protocol (FTP) where this may not be possible then a risk assessment is to be conducted and documented. 

6.76.     The SIRO/IAO and/or the IT security team will require checks on, or an audit of, actual implementations based on approved security policies.

4.1 ANTI-VIRUS

All servers MUST have an anti-virus application installed that offers real-time scanning protection to files and applications running on the target system if they meet one or more of the following conditions:

•           Non-administrative users have remote access capability

•           The system is a file server

•           NBT/Microsoft Share access is open to this server from systems used by non-administrative users

•           HTTP/FTP access is open from the Internet

•           Other “risky” protocols/applications are available to this system from the Internet at the discretion of the <Company Name> Security Administrator

All servers SHOULD have an anti-virus application installed that offers real-time scanning protection to files and applications running on the target system if they meet one or more of the following conditions:

•           Outbound web access is available from the system

4.2 MAIL SERVER ANTI-VIRUS

If the target system is a mail server it MUST have either an external or internal anti-virus scanning application that scans all mail destined to and from the mail server. Local anti-virus scanning applications MAY be disabled during backups if an external anti-virus application still scans inbound emails while the backup is being performed.

4.3 ANTI-SPYWARE

All servers MUST have an anti-spyware application installed that offers real-time protection to the target system if they meet one or more of the following conditions:

•           Any system where non-technical or non-administrative users have remote access to the system and ANY outbound access is permitted to the Internet

•           Any system where non-technical or non-administrative users have the ability to install software on their own

4.4 NOTABLE EXCEPTIONS

An exception to the above standards will generally be granted with minimal resistance and documentation if one of the following notable conditions apply to this system:

•           The system is a SQL server

•           The system is used as a dedicated mail server

•           The system is not a Windows based platform

6.77.     Malicious Software

6.78.     For ‘core’ systems the Trust ICT department will ensure that measures are in place to detect and protect the network from viruses and other malicious software.  For non ‘core’ systems then the system owner is to ensure that this is implemented.

6.79.     Secure Disposal or Re-use of Equipment

6.80.     ICT department staff must ensure that where equipment is being disposed of all data on the equipment (e.g. on hard disks or tapes) is securely overwritten.  Where this is not possible ICT Department staff should physically destroy the disk or tape.  ICT department staff are to comply with the local procedures that cover this activity.  Where the ICT department are not responsible for ICT equipment then their advice is always to be sought before disposal or re-use is considered.

6.81.     System owners are to ensure that where disks are to be removed from the premises for repair, where possible, the data is securely overwritten or the equipment de-gaussed by the IT Department.  Where disks have been installed in any RAID configuration other than RAID1 then providing no more than one disk is sent for repair at the same time then this requirement can be

6.82.     System Change Control

6.83.     System owners are to ensure that the IT security team review and approve all changes to the network to ensure that the security of the ICT network is maintained.  The ICT departments’ Technical Services Manager is responsible for updating all relevant Network Security Policies, design documentation, security operating procedures and network operating procedures.

6.84.     The SIRO/IAO/IT security team may require checks on, or an assessment of the actual implementation based on the proposed changes.

6.85.     The IT security team is responsible for ensuring that selected hardware or software meets agreed security standards in accordance with appropriate national guidelines.

6.86.     As part of acceptance testing of all new network systems, the ICT department will attempt to cause a security failure and document other criteria against which tests will be undertaken prior to formal acceptance.

6.87.     Testing facilities will be used for all new network systems.  Development and operational facilities will be separated.

6.88.     Security Monitoring

6.89.     Ensure that the network is monitored for potential security breaches.   All monitoring will comply with current legislation.

6.90.     Reporting Security Incidents & Weaknesses

6.91.     All potential security breaches on the ICT networks must be reported to the IT security team who will investigate as appropriate.  Security incidents and weaknesses must be reported in accordance with the requirements of the organisation’s incident reporting procedure.

6.92.     System Configuration Management

6.93.     Ensure that there is an effective configuration management system for the ICT network.

6.94.     Business Continuity & Disaster Recovery Plans

6.95.     Ensure that business continuity plans and disaster recovery plans are produced for the ICT network.

6.96.     The plans must be reviewed by the ICT departments’ Technical Services Manager and tested on a regular basis.

6.97.     Unattended Equipment and Clear Screen

6.98.     Users must ensure that they protect the network from unauthorised access.  They must log off the network when finished working.

6.99.     The Trust operates a clear screen policy that means that users must ensure that any equipment logged on to the network must be protected if they leave it unattended, even for a short time. Workstations must be locked or a screensaver password activated if a workstation is left unattended for a short time.

6.100.   Users failing to comply will be subject to disciplinary action

Data Security

You must not turn off or attempt to circumvent any security measures (antivirus software, firewalls, web filtering, encryption, automatic updates etc.) that the IT team have installed on your computer, phone or network or the company IT systems.

3.3        You must report any security breach, suspicious activity, or mistake you make that may cause a cyber security breach, to [name, role] by [contact method] within [number] minutes of the discovery or occurrence.

3.4        You must only access work systems using computers or phones that the company owns. [You may only connect personal devices to the [public] OR [visitor] Wi-Fi provided in [location].]

3.5        You must not install software onto your company computer or phone[. All software requests should be made to [name, role]].

3.6        You should avoid clicking on links to unknown websites, downloading large files, or accessing inappropriate content using company equipment or networks.

4.         Consequences of system misuse

4.1        The company considers the following actions to be a misuse of its IT systems or resources:

(a)        any malicious or illegal action carried out against the company or using the company’s systems;

(b)        accessing inappropriate, adult or illegal content within company premises or using company equipment;

(c)        excessive personal use of company IT systems during core working hours;

(d)        removing data or equipment from company premises or systems without permission, or in circumstances prohibited by this policy;

(e)        using company equipment in a way prohibited by this policy;

(f)         circumventing technical cyber security measures implemented by the company’s IT team; and

(g)        failing to report a mistake or cyber security breach[ within [number] minutes of its occurrence or discovery].

[additional list items]

4.2        If you are an employee, misuse of the IT system will be referred to the human resources team and [may] OR [will] be considered [misconduct or gross misconduct]; if you are a contractor and are found to be misusing the company IT systems, your contract [may] OR [will] be terminated.

11.        Security Awareness and Procedures 

The policies and procedures outlined below must be incorporated into company practice to maintain a high level of security awareness. The protection of sensitive data demands regular training of all users and contractors.

•           Review handling procedures for sensitive information and hold periodic security awareness meetings to incorporate these procedures into day to day company practice.

•           Distribute this security policy document to all company users to read. It is required that all users confirm that they understand the content of this security policy document by signing an acknowledgement form (see Appendix A)

•           All users that handle sensitive information will undergo background checks (such as criminal and credit record checks, within the limits of the local law) before they commence their employment with the Company.

•           All third parties with access to credit card account numbers are contractually obligated to comply with card association security standards (PCI/DSS). 

•           Company security policies must be reviewed annually and updated as needed.

12.          Network security

•           Firewalls must be implemented at each internet connection and any demilitarized zone and the internal company network.

•           A network diagram detailing all the inbound and outbound connections must be maintained and reviewed every 6 months.

•           A firewall and router configuration document must be maintained which includes a documented list of services, protocols and ports including a business justification.

•           Firewall and router configurations must restrict connections between untrusted networks and any systems in the card holder data environment.

•           Stateful Firewall technology must be implemented where the Internet enters the Company Card network to mitigate known and on-going threats. Firewalls must also be implemented to protect local network segments and the IT resources that attach to those segments such as the business network, and open network.

•           All inbound and outbound traffic must be restricted to that which is required for the card holder data environment.

•           All inbound network traffic is blocked by default, unless explicitly allowed and the restrictions have to be documented.

•           All outbound traffic has to be authorized by management (i.e. what are the whitelisted category of sites that can be visited by the users) and the restrictions have to be documented

•           The company will have firewalls between any wireless networks and the cardholder data environment.

•           The company will quarantine wireless users into a DMZ, where they will be authenticated and firewalled as if they were coming in from the Internet.

•           Disclosure of private IP addresses to external entities must be authorized.

•           A topology of the firewall environment has to be documented and has to be updated in accordance to the changes in the network.

•           The firewall rules will be reviewed on a six months basis to ensure validity and the firewall has to have clean up rule at the bottom of the rule base.

•           The Company have to quarantine wireless users into a DMZ, where they were authenticated and firewalled as if they were coming in from the Internet.

•           No direct connections from Internet to cardholder data environment will be permitted. All traffic has to traverse through a firewall.

Rules  

Source IP

Destination IP

Action

13.        System and Password Policy

All users, including contractors and vendors with access to the Company systems, are responsible for taking the appropriate steps, as outlined below, to select and secure their passwords.

•           A system configuration standard must be developed along industry acceptable hardening standards (SANS, NIST, ISO)

•           System configurations should be updated as new issues are identified (as defined in PCI DSS requirement 6.1)

•           System configurations must include common security parameter settings

•           The systems configuration standard should be applied to any news systems configured.

•           All vendor default accounts and passwords for the systems have to be changed at the time of provisioning the system/device into the Company network and all unnecessary services and user/system accounts have to be disabled.

•           All unnecessary default accounts must be removed or disabled before installing a system on the network.

•           Security parameter settings must me set appropriately on System components

•           All unnecessary functionality (scripts, drivers, features, subsystems, file systems, web servers etc.,) must be removed.

•           All unnecessary services, protocols, daemons etc., should be disabled if not in use by the system.

•           Any insecure protocols, daemons, services in use must be documented and justified.

•           All users with access to card holder data must have a unique ID.

•           All user must use a password to access the company network or any other electronic resources

•           All user ID’s for terminated users must be deactivated or removed immediately.

•           The User ID will be locked out if there are more than 5 unsuccessful attempts. This locked account can only be enabled by the system administrator. Locked out user accounts will be disabled for a minimum period of 30 minutes or until the administrator enables the account.

•           All system and user level passwords must be changed on at least a quarterly basis.

•           A minimum password history of four must be implemented.

•           A unique password must be setup for new users and the users prompted to change the password on first login.

•           Group, shared or generic user account or password or other authentication methods must not be used to administer any system components.

•           Where SNMP is used, the community strings must be defined as something other than the

Standard defaults of “public,” “private” and “system” and must be different from the passwords used to log in interactively.

•           All non-console administrative access will use appropriate technologies like ssh,vpn etc. or strong encryption is invoked before the administrator password is requested

•           System services and parameters will be configured to prevent the use of insecure technologies like telnet and other insecure remote login commands

•           Administrator access to web based management interfaces is encrypted using strong cryptography.

•           The responsibility of selecting a password that is hard to guess generally falls to users. A strong password must:

a)         Be as long as possible (never shorter than 6 characters).

b)         Include mixed-case letters, if possible.

c)         Include digits and punctuation marks, if possible.

d)         Not be based on any personal information.

e)         Not be based on any dictionary word, in any language.

•           If an operating system without security features is used (such as DOS, Windows or MacOS), then an intruder only needs temporary physical access to the console to insert a keyboard monitor program. If the workstation is not physically secured, then an intruder can reboot even a secure operating system, restart the workstation from his own media, and insert the offending program.

•           To protect against network analysis attacks, both the workstation and server should be cryptographically secured. Examples of strong protocols are the encrypted Netware login and Kerberos.

14.        Anti-virus policy

•           All machines must be configured to run the latest anti-virus software as approved by the Company. The preferred application to use is XXXX Anti-Virus software, which must be configured to retrieve the latest updates to the antiviral program automatically on a daily basis. The antivirus should have periodic scanning enabled for all the systems.

•           The antivirus software in use should be cable of detecting all known types of malicious software (Viruses, Trojans, adware, spyware, worms and rootkits)

•           All removable media (for example floppy and others) should be scanned for viruses before being used.

•           All the logs generated from the antivirus solutions have to be retained as per legal/regulatory/contractual requirements or at a minimum of PCI DSS requirement 10.7 of 3 months online and 1 year offline.

•           Master Installations of the Antivirus software should be setup for automatic updates and periodic scans

•           End users must not be able to modify and any settings or alter the antivirus software

•           E-mail with attachments coming from suspicious or unknown sources should not be opened. All such e-mails and their attachments should be deleted from the mail system as well as from the trash bin. No one should forward any e-mail, which they suspect may contain virus.

•           Always run the Corporate standard, supported anti-virus software is available from the corporate download site. Download and run the current version; download and install anti-virus software updates as they become available.

•           NEVER open any files or macros attached to an email from an unknown, suspicious or untrustworthy source. Delete these attachments immediately, then “double delete” them by emptying your Trash.

•           Delete spam, chain, and other junk email without forwarding, in with <Company Name>’s Acceptable Use Policy.

•           Never download files from unknown or suspicious sources.

•           Avoid direct disk sharing with read/write access unless there is absolutely a business requirement to do so.

•           Always scan a floppy diskette from an unknown source for viruses before using it.

•           Back-up critical data and system configurations on a regular basis and store the data in a safe place.

•           If lab testing conflicts with anti-virus software, run the anti-virus utility to ensure a clean machine, disable the software, then run the lab test. After the lab test, enable the anti-virus software. When the anti-virus software is disabled, do not run any applications that could transfer a virus, e.g., email or file sharing.

•           New viruses are discovered almost every day. Periodically check the Lab Anti-Virus Policy and this Recommended Processes list for updates.

15.        Patch Management Policy

•           All Workstations, servers, software, system components etc. owned by the Company must have up-to-date system security patches installed to protect the asset from known vulnerabilities.

•           Where ever possible all systems, software must have automatic updates enabled for system patches released from their respective vendors. Security patches have to be installed within one month of release from the respective vendor and have to follow the process in accordance with change control process.

•           Any exceptions to this process have to be documented.

20.        Audit and Log review

•           This procedure covers all logs generated for systems within the cardholder data environment, based on the flow of cardholder data over the Company network, including the following components:

•           Operating System Logs (Event Logs and su logs).

•           Database Audit Logs.

•           Firewalls & Network Switch Logs.

•           IDS Logs.

•           Antivirus Logs.

•           Cctv Video recordings.

•           File integrity monitoring system logs.

•           Audit Logs must be maintained for a minimum of 3 months online (available for immediate analysis) and 12 months offline.

•           Review of logs is to be carried out by means of the Company’s network monitoring system (the Company to define hostname), which is controlled from the Company console (the Company to define hostname). The console is installed on the server (the Company to define hostname / IP address), located within the Company data center environment.

•           The following personnel are the only people permitted to access log files (the Company to define which individuals have a job-related need to view audit trails and access log files).

•           The network monitoring system software (the Company to define) is configured to alert the Company [RESPONSIBLE TEAM] to any conditions deemed to be potentially suspicious, for further investigation. Alerts are configured to:

•           A dashboard browser-based interface, monitored by the Company [RESPONSIBLE TEAM].

•           Email / SMS alerts to the Company [RESPONSIBLE TEAM] mailbox with a summary of the incident. The Company [ROLE NAME] also receives details of email alerts for informational purposes.

•           The following Operating System Events are configured for logging, and are monitored by the console (the Company to define hostname):

a)         Any additions, modifications or deletions of user accounts.

b)         Any failed or unauthorized attempt at user logon.

c)         Any modification to system files.

d)         Any access to the server, or application running on the server, including files that hold cardholder data.

e)         Actions taken by any individual with root or administrative privileges.

f)          Any user access to audit trails.

g)         Any creation / deletion of system-level objects installed by Windows. (Almost all system-level objects run with administrator privileges, and some can be abused to gain administrator access to a system.)

•           The following Database System Events are configured for logging, and are monitored by the network monitoring system (the Company to define software and hostname):

a)         Any failed user access attempts to log in to the Oracle database.

b)         Any login that has been added or removed as a database user to a database.

c)         Any login that has been added or removed from a role.

d)         Any database role that has been added or removed from a database.

e)         Any password that has been changed for an application role.

f)          Any database that has been created, altered, or dropped.

g)         Any database object, such as a schema, that has been connected to.

h)         Actions taken by any individual with DBA privileges.

•           The following Firewall Events are configured for logging, and are monitored by the network monitoring system (the Company to define software and hostname):

a)         ACL violations.

b)         Invalid user authentication attempts.

c)         Logon and actions taken by any individual using privileged accounts.

d)         Configuration changes made to the firewall (e.g. policies disabled, added, deleted, or modified).

•           The following Switch Events are to be configured for logging and monitored by the network monitoring system (the Company to define software and hostname):

a)         Invalid user authentication attempts.

b)         Logon and actions taken by any individual using privileged accounts.

c)         Configuration changes made to the switch (e.g. configuration disabled, added, deleted, or modified).

•           The following Intrusion Detection Events are to be configured for logging, and are monitored by the network monitoring system (the Company to define software and hostname):

a)         Any vulnerability listed in the Common Vulnerability Entry (CVE) database.

b)         Any generic attack(s) not listed in CVE.

c)         Any known denial of service attack(s).

d)         Any traffic patterns that indicated pre-attack reconnaissance occurred.

e)         Any attempts to exploit security-related configuration errors.

f)          Any authentication failure(s) that might indicate an attack.

g)         Any traffic to or from a back-door program.

h)         Any traffic typical of known stealth attacks.

•           The following File Integrity Events are to be configured for logging and monitored by (the Company to define software and hostname):

a)         Any modification to system files.

b)         Actions taken by any individual with Administrative privileges.

c)         Any user access to audit trails.

d)         Any Creation / Deletion of system-level objects installed by Windows. (Almost all system-level objects run with administrator privileges, and some can be abused to gain administrator access to a system.)

•           For any suspicious event confirmed, the following must be recorded on F17 – Log Review Form, and the Company [ROLE NAME] informed:

a)         User Identification.

b)         Event Type.

c)         Date & Time.

d)         Success or Failure indication.

e)         Event Origination (e.g. IP address).

f)          Reference to the data, system component or resource affected.

23.        Incident Response Plan

‘Security incident’ means any incident (accidental, intentional or deliberate) relating to your communications or information processing systems. The attacker could be a malicious stranger, a competitor, or a disgruntled employee, and their intention might be to steal information or money, or just to damage your company.

The Incident response plan has to be tested once annually. Copies of this incident response plan is to be made available to all relevant staff members, and take steps to ensure that they understand it and what is expected of them.

Users of the company will be expected to report to the security officer for any security related issues.

The Company PCI security incident response plan is as follows:

1.         Each department must report an incident to the Information Security Officer (preferably) or to another member of the PCI Response Team.

2.         That member of the team receiving the report will advise the PCI Response Team of the incident.

3.         The PCI Response Team will investigate the incident and assist the potentially compromised department in limiting the exposure of cardholder data and in mitigating the risks associated with the incident.

4.         The PCI Response Team will resolve the problem to the satisfaction of all parties involved, including reporting the incident and findings to the appropriate parties (credit card associations, credit card processors, etc.) as necessary.

5.         The PCI Response Team will determine if policies and processes need to be updated to avoid a similar incident in the future, and whether additional safeguards are required in the environment where the incident occurred, or for the institution.

6.         If an unauthorized wireless access point or devices is identified or detected as part of the quarterly test this is should be immediately escalated to the Security officer or someone with similar privileges who has the authority to stop, cease, shut down, and remove the offending device immediately.

7.         A department that reasonably believes it may have an account breach, or a breach of cardholder information or of systems related to the PCI environment in general, must inform the Company PCI Incident Response Team. After being notified of a compromise, the PCI Response Team, along with other designated staff, will implement the PCI Incident Response Plan to assist and augment departments’ response plans.

The Company PCI Security Incident Response Team: (Update as applicable)

CIO                             

Communications Director                   

Compliance Officer                             

Counsel                                  

Information Security Officer                            

Collections & Merchant Services                                 

Risk Manager                          

Incident Response Notification

Escalation Members

Escalation – First Level

Information Security Officer Controller

Executive Project Director for Credit Collections and Merchant Services Legal Counsel

Risk Manager

Director of the company Communications

Escalation – Second Level

The company President

Executive Cabinet

Internal Audit

Auxiliary members as needed

      External Contacts (as needed)

Merchant Provider Card Brands

Internet Service Provider (if applicable)

Internet Service Provider of Intruder (if applicable) Communication Carriers (local and long distance) Business Partners

Insurance Carrier

External Response Team as applicable (CERT Coordination Center 1, etc.) Law Enforcement Agencies as applicable inn local jurisdiction

In response to a systems compromise, the PCI Response Team and designees will:

1.         Ensure compromised system/s is isolated on/from the network.

2.         Gather, review and analyze the logs and related information from various central and local safeguards and security controls

3.         Conduct appropriate forensic analysis of compromised system.

4.         Contact internal and external departments and entities as appropriate.

5.         Make forensic and log analysis available to appropriate law enforcement or card industry security personnel, as required.

6.         Assist law enforcement and card industry security personnel in investigative processes, including in prosecutions.

The card companies have individually specific requirements the Response Team must address in reporting suspected or confirmed breaches of cardholder data.

Incident Response notifications to various card schemes 

1.         In the event of a suspected security breach, alert the information security officer or your line manager immediately. 

2.         The security officer will carry out an initial investigation of the suspected security breach. 

3.         Upon confirmation that a security breach has occurred, the security officer will alert management and begin informing all relevant parties that may be affected by the compromise.  

 VISA Steps

If the data security compromise involves credit card account numbers, implement the following procedure:

•           Shut down any systems or processes involved in the breach to limit the extent, and prevent further exposure. 

•           Alert all affected parties and authorities such as the Merchant Bank (your Bank), Visa Fraud Control, and the law enforcement.

•           Provide details of all compromised or potentially compromised card numbers to Visa Fraud Control within 24 hrs. 

•           For more Information visit:

USA Visa

Visa Incident Report Template

This report must be provided to VISA within 14 days after initial report of incident to VISA. The following report content and standards must be followed when completing the incident report. Incident report must be securely distributed to VISA and Merchant Bank. Visa will classify the report as “VISA Secret”*.

I.          Executive Summary

a.         Include overview of the incident

b.         Include RISK Level(High, Medium, Low)

c.         Determine if compromise has been contained II. Background

III. Initial Analysis

IV. Investigative Procedures

a.         Include forensic tools used during investigation V. Findings

a.         Number of accounts at risk, identify those stores and compromised

b.         Type of account information at risk

c.         Identify ALL systems analyzed. Include the following:

•           Domain Name System (DNS) names

•           Internet Protocol (IP) addresses

•           Operating System (OS) version

•           Function of system(s)

d.         Identify ALL compromised systems. Include the following:

•           DNS names

•           IP addresses

•           OS version

•           Function of System(s)

e.         Timeframe of compromise

f.          Any data exported by intruder

g.         Establish how and source of compromise

h.         Check all potential database locations to ensure that no CVV2, Track 1 or Track 2 data is stored anywhere, whether encrypted or unencrypted (e.g., duplicate or backup tables or databases, databases used in development, stage or testing environments, data on software engineers’ machines, etc.)

i.          If applicable, review VisaNet endpoint security and determine risk

VI. Compromised Entity Action

VII. Recommendations

VIII. Contact(s) at entity and security assessor performing investigation

*This classification applies to the most sensitive business information, which is intended for use within VISA. Its unauthorized disclosure could seriously and adversely impact VISA, its users, member banks, business partners, and/or the Brand

MasterCard Steps:

1.         Within 24 hours of an account compromise event, notify the MasterCard Compromised Account Team via phone at 1-636-722-4100.

2.         Provide a detailed written statement of fact about the account compromise (including the contributing circumstances) via secured e-mail to  [email protected]

3.         Provide the MasterCard Merchant Fraud Control Department with a complete list of all known compromised account numbers.

4.         Within 72 hours of knowledge of a suspected account compromise, engage the services of a data security firm acceptable to MasterCard to assess the vulnerability of the compromised data and related systems (such as a detailed forensics evaluation).

5.         Provide weekly written status reports to MasterCard, addressing open questions and issues until the audit is complete to the satisfaction of MasterCard.

6.         Promptly furnish updated lists of potential or known compromised account numbers, additional documentation, and other information that MasterCard may request.

7.         Provide finding of all audits and investigations to the MasterCard Merchant Fraud Control department within the required time frame and continue to address any outstanding exposure or recommendation until resolved to the satisfaction of MasterCard.

Once MasterCard obtains the details of the account data compromise and the list of compromised account numbers, MasterCard will:

1.         Identify the issuers of the accounts that were suspected to have been compromised and group all known accounts under the respective parent member IDs.

2.         Distribute the account number data to its respective issuers.

Users of the company will be expected to report to the security officer for any security related issues. The role of the security officer is to effectively communicate all security policies and procedures to users within the company and contractors. In addition to this, the security officer will oversee the scheduling of security training sessions, monitor and enforce the security policies outlined in both this document and at the training sessions and finally, oversee the implantation of the incident response plan in the event of a sensitive data compromise.

Discover Card Steps

1.         Within 24 hours of an account compromise event, notify Discover Fraud Prevention

2.         Prepare a detailed written statement of fact about the account compromise including the contributing circumstances

3.         Prepare a list of all known compromised account numbers

4.         Obtain additional specific requirements from Discover Card

American Express Steps

1.         Within 24 hours of an account compromise event, notify American Express Merchant Services

2.         Prepare a detailed written statement of fact about the account compromise including the contributing circumstances

3.         Prepare a list of all known compromised account numbers

Obtain additional specific requirements from American Express

27.        Access Control Policy

•           Access Control systems are in place to protect the interests of all users of The Company computer systems by providing a safe, secure and readily accessible environment in which to work.

•           The Company will provide all users and other users with the information they need to carry out their responsibilities in as effective and efficient manner as possible.

•           Generic or group IDs shall not normally be permitted, but may be granted under exceptional circumstances if sufficient other controls on access are in place.

•           The allocation of privilege rights (e.g. local administrator, domain administrator, super-user, root access) shall be restricted and controlled, and authorization provided jointly by the system owner and IT Services. Technical teams shall guard against issuing privilege rights to entire teams to prevent loss of confidentiality.

•           Access rights will be accorded following the principles of least privilege and need to know.

•           Every user should attempt to maintain the security of data at its classified level even if technical security mechanisms fail or are absent.

•           Users electing to place information on digital media or storage devices or maintaining a separate database must only do so where such an action is in accord with the data’s classification

•           Users are obligated to report instances of non-compliance to the Company CISO

•           Access to The Company IT resources and services will be given through the provision of a unique Active Directory account and complex password.

•           No access to any The Company IT resources and services will be provided without prior authentication and authorization of a user’s The Company Windows Active Directory account.

•           Password issuing, strength requirements, changing and control will be managed through formal processes. Password length, complexity and expiration times will be controlled through Windows Active Directory Group Policy Objects.

•           Access to Confidential, Restricted and Protected information will be limited to authorized persons whose job responsibilities require it, as determined by the data owner or their designated representative. Requests for access permission to be granted, changed or revoked must be made in writing.

•           Users are expected to become familiar with and abide by The Company policies, standards and guidelines for appropriate and acceptable usage of the networks and systems.

•           Access for remote users shall be subject to authorization by IT Services and be provided in accordance with the Remote Access Policy and the Information Security Policy. No uncontrolled external access shall be permitted to any network device or networked system.

•           Access to data is variously and appropriately controlled according to the data classification levels described in the Information Security Management Policy.

•           Access control methods include logon access rights, Windows share and NTFS permissions, user account privileges, server and workstation access rights, firewall permissions, IIS intranet/extranet authentication rights, SQL database rights, isolated networks and other methods as necessary.

•           A formal process shall be conducted at regular intervals by system owners and data owners in conjunction with IT Services to review users’ access rights. The review shall be logged and IT Services shall sign off the review to give authority for users’ continued access rights

28.        Wireless Policy

•           Installation or use of any wireless device or wireless network intended to be used to connect to any of the company networks or environments is prohibited.

•           A quarterly test should be run to discover any wireless access points connected to the company network

•           Usage of appropriate testing using tools like net stumbler, kismet etc. must be performed on a quarterly basis to ensure that:

•           Any devices which support wireless communication remain disabled or decommissioned.

•           If any violation of the Wireless Policy is discovered as a result of the normal audit processes, the security officer or any one with similar job description has the authorization to stop, cease, shut down, and remove the offending device immediately.

If the need arises to use wireless technology it should be approved by the company and the following wireless standards have to be adhered to:

1.         Default SNMP community strings and passwords, passphrases, Encryption keys/security related vendor defaults (if applicable) should be changed immediately after the installation of the device and if anyone with knowledge of these leaves the company.

2.         The firmware on the wireless devices has to be updated accordingly as per vendors release schedule

3.         The firmware on the wireless devices must support strong encryption for authentication and transmission over wireless networks.

4.         Any other security related wireless vendor defaults should be changed if applicable.

5.         Wireless networks must implement industry best practices (IEEE 802.11i) and strong encryption for authentication and transmission of cardholder data.

6.         An Inventory of authorized access points along with a business justification must be maintained. (Update Appendix B)

USER ACCOUNTS

It’s the purpose of this policy to inform all Heads of Departments and users that user accounts are the front line of protection for company’s security. As per such principle, it must be considered that a poorly chosen password may result in a compromise of our security and as such it must considered seriously to take the appropriate steps, as outlined below in order to provide a secure digital environment for all.

GENERAL

  1. All accounts provided by IT Department in order to access company’s systems and resources are personal and non-transferable.
  • Users are responsible for their assigned account(s), its access and all transactions made with them.
  • User’s account(s) use is allowed only and exclusively during working hours and under contractual relationship with the company or its affiliates.
  • User accounts, passwords and any other credentials will be registered in IT local Department Credentials Control software.
  • IT Department Credentials Control must be placed in IT Department local shared folder where only specific appointed IT staff will have access.
  • IT Department Credentials Control backup is performed every day and allocated in the backup server.
  • A hard copy of IT Department Credentials Control will be printed at the end of each month and will be handed over to General Manager or any other appointed position by Top Management.

WINDOWS USER ACCOUNTS

  1. lowercase (First letter of First name + Last name)

Example: User full name: John Doe
                User: jdoe

Note: In case of coincidence on values of above structure, it will be sorted out considering the following options:

Option #1: lowercase (First letter of First name + Second letter of First name + Last name).

Example: User #1 full name: John Doe

         User: jodoe

                User #2 full name: Jane Doe

                User: jadoe

Option #2: lowercase (First letter of First name + First letter of Second name + Last name).

Example: User #1 full name: John A. Doe

         User: jadoe

                User #2 full name: John P. Doe

                User: jpdoe

Option #3: lowercase (First letter of First name + any letter(s) available to highlight the required difference on First/Second name + Last name + any letter(s) available to highlight the required difference on last name).

Example: User #1 full name: John Albert Doe

         User: jaldoe

                User #2 full name: John Andrew Doe

                User: jandoe

  • lowercase (department or use related ID + consecutive numbering)

Example 1: User department: HR
                   User: hr01

Example 2: User designation: Finance assistant
                   User: fa01

Example 3: Account use: backup tasks
                   User: backup

  • New user’s information will be provided by HR department and will be strictly created as per their submitted form and new employee’s passport/ID copy.
  • User accounts first model (previous point) will be considered as default and second one will be created upon request/approval of new user’s Department Head of Department.
  • Access passwords must comply with the following specifications:
    • Have a minimum of eight (8) characters.
    • It must contain at least one uppercase letter.
    • It must contain one lowercase letter.
    • It must contain one number.
    • It must contain one of the following special characters: + – * / @ # $% &.
    • It must not contain marked vowels or spaces.
    • Same user name as password will not be accepted.
  • A temporary password will be set by IT department during the account creation and configuration process. After accessing the system for first time with given password, the user will be prompted to create a new password and confirm it.
  • On compliance with security rules, user’s password will be changed every 90 days. Once this period of time has been exceeded, the password will expire and the system will prompt a request to change the password and confirm.
    Note: Laptop users are excluded of this rule and password shall not expire.
  • In case of password lost or forgotten, the user must inform IT department in order to set anew temporary password. After accessing for first time with given password, the user will be prompted to create a new password and confirm it.
  • After 3 unsuccessful attempts to initiate a session the user will be blocked, and must contact IT department to request account unblocking.
  • It is mandatory that all users on permanent or temporary leave (more than 2 week), must do an official account’s password handover to whom will be appointed as replacement or to the immediate supervisor, in order to warranty the continuity of operations.
  1. In the case of an employee retiring, quitting, reassigned, released or dismissed from the company a mail must be sent informing IT department about employee’s final leave date and his/her user account will be disabled after performing final backup and proper handover confirmed by user’s supervisor.
  1. IT Department staff can request a password set by user(s) if required to perform maintenance, software configuration, backup and all other relevant activities of the Department.
  1. IT Department staff can reset a password set by user(s) if he/she is not available, reachable, or willing to comply with previous mentioned point.
  1. A disabled account can be reenabled upon user’s Department supervisor request where a temporary password will be assigned by IT Department.
  1. Temporary users (Contractors, Audits, etc) can be created as per Heads of Department request where they will be responsible to inform credential’s access required level, purpose of the same and account’s expiration date.
  1. It’s responsibility of each Head of Department to inform IT about user accounts and passwords which are not longer required by their department.

PASSWORD PROTECTION STANDARDS

The following guidelines must be considered in order to safekeep your user account and password

  • Don’t share company’s passwords with anyone, including administrative assistants or secretaries. All passwords are to be treated as sensitive, confidential company’s information.
  • Don’t reveal a password over the phone to anyone.
  • Don’t talk about a password in front of others.
  • Don’t hint at the format of a password (e.g., “my family name”).
  • Don’t reveal a password on questionnaires or security forms.
  • Don’t share a password with family members.
  • Don’t use the “Remember Password” feature of applications.
  • Don’t write passwords down and store them anywhere in your office.

OTHER ACCOUNTS AND PASSWORDS

  1. User accounts and passwords will be set by IT Department and provided as a screen capture by email.
  • User password will be changed in case of an employee retiring, quitting, reassigned, released or dismissed from the company.
  • Passwords must not be written into email messages or other forms of electronic communication.
  • In case the user considers his/her password has been compromised, IT department must be informed in order to reset password and create a new user account if required.
  • Access to company networks via remote access is controlled by using a Virtual Private Network in which a password and user id are required.
  • For web access sites on software tools, services, etc; the following guidelines must be on compliance by IT department:
  1. Users must not have password change access.
    1. Recovery email must be set as per IT software general management account. Example: [email protected]
    1. Administrator access must only be managed by IT Department.
  • As per general rule, email passwords will not be handed over to any user unless it’s strictly necessary for IT equipment assigned (PC, Laptop, smart phone, tablet, etc) configuration.

Anshika

Author

Anshika

Please let me know if you have any questions. ... Don't hesitate to comment

Up Next

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *