One of the (many) challenges that attracted me to a role within Information Security was to seek a way of better integrating and aligning the benefits of both amazing products alongside amazing information security.
Now, 'amazing' security need not require multi-million $ appliance-level technology or investment, but should be sat close to the edge of the trail-blazing curve from both an AppSec and InfoSec standpoint both through practices, culture and attitude.
What do I mean?
Well, right now I'm not 100% certain, hence this blog post (I'm looking for ideas and validation/criticism) but here's the concept:
What if Security itself became a 'Product' for the business much like any other they produce?
Or perhaps - but I am shying away from the idea for a few reasons I'll explain - a set of features/requirements that are baked in to every product we release?
Sure, best practices and ISMS frameworks mandate/dictate what 'best practices' look like, but there is something deeper and more resonant that I think they miss - especially when 'regulation' isn't the reason to include a feature, for example password complexity on consumer accounts.
The example I've been using lately is the concept of 'time travel' and the fact that customers may not realise they want the e-retailers they choose to do business with to be 'time travel aware':
By this I'm thinking of a scenario where the consumer is shown (via application logs to a SOC) to login from IP X (let's say found to be based in Paris) but then 5 minutes, and hour, or perhaps 3 later from IP Y based - say - in Vietnam...or China...or Indonesia. Time travel. They sure didn't jump on a jet and buy a widget from you in that time. Nor did they likely choose to VPN to that location and then loop back and browse our sites.
Now, ask a consumer if they'd like this functionality within the products they use...and I'd guess they'd say 'yes' - it seems like a sensible way of detecting someone 'rattling the lock' of the retailer's security practices. But until asked they probably didn't know they needed, or even expected this product/feature.
Often - and in light of well-publicised recent industry breaches - I feel it's fair to say that consumers don't always know or are able to articulate what these Product features would be that would help keep them and their data safe and warm in the vaults of their trusted retailer. They DO care, but they may have expectations they've simply assumed we all follow.
So this is where 'Security as a Product' comes from in my mind. Security doesn't sit on the periphery of 'Product'. nor the same for 'Engineering' as its own entity. Instead Security becomes a product (or perhaps a set of tailored features?) with a assigned Product Owner ensuring that the best interests of the product are always represented from a Security perspective. Perhaps part of Site Reliability Engineering?
Yes, you can argue it's just a twist on, or perhaps explicit part of, what a CISO's role is. However the reality is that the CISO is usually only one person with a constrained team, and conversely the product-set a wide ranging catalogue too large to manage day to day at the level I'm trying to convey in this thought piece.
The diversity of Products requires dedicated care and attention - and a vanilla set of requirements from 'Security' are hard to whitewash across all in the same way...and, too, are unlikely to be applicable to all and potentially even damage the Products, UX and ultimately the business.
So that's where my head is at right now - Security as a Product - I'd welcome thoughts, feedback, criticism.
Now, 'amazing' security need not require multi-million $ appliance-level technology or investment, but should be sat close to the edge of the trail-blazing curve from both an AppSec and InfoSec standpoint both through practices, culture and attitude.
What do I mean?
Well, right now I'm not 100% certain, hence this blog post (I'm looking for ideas and validation/criticism) but here's the concept:
What if Security itself became a 'Product' for the business much like any other they produce?
Or perhaps - but I am shying away from the idea for a few reasons I'll explain - a set of features/requirements that are baked in to every product we release?
Sure, best practices and ISMS frameworks mandate/dictate what 'best practices' look like, but there is something deeper and more resonant that I think they miss - especially when 'regulation' isn't the reason to include a feature, for example password complexity on consumer accounts.
The example I've been using lately is the concept of 'time travel' and the fact that customers may not realise they want the e-retailers they choose to do business with to be 'time travel aware':
By this I'm thinking of a scenario where the consumer is shown (via application logs to a SOC) to login from IP X (let's say found to be based in Paris) but then 5 minutes, and hour, or perhaps 3 later from IP Y based - say - in Vietnam...or China...or Indonesia. Time travel. They sure didn't jump on a jet and buy a widget from you in that time. Nor did they likely choose to VPN to that location and then loop back and browse our sites.
Now, ask a consumer if they'd like this functionality within the products they use...and I'd guess they'd say 'yes' - it seems like a sensible way of detecting someone 'rattling the lock' of the retailer's security practices. But until asked they probably didn't know they needed, or even expected this product/feature.
Often - and in light of well-publicised recent industry breaches - I feel it's fair to say that consumers don't always know or are able to articulate what these Product features would be that would help keep them and their data safe and warm in the vaults of their trusted retailer. They DO care, but they may have expectations they've simply assumed we all follow.
So this is where 'Security as a Product' comes from in my mind. Security doesn't sit on the periphery of 'Product'. nor the same for 'Engineering' as its own entity. Instead Security becomes a product (or perhaps a set of tailored features?) with a assigned Product Owner ensuring that the best interests of the product are always represented from a Security perspective. Perhaps part of Site Reliability Engineering?
Yes, you can argue it's just a twist on, or perhaps explicit part of, what a CISO's role is. However the reality is that the CISO is usually only one person with a constrained team, and conversely the product-set a wide ranging catalogue too large to manage day to day at the level I'm trying to convey in this thought piece.
The diversity of Products requires dedicated care and attention - and a vanilla set of requirements from 'Security' are hard to whitewash across all in the same way...and, too, are unlikely to be applicable to all and potentially even damage the Products, UX and ultimately the business.
So that's where my head is at right now - Security as a Product - I'd welcome thoughts, feedback, criticism.
Security as a product is an interesting concept. I think one of the main issues I see is the security team investing in excellent technical solutions which are by passed by the business functions. Recently there has been a shift to the value of integrated solutions from point concepts. But for the business lines to buy in we need to design these with user experience in mind. There is no point investing in the best solutions the market has to offer if these aren't intelligently designed from a security and user experience perspective. Maybe changing to the product view could drive this forward. Susanna Holden (Harper) IBM UK Ltd
ReplyDelete