Our IT Executive Roundtables 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 "Speed vs. Risk: effective software security doesn't choose," led by the CSO of a financial solutions company. This Session was sponsored by Veracode.
The rising number of sophisticated ransomware attacks has forced companies to consider shifting security left. Making security an intrinsic part of your SDLC shouldn’t slow things down. In fact, if you integrate security and development in the right way, you should be able to speed everything up. For example, security defects will be detected early on, developers will be able to run their own penetration tests, and the security team will always have an open communication channel with the developers. But, developing a healthy relationship between development and security teams is not always straightforward.
During the discussion, attendees were asked to comment on the relationship between development and security teams in their organizations. A CIO started by saying that they have set up a dedicated team to kick off the DevOps journey and are trying to integrate security more into their development practices. A senior executive added that even though they have security controls integrated into their CI/CD pipelines, they are still struggling to move security to the start of their SDLC. A VP told the audience that they don’t let people push insecure code and ensure that people adhere to their secure coding policy by performing periodic audits, code reviews, and vulnerability scans. Lastly, a director shared that they are exploring ways to use data analysis and machine learning to make informed decisions regarding cybersecurity.
Multiple participants agreed that security measures shouldn’t slow down the speed. In today’s competitive market, it’s important to strike a balance between security and risk. A business must be capable of promptly catering to changing market dynamics while keeping real-world risks in mind. However, this can sometimes be hard to achieve. For example, a security team may hold up a release if they detect a potentially exploitable flaw in the code. However, this may not resonate with the business team, who wanted the release shipped out yesterday.
An executive talked about the importance of having open communication between security and development teams. Security engineers should educate developers regarding common and high-priority security risks and action items. Developers should, in turn, seek the security team's approval before installing a third-party/open-source package. Moreover, both teams should be capable of executing penetration tests, performing static code analysis, and identifying potential security flaws. You can’t shift security to the absolute left without enabling seamless collaboration between security and development teams.
A speaker remarked that building an inventory should be the first step of the security journey. Create a list of applications, resources, and environments that you need to protect, and go from there. Without a proper inventory, you will often not know what you are up against. The next step would be to slowly start your threat modeling and find your security champions, i.e., people passionate about security and can be your change advocates. If you can get the managers, scrum masters, and architects on board early on, they can act as the perfect medium to deliver the message to a broader audience.
An attendee shared with the group that it can be hard to prioritize security items over feature requests in a sprint cycle, especially if the security items get added to an active sprint. If developers are asked to resolve a major security hotspot during a sprint, they may not have enough time to deliver an urgent feature to the business team. A solution can be to reserve some time for security fixes at the start of every sprint. Moreover, if any security-related items are expected in the near future, the security team should inform the scrum master beforehand.
Various speakers agreed that boards are now taking a deeper interest in cybersecurity. The main reason for this is the rising real-world incidents, media coverage, and financial losses. There was a time when organizations considered themselves “prepared” if they had cybersecurity insurance, but that is no longer enough. You need to take real security measures, make real investments into tooling and audits, and transform your culture (and workforce) to be more security-centric.