Understanding Attack Surfaces: A Marketer's Guide to the Way Systems Break

You're writing marketing copy for your security product. The engineer says, "Our solution reduces the attack surface by 70%."

You nod. You write it down. You have no idea what it actually means.

Or maybe you're evaluating a vendor. They mention their "minimal attack surface" as a key differentiator. Is this marketing fluff or a real advantage? You can't tell.

Attack surface isn't jargon. It's a fundamental concept that explains how systems get compromised. Understanding it changes how you communicate about security, evaluate products, and identify actual risk.

This guide explains attack surfaces from a systems perspective. No hand-waving. No "imagine your house has doors and windows" metaphors. Just the actual mechanics of how attackers find ways in.

What Is an Attack Surface?

An attack surface is the sum of all possible entry points where an unauthorized user could attempt to access or extract data from a system.

Think of it as exposure. Every interface, every connection, every way your system interacts with the outside world is a potential point of compromise.

The larger the attack surface, the more opportunities for attack. The smaller the attack surface, the fewer ways in.

But size isn't the only factor. Attack surfaces have different characteristics:

• Complexity (simple vs. intricate)

• Visibility (public vs. hidden)

• Strength (well-defended vs. vulnerable)

• Value (high-value targets vs. low-value)

Understanding these dimensions helps you evaluate actual risk, not just count entry points.

The Three Categories of Attack Surface

Every attack surface breaks down into three main categories. Each has different characteristics and defense requirements.

1. Network Attack Surface

This is everything accessible over a network. The digital perimeter of your system.

Components:

• Public-facing web applications

• APIs accessible from the internet

• Email servers

• DNS servers

• VPN endpoints

• Remote desktop services

• Cloud infrastructure endpoints

• IoT devices connected to networks

Why it matters: Network attack surface is what attackers probe first. It's remotely accessible, often from anywhere in the world. No physical access required.

Example: A company runs:

• A public website (1 entry point)

• A customer API (1 entry point)

• An admin panel (1 entry point)

• Email server (1 entry point)

• Employee VPN (1 entry point)

Network attack surface: 5 major entry points. Each can be probed, scanned, and potentially exploited remotely.

How attackers exploit it:

• Port scanning to find open services

• Vulnerability scanning for known weaknesses

• Automated exploitation of unpatched systems

• Brute force attacks on login pages

• API endpoint enumeration and testing

2. Physical Attack Surface

This is everything accessible through physical access to hardware or facilities.

Components:

• Servers in data centers

• Employee workstations

• USB ports and peripheral connections

• Network jacks in offices

• Disposal of old hardware

• Physical documents

• Building access points

Why it matters: Physical access often bypasses digital security measures. If someone can touch your hardware, they can potentially compromise it.

Example: An office has:

• 50 employee laptops (50 entry points)

• 5 servers in a closet (5 entry points)

• USB ports on all workstations (50+ entry points)

• Network jacks throughout the office (100+ entry points)

• Printer with hard drive (1 entry point)

Physical attack surface: 200+ entry points. Each represents a potential compromise if physical security fails.

How attackers exploit it:

• Installing keyloggers on accessible keyboards

• Booting from USB drives to bypass OS security

• Network taps on accessible network cables

• Stealing hard drives with sensitive data

• Dumpster diving for documents or discarded equipment

3. Social Engineering Attack Surface

This is everything accessible through manipulating people. The human element.

Components:

• Employees with system access

• Help desk personnel who can reset passwords

• Executives who might be targeted for credential theft

• Third-party contractors with access

• Customer service reps with database access

• Anyone who receives company email

Why it matters: Humans are often the weakest link. Technical security is irrelevant if someone tricks an employee into handing over credentials.

Example: A company has:

• 100 employees with email accounts (100 potential phishing targets)

• 20 employees with admin access (20 high-value targets)

• 10 developers with code repository access (10 critical targets)

• 5 executives with financial system access (5 extremely high-value targets)

• 3 help desk staff who can reset passwords (3 privilege escalation points)

Social engineering attack surface: Everyone with access. The more people with access, the more opportunities for manipulation.

How attackers exploit it:

• Phishing emails to steal credentials

• Pretexting (pretending to be IT support) to get passwords reset

• Baiting (leaving infected USB drives in parking lots)

• Quid pro quo (offering services in exchange for access)

• Tailgating (following employees into secure areas)

How Attack Surfaces Expand (And Why It Matters)

Systems don't stay static. Attack surfaces grow over time, often without anyone noticing.

Growth Vector 1: Feature Addition

Every new feature potentially expands attack surface.

Example scenario:

Year 1: Company launches with a simple web application.

• Attack surface: 1 web app, 1 database

Year 2: Add mobile app with push notifications.

• Attack surface: 1 web app, 1 mobile API, 1 notification service, 1 database

• Increase: 2 new entry points

Year 3: Add third-party integrations (payment processing, analytics, CRM).

• Attack surface: Previous + 3 external API integrations, 3 authentication mechanisms

• Increase: 6 new entry points

Year 4: Add admin dashboard, reporting features, data export.

• Attack surface: Previous + 1 admin panel, 1 reporting engine, 1 export service

• Increase: 3 new entry points

Total: From 1 entry point to 12+ entry points in 4 years.

Each addition made business sense. But the cumulative effect is a dramatically larger attack surface.

Growth Vector 2: Third-Party Dependencies

Modern software relies on external services and libraries. Each dependency expands attack surface.

Example dependency chain:

Your application uses:

• AWS for hosting (introduces AWS-specific vulnerabilities)

• Stripe for payments (introduces payment API as attack vector)

• SendGrid for email (introduces email service as vector)

• Google Analytics (introduces tracking script as potential injection point)

• 50 npm packages (each with potential vulnerabilities)

Each dependency is part of your attack surface. If any of them have vulnerabilities, you inherit those vulnerabilities.

Real-world impact: The 2017 Equifax breach exploited a vulnerability in Apache Struts, a dependency. Equifax's own code wasn't vulnerable. Their dependency was.

Growth Vector 3: Legacy Systems That Never Get Removed

Old systems accumulate. They often stay accessible even after replacement.

Common pattern:

Version 1.0: Original system built and deployed Version 2.0: New system built to replace it, but v1.0 stays online "just in case" Version 3.0: Yet another rebuild, but v1.0 and v2.0 still accessible

Result: Three versions running simultaneously, each with its own vulnerabilities. Attack surface tripled.

Why this happens:

• Fear of breaking dependencies

• Lack of documentation on what uses old systems

• "It's working, don't touch it" mentality

• Migration complexity

Growth Vector 4: Shadow IT

Employees use tools IT doesn't know about or approve.

Examples:

• Marketing uses an unapproved analytics tool

• Sales uses a Chrome extension for LinkedIn automation

• Developers use a third-party logging service

• Finance uses a personal Dropbox for file sharing

Each shadow IT tool expands attack surface. IT can't secure what they don't know exists.

Growth Vector 5: Acquisitions and Mergers

Company A acquires Company B. Both systems must integrate.

Before merger:

• Company A: 50 servers, 10 applications, 100 employees

• Company B: 30 servers, 8 applications, 60 employees

After merger:

• Combined: 80 servers, 18 applications, 160 employees

• Plus: Integration points between the two networks

• Plus: Employees now have access to both systems

• Plus: Different security standards that must be reconciled

Attack surface doesn't just add. It multiplies because of new integration complexity.

The Anatomy of an Attack Surface Element

Let's examine what makes up a single entry point in detail. Understanding this helps you evaluate risk.

Element: A Public-Facing API

Example: Your company exposes a REST API for customers to access their data.

What makes this an attack surface:

1. Endpoints Every API endpoint is a potential entry point.

• GET /api/v1/users (retrieve user data)

• POST /api/v1/users (create user)

• PUT /api/v1/users/{id} (update user)

• DELETE /api/v1/users/{id} (delete user)

Each endpoint can be tested for vulnerabilities.

2. Authentication Mechanisms How does the API verify who you are?

• API keys (can be stolen or leaked)

• OAuth tokens (can be compromised)

• Session cookies (vulnerable to hijacking)

• JWT tokens (can be forged if implementation is weak)

Each authentication method has attack vectors.

3. Input Validation What happens if you send unexpected data?

• SQL injection (malicious database queries)

• Cross-site scripting (injecting malicious scripts)

• Command injection (executing system commands)

• Path traversal (accessing unauthorized files)

Poor input validation = exploitable attack surface.

4. Rate Limiting Can attackers make unlimited requests?

• Brute force attacks on authentication

• Denial of service through resource exhaustion

• Data scraping at scale

Lack of rate limiting = expanded attack surface.

5. Error Messages What information do errors reveal?

• Stack traces (show internal code structure)

• Database errors (reveal schema and queries)

• File paths (show system architecture)

Verbose errors = information leakage = larger attack surface.

6. Dependencies What libraries and frameworks does the API use?

• Web framework (Express, Django, Flask)

• Database driver

• Authentication library

• Validation library

Each dependency with known vulnerabilities expands attack surface.

This single API endpoint is actually dozens of potential attack vectors. Multiplied across all your endpoints, the attack surface grows exponentially.

Real-World Attack Surface Analysis

Let's analyze actual products to see how attack surface manifests in practice.

Case Study 1: Gmail (Large, Complex Attack Surface)

Network Attack Surface:

• Web application (gmail.com)

• Mobile apps (iOS, Android)

• IMAP/SMTP/POP3 protocols for email clients

• OAuth API for third-party integrations

• Chrome extensions that access Gmail

• Google Workspace integrations

Physical Attack Surface:

• Google data centers (highly secured)

• User devices accessing Gmail

• Cached email on local devices

Social Engineering Attack Surface:

• 1.8 billion users (massive phishing target pool)

• Gmail addresses used as recovery emails for other services

• "Sign in with Google" used across the web

Why the large attack surface is managed:

• Massive security team

• Automated vulnerability scanning

• Bug bounty program

• Continuous monitoring

• Multi-factor authentication as standard

• Advanced phishing detection

Lesson: Large attack surface isn't inherently bad if you have resources to defend it properly.

Case Study 2: WhatsApp (Minimized Attack Surface by Design)

Network Attack Surface:

• Mobile apps (iOS, Android, limited desktop)

• End-to-end encryption by default

• Minimal web interface

• No public API

• No third-party integrations

Physical Attack Surface:

• User devices only

• No server-side message storage (reduces data breach risk)

Social Engineering Attack Surface:

• 2+ billion users (large)

• But limited attack vectors due to encryption

• Group invite links (potential spam/scam vector)

Design choices that minimize attack surface:

• No usernames (phone numbers only, harder to enumerate)

• End-to-end encryption (even WhatsApp can't read messages)

• Minimal features (no games, no bots, no extensions)

• No public API (can't build third-party tools)

Lesson: Deliberate feature limitation reduces attack surface. Every feature not built is an attack vector that doesn't exist.

Case Study 3: Traditional Enterprise Software (Attack Surface Explosion)

Typical enterprise system:

Network Attack Surface:

• Main application (web-based)

• Legacy desktop clients (still in use)

• Mobile apps

• Admin panels

• Reporting dashboards

• Developer API

• Partner API

• SFTP server for data imports

• Email integration

• Calendar integration

• SSO integration with Active Directory

• Database with remote access enabled

Physical Attack Surface:

• On-premise servers

• Employee workstations with local data

• Backup tapes in storage

• Old servers not yet decommissioned

Social Engineering Attack Surface:

• 500+ employees with various access levels

• 50+ admin users

• 20+ third-party vendors with access

• Contractors with temporary access (sometimes never revoked)

Why enterprise attack surfaces are so large:

• Accumulated over decades

• Multiple integration requirements

• Backward compatibility demands

• Compliance requirements for data retention

• Fear of breaking existing workflows

Lesson: Enterprise attack surfaces grow organically without deliberate management. Technical debt compounds security risk.

How Attackers Think About Attack Surfaces

Understanding the attacker's perspective helps you prioritize defense.

Reconnaissance: Mapping the Attack Surface

Step 1: Discovery Attackers don't start by hacking. They start by mapping what exists.

Tools and techniques:

• DNS enumeration (finding all subdomains)

• Port scanning (identifying open services)

• Web crawling (discovering all pages and endpoints)

• Google dorking (finding exposed information via search)

• Shodan searches (finding internet-connected devices)

• LinkedIn reconnaissance (identifying employees and their roles)

What they're building: A complete map of your attack surface.

Step 2: Prioritization Not all attack surface is equally valuable. Attackers prioritize.

High-priority targets:

• Admin panels (highest privilege)

• APIs with authentication bypass potential

• File upload functionality (potential for code execution)

• Database access points

• Systems with known vulnerabilities

Low-priority targets:

• Static marketing pages

• Well-secured login forms with rate limiting

• Services with no obvious value

Step 3: Vulnerability Assessment For each entry point, test for weaknesses.

Common vulnerability checks:

• Default credentials

• Known CVEs (Common Vulnerabilities and Exposures)

• SQL injection

• Cross-site scripting

• Authentication bypasses

• Authorization flaws

Step 4: Exploitation Once a vulnerability is found, exploit it to gain access.

Common exploitation paths:

• Low-privilege access → privilege escalation → admin access

• External access → internal network pivot → sensitive systems

• Social engineering → credentials → legitimate access

What this means for defense: Attackers systematically probe your entire attack surface. Defense must be equally systematic.

Attack Surface Reduction: Practical Strategies

Understanding attack surfaces is useful. Reducing them is valuable.

Strategy 1: Remove Unnecessary Exposure

Principle: The best defense for an attack surface is for it not to exist.

Implementation:

Audit all public-facing services:

• Is this service still needed?

• Does it need to be publicly accessible?

• Can it be moved behind authentication?

• Can it be moved behind a VPN?

Example: Company has an admin panel accessible from the internet.

Before:

• Admin panel: admin.company.com (publicly accessible)

• Attack surface: Anyone can try to break in

After:

• Admin panel: Only accessible via VPN

• Attack surface: Must compromise VPN first (additional barrier)

Impact: Removed entire attack vector from public internet.

Close unused ports and services:

Before: Server has ports 22 (SSH), 80 (HTTP), 443 (HTTPS), 3306 (MySQL) open.

Audit:

• Port 22: Needed for maintenance

• Port 80/443: Needed for web traffic

• Port 3306: Why is database accessible from internet?

After: Close port 3306. Database only accessible from application server.

Impact: Eliminated direct database attack vector.

Strategy 2: Consolidate Entry Points

Principle: Fewer entry points = smaller attack surface to defend.

Implementation:

Replace multiple services with single, well-secured gateway:

Before:

• Service A has its own login

• Service B has its own login

• Service C has its own login

• Attack surface: 3 separate authentication systems to secure

After:

• Single sign-on (SSO) with one authentication system

• Services trust SSO authentication

• Attack surface: 1 authentication system to secure (but must be extremely robust)

Trade-off: Single point of failure if SSO is compromised, but dramatically easier to secure one system well than three systems adequately.

API Gateway Pattern:

Before:

• 10 microservices, each with its own public endpoint

• Attack surface: 10 separate entry points

After:

• 1 API gateway that routes to microservices

• Microservices only accessible from gateway

• Attack surface: 1 entry point (gateway)

Benefits:

• Centralized authentication

• Centralized rate limiting

• Centralized logging

• Easier to monitor

Strategy 3: Minimize Third-Party Dependencies

Principle: Every dependency inherits its vulnerabilities.

Implementation:

Audit dependencies:

• What npm packages, Python libraries, or gems are you using?

• Are they all necessary?

• Do they have known vulnerabilities?

• Are they actively maintained?

Remove unused dependencies: Many projects accumulate dependencies that are no longer used.

Before:

• 150 npm packages in package.json

• 50 are actually used

• Attack surface: 150 packages × average 2 vulnerabilities = 300 potential issues

After:

• Audit and remove unused packages

• 50 packages remain

• Attack surface: 50 packages × average 2 vulnerabilities = 100 potential issues

Impact: 66% reduction in dependency attack surface.

Evaluate alternatives: Sometimes you can replace complex dependencies with simpler ones or native functionality.

Example: Using a 20MB library just to format dates when native JavaScript can do it.

Before:

• Dependency: moment.js (large, deprecated)

• Attack surface: Entire library + its dependencies

After:

• Use native Intl.DateTimeFormat

• Attack surface: Zero additional dependencies

Strategy 4: Implement Defense in Depth

Principle: Multiple layers of security reduce risk even if attack surface is large.

Implementation:

Layer 1: Network

• Firewalls

• DDoS protection

• Rate limiting

Layer 2: Application

• Input validation

• Output encoding

• Authentication and authorization

Layer 3: Data

• Encryption at rest

• Encryption in transit

• Data access controls

Layer 4: Monitoring

• Intrusion detection

• Anomaly detection

• Audit logging

Even if attackers breach one layer, others remain.

Example: Attacker finds SQL injection vulnerability (breaches application layer).

Without defense in depth:

• Direct database access

• Can read/modify all data

With defense in depth:

• Database layer: Separate credentials with limited permissions

• Data layer: Sensitive data encrypted

• Monitoring layer: Unusual queries trigger alerts

Impact: Vulnerability exists, but exploitation is limited and detected.

Strategy 5: Principle of Least Privilege

Principle: Every user, service, and system should have the minimum access required to function.

Implementation:

User access:

Before:

• All developers have production database access

• Attack surface: 20 developers could accidentally or maliciously access customer data

After:

• Only senior engineers have production access

• Others use anonymized development databases

• Attack surface: 5 senior engineers with access (and stronger audit controls)

Service accounts:

Before:

• Application uses root database credentials

• Attack surface: If application is compromised, full database access

After:

• Application uses account with SELECT/INSERT/UPDATE only (no DELETE, no admin functions)

• Attack surface: Compromise is limited to data modification, not total destruction

API permissions:

Before:

• API key has full access to all endpoints

• Attack surface: Leaked key = complete compromise

After:

• API keys scoped to specific resources and actions

• Read-only keys for analytics

• Write keys for specific resources only

• Attack surface: Leaked key = limited compromise

Communicating About Attack Surfaces

If you're in marketing, sales, or customer-facing roles, you need to communicate about attack surfaces accurately.

What NOT to Say

Don't say: "We have zero attack surface."

Why it's wrong: If your product does anything, it has an attack surface. Zero attack surface = zero functionality.

What to say instead: "We've minimized our attack surface through [specific measures]."

Don't say: "We're unhackable."

Why it's wrong: Nothing is unhackable. This is provably false and damages credibility.

What to say instead: "We employ defense-in-depth strategies and continuous security monitoring to protect against attacks."

Don't say: "Our competitors have huge security problems."

Why it's wrong: Unless you're citing specific, public disclosures, this is speculation and potentially defamatory.

What to say instead: "Our architecture minimizes attack surface through [specific design choices], which differs from common approaches."

What TO Say (With Specifics)

Good claim: "We reduce attack surface by 70% compared to traditional deployments."

Support it with:

• Traditional deployment: 10 public endpoints

• Our deployment: 3 public endpoints

• Reduction: 70%

Good claim: "Our API uses OAuth 2.0 with short-lived tokens to minimize credential exposure."

Why it's good: Specific, verifiable, explains actual security mechanism.

Good claim: "We practice least privilege access, with role-based permissions that limit exposure from any single compromised account."

Why it's good: Describes actual security practice, explains defense-in-depth.

Good claim: "Our architecture eliminates [specific attack vector] by [specific design choice]."

Example: "Our architecture eliminates SQL injection vulnerabilities by using parameterized queries exclusively."

Why it's good: Specific vulnerability, specific countermeasure, verifiable claim.

Attack Surface in Product Marketing

Understanding attack surface helps you position products more effectively.

For Security Products

Positioning framework:

Problem: Customer has large, complex attack surface Agitation: Every entry point is a potential breach Solution: Your product reduces attack surface by [specific mechanism]

Example messaging:

Weak: "Our product makes you more secure."

Strong: "Our product consolidates 50+ security tools into a single platform, reducing your attack surface from dozens of separate systems to one hardened interface."

Why it's better: Specific, quantifiable, explains mechanism.

For SaaS Products

Competitive differentiation:

Your product:

• Minimal third-party dependencies

• No third-party scripts in frontend

• All data encrypted at rest

• Zero-knowledge architecture (you can't access customer data)

Competitor product:

• 50+ third-party analytics and tracking scripts

• Customer data accessible by vendor

• Additional integrations increase attack surface

Messaging: "Unlike traditional solutions that expand your attack surface with dozens of third-party integrations, our zero-knowledge architecture ensures we can't access your data even if we wanted to."

For Web3/Blockchain Products

Unique attack surface considerations:

Smart contract attack surface:

• Every public function is an entry point

• Immutable code means vulnerabilities can't be patched

• Economic incentives make attacks profitable

Messaging approach:

Weak: "Our smart contracts are audited."

Strong: "We minimize smart contract attack surface through:

• Minimal public functions (3 vs. industry average of 15)

• Formal verification of core logic

• Multiple independent audits

• Bug bounty program with $1M+ in rewards

• Time-locked upgrades for additional security layer"

Why it's better: Specific measures, quantifiable differences, demonstrates depth of security thinking.

The Business Case for Attack Surface Reduction

Security isn't just technical. It's a business decision.

Cost of Large Attack Surface

Direct costs:

• More infrastructure to monitor and secure

• Larger security team required

• More expensive security tools (priced per endpoint)

• Higher insurance premiums

• Compliance costs scale with attack surface

Indirect costs:

• Slower development (more surfaces to secure)

• Increased breach risk

• Potential regulatory penalties

• Customer trust impact

• Incident response costs

Example calculation:

Large attack surface company:

• 100 public services to monitor

• Security team of 10 people @ $150K average = $1.5M/year

• Security tools at $50K/year per service = $5M/year

• Insurance: $500K/year

• Total: $7M/year in security costs

Reduced attack surface company:

• 20 public services to monitor

• Security team of 5 people @ $150K average = $750K/year

• Security tools at $50K/year per service = $1M/year

• Insurance: $200K/year

• Total: $1.95M/year in security costs

Savings: $5.05M/year

ROI of Attack Surface Reduction

Investment: 6 months of engineering time to consolidate services, remove legacy systems, implement API gateway.

Cost: 3 engineers × 6 months × $75K/year = $225K

Annual savings: $5M in ongoing security costs

Payback period: 0.54 months (less than 3 weeks)

Additional benefits:

• Reduced breach risk

• Faster development velocity

• Simpler architecture

• Easier compliance

• Better performance

This is why attack surface reduction matters to business leaders.

Your Action Plan: Applying This Knowledge

Here's how to use attack surface thinking in your role.

For Marketers

Week 1: Audit your messaging

• Review all security claims in your materials

• Identify vague or unsupported claims

• Replace with specific, verifiable statements

Week 2: Interview your security team

• Ask: What's our biggest attack surface?

• Ask: How do we minimize it?

• Ask: What makes us different from competitors?

Week 3: Create specific messaging

• Document 3-5 specific ways your product reduces attack surface

• Create comparison content showing before/after

• Develop case studies with quantifiable improvements

Week 4: Test messaging with prospects

• Present technical security benefits

• Gauge understanding and resonance

• Refine based on feedback

For Product Managers

Week 1: Map your attack surface

• List all public-facing services

• List all third-party integrations

• List all user access points

Week 2: Prioritize reduction opportunities

• Which surfaces are largest?

• Which are most vulnerable?

• Which provide least value?

Week 3: Quantify reduction options

• If we consolidate X and Y, attack surface reduces by Z

• If we remove legacy feature, we eliminate N entry points

• Document trade-offs

Week 4: Build business case

• Calculate security cost savings

• Estimate breach risk reduction

• Present to leadership

For Founders

Week 1: Review architecture decisions

• Are we adding features without considering attack surface?

• Do we remove old systems when replacing them?

• Do we track attack surface growth?

Week 2: Establish policies

• Every new feature must consider attack surface impact

• Quarterly review of services to identify removal candidates

• Third-party integrations require security review

Week 3: Educate team

• Share attack surface concepts with engineering

• Make it a regular consideration in design reviews

• Celebrate attack surface reduction alongside feature launches

Week 4: Measure and track

• Define metrics (number of public endpoints, number of dependencies)

• Set targets for reduction

• Review quarterly

Final Thoughts: Attack Surface as a Mental Model

Attack surface isn't just a security concept. It's a way of thinking about system design and risk.

Every feature adds surface. Understanding this helps you make informed trade-offs between functionality and security.

Every integration adds surface. This helps you evaluate whether the value of an integration exceeds the security cost.

Every dependency adds surface. This guides decisions about build vs. buy and library selection.

Attack surface compounds over time. Without active management, it grows indefinitely. Deliberate reduction must be part of development culture.

You don't need to be a security engineer to understand attack surfaces. You need to think in systems: where are the entry points, what are the vulnerabilities, what's the exposure?

This mental model makes you more effective whether you're marketing a security product, evaluating vendors, making product decisions, or just trying to understand why security matters.

The attack surface is always there. Now you can see it, measure it, communicate about it, and help reduce it.