Example of Virtual Private Network (VPN)Policy

1. Purpose

The purpose of this policy is to provide guidelines for Remote Access IPSec or L2TP Virtual Private Network (VPN) connections to the XXX corporate network.Virtual Private Network (VPN) connections provide a convenient way for staff to access internal network resources remotely over the network. It also provides a mechanism for staff and vendors to provide support for applications and software remotely. Like any remote connection, they must be carefully managed and secured.

2. Scope

This policy applies to all XXX employees, contractors, consultants, temporaries, and other workers including all personnel affiliated with third parties utilizing VPNs to access the XXX network. This policy applies to implementations of VPN that are directed through an IPSec Concentrator.

3. Policy

3.1 General

Approved XXX employees and authorized third parties (customers, vendors, etc.) may utilize the benefits of VPNs, which are a “user managed” service. This means that the user is responsible for selecting an Internet Service Provider (ISP), coordinating installation, installing any required software, and paying associated fees.

Additionally,

  1. It is the responsibility of employees with VPN privileges to ensure that unauthorized users are not allowed access to XXX internal networks.
  2. VPN use is to be controlled using either a one-time password authentication such as a token device or a public/private key system with a strong passphrase.
  3. When actively connected to the corporate network, VPNs will force all traffic to and from the PC over the VPN tunnel: all other traffic will be dropped.
  4. Dual (split) tunneling is NOT permitted; only one network connection is allowed.
  5. VPN gateways will be set up and managed by XXX network operational groups.
  6. All computers connected to XXX internal networks via VPN or any other technology must use the most up-to-date anti-virus software that is the corporate standard (provide URL to this software); this includes personal computers.
  7. VPN users will be automatically disconnected from XXX’s network after thirty minutes of inactivity. The user must then logon again to reconnect to the network. Pings or other artificial network processes are not to be used to keep the connection open.
  8. The VPN concentrator is limited to an absolute connection time of 24 hours.
  9. Users of computers that are not XXX-owned equipment must configure the equipment to comply with XXX’s VPN and Network policies.
  10. Only IT-approved VPN clients may be used.
  11. By using VPN technology with personal equipment, users must understand that their machines are a de facto extension of XXX’s network, and as such are subject to the same rules and regulations that apply to XXX-owned equipment, i.e., their machines must be configured to comply with IT’s Security Policies.

3.2 Administration and Management Responsibilities

IT Department shall ensure the following for all VPN users:

  • All computers connected to via VPN or any other similar remote technology must use up-to-date virus and malware protection software
  • VPN users shall be automatically disconnected from the network after a specified period of inactivity.
  • Support shall disallow pings or other artificial network processes to keep the connection open

3.3 Audit Controls and Management

On-demand documented procedures and evidence of practice should be in place for this operational policy. Satisfactory examples of evidence and compliance include:

  • Logs of authorized VPN users
  • Anecdotal ticketing information showing compliance with this procedure
  • Documented help and user documentation for remote VPN installations
  • Archival communication documentation showing policy implementation

4. Policy Compliance

4.1 Compliance Measurement

The IT team will verify compliance to this policy through various methods, including but not limited to, periodic walk-thrus, video monitoring, business tool reports, internal and external audits, and feedback to the policy owner.

4.2 Exceptions

Any exception to the policy must be approved by the IT Team in advance.

4.3 Non-Compliance

An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

Example of Remote Access Mobile Computing Storage Policy

1.0 Purpose

The purpose is to establish an authorized method for controlling mobile computing and storage devices that contain or access information resources at the XXX.

2.0Scope

XXX employees, consultants, vendors, contractors, students, and others who use mobile computing and storage devices on the network at the XXX.

3.0 Policy

With advances in computer technology, mobile computing and storage devices have become useful tools to meet the business needs at the XXX.  These devices are especially susceptible to loss, theft, hacking, and the distribution of malicious software because they are easily portable and can be used anywhere.  As mobile computing becomes more widely used, it is necessary to address security to protect information resources at the XXX.

3.1 General Policy

It is the policy of the XXX that mobile computing and storage devices containing or accessing the information resources at the XXX must be approved prior to connecting to the information systems at the XXX. This pertains to all devices connecting to the network at the XXX, regardless of ownership.

Mobile computing and storage devices include, but are not limited to: laptop computers, personal digital assistants (PDAs), plug-ins, Universal Serial Bus (USB) port devices, Compact Discs (CDs), Digital Versatile Discs (DVDs), flash drives, modems, handheld wireless devices, wireless networking cards, and any other existing or future mobile computing or storage device, either personally owned or owned, that may connect to or access the information systems at the XXX. A risk analysis for each new media type shall be conducted and documented prior to its use or connection to the network at the XXX unless the media type has already been approved by the Desktop Standards Committee. The Desktop Standards Committee will maintain a list of approved mobile computing and storage devices.

Mobile computing and storage devices are easily lost or stolen, presenting a high risk for unauthorized access and introduction of malicious software to the network at the XXX. These risks must be mitigated to acceptable levels.

Portable computing devices and portable electronic storage media that contain confidential, personal, or sensitive XXX information must use encryption or equally strong measures to protect the data while it is being stored.

Unless written approval has been obtained from the Data Resource Manager and Chief Information Security Officer, databases or portions thereof, which reside on the network at the XXX, shall not be downloaded to mobile computing or storage devices.

3.2 Procedures

To report lost or stolen mobile computing and storage devices, call the Enterprise Help Desk. For further procedures on lost or stolen handheld wireless devices, please see the Procedures section.
The XXX’s Committee shall approve all new mobile computing and storage devices that may connect to information systems at the XXX.
Any non-departmental owned device that may connect to the XXX’s network must first be approved by technical personnel such as those from the XXX Desktop Support. Refer to the Mobile Media Standards for detailed information.

3.3 Roles & Responsibilities

Users of mobile computing and storage devices must diligently protect such devices from loss of equipment and disclosure of private information belonging to or maintained by the XXX. Before connecting a mobile computing or storage device to the network at XXX, users must ensure it is on the list of approved devices issued by the ISD.

The Enterprise Help Desk must be notified immediately upon detection of a security incident, especially when a mobile device may have been lost or stolen.

The Infosec Team is responsible for the mobile device policy at the XXX and shall conduct a risk analysis to document safeguards for each media type to be used on the network or on equipment owned by the XXX.

The Information Systems Division (ISD) is responsible for developing procedures for implementing this policy. The Desktop Standards Committee will maintain a list of approved mobile computing and storage devices and will make the list available on the intranet.

4. Policy Compliance

4.1 Compliance Measurement

The IT team will verify compliance to this policy through various methods, including but not limited to, periodic walk-through, video monitoring, business tool reports, internal and external audits, and feedback to the policy owner.

4.2 Exceptions

Any exception to the policy must be approved by the IT team in advance.

4.3 Non-Compliance

An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

Example of Application security policy

1. Purpose

The purpose of this policy is to define Application security assessments within XXX. Application assessments are performed to identify potential or realized weaknesses as a result of inadvertent mis-configuration, weak authentication, insufficient error handling, sensitive information leakage, etc.  Discovery and subsequent mitigation of these issues will limit the attack surface of XXX services available both internally and externally as well as satisfy compliance with any relevant policies in place.

2. Scope

This policy covers all Application security assessments requested by any individual, group or department for the purposes of maintaining the security posture, compliance, risk management, and change control of technologies in use at XXX.

All Application security assessments will be performed by delegated security personnel either employed or contracted by XXX.   All findings are considered confidential and are to be distributed to persons on a “need to know” basis.  Distribution of any findings outside of XXX is strictly prohibited unless approved by the Chief Information Officer. Any relationships within multi-tiered applications found during the scoping phase will be included in the assessment unless explicitly limited.  Limitations and subsequent justification will be documented prior to the start of the assessment.

3. Policy

3.1 All Applications are subject to security assessments based on the following criteria:

  1. New or Major Application Release – will be subject to a full assessment prior to approval of the change control documentation and/or release into the live environment.
  2. Third Party or Acquired Application – will be subject to full assessment after which it will be bound to policy requirements.
  3. Point Releases – will be subject to an appropriate assessment level based on the risk of the changes in the application functionality and/or architecture.
  4. Patch Releases – will be subject to an appropriate assessment level based on the risk of the changes to the application functionality and/or architecture.
  5. Emergency Releases – An emergency release will be allowed to forgo security assessments and carry the assumed risk until such time that a proper assessment can be carried out.  Emergency releases will be designated as such by the Chief Information Officer or an appropriate manager who has been delegated this authority.
  6. Annual Review – all applications will be subject to a full annual review in its entirety to review potential risks of functionality and/or architecture.

3.2 All security issues that are discovered during assessments must be mitigated based upon the following risk levels. The Risk Levels are based on the Risk Rating Methodology. Remediation validation testing will be required to validate fix and/or mitigation strategies for any discovered issues of Medium risk level or greater.

  1. High – Any high-risk issue must be fixed immediately or other mitigation strategies must be put in place to limit exposure before deployment.  Applications with high risk issues are subject to being taken off-line or denied release into the live environment.
  2. Medium – Medium risk issues should be reviewed to determine what is required to mitigate and scheduled accordingly.  Applications with medium risk issues may be taken off-line or denied release into the live environment based on the number of issues and if multiple issues increase the risk to an unacceptable level.  Issues should be fixed in a patch/point release unless other mitigation strategies will limit exposure.
  3. Low – Issue should be reviewed to determine what is required to correct the issue and scheduled accordingly.

3.3 The following security assessment levels shall be established by the XXX organization or other designated organization that will be performing the assessments.

  1. Full – A full assessment is comprised of tests for all known web application vulnerabilities using both automated and manual tools based on the OWASP Testing Guide.  A full assessment will use manual penetration testing techniques to validate discovered vulnerabilities to determine the overall risk of any and all discovered.
  2. Quick – A quick assessment will consist of a (typically) automated scan of an application for the OWASP Top Ten web application security risks at a minimum.
  3. Targeted – A targeted assessment is performed to verify vulnerability remediation changes or new application functionality.
  4. The current approved web application security assessment tools in use which will be used for testing are:
    • Zed Attack Proxy (ZAP)
    • Bandit
    • <please put in your own tools . I don’t support any brand>
  5. Other tools and/or techniques may be used depending upon what is found in the default assessment and the need to determine validity and risk are subject to the discretion of the Security Engineering team.

4. Policy Compliance

4.1 Compliance Measurement

The IT team will verify compliance to this policy through various methods, including but not limited to, business tool reports, internal and external audits, and feedback to the policy owner.

4.2 Exceptions

Any exception to the policy must be approved by the Infosec team in advance.

Non-Compliance

An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment. Web application assessments are a requirement of the change control process and are required to adhere to this policy unless found to be exempt.   All application releases must pass through the change control process.  Any web applications that do not adhere to this policy may be taken offline until such time that a formal assessment can be performed at the discretion of the Chief Information Officer.

Example of Communication, Router and Switch Security Policy

1. Purpose

This document describes a required minimal security configuration for all routers and switches connecting to a production network or used in a production capacity at or on behalf of XXX. It also describes requirements for communication equipment security configurations of XXX.

2. Scope

All employees, contractors, consultants, temporary and other workers at XXX and its subsidiaries must adhere to this policy. All Communication equipment, routers and switches connected to XXX production networks are affected.

3. Communications Equipment Policy

  1. The security features necessary to minimize risks to communication equipment must be configured in the equipment before it is placed into service. There are two possible roles for the staff that manages the communication equipment: monitoring and administrator. The monitoring role has read only privileges. The administrator role is able to change configuration parameters. All issued commands by users will be recorded, as well as any other security events that may pose a threat to the equipment.
  2. Local users are not allowed on communication equipment. Everyone must authenticate through the central repository of users using a protocol that reduces the risk of identity theft.
  3. All information transmitted from the device must be encrypted by a strong encryption algorithm to minimize the risks of eavesdropping on the communications and man-in-the-middle attacks.
  4. The events recorded by the communication equipment must be kept in storage media that is subject to a regular backup process. The process of maintaining these backups must ensure that the information is not amended.
  5. The password of the communication equipment’s administrator user must not be known by anyone on the staff that manages the equipment. If, for any reason, it is necessary to make use of the highest administrative privileges within the device, then the staff must file a request to the internal security division for the password attaching the justification for its use and completing the required forms. The password must then be reset by the highest administrator to maintain security.

4. Router and Switch Policy

Every router must meet the following configuration standards:

  1. No local user accounts are configured on the router. Routers and switches must use TACACS+ for all user authentication.
  2. The enable password on the router or switch must be kept in a secure encrypted form. The router or switch must have the enable password set to the current production router/switch password from the device’s support organization.
  3. The following services or features must be disabled:
    • IP directed broadcasts
    • Incoming packets at the router/switch sourced with invalid addresses such as RFC1918 addresses
    • TCP small services
    • UDP small services
    • All source routing and switching
    • All web services running on router
    • XXX discovery protocol on Internet connected interfaces
    • Telnet, FTP, and HTTP services
    • Auto-configuration
  4. The following services should be disabled unless a business justification is provided:
    • XXX discovery protocol and other discovery protocols
    • Dynamic trunking
    • Scripting environments, such as the TCL shell
  5. The following services must be configured:
    • Password-encryption
    • NTP configured to a corporate standard source
  6. All routing updates shall be done using secure routing updates.
  7. 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.
  8. Access control lists must be used to limit the source and type of traffic that can terminate on the device itself.
  9. Access control lists for transiting the device are to be added as business needs arise.
  10. The router must be included in the corporate enterprise management system with a designated point of contact.
  11. 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.”

  1. 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.
  2. Dynamic routing protocols must use authentication in routing updates sent to neighbors. Password hashing for the authentication string must be enabled when supported.
  3. 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

5. Policy Compliance

5.1 Compliance Measurement

The IT team will verify compliance to this policy through various methods, including but not limited to, periodic walk-through, video monitoring, business tool reports, internal and external audits, and feedback to the policy owner.

5.2 Exceptions

Any exception to the policy must be approved by the IT team in advance.

5.3 Non-Compliance

An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

Example of Server security Policy

1. Purpose

  1. The purpose of this policy is to establish standards for the base configuration of internal server equipment that is owned and/or operated by XXX. Effective implementation of this policy will minimize unauthorized access to XXX proprietary information and technology.
  2. XXX hereby provides its consent to allow IS auditors both internal and external to access its servers to the extent necessary to allow to perform scheduled and ad hoc audits of all servers at XXX.
  3. The purpose of this policy is to outline which server systems are required to have anti-virus and/or anti-spyware applications

2. Scope

All employees, contractors, consultants, temporary and other workers at XXX and its subsidiaries must adhere to this policy. This policy applies to server equipment that is owned, operated, or leased by XXX or registered under a XXX-owned internal network domain.

3. Policy

3.1 General Requirements

  1. All internal servers deployed at XXX 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 the IT team. 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 IT. The following items must be met:
    • Servers must be registered within the corporate enterprise management system. At a minimum, the following information is required to positively identify the point of contact:
      • Server contact(s) and location, and a backup contact
      • Hardware and Operating System/Version
      • Main functions and applications, if applicable
    • Information in the corporate enterprise management system must be kept up to date.
    • Configuration changes for production servers must follow the appropriate change management procedures
  2. For security, compliance, and maintenance purposes, authorized personnel may monitor and audit equipment, systems, processes, and network traffic per the Audit Policy.

3.2 Configuration Requirements

1 Operating System configuration should be in accordance with approved IT team guidelines.
2 Services and applications that will not be used must be disabled where practical.
3 Access to services should be logged and/or protected through access-control methods such as a web application firewall, if possible.
4 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.
5 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 is sufficient.
6 Always use standard security principles of least required access to perform a function. Do not use root when a non-privileged account will do.
7 If a methodology for secure channel connection is available (i.e., technically feasible), privileged access must be performed over secure channels, (e.g., encrypted network connections using SSH or IPSec).
8 Servers should be physically located in an access-controlled, secured environment.
9 Servers are specifically prohibited from operating from uncontrolled or unsecured cubicle areas.

3.3 Monitoring

  1. 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.
  2. Security-related events will be reported to IT, 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.

3.4 Server Malware Protection

XXX operations staff will adhere to this policy to determine which servers will have anti-virus and/or anti-spyware applications installed on them and to deploy such applications as appropriate.

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 XXX 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

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.

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 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

3.5 Server Audit

XXX hereby provides its consent to allow <Internal or External Audit Name> to access its servers to the extent necessary to allow <Audit organization> to perform scheduled and ad hoc audits of all servers at XXX.

1. Specific Concerns

Servers in use for XXX support critical business functions and store company sensitive information. Improper configuration of servers could lead to the loss of confidentiality, availability or integrity of these systems.

2. Guidelines

Approved and standard configuration templates shall be used when deploying server systems to include:

  • All system logs shall be sent to a central log review system
  • All Sudo / Administrator actions must be logged
  • Use a central patch deployment system
  • Host security agent such as antivirus shall be installed and updated
  • Network scan to verify only required network ports and network shares are in use
  • Verify administrative group membership
  • Conduct baselines when systems are deployed and upon significant system changes
  • Changes to configuration template shall be coordinated with approval of change control board

3. Responsibility

<Internal or External Audit Name> shall conduct audits of all servers owned or operated by XXX. Server and application owners are encouraged to also perform this work as needed.

4. Relevant Findings

All relevant findings discovered as a result of the audit shall be listed in the XXX tracking system to ensure prompt resolution or appropriate mitigating controls.

5. Ownership of Audit Report.

All results and findings generated by the <Internal or External Audit Name> Team must be provided to appropriate XXX management within one week of project completion.  This report will become the property of XXX and be considered company confidential.

4.0 Policy Compliance

4.1 Compliance Measurement

The IT team will verify compliance to this policy through various methods, including but not limited to, business tool reports, internal and external audits, and feedback to the policy owner.

4.2 Exceptions

Any exception to the policy must be approved by the II team in advance.

4.3 Non-Compliance

An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

Example of Wireless Communication Policy and standard

1.Purpose

The purpose of this policy is to secure and protect the information assets owned by XXX. XXX provides computer devices, networks, and other electronic information systems to meet missions, goals, and initiatives. XXX grants access to these resources as a privilege and must manage them responsibly to maintain the confidentiality, integrity, and availability of all information assets.

This policy specifies the conditions that wireless infrastructure devices must satisfy to connect to XXX network. Only those wireless infrastructure devices that meet the standards specified in this policy or are granted an exception by the Information Security Department are approved for connectivity to a XXX network.

2. Scope

All employees, contractors, consultants, temporary and other workers at XXX, including all personnel affiliated with third parties that maintain a wireless infrastructure device on behalf of XXX must adhere to this policy. This policy applies to all wireless infrastructure devices that connect to a XXX network or reside on a XXX site that provide wireless connectivity to endpoint devices including, but not limited to, laptops, desktops, cellular phones, and tablets. This includes any form of wireless communication device capable of transmitting packet data.

3. Policy

3.1 General Requirements

All wireless infrastructure devices that reside at a XXX site and connect to a XXX network, or provide access to information classified as XXX Confidential, or above must:

  • Abide by the standards specified in the Wireless Communication Standard.
  • Be installed, supported, and maintained by an approved support team.
  • Use XXX approved authentication protocols and infrastructure.
  • Use XXX approved encryption protocols.
  • Maintain a hardware address (MAC address) that can be registered and tracked.
  • Not interfere with wireless access deployments maintained by other support organizations.

3 .2 Lab and Isolated Wireless Device Requirements

All lab wireless infrastructure devices that provide access to XXX Confidential or above, must adhere to section 4.1 above. Lab and isolated wireless devices that do not provide general network connectivity to the XXX network must:
4.2.1 Be isolated from the corporate network (that is it must not provide any corporate connectivity) and comply with the Lab Security Policy.
4.2.2 Not interfere with wireless access deployments maintained by other support organizations.

3.3 Home Wireless Device Requirements

4.3.1 Wireless infrastructure devices that provide direct access to the XXX corporate network, must conform to the Home Wireless Device Requirements as detailed in the Wireless Communication Standard.
4.3.2 Wireless infrastructure devices that fail to conform to the Home Wireless Device Requirements must be installed in a manner that prohibits direct access to the XXX corporate network. Access to the XXX corporate network through this device must use standard remote access authentication.

4. Wireless Communication Standard

4.1 General Requirements

All wireless infrastructure devices that connect to a network or provide access to Confidential, Highly Confidential, or Restricted information must:

1 Use Extensible Authentication Protocol-Fast Authentication via Secure Tunneling (EAP-FAST), Protected Extensible Authentication Protocol (PEAP), or Extensible Authentication Protocol-Translation Layer Security (EAP-TLS) as the authentication protocol.
2 Use Temporal Key Integrity Protocol (TKIP) or Advanced Encryption System (AES) protocols with a minimum key length of 128 bits.
3 All Bluetooth devices must use Secure Simple Pairing with encryption enabled.

4.2 Lab and Isolated Wireless Device Requirements

1 Lab device Service Set Identifier (SSID) must be different from production device SSID.
2 Broadcast of lab device SSID must be disabled.

4.3 Home Wireless Device Requirements

All home wireless infrastructure devices that provide direct access to a network, such as those behind Enterprise Teleworker (ECT) or hardware VPN, must adhere to the following:

1 Enable WiFi Protected Access Pre-shared Key (WPA-PSK), EAP-FAST, PEAP, or EAP-TLS
2 When enabling WPA-PSK, configure a complex shared secret key (at least 20 characters) on the wireless client and the wireless access point
3 Disable broadcast of SSID
4 Change the default SSID name
5 Change the default login and password

5.Policy Compliance

5.1 Compliance Measurement

The Infosec team will verify compliance to this policy through various methods, including but not limited to, business tool reports, internal and external audits, and feedback to the policy owner.

5.2 Exceptions

Any exception to the policy must be approved by the Infosec team in advance.

5.3 Non-Compliance

An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

Example of Remote Access Policy for Information security Management System

1. Purpose

The purpose of this policy is to define rules and requirements for connecting to XXX’s network from any host. These rules and requirements are designed to minimize the potential exposure to XXX from damages which may result from unauthorized use of XXX resources. Damages include the loss of sensitive or company confidential data, intellectual property, damage to public image, damage to critical XXX internal systems, and fines or other financial liabilities incurred as a result of those losses. It also defines the requirements for remote access tools used at XXX.

2. Scope

This policy applies to all XXX employees, contractors, vendors and agents with a XXX-owned or personally-owned computer or workstation used to connect to the XXX network. This policy applies to remote access connections used to do work on behalf of XXX, including reading or sending email and viewing intranet web resources. This policy covers any and all technical implementations of remote access used to connect to XXX networks.

3. Policy

Remote access to our corporate network is essential to maintain our Team’s productivity, but in many cases this remote access originates from networks that may already be compromised or are at a significantly lower security posture than our corporate network. While these remote networks are beyond the control of Hypergolic Reactions, LLC policy, we must mitigate these external risks the best of our ability. It is the responsibility of XXX employees, contractors, vendors and agents with remote access privileges to XXX’s corporate network to ensure that their remote access connection is given the same consideration as the user’s on-site connection to XXX. General access to the Internet for recreational use through the XXX network is strictly limited to XXX employees, contractors, vendors and agents (hereafter referred to as “Authorized Users”). When accessing the XXX network from a personal computer, Authorized Users are responsible for preventing access to any XXX computer resources or data by non-Authorized Users. Performance of illegal activities through the XXX network by any user (Authorized or otherwise) is prohibited. The Authorized User bears responsibility for and consequences of misuse of the Authorized User’s access. For further information and definitions, see the Acceptable Use Policy. Authorized Users will not use XXX networks to access the Internet for outside business interests. For additional information regarding XXX’s remote access connection options, including how to obtain a remote access login, free anti-virus software, troubleshooting, etc., go to the Remote Access Services website.

3.1 Requirements

  1. Secure remote access must be strictly controlled with encryption (i.e., Virtual Private Networks (VPNs)) and strong pass-phrases. For further information see the Acceptable Encryption Policy and the Password Policy.
  2. Authorized Users shall protect their login and password, even from family members.
  3. While using a XXX-owned computer to remotely connect to XXX’s corporate network, Authorized Users shall ensure the remote host is not connected to any other network at the same time, with the exception of personal networks that are under their complete control or under the complete control of an Authorized User or Third Party.
  4. Use of external resources to conduct XXX business must be approved in advance by IT and the appropriate business unit manager.
  5. All hosts that are connected to XXX internal networks via remote access technologies must use the most up-to-date anti-virus software, this includes personal computers. Third party connections must comply with requirements as stated in the Third Party Agreement.
  6. Personal equipment used to connect to XXX’s networks must meet the requirements of XXX-owned equipment for remote access as stated in the Hardware and Software Configuration Standards for Remote Access to XXX Networks.

3.2 Remote Access Tools

Remote desktop software, also known as remote access tools, provide a way for computer users and support staff alike to share screens, access work computer systems from home, and vice versa. Examples of such software include LogMeIn, 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 XXX network that can be used for theft of, unauthorized access to, or destruction of assets. As a result, only approved, monitored, and properly controlled remote access tools may be used on XXX computer systems.All remote access tools used to communicate between XXX assets and other systems must comply with the following policy requirements.

  1. XXX provides mechanisms to collaborate between internal users, with external partners, and from non-XXX systems.  The approved software list can be obtained from <link-to-approved-remote-access-software-list>.  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:
    • All remote access tools or systems that allow communication to XXX 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.
    • 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 such as OAuth 2.0.  The remote access tool must mutually authenticate both ends of the session.
    • Remote access tools must support the XXX application layer proxy rather than direct connections through the perimeter firewall(s).
    • Remote access tools must support strong, end-to-end encryption of the remote access communication channels as specified in the XXX network encryption protocols policy.
    • All XXX antivirus, data loss prevention, 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 XXX procurement process, and the information technology group must approve the purchase.

3.3 Dial-In Access Policy

  1. XXX employees and authorized third parties (customers, vendors, etc.) can use dial-in connections to gain access to the corporate network. Dial-in access should be strictly controlled, using one-time password authentication.
  2. It is the responsibility of employees with dial-in access privileges to ensure a dial-in connection to XXX is not used by non-employees to gain access to company information system resources. An employee who is granted dial-in access privileges must remain constantly aware that dial-in connections between their location and XXX are literal extensions of XXX’s corporate network, and that they provide a potential path to the company’s most sensitive information. The employee and/or authorized third party individual must take every reasonable measure to protect XXX’s assets.
  3. Analog and non-GSM digital cellular phones cannot be used to connect to XXX’s corporate network, as their signals can be readily scanned and/or hijacked by unauthorized individuals. Only GSM standard digital cellular phones are considered secure enough for connection to XXX’s network. For additional information on wireless access to the XXX network, consult the Wireless Communications Policy.
  4. Note: Dial-in accounts are considered ‘as needed’ accounts. Account activity is monitored, and if a dial-in account is not used for a period of six months the account will expire and no longer function. If dial-in access is subsequently required, the individual must request a new account as described above.

4. Policy Compliance

4.1 Compliance Measurement

The IT team will verify compliance to this policy through various methods, including but not limited to, business tool reports, internal and external audits, and feedback to the policy owner.

4.2 Exceptions

Any exception to the policy must be approved by the IT team in advance.

4.3 Non-Compliance

An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

Example of Encryption Policy for Information Security Management System

1. Purpose

  1. The purpose of this policy is to provide guidance that limits the use of encryption to those algorithms that have received substantial public review and have been proven to work effectively.
  2. This policy outlines the requirements for protecting encryption keys that are under the control of end users. These requirements are designed to prevent unauthorized disclosure and subsequent fraudulent use. The protection methods outlined will include operational and technical controls, such as key backup procedures, encryption under a separate key and use of tamper-resistant hardware.
  3. This document also describes Information Security’s requirements for encrypting data at rest on XXX mobile devices.

2 Scope

  1. This policy applies to all XXX employees and affiliates.
  2. This policy applies to any mobile device issued by XXX or used for XXX business which contains stored data owned by XXX.
  3. This policy applies to any encryption keys listed below and to the person responsible for any encryption key listed below. The encryption keys covered by this policy are:
    • encryption keys issued by XXX
    • encryption keys used for XXX business
    • encryption keys used to protect data owned by XXX

3 Policy

3.1 Acceptable Encryption Policy

3.1.1 Algorithm Requirements

  1. Ciphers in use must meet or exceed the set defined as “AES-compatible” or “partially AES-compatible” according to the IETF/IRTF Cipher Catalog, or the set defined for use in the United States National Institute of Standards and Technology (NIST) publication FIPS 140-2, or any superseding documents according to the date of implementation. The use of the Advanced Encryption Standard (AES) is strongly recommended for symmetric encryption.
  2. 4.1.2 Algorithms in use must meet the standards defined for use in NIST publication FIPS 140-2 or any superseding document, according to date of implementation. The use of the RSA and Elliptic Curve Cryptography (ECC) algorithms is strongly recommended for asymmetric encryption.
  3. 4.1.3 Signature Algorithms
AlgorithmKey Length (min)Additional Comment
ECDSAP-256Consider RFC6090 to avoid patent infringement. 
RSA2048Must use a secure padding scheme. PKCS#7 padding scheme is recommended. Message hashing required.
LDWMSHA256Refer to LDWM Hash-based Signatures Draft

3.1.2 Hash Function Requirements
In general, XXX adheres to the NIST Policy on Hash Functions.

3.1.3 Key Agreement and Authentication

  1. Key exchanges must use one of the following cryptographic protocols: Diffie-Hellman, IKE, or Elliptic curve Diffie-Hellman (ECDH).
  2. End points must be authenticated prior to the exchange or derivation of session keys.
  3. Public keys used to establish trust must be authenticated prior to use. Examples of authentication include transmission via cryptographically signed message or manual verification of the public key hash.
  4. All servers used for authentication (for example, RADIUS or TACACS) must have installed a valid certificate signed by a known trusted provider.
  5. All servers and applications using SSL or TLS must have the certificates signed by a known, trusted provider.

3.1.4 Key Generation

  1. Cryptographic keys must be generated and stored in a secure manner that prevents loss, theft, or compromise.
  2. Key generation must be seeded from an industry standard random number generator (RNG). For examples, see NIST Annex C: Approved Random Number Generators for FIPS PUB 140-2.

3.2 End User Encryption Key Protection Policy

Encryption Key Management, if not done properly, can lead to compromise and disclosure of private keys use to secure sensitive data and hence, compromise of the data. While users may understand it’s important to encryption certain documents and electronic communications, they may not be familiar with minimum standards for protection encryption. All encryption keys covered by this policy must be protected to prevent their unauthorized disclosure and subsequent fraudulent use.

3.2.1 Secret Key Encryption Keys

Keys used for secret key encryption, also called symmetric cryptography, must be protected as they are distributed to all parties that will use them. During distribution, the symmetric encryption keys must be encrypted using a stronger algorithm with a key of the longest key length for that algorithm authorized in XXX’s Acceptable Encryption Policy. If the keys are for the strongest algorithm, then the key must be split, each portion of the key encrypted with a different key that is the longest key length authorized and the each encrypted portion is transmitted using different transmission mechanisms. The goal is to provide more stringent protection to the key than the data that is encrypted with that encryption key. Symmetric encryption keys, when at rest, must be protected with security measures at least as stringent as the measures used for distribution of that key.

3.2.2 Public Key Encryption Keys

Public key cryptography, or asymmetric cryptography, uses public-private key pairs. The public key is passed to the certificate authority to be included in the digital certificate issued to the end user. The digital certificate is available to everyone once it issued. The private key should only be available to the end user to whom the corresponding digital certificate is issued.

  1. XXX’s Public Key Infrastructure (PKI) Keys:The public-private key pairs used by the XXX’s public key infrastructure (PKI) are generated on the tamper-resistant smart card issued to an individual end user. The private key associated with an end user’s identity certificate, which are only used for digital signatures, will never leave the smart card. This prevents the Infosec Team from escrowing any private keys associated with identity certificates. The private key associated with any encryption certificates, which are used to encrypt email and other documents, must be escrowed in compliance with XXX policies. Access to the private keys stored on a XXX’s issued smart card will be protected by a personal identification number (PIN) known only to the individual to whom the smart card is issued. The smart card software will be configured to require entering the PIN prior to any private key contained on the smart card being accessed.
  2. Other Public Key Encryption Keys:Other types of keys may be generated in software on the end user’s computer and can be stored as files on the hard drive or on a hardware token. If the public-private key pair is generated on smartcard, the requirements for protecting the private keys are the same as those for private keys associated with PKI. If the keys are generated in software, the end user is required to create at least one backup of these keys and store any backup copies securely. The user is also required to create an escrow copy of any private keys used for encrypting data and deliver the escrow copy to the local Information Security representative for secure storage. The Infosec Team shall not escrow any private keys associated with identity certificates. All backups, including escrow copies, shall be protected with a password or passphrase that is compliant with XXX Password Policy. Infosec representatives will store and protect the escrowed keys as described in the XXX Certificate Practice Statement Policy.
  3. Commercial or Outside Organization Public Key Infrastructure (PKI) Keys: In working with business partners, the relationship may require the end users to use public-private key pairs that are generated in software on the end user’s computer. In these cases, the public-private key pairs are stored in files on the hard drive of the end user. The private keys are only protected by the strength of the password or passphrase chosen by the end user. For example, when an end user requests a digital certificate from a commercial PKI, such as VeriSign or Thawte, the end user’s web browser will generate the key pair and submit the public key as part of the certificate request to the CA. The private key remains in the browser’s certificate store where the only protection is the password on the browser’s certificate store. A web browser storing private keys will be configured to require the user to enter the certificate store password anytime a private key is accessed.
  4. PGP Key Pairs: If the business partner requires the use of PGP, the public-private key pairs can be stored in the user’s key ring files on the computer hard drive or on a hardware token, for example, a USB drive or a smart card. Since the protection of the private keys is the passphrase on the secret keying, it is preferable that the public-private keys are stored on a hardware token. PGP will be configured to require entering the passphrase for every use of the private keys in the secret key ring.

3.2.3 Hardware Token Storage

Hardware tokens storing encryption keys will be treated as sensitive company equipment, as described in XXX’s Physical Security policy, when outside company offices. In addition, all hardware tokens, smartcards, USB tokens, etc., will not be stored or left connected to any end user’s computer when not in use. For end users traveling with hardware tokens, they will not be stored or carried in the same container or bag as any computer.

3.2.4 Personal Identification Numbers (PINs), Passwords and Passphrases

All PINs, passwords or passphrases used to protect encryption keys must meet complexity and length requirements described in XXX’s Password Policy.

3.2.5 Loss and Theft

The loss, theft, or potential unauthorized disclosure of any encryption key covered by this policy must be reported immediately to The IT Team. IT personnel will direct the end user in any actions that will be required regarding revocation of certificates or public-private key pairs.

3.3 Mobile Device Encryption Policy

Mobile devices such as smart phone and tablets offer great flexibility and improved productivity for employees.  However, they can also create added risk and potential targets for data loss.  As such, there use must be in alignment with appropriate standards and encryption technology should be used when possible. All mobile devices containing stored data owned by XXX must use an approved method of encryption to protect data at rest. Mobile devices are defined to include laptops, PDAs, and cell phones. Users are expressly forbidden from storing XXX data on devices that are not issued by XXX, such as storing XXX email on a personal cell phone or PDA.

3.3.1 Laptops

Laptops must employ full disk encryption with an approved software encryption package. No XXX data may exist on a laptop in plain text.

3.3.2 PDAs and Cell phones

Any XXX data stored on a cell phone or PDA must be saved to an encrypted file system using XXX-approved software. XXX shall also employ remote wipe technology to remotely disable and delete any data stored on a XXX PDA or cell phone which is reported lost or stolen.

3.3.3 Keys

All encryption keys and pass-phrases must meet complexity requirements described in XXX’s Password Protection Policy.

3.3.4 Loss and Theft

The loss or theft of any mobile device containing XXX data must be reported immediately

4. Policy Compliance

4.1 Compliance Measurement

The IT team will verify compliance to this policy through various methods, including but not limited to, business tool reports, internal and external audits, and feedback to the policy owner.

4.2 Exceptions

Any exception to the policy must be approved by the IT team in advance.

4.3 Non-Compliance

An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

Example of Email security Policy

1         Overview

Electronic email is pervasively used in almost all industry verticals and is often the primary communication and awareness method within an organization. At the same time, misuse of email can post many legal, privacy and security risks, thus it’s important for users to understand the appropriate use of electronic communications.

2         Purpose

The purpose of this email policy is to ensure the proper use of XXX email system and make users aware of what XXX deems as acceptable and unacceptable use of its email system. This policy outlines the minimum requirements for use of email within XXX Network.

3         Scope

This policy covers appropriate use of any email sent from a XXX email address and applies to all employees, vendors, and agents operating on behalf of XXX.

4         Policy

4.1 Email Security

  1. All use of email must be consistent with XXX policies and procedures of ethical conduct, safety, compliance with applicable laws and proper business practices. 
  2. XXX email account should be used primarily for XXX business-related purposes; personal communication is permitted on a limited basis, but non-XXX   related commercial uses are prohibited.
  3. All XXX data contained within an email message or an attachment must be secured according to the Data Protection Standard.
  4. Email should be retained only if it qualifies as a XXX business record.
  5. Email is a XXX business record if there exists a legitimate and ongoing business reason to preserve the information contained in the email.
  6. The XXX email system shall not to be used for the creation or distribution of any disruptive or offensive messages, including offensive comments about race, gender, hair color, disabilities, age, sexual orientation, pornography, religious beliefs and practice, political beliefs, or national origin. Employees who receive any emails with this content from any XXX employee should report the matter to their supervisor immediately.
  7. XXX employees shall have no expectation of privacy in anything they store, send or receive on the company’s email system.
  8. XXX may monitor messages without prior notice. XXX is not obliged to monitor email messages.
  9. Do not use email:
    • To send confidential/sensitive information, particularly over the Internet, unless it is first encrypted by an encryption system approved by Information Security;
    • To create, send, forward or store emails with messages or attachments that might be illegal or considered offensive by an ordinary member of the public i.e. sexually explicit, racist, defamatory, abusive, obscene, derogatory, discriminatory, threatening, harassing, or otherwise offensive;
    • To commit the organization to a third party for example through purchase or sales contracts, job offers, or price quotations, unless you are explicitly authorized by management to do so (principally staff within Procurement and HR). Do not interfere with or remove the standard corporate email disclaimer automatically appended to outbound emails;
    • For private or charity work unconnected with the organization’s legitimate business;
    • In ways that could be interpreted as representing or being official public statements on behalf of the organization, unless you are a spokesperson explicitly authorized by management to make such statements;
    • To send a message from anyone else’s account or in their name (including the use of false ‘from:’ addresses). If authorized by the manager, a secretary may send an email on the manager’s behalf but should sign the email in their own name per pro (‘for and on behalf of’) the manager;
    • To send any disruptive, offensive, unethical, illegal, or otherwise inappropriate matter, including offensive comments about race, gender, color, disability, age, sexual orientation, pornography, terrorism, religious beliefs and practice, political beliefs or national origin, hyperlinks, or other references to indecent or patently offensive websites and similar materials, jokes, chain letters, virus warnings and hoaxes, charity requests, viruses or other malicious software;
    • For any other illegal, unethical or unauthorized purpose.
  10. Apply your professional discretion when using email, for example abiding by the generally accepted rules of email etiquette. Review emails carefully before sending, especially formal communications with external parties.
  11. Do not unnecessarily disclose potentially sensitive information in “out of office” messages.
  12. Emails on the corporate IT systems are automatically scanned for malicious software, spam, and unencrypted proprietary or personal information. Unfortunately, the scanning process is not 100% effective (e.g. compressed and encrypted attachments may not be fully scanned), therefore undesirable/unsavory emails are sometimes delivered to users. Delete such emails or report them as security incidents to the IT Help/Service Desk in the normal way.
  13. Except when specifically authorized by management or where necessary for IT system administration purposes, employees must not intercept, divert, modify, delete, save or disclose emails.
  14. Limited personal use of the corporate email systems is permitted at the discretion of local management provided always that it is incidental and occasional, and does not interfere with business. You should have no expectations of privacy: all emails traversing the corporate systems and networks are subject to automated scanning and maybe quarantined and/or reviewed by authorized employees.Non-work related email shall be saved in a separate folder from work related email.  Sending chain letters or joke emails from a XXX email account is prohibited.
  15. Do not use Gmail, Hotmail, Yahoo, or similar external/third-party email services (commonly known as “web-mail”) for business purposes. Do not forward or auto-forward corporate email to external/third-party email systems. [You may access your own web-mail via corporate IT facilities at local management discretion provided that such personal use is strictly limited and is not considered private.
  16. E-mail shall only be used for business purposes, using terms, which are consistent with other forms of business communication. E-mail guidelines are intended to help users make the best use of the electronic mail facilities at their disposal. When using the organization’s electronic mail facilities, users should comply with the E-mail guidelines.

4.2 Email Retention

4.2.1 Administrative Correspondence

XXX Administrative Correspondence includes, though is not limited to clarification of established company policy, including holidays, time card information, dress code, work place behavior and any legal issues such as intellectual property violations.   All email with the information sensitivity label Management Only shall be treated as Administrative Correspondence.  To ensure Administrative Correspondence is retained, a mailbox admin@XXX has been created, if you copy (cc) this address when you send email, retention will be administered by the IT Department.

4.2.2 Fiscal Correspondence

XXX Fiscal Correspondence is all information related to revenue and expense for the company.  To ensure Fiscal Correspondence is retained, a mailbox fiscal@XXX has been created, if you copy (cc) this address when you send email, retention will be administered by the IT Department.

4.2.3 General Correspondence

XXX General Correspondence covers information that relates to customer interaction and the operational decisions of the business.  The individual employee is responsible for email retention of General Correspondence.

4.2.4 Ephemeral Correspondence

XXX Ephemeral Correspondence is by far the largest category and includes personal email, requests for recommendations or review, email related to product development, updates and status reports.

4.2.5 Instant Messenger Correspondence

XXX Instant Messenger General Correspondence may be saved with logging function of Instant Messenger, or copied into a file and saved.  Instant Messenger conversations that are Administrative or Fiscal in nature should be copied into an email message and sent to the appropriate email retention address.  The Jabber Secure IM Client is the only IM that is approved for use on XXX computers.

4.2.6 Encrypted Communications

XXX encrypted communications should be stored in a manner consistent with XXX Information Sensitivity Policy, but in general, information should be stored in a decrypted format.

4.2.7 Recovering Deleted Email via Backup Media

XXX maintains backup tapes from the email server and once a quarter a set of tapes is taken out of the rotation and they are moved offsite.  No effort will be made to remove email from the offsite backup tapes.

4.2.8 General Standards

  1. Approved Electronic Mail:Includes all mail systems supported by the IT Support Team. These include, but are not necessarily limited to, [insert corporate supported mailers here…]. If you have a business need to use other mailers contact the appropriate support organization.
  2. Approved Encrypted email and files: Techniques include the use of DES and PGP. DES encryption is available via many different public domain packages on all platforms. PGP use within XXX is done via a license. Please contact the appropriate support organization if you require a license.
  3. Approved Instant Messenger:The Jabber Secure IM Client is the only IM that is approved for use on XXX computers.
  4. Individual Access Controls:Individual Access Controls are methods of electronically protecting files from being accessed by people other than those specifically designated by the owner. On UNIX machines, this is accomplished by careful use of the chmod command (use man chmod to find out more about it). On Mac’s and PC’s, this includes using passwords on screensavers, such as Disklock.     
  5. Insecure Internet Links: Insecure Internet Links are all network links that originate from a locale or travel over lines that are not totally under the control of XXX.
  6. Encryption: Secure XXX Sensitive information in accordance with the Acceptable Encryption Policy. International issues regarding encryption are complex. Follow corporate guidelines on export controls on cryptography, and consult your manager and/or corporate legal services for further guidance.

Automatically Forwarded Email Policy

Employees must exercise utmost caution when sending any email from inside XXX to an outside network. Unless approved by an employee’s manager , XXX email will not be automatically forwarded to an external destination. Sensitive information, as defined in the Data Classification and Protection Policy, will not be forwarded via any means, unless that email is critical to business and is encrypted in accordance with the Acceptable Encryption Policy.

5  Policy Compliance

5.1 Compliance Measurement

The IT team will verify compliance to this policy through various methods, including but not limited to, periodic walk-through, video monitoring, business tool reports, internal and external audits, and feedback to the policy owner.

5.2  Exceptions

Any exception to the policy must be approved by the Infosec team in advance.

5.3  Non-Compliance

An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

ISO 27001:2022 A 8.26 Application security requirements

Application security,is the practice of using security software, hardware, techniques, best practices and procedures to protect computer applications from external security threats. Application software programs such as web applications, graphics software, database software, and payment processing software are vital to many critical business operations. However, these applications are often exposed to security vulnerabilities that may result in the compromise of sensitive information.Organisations can establish and apply information security requirements for the development, use, and acquisition of applications.Application security describes security measures at the application level that aim to prevent data or code within the app from being stolen or hijacked. It encompasses the security considerations that happen during application development and design, but it also involves systems and approaches to protect apps after they get deployed. Application security may include hardware, software, and procedures that identify or minimize security vulnerabilities. A router that prevents anyone from viewing a computer’s IP address from the Internet is a form of hardware application security. But security measures at the application level are also typically built into the software, such as an application firewall that strictly defines what activities are allowed and prohibited. Procedures can entail things like an application security routine that includes protocols such as regular testing.

Control

Information security requirements should be identified, specified and approved when developing or acquiring applications.

Purpose

To ensure all information security requirements are identified and addressed when developing or acquiring applications.

ISO 27002 Implementation Guidance

General

Application security requirements should be identified and specified. These requirements are usually determined through a risk assessment. The requirements should be developed with the support of information security specialists.
Application security requirements can cover a wide range of topics, depending on the purpose of the application.
Application security requirements should include, as applicable:

  1. level of trust in identity of entities (e.g. through authentication) ;
  2. identifying the type of information and classification level to be processed by the application;
  3. need for segregation of access and level of access to data and functions in the application;
  4. resilience against malicious attacks or unintentional disruptions [e.g. protection against buffer overflow or structured query language (SQL) injections;
  5. legal, statutory and regulatory requirements in the jurisdiction where the transaction is generated, processed, completed or stored;
  6. need for privacy associated with all parties involved;
  7. the protection requirements of any confidential information;
  8. protection of data while being processed, in transit and at rest;
  9. need to securely encrypt communications between all involved parties;
  10. input controls, including integrity checks and input validation;
  11. automated controls (e.g. approval limits or dual approvals);
  12. output controls, also considering who can access outputs and its authorization;
  13. restrictions around content of “free-text” fields, as these can lead to uncontrolled storage of confidential data (e.g. personal data);
  14. requirements derived from the business process, such as transaction logging and monitoring, non repudiation requirements;
  15. requirements mandated by other security controls (e.g. interfaces to logging and monitoring or data leakage detection systems);
  16. error message handling.

Transactional services

Additionally, for applications offering transactional services between the organization and a partner, the following should be considered when identifying information security requirements:

  1. the level of trust each party requires in each other’s claimed identity;
  2. the level of trust required in the integrity of information exchanged or processed and the mechanisms for identification of lack of integrity (e.g. cyclic redundancy check, hashing, digital signatures);
  3. authorization processes associated with who can approve contents of, issue or sign key transactional documents;
  4. confidentiality, integrity, proof of dispatch and receipt of key documents and the non-repudiation (e.g. contracts associated with tendering and contract processes);
  5. the confidentiality and integrity of any transactions (e.g. orders, delivery address details and confirmation of receipts);
  6. requirements on how long to maintain a transaction confidential;
  7. insurance and other contractual requirements.

Electronic ordering and payment applications

Additionally, for applications involving electronic ordering and payment, the following should be considered:

  1. requirements for maintaining the confidentiality and integrity of order information;
  2. the degree of verification appropriate to verify payment information supplied by a customer;
  3. avoidance of loss or duplication of transaction information;
  4. storing transaction details outside of any publicly accessible environment (e.g. on a storage platform existing on the organizational intranet, and not retained and exposed on electronic storage media directly accessible from the internet);
  5. where a trusted authority is used (e.g. for the purposes of issuing and maintaining digital signatures or digital certificates) security is integrated and embedded throughout the entire end- to-end certificate or signature management process.

Several of the above considerations can be addressed by the application of cryptography, taking into consideration legal requirements

Other information

Applications accessible via networks are subject to a range of network related threats, such as fraudulent activities, contract disputes or disclosure of information to the public; incomplete transmission, mis-routing, unauthorized message alteration, duplication or replay. Therefore, detailed risk assessments and careful determination of controls are indispensable. Controls required often include cryptographic methods for authentication and securing data transfer.

Application security is the process of developing, adding, and testing security features within applications to prevent security vulnerabilities against threats such as unauthorized access and modification.Application security is important because today’s applications are often available over various networks and connected to the cloud, increasing vulnerabilities to security threats and breaches. There is increasing pressure and incentive to not only ensure security at the network level but also within applications themselves. One reason for this is because hackers are going after apps with their attacks more today than in the past. Application security testing can reveal weaknesses at the application level, helping to prevent these attacks. Security measures include improving security practices in the software development life cycle and throughout the application life cycle. All application security activities should minimize the likelihood that malicious actors can gain unauthorized access to systems, applications or data. The ultimate goal of application security is to prevent attackers from accessing, modifying or deleting sensitive or proprietary data. Any action taken to ensure application security is a countermeasure or security control. Security control can be defined as a safeguard or countermeasure prescribed for an information system or an organization designed to protect the confidentiality, integrity, and availability of its information and to meet a set of defined security requirements.

countermeasures include the following:

  • firewalls
  • encryption and decryption programs
  • antivirus programs
  • spyware detection and removal programs
  • biometric authentication systems

Types of application security
Different types of application security features include authentication, authorization, encryption, logging, and application security testing. Developers can also code applications to reduce security vulnerabilities.

Authentication: When software developers build procedures into an application to ensure that only authorized users gain access to it. Authentication procedures ensure that a user is who they say they are. This can be accomplished by requiring the user to provide a user name and password when logging in to an application. Multi-factor authentication requires more than one form of authentication—the factors might include something you know (a password), something you have (a mobile device), and something you are (a thumb print or facial recognition).
Authorization: After a user has been authenticated, the user may be authorized to access and use the application. The system can validate that a user has permission to access the application by comparing the user’s identity with a list of authorized users. Authentication must happen before authorization so that the application matches only validated user credentials to the authorized user list.
Encryption: After a user has been authenticated and is using the application, other security measures can protect sensitive data from being seen or even used by a cybercriminal. In cloud-based applications, where traffic containing sensitive data travels between the end user and the cloud, that traffic can be encrypted to keep the data safe.
Logging: If there is a security breach in an application, logging can help identify who got access to the data and how. Application log files provide a time-stamped record of which aspects of the application were accessed and by whom.
Application security testing: A necessary process to ensure that all of these security controls work properly.

Organisations should carry out a risk assessment to determine the type of information security requirements appropriate to a particular application. While the content and types of information security requirements may vary depending on the nature of the application, the requirements should address the following:

  • The degree of trust assigned to the identity of specific entities.
  • Identification of the level of classification assigned to information assets to be stored on or processed by the application.
  • Whether there is a need to segregate the access to functions and information stored on the application.
  • Whether the application is resilient against cyber attacks such as SQL injections or unintentional interceptions such as buffer overflow.
  • Legal, regulatory and statutory requirements and standards applicable to the transaction processed, generated, stored, or completed by the application.
  • Privacy considerations for all parties involved.
  • Requirements for the protection of confidential data.
  • Protection of information when in use, in transit, or at rest.
  • Whether secure encryption of communications between all relevant parties is necessary.
  • Implementation of input controls such as input validation or performing integrity checks.
  • Carrying out automated controls.
  • Performing output controls, taking into account who can view outputs and the authorisation for Access.
  • Need to impose restrictions on the content of “free-text” fields to protect the dissemination of confidential data in an uncontrollable manner.
  • Requirements arising out of business needs such as logging of transactions and non-repudiation requirements.
  • Requirements imposed by other security controls such as data leakage detection systems.
  • How to handle error messages.

Organisations to take into account the following seven recommendations when an application offers transactional services between the organisation and a partner:

  • The degree of trust each party in the transaction requires in the other party’s identity.
  • The degree of trust required in the integrity of data communicated or processed and identification of a proper mechanism to detect any lack of integrity, including tools such as hashing and digital signatures.
  • Establishment of an authorisation process for who is allowed to approve the content of, sign, or sign off on essential transactional documents.
  • Maintaining the confidentiality and integrity of the critical documents and proving sending and receipt of such documents.
  • Protecting and maintaining the integrity and confidentiality of all transactions such as orders and receipts.
  • Requirements for what time period transactions shall be kept confidential.
  • Contractual requirements and requirements related to insurance.

When applications include payment and electronic ordering functionality, organisations should take into account the following:

  • Requirements ensure that confidentiality and integrity of order information are not compromised.
  • Determining an appropriate degree of verification to verify the payment details provided by a customer.
  • Preventing the loss or duplication of transaction information.
  • Ensuring that information related to information is stored outside of a publicly accessible environment such as on a storage media housed on the organisation’s own intranet.
  • Where organisations rely on a trusted external authority such as for the issuance of digital signatures, they must ensure that security is integrated across the entire process.

Application security controls are techniques to enhance the security of an application at the coding level, making it less vulnerable to threats. Many of these controls deal with how the application responds to unexpected inputs that a cybercriminal might use to exploit a weakness. A programmer can write code for an application in such a way that the programmer has more control over the outcome of these unexpected inputs. Fuzzing is a type of application security testing where developers test the results of unexpected values or inputs to discover which ones cause the application to act in an unexpected way that might open a security hole.When applications are accessed through networks, they are vulnerable to threats such as contract disputes, fraudulent activities, mis-routing, unauthorized changes to the content of communications, or loss of confidentiality of sensitive information. Organisations to perform comprehensive risk assessments to identify appropriate controls such as the use of cryptography to ensure the security of information transfers.The information involved in application service transactions must be protected to prevent incomplete transmission, misrouting, unauthorized message alteration, unauthorized disclosure, unauthorized message duplication, or replay. Additional protection is likely to secure application service transactions (not necessarily just financial transactions). These may include; Use of electronic signatures, Use of encryption; and Use of secure protocols. The ongoing monitoring of such transactions in a near to real-time manner is also likely to be required.

Application developers perform application security testing as part of the software development process to ensure there are no security vulnerabilities in a new or updated version of a software application. A security audit can make sure the application is in compliance with a specific set of security criteria. After the application passes the audit, developers must ensure that only authorized users can access it. In penetration testing, a developer thinks like a cybercriminal and looks for ways to break into the application. Penetration testing may include social engineering or trying to fool users into allowing unauthorized access. Testers commonly administer both unauthenticated security scans and authenticated security scans (as logged-in users) to detect security vulnerabilities that may not show up in both states.