Tag Archives: red team

The Ian Amit Spectrum of Pentesting Efficacy

It’s been a while since I posted (duh), but recently I’ve had something brewing in my mind that appeared to not have been clearly discussed before, so here goes.

I’ve been seeing some discussions and ambiguity around pentesting, vulnerability assessment, and red teaming (again – no huge shocker for those of us in the industry). However, as much as the “look at our shiny new red team” marketing BS coming from big companies (read as “we do pentesting, we have a new name for it so you can pay more”), pisses me off, what bugged me even more is the lack of clarity as to where and when pentesting can/should be used, and through which means.

I offer you this – my simplified spectrum of pentesting efficacy.

In short, here’s how this works: first identify the actual need for the test. There should be three categories as follows:

  1. Testing because you have to (i.e. compliance). PCI is a good example here. It’s something you can’t avoid, and doesn’t really provide any real value to you (because of the way it is structured, and as we all know, compliance/regulation has nothing to do with security so you might as well ignore it.
  2. Testing because you want to make sure that your controls are effective, and that your applications are built properly. This is where the “meat” of your pentesting should come into play. This is where you see direct value in identifying gaps and fixing them to adjust your risk exposure and tolerance (based on your threat model and risk management, which you should have, or if you don’t, just go ahead and quit your job).
  3. Testing to see how you fare up against an actual adversary. Bucket 2 above was fairly technical in its scope and nature. This bucket is threat focused. More specifically – threat actor focused. Your risk management strategy should identify the adversaries you are concerned about, and here you want to see how you fare up against them in a “live fire” scenario.

Once you have these, you are almost done. Here’s how you approach “solving” for each category:

  1. Compliance: find the cheapest vendor that’ll check off the box for you. Don’t be tempted for cheap marketing tricks (we red team, we thoroughly test your controls, we bring in the heavy hitters who have spoken at BlackHat and DEFCON and the super-underground conferences). Remember – you are getting no security value from here, so shop around and see who will tick the box for you. Remember to be heavy handed on the reporting and remediation, as if you are doing things correctly, the scope should be very minimal (remember – just enough to cover compliance requirements) and you should easily have these covered as part of your standard security practice.
    Also – no point of putting any internal resources into here since it won’t challenge them and is menial work that should be outsourced.
  2. Controls and Applications: this is where you should invest in your own resources. Send your security engineers to training. Build up an SDLC that includes security champions and involves the dev teams (DevSecOps anyone?). This is where you should see the most value out of your investment and where your own resources are better equipped to operate as they are more familiar with your operating environment, threats, and overall risk prioritization. In this category you’ll also sometimes include testing of 3rd parties – from supply chain to potential M&As. Use your discretion in choosing whether to execute internally or engage with a trusted pentest company (make sure you utilize the Penetration Testing Execution Standard when you do).
  3. Adversarial Simulation: This is where you shift from pentesting to red teaming. The distinction is clear: pentesting focuses on one domain (technical), and sometimes claims to be a red team when phishing is involved (social). A red team engagement covers three (technical, social, physical), and more importantly, the convergence of two or three domains (social/physical, technical/social, technical/physical, or all three). This is where you should engage with a company that can actually deliver on a red team (again – use the PTES sparingly in helping you scope and set expectations for the engagement), and can work with you to identify what kind of adversary they should be simulating, how open or closed does the intelligence gathering works, how engaged will they get with targets, and to which degree are you ok with potential disruptions. This is where you’ll see value in affirming your security maturity across several domains, and how these fare up against your threat communities. This will also enable you to more clearly align your investments in reducing exposure and increasing your controls, monitoring, and mitigations for actual loss scenarios.

I did mention vulnerability assessments initially, and if you made it through here you noticed it’s not on the spectrum. Well, it kind of is – it should be part of all of the engagement types, and is not considered an independent member of an engagement. Hint – never outsource this. It’s extremely cheap to engage in VA by yourself, and there are plenty of tools/programs/services that are highly effective in continuously performing VA for you that range from free to very cheap. Don’t be tempted to pay any premium for it.

That’s all for now – hope this made some sense, and helped you in prioritizing and understanding how pentesting (and red teaming) are best applied through your security program!

ISTS12 Keynote and Red Team

I’ve had the pleasure and the honor to keynote this year’s ISTS (Information Security Talent Search) that ran at the Rochester Institute of Technology (RIT). Additionally I was also fortunate to get a seat with the Red Team during the event itself and work closely with some of my friends and colleagues.

It has been a while since I had the chance to work with students (mostly with my Alma Mater from the IDC during freshmen orientation, and the “CS for Real” series for CS students). And I honestly didn’t know how to address this initially. Thankfully, Jared and the ISTS team were pretty open to my suggestion of combining a “here’s how I got here” rant with some technical examples of challenges and engagements.

The keynote wasn’t recorded (thankfully?) but here are the slides that were used as the backdrop for it. I ended up coming back with some insights from the keynote (as I usually try not just to provide information, but also learn new things), and thanks to some awesome questions from the audience (students, red teamers, and apparently faculty which I haven’t realized were also there…) it ended up a really great session for me!

The next day was spent with the red team, which was a great opportunity to catch up on some skills that I left behind (always pick the task that you are less familiar with!), and really kick some ass with the team. Chris Gates has written a great wrap-up blog on it here: http://carnal0wnage.attackresearch.com/2015/03/ists12-thoughts-notes-feedback.html

Really looking forward to working more closely with people who are just starting their way in the industry – if the feedback doesn’t lie, it seemed to be somewhat beneficial to them, and from a completely selfish perspective, I had a chance to learn a few things myself too!

Sensationalism – doing more damage than good

It took me a while to really decide to pull the trigger on this post. For several reasons:

1. I think the way that @ZeroFOX handled this was impeccable. As far as “we” are concerned this issue was to bed once the instigator (@avriette) balked out on actually having a constructive discussion when invited to.

2. Deciding to pick this up the next day showed me that @avriette blocked me on twitter. That kind’a shows the level of maturity we are dealing with here. Burying your head in the sand and refusing to deal with your provocation is not something that I can respect.

Nevertheless, I did want to put my personal thoughts on this out there (specifically since I don’t think that ZeroFOX needs to handle this anymore, and since I have already voiced my thoughts about this before: http://www.iamit.org/blog/2014/02/women-in-infosec-that-thing-again/).

So here goes: During a presentation at Shmoocon, that discussed research conducted with John’s Hopkins University about a red team / blue team exercise over social media. As such, the students have learned about attack vectors that were effective, and have engaged in launching those against their fellow students in other universities. As the talk title implied, the obvious attack methods online were ones that appealed to the target demography: “Mascots, March Madness & #yogapants”. It should have been pretty obvious, that when discussing any attack vectors on social media (and social engineering), anything related to sex, sports, food, free/discounted stuff, will all show up with varying degrees of effectiveness.

powersAnd yes – Tinder showed up there as an effective method (yes, it’s a sex-as-a-service app) to target people. I can admit to using Tinder (and Grindr, and happn, and okcupid, and others) as highly effective means of social engineering my targets on red team engagements. I also admit that I have totally stereotyped my female targets and used discounts on Manolo Blahnik shoes, LV bags, and high-end wine. And it was very effective. I’ve used free hot cocoa offers in the winter, and beach getaways in the summer, and iTunes cards, and free food samples, and court side tickets for Knicks games (yes, people actually still go there), and a gazillion other “objectifying” methods of appealing to my targets. Because these things work. And as such, I have presented my experience and research about it, just like this one (and I have been passing along that knowledge very successfully on our Red Team Trainings in the past as well).

During the presentation, it was brought to my attention that someone is tweeting about how the talk is objectifying women and making women in the audience feel uncomfortable. Mike (@theprez98) posted a short blog about this here: http://theprez98.blogspot.com/2015/01/hacker-cons-and-speech-codes.html.

The funny thing is that while I was sitting at the talk, I had two women who I highly respect, tell me how they fail to see whether the content or presentation would make them feel uncomfortable, nor that it was objectifying women in any way. Anecdotally, one of these women also runs the @ZeroFOX account, which “Jane the destroyer” was tweeting to, probably thinking that a man was running it (can you say stereotyping?).

I can’t put myself in anyone else’ shoes, so there is no way for me to debate the “making me feel uncomfortable” claim. Should have been a trigger warning at the beginning of the talk? Probably not. Especially if you bothered to read the talk title, or the short abstract. But going out, and just for the sake of making a potential scene, and then to bail out when offered to discuss things in more details shows me the true nature of the instigation.

And that’s where it gets me – it’s doing more damage than good. Like I have said before – my personal experience in the industry is not of “holding back women”. It’s of a very equal approach that puts women and men in the same position: professional. Just like another person that I highly respect in the industry put it in the past: “Calling bullshit on women in infosec” (thanks again Jennifer), and then Amanda’s post about the BSidesLV “incident” – these instigators are just doing more damage.

Yes, just like in any large enough group of people, you’ll find the assholes who are sexist. You’ll also find bigots, racists, trolls, anti-social people, douchebags (bro’s), etc… You cannot expect that since this environment is “yours” (i.e. infosec), it would be devoid of your run-of-the-mill social miscreants. Just like you deal with it on your non-infosec life, deal with it here. I’m dealing with it because I’m bald, and Israeli, and am often associated with Jews (no – I don’t care for kosher food. I like GOOD food, which usually excludes kosher. Stop stereotyping!). And I’ve dealt with it when I saw other people out of line when it comes to my friends or the hacker family. Whether it was a cop picking on a black person, or a women being harassed at a bar or a conference (not that they need it – they stood up for themselves just fine…).

So here goes. You got your 15 minutes of fame, I hope you enjoy them. I wouldn’t want mine to be about stuff like this. I’d like it to be about things that I’m passionate about, and that can actually make a difference.

Like hacking.

Think about it.

 

Update: This pretty much puts it to bed.

Screen Shot 2015-01-23 at 11.08.21 AM

Seeing RED in your future? – Recap from DerbyCon 3.0

Yes, I know, It’s been a while since I updated anything here. Work, life, etc…

yin and yang

So here’s a quick update/recap on some of the latest: SecurityZone 2013 was an excellent experience. Always great to get back to Cali to meet who are now friends rather than just colleagues and conference organizers. I delivered the keynote there, where it was fun getting feedback for stating out-loud some of the things that we all (should) realize, which is our reliance on products is hurting us.

And this week was DerbyCon. Can’t stress enough how much fun it is to run the Red Team Training class with my best friend Chris, and the kind of feedback (and learning) we have a chance to get.

Speaking of DerbyCon – OMG what a conference! It’s just amazing what a small crew of dedicated individuals can come up with in such a short period of time. If you’d ask me for how long this con has been running I’d say at least 8-9 years. And this one was just the third iteration. Everything from the volunteer crew, through the hotel staff (major kudos to the Hyatt for taking DerbyCon on, and “working” with us – going well above just accommodating a conference venue).

My talk at DerbyCon focused on the “receiving end” of a red-team, which articulates what an organization should do in order to thoroughly prepare for such an engagement, and maximize the impact from it and the returns in the form of improving the organizational efficiency and security posture. Had a lot of great feedback on it, and some excellent conversations with people who have been struggling to get to that “buy-in” point in their organizations. Really hoped that I managed to help a bit in figuring out how to more accurately convey the advantages and ROI of such an engagement to the different internal groups.

Following are the video and slides. Have fun!

Do as I say, not as I do. RSA, Bit9, Adobe, and others…

So you thought you had everything nailed down. You might have even gone past the “best practice” (which would have driven you to compliance, and your security to the gutter), and focused on protecting your assets by applying the right controls in a risk-focused way.

You had your processes, technologies, and logs all figured out.

But you still got owned. Want to know why? Because you are still a little naïve.

You put your trust in big name vendors that preached for you to get your stuff together. You listened to them, were convinced by their pitch, and you might have even put their products through rigorous testing to make sure they deliver. But you forgot one thing. Big ticket vendors are no much different from a zealot church.

They will preach, and guide you through to the righteous passage. But when you look behind the curtain, well, you know what I mean…

The latest Bit9 compromise isn’t that surprising. Bit9’s customers are obviously very security aware as they opted to use a whitelisting product to protect their computing assets. As such, these customers are most probably high value targets to adversaries. It also means that with such an awareness to security, these customers probably have more measures and practices to mitigate and protect themselves from attackers. That means, that if I were to scope such a target for an attack, I would have focused on supply chain elements that were weaker than the target itself (much like the way we teach at out Red-Team Testing classes…).

RSA was such a target. Adobe is a similar one. Bit9 just was for some of its customers.

Color me surprised.

And yes – if you are a vendor that gloats over the latest compromise – please don’t. If you haven’t gone through a similar threat model your products are either not good enough (hence your customers aren’t high value targets. How does that make you feel now?), or your own security isn’t up to speed and you haven’t realized you have been breached yet. Now go clean your own mess.

If you are a security consumer (hence – care a bit more for your information than just getting compliant and tabling it), make sure not to make any assumptions about your providers. Especially about your providers. They aren’t the target. You are. As such, they are the vehicle, and they have a more generalized security practice than yours. Account for it in your security strategy, and never fully trust anything outside of your control span. It is your responsibility to hold them to at least their own standard, and demand oversight and proof that they do so.