Welcome back to our series on building security programmes. A series we hope helps you not only better secure your organisation, but also highlights CDW’s commitment to help customers approach security holistically and effectively with their unique business context in mind. 

In this instalment, we’ll focus on the beasts that are Product organisations. 

The amount of flexibility (and lack of accountability) that some Engineering departments are offered in the name of accelerating innovation can be an absolute nightmare for the CISO. 

It’s often not limited to security problems either, although the business is often unaware of the broader issues generated. 

It usually comes down to a lack of architecture and code quality, because many engineering functions seem to only be expected to deliver requested functionality, and fast. 

Hundreds of random system instances generated unused code full of potential (and sometimes obvious) security vulnerabilities, and other unknowns. These platforms can make even the most hardened DevOps and Site Reliability Engineers pull their hair out, as can the poorly architected and inefficient compute functions that inflict enormous excess cloud costs. 

These are just some of the things rarely noticed by the business, but that can make any concerned CISO stew with frustration. It’s no surprise I’ve heard Engineering departments referred to as the “Fountain of Risk”. 

In terms of security being a quality function and helping reduce tangible business costs beyond just reducing risk, getting involved in Engineering and Product is also probably the biggest contribution we can do as security practitioners. Not only because a runaway Engineering function is likely going to require a lot of SecOps resource, but because fixing the fundamental issues causing the vulnerabilities and incidents is likely to drive significant quality and cost improvements. 

But because few realise this, it’s also likely to be the one the business pushes back the hardest on when we try to apply good security practices to it, so communication on the benefits here is important. It’s often the department where all deliverables are seen, but all the external costs it inflicts are not. We must present a larger picture where those costs are visible. 

It’s not limited to what we mentioned before either. These costs include more technical debt, the need for more computing and the associated environmental and financial costs, less stable applications, reduced application performance, more effort to remediate defects, and every new change or feature will become just a little more difficult, time consuming, and expensive to implement. 

I’ve seen first-hand how poor engineering practices resulted in huge numbers of vulnerabilities. I’ve also seen them cause seven-figure amounts of excess compute usage, generate change requests that should have taken days to take months due to excess complexity, led to burnout and turnover in support staff, affected the viability and/or saleability of a product, and even bleed out a company’s capital reserves, forcing painful restructuring and layoffs. 

There is also the issue that many product development engineers and managers are oblivious to client companies’ expectations when it comes to product/service security in a B2B context. (They’ve never seen a security questionnaire and have no idea what’s in most regulatory or compliance standards.) 

Combatting all of this is the rationale behind this part of the framework. 

So, let’s quickly cover what I include in it. 

The first thing is about product features: What minimum security features should the product have? For example, you may set a policy that all your products should be able to integrate with a third-party identity provider, have end-to-end encryption, store credentials with certain encryption mechanisms, feature MFA, and so forth. 

After that I define that we want full security documentation of each application which explains what platform it runs on, what the authentication mechanisms are, how data are stored, what the data flows are, how each function works, and so forth.  

In some organisations it makes sense to have two copies. The first a detailed version for internal use the second a less granular one that can be presented to clients for pre-sales and due-diligence reasons. 

Other components can vary but will focus on ensuring the quality and consistency of development processes. 

This can include guidelines or policies on which languages to use, rules around libraries, best practices around the use of GitHub, the overall development process, code reviews, general application security, testing regimes, and so on. 

I think “Product” and “Engineering” could be treated as separate domains with one focusing on the product itself (functional [security] features) and the other one the quality and consistency of development (along with the associated best practices), but I’ve found that combining both has worked well as they complement each other in the psyche of the teams involved. 

Plus, by exposing both Product and Engineering teams (when they are separate teams) to the same part of the framework, it can have the positive effect of helping them better understand each other’s roles and obligations when it comes to security.   

I’ll leave it at that when it comes to this area. Different organisations have different Engineering functions with potentially very different products, the important thing is to keep in mind their impact to the business and the risks and opportunities therein and try to maximise our value and structuring those contributions into our framework accordingly. 

Naturally, if there’s anything we at CDW can to do help you streamline and secure your application development, whether it be advice or some great products and platforms, please get in touch! 

Join us for our next instalment where we dive into Human Factors.