In karate, earning a black belt isn’t the end of your journey; it’s just the beginning. It’s the same idea with application security: be proud of the work you’ve put in to get to this point, but you aren’t finished. Things change, forcing you to adapt, which causes your security posture to change, too. Reassessments are how you deal with that reality.
Do reassessments right so they’re more effective, less expensive, and deliver a better partnership.
“Once you know the rules, the game changes.” That’s how a director of application security described how fast the world changes.
Change comes in many forms. All of them require you to revisit your security.
You develop your system constantly. If you’re like most companies in the software business, you’re relentlessly developing new features, streamlining workflows, and improving the user experience. Every single change to your platform changes your attack surface. Whenever you update your application, you might introduce or alter threat vectors; you need to evaluate them for vulnerabilities.
Your development priorities shift. Maybe you see an opportunity in the market or learn that your customers want something that is currently backlogged on your development roadmap. As you adjust, your security model changes. You need to reevaluate how these changes impact your security. As you develop new code, you’ll almost certainly inject new vulnerabilities. You need to address those, too.
Customer demands change. Sometimes they require new security controls. Sometimes they want to change their model, such as moving from software that is hosted on-premises (which runs at their physical site on computers they own and control) to software that is cloud-hosted (which runs remotely on computers owned and controlled by a service provider). Whatever the change, they need assurance that your security meets their new needs.
New attack techniques are invented. Attackers are constantly inventing new ways to exploit systems. You need to constantly investigate these new techniques, too. Security truly is an arms race, and you need to keep up.
Widespread vulnerabilities in core technologies are discovered. The very nature of building software is that you’ll have dependencies. Whether that’s on a cloud provider, third-party libraries, integration of third-party solutions, or some other shared component, your security relies on someone else’s security to some extent. Those third parties are evolving, too, while at the same time, new exploits are discovered in them. You need to reevaluate your system to defend accordingly.
The point is this: change happens. Change impacts your security. To deal with that, you need to adapt. You want to be like the ultimate hackers: squirrels.
Yup, squirrels.
If you’ve ever seen a bird feeder, you’ve seen squirrels defeat almost any attempt to prevent them from stealing the feed. Squirrels don’t care that the feed isn’t for them. To the squirrel, it’s about survival. Steal the feed or die. So they relentlessly adapt to whatever barrier is thrown at them.
That’s the level of intensity you’re up against. That’s how your attackers think, and that’s how you must, too.
Many people mistake security as being a linear process. Do step A, then step B, then step C, and you’re done. But that’s wrong. Security is not a line; security is a loop. Yes, there is a process, but once you finish, you must repeat it. Forever. As an SVP of product management put it, “There’s no finish line for security.”
The process follows a simple formula:
Your security partner has found your vulnerabilities through security assessment; now they need to perform reassessments. In a reassessment, all of the same steps as the initial assessment happen. Analyze changes to the design. Run scans. Look for common vulnerabilities. Abuse functionality. Chain exploits. Look for unknown unknowns. You deploy the same methodology, mindset, and testing types. You pursue the same outcomes.
The initial assessment is to break. The reassessment is to break again.
What additional value do reassessments deliver?
Short answer: a lot.
Our data shows that the impact is clear: important vulnerabilities continue to appear, even in later rounds of assessment. Critical vulnerabilities are found in 30 percent of reassessments, whereas high-severity vulnerabilities are found at nearly double that rate (58 percent of reassessments). A moment ago, we discussed how change impacts your security posture. These numbers quantify that impact. This data also powerfully supports the things you want to do:
Another way to consider the same data is distribution of vulnerabilities, which this graph shows. The data demonstrates that of all critical and high-severity vulnerabilities that are discovered, 7.78 percent of them are found in reassessments.
Pause to think about that. It means that for every one hundred vulnerabilities that exist, almost eight of them are critical or high severity and will only be found in reassessment. No matter how many you find in the initial assessment, you will find more in reassessments.
So how often should you have your security partner perform reassessments?
Short answer: frequently.
Probably more frequently than you currently are.
The right reassessment interval for most apps is every three to six months. Some require more or less frequency, but most fall into this range. However, many companies think about security only annually or every two years. Some consider it even less frequently than that.
If you hit the right cadence, you account for change. If you wait too long, you cede the advantage to your attackers. You leave yourself unnecessarily exposed for too long.
The time frame between assessments should be driven by a variety of factors, such as how rapidly you develop, how valuable your assets are, how much of an attack target you are, and how frequently your customers need assurance. As these factors increase, your time frame between assessments must decrease.
Unfortunately, many companies pace their reassessment intervals on some arbitrary time frame instead. This might be because compliance programs have latched on to the idea of “annual penetration testing” or because many enterprise buyers seem to suggest this, too. Many people think of security like an annual physical exam with your doctor: a necessary but annoying interruption that you do as infrequently as possible, and hope it doesn’t bring bad news. Instead, think of it like nutrition: something you consider constantly. You shouldn’t evaluate your sugar intake once a year; you should evaluate it regularly.
When you implement an appropriate assessment cadence rather than one that’s too long, you’ll find that it is more effective, less expensive, and delivers better partnership value.
It’s pretty common to hear people say that they want to change their security partner every year or two in an effort to get “fresh perspectives.” The spirit of this makes sense: you want to avoid routines or complacency that would cause blind spots. However, keep in mind that the point is about changing perspectives, not necessarily about changing partners.
There are good reasons to change your security partner. If they’re inflexible, hard to work with, or deliver subpar results, you should replace them. Same if they give you bloated and unhelpful reports, rely too heavily on tools rather than manual investigation, or are unable to execute every element needed. Furthermore, even if you aren’t dissatisfied, but you come across a partner who can better achieve your goals, that would be a good reason to change, too. In fact, I’d even go so far as to recommend that you reevaluate your partner right now anyway, given that there are so few security companies who understand (let alone implement) how to do application security right. That means it’s highly likely that you’ve already hired the wrong partner. If you did, that’s a good reason to change, too.
But don’t change just for the sake of change. That’s inefficient and doesn’t necessarily solve your problems anyway.
So how do you change perspectives without changing partners? Here’s how we do it, and I recommend any security partner you hire does the same—because it works:
When these things are done right, it not only gives fresh perspectives, but it also delivers two extra benefits. First, it multiplies expertise. For example, we have some people who dominate firmware projects, whereas others dominate cloud projects. Pairing them on various projects makes both of them better at each other’s specialty. Second, it protects against turnover. Due to the skills shortage in our industry, security professionals are in high demand, constantly subject to poaching. By rotating personnel and transferring knowledge, it ensures that when someone leaves, the rest of the team is still fully operational and efficient in executing your project.
In karate, a black belt is not the end; it’s the beginning. Same idea with security. Once you’ve done your first security assessment, the journey is not over: it’s only just begun. Security is a never-ending loop toward excellence. Keep hacking your app in an ongoing cycle of reassessments.
Because if you’re good, you’re never done.
If you’re not satisfied with your current application security provider, please talk to us. Whether you need security reassessments or vulnerability testing or something entirely different, we can assist you.
Content adapted from: