“Governance, risk, and compliance” (GRC) might be dirty words for many people working in application development and delivery. Strict rules and processes can be obstacles to innovation or meeting project deadlines. However, with security failures causing downtime, lost revenue, leaked customer and proprietary information, and hefty regulatory fines, application teams cannot afford to ignore GRC measures designed to limit the probability and potential for harm.

With the right methodologies and tooling in place, such as a centralized web application firewall (WAF), application teams can build GRC measures into their workflows without frustrating team members or project velocity.

Why is GRC important?

In 2021, the average cost of a data breach to financial industries rose to $5.72 million. The scale of the problem is huge. In 2019 a data breach compromised more than 100 million accounts at Capital One; another breach exposed more than 855 million mortgage and real-estate documents at First American Financial Corp.

The number of attack vectors is increasing. Remote banking means more user accounts containing personal data and more online transactions. Big data means more personal information in one place, providing a tantalizing opportunity for attackers to make a big score. Even as organizations invest in AI-driven innovation, attackers also use more sophisticated bots for farming usernames and passwords and avoiding detection.

Governance, risk, and compliance, when applied to cybersecurity, are not just about box-ticking or avoiding blame. They are necessary for addressing the problems consistently.

Best practices can help application teams to develop and deliver secure products. In addition, following clear guidelines allows organizations to be audited and verified by outside experts. This builds confidence.

DevOps teams build confidence that they are doing the right thing, and clients and regulators build confidence that the organization is trustworthy.

Reducing the cost of GRC

Committing your organization to follow GRC best practices isn’t cost-free. GRC usually adds steps to existing processes and adds extra personnel to do those steps – and validate that those steps have been done. This means projects take more time and more people to complete. And these costs are rising. Deloitte estimates banks’ compliance costs have risen more than 60% since 2008.

Organizations pursuing GRC should also pursue efficiency to avoid ever-growing costs and delays. You can simplify GRC in cybersecurity and introduce efficiencies by adopting the right methodologies and tooling.

Methodologies and Tooling for Efficient GRC

Application teams can avoid expensive delays, revisions, and patches by starting with the right methodologies.

Good security is multi-layered, from application design to developer environments to testing to traffic management to threat intelligence and risk-scoring.

By adopting security principles throughout the design, coding, testing, and delivery pipeline, you can get more right on the first try and avoid costly do-overs. You can read Snapt’s previous advice in these articles.

• Best Practices for Application Data Protection and Fraud Prevention
• Designing Secure Applications
• Secure Coding Practices
• How To Test Application Security
• How Does Threat Intelligence Work?

Tooling can also make a big difference. To manage and protect application traffic effectively and efficiently, you need a modern web application firewall (WAF) that makes it easy to apply and validate consistent security policy.

What does a Web Application Firewall do?

A web application firewall (WAF) is a network function usually deployed in front of application backends. It monitors, filters, and limits traffic between external clients and the application backend. Nothing gets to your application – and no data gets out of your application – without going through the WAF.

A WAF can identify malicious traffic and common attack vectors and can block malicious users and bots from causing downtime (eg. a Denial of Service attack), a data breach (eg. a SQL injection attack), or taking over legitimate user accounts (using bots for a credential stuffing attack). Most WAFs prioritize protection against the OWASP Top 10 vulnerabilities.

The most common way to deploy a WAF is as a reverse proxy, meaning that the WAF acts as an intermediary between clients and the backend systems. Clients communicate only with the WAF, never directly with your backend systems. This process is transparent so clients are unaware that they are communicating with an intermediary. Incoming client requests and outgoing server responses pass through the WAF in both directions. The WAF may deny traffic that violates its security policies.

The WAF is a powerful tool for implementing GRC measures for cybersecurity.

How a modern WAF strengthens cybersecurity

A WAF can filter traffic according to several different strategies:

• Negative security model
• Positive security model
• Machine learning and AI

Your security model has significant implications for GRC, so choose a WAF with a security model that matches your GRC strategy.

What is a negative security model?

A negative security model assumes all traffic is safe unless it is identified as unsafe. Traffic that matches predefined threat signatures or violates a security rule is identified as unsafe.

A WAF with a negative security model will allow all incoming requests by default and will only block requests identified as unsafe.

A negative security model has many problems, including:

• It cannot protect against zero-day exploits or any attack that isn’t in the threat database.
• It cannot protect against attacks that have been modified to be slightly different from known attack signatures.
• It cannot protect against all types of attacks. For example, among the OWASP Top 10 Web Application Security Risks, three of them (A2 [Broken Authentication], A5 [Broken Access Control], and A7 [Cross-Site Scripting]) are not effectively covered by a negative security approach.
• It often provides insufficient protection even against known and identified attacks. For example, A1 [Injection] attacks.

Unfortunately, many WAFs sold today still use the negative security model and do not provide full protection against cybersecurity threats. These products represent a risk to most GRC strategies.

What is a positive security model?

A positive security model assumes that all traffic is unsafe unless it is identified as safe. Traffic that passes security checks and matches the characteristics of legitimate user requests is identified as safe.

A WAF with a positive security model will only allow legitimate users and will block requests displaying anomalies. In some cases, a WAF will allow anomalous traffic but will analyze it further (with a low tolerance for irregular behavior) before making a block decision.

A WAF using a positive and negative security model in combination is much more effective than a purely negative security model at protecting against:

• Unknown attacks
• Modified attacks
• Attacks that look very similar to legitimate user behavior
• Exceptions and edge cases

A good example of the usefulness of a positive security model is bot protection. Bots often avoid detection by cycling through random IP addresses, entering through anonymous proxies, changing their identities, and mimicking human behavior.

To counter the bot threat, a sophisticated WAF using a positive security model should identify suspicious browsing patterns, non-human input, and traffic from questionable sources.

Further, it should also submit suspicious users for intensive evaluation of the user’s input, browsing patterns, browser identifier, location, reputation, and more. It should also compare the client to other known bots, safe browsers, and legitimate bots and spiders to avoid false positives.

Machine learning and AI

Machine learning (ML) avoids static rulesets but uses pattern recognition and profiling from large datasets to determine whether traffic is safe or unsafe. Traffic that matches the learned pattern of unsafe traffic is assumed to be unsafe or suspicious, while traffic that matches the learned pattern of safe traffic is assumed to be safe until new data contradicts this.

A WAF using machine learning is able to generate new profiles and rules that security engineers might not anticipate with static rulesets. In conjunction with AI-based automation, an intelligent WAF can provide a fully automated and self-learning response to emerging threats.

This has interesting conceptual and practical implications for GRC strategies. Conceptually, the applications for ML and AI are some way ahead of GRC – the rulebooks have some catching up to do, so it’s far from as simple as saying, “I have ML in my WAF; therefore, I’m extra compliant”. Practically, ML and AI have demonstrated their effectiveness at blocking zero-day attacks. For example, Snapt Nova’s ML-powered threat intelligence pre-emptively blocked 98% of hosts attempting Log4j exploits before the vulnerability was announced. Furthermore, IBM identified that organizations using security AI were able to mitigate costs by $3.8 million.

Consequently, you should consult with your legal or GRC teams on the impact of ML and AI security automation.

How a centralized WAF improves visibility and efficiency in complex networks

A major part of any GRC strategy is validating that best practices and procedures have been followed. In complex distributed applications, this can be a real challenge. Doing it without incurring high costs and delays is doubly difficult.

With teams, tools, data, and reporting all fragmented and siloed between different locations and environments, how can you ensure that cybersecurity policy (for example, blocklists) has been implemented consistently everywhere?

You need a way to simplify regulatory compliance for your applications at scale to reduce costs and increase agility. This means centralizing your security policies and observability.

A centralized security platform will allow you to:

• Set security configuration for all your applications and APIs in one place and vary it for each location where you operate (to comply with local regulations).
• Push configuration automatically to every node in your network.
• See all your data centrally and validate that policy has been implemented
• Receive smart multi-channel alerts when problems arise (via webhook, Slack, email, SMS, etc.).
• Apply role-based access control and maintain accountability through complete user logging.

There are a few ways to achieve this.

Orchestration and Integration

You can use an orchestration platform and API-friendly WAFs to centralize your security policy and keep all of your WAFs synchronized. Your WAFs can feed telemetry back to your orchestration platform for reporting and automation.

This architecture is complex and relies on sourcing components from multiple vendors and ensuring they integrate seamlessly. This is a challenge for most teams. Even with the best components, scaling such a system can be extremely expensive.

Centralized Application Services Platform

Alternatively, you can use a WAF or an application services platform (providing WAF alongside load balancing and other functions) with a centralized control plane that puts all your policy, controls, data, and reporting in one place.

A centralized platform allows security teams to meet GRC targets efficiently, applying consistent policy to complex global networks from one central UI or automated via API. It also provides instant feedback and validation that configuration is applied correctly in every node in your network.

A single unified platform avoids the complexity, cost, and scalability challenges associated with orchestration platforms and multiple vendors and licensing agreements.

This provides the best combination of GRC-friendly tooling, efficiency, and agility for application teams to continue to deliver innovation.

Modern cybersecurity tooling reduces the cost of meeting your GRC mandate

Application and security teams delivering on their GRC mandate need to pull off an incredible balancing act. Product teams want shorter time-to-market; revenue teams want lower unit costs; and compliance teams want less risk and audits passed. Meanwhile, developers mostly just want to build cool stuff.

The right tooling can help resolve this conundrum.

Request a trial of Snapt Nova to set up an enterprise POC and see the difference it makes in your organization.

Guest post originally published on the Iwan Price-Evans
Source CNCF