CIOTechOutlook >> Magazine >> July - 2013 issue

3 Tips to Help Security & Development Team Coexist Together

By

Security and development are known to have a tumultuous–if not antagonistic–relationship with each other. But in this era of rapid development cycles, an explosion of applications, BYOD and increasingly sophisticated attacks, development and security need to rely on each other and work together toward a common goal: keeping the bad guys out. Security needs to rely on the scale and knowledge of development—they are the ones who wrote the code and ultimately, the ones who will fix the code when application vulnerabilities are identified. Yet building a bridge across development and security may seem like a challenge given they typically have different objectives, motivations and incentives. It is not only possible for these two teams to coexist in harmony, but necessary for the business. Here is some advice and insight into development for our friends in the security organizations that aim to help make this relationship more productive.

Learn to “Think like a Developer”

One of the most important things to consider is that developers and security professionals do not always speak the same language. While developers may talk about "defects" and "bugs", security teams will speak of "0-days" and "vulnerabilities". By learning the language associated with the technologies that developers use on a daily basis, the working relationship between these teams could improve significantly.

Security pros that take the time to learn about development processes and working within them (instead of around them) will make nothing but friends with their development counterparts. For example, entering defects using the issue tracking system that development uses in its daily workflow is preferable to using PDF reportsor a separate security-only bug tracker.

Prioritization is a key activity in the development process. Learn to use risk tools to build tailored lists of the most critical security defects for each application. Doing this will help focus the efforts of development and allow them to spend their time on fixing the defects that represent the most important risks for their application.

Finally, always explain "how to fix" with "how to break." Breaking code is a great way to demonstrate the existence of a vulnerability, but without clearly explaining to development how to fix the issue, not generically but in the context of their codebase, developers are unlikely to act. Teaching developers how to actually fix the defect will make you far more effective at communicating with them.

Security is not the only Stakeholder

Security defects are not an intrinsically high priority for the development group. They have resource constraints, release deadlines to meet and other stakeholders to coordinate with beyond just security. If security activities take resources away from things that other stakeholders care about, especially if these activities are unplanned, development can and should escalate to a decision maker who can make the appropriate business trade-off. Therefore, efficiency is key. The more efficient security activities are, the less difficult the trade-off will be.

To make security activities efficient, security teams should work with engineering management to agree upon a Secure Development Lifecycle that weaves security into the way that software is developed. If you are fortunate enough to have the power to impose security gates, think through how development will avoid getting stuck behind them.

The key to enabling secure development is addressing security issues at the most efficient points in the development process. For each weakness type that is in your application’s priority list, consider all of the controls available. Consider the costs and risk mitigation provided by each control, and put appropriate ones in place and plan for them in the next development cycle.

Finally, be realistic about what can be achieved – not all controls can be implemented, and not all defects can be fixed immediately. Trying to do too much at once can cause escalation to upper management which will slow the process down— exactly what development does not want to happen. We have also seen developers get overwhelmed when security teams send those hundreds of defects at once. Moderate these requests by sending, say, 10 critical defects at a time, and requesting a seat at the table to help plan for the next development cycle. You are more likely to get the result you want without overwhelming your development team.

Relationships are Important

Some developers are genuinely interested in security – probably more than you would initially assume. Get to know your development team, and help them incorporate security into their projects.

Doing this right requires building relationships with engineering management. Show them you can be a partner in helping them deliver better, more secure software. You will be rewarded by being brought into the development process earlier, where planning and design is done. This is where the big decisions are made: resource allocation, feature scope and overall system architecture. By being a part of the development process at this early stage, security activities can be baked into the plan at every stage of development.

On The Deck

CXO Insights

The Slow Death of ERP

By Rana Gujral, CEO, TiZE Inc

Blockchain - Infinite Possibilities yet Two...

By Sajal Singhal , Associate Vice President Engineering, GlobalLogic India

Cloud: Its all about WHEN not IF

By Samir Sayed , Global Head - Projects and Services, AGC Networks

Facebook