It’s the 21st yearly Month of Cybersecurity Awareness, and we are addressing various aspects to aid organizations in handling their challenges related to cybersecurity. In this series of brief articles, we are concentrating on distinct job positions beyond cybersecurity and the approaches their teams take towards security.
For programmers, cybersecurity has, traditionally, been a matter of mixed feelings. The general belief is that developers are disheartened by the need to adapt their work to comply with cybersecurity regulations. Nevertheless, many companies are now accepting a security-first strategy, and some programmers are showing interest.
One such company striving to alter how software developers perceive security is Microsoft, actively engaging in training teams on principles such as intelligence on threats and the motivation of attackers.
Siri Varma, the leading tech and engineer in software development with Microsoft Security, interacts daily with both programmers and cybersecurity squads.
Varma is responding here to three primary inquiries regarding the bond between programmers and cybersecurity:
What obstacles lie between programmers and cybersecurity?
Initially, they have differing priorities. Programmers typically prioritize rapidity, feature incorporation, and speed of launching, while cybersecurity squads emphasize protection and risk minimization. This divergence could bring about tension when security guidelines enforce controls that hinder the workflow according to programmers.
For example, a security instruction may require blocking all internet traffic by default to lessen exposure to potential breaches. This is a topmost practice to ensure only vital traffic is permitted, diminishing the surface vulnerable to attacks. Yet, programmers may resist this, preferring to postpone these stringent measures because finding and allowing legitimate traffic can be a lengthy process.
Subsequently, there’s the gap regarding knowledge; coders might lack the needed comprehension of security methodologies, and cybersecurity units may not entirely grasp the intricacies of the development workflow.
For example, a developer could set up an S3 bucket with public read accessibility, assuming it’s required for the application’s functionality. This negligence can expose all data in the bucket to anyone online. Conversely, cybersecurity squads may not fully grasp the programmer’s workflow and the constraints they encounter, which could lead to misunderstandings about why implementing particular security measures becomes challenging.
What are the common misconceptions between both groups?
The two prevalent misconceptions are considering security as an afterthought and as a mere checklist item.
Developers frequently view security as an afterthought. They might prioritize feature expansion and anticipate addressing security concerns subsequently in the process. This method usually results in reacting to vulnerabilities that emerge.
For instance, consider the case of permitting public access to storage. Programmers might initially configure storage with broad access rights, intending to tighten them later on. This method could become complicated, often demanding an evaluation of network telemetry to determine the resources accessing the storage, ensuring essential functionalities remain operational while restricting access controls.
Furthermore, perceiving security as merely a final task on a checklist rather than an integral part of the development culture has to transform. This transition is solely attainable by embedding security methodologies throughout the development process and fostering an environment where security forms a continuous and collective obligation.
If cybersecurity units could enact one modification, one request, to enhance the security stance of developers, what would it entail?
The most influential request would be for programmers to shift towards security early in the development process. This can be executed through secure coding practices, automated security assessments, and regular code inspections with security considerations. By incorporating security within the DevOps pipeline (DevSecOps), programmers can identify and resolve issues promptly, reducing both security hazards and the expenses linked to addressing vulnerabilities at a later stage.
This integration bears so much importance that the Open Worldwide Application Security Project (OWASP) Foundation has deigned developed models of maturity to guide organizations at various phases of DevSecOps implementation.
As the bond between programmers and cybersecurity units evolves continually, cooperation and mutual responsibility are ever more critical. By embedding security within the developmental process right from the commencement, organizations can strengthen their defenses against emerging threats while fostering a culture wherein security naturally integrates into development.