Security considerations for your website (ITSM.60.005)

1.1 Data sensitivity

Before designing your website, you should identify high-value and sensitive data (e.g. personal, financial, business critical, or proprietary information) to ensure that you implement measures in your website design and architecture to protect it. Data sensitivity is measured by assessing the possible harm that could result from the inability to protect the confidentiality, integrity, and availability of information. Confidentiality protects information from unauthorized disclosure. Integrity protects information from unauthorized changes. Availability ensures that information is available when it is required.

When categorizing your data, you should assign sensitivity levels to each of these three areas (confidentiality, integrity, availability) to create a three-part data security profile. Data sensitivity is categorized as high (H), medium (M), or low (L). For example, consider a data set that has a data security profile of H/M/L. You can interpret the three parts of the data security profile in the following ways:

• A data confidentiality compromise (H) has a critical or prohibitive impact;
• A data integrity compromise (M) has a major impact; and
• A data availability compromise (L) has a moderate impact.

Data classification can be time sensitive. For example, the sensitivity of election result data is higher the day of an election than the day after. Classify your data based on the highest level of expected injury that could result if that data is compromised. See Annex 1 of ITSG-33 IT Security Risk Management: A Lifecycle Approach ^{Footnote 3} for more information on classifying and categorizing your data.

3.1 Segregate web service components

When you design your web services, you should segregate, or separate, your web service components from one another. By separating them, you can ensure that if one component is compromised, the other components are protected. For example, if a threat actor successfully accesses a part of your infrastructure, they won’t be able to access the other components.

A simple web service has the following components: a web server, an application, and a database. The web server accepts and formats requests from the client browser across the Internet and then passes these requests to the application for processing. The web server also receives responses from the application and presents them to the client browser (i.e. the presentation tier). The application conducts the main processing in the web service, applying business logic to requests (i.e. the application tier). The database is your persistent data repository, which houses your sensitive data (i.e. the persistent tier).

A simple design could have all components residing on a single web server. This design works from a functionality perspective, but it leaves your data vulnerable to threats. If the web server is compromised, and everything is stored on that one web server, then your data is compromised as well. To secure your architecture, use techniques such as physical separation (where possible), firewalls, security policies, and access controls. If you are using a service provider, you should identify how they separate web service components.

3.2 Protect your internet-facing web services

Threat actors target web-facing components because they serve as entry points to your network. Where possible, you need to identify and stop malicious requests before they reach your network.

You can protect your Internet-facing web services by using the following techniques:

• Insert a proxy server in front of your web services;
• Use a web application firewall (WAF), which an application firewall that filters, monitors, and blocks Hypertext Transfer Protocol (HTTP) traffic;
• Implement access controls and authentication methods (see sections 4 andsections 5); and
• Monitor and use an IDS or IPS (see section 9).

3.3 Implement redundant components

You should build redundancy into your design to avoid a single point of failure to help you effectively return to operations and minimize the impacts if an issue occurs. All hardware components are subject to failure at some point. Redundancy (i.e. replication) is an architectural principle that ensures that multiple resources serve the same function. By implementing redundancies in your web service components, you can maintain the availability of systems and services and reduce the risk of data loss. In addition, redundancy can reduce the impacts of a DoS attack, which can target web-facing components to intentionally disrupt services. You should prioritize creating redundancies for web-facing components.

Your redundancy plan should focus first on web-facing components, such as proxy servers, but it should also consider internal components, such as web servers, load balancers, databases, and application servers. If load balancing is required, you should determine which load balancing distribution mechanisms are available to you (e.g. source IP, source port, quintuple) and verify that these mechanisms are compatible with your web servers and applications.

Ensure you back up your data regularly. It is not enough to create redundant components and back ups; you need to test them rigorously to ensure they work properly.

3.4 Isolate administrative interfaces

You should isolate your website’s administrative interface. Administrative or privileged users have elevated access to your network. When assigning privileges to users, you should always consider the potential impact should their accounts be compromised. You should also have separate log-in interfaces for general users from administrative or privileged users. Login interfaces for web applications are Internet-facing, making them a target for attack. Issues with the user login interface could escalate quickly if an administrator uses that same interface. If something goes wrong with your website, it is your administrator that needs to get in to fix the issues.

You should isolate your website’s administrator interface. In the case of remote work environments, administrative or privileged users should use a virtual private network (VPN) to log in to and access your network.

Additionally, you should store administrative user credentials separately from general user credentials, such as in a different database instance.

4.1 Plan and test access controls

Application or network access requires access control planning. When defining access controls, you should apply the principles of least privilege and default deny. The principle of least privilege ensures that entities have the minimum access they need to perform their authorized functions. In the principle of default deny, requests are denied unless the source of the request is authorized by your organization as per the allow list.

Access control is complicated in a web application. There are multiple layers of mechanisms at play when resources or data are being accessed. The access control layers in your web application should include the following:

• URL-based access control on the web server or web platform: Disallow certain URL elements. If you only want access to your site from certain geographic locations, this may include geo location protections.
• File system and server permission: To pass through a web server, filesystem permission and web server permission must be examined.
• Application (business logic) access control: Access control to define what the user can and cannot do in the application functions.
• Data layer access control: Complements application access control by controlling access to database elements.
• Application (presentation layer) access control: Controls the limits of the application that a user can view.

When designing access controls for each layer, you should always consider defence in depth and the user’s identity and role. Define the roles and the functions that each role can perform. For each function, you should be as specific as possible when defining what the entities can do and see (e.g. read, update, or delete data), and what data these entities can access in your database. You should create an access control matrix that uses rules or roles to link resources to objects. For example, create a table that distinguishes administrative roles, such as system administrators and application administrators. You should create an additional table to describe what data they can see. It is crucial that you test your access controls to ensure they are implemented properly.

Ensure that you define requirements for reviewing and updating privileges regularly (e.g. when a user changes roles or leaves the organization).

5.1 Establish a strong password policy

Establish a strong password policy that includes a minimum number of characters and the expiry dates of passwords. You should not enable password hints as they make it easier for threat actors to guess passwords. We find that the following standards produce the best deterrent effect:

• Passphrases should be at least 4 words and 15 characters long;
• Passwords should be at least 12 characters long; and
• Passcodes and personal identification numbers (PINs) should only be used if passphrases and passwords cannot be used.
  • Use randomly generated PINs where available.

Be sure to rigorously test your password implementation. For more password best practices, see ITSAP.30.032 Best Practices for Passwords and Passphrases ^{Footnote 5}.

Credential stuffing attacks are becoming more common. In a credential stuffing attack, threat actors use previously stolen credentials to attempt to log in to other websites and systems until matches are found. Credential stuffing attacks work because people tend to reuse their passwords across multiple websites.

To protect your customers against credential stuffing, encourage them not to reuse their passwords and prevent them from using passwords that are known to have been leaked. Do not allow users to enter their email addresses as their usernames. Allowing email addresses as usernames gives threat actors a plausible username and password combination.

There are online resources available that identify compromised passwords, such as the website, “Have I Been Pwned” and its Pwned Passwords service. Through this service, users can see if any of their information has been subject to a data breach. This service was created after the National Institute for Standards and Technology (NIST) released guidance specifically recommending that user-provided passwords are checked against existing data breaches.

With password requirements becoming more complex, users may have difficulties remembering complex passwords without writing them down, which is a risk to security of the passwords. Increasingly, websites use password management services supplied by vendors, which can not only store and manage passwords but also generate complex passwords for users. For security tips on password managers, refer to ITSAP.30.025 Password Managers Security ^{Footnote 6}.

5.2 Enable MFA

We highly recommend enabling MFA for all types of accounts (e.g. administrators, users). MFA requires users to have at least two different authentication factors to log in to their accounts. As identified in our publication, ITSP.30.031 v3 User Authentication Guidance for Information Technology Systems ^{Footnote 7}, there are three main types of authentication factors:

1. Something you know (e.g. a PIN, password, or passphrase);
2. Something you have (e.g. a hard token, smart card); and
3. Something you are (e.g. a biometric like a fingerprint).

Note: There is increasing recognition for additional authentication factors to further strengthen authentication, such as your location and user behavior (i.e. what you are doing).

It is easier to implement a type 2 authentication factor (i.e. something you have) because it doesn’t require the user (or browser component) to know or remember the factor (e.g. a password or PIN), and you can fit the input into an HTML form. However, it may not be feasible to issue hardware token to all website clients; instead, you could issue hardware tokens to special users or administrators.

Many vendors have proprietary solutions for MFA tokens. In most cases, the vendor provides the API for different development languages that the developer integrates into the authentication application. If you use one of these solutions, ensure that it uses at least two of the authentication factor types listed above. You should also ensure that the vendor can support electronic distribution of the second factor.

MFA is not a perfect solution, but this measure requires threat actors to work harder to succeed at hacking an account. It is possible for threat actors to hijack user sessions or compromise more than one medium to defeat out-of-band authentication mechanisms. However, by using per-use tokens and expiring tokens, you can limit or eliminate the window of time in which a threat actor can use the targeted login credentials.

Additionally, MFA does not prevent person-in-the-middle attacks from occurring. A threat actor can also send a phishing message with a link to a spoofed log-in page to trick the recipient into entering their credentials.

5.3 Have a secure account recovery process

You should define a secure account recovery process. If a customer loses one or both of their authentication factors, this recovery process enables them to reset their passwords and log into their accounts. You must carefully implement account recovery to minimize the risks of threat actors masquerading as legitimate customers. You can also notify the customer any time abnormal log-in activity occurs (e.g. from a new device or location).

Your account recovery process should include the following steps, at a minimum:

1. Ask the user to identify themselves (e.g. username, customer number, emails address);
2. Ask private security questions;
   • Choose these questions carefully and avoid asking questions that rely on answers based on publicly available information. Instead, use questions relating to previous transactions or other account details;
3. Generate an email containing a time-sensitive, one-time link;
   • This email provides a second authentication factor by communicating with the user on another medium;
4. Allow the user to enter a new password;
   • The user must meet the password complexity requirements;
   • The user enters the new password twice to validate the change; and
5. Alert the user that the password or account details have changed.

5.4 Use measures to protect passwords

In addition to a strong password policy, you should apply additional measures to protect passwords. When users log into your website, do not allow passwords to be sent in plaintext. Instead require the use of HTTPS and hashing. You should review your coding practices to ensure that credentials and API keys are never allowed to be hardcoded into your web services.

5.5 Use account lockout, login delay, and CAPTCHA

During a brute force attack, a threat actor repeatedly attempts to log in through trial and error until they find the correct credential combination. To prevent brute-force attacks, you should not allow users to use their email addresses as their usernames (refer to subsection 5.3). You should also apply some additional security controls, including account lockouts, login delays, and CAPTCHAs.

You should monitor failed login attempts to identify potential brute force attacks and alert your administrator as soon as possible. You can use a WAF to help with your detection and response activities.

With account lockouts, users have a maximum number of allowed login attempts before their accounts are locked. This threshold gives users or threat actors a finite number of chances to login before the account is frozen, forcing them to follow the account recovery process. Your developers should review the authentication mechanisms used. If using a basic or a digest authentication mechanism, you need to customize it to support account lockout. There are few vendors that provide authentication backends with built-in account lockout capabilities, including Lightweight Directory Access Protocol (LDAP), Active Directory (AD), and SQL Server.

Add a delay to each login attempt. When carrying out brute force attacks, many threat actors use automated tools. A delay of 0.5 seconds is usually enough to interrupt these tools.

You should also add a CAPTCHA, or a similar mechanism, to confirm that a user is not a robot if they fail to login after one or two attempts. For example, a CAPTCHA mechanism may ask the user to look at a picture and type the characters they see. You do not need to develop this mechanism. You can purchase it off the shelf and integrate it into your interface. You may want to reach out to CAPTCHA and alternative vendors to discuss the feasibility of using CAPTCHA mechanisms.

6.1 Use session management toolkits

Programming languages such as Hypertext Preprocessor (PHP), .NET and Active Server Pages (ASP) have session management features built in. There is no need to reinvent session management mechanisms unless you have an in-house specialist on session management. Using these established products makes it easier for you to test and update these mechanisms. You should review these toolkits to ensure they meet your application’s objectives and that they can support future service enhancements. If you choose to use a toolkit, be sure to document the security configurations for repeatability.

Note: Because toolkits are not inherently secure, you should follow the guidance in subsections 6.2 to 6.6 to secure sessions.

6.2 Use random session identifiers that adhere to a minimum length

You should use randomly generated session identifiers to prevent threat actors from inferring the next session token. If session tokens are based on sequential values or use data like timestamps when created, then they can be inferred.

You should also implement a minimum length for session identifiers to prevent brute-force attacks. OWASP recommends a minimum length of 128 bits.

6.3 Use cookie security flags

To ensure the security of cookies, use the following cookie flags:

• Secure: The Secure flag indicates to the browser that this cookie is to be sent only in secure connections, such as a TLS connection. Using TLS encrypts the cookie header so it cannot be read.
• HTTPOnly: The HTTPOnly flag tells the browser to disallow any access to the cookie from a JavaScript component. Some attacks, such as cross-site scripting, can control the victim browser’s JavaScript and send the cookie to malicious sites.
• SAME-SITE: The SAME-SITE flag allows cookies to be sent only to the same domain where the cookies originated.

6.4 Store cookie data on a server

During user authentication, your web server generates a session ID and sends it to the user’s browser. All subsequent requests to the web server will include this value, which enables the server to recognize the user without having to authenticate them again. However, many web services also track sessions, including the user’s individual preferences. You should store this sensitive session data on your web service servers and store only the minimum amount of session data that is stored in the user’s browser. A user’s browser is less secure, often due to vulnerabilities, (e.g. out-of-date software) which threat actors can exploit through XSS and CSRF attacks. In addition, laptops and mobile devices can be lost or stolen.

6.5 Expire session data

Threat actors can use discarded token data to impersonate users through CSRF. You should apply session timeout mechanisms to limit the window in which threat actors can use session credentials. Additionally, users may not log out after their sessions. You should implement a session timeout mechanism that occurs after a defined period (e.g. after 15 minutes) of user inactivity.

6.6 Add layers of session authentication

You should create layers of session authentication. Authentication is not a one-time activity in secure, modern web applications. Authentication should be considered to extend beyond the log-in page and through the entire session in which the user is interacting with the application. A form of authentication can be performed for every single request by using a combination of user behaviours, attributes, request timing, IP addresses, and browser details to determine the legitimacy of the requests. You should consider additional authentication mechanism when performing high-risk functions, as well as the MFA principles introduced in section 5.2.

You should implement anti-CRSF tokens each time a form is submitted. You should also ensure that the application reauthenticates the user when they are performing higher risk operations (e.g. requests to reset their password). This type of activity mitigates XSS and CSRF attacks. For more details on input validation, see section 7 below.

7.1 Validate early, but coordinate

As a best practice, you should validate inputs as early as possible in the processing process to reduce strain on your servers. Consider all areas where validation can occur. For example, consider credit card numbers. If you accept credit card numbers as an input, validation begins at the user’s browser, as opposed to waiting for the application business logic (e.g. expected length). Validating at the user’s browser prevents unnecessary noise going to your web infrastructure. However, validation at the user’s browser is limited, and it can be bypassed at the user end.

You should complement browser validation with stronger validation methods. For example, web filtering provides a flexible add-on to drop invalid requests. Generally, web application validation is more secure. You should validate both the front end (i.e. form) and the backend (i.e. data that is submitted through a service) and don’t just rely on one area.

7.2 Confirm expected input length

Buffer overflow occurs when inputs for one function exceed the allotted buffer for data, impacting the web application in an unexpected way. This can impact your web services by potentially exposing sensitive data. Refer to NIST’s National Vulnerability Database to see details in CVE-2014-0160 Detail ^{Footnote 10}, which describes the Heartbleed exposure in 2014.

You can minimize buffer overflow by imposing input limitations in line with expected input lengths and buffer capacity. Test buffer overflow prevention at run-time or in code reviews. Ensure that your web application can handle buffer overflow gracefully and that there are no unexpected alterations that occur in the database. You can also use Java, Perl, and PHP, which have built-in protections against buffer overflow.

7.3 Ensure validation code is central

Input validation is prevalent and can occur almost anywhere in your code. As such, input validation can be quite difficult to test effectively. Centralize your validation code in functions rather than scattering it across your code. Clearly identify in your code where the input validation occurs. This enables reuse of input validation for inputs of similar type and facilitates effective testing across your code. You should establish this in your coding standards before development begins and require that code reviews verify effective input validation.

7.4 Restrict input format as much as possible

In a free-form field, the user can enter any text they want. This type of input requires the most complex input validation because of the increased risk that something malicious can get through. To avoid this risk, you should restrict the format as much as possible and limit free-form client input where possible. Instead use limited option fields where possible, such as drop-down lists, radio buttons, or checkboxes, which are much easier to test. Do not ask for the same data more than once. Confirm inputs to ensure expected input type.

7.5 Filter special characters

Filtering out special character combinations can protect you from several different types of cyber threats and attacks, such as malicious input injection. Where possible, use existing code frameworks and libraries, which have the benefit of maturity and community input, instead of creating these filters from scratch.

Operating system command line injection occurs when applications allow users to send command line arguments on the operating system with the privileges of service. This is particularly risky because threat actors can use malicious operating system code injection to escalate privileges or carry out DoS attacks. To mitigate this attack, you should validate input constraints, blocking special characters such as semi-colons (;), slashes (/), pipes (|), and database or application key words.

In HTTP header injection attacks, the user of the application is targeted as opposed to the web application itself. When the user logs in to a web application, the HTTP response reacts based on who the user is. For example, when logging in to a banking website, the HTTP response accepts inputs, such as user ID, and redirects the user to a particular page that contains their banking information. However, a threat actor can use special characters to create new header items, which can be used to spoof a user’s cookies or redirect the user to an invalid site. This is often used to help facilitate XSS and CSRF. To mitigate this type of attack, you should validate input constraints, blocking special characters, such as “\r” “\n” and other HTTP header editing commands.

SQL injection occurs when a threat actor adds SQL in the input field to view or alter the data in a database. Through this attack method, a threat actor can alter or destroy a database; the threat actor only needs rudimentary SQL skills to carry out the attack. To mitigate this type of attack, you should block escaping mechanisms (i.e. quotation marks or double quotation marks) and special characters associated with SQL (e.g. DELETE, UPDATE) where possible and depending on web application permissions.

7.6 Hide SQL error messages from users

SQL error messages can provide a lot of data about your database, including queries to specific database tables and fields. Do not allow error messages to be displayed to users, as this can provide threat actors with insight into what your database looks like.

7.7 Block multiple parameter instances

You should block multiple parameter instances, where possible, to filter requests before they are processed by the application server. The implementation in the code depends on which application platform you use. Some platforms have implicit protection against multiple parameters of the same name. You can also constrain your inputs at the front end and use WAF to block certain keywords specific to SQL statements.

HTTP allows multiple parameters of the same name; as such, multiple values of the same parameter name can occur in a single request. Different server platforms (e.g. ASP.NET, JSP, PHP) handle this in different ways, using both values or just the first value or the second value, which can cause confusion. The application behaviour can change, and input validation can be bypassed.

You should test these validations during the development phase using code reviews and development testing.

7.8 Validate after encoding

You should set encoding on web pages and ensure all pages support the same encoding. Disable best-fit mapping where possible and normalize data via encoding before you validate the data. Your customers and software platforms can be global. As such, there can be a confusion between characters of different languages which look quite similar but mean something completely different to your application.

Use Unicode standard Unicode Transformation Format 8 (UTF-8) where possible. UTF-8 is the most common standard in the world for web pages and supports backward compatibility. Currently, the latest established version of the UTF-8 was v.12.1 Use standard normalization libraries. Most modern software providers use Unicode, as a universal language, to uniquely identify characters, as data is processed through different platforms and devices, to prevent corruption of data.

Conduct testing as part of the development process, using code reviews as well as run-time testing.

7.9 Secure file upload

File upload is a form of input into your web application. In many instances, file upload can become a part of your site’s content. There is a risk that the upload could include executable content or some type of malware. Additionally, an upload that is larger than expected can cause availability issues for your web application.

You should investigate why file upload is needed and if there are alternative forms that can acquire this data, such as form text and text area fields. Although these alternative forms require more input from the end user, they enable safer storage. Additionally, it is easier to perform searches on the data when it entered in these forms because the content is consistent (i.e. text-based). For example, consider a job-hunting application. Form-based input provides more benefit for both the reviewer, as they can run searches on keywords, and the applicant, as they don’t have to worry that reader software can’t parse the content of their resume.

If file upload is deemed necessary, you should filter file upload based on file extension and size limits and analyze the content. You can use the “file” command, which checks for file types and understands the type of content inside. To extract the metadata or content for closer inspection, you can also use additional tools and libraries to extract the file in text or Extensible Markup Language (XML) format. For graphics, you can use tools to strip out metadata and detect abnormalities.

7.10 Test business logic

Business logic refers to your organization’s business decisions and how these decisions are translated into coding logic on the application server. Risks may be introduced if the business decisions are unclear or are not translated effectively to the coding logic. Business logic flaws can allow improper inputs to enter your space, which may cause a variety of problems.

You should clearly define your requirements and use cases, including misuse cases. When defining security requirements, look at the business process in its entirety. Test the business logic during and after the development phase to address use and misuse cases. You should ensure that the use cases address any instances of concurrency, which is when multiple processes need to access the same resource at the same time.

7.11 Conduct penetration testing

You should conduct penetration testing to determine how resilient your input validation is to malicious activities. Penetration testing, or ethical hacking, involves testers who are authorized to attempt to find and exploit security vulnerabilities. There are different types of penetration testing (e.g. testers are given more or less information about your systems); however, your testers should not be a part of your development team so that they can simulate threat actor behaviours.

8.1 Turn off directory browsing

To prevent leaking potentially sensitive information to users, turn-off directory browsing on your web server. Directory browsing occurs when you can see and access the folders and files that create the website instead of seeing the website as it is meant to look to users. These folders can contain information that is not meant to be viewed by the public, including images, scripts, or backups. Directory browsing is usually implemented on a per-directory basis, and you need to turn off directory browsing in each directory.

You should also create an empty index.htm file in each directory. If the base file, like index.htm or index.php is not available, then by default, anyone can see all the files and the sub-directories listed in the browser. Test each directory and sub directory.

8.2 Remove unnecessary web directory files

As a part of your secure deployment policy, you should review your web directories before and after deploying your website to mitigate the risks associated with data leaks. Web directories can contain information that is not meant to be viewed by the public, including images, scripts, or backups.

You should also define requirements for life cycling web directory files. You should also remove unnecessary web operation files from the web directories. Focus on old version files (multiple default.asp files), source code (.bak), backup files (could contain passwords), and source control files (.svn and .git). To make these files easier to identify, you can turn on last access time on the file system, which enables you to gain a visual of files that used seldomly, if ever. Verify during your code reviews.

8.3 Lock down web service components

To decrease your threat surface, you need to lock down various components of your web services.

You should prioritize locking down, or harden, your web service hosts by removing unused ports, files, and code, and lifecycling unused accounts. If your web servers are left exposed, there is an increased risk that threat actors can exploit these ports and services. These measures can supplement the protections offered through firewalls and security policies.

You should also remove any unnecessary plug-ins in your Configuration Management Systems (CMS). The more plug-ins you have, the greater your attack surface is, especially if the plug-ins are not official.

Additionally, harden the SQL server and remove any unused stored procedures and default accounts in your database. Monitor the SQL server’s outbound connection to detect intrusion.

8.4 Disable browser caching of credentials

Browsers offer to save user passwords for convenience. However, password storage on the user’s browser is not secure. If the user’s mobile device or laptop is stolen and the threat actor accesses the website, the user’s credentials are automatically displayed. When coding this in an HTML form, ensure to set the autocomplete element to off, which tells the browser to turn off credential caching for this form.

8.5 Use vulnerability scanners

You should integrate vulnerability scanning into your secure deployment process. Tools such as the open source OWASP Zed Attack Proxy (ZAP) are commonly used to identify vulnerabilities specific to web applications. You can use these tools to identify vulnerabilities, which can also be used by penetration testers to identify entry points into your web services.

8.6 Automate deployment

Managing secure configurations on all the moving parts of your website can be complicated. Automating the environments is a best practice as it ensures they are built in a repeatable (e.g. can be redeployed if needed) and automated way (i.e. no human intervention). You should define the roles and responsibilities for carrying out configuration management and verification.

You can use security configuration templates and containers. To lower your attack surface, you should containerize to just an image based on a web server. By using templates and containers, you can ensure that new web server versions do not have zero-day bugs. During deployment remember to disable any remote login capabilities so that Secure Shell (SSH) is not allowed in production.

9.1 Conduct monitoring activities

Define your monitoring strategy to identify potential attacks and anomalies specific to web application risks referenced in the OWASP Top 10 ^{Footnote 4}. When conducting monitoring activities for your web application, consider the web service architecture components referenced in Section 3 of this document. Monitor your network traffic, as well as any unsuccessful connection attempts. You should analyze logs and notify the appropriate parties of any unusual activities in a timely manner to ensure an effective response.

9.2 Establish an incident response plan

Establish an incident response plan, including incident playbooks, to define the actions that your organization needs to carry out when an incident is detected. For example, you should include steps for identifying, communicating, containing, and remediating incidents. You should clearly define the roles and responsibilities for incident response, especially if you have multiple teams or organization involved to support your monitoring requirements. Test this plan rigorously to ensure its effectiveness.

If you are working with an MSP or a CSP, work with your service provider to establish a common incident response plan and ensure that you have access with the appropriate data and are notified appropriately. Be sure to coordinate testing activities with your service provider. You should identify the information and the reasonable turnaround times that will enable you to respond appropriately.

For a full list of security monitoring capabilities, see the security control catalogue in Annex 3a of ITSG-33 ^{Footnote 3}, specifically the auditing and accountability [AU] and incident response [IR] security control families.

9.3 Establish a patching strategy

Patch management is your process for acquiring, testing, and installing patches and upgrades on your systems. Your patch management strategy for your web applications will be similar to the patching strategy for your other infrastructure. However, you need to consider and prioritize the architecture components that are exposed to the Internet.

You may want to subscribe to vulnerability and application feeds (e.g. Mitre Common Vulnerabilities and Exposures [CVE] list) so that you can identify vulnerabilities as they become known. There are several well-known and low-cost tools, that you can use to scan for vulnerabilities in your network. Be sure to consider vulnerabilities in library dependencies and containers as well. Another option is to scan for old or outdated software components to update. If your organization cannot implement patches quickly, look at your firewall rules to reduce risks.

If you use managed or cloud services, work with your service provider to apply security patches and updates in a timely manner that meets your requirements. For cloud services, the entity responsible for patching depends on your cloud service model (e.g. in a software-as-a-service model, the CSP is responsible for updating and patching).

9.4 Promote security awareness

As technologies and cyber threats evolve, you can continue to protect your systems, information, and customers from compromises by promoting security awareness. Promote best practices like not clicking on links or downloading files by changing the way that you communicate with your customers. For example, if you need to contact a customer about their account, do not include a link or a downloadable file in the communication. Instead, direct the customer to log in to your website or contact you via the contact information listed on your website. You can recommend that they verify any communications they receive from you and report any suspicious activity.

You can also direct customers to our Get Cyber Safe campaign material, which promotes individual Canadians’ security awareness.

10.1 Talk to your peers

In any industry sector, the issues and concerns you are dealing with, are not necessarily unique. Understandably, it may not be an easy scenario to discuss security issues with competitors. However, keep an eye open for opportunities to discuss product and vendor options, as well as development challenges. You may be pleasantly surprised by how much you can learn from others’ experiences.

10.2 OWASP

The OWASP Foundation is a non-profit foundation that aims to improve the security of software. You can review the OWASP Top 10 ^{Footnote 4} to review their list of critical security risks to web applications.

10.3 Canadian Anti-Fraud Centre

If your organization is the target of fraud, such as a threat actor posing as your organization, contact your local police and file a report online through the Canadian Anti-Fraud Centre’s Fraud Reporting System.

10.4 Contact us

For more information on cyber security, visit our website (cyber.gc.ca) or contact our Contact Centre:

Contact Centre
contact@cyber.gc.ca
613-949-7048 or 1-833-CYBER-88