The DevSecOps Playbook: Deliver Continuous Security at Speed
InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory
Jan 31 2024
How to make developers accept DevSecOps
According to a recent Dynatrace report, only 50% of CISOs believe that development teams have thoroughly tested the software for vulnerabilities before deploying it into the production environment.
This is a statistic that needs to change and the only way to change it is to make sure developers are on the same page as security practitioners.
The challenges
Making developers accept the importance of security in their software development process comes with numerous challenges. They can be split into four categories:
- Tool-related challenges
- Practice-related challenges
- Infrastructure-related challenges
- People-related challenges
Integrating security tools into existing DevOps tools can be complicated. “A significant barrier in implementing security into [DevSecOps] is the differences in tool-sets between security and other teams,” researchers Roshan N. Rajapaksea, Mansooreh Zahedia, M. Ali Babara and Haifeng Shenc noted. Also, each team member has their own preferences in tools based on specific advantages.
Some toolsets may also be inadequate, and without standards or documentation developers will have even more difficulties with the integration.
Practice-related challenges involve automation and deployment. DevOps processes are mostly automated, but security requires human action, i.e., manual security practices that are difficult to automate.
Developers are also all about pushing the product as soon as possible, yet, by implementing DevSecOps, the development process needs to slow down to allow possible vulnerabilities to be fixed.
When it comes to infrastructure, a complex cloud environment can slow down secure software development, while a multi-cloud environment can pose difficulties when securing data. Highly regulated environments (air-gapped environments, medical infrastructure, etc.) can also make DevSecOps adoption difficult.
Finally, there’s the people-related challenges: developers may have difficulties with the imminent changes that DevSecOps bring to the development process, and may lack security skills required to carry out certain security practices in DevSecOps.
CISOs and developers (69% and 64%, respectively) both see that the lack of communication and collaboration between developers and security teams is a significant problem.
Implementing DevSecOps will also not work without the right knowledge, which developers have yet to build.
The solutions
To make developers accept DevSecOps, they need to be heard, which means making sure they have a say when security decisions are made. This can contribute to a more productive and constant collaboration and communication between security and development engineers, while also defining roles and responsibilities.
Shifting left is a must, but developers need to know exactly what is expected of them when it comes to secure coding.
“A big part of improving the DevSecOps experience is not introducing more tooling, but getting clear on the process and expectations of how developers should use the tools they already have. Clear communication about policies ensures an organized and consistent approach to implementing security throughout the SDLC,” says Nick Liffen, director at GitHub Advanced Security.
Training is an important part of DevSecOps implementation, but developers need to be reassured that their job will not be disrupted when security gets integrated into coding.
To further motivate them, it’s good to let them see that knowing how to code securely can contribute to both the company’s success and their personal growth.
Learning that being a DevSecOps professional is a good career choice can additionally boost their motivation.
“Between 2021 and 2028, the DevSecOps market is expected to grow at a CAGR of 24.1%. DevSecOps professionals have several job opportunities as a result of this rapid rise. This demand is expected to grow as more companies adopt DevSecOps practices,” said Misbah Thevarmannil, content lead at Practical DevSecOps.
InfoSec tools | InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory
Jan 10 2024
DevSecOps: 5 Tips for Developing Better, Safer Apps
https://www.crowdstrike.com/blog/devsecops-tips-to-develop-better-safer-apps/
According to the CrowdStrike 2023 Global Threat Report, there was a 95% increase in cloud exploits in 2022, with a three-fold increase in cases involving cloud-conscious threat actors. The cloud is rapidly becoming a major battleground for cyberattacks — and the cost of a breach has never been higher. The estimated average cost of a breach impacting multi-cloud environments is more than $4.75 million USD in 2023.1 The acceleration of cloud-focused threat activity and its effects has made security a key priority across organizations.
Security in the Cloud Is a Shared Responsibility
Security teams are accountable for protecting against risks, but they cannot be the only ones. Each team must try to communicate why their part of the development lifecycle is important to the other teams in the pipeline. With the growth of cloud-native applications and the demand for faster application delivery or continuous integration/continuous delivery (CI/CD), the use of containers is increasing widely. As businesses adopt containerized and serverless technologies and cloud-based services, more complex security issues arise.
Application developers have a tricky balance to maintain between speed and security. In DevOps, security used to be an issue addressed after development — but that’s changing. Now, developers who previously had to code right up to the last minute — leaving almost no time to find and fix vulnerabilities — are using tools like Infrastructure as code (IaC) scanning to validate they have fewer security vulnerabilities before they move to the next phase of development.
When security is considered at every step in the pipeline, it ensures developers find and address issues early on and it streamlines the development process. DevSecOps helps developers find and remediate vulnerabilities earlier in the app development process. Vulnerabilities discovered and addressed during the development process are less expensive and faster to fix. By automating testing, remediation and delivery, DevSecOps ensures stronger software security without slowing development cycles. The goal is to make security a part of the software development workflow, instead of having to address more issues during runtime.
5 Tips to Develop Apps with Security and Efficiency
1. Automate security reviews and testing. Every DevSecOps pipeline should utilize a combination or variation of tools and features like those listed below. A good automated and unified solution will provide broad visibility and address those issues as they arise, while alerting, enforcing compliance and providing customized reports with relevant insights for the DevOps and security teams.
- SAST: Static application security testing to detect insecure code before it’s used (tools like GitHub, GitGuardian and Snyk, to name a few)
- SCA: Software composition analysis to detect library vulnerabilities before building (tools like GitHub and GitLab)
- CSA: Container scanning analysis to detect Operating System Library vulnerabilities and mitigate risk (tools like CrowdStrike Falcon® Cloud Security and GitLab)
Figure 1. Dynamic container analysis in the Falcon platform (click to enlarge)
- IaC scanning: Infrastructure-as-code scanning to detect vulnerabilities in infrastructure (tools like Falcon Cloud Security and GitLab)
Figure 2. Falcon infrastructure-as-code (IaC) scanning (click to enlarge)
- ASPM: Application security posture management to detect application vulnerabilities and risks once deployed (such as Falcon Cloud Security)
Figure 3. Architecture view of apps, services, APIs and more in Falcon (click to enlarge)
2. Integrate with developer toolchains. Streamline and consolidate your toolchain so developers and security teams can focus their attention on a single interface and source of truth. The tighter the integration between security and app development, the earlier threats can be identified, and the faster delivery can be accelerated. By seamlessly integrating with Jenkins, Bamboo, GitLab and others, Falcon Cloud Security allows DevOps teams to respond to and remediate incidents faster within the toolsets they already use. Â
3. Share security knowledge among teams. DevSecOps is a journey enabled by technology, but a process that starts with people. Your DevSecOps team should share lessons learned and mitigation steps after resolving the compromise. Some organizations even assign a security champion who helps introduce this sense of responsibility of security within the team. Be prepared to get your teams on board before changing the process, and ensure everyone understands the benefits of DevSecOps. Make security testing part of your project kickoffs and charters, and empower your teams with training, education and tools to make their jobs easier.
4. Measure your security posture. Identify the software development pain points and security risks, create a plan that works well for your organization and your team, and drive execution. Make sure to track and measure results such as the time lost in dealing with vulnerabilities after code is merged. Then, look for patterns in the type or cause of those vulnerabilities, and make adjustments to detect and address them earlier. This introduces a shared plan with integration into the build and production phases. CrowdStrike offers a free comprehensive Cloud Security Risk Review and services to help you plan, execute and measure your plan. Â
5. “Shift right” as well as “shift left.” Detection doesn’t always guarantee security. Shifting right and knowing how secure your applications and APIs are in production is just as important. By leveraging ASPM to uncover potential vulnerabilities in the application code once they are up and deployed, teams can find potential exposure in their application code that could allow backdoor access to other critical data and systems.Â
The bottom line is that while security and development used to be separate, the lines are now blurring to a point where security is becoming more and more integrated with the day-to-day job of developers. The benefit is that the modern practice brings together teams across the company to a common understanding, which then drives business growth. DevSecOps requires teams to collaborate and enables the organization to deliver safer applications to customers without compromising security.
How CrowdStrike Powers Your DevSecOps Journey
Security is not meant to be a red light on the road to your business goals or slow down your software development. It is meant to enable you to reach those goals safely with minimal risk. Falcon Cloud Security empowers DevSecOps teams to “shift left” in the application security paradigm, with tools including Infrastructure-as-Code Scanning, Image Assessment, and Kubernetes Admission Controller, all designed to ensure applications are secure earlier in application development and deployment.Â
CrowdStrike Falcon Cloud Security lets DevOps and security teams join forces to build applications securely before deployment, monitor they are compliant once deployed, and ensure the code is secure during runtime using ASPM. With ASPM in a unified interface that’s easy to visualize and understand, customers can “shift right” to reduce risk and stop breaches from applications that are already deployed.
The DevSecOps Playbook: Deliver Continuous Security at Speed
InfoSec tools | InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory
Dec 20 2023
The Future of DevSecOps: Emerging Trends in 2024 and Beyond
https://istari-global.com/insights/articles/future-of-devsecops-emerging-trends-2024/
In the rapidly evolving landscape of software development and cybersecurity, the integration of security planning earlier in the software development life cycle has become paramount. This practice, known as DevSecOps, has gained significant traction in recent years as businesses recognize its potential to bolster cyber defenses and ensure the security of their digital assets. As we look ahead to 2024 and beyond, it is crucial to understand the key trends that will shape the future of DevSecOps. I wanted to take a few moments to discuss the emerging trends that will drive innovation and efficiency in the field of DevSecOps, including automation, tool consolidation, infrastructure as code, remediation, and the evolution of the software bill of materials (SBOMs).
Key Trends in 2024
Automation Underpinning Innovation
Automation is at the forefront of driving operational efficiency in the field of security. In 2024, we can expect to see further advancements in automation, coupled with artificial intelligence (AI), empowering companies to streamline decision-making processes and optimize resource allocation. By leveraging automation and AI, security teams can focus on strategic initiatives, leaving operational functions to automated systems. This shift will enable organizations to respond to security threats with greater precision and agility, ultimately enhancing their cyber defenses.
The concept of “secure-by-design” will also gain additional momentum in 2024. By establishing cybersecurity standards, detecting vulnerabilities, and addressing them at the outset, organizations can prevent risks before they manifest. This transformative approach will enable businesses to innovate without unforeseen impediments, ensuring that security is an integral part of the development process from the very beginning.
Tool Consolidation
As organizations seek to incorporate security into their processes, the need for tool consolidation becomes apparent. Rather than accumulating an excessive number of tools, which can lead to inefficiencies and increased costs, businesses will opt for more streamlined security tool architectures and services. According to Gartner, 75% of organizations have already begun the process of consolidating their security tools. By merging tool-chain observability and monitoring into a single platform, companies can gain a comprehensive view of their security landscape and identify any potential blockages. This consolidation will create a more conducive environment for building and strengthening security processes.
Infrastructure as Code (IaC)
Traditional IT infrastructure management processes are often manual, resulting in increased costs and resource allocation. With the rapid growth of cloud computing and the constant release of new applications, infrastructure as code (IaC) emerges as a valuable tool. By utilizing configuration files, IaC allows for the automated management and oversight of today’s ever-evolving infrastructure. This level of abstraction frees engineers from the burden of keeping up with constant changes, maximizing the potential of cloud computing and enabling developers to allocate their time more efficiently.
Remediation
In response to the rising threat of cybercrime, organizations are shifting their focus from mere detection to proactive remediation. Rather than simply identifying security breaches, companies are increasingly investing in continuous monitoring and prompt remediation to eliminate threats. Gartner recommends that organizations be prepared to perform emergency remediation on key systems immediately following the release of security patches. To achieve this, companies must adopt intelligent and automated remediation approaches that are integrated into their processes. Prescriptive “best practices” alone will not suffice; automation is necessary to effectively address security issues in real-time.
Beyond SBOMs
The software bill of materials (SBOMs), an inventory of the codebase, has gained recognition as a game-changer in software transparency. However, in 2024, we can expect SBOMs to evolve further to meet industry standards and deliver on their promise. While SBOMs provide valuable insights into the software components used by an application, there are still obstacles to overcome. Many tools designed to automate SBOM generation lack consistency in data provision, hindering their adoption. Additionally, SBOMs have limited value in procurement decisions, as they require frequent updates to remain relevant. To establish a well-managed and secure software supply chain, additional tools such as software composition analysis and code signing will become essential. Achieving this will require industry-wide collaboration, defining best practices, and incentivizing vendors to prioritize transparency.
Security Remains Vital
Despite budget constraints and organizational restructuring, DevSecOps remains a critical area of focus for businesses. Cybersecurity risks continue to be a top concern, and DevSecOps strategies offer a cost-effective solution to mitigate these risks. However, organizations will optimize their budget allocations by investing in solutions that provide actionable results. In 2024, we can expect to see a greater emphasis on remediation, integration of security into the software development life cycle, and automation to streamline operational processes.
Conclusion
The future of DevSecOps is promising, with several key trends shaping the field in 2024 and beyond. Automation, tool consolidation, infrastructure as code, remediation, and the evolution of SBOMs will drive innovation and efficiency in the industry. As organizations strive to enhance their cyber defenses and navigate the evolving threat landscape, embracing these trends will be crucial. By staying ahead of the curve and implementing robust DevSecOps practices, businesses can ensure the security of their digital assets and maintain a competitive edge in the digital economy.
InfoSec tools | InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory
Aug 04 2022
GitHub blighted by “researcher” who created thousands of malicious projects
Just over a year ago, we wrote about a “cybersecurity researcher” who posted almost 4000 pointlessly poisoned Python packages to the popular repository PyPI.
This person went by the curious nickname of Remind Supply Chain Risks, and the packages had project names that were generally similar to well-known projects, presumably in the hope that some of them would get installed by mistake, thanks to users using slightly incorrect search terms or making minor typing mistakes when typing in PyPI URLs.
These pointless packages weren’t overtly malicious, but they did call home to a server hosted in Japan, presumably so that the perpetrator could collect statistics on this “experiment” and write it up while pretending it counted as science.
A month after that, we wrote about a PhD student (who should have known better) and their supervisor (who is apparently an Assistant Professor of Computer Science at a US university, and very definitely should have known better) who went out of their way to introduce numerous apparently legitimate but not-strictly-needed patches into the Linux kernel.
They called these patches hypocrite commits, and the idea was to show that two peculiar patches submitted at different times could, in theory, be combined later on to introduce a security hole, effectively each contributing a sort of “half-vulnerability” that wouldn’t be spotted as a bug on its own.
As you can imagine, the Linux kernel team did not take kindly to being experimented on in this way without permission, not least because they were faced with cleaning up the mess:
Please stop submitting known-invalid patches. Your professor is playing around with the review process in order to achieve a paper in some strange and bizarre way. This is not ok, it is wasting our time, and we will have to report this, AGAIN, to your university…
GitHub splattered with hostile code
Apr 08 2022
Developers Remediate Less Than a Third of Vulnerabilities
Developers Remediate Less Than a Third of Vulnerabilities
Developers are regularly ignoring security issues as they deal with an onslaught of issues from security teams, even as they are expected to release software more frequently and faster than ever before.
In addition, developers fix just 32% of known vulnerabilities, and 42% of developers push vulnerable code once per month, according to Tromzo’s Voice of the Modern Developer Report.
The report, based on a survey of more than 400 U.S.-based developers who work at organizations where they currently have CI/CD tools in place, also found a third of respondents think developers and security are siloed.
Tromzo CTO and co-founder Harshit Chitalia pointed out the top security vulnerabilities of the past few years—Log4j, SolarWinds, Codecov—have all been supply chain attacks.
“This has made AppSec an urgent and top priority for CISOs worldwide,” he said. “In addition, everything as code with Kubernetes, Terraform and so on have made all parts of the development stack part of AppSec.”
From his perspective, the only way this big attack surface can be overcome is with security and development teams working hand in hand to secure the application in every step of the development cycle.
He added developers ignoring security issues is one of the fundamental issues AppSec engineers have with security.
“Security teams put their blood, sweat and tears into finding different vulnerabilities in code through orchestrating scanners and manual testing,” he said. “After all the work, seeing the issue on Jira queue for months is disappointing and quite frustrating.”
Fighting Friction
On the other hand, he pointed to developers who are now asked not only to develop features and fix bugs but also look at DevOps, performance and security of their applications.
“This leads to friction in priorities and, if unresolved, leads to unhappy employees,” he said. “The C-suite is very much aware of this problem, but they are stuck with security tools which are not created for developers. As application security is going through a big transformation, we believe the tooling will also shift.”
He explained there were several concerning findings from the survey but that two, in particular, stood out.
The first thing Chitalia found deeply concerning was the fact that 62% of developers are using 11 or more application security tools.
He said application security has evolved in recent years with AppSec teams now responsible for source-code analysis, DAST, bug bounty, dependency, secrets scanning, cloud scanning and language-specific scanners.
“This means developers are constantly fed information from these tools without any context and they have to triage and prioritize the workload these tools generate for them,” he said.
The second big worry was the fact that a third of vulnerabilities are noise.
“If someone told you that a third of the work you did needs to be thrown away every single day, how would you feel about that?” he asked. “But that’s the current state of application security.”
False Positives a Big Negative
Securing DevOps: Security in the Cloud
Feb 09 2022
Adding Data Privacy to DevSecOps
Colorado and Virginia passed new data privacy laws in 2021. Connecticut and Oklahoma are among the states that could enact new legislation around data privacy protections in 2022. California, which kicked off the conversation around data privacy at the state level, is updating its laws. Couple that with the EU’s GDPR and other data privacy laws enacted worldwide, and it is clear that data privacy has become incredibly important within cybersecurity. And that includes within the DevSecOps process.
It’s been enough of a challenge to integrate security into the DevOps process at all, even though it is now recognized that adding security early in the SDLC can eliminate issues further along in app development and deployment. But adding data privacy? Is it really necessary? Yes, it is necessary, said Casey Bisson, head of product growth at BluBracket, in email commentary. Applications now include more and more personal data that needs protection, such as apps that rely on medical PII. Those apps must have security and privacy baked into each phase of the SLDC via DevSecOps.
“There have been far too many examples of leaks of PII within code, for instance, because many companies don’t secure their Git repositories,” said Bisson. “As more sensitive information has made its way into code, it’s natural that hackers will target code. True DevSecOps will bake privacy concerns into every stage and will make these checks automated.”
Data in the Test Process
In DevSecOps, applications are developed often by using test data. “If that data is not properly sanitized, it can be lost,” said John Bambenek, principal threat hunter at Netenrich, in an email interview. “There is also the special case of secrets management and ensuring that development processes properly secure and don’t accidentally disclose those secrets. The speed of development nowadays means that special controls need to be in place to ensure production data isn’t compromised from agile development.” Beyond test data, real consumer data has to be considered. Ultimately, every organization has information they need to protect so it’s important to focus on data privacy early in development so the team working on the platform can build the controls necessary into the platform to support the privacy requirements the data has, explained Shawn Smith, director of infrastructure at nVisium, via email. “The longer you wait to define the data relationships, the harder it is to ensure proper controls are developed to support them.”
Bringing Privacy into DevSecOps
Putting a greater emphasis on privacy within DevSecOps requires two things—data privacy protocols already in place within the organization and a strong commitment to the integration of cybersecurity with data privacy. “An organization needs to start with a strong privacy program and an executive in charge of its implementation,” said Bambenek. “Especially if the data involves private information from consumers, a data protection expect should be embedded in the development process to ensure that data is used safely and that the entire development pipeline is informed with strong privacy principles.” The DevSecOps team and leadership should have a strong understanding of the privacy laws and regulations—both set by overarching government rules and by industry requirements. Knowing the compliance requirements that must be met offers a baseline to measure how data must be handled throughout the entire app development process, Smith pointed out, adding that once you have the base to build upon, the controls and steps to actually achieve the privacy levels you want will fall into place pretty easily. Finally, Bisson advised DevSecOps professionals to shift security left and empower developers to prevent any credentials or PII from being inadvertently accessible through their code before it makes it to the cloud. “DevSecOps teams should scan code both within company repositories and outside in public repos; on GitHub, for instance. It’s so easy to clone code that these details and secrets can easily be leaked,” said Bisson.
Consumers don’t understand how or where in the development process security is added, and it’s not entirely necessary for them to understand how the sausage is made. The most important concern for them is that their sensitive data is protected at all times. For that to happen most efficiently, data privacy has to be an integral part of DevSecOps.
Understanding Privacy and Data Protection: What You Need to Know
#DevSecOps: A leader’s guide to producing secure software without compromising flow, feedback and continuous improvement
Oct 07 2021
Divide Between Security, Developers Deepens
Security professionals work hard to plan secure IT environments for organizations, but the developers who are tasked with implementing and carrying these plans and procedures are often left out of security planning processes, creating a fractured relationship between development and security.
This was the conclusion from a VMware and Forrester study of 1,475 IT and security managers, including CIOs and CISOs and managers with responsibility for security strategy and decision-making.
The report found security is still perceived as a barrier in organizations, with 52% of developer respondents saying they believed that security policies are stifling their ability to drive innovation.
Only one in five (22%) developers surveyed said they strongly agree that they understand which security policies they are expected to comply with and more than a quarter (27%) of the developers surveyed are not involved at all in security policy decisions, despite many of these decisions greatly impacting their roles.
The research indicated that security needs a perception shift and should be more deeply embedded across people, processes and technologies.
This means involving developers in security planning earlier and more often; learning to speak the language of the development team rather than asking development to speak security, sharing KPIs and increasing communication to improve relationships and automating security to improve scalability, the report recommended.
Set a Clear Scope for Security Requirements
“Regardless of whether if it’s customer-facing functionality or a business logic concern, every line of code developed should prioritize security as a design feature,” he said. “Once security is taken as seriously as other drivers for DevOps adoption, then a fully holistic integration can be achieved.”
#DevSecOps: A leader’s guide to producing secure software without compromising flow, feedback and continuous improvement
Jul 12 2021
APPSEC TESTING APPROACHES
May 20 2021
Hiring remote software developers: How to spot the cheaters
How are software development applicants cheating?
Prior to COVID-19, many companies had engineering applicants take coding skills assessments in person. On-premises testing allowed employers to control the environment and observe the applicant’s process. Now, employers are providing these assessments (and getting observations) remotely, and applicants (almost exclusively at the junior level) are gaming the platforms.
The two most common strategies are plagiarism and identity misrepresentation. In the former, applicants copy and paste code found on sites like Github or they are lifting code from prior assessments administered by the same employer that have been published and/or sold online. (Companies that have only a few variations of a coding challenge will find, with a quick Google search, that prior test-takers have either posted it online or are offering the answers privately. They’ll even sprinkle in some minor differentiations so that it’s harder to catch.) Identity misrepresentation means asking or paying someone else to log in to the test platform and solve the test (or part of it) for the applicant.
Globally, the rate for plagiarism in 2020 was 5.6%, and suspicious connectivity patterns – indicative of session handover to someone else other than the applicant – appear in 6.48% of sessions. We are seeing a slight growth in the percent of sessions with suspicious behaviors, and this growth is visible in both global and financial markets in particular.
Some industries will have higher rates of cheating than others; for example, organizations in the government, education, and non-profit sectors can see up to double the global average for red-flag behavior. The general shortage of HR professionals with deep technical knowledge make practically all employers vulnerable to inefficiencies and the perils of under-qualified tech candidates making it too far into the recruitment funnel. Higher rates of cheating mean that IT professionals need smarter tools to avoid mis-hires.
Addressing this problem needs to be a priority for employers looking to hire remotely on a larger scale or as a permanent practice, because the short- and long-term consequences are always more costly than whatever investments they put into preventative safeguards.
Hiring a person who cheated in the recruitment process is a recipe for disaster, both for the employer and the employee. Job seekers will typically cheat because they lack the qualifications to pass the recruitment process or, sometimes, just lack the confidence that they can succeed. In either case, if the recruitment leads to employment, the nascent working relationship is botched from day one. The lack of qualifications surfaces sooner or later, frequently damaging schedules, reliability, and security of software products and services, not to mention driving business costs up and reputation down.
More alarmingly, common sense and academic research suggest (Peterson et al., 2011; Schneider & Goffin, 2012), says that the lack of integrity has a potential to reoccur on the job, quite possibly leading to security breaches immensely more dangerous than software bugs. Last but not least, it is plainly emotionally difficult for many individuals to grow a healthy relationship towards the employer and the workplace when the relationship started with dishonesty.
![Don't Hire a Software Developer Until You Read this Book: The software survival guide for tech startups & entrepreneurs (from idea, to build, to product launch and everything in between.) by [K.N. Kukoyi]](https://m.media-amazon.com/images/I/51a9ala-KuL.jpg)
