Why You Should Go Beyond The Typical Penetration Test

This post was originally published on Forbes

If you’ve ever run across a penetration test report, they usually look bleak. I should know; I’ve authored hundreds of them. By their very nature, they try to focus on the most egregious security issues within a system or network. Having an understanding of how an actual adversary would perceive the organization (which is a lot different than how a hired penetration tester does) and a grasp of the business and operational relevance of the tested environment are crucial to driving an effective result.

In combination with a good understanding of the business risks and how they relate to cybersecurity (see my previous article on utilizing two frameworks for securing a decentralized organization), a company’s security organization can provide context for such technical and scope-focused penetration tests. As we go through a report and align it with business risks, we should keep asking “why/what.” Why is this finding relevant? Why is this issue so critical? What is the root cause that allowed an asset to be exploited? What are the environmental factors that are part of this scenario?

Through connecting the technical report to the specific business environment and contextualizing it with the actual valuation of assets/risks, we end up with a highly enriched map. This map contains the original report findings along with additional elements that the penetration test did not address, such as processes, out-of-scope-systems, environmental elements, compensating controls and awareness/practices.

How does this play out? Consider a report finding related to the ability to steal credentials, escalate them to a higher privilege and gain access to a sensitive server. A penetration tester may suggest addressing this through technical means (hardening the server to allow access from predetermined hosts, locking down workstations to reduce privilege escalation effectiveness and adding MFA). However, this could also be amended by enforcing two-person authorization for critical actions (breaking the ability to abuse a compromised account), using password managers (reducing the chances of reused or guessable passwords) or even increasing logging visibility (to provide the SOC with insights on privileged activities through the systems). These remediations are less likely to turn up on a penetration test report, however, they are just as effective — if not more so — than the classic ones that only address the common technical aspects of the issue.

By no means should this be read as an encouragement to ignore the report findings from a penetration test, but rather, it should compel you to enhance them within the business context and make them more applicable for your organization. Many of these tests are done through narrow scoping, so as you get more proficient in contextualizing the results, you’ll be able to work more closely with your penetration testers and guide them to provide tests and results that are attuned to your business’ needs.

Rather than taking these penetration test results as gospel, and instead of accounting for the specific business environment and risks (and, yes, the culture, practices and tolerance), security organizations can provide more effective and longer-lasting mitigations to security gaps, perhaps even lowering the severity of seemingly critical issues to negligible ones. By being a true partner in the organization, instead of limiting ourselves to a technical watch-guard, we can more easily come to acceptance and cooperation — not only from the technical teams we work with, but also from business leadership.

Two Frameworks For Securing A Decentralized Enterprise

This post was originally published on Forbes

Many modern enterprises no longer operate in a highly centralized manner. Traditionally, cybersecurity in enterprise environments consisted of defining trust boundaries, placing controls over these boundaries, setting standards and policies for the safe and secure handling of data, enforcing said policies and scrutinizing any code/applications that were developed for flaws that may be exploited by adversaries — inside or out.

But now, as part of a decentralized model, optimizing for performance and independence, the kind of control and scrutiny that security organizations once had in the past is becoming irrelevant. This leaves the separate business operations within an enterprise free to choose their own implementation (and sometimes prioritization) of how they run their security.

If the CSO/CISO role was challenging before, now it is even more complex. We need to hold a delicate balance between enforcing some elements and providing guidance or general directions for most others.

As the parent company of multiple independently operated businesses, our approach at Cimpress is to emphasize a shared-security-responsibility model, where each business unit is not only responsible for choosing and operating its technical stack but also its security and risk management. As such, our security organization has two main tasks: providing clear and transparent metrics for security maturity and providing a means for measuring (really, this means quantifying) risk in a way that supports decision making around changing controls. We have chosen to utilize two well-known frameworks to achieve this.

For security maturity metrics, we chose NIST-CSF: the NIST Cybersecurity Framework. This framework provides a consistent and clear indication of security maturity across over 100 categories and subcategories of an organization’s defense capabilities. There are many approaches to using this framework, ranging from self-attested surveys to fully automated and continuously updating platforms. The technique is less of an issue than the ability to create a clear reflection of each business’ maturity levels and, of course, set a minimal or sought-after maturity level (again, this doesn’t have to exist across all the subcategories). This baselining allows businesses to better align themselves with existing policies (which are translated to the minimal required maturity levels) and map out their tactical security gaps.

For our risk measurements, we picked FAIR: Factor Analysis of Information Risk. FAIR is being used at the enterprise risk management (ERM) level and is combined with the rest of the ERM functions to assure relevancy and context for our business leaders. We do not deploy FAIR analysis across a broad range of scenarios; rather, we focus on the top three to five that each business identifies as the most relevant ones for themselves.

The goal of using the framework this way is to get immediate buy-in from business leaders while providing them with means of making informed decisions about their risks. After identifying the scenarios, we perform a FAIR-based analysis of the risk and come up with the results of the expected loss. Behind the scenes, we map the relevant controls to the already-identified security maturity measure.

Beyond providing a more realistic reflection of risk (while shying away from high/medium, red/green, etc. qualitative measures), we also create an immediate feedback loop. At this point, we’ve turned security and risk management into a business problem that’s more “easily” solved through financial measurements of recommended changes and their impact to previously expected losses.

If you are asking yourself, “Great, but where do I get started with this?” I would suggest to first define how a shared security responsibility model would look like in your organization. Where do you draw the line between the core responsibilities of the security organization, and where do you expect other parts of the business to own their share of security?

Once that’s defined, utilizing the different frameworks to facilitate this becomes more natural. We’ve used the NIST-CSF to provide metrics for everyone to gauge their maturity level and, based on the shared responsibility model, understand what areas need to improve. I’d suggest tailoring the use of the framework to your needs. In our specific implementation, we simplified the framework in terms of the number of maturity levels and provided focus on several specific subcategories that we defined as “basic security hygiene.”

Lastly, in order to prioritize these tasks of closing maturity level gaps, choose a risk model that works for you. In our case, it was FAIR, and even then we allowed ourselves to use it in a way that works for us rather than cover all our use cases and scenarios. This allowed us to stay more agile and have an easier adoption period where our businesses were getting used to the methodology and the framework.

At the end of the day, it’s about what works for your organization rather than about sticking to the letter of how a specific framework is structured. And of course, always make sure to build closed-loop feedback cycles in order to facilitate continuous improvement for how your security program works.

One of the biggest challenges of running a security organization is balancing the ongoing efforts, with strategic directions, all while keeping the “pressure” on to increase the maturity across the prioritized elements that give you the most risk reduction over time.

Seems like a bunch of management words, I admit, but it’s truly one of the more exciting areas to run. Combines technical depth, with business understanding of not only what matters now, but also how to “open” up business opportunities by enabling it to take risks.

How to Vendor/Sales in the Security Industry

I’ve been on the receiving end of sales pitches for years now. Ever since I took on senior leadership roles the constant trickle of various sales pitches just kept increasing.

These vary from completely out of the blue “cold calls” that attempt to push some solution, through the slightly better informed ones that take into account some of the business context, to highly relevant and targeted ones (not too many of those unfortunately).

This discussion recently came up during a conversation with one of my friends (who happens to be in sales), and we were comparing notes on the atrocities that we’ve seen as far as those pitches go. So I brushed up on one of my favorite Vendor Rebuffs courtesy of Andy Ellis, and was pointed to an interesting post by Mike Johnson from Lyft.

Both provide a good approach to dealing with vendors, but I found that there’s something missing, so here’s my additional take on it:

  1. Don’t pitch me. I’m probably not the right first contact for you. In every organization I’ve managed or built, I had subject matter experts (security architect, managers, etc) who were provided with the responsibility, autonomy and budget for their domains. You are looking for them.
  2. Don’t try to skip over. Skipping over my SMEs and going directly to me will result in the best case you being re-routed to them. Skipping me and trying to go to my CEO/CFO/etc will result in your company being blacklisted.
  3. Context is king. Trust me to do the minimal amount of work required to get my job done – which means I’m well aware of areas where we need products/services. There’s zero chance of you educating me of a completely new domain where I need help with (if there was, I’d be fired, or quit before that). Then you’d need to trust me to know the market enough to have conducted due-diligence and find the relevant providers in that domain. From the well-known names, to 5 people startups. We do not discriminate, and I always make sure to cover the market properly (I personally prefer to work with startups where we can have better control over the product features and roadmap actually…).
    If you aren’t in the running, then it’s one of two options:

    1. Your solution is known, but isn’t good enough for us or doesn’t fit our requirements (we work based on our requirements, rather than on what the vendors have to offer).
    2. You have an opportunity to educate us on your solution and we’d love to hear about it and see whether it fits our needs or not.
  4. As per the vendor rebuff from Andy – you don’t need to follow up again on your email. Not even once (definitely not 3 times). I do read all my email, and yes – I’ve been ignoring yours because I reached the conclusion that this is the best way to get rid of you. Past experience have shown that “unsubscribe”, “don’t contact me again”, and “this isn’t relevant” responses end up being perceived as “sure – reach out again in 6/12 months to see if my memory is shoddy”).
    Absolutely do not try to actually call me on my phone. You are wasting my time (and compoundly so, since it requires me to shift my multitasking and deal with your analogue call continuously).
  5. I maintain a black-list of vendors. It’s not easy to get into it (I do provide the benefit of the doubt and best intentions to everyone), but it’s impossible to get out of. You can ask vendors who have suddenly saw an immediate halt on all orders from my organization once I started working there.

So here you have it – a roadmap on how to get the 15 minutes of attention. Yes – it means you need to do your homework first. No – “clever” pitches to grab attention will not result in getting it (unless you were fortunate enough to be the one who caught me on a bad day, in which case I’ll probably post your egregious sleazy pushy email anonymously somewhere).

And even when you do your homework, you need to remember that you are dealing with a market that’s pretty mature and educated (or at least, my organization is such). Your attempt to “educate” us on a need is likely to be ineffective. Keep to the above and you might have a chance to get thrown into our POCs where we evaluate solutions for our needs.

Update: found this gem of a post – sadly I’ve ran across each and every item listed there. Go study it and figure out how to avoid getting into the blacklist 😉

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 😉