Risk Appetite in Web Security: How to Take Calculated Risks

Risk appetite can be defined as the type and amount of risk that an organization is willing to accept in order to achieve its business goals, and once you understand your company’s risk appetite you will be in a better position to take the calculated risks it needs to thrive.

While that seems clear enough, it may leave you wondering about the details: what types of risk are we talking about and how do we measure them? Answering both questions is what this article is about.

What is risk appetite in the context of websites? 

Risk appetite in websites means the acceptable level of risk that the website owner or operator is willing to take in pursuit of their business goals. In an ideal case, it would mark the line they draw between calculated risk-taking and unacceptable exposure in the areas of website security, functionality, performance, and compliance. In reality, most organizations aren’t even aware of the risks they face due to the inherent complexity of modern websites. This lack of visibility is one of the main reasons why so many use Reflectiz.

Think of it as a spectrum:

• A low-risk appetite business owner prioritizes extreme security and data protection, even
  if it limits website functionality or performance.
• A high-risk appetite owner might choose insecure free open-source tools over secure paid tools, accepting their higher vulnerability to threats in return for lower costs. 

Every business will need to define its risk appetite across a variety of different scenarios and it will likely be willing to accept different levels for different business activities. The first step in this process is to define risk appetite, and the way to do this is to ask questions,lots of questions, again and again (because it’s an ongoing process). So, here are some examples of what you might ask in order to understand your firm’s risk appetite, divided into the four areas we mentioned above.

Security

Data breaches: How much potential exposure of user data (e.g., email addresses, passwords) do we consider acceptable for specific functionalities?

Third-party integrations: While it’s natural to ask what level of risk is acceptable for integrating with third-party tools or services, it’s a question that’s almost impossible to answer because there are so many variables at play. If such integrations are necessary, then it’s best to use a tool like Reflectiz to mitigate the inevitable risks that they bring. 

Software updates: Are we willing to accept potential downtime or bugs associated with implementing frequent security updates?

Functionality and performance

Downtime: How much downtime is acceptable for maintenance, updates, or unforeseen outages?

Experimental features: Are we willing to roll out new features with some known issues to gain early user feedback?

Third-party scripts: How much of a performance impact are we willing to accept by using third-party scripts for analytics, advertising, or other functionalities?

Compliance and regulations

Data privacy regulations: How closely do we need to adhere to regulations like GDPR, CCPA, or the Cyber Resilience Act, even if doing so imposes limitations on website functionalities (or requires time, resources, and budget)?

Industry standards: How far are we willing to go beyond industry standards for security or accessibility, and incur additional costs or added complexity?

These are just examples. You will obviously go into a lot more depth and detail in each area.

Factors that influence risk appetite

Different industries have different risk tolerances due to regulations, user expectations, and data sensitivity. E-commerce sites will likely have lower risk tolerance for payment processing features, while informational sites might prioritize data security. 

Target audience makes a difference. Websites targeting children or handling sensitive information might have a lower tolerance for risk. Budgetary constraints make a difference too, they might influence the ability to implement advanced security measures or carry out thorough testing.

Who owns your risk appetite?

Cyber risk specialist Matt Tolbert presenting at the 2023 RSA conference argues (from the basis of years of experience in the financial sector) that ultimate responsibility for establishing the organization’s risk appetite lies with the board, but it’s also something that needs to be cascaded to every level of the organization, so that everyone understands what the organization will and won’t do and how they can contribute personally. Following his guidelines to the letter will probably leave you with no time left to run your business, so take these takeaways from his presentation (linked above) as suggestions for consideration:

• Defining risk appetite so you can take calculated risks is an ongoing process, rather than a one-and-done.
• It should be regularly reviewed and adjusted as your business evolves, the threat landscape changes and website goals shift.
• The board defines risk appetite and reviews and approves it (especially as conditions change) through regular discussions with management.
• Management regularly measures and reports on adherence.
• As a company, you embed an understanding of your risk appetite in your organizational processes so that individual personnel know what they can and can’t do. For instance, they will understand what parameters to apply when they’re vetting third-party suppliers.
• Statements and metrics (KRIs/KPIs/KCIs) for all risk-taking activities will act as concrete guidelines that keep staff informed and accountable.

How does risk appetite relate to third-party apps?

While third-party apps offer a convenient way to access valuable functionalities, they also introduce a range of security, privacy, and operational risks. Understanding your risk appetite in this context helps you make informed decisions about what integrations are acceptable and how to manage the risks they bring.

Here’s how risk appetite relates to choosing and using third-party apps:

Integration Decisions

Assessing Risk

Your risk appetite guides which third-party apps you integrate with. If your appetite is low, you might prioritize apps with strong security reputations and established track records. You may also limit yourself to a single tool in high-risk areas, such as integrating just one payment gateway, for instance. Conversely, a higher appetite might allow for exploring newer, more innovative, and cheaper tools despite the potential unknowns.

Negotiation

During negotiations with third-party vendors, your risk appetite will influence the terms you’re looking for. This includes data security guarantees, access controls, incident response procedures, and compliance certifications.

Vendor assessment tools

If you’re going to take a calculated risk on a third-party app, then you might feel tempted to try and gauge the level of risk associated with its vendor, but as we mentioned already, this is something that’s almost impossible to quantify. There are certainly various commercially available tools that will offer you some insights into the reputations of various vendors, but bear in mind that the ratings they offer can never be conclusive, cast-iron guarantees of safety. . 

Reflectiz has bypassed the problem of vendor assessment completely by taking the opposite approach to these reputation-based tools. Instead, the solution maps every integration in your infrastructure and manages them behaviorally. 

Security Questionnaires

CIS Controls

An industry-standard questionnaire covering critical security controls for third-party vendors.

CSA STAR Level

Standardized questionnaire assessing security practices, risk management, and incident response capabilities of cloud service providers.

Additional tools and resources

Data privacy impact assessments (DPIAS)

Analyze potential privacy risks associated with sharing data with the vendor.

Penetration testing and vulnerability scanning

Simulate cyberattacks to identify exploitable weaknesses in the vendor’s software.

Industry reports and analyst reviews

Consult resources like Gartner, Forrester, and industry publications for vendor evaluations and security considerations.

Online Reputation Research

Investigate vendor track records, customer reviews, and any reported security incidents. 

Best Practices

Prioritize vendor selection

Carefully evaluate potential vendors based on security practices, data privacy policies, and compliance certifications.

Contractual safeguards

Clearly define security responsibilities, data governance, incident response procedures, and termination clauses in contracts.

Ongoing monitoring

Continuously monitor vendor security posture, software updates, and emerging threats.

Regular reassessment

Reassess vendor risk regularly, especially after software updates or changes in data handling practices.

Risk Appetite: Inherent risk vs residual risk

Web security risks are generally divided into two types. The first is inherent risk. This describes the fundamental risk, the unavoidable vulnerabilities that are present in a website even before you implement any security measures. You could call it the baseline level of risk that comes just from operating online. Naturally, you will add security solutions to mitigate these baseline risks, and any risks that are still left over after you’ve done this are known as residual risks.

Factors contributing to inherent risks

Hacker ROI

Poorly protected website traffic is a potential goldmine for hackers that doesn’t cost them much to access in terms of hacking effort or expense. If successful they can resell credit card, health, and personal information in bundles for good money on the dark web, which makes this low-effort/high-reward activity a strong motivating factor for criminals. 

Technology limitations

Inherent vulnerabilities in web protocols, operating systems, and software applications. 

Human error

Things like mistakes made by developers, administrators, or users that introduce security gaps.

External threats

The ever-evolving landscape of cyber threats and the evolving tactics of attackers.

Third-party integrations

Third-party app and domain integrations are essential, and a website without them either won’t work or will be too costly to maintain, which makes them an inherent risk. 

Factors contributing to residual risks

Shadow IT

Any IT used by employees without official sanction.

Social Media 

On LinkedIn and others we’re encouraged to share company information that could be compromising.

Effectiveness of controls

Limitations or imperfections in implemented security measures that mean they can be bypassed.

Zero-day exploits

Novel attack methods for which defenses are yet to be developed.

Insider threats

Malicious activity from authorized system users.

Illustrative Examples

• Inherent risk: A website relies on an outdated content management system with known vulnerabilities (unpatched).
• Residual risk: After patching the vulnerabilities, a zero-day exploit targeting the same system remains effective.
• Inherent risk: An e-commerce site stores user credit card information.
• Residual risk: Implementing strong encryption and access controls mitigates risk, but the inherent risk of data theft remains.

Risk Appetite: Managing inherent and residual risk

Risk assessment

Regularly identify and evaluate both inherent and residual risks across your website’s infrastructure, applications, and data.

Prioritization

Focus on mitigating risks with the highest potential impact or likelihood of occurrence.

Control implementation

Implement appropriate security controls tailored to identified risks, like firewalls, intrusion detection systems, code reviews, and security awareness training.

Validation

Validate that your corrective actions and control work. Adopt the attacker’s perspective and try to penetrate the system.

Continuous monitoring

Continuously monitor your systems for vulnerabilities and suspicious activity, adapting your controls as needed.

By understanding and managing both inherent and residual risk, you can make informed decisions about your risk appetite.

Risk appetite vs risk tolerance

 

Both risk tolerance and risk appetite deal with your willingness to accept risk, but they have subtle differences in meaning and application:

Risk tolerance

This refers to the maximum level of risk you are willing to endure before taking action. It defines the threshold for acceptable risk within your overall risk appetite, and more specifically, it focuses on a particular risk or a specific situation, allowing you to set different tolerance levels for different scenarios. It’s often something you deal with reactively.

Risk appetite

This defines the overall level of risk you are willing to take in pursuit of your goals. It establishes the broad framework within which your risk tolerance operates. More generally, it sets a broader direction for risk-taking across your entire organization or project.

Here’s an analogy. Imagine you’re driving across a country.

• Risk appetite: This is your overall speed limit for the entire journey. You might set it at 70 mph, considering your desired arrival time, road conditions, and personal comfort level.
• Risk tolerance: This is how close you’re willing to get to that limit in specific situations. You might tolerate going up to 75 mph on a clear highway but slow down to 55 mph during inclement weather or congestion.

Key differences

• Scope: Risk appetite is broader, encompassing all risks across an organization or project, while risk tolerance is narrower, focusing on specific situations.
• Proactiveness vs. reactiveness: Risk appetite is set proactively, guiding future decisions, while risk tolerance often comes into play after a risk has been identified and requires a reaction.
• Specificity: Risk appetite is more general, while risk tolerance allows you to define different thresholds for different scenarios.

In the context of your website and third-party apps:

• Risk appetite: Determines your overall approach to integrating third-party apps. Are you more focused on security and stability, even if it limits functionality? Or are you open to innovation and experimentation, accepting some additional risk?
• Risk tolerance: Determines how much risk you’re willing to tolerate with specific third-party apps. For example, you might have a lower tolerance for data breaches with apps handling sensitive information, but a higher tolerance for performance issues with non-critical tools.

How to take calculated risks in web security

Using some of the tools we mentioned, take these steps:

Identify risks

Start by identifying potential threats and vulnerabilities in your system. The risks with third parties are the vendor’s level of security, what data the app can access, its own vulnerabilities, what domains it communicates with, and any other problematic actions. Identifying these risks can be difficult, but Reflectiz can help with this stage as it maps every internal, third- and fourth-party component that’s connected to your web infrastructure. If any component exhibits a security risk, Reflectiz will alert you.

Estimate likelihood and impact

Assess the likelihood of each risk occurring and the potential impact on your organization. The likelihood is connected to the vendor’s popularity and how much it spends on security. The impact is linked to the type of information the application is accessing and what type of page it is loaded into. For example, many websites use Google ReCAPTCHA in the login page. This is a good practice because the likelihood of Google ReCAPTCHA being hacked is very low. But the impact is severe – if a hacker gets in he can steal the user’s credentials.

Determine the severity of the risk

Combine the likelihood and impact to determine the overall severity of each risk. This will help you prioritize which risks to address first.

Implement controls

Put measures in place to mitigate the identified risks. This could include anything from installing security patches to implementing stronger access controls.

Reflectiz recognizes that your website is a dynamic environment that is constantly changing in ways that are beyond your control – your third-party vendors also have third-party vendors, and so on. 

This explains the critical need for the controls that we implement to warn you about risky changes and alert you to the most important ones.

With our user-friendly dashboard, you may see alerts like:

• Attention! You are now connected to a new fourth-party application.
• You are now connected to a new domain.
• An application is now accessing extra data.
• An application script was changed.
• An application is now communicating with an additional domain.

Decide what to fix

You can’t hope to eliminate every risk, and there are various reasons why:

Feasibility – it’s impractical to change the entire site architecture beyond once every few years

Cost – changing everything would be too expensive.
Commitments – long-term agreements with vendors mean there are some things you can’t change.
“Corridors politics” – you may not be able to change a certain component because the CTO loves it too much.

Reflectiz will help you to estimate the impact of each fix and identify quick wins.

Learn from peers

Since you’re not the only player in your industry, you can learn from other organizations that are facing the same issues. This is why it is a good idea to implement a risk management solution.

How does Reflectiz’s security baseline help determine the risk appetite for your website?

Reflectiz creates an automated inventory of your digital ecosystem. It maps every asset in your environment so that you can manage them easily. It analyzes what sensitive actions your third-party apps perform, giving you control over your data and your customers’ sensitive information.

With an accurate and up-to-date understanding of your risk exposure, you can formulate your risk appetite, both now and in the future. Sign up today and let Reflectiz empower your business to take the calculated risks you need to succeed.