Our Roundtable Sessions are invite-only events hosted by peers for peers that bring together a select group of senior IT leaders from across industries for topic-driven, intimate dialog on current trends and topics. The group met remotely to discuss development vs. security, who is responsible for AppSec, led by the CISO of a global technology and multimedia company. This Session was sponsored by Wabbi.
Security is no longer just InfoSec’s job. It’s a business requirement that all relevant stakeholders must collectively fulfill. Developers must ensure that they have security top-of-mind while designing products and writing code. Security teams must collaborate with the developers during all the stages of the SDLC and ensure that the proper security controls and policies are being implemented.
There’s an apparent necessity to bridge the gap between development and security teams. Security considerations need to be pushed to the left of the SDLC – developers need to be trained to make application code secure by design. Providing developers with the tools to automate and monitor security controls and checks themselves can help in this regard. There is also a need to establish procedures and frameworks for better communication and collaboration between the two teams.
Educating your developers regarding security is especially important if you’re moving to the cloud. Before an application gets deployed on a cloud platform, it must be scrutinized for any security flaws or vulnerabilities. Development and security teams must collaborate to ensure that there are no misconfigurations in the way the application is deployed on the cloud. A tiny misconfiguration (e.g., an overly permissive firewall, publicly accessible storage bucket) can potentially put your infrastructure at risk of compromise.
An executive told the audience that a secure product is one that goes through a formalized, well-documented process of becoming secure. The process must be reviewable, unanimously agreed upon, and devoid of any doubts. The first step to formulating such a process involves collecting business requirements and translating them into practical action points.
Another attendee chimed in by saying that the definition of “secure” differs for different products. For example, ensuring 99.99% uptime of an internally used documentation tool may not be your #1 priority. However, if we talk about a tool that’s used by the sales team to track customer journeys, you’d have to go the extra mile to make it highly secure and available.
Various executives agreed that security is a quality issue. Developers are often very conscious of their code quality. If security is added as a metric for code quality, developers are very likely to start taking it seriously.
A speaker remarked that developers are great at solving problems. And security is just another problem that they must solve. It’s important to let developers know that security isn’t an add-on and not an afterthought; it’s an intrinsic functional requirement. Once they understand this, they should be able to identify and collect requirements for security, just like they would for any other feature.
A participant said you don’t always have to release X amount of new features to be a good product. These days you can use security and compliance as your differentiating factors. E.g., you can release a new version which announces your compliance with various security standards and regulations, such as GDPR, HIPPA, and PCI DSS.
An exec mentioned that OWASP SAMM (Software Assurance Maturity Model) is a great resource for analyzing and improving your secure development lifecycle. It includes various best practices for governance, design, implementation, verification, and operation functions. Another great resource is Microsoft SDL (Security Development Lifecycle), which presents a refined process to develop and maintain secure software.