“So What?” — Telling the Business Story of Security Vulnerabilities
Contextualizing Security Vulnerabilities
As a former penetration tester turned product-focused security professional, one of the most important things I’ve realized is that translating security risk to business impact is crucial in making your work resonate. Often times, the buyer of whatever security offering you’re selling will not care about the granular details of vulnerabilities your tool or service is able to uncover. For security analysts on the front line, contextualizing the “so what?” with the buyer will help build trust and leave a lasting impression.
Stepping into the world of web application security, let’s take a look at some of my favorite vulnerabilities to test for and how each can be succinctly translated to an executive. For these examples, I’ll assume we’re working with a banking client.
SQL Injection
The Technical Story
“I came across functionality within your website that looked to be housed on top of a back end-data store. I crafted SQL injection payloads that returned metadata pertaining to the backend database in the HTTP response body. I then used the technology disclosure to enhance my payloads and enumerate database columns, ultimately extracting and viewing data pertaining to client accounts that I am not provisioned to see.”
The Business Impact
“Your website is vulnerable to SQL injection, which means I can manipulate the database that stores banking accounts you manage. If news were to break that attackers can extract sensitive client information with a few clicks, you’ll ruin the trust you’ve built, and they’ll look to take their business elsewhere. Less clients means less revenue, which means less profit.”
Cross-Site Scripting (XSS)
The Technical Story
“I came across functionality within your website that appears to render unsanitized payloads in the HTTP response body. The page is rendered in HTML, so I injected an XSS payload by closing an open script tag, opening a new one, and including JavaScript that steals the user’s session token (</script><script>alert(document.cookie)</script>). This proves that an attacker can embed malicious JavaScript into the application by taking advantage of missing input sanitization and/or output encoding.”
The Business Impact
“Your website is vulnerable to Cross-Site Scripting, which means I can make your users do things they weren’t intending to. With one click, attackers can redirect them to a site of their choice, steal their username/password, or deface your website entirely. If a successful attack is carried out, you’ll likely be in the news, and your users will lose trust in you quickly. Aside from reputational impact of prospective clients, your current clients will think twice before using your website again, which could lead to lost business.”
Clickjacking
The Technical Story
“Your website does not set the X-Frame-Options header in its HTTP response. I was able to render your website into an HTML frame or Iframe tag and steal the clicks of users. Even worse, I was able to do so on the login page and implement a keystroke logger, allowing me to capture the victim’s keystrokes when he/she entered their username and password.”
The Business Impact
“Your website is vulnerable to clickjacking, which means users’ clicks and keystrokes can be easily captured by an attacker. If an attacker set up a spoofing site, he/she could make it look exactly like yours on the surface and steal the clicks and keystrokes of your clients. If your client entered his/her username and password on a spoofed login page, the attacker would gain possession and could theoretically log in to your real website as your client. Your client would be upset if this happened, and you’ll likely lose their business.”
Cross-Site Request Forgery (CSRF)
The Technical Story
“I utilized CSRF to manipulate payment transfer functionality, re-routing a transfer from the user’s bank account to mine. I intercepted the original HTTP request that transfers money and generated a CSRF PoC. I then manipulated the bank account parameter’s value to equal my account instead of the user’s. While the user is logged in, I crafted a targeted phishing attack and subsequently tricked the user to clicking a URL that executes the request upon clicking. This was accomplished by taking advantage of the browser’s trust in the user’s session.”
The Business Impact
“Your website is vulnerable to CSRF, which means attackers can steal money from your clients if they get tricked into clicking a link. On top of the adverse reputational damage, it’s likely quite resource intensive to clean up and restore stolen funds to your clients. Your clients will likely lose trust in you, which could lead to lost business, and you’d have to allocate overhead to handle the downstream effects of money being stolen.”
Conclusion
At the end of the day, both the technical story and business impact behind vulnerabilities are important to keep a pulse on. As a security professional, you’ll likely end up explaining the technical side more in your day-to-day, but having the business side down is just as important to prove value to the executive-level buyer. When all else fails, remember to put yourself in their shoes, consider the downstream effects, and think “so what?”.
