An report from May 2021 has found that 81% of developers admit to knowingly releasing vulnerable apps, and 76% experienced pressure to sacrifice mobile security for expediency. What needs to change so we can break out of this cycle and where does it need to start – bottom-up or top-down?
More stats that stand out from the report: 20% of senior management often signed off on unsafe apps while 80% appeared to be shifting the blame to developers for not doing their job properly. On the other hand, developers seem to blame a lack of resources.
The ongoing debate of why software and applications with vulnerabilities are making it to market is multi-faceted, with several stakeholders involved. Everyone seems intent on passing the buck: DevOps teams, their functional buyers (the primary users of the project), even CISOs. Many claim that patching is just an unavoidable fact of life.
The Biden administration in the US has recently voiced its concerns, too. It has called into question the reliance on post-sale bug patches, suggesting that companies should be required to build software in secure development environments. The stamp the administration plans to introduce to allow the public and the government to determine if the software was developed securely may cause developers to re-examine their environments and improve the overall security standard of applications.
Whilst this solution will act as a form of accreditation, is it the only solution to stopping mass vulnerabilities? Or do we need to accept patching as an unpleasant truth?
Software development security is everyone’s responsibility
The first and most important concept that all stakeholders from C-suite, to Security, to Operations, Development, Project and Product Management need to understand is that security is everyone’s responsibility. Development cannot blame lack of resourcing, management cannot blame developers for not doing their job properly, Operations cannot blame overwork when failing to install upgrades and patches promptly.
If all participants in the software development life cycle (SDLC) are not invested in the security of the solution, the environment, and the solution’s full lifecycle, then the process is prone to failure. Management, Project and Product Management all need to ensure that they are allowing for the time, effort, and investment in tools that Security, Operations, and Development teams need to ensure that they have a secure application.
Now that everyone is in the right mindset and we are sharing the responsibility for the security of the application, let’s talk SDLC. There are standards, tools, and guidance to help implement secure development practices in your DevSecOps activities. In the case of SaaS solutions, implementing automated vulnerability assessment, security baselines, patch management, endpoint protection, detection, and response solutions in which the environment the application is delivered is also critical.
Patching
Equally, though, it’s difficult for developers to anticipate every security gap and vulnerability for every update, which is why patching exists. Patching is an unavoidable fact of life and should be a top priority for IT teams. Yet, in the threat-rich world that security and operations teams work in, patching often takes a back seat to other threat deterrence tasks.
If a vulnerability is not identified today, it does not mean one does not exist. It is ideal to incorporate rapid response to vulnerabilities into application designs. Designing for forward compatibility, which allows a system to accept input intended for a later version of itself, for any third-party components and an ability to drop newer versions to production quickly helps to respond to zero-day vulnerabilities or critical vulnerabilities that are identified in the field.
Planning for a swarming process of cross-functional collaboration vs. traditional out-of-band (OOB) response methods prepares a team for agile response to security threats. It may seem like the same thing, but unscheduled out-of-band release cycles are not well organized and very disruptive to the SDLC.
Preparing for and anticipating security responses to happen in parallel with release activities trains teams to quickly identify key resources to resolve the vulnerability, provide them essential support, and provide a quick route for delivery of the update to resolve the threat while the rest of the development team executes their current activities undisrupted.
The security diligence does not stop there. Up to now we have established a good security mindset for all participants in the SDLC, established foundational secure coding practices, and implemented tools and activities to properly secure proprietary and third-party code as well as the cyber hygiene of the environment (in the case of SaaS solutions).
The security of the development environment is also critical and played a significant part in the SolarWinds incident. Therefore, many mature application development organizations adopt an “assume breach” mindset.
Zero trust
Organizations should look to incorporate zero trust into the development environments. Secure the user, secure the device, secure access (and data). Three simple principles, but when implemented effectively will significantly mitigate the possibility of a data breach that could allow an attacker to access an organization’s supply chain. This can be done by constantly verifying the network, device, and context of a user as they interact with an application.
Patch management, endpoint protectionmobile threat defense, EDR (endpoint detection & response), application control and privilege management can establish good cyber hygiene of devices. Moving to zero trust access to limit access requests to only what is needed and continually assessing the user and device during a session will verify that an authorized person is attempting to access data.
Integration of the SDLC with other IT service management processes like enterprise service management and unified endpoint management can reduce the operational burdens on IT teams. Integration ensures infosec teams are not flicking between different applications to perform tasks, allowing them instead to do so through a single pane of glass removing complexity and enhancing productivity.
But the jewel in the crown of patch management technologies is hyper-automation. Hyper-automation, like deep learning supervised learning and unsupervised learning, makes an enormous difference in threat mitigation and detection. They take the burden of a time-consuming job away from IT teams allowing them to monitor releases and production environments in real-time as the information is gathered from a range of online resources.
This brings us back to cybersecurity’s two core principles: systems development security is everyone’s responsibility and constant vigilance is the price you pay for peace of mind. Both need to become part of your company’s DNA.
Credit: Source link
