Contributed by Rajesh Laskary
Cybersecurity threats are evolving by every passing day and so the level of sophistication with which an attack can be planned, organized and executed. In the past organizations have been more focused around ‘Quality’ and less on ‘Security’. Now we are witnessing a shift wherein organizations have started considering ‘Security-By-Design’ in their products or applications alongside quality while embracing the ‘agility’ of fast-paced agile software development. What we need to keep in mind is, ‘Security’, ‘Quality’ or ‘Agility’ is not just about tools and processes, it’s more about a cultural change in an organization, understanding vulnerabilities, it’s about the change in the mind-set of people working for your organization to view things from a different angle.
Let’s assume a scenario (and trust me it’s omnipresent in one form or the other in every organization) before we start and let me set the background.
“ Your system/business analysts are always on their toes as business keeps changing the requirements and there is always a never-ending discussion taking place on the scope or the priority of a business requirement and hence your development teams are also under tremendous pressure with ever-changing scope or priority of business requirements, last-minute design changes, CI/CD (Continuous Integration and Continuous Delivery) issues, daily scrums and other meetings, pressure to deliver at a fast pace and in a short sprint etc.
Similarly, the Testing and Quality Assurance teams are testing something which they have just received late in the sprint, they have just encountered something that was changed and they were not aware of it till the very last moment, they haven’t yet finished their SIT (System Integration Testing) and sprint is about to complete and they do not have sufficient time to regression test the system or for performance testing. (Do you think they’ll have time to think of ‘Security’?)”
The ‘Security’ and the ‘Quality’ tussle:
‘Quality’ of the product has always been of utmost importance to any organization and now ‘Security’ has started sharing the time, resources and budget which once only belonged to ‘Quality’.
We’ve seen budget and resource constraints in the past while delivering a quality product and unfortunately quality/testing teams have always suffered from budget cuts, ratio of number of developers to testers/quality personnel has always been in midst of debate as most of the project managers most of their budget will be consumed in to product development itself.
Today when there are hundreds of players in market full of competition, organizations are not only shifting left and trying to fix the ‘Quality’ issues in early stages of the SDLC (System Development Life Cycle), they have already started considering ‘Security’ an integral part of their SDLC equally to ‘Quality’ while maintaining a pace with the ‘Agility’ of the agile project management.
This article tries to give an insight into today’s fast-paced organizational developments as to how Agility, Security & Quality should be seen or perceived together and not in silos.
Security is everyone’s responsibility, so the Quality is:
Few things to keep in mind, when you think about securing your information assets versus the quality of the product being developed.
o You can’t secure ‘everything’, you shouldn’t and you won’t be able to but that does not mean you should leave everything in open.
o On the same lines, There will be quality issues no matter how hard you test
o Do consider that you’ll be hacked one day or probably you’re being hacked now as someone said, so keep a plan B ready.
o You can’t always go behind the attacker and you shouldn’t.
o Security is everyone’s responsibility but ensure the accountability is taken care of equally.
o There are companies which were fined millions for a product quality issue or lost some reputation but there are companies that went bankrupt because of one security incident.
Shifting left, No matter it is Security or Quality:
If ‘quality’ is ‘right’ when you’re on the steering wheel, ‘security’ is to your ‘left’. You need to take both into account while you’re on a driver’s seat and decide whether to take a left or right at each turn depending upon where you’re heading to. Shifting left is not just about moving left on the project timeline or to move to earlier stages of your System Development Life Cycle, it also means going back to the basics and doing the right thing, at the right time (when it is needed the most). A defect (be it a security issue or a quality issue) identified in early development phase will save you an enormous amount of money and resources.
Agility will impact both Security and Quality:
Now after all this how confident you are on quality or the security of the product? Do you know what issue can be left untested, what security requirements were missed (maybe not at all considered in the first place), maybe not developed at all (or even if developed, the developer left some back doors or did not implement a certain portion of it due to time pressure), or who knows if security requirements were considered by system analysts, developed and implemented by developers, tested by testers BUT still are you sure that there will be no quality issue in production or there won’t be any security incident due to a bug which was never revealed during SDLC?
While ‘Agility’ is like an ‘Accelerator’ of a running car, ‘Security & Quality’ can be compared to ‘Breaks’ and a balance must be maintained with an equal focus on both on each stage of product development. There is no harm in slowing down, taking a pause for a moment and take a cognitive decision in the direction you’re heading to.
What’s your plan ‘B’ for ‘Security incidents’ and for ‘Quality issues’ and where does it all overlap?
Everyone can be and everyone will be hacked one day or the other or there is a high probability it’s happening now. It’s just that you don’t know when it will happen. There will be quality issues, bugs once an application or a change is deployed to the production environment and there will be security incidents no matter how hard you test or how strong your quality or security processes are. So does that mean we should not be testing enough or we should not build enough security controls in our systems? How much enough is ‘enough’?
o What is your project budget?
o How much of the budget, time and resources should you allocate for product quality & how much for security testing?
o Is it possible to combine both?
o How does the SDLC process ensure that quality and security go hand in hand and there are controls in place to validate both?
o What is the criticality of information the system is handling?
o Is it an internal application or an internet facing?
o What could be the potential impact of a quality issue?
o What could be the potential impact of a security incident?
o And, many more such basic questions.
Once you have answered the above questions, the immediate next question is, what is your plan ‘B’ if any of quality issue or security incident take place? And, how does plan ‘B’ addresses the impacts at following fronts:
The One Perfect Solution:
There is no perfect solution to any of the problems mentioned above and the focus should always be on the best available solution and the most optimum one catering your security and quality needs. While thinking of a solution, one thing that is of the paramount importance is that the change should always begin at the top and both quality and security should be endorsed equally by the ‘C’ level while maintaining the agility in the organizational processes.
Yes we know a lot about quality, however, we can always balance it with security by:
o Bringing a cultural change and including security in the organizational processes.
o Security training and awareness among all the employees.
o Imbibe the security requirements in early system design and ensuring that security is integrated into the development process.
o Building, implementing and validating security controls in each phase of SDLC.
o Training and educating the developers on best application security practices or secure system development.
o Training the testers on basics of cybersecurity and security testing.
o Automate as much as possible.
The resources should be deployed to ensure that there are no controls remaining which have not been validated thoroughly. We cannot completely eliminate a risk (and we should not try to) but we can definitely lessen the impact on the organization. And most importantly ‘Bring-Security-In’ before you plan to ‘Build-Security-In’.
We at CISO MAG are set to publish the Power List, a comprehensive publication which will explore critical areas of cloud security while elucidating best practices to adopt for securing the cloud space. Ahead of it, we are discussing several trends and vendors in the space while we tell you what differentiates each product from the rest.
The opinions expressed within this article are the personal opinions of the author. The facts and opinions appearing in the article do not reflect the views of CISO MAG and CISO MAG does not assume any responsibility or liability for the same.