You need to prove that your app is secure. To do that, you may think you just need security testing, such as “penetration testing” or “red teaming.” However, while you do indeed need security testing, you won’t get it right unless your goal is to achieve security excellence. Security excellence is the relentless pursuit of better. It’s about constant improvement. Wherever you are today, be better tomorrow. And then be better the day after that, and the month after that, and the year after that. Don’t wait. Start getting better right now.
That’s the heart of security excellence, and security excellence is the heart of application security. It’s the mindset that leads to security success. You must understand it. You must apply it.
Mindset Part 1: Constantly Seek Improvement
Think of all the ways that Apple has changed the world, whether with computers, music, or phones. They’re certainly defined by overall excellence. They’re also defined by security excellence.
When Apple first launched the iPhone, our research team wanted one badly—partly because it’s awesome, but also because we wanted to hack it. And we wanted to be first.
Problem was, so did every other security researcher. We didn’t have any advantage over anyone. It was a level playing field. We couldn’t get our hands on the device before the release to the general public. Apple wouldn’t reveal anything in advance about what the new system might entail. We couldn’t even skip the line to buy one! We had to camp out in front of the store, just like every other fanatic.
Without early access to the device, it would simply be a race. That was too much of a toss-up. What we needed to do was to create an advantage. We needed to tip the scales in our favor and give ourselves a head start. To do that, we leaned on a simple theory: in the rush to launch by release date, Apple might accidentally port an unresolved security flaw from the desktop operating system to the mobile operating system. We guessed that other researchers wouldn’t consider this angle, and so if we were right, it would give us the advantage we needed. We could consider exploit scenarios in advance, enabling us to be a few steps ahead once we got a device.
Our hunch proved correct.
Apple did indeed carry an unresolved issue over to the mobile operating system: a buffer overflow vulnerability. It’s a flaw whereby attackers can corrupt memory in order to manipulate system functionality—and it delivered full administrative control of the device. We could modify contacts, send text messages, delete photos—anything a user can do, we could do. It represented a catastrophic compromise. Unquestionably, it was a worst-case scenario for Apple.
To prove the concept, we took over the iPhone of a New York Times reporter while it sat on his desk in Manhattan, two hundred miles away from our lab in Baltimore (don’t worry, this was done in collaboration with him as part of the research). As you might imagine, it was quite a vivid demonstration. It made for a great news story.
We achieved our goal, becoming the first company ever to hack the iPhone. But that’s not where the story ends; after all, the entire point of security research is to make things better. We reported the issue to Apple and helped them figure out how to fix it. They issued a patch, eradicating the vulnerability. Millions of people buying iPhones were now safe from this particular flaw.
The key is getting better. Apple, even with all of its money and ridiculously smart people, still introduces vulnerabilities. They’re human just like the rest of us. Yet, this story displayed a few qualities you want to emulate: they fixed their product and made it better. They set out not just to build good products but to build secure products. And they recognized that this work is never done.
That’s how you need to think and behave, too.
Mindset Part 2: Think like a Hacker
To defend against attackers, you need to think like them. Here’s the basic premise:
- Normal users figure out what they’re supposed to do.
- Attackers figure out what they’re not supposed to do. Then they do those things.
Attackers relentlessly look for flaws. They identify assumptions, break systems, and ask “what-if” questions. They don’t follow the rules; they figure out how to break them.
Here’s how to think like an attacker:
Set a goal. In this story, the goal was to bypass the line and the cover charge. To do that, I needed to elevate my privileges from a normal patron to VIP.
Learn how the system works. For example, I observed that the bar required authorization, which is when a system verifies permission to do something (in this case, enter by the VIP line). The purpose of the VIP host is to verify those permissions.
Gather information. To get on the VIP list, I needed to identify a group who was legitimately on it so I could associate myself with that group.
Identify assumptions. The system relied on several assumptions. Some groups have VIP access. A person is authorized to enter by the VIP line if they are with a valid VIP group. A person is assumed to be part of a VIP group if they can produce the group’s name.
Get the system to respond in ways it’s not supposed to. By using specially crafted inputs (my vague, leading statements, paired with my confident demeanor), I got the VIP hostess to reveal secrets, such as the name of a valid VIP group. I then got her to believe that I was a member of that group. She was supposed to keep me out, but as a result of this, she let me in instead.
Exploit. I escalated my privileges from normal patron to VIP, thereby obtaining elevated access I shouldn’t have had. I entered the bar without paying cover or waiting in line. The system was specifically designed to prevent exactly this, and yet I was able to do it anyway — all by thinking like an attacker.
How Mindsets Drive Outcomes
Let’s talk about injecting drugs into your spine.
After a recent security assessment of a drug infusion pump, we met with our client to review the results. We started by explaining the attack scenarios, describing how an adversary could exploit the system.
The CEO quickly interrupted, saying, “This isn’t as bad as you suggest.”
We paused, encouraging him to elaborate.
“Well, even though that could happen, that doesn’t mean it’s worth worrying about,” he said.
Again, we encouraged him to continue.
“Let me put it this way: I drive a BMW,” he said with a smile. “I love that car; I’d hate to see it scratched. Theoretically, someone could haul a piano up onto the roof of our building, throw it down onto my BMW, and destroy the car. But I’m just not worried about that.”
Let that sink in for a moment.
This device injects morphine into your spine. It can literally kill you. We just showed him several ways an attacker could do exactly that. And yet, this CEO rejected the significance of security vulnerabilities that are known to exist in his device. Instead of fixing the problems, he tried to dismiss them.
The United States Food and Drug Administration (FDA), which approves medical devices for use on patients, did not like this CEO’s minimizing attitude toward security. At first, he tried to get their approval without showing them any security assessment reports. When it became clear that the FDA wouldn’t approve without seeing one, he relented and shared the report we supplied him. When they asked about his plan to remediate the issues, he shared that he didn’t intend to. The device was denied approval for use on patients. Unable to sell their product, the company soon went out of business.
It’s a sad story, and I certainly do not celebrate this failure. I’m an entrepreneur myself and prefer to celebrate successes! However, this cautionary tale needs to be shared. It is a powerful demonstration of how mindset dramatically impacts outcomes. They didn’t want to get better, so they didn’t try to get better, and so they simply didn’t get better. It ended badly.
By contrast, a different client of ours did want to achieve security excellence. They knew that security was important to their customers, so despite their small size and limited money, they invested in manual white-box vulnerability assessments—by far the most effective approach but also the most involved (I’ll explain how and why to do this).
Over the next few years, we helped them discover flaw after flaw after flaw. At times, it was unpleasant for them. Yet they kept pursuing their goal.
The engineering practices evolved. The developers got better. They stopped repeating issues. The application got stronger. They learned how to communicate their security philosophy. They earned trust. They won sales.
Eventually, they were acquired for more than $100 million.
I’d be a fool to suggest that they were acquired only because they were secure; they obviously had the makeup of a good acquisition, including sound business fundamentals and a stellar executive team. However, they wouldn’t have been in consideration if they couldn’t prove security. They didn’t just settle for the basics either. They sought greatness. Security excellence is what set them apart from other solutions that might have been acquired instead.
Right Mindset + Right Partnership = Security
Compare these stories side by side. One went out of business, whereas the other produced millionaires. These companies had different mindsets that led to different outcomes, but they reveal the same lesson:
How you think determines what you achieve. Security starts with the right mindset, combined with the right partnership.
Secure your application by hiring a team of experts who are trained to think like an attacker.
Content adapted from:
