Tag Archives: threat modeling

Basic is great

Encouraged by the response to my last post (https://www.iamit.org/blog/2018/06/the-ian-amit-spectrum-of-pentesting-efficacy/ for those who missed it), and following up on a couple of recent Twitter/LinkedIn/WhatsApp conversations, I’d like to emphasize the importance of doing basic and simple work (in security, but it probably also applies to everything else).

We are working in a weird industry. The industry encourages unique thinking, contrarian ones, and creativity. Guess what? The kinds of people who find themselves “fitting in” is more often than not your typical ‘hacker’ with the stereotypical social baggage that comes with it. It also means (and of course, I’m generalizing) a short fuse, lack of respect/patience to people who are not as immersed in the cybers as they are, and that often creates the scenarios that Phil describes in his post.

Moreover, those of us who have been around the block a couple of times, also know and realize that there is no silver bullet solution to security. We are in it because we realize it is a constantly moving and evolving practice. Because we love the challenge, the changing landscape, and the multitude of domains involved in practicing security properly.

Which gets me to the basics. 

This, and other conversations (the notorious “Cyberberet” WhatsApp channel for the Israeli guys), which revolve around the latest and greatest [insert cyber-marketing-buzz/fud] solution. So here is my old-man eye-roll for you…

I earned the right to roll my eyes. 20+ years and counting 😉

The reason being, I still see a lot of organizations trying to decipher how they are going to integrate said [insert cyber-marketing-buzz/fud] product, while failing to have a basic security program.

They often don’t have one, because they never bothered to perform a proper threat modeling exercise where they “dare” ask their executive leadership what do they care about (i.e. what are they afraid of). I’ve seen companies invest huge $ in fancy SIEM solutions while not having a basic authentication mechanism for their employees (dare I say MFA?). And even the inability to get a somewhat consistent asset inventory and tracking, which comes with the usual excuse – all this cloud stuff is very dynamic, we don’t have racked servers like in the olden days. To which my rebuttal – all this cloud stuff makes it easier to track your assets. You are just lazy and incompetent.

Compound that with an approach which I sadly see some of my colleagues take, which says – forget about all those products, you are going to get breached. You need to embrace the [other-fud-buzz-cyber] approach where attackers [pre-cog / deceived / lost / identified before they get to you / hacked_back / …]. Hmmmm, let me guess – you must have a company operating in that space, right? 

So no. Neither precog, nor deception or hacking back will save you either. And I’ve played attacker against these things in the past, and (shocked face) always won against them. What you should be doing in getting back to basics.

You know – the stuff they teach at intro to infosec 101. Layered security. Logging, monitoring and anomaly detection (behavioral – after baselining and such). Getting the basics of authentication and authorization done properly. Having a patch management practice coupled with a vulnerability scanning one. Knowing what is your threat model. What assets are you protecting. Which do you need to prioritize over others. What is your threat landscape (and no – no matter how fancy or ninja/8200/NSA the threat feed is, it most likely has zero applicability to your threat landscape). What controls do you have in place (technological, and others) and how effective are they.

Image result for polishing turd

“Playing” with these basic elements can, and will have a huge impact over your security posture. Much more than trying to fit a fancy “cyber” solution without any context over what you are getting done (see equivalent image to the left…). But you know what – don’t take my word for it, ask any competent pentester who’s faced both – a properly executed security program, and for comparison one of the latest buzz-worthy products. You’ll get the same response: it’s harder to overcome the security program, while dealing with a magic product requires a one-time effort to render it moot.

Now go back to the basics. There’s no shame in it, you’ll get to play with the fancy stuff a bit later, and when you do, make sure to come up with what YOU need from it rather than get starry-eyed while listening to the sales folk try to wow you 😉

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!

An obituary to pentesting?

I just saw a blog post in which Mike Kemp discovers the realities of 2010 (linkedin). (disclaimer – I know Mike and love him as a person, and this is my way of poking at him a bit – no disrespect here, but pretty much the opposite)

Now, go read that post (yes, I know, it’s long, but trust me).
This isn’t new (albeit very honest, direct and true),but here are a couple of comments I have:

  1. Penetration Testing is dead. Overrated, and abused by fancy vulnerability scanning, it died a few years ago. If you are still paying for one – check carefully what you are actually getting…
  2. Automation is king. I actually argue that 80% of what’s sold as a pentest by the major providers can/should be automated. All those scanner monkeys should be fired or forced to step up their game and actually do some work.
  3. Compliance? Really? Do you really want to go there? It’s got nothing to do with security, and if you thought so for a second I want to have what you were on when you did.
  4. Standards. This is where Mike touches on a sensitive topic for me (yes, PTES…). I’d actually challenge Mike to show me how PTES (which he mentions in the post – but you already know that because you read it, right?!) restricts providers by providing the engagement steps – which they should follow. There’s no restriction to scope, and I have personally used PTES in red team engagements. Full scope, no bars held. But still with a standard to follow, and something the client can also keep track of and know what to expect (and demand).
  5. I fully agree on the “pass the wealth” point where you should call in someone else who’s an expert to deal with a specific client request. Done that many times, and have never lost a customer that way.

Last but not least – yes, I do think that most pentesters can be replaced with a script. As they should. I do however have a solid advice to Mike and others who are still valuable professionals that have skills which are not replaceable by automation: demand a proper engagement model. And yes – I’m referring to the PTES again. You’d notice that threat modeling is part of it. Done properly threat modeling achieves multiple goals:

  • Forces the discussion to be around security rather than compliance, price or other factors that have nothing to do with security.
  • Scope goes out the window as threat models focus on the BUSINESS and not the TECHNOLOGY.
  • Enables the organization to test itself against its adversaries (threat actors/communities) rather than against pentesters. Much more rewarding, and correct.
  • Enables the provider (if it can muster to perform a decent threat model with the client) to charge decent rates for its services. You can clearly show how this isn’t some automated software running and spitting out reports, but skills and experience playing. It’s then your responsibility to follow through on it and make sure the final deliverable also looks like that (otherwise you are looking at a very short success rate for trying to adopt only part of this approach).

I actually welcome the hordes of scanner monkeys and tool-jockeys. They make the real professionals look even better. And although professionals don’t often have the marketing/sales power of the big-[number], trust me – they are busy, and doing work that the “big” and “trusted” suppliers can’t even start to put on their canned proposal templates.