‘DIRT CLEAN’ -a technology rationalization approach for security controls

Security is a boardroom topic and not a hard sell these days.

Not saying the job of the CISO has become easier, but certainly getting funding is less of a herculean task as it used to be 10 years ago. Everyday we get updates about breaches regardless of the size or cyber budget of the organizations. Smaller companies not investing adequately in security capabilities are expected to face the heat but why the larger organizations are hacked despite spending in millions and billions?

This question requires a deeper introspection, it is not always money that hinders a company’s ability to put up a solid hackerproof defense. It is the combination of people, process and technological maturity that should go hand in hand for stronger security posture. Fair enough but why companies with humongous cyber budget can not bring the needed maturity to improve security?

To me the answer is deeply rooted in four factors– a) trying to build a “best in class security” with a “defense in depth” approach that at times hurts more than any help  b) decision paralysis in product selection c) lack of a clear RACI(accountability model) between CIO, CTO and CISO organizations d) too many checks and balances in governance process stalling implementation agility. This is a general theme I have seen in last 20+ years in security industry. In this article I will focus more on the first point and see if we can come up with a solution to address.

Organizations usually don’t have a clear definition of need vs desire when it comes to picking security controls. Organic growth, M&A activities, fear of causing operational impact, breach news in the media and vendor pitch are some of the well-known factors for piling up security controls that is also a manifestation of a “shiny-toy syndrome”. Adding unnecessary security controls rather open bigger security holes than closing a few because the more tools we add, the bigger the likelihood of keeping unpatched or under patched security controls.

As a result, we are opening holes, slowing down system performance, killing the incident response agility, adding operational complexity and last but not the least spending more on capital and operational expense. So, what is the answer here? Technology rationalization of the control set is the need of the hour to strengthen the posture, making operations more agile in responding to incidents and improve application performance. But industry is full of vendors providing overlapping coverage, every product has some niche strength that is important for security. How to do the rationalization? Do we paint the picture with only one or two vendors? Do we go for the best of the breed product in every control category? These are the usual questions coming in mind when we talk about control rationalization and my answer to this is the approach called ‘DIRT CLEAN’. When you have too many junk things in your house, you need to cleanup unnecessary things, the same applies in security control space.

Developer experience is a critical part when we make technology stack decisions. Security controls should have open APIs for the developers to be able to access and fix their applications without needing to invasively change the application architecture. The tools should be well integrated with CI/CD pipeline and able to automate using code. If developers don’t like the experience, they will bypass the control. Importance level - High

Industry trends will be another aspect that we have to be keeping our tabs on. We don’t want to add or remove a security control that is not on the line of the industry trends. For example, if we select a control that is not artificial intelligence, machine learning based supporting open API connectivity with orchestration ability, we are not looking for the future. Importance level - High

Regulatory requirements will be another area we have to be very careful about while adding or removing security controls from our stack. We must be up to the speed on various compliance and regulatory aspects like PCI-DSS, NYDFS, HIPAA, GLBA, MAR, GDPR, SOC1/2 and many more based on the industry of operation. We can not afford to do a rationalization missing the regulatory ask and being financially or legally penalised by the pertinent authorities. Importance level - High

Threat landscape is the core requirement that any control rationalisation decision should be based on. Pickup any framework (E.g. MITRE) that is TTP (tactics, techniques, procedure) focused in identifying the strength and weaknesses of the current posture before adding or removing something from the portfolio. Importance level - High

Consolidation of capabilities will be a key focus area for technology simplification. Consolidation not only improves performance or financial expense; it also improves the security posture by reducing the attack vectors by keeping less things unpatched or under patched by mistake. Importance level - Medium

Lean operating model is something to be considered as one of the core principals of technology rationalization. Leaner stack helps in improving performance, lowering capital or operating cost while improving security posture with increased agility in operational response. Importance level - Medium

Economic sense will be a major factor to be considered behind security control rationalization exercise. The goal will be to cut down the budget from maintaining too many security tools that add marginal value in improving security posture. Importance level - Low

Agility in incident response is probably the most important aspect of this exercise. Whatever security controls an architecture or engineering team deploys are used by security operations team. SecOps folks are the real customers of these tools. If the tool does not enable them to faster identification and remediation of security incidents, it does not serve the purpose of the operations team. Importance level - High

Negligible performance impact should be introduced by the security tools for developers and business clients to accept it. Importance level - High

It is observed that organizations often debate on best of the breed controls versus consolidation of the capabilities. Often in order to do a data driven product selection, security organizations forget to look at the basic things like risk vs reward analysis, does not consider if the marginal security benefit that warrants burning too much of calories in terms of detailed proof of concept vetting. This results in a decision paralysis which causes more harm by keeping the window of opportunity open to the hackers as opposed to an agile implementation with less feature set to close a major security gap. So, we have to be agile, burn calories judiciously during bake-off and follow the above-mentioned DIRT CLEAN rationalization approach in an agile fashion to bring in the maximum-security benefit to the organization.