Tim MalcomVetter has been building and breaking computer systems since the 1980s. As NetSPI's Executive Vice President of Strategy Tim is focused on disrupting the proactive security category, helping NetSPI maintain our high standard of service, and retaining our team's top-notch culture of passionate innovation.
He brings an insightful background as a security analyst, pentester, director of red team, and chief technology officer for some of the most prominent companies across the globe. Tim's accomplishments include:
• Startup exit to a world leading private equity firm
• Scaling a security business to 300% growth in a little over a year
• Building the Red Team program at the world’s largest company
• Advising and consulting startups, enterprises, and mergers & acquisitions
• Leading high performing teams of engineers
• Hacking everything from mainframes, web APIs, mobile apps, to IoT
• Holding an academic university cybersecurity research fellowship
• Presenting at numerous technical conferences
• Contributing to open-source software and frameworks like MITRE ATT&CK
There are nearly countless tools in our industry right now that can give us an inventory of our external facing assets, laid out neatly for our teams to tackle.
But, how do you know which of those high-scoring vulnerabilities is actually going to be the most impactful on your particular environment? Does your team know how to interpret the assessments these tools provide while considering your company’s external attack surface? Has the assessment really given you what you need to validate and prioritize the identified risks?
We dove deep into these questions – and more – during this live event! As part of our “Let’s Talk Proactive Security” series, NetSPI CEO Aaron Shilts sat down with our EVP of Strategy Tim MalcomVetter to pick apart these questions and give guidance on how to approach external attack surface management in the right way for your company.
What is proactive security? How must pentests evolve to stay relevant and valuable? What makes an effective red team? What parallels can be drawn between managing a household of six children and a 400+ person security team?
Get answers to these questions – and more – during this event as NetSPI CEO Aaron Shilts sits down with EVP of Strategy Tim MalcomVetter to discuss:
Hot takes on a variety of proactive security topics
Effective red team operations
Security testing maturity levels
Tim recently joined NetSPI bringing an incredibly insightful background as a security analyst, pentester, director of red team, and chief technology officer for some of the most prominent companies around the globe. During which he built the red team program at the world’s largest retail company, led high performing teams of security engineers, and hacked everything from mainframes to APIs to mobile to IoT devices.
Let’s deep-dive into the world of proactive security together! 🤿
Today, I'm excited to be chatting with Tim MalcomVetter, a member of our executive team. We first crossed paths 10 years ago, and I've been fascinated by his career journey, from a hands-on practitioner all the way to the executive ranks. We're thrilled to have him onboard, working closely with our customers and leading his team in strategic initiatives that directly benefit our customers. Now, Tim’s title is EVP of Strategy, which might sound similar to a "VP of Special Projects," but his role goes far beyond that.
Welcome to NetSPI, Tim! What are you most excited to tackle in your role here?
A significant part of my work involves thinking disruptively and asking, "How can we revolutionize penetration testing? How can we push the boundaries and make them even more impactful than they've been in the past 20 years?"
This drives me to explore continuous testing and find ways to bridge the gap between the advanced security practices of well-funded programs and the needs of enterprises, both large and small. Many smaller companies may not even know where to begin, and that's where I find my true purpose — helping businesses of all sizes adopt robust security measures. This is what excites me about my future at NetSPI, and ultimately, why I'm here.
Tim and I have known each other for more than a decade. What was the hottest thing in security when we first started working together (2014)?
Application security was reaching maturity by that point—it was a thing that stood on its own. But enterprises were still early in the early stages of adopting it. Credit cards were still what people were really concerned about, like ransomware. The first ransomware was 10 years ago. When I started red teaming, and even pentesting, we were all concerned about credit cards, especially when you work with different merchants, that's the number one thing that bothered them.
Now, red teams don’t even go for that hardly at all. The black market isn’t selling stolen cards the same way. You used to get a lot of value out of them. But now the banks have figured out how to detect fraud. The merchants have become largely very mature. And there's credit card tokenization and scope reduction and all this stuff. We used to do this crazy stuff where we would attack credit card tokenization systems; we were using timing analysis where you'd send a request and see if it is 50 milliseconds or 80 milliseconds to get the response back. The difference in time indicated whether we’d hit an existing token. It was weird, though, the things we would do now. Now nobody cares what that’s like, it's just gone.
What is proactive security? How do you define it?
I think offensive security is probably a deep joke that some red teamer thought of, you know, ‘You guys are defensive, so I'll be offensive.’ Am I offensive or offensive, like the stress on the syllables matter. I think it was a joke, and the industry took it.
Now that being said, the culture or idea that we're going to be offensive, we're going to be brash is 100% not NetSPI. I haven't seen it anywhere. That’s not in the culture.
I think that has a lot to do with the way NetSPI works, how we were building up talent through NetSPI University. We actually teach them ourselves. There's this culture of we bring people along here; there's not this culture of, ‘We go hire rock stars that are suddenly the best you can get, and your quality is different on your engagement, because you got the right rockstar.’
So, to level set, that's not here and you don't see that that mindset here. Secondly, in terms of proactive security, it's taking the same concepts of, ‘OK cool, you did an external pentest and that was a two-week engagement. What did you do the other 50 weeks of the year?’ How do you know that you've got somebody with expert level eyes?
If you've got an external pentester, one of the things that they're really good at is finding weird stuff. You might not know it, and there might be this moment in time that something popped up and it was there for a week and it went away. That's the opportunity. That's the thing that caused the breach.
If we can race it, like everything in cyber is all about finding the bad things faster than the bad guys can find it so that the good guys can get ahead of it and aligning with the defender’s mindset. If you work in a SOC, nobody understands this better than people that work in SOCs because it doesn't ever turn off. 24/7 and you've got something you could be looking at. Our goal is to align that mindset and bring the most important things to the top so you're not wasting time.
What is the biggest misconception with proactive security?
As somebody who wasn't familiar with how NetSPI did delivery, and when we first talked about it as pentesting, you look at this technical review, break it apart and then ship somebody a 100-page PDF. That is so old fashioned. Why is pentesting still doing that?
And then I got into NetSPI, and I saw we've already figured that out with our Resolve platform. We're doubling it down with our new platform that we'll talk about later this year. We are getting ahead of that. We're not just shipping you a PDF. It is now part of your workflow; we integrate with your JIRA for your developers, or whatever bugs ticketing and tracking system you've got. It becomes a piece and a part of the process where we can bring our expertise in. To me, that is already wildly different than a lot of consultants out there.
I've seen it on the other side, where that’s part of the benefit of being a practitioner on the enterprise side, you get to see pentesters who’ve found all this stuff. Now it's going to go get farmed out to four different dev teams, because there's different components — there's a complicated app, and different dev teams have different priorities. How do we get all of that friction and remove it? Make it where we understand how you work. To me, that's one of the ways we can be the most disruptive is to take all that friction away, and make it as easy as possible.
Shifting gears slightly, what are your least favorite cyber buzzwords?
I am fascinated by the fact that SIM, or SIEM as some people pronounce it, still persists, defiantly by the way, those who cling to the term SIEM. How that term even came to be is a weird story. Back in the early days of my career when I was naive and young, I thought, "Oh, security is just like following a recipe, right? I'm this expert chef, here's all the ingredients, I'm going to use this type of protein and this type of starch, and we're going to mix it all up, and we're going to have this perfect security model, right? And it's never going to break."
Eventually, I realized, well, that's stupid. It was a wake-up call for me that you have to monitor. And if you're going to monitor, you have to throw your stuff in some sort of place where you can find your logs.
And everybody said, "Okay, we're going to throw it in a SEM. We're going to call it a Security Event Management solution." Another company came along and said, "We're going to throw it in our SIM, as in Security Information Manager." And then somebody said, "Hold the phone. Our marketing is better than yours. We're going to be both. We're going to be a Security Event and Information Manager, or Security Information and Event Manager." Nobody knows!
I seriously think that if you go to a random SOC today, and you find somebody with less than, say, three years of cyber work in the frontlines defending some big enterprise today, and you ask them, "What does SIM stand for?" There's a coin toss chance that they don't even know. And if you ask the most seasoned person in there, "Where did the name come from?" I guarantee they don't know. They don't realize that it's like that.
What's your take on the GenAI boom? Any thoughts around its rapid adoption?
I will say that I was the first person up until about June-July timeframe to say stop talking about AI. I've even joked that one of the best things I've ever done in my career is to take certain cyber marketing people and tell them to stop saying AI and ML where it doesn’t make sense. You can do anomaly detection, you can do k-means clustering, things like that; that's a form of ML, but it doesn't mean we need to go slap it on there just to be buzzword-compliant. I still maintain that there's still a place for discrete algorithms and human intelligence that will absolutely trump, and you can't take that out. But at the same time, unless you're not paying attention, with what with the GPT-3, branch release and everything else, that changed a lot of things. But it didn't completely and now we've got all these organizations rushing to adopt it.
If you're an enterprise, almost in any space, if you're not rushing to adopt it, you're taking on too much risk by not adopting it. I like to go back to Dan Geer — I listen to his talks all the time — and he talks about two kinds of risk:
Not putting enough risk and play with the business, and
At the same time also having too much risk
You’ve got to find that sweet spot to really grow your business. You must have it in there. But the way I see it going, honestly I've bounced this off a bunch of different people inside and outside, and inside my network. This looks to me, like you're going to have people building models. And it's going to be deep understanding of the math behind the model. Understanding how the model works and how you can potentially do adversarial ML against the model, whether it's a large language model, or it's just a traditional ML like a classifier or something or unsupervised learning, like all of that stuff, very deep, very technical. There's going to be a subset of enterprises that absolutely have to have them, almost all of that will be tech companies, with some big enterprises kind of mixed in with little projects that they do.
As this becomes normalized and adopted, it's going to meld into what you do for AppSec. For example, I have this web application, and I need to do a penetration test. By the way, you're going to list out the components: I'm using this CDN in front of it, I'm using this WAF, I'm using this development stack, I'm integrating with these types of services. I've got a microservices architecture, and by the way, I'm integrating with this large language model. Then that's going to bring out a set of abuse cases that need to get tested with the app. It's going to merge, and the pentesters who don't know that are going to get left behind, because they're not going to get proper coverage for their customers.
At the same time, that's a good thing, because it means we can help the big enterprises that are adopting the frameworks. We test all the big tech companies’ LLMs in all their tech stacks to make sure that it’s all functional.
I joke and say it's somewhere between SQL injection and securing an s3 bucket. If you remember, when SQL injection came out, everyone was vulnerable, because everyone was doing string concatenation on their web apps. You could inject random SQL statements into your query, and then bad things would happen.
Then what happened? Every development framework came out with a mechanism to drop in parameterize queries. You had a framework that just took care of it for you — developers don't have to understand anymore, they just know to use this framework and be done. I think we'll see that happen with the injection side, and then on the like the equivalent of the s3 bucket, when Amazon s3 service and same thing with Azure and GCP storage came out, people would start putting things in there and not understand the permissions and then expose content to the world and not understand because it's complicated.
I think you'll have the same kind of problem with people over indexing and giving too much data into their LLM for building out the model for what it has access to the APIs and everything else, so we’ll see a governance aspect there.
Before we go, I have one last question for you. This one is for all the team leads listening in. What are some parallels between managing a household with six children and managing a 400+ person cybersecurity team?
What ends up happening is I use the same kind of conversations when drama does inevitably happen on either of those scenarios with my kids. I can say, "Does hitting your sister get you closer or further to your goal of getting ice cream?" And I can say, "Did talking to your coworker that way get you closer or further to getting your project approved?" It's the same thing. It's kind of funny how sometimes that works.
Catch the full conversation between Tim and Aaron below or continue your proactive security journey by reaching out to NetSPI for a consultation to guide your next steps toward proactive security.
You’re about to have your first Red Team experience, or maybe your first one in the CISO seat of your organization. Maybe it’s just been a little while since your last one and you are curious how this one will go, what the Red Team will find, how your Blue Team will handle it, and what the longer tail takeaways post-engagement will be like.
But before you begin, it’s important to consider: What am I not thinking about? Are we ready? How can I prepare for this?
What if I Have Specific Objectives for Red Teaming?
If you haven’t already, make sure you’ve discussed your objectives with your Red Team partners to ensure alignment with what you’re hoping to learn and focus on. This conversation will often center around matching Red Team objectives with the maturity of the security program and your Blue Team to get the most benefit from a Red Team exercise, because this definitely should not be a one-size-fits-all exercise. For example, at NetSPI, we tailor match the Tactics, Techniques, and Procedures (TTPs) we use to your currently known capabilities and gaps. Our goal is to help you grow your program in a meaningful and material way, even if resources are constrained and growth is gradual.
How Much Do I Tell My Team when Engaging Red Team Testing?
It’s most common for a Red Team exercise to be an extremely limited knowledge event. Who you provide advanced notice to is up to you. Our advice: less is more if you want to know how truly prepared your security program is.
If you do these all the time, you may want to tell your team that a Red Team exercise will happen in the future but remain vague—no specific dates. This has a “Secret Shopper” effect, just like a retail clerk who is unsure if their customer is an actual customer, or a plant sent from corporate headquarters to evaluate the store. The foreknowledge that a secret shopper may arrive at any time can have a positive psychological effect, bringing out the best performance of the team. Likewise, your Blue Team may become naturally more vigilant simply because they know a Red Team may come anytime.
What if I have an MSSP or MDR Provider?
Since most MSSP or MDR provider relationships are focused solely on the ability to detect and respond to credible threats, it is best to NOT advise them in advance that the Red Team exercise is happening. However, post-exercise, it is critical that you properly read-in your provider so that they can collaborate with you on a path to improve detection and response coverage. NetSPI, specifically, loves to partner with MSSPs and MDR Providers, because they are your Blue Team on the front lines. Our objective isn’t to make your provider look bad; our objective is to prepare your organization for the eventuality of a real incident.
Should I Have Expectations on How Successful the Red Team Exercise Will Be?
It’s probably best to set expectations that while your Blue Team will bring some friction to the Red Team, it will feel like the Red Team managed to get ahead and reach objectives too easily. This isn’t always the case, of course, and we love to have our best tradecraft get shut down by our customers!
But since our Red Team constantly focuses on what works, what doesn’t, what security controls provide friction against which TTPs, etc., we are constantly improving. If our Red Team is successful, it doesn’t mean that the threat actors most likely to land in your environment will automatically have equal success.
Threat groups tend to cluster around a smaller set of TTPs than our Red Team because they apply them at Internet scale across many organizations. If the techniques fail and a Blue Team contains them, they don’t care. There isn’t enough friction to change TTPs often if they still work on the next victim. Our goal is to be the best [simulated] threat actor we can be for you. This is a subtle, but important difference.
Now all of that isn’t to say this is easy for our Red Team. By far the hardest part of our job is getting the initial access foothold into your organization. We don’t have magic 0-day exploits to walk right in. We have drudgery ahead of us: scouring your entire perimeter, learning about your business using Open-Source Intelligence (OSINT), social engineering our way in (if that’s in scope for your engagement) … essentially leaving no stone unturned.
We prefer to do it this way, when possible, because once our Red Team lands inside your organization, it will “feel natural” to incident responders who eventually (hopefully) will see something unusual that they chase to its origin. But that said: do not over-index on this step. If your goal is to absolutely find a way from the outside into your organization, you probably should do an External Network Penetration Test instead.
What you’re ultimately buying in a Red Team exercise is the detection and response cat-and-mouse game that helps you evaluate your readiness for a breach. You don’t get that benefit from us until we land inside your organization. Because neither you nor we have unlimited surplus budget, we will want to time box our efforts looking for the “natural” ingress point, and when we hit that point, we will want to switch to an “assumed breach” scenario where you seed us access. We can even do it this way from the start to save time and money.
What Happens After a Red Team Exercise?
Besides the debrief meeting and handing you deliverables, what’s next for a CISO after a Red Team exercise? In most cases, there will be significant security engineering and process overhaul project work. Unlike a pentest, where a finding can be quite small and tactical, such as applying a patch, fixing permissions, changing a password, or updating a line of code, findings coming out of Red Team exercises are typically wide-reaching and systemic. Some may require projects that span more than a year to complete. It may be good for you to brief your CFO, CEO, and Board of Directors about the exercise in advance that you will likely come asking for a budget increase to cover control gaps. We can certainly help you with messaging there as well! Reach out anytime.
What about Follow-Up Testing?
While the Red Team may likely find and exploit vulnerabilities in your internal environment, they won’t exhaustively search for all related instances of that vulnerability. Red Teaming is a depth-first search: chaining vulnerabilities, detection gaps, process flaws, and misplaced human trust together to reach an objective.
Penetration Testing, on the other hand, is a breadth-first search: locating all instances and permutations of all possible vulnerabilities. For example, if the Red Team finds a single instance of SQL injection on an internal web application, exploiting that to gain additional objectives or access, the best next step is to perform a top-to-bottom penetration test on that web application, to ensure nothing else was missed that the Red Team didn’t have time to find, or was trying to be too quiet to test.
How Often Should I Plan for Red Team Testing?
This is entirely up to you, of course, but here are some things for you to consider:
How much has changed with your controls since you completed the first Red Team exercise? If not much, don’t expect a wildly different experience in the Red Team’s ability to reach objectives—but the exercise can still be meaningful to give your Blue Team another chance to train and become more prepared for an actual event. You can also ask us to avoid certain things or modify the path towards objectives to vary from your prior experience.
How large and segmented is your business? If you have a lot of M&A, subsidiaries, disparate geographic locations, etc., you may benefit from intentionally scoping another Red Team exercise to land in another part of your organization sooner than later. These “satellite” organizations often provide less detection and response friction to adversaries looking for a path to pivot into the corporate mothership.
What cadence are you trying to establish? It may be beneficial from a budgeting perspective to plan for a semi-annual or annual Red Team exercise to set a solid precedent with your CFO, CEO, and Board of Directors that this is a meaningful recurring part of your security program. When combined with the ideas above, the experiences each time will definitely vary.
How Can I Tell if a Red Team Exercise is Successful?
As the CISO, you will appreciate that a successful Red Team exercise has almost nothing to do with whether the Red Team reached an objective.
The Red Team could reach an objective but highlight serious gaps in the process that you can quickly fix with existing controls or help make the business case for a security budget extension. Or they could be contained by your Blue Team without any new technical learnings, yet the confidence the Blue Team gains from containing the Red Team might be precisely what is needed for your security program.
At the end of the day, “success” is largely a product of clearly defining the goals you have for the engagement and tying the results back to the identification and reduction of risk, improving your cybersecurity program, and protecting your organization. No two exercises are exactly alike!
Whether you’re starting your first Red Team exercise, or you’re looking for an outside perspective on your overall security, NetSPI is here to help. Access our Red Team data sheet below to get started.
[post_title] => What is the CISO Experience in a Red Team Exercise?
[post_excerpt] => What can you expect while going through a Red Team exercise? We answer the questions on every CISO’s mind when considering a Red Team engagement.
[post_status] => publish
[comment_status] => closed
[ping_status] => closed
[post_password] =>
[post_name] => ciso-experience-in-red-team-exercise
[to_ping] =>
[pinged] =>
[post_modified] => 2024-01-15 17:13:28
[post_modified_gmt] => 2024-01-15 23:13:28
[post_content_filtered] =>
[post_parent] => 0
[guid] => https://www.netspi.com/?p=31772
[menu_order] => 21
[post_type] => post
[post_mime_type] =>
[comment_count] => 0
[filter] => raw
)
)
[post_count] => 3
[current_post] => -1
[before_loop] => 1
[in_the_loop] =>
[post] => WP_Post Object
(
[ID] => 32190
[post_author] => 53
[post_date] => 2024-03-27 13:50:27
[post_date_gmt] => 2024-03-27 18:50:27
[post_content] =>
There are nearly countless tools in our industry right now that can give us an inventory of our external facing assets, laid out neatly for our teams to tackle.
But, how do you know which of those high-scoring vulnerabilities is actually going to be the most impactful on your particular environment? Does your team know how to interpret the assessments these tools provide while considering your company’s external attack surface? Has the assessment really given you what you need to validate and prioritize the identified risks?
We dove deep into these questions – and more – during this live event! As part of our “Let’s Talk Proactive Security” series, NetSPI CEO Aaron Shilts sat down with our EVP of Strategy Tim MalcomVetter to pick apart these questions and give guidance on how to approach external attack surface management in the right way for your company.
Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.
Name
Domain
Purpose
Expiry
Type
YSC
youtube.com
YouTube session cookie.
52 years
HTTP
Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.
Name
Domain
Purpose
Expiry
Type
VISITOR_INFO1_LIVE
youtube.com
YouTube cookie.
6 months
HTTP
Test
test.com
Testing
7 days
HTTP
Analytics cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.
We do not use cookies of this type.
Preference cookies enable a website to remember information that changes the way the website behaves or looks, like your preferred language or the region that you are in.
We do not use cookies of this type.
Unclassified cookies are cookies that we are in the process of classifying, together with the providers of individual cookies.
We do not use cookies of this type.
Cookies are small text files that can be used by websites to make a user's experience more efficient. The law states that we can store cookies on your device if they are strictly necessary for the operation of this site. For all other types of cookies we need your permission. This site uses different types of cookies. Some cookies are placed by third party services that appear on our pages.
Cookie Settings
Discover how the NetSPI BAS solution helps organizations validate the efficacy of existing security controls and understand their Security Posture and Readiness.
