We all make choices about effort. There are only so many hours in a day, and there are only so many things we can focus our energy on. It’s not just about personal energy, but also resources. Maybe we think we want to put the effort into becoming a fine wine connoisseur, but then after checking out the credit card bill for the month we have second thoughts. Yeah, we are willing to put the time into drinking a bunch of wine…we just don’t want to pay for it.
But that’s fine. Choosing what we put our effort into is a reflection of our values and what we care about. The reason we go to the gym is because we believe the effort will make our lives better, even if it’s difficult and forces us to not sleep in or go to brunch. The reason we save and invest money for a house or retirement or any big purchase is because the effort of sacrifice now will result in returns down the line.
In fact, with both the gym and investing, the effort compounds. Doing it once doesn’t really solve any problems. Even if that one-time effort is extremely intense, it will only have a limited benefit. Consistent, meaningful effort over time, on the other hand, leads to significant results. If you exercise 5 days a week for 30 minutes for a year, you’ll notice an improvement. If you put a little of every paycheck into some kind of (safe) investment for 10 years, you’ll actually end up with quite a lot of money.
Now, let’s qualify all of this. Will you be ready for the Olympics? Probably not. Will you be using your steady investment to purchase a castle? Maybe if it’s like one of those bouncy house castles that they have at kid parties, but other than that I think it’s unlikely. But what you will have is “success” in the broad sense, which is what most people are looking for. Most people understand that fitness doesn’t make you bulletproof and saving won’t make you the Monopoly Man. Your goals, however, will be attained because you executed on a plan.
Effort In Security Assessments
It can be very difficult to feel confident about a security strategy. We want someone to give us a seal of approval or simply avoid an incident. Those things can feel like success, but I don’t think it necessarily inspires confidence. Maybe we should be looking at security more like other disciplines, like fitness or investment, and outline our goals first so we can come up with a plan that fits those goals. Here’s a few goals that I think are worthy for most people or businesses when it comes to security including perhaps a few less obvious ones:
- Data privacy
- Data integrity
- System/data availability
- Accountability (proof that we are secure)
- Public confidence in our security to the point we promote it
- Peace of mind (should not be underestimated)
- Efficiency
Perhaps you have some other goals as well, but I think for most people if you checked off those boxes you would be happy with your security. What kinds of questions should we ask ourselves, as it pertains to effort in the assessment process, that will help us come up with a plan?
- Assets - What assets are we trying to protect? Where do they live and what do we do with these assets? What matters and what doesn’t matter? What’s the impact of an incident?
- A metaphor I often use is a bank. You can steal the pens all day, but you can’t get in the vault easily because they know what assets they need to protect and where it lives. It’s all too common that people try to establish a plan for security without defining what they are protecting first.
- Systems - What systems (technical, physical, management) govern the use of these assets? How complicated are these systems? How accessible or public are these systems to the outside world? Who gets access and under what conditions? When I am working on scoping a security assessment, this is a key concern. The complexity and depth of a system will impact how much effort it takes to truly assess its effectiveness.
- Threat Actors - Who or what threatens my system? Is it common criminals or perhaps nation-states? What about our own staff or competitors?
Those first questions are focused on Threat Modeling, which we talk about a lot. But here’s a few other questions that I think are more about practicality and good management.
- Change – What’s the actual plan with the systems that govern all our assets? A system that undergoes constant change and evolution will require a different approach than one with only modest change over time where perhaps more of a “maintenance” attitude is correct.
- Operational Practicality – How much can we handle? We don’t want the medicine to be worse than the disease, so to speak. Or, if the team doesn’t have the time or resources to fix the items identified in a security assessment, perhaps we need to reassess our goals.
- Accountability – What do we need to demonstrate to provide confidence to our stakeholders that we are on top of security? While the stakeholders are an important part of security planning, they may not always understand some of the details. Security can be tricky to communicate and get buy-in on, so it’s important we make the details as easy to digest as possible.
Some of these questions may have strict and objective answers. Perhaps compliance demands you do at minimum an annual assessment or you have a defined reporting requirement to meet. But some of these details may be a little less clear. Particularly in development, it can be hard to know exactly how a system might evolve over the next few years. That’s OK. It’s more important to understand the general idea as well as how deviations from what you anticipate will affect your assessment plan.
Here's some idea (an oversimplification) of what I would probably recommend for some basic examples:
- A basic web application with public access, hosted in a well-known Cloud environment, some PII but no extremely sensitive information. Development is consistent but no major revisions for a few years. It’s built on front-end/back-end/databases that are considered among the standards. Chances are, an application like this would be fine with an annual application security assessment with a standard set of dynamic testing efforts and reporting, along with remediation testing to validate fixes.
- A corporate environment for a business with under 500 employees, with sensitive intellectual property but nothing like national defense information. Corporate systems are hosted partially on-site and partially in the Cloud. Like most corporate networks, the system goes through occasional overhauls, like new file systems or a migration to a new CRM, but generally in waves. Assuming the systems are not particularly complicated, annual or perhaps bi-annual (depending on rate of change) would be an appropriate cadence for assessment. Actual testing efforts here would probably be more significant and broad than in the first example, since overall the systems are more complicated and you would likely want to test for things like phishing and social engineering.
- An application environment for a well-known public company with thousands of employees, segregated systems based on brands or divisions, complex assets from PII of public figures to proprietary information and more. The company is fast-paced and evolving. This is a very broad example, but testing efforts here would need to be frequent, with multiple teams looking at different aspects of systems and probably testing of some system always happening. Obviously, most organizations aren’t like this, but for some operations security assessments are just a part of the day-to-day business. This just means you must make sure that, say, an annual plan for testing is covering all of your bases realistically. These are also the circumstances where we will have to be willing to change our plans since things are so complicated.
But just because we can make the effort, is it worth it?
A common excuse for not doing something is that we just don’t see the point. The one problem with my metaphor about fitness is that more isn’t necessarily always better. If you push yourself too far, you at best waste effort, or at worst hurt yourself. But is the same thing true for security assessments? What difference does it make if we invest twice the effort in testing? Will we benefit from it?
Well, yes. It makes an objective difference within reason. Manual security testing, whether it’s an application or a network, is about seeing what kinds of attacks a system is susceptible to and how they could be exploited. Here’s some statistics we gathered based on actual testing we did for clients in 2022.
You may notice from this chart that not only did we see that the longer assessments produced more vulnerability results, but that we found higher levels of vulnerabilities with the longer assessments.
We should also understand that effort goes both ways, both from our perspective as trying to secure things as well as those trying to attack us. While we have some advantages by knowing our systems and having information that outsiders probably don’t have, if given enough time and resources, security can be broken. The key is that our testing efforts must be significant enough to find the vulnerabilities that can be exploited from the efforts that our adversaries are willing to put in. If ISE can find more vulnerabilities with longer assessments, by that same logic threat actors will be able to do more damage if they are willing to put in the time. We must be better than them with the tools and resources we have.
So take a little time and think about some of the areas I discussed when either creating or evaluating your approach to security testing. While the applicability of these areas varies from case to case, you can apply these ideas even to modest security management, like protecting your home or a very small business with basic technology.
Want to talk about your approach to security testing? We’re happy to provide some simple advice. Reach out to us today to learn more about how we help our clients successfully navigate these challenges.
