3 types of application security

I’m indebted to my friend and colleague, Matt Smith, for putting me on the road to this article: he came up with a couple of the underlying principles that led me to what you see below. Thanks, Matt: we’ll have a beer (and maybe some very expensive wine) – one day.

There are security applications and there are applications which have security: specifically, security features or functionality. I’m not saying that there’s not a cross-over, and you’d hope that security applications have security features, but they’re used for different things. I’m going to use open source examples here (though many of them may have commercial implementations), so let’s say: OpenVPN is a security product, whose reason for existence is to provide a security solution, where as Kubernetes is not a security application, though it does include security features. That gives us two types of application security, but I want to add another distinction. It may sound a little arbitrary, at least from the point of the person designing or implementing the application, but I think it’s really important for those who are consuming – that is, buying, deploying or otherwise using an application. Here are the three:

1. security application – an application whose main purpose is to solve a security-related problem;
2. compliance-centric security – security within an application which aims to meet certain defined security requirements;
3. risk-centric security – security within an application which aims to allow management or mitigation of particular risk.

Types 2 and 3 are subsets of the non-security application (though security applications may well include them!), and may not seem that different, until you look at them from an application user’s point of view. Those differences are what I want to concentrate on in this article.

Compliance-centric

You need a webserver – what do you buy (or deploy)? Well, let’s assume that you work in a regulated industry, or even just that you’ve spent a decent amount of time working on your risk profile, and you decide that you need a webserver which supports TLS 1.3 encryption. This is basically a “tick box” (or “check box” for North American readers): when you consider different products, any which do not meet this requirement are not acceptable options for your needs. They must be compliant – not necessarily to a regulatory regime, but to your specific requirements. There may also be more complex requirements such as FIPS compliance, which can be tested and certified by a third party – this is a good example of a compliance feature which has moved from a regulatory requirement in certain industries and sectors to a well-regarded standard which is accepted in others.

I think of compliance-centric security features as “no” features. If you don’t have them, the response to a sales call is “no”.

Risk-centric

You’re still trying to decide which webserver to buy, and you’ve come down to a few options, all of which meet your compliance requirements: which to choose? Assuming that security is going to be the deciding factor, what security features or functionality do they provide which differentiate them? Well, security is generally about managing risk (I’ve written a lot about this before, see Don’t talk security: talk risk, for example), so you look at features which allow you to manage risks that are relevant to you: this is the list of security-related capabilities which aren’t just compliance. Maybe one product provides HSM integration for cryptographic keys, another One Time Password (OTP) integration, another integrity-protected logging. Each of these allows you to address different types of risk:

• HSM integration – protect against compromise of private keys
• OTP integration – protect against compromise of user passwords, re-use of user passwords across sites
• integrity-protected logging – protect against compromise of logs.

The importance of these features to you will depend on your view of these different risks, and the possible mitigations that you have in place, but they are ways that you can differentiate between the various options. Also, popular risk-centric security features are likely to morph into compliance-centric features as they are commoditised and more products support them: TLS is a good example of this, as is password shadowing in Operating Systems. In a similar way, regulatory regimes (in, for instance, the telecommunications, government, healthcare or banking sectors) help establish minimum risk profiles for applications where customers or consumers of services are rarely in a position to choose their provider based on security capabilities (typically because they’re invisible to them, or the consumers do not have the expertise, or both).

I think of risk-centric security features as “help me” features: if you have them, the response to a sales call is “how will they help me?”.

Why is this important to me?

If you are already a buyer of services, and care about security – you’re a CISO, or part of a procurement department, for instance – you probably consider these differences already. You buy security products to address security problems or meet specific risk profiles (well, assuming they work as advertised…), but you have other applications/products for which you have compliance-related security checks. Other security features are part of how you decide which product to buy.

If you are a developer, architect, product manager or service owner, though, think: what I am providing here? Am I providing a security application, or an application with security features? If the latter, how do I balance where I put my effort? In providing and advertisingcompliance-centric or risk-centric features? In order to get acceptance in multiple markets, I am going to need to address all of their compliance requirements, but that may not leave me enough resources to providing differentiating features against other products (which may be specific to that industry). On the other hand, if I focus too much on differentiation, you may miss important compliance features, and not get in the door at all. If you want to getting to the senior decision makers in a company or organisation and to be seen as a supplier of a key product – one which is not commoditised, but is differentiated from your competitors and really helps organisations manage risk – then you need to thinking about moving to risk-centric security features. But you really, really need to know what compliance-centric features are expected, as otherwise you’re just not going to get in the door.