Tag Archives: startups

Elastic Permissions

Over the past two years my colleagues and friends have heard me talk about Elastic Permissions, and at some point I started hearing other people mention the term (yay for planting the seeds through consistently using a new term…). So I figured – for the sake of clarity, let’s put this out there for posterity.

The goal of applying the Elastic Permission model is to reduce the effective attack surface for an organization.

Elastic Permissions (can you tell I am an Amazon AWS veteran? 😉 ) is a concept where permissions are being constantly and dynamically evaluated against the actual use of the granted permissions, and reduced to where they match said usage. This requires a few phases: mapping, measuring, and elasticity.

Mapping – in order to apply Elastic Permissions effectively, we first need a system to identify all the users, accounts, roles, assets, as well as all the relations between them. Think about a sort of a graph map where you can traverse between users, their accounts, the assets (whether data or functional/compute) using the effective set of permissions that tie them together. Now apply that to your organization, across all systems and platforms (including across platforms – for example IaaS, Saas, etc…).

Measuring – once you have a map graph, the actual use of every permission should be measured. This needs to be recorded in a way that reflects usage over time, in order to identify patterns of seasonality, volume, and misuse/under-use. In an essence, this phase applies weights to the graph map – where the higher the weight, the more use that set of permission gets.

Elasticity – based on the mapping and the difference between granted and used permissions, the system should revoke access dynamically. This means that unused (or even less used) permissions are being revoked. Additionally, permissions that have been identified as being used seasonally, should be revoked while unused, and re-granted in preparation for the usage period (then to be revoked again). Lastly – since there is an expected potential friction where permissions are incorrectly revoked, the system should offer a way to natively escalate and regain privileges (for example – through an MFA challenge) and apply learning to the decision to revoke the permission set in the future. Systems should also consider several grades of escalation based on the confidence level of the revocation (from granting access immediately, through challenge-response to verify with the user their intent, to an out-of-band escalation to a manager/SOC).

The end result as stated in the Elastic Permission goal is to accomplish a reduction in the effective attack surface. In my personal experience working with several systems like this, organizations should expect somewhere around 70-80% reduction, but these numbers will depend on the level of complexity of the organization (how many platforms are used, and the relationships between platforms), and allow the security organization to focus on real incidents since the elasticity acts as sort of a canary/honeypot.

The Product Versus Skill Pendulum In Security And The Need For Better Solutions

This post was originally published on Forbes

Security used to be easy–a fairly binary condition over whether you are protected or not, whether you are patched or not, or whether the port is accessible to outside IP addresses or not.

And then came complexity: Overlaying different aspects of vulnerabilities. Factoring in application issues, platform bugs, OS patches, network configurations and user access controls has shifted the rather binary situation to an exponential one. As such, we, as security practitioners, learned to use more skills in terms of threat modeling, secure development, honeypots and honeytokens for earlier detections, data-centric decision-making and increased focus on education and training.

We’ve reached a point where products matter less and less. Remember when the first action when getting a new PC was to install an AV on it and try to beat the clock before it got exploited? Now, PCs are pretty much secure out of the box thanks to the native malware detection and mitigation tools that are part of the operating system.

However, when looking at the security industry, we still see a lot of relics of the old-school way of operating. I’m not looking to explore who’s to blame (VCs? Startups? Consumers? Analysts? Your bet is as good as mine), but a lot of security vendors still treat the world in a binary fashion. If you look at marketing claims, for instance, it’s either you have their product, or you are not secure.

This brings me to my main point: A lot of security organizations are already through the pendulum shift. They are much more data- and customer-focused and are prioritizing their risk decisions around this rather than around the binary checklist of products. If that’s the case, where does that leave most industry vendors, especially with products that are not designed around the customer’s actual needs?

As an example, our security organization at Cimpress has been pretty adamant about practicing this customer-focused approach. We make it clear what our needs are and the features/capabilities we’d like to have based on our threat models and current capabilities. However, this leads to several problems.

First, a lot of vendors don’t know how to address that. They have a list of features and their marketing pitch, and that’s it. We’re looking for specific answers–possibly answers that include road map milestones–and are not expecting a single product to address all of our needs. Vendors, on the other hand, find it difficult to adjust their sales process (and pricing) to address customers’ specific needs, leaving frustrated after being told that we’re not using 80% of the product capabilities but would love to pay for the 20% we actually need.

Second, there seems to be a lack of vendors who truly adopt the approach of identifying needs on the customer side and are still adopting the approach of finding novel technical problems and solutions to address them. So, we’re left with niche products that don’t address actual needs but get snazzy marketing backing. We end up pushing the pendulum further into the skills territory, forcing security teams to rely on their own skills and in-house tooling.

To top it off, this increased reliance on skill is deepening the skills gap we already have in the industry. We have an education process that focuses on specific areas of the security field and training and education programs that are often product-focused. Meanwhile, generalists are becoming more rare and expensive as demand for less product-centric and more data/process-centric expertise increases.

What to do? Simple: Enjoy the sound of silence for a moment, especially as a vendor. Don’t incessantly ask what a potential customer’s current challenges are while trying to calculate what part of the answer you can anchor on to and sell your product through. We need to “shift left” that question from sales back to product design and even company inception. We need more smart people listening to what customers say about their needs and, rather than identifying where existing solutions can address them, trying to identify where there are partial or no solutions.

I’ve been fortunate to work with a few VCs and startups that do just that and have the foresight to validate these needs and keep driving their solution to address them or pivot their product so that it truly addresses the core issues.

On the other hand, I get frustrated with vendors who succumb to trying to latch on to a minor detail and blow it out of proportion or, worse, resort to speaking ill of their competition. Statements like, “We see a lot of customers of vendor X come to us after two years, and now, with our product, they are happy,” should be banned from sales discussions and replaced with, “Vendor X? Yes! I hear that their product is really good and addresses a certain set of problems really well. I’d love to know what your threat model and priorities are to better understand whether it is X you should go with or maybe find a different set of solutions.”

And as much as innovative products sometimes need to educate the market (I’ve been there and am actively working with companies like that as well), most times, the reverse is what’s needed: truly understanding what the industry needs right now and providing true minimal viable products (MVPs) that solve these often basic problems. There’s money in solving seemingly simple issues, especially if they have been around for a long time and are considered “the norm” or something that people need to just accept as suboptimal.