2 weeks ago I attended RSA Conference 2016 in San Francisco. I had the chance to attend multiple talks in the AppSec track and listen to what the other vendors, thought-leaders and experts had to say. In a nutshell, all talks and discussions revolved around how to get the developers engaged with the security process. Buy them in, get their participation and educate them. I couldn’t help thinking to myself how all of these things have been on Maty’s and Checkmarx’s agenda for over 10 years.
10 years ago, when Maty Siman founded Checkmarx, he approached his new mission from a developer’s point of view. Until today, the core features that we developed back then are a major reason that Checkmarx is the only source code analysis solution that developers adopt willingly. Short scanning cycles, quick mitigation techniques and seamless integration are some of these features.
Of the five sessions I attended, three left an impression on me – some negative, some positive. I will roughly summarize the points discussed in each one of them. This summary is based on my understanding of the sessions and I apologize in advance if I misinterpreted any of the speaker’s points.
A good talk depends greatly on how engaging the speaker is. I would like to start by congratulating Michael on an engaging talk.
As with many talks discussing application security practices, the discussion revolved around processes within the organization and how to improve them. Michael’s talk touched these points on multiple different aspect.
- CISO vs Product Security
Michael brought up the impossible separation between the CISO’s team and the product security team. These two functions are often separated within product organizations. While this may work for waterfall-based development organizations, in a modern agile environment this cannot fly. A central point of security responsibility is a key requirement for a secure product delivery. Separating these two causes a cultural disconnect, as Michael described it.
- Penetration tests
Another interesting point that was brought up is that penetration testing is usually an external function not employed by the company itself. In a fast paced environment organizations should consider having a dedicated penetration testing function as part of the development organization. Security champions within the organization are important however with short cycles of development, penetration testing should be an ongoing task and should not delay projects by requiring weeks to complete an assessment.
Developers are hired to develop code and that’s what they should know best. Secure code delivery should become part of developer’s goals however if we have an automated process for functionality testing we should also have an automated process for security testing. Without automation, any additional requirement from the developer will cause delays and frustration at the developer side. Automation should allow the developer to continue their regular SDL while making security and integral piece of the process. These points and many others, no matter how obvious they seem to the Application Security industry, should be discussed and improved.
This next session was a panel discussion. The experts on stage are leading personas in today’s application security industry and as such I was expecting some interesting discussion points.
The discussion started off in a laid back approach which I like and believe is ideal to deliver important and sometimes boring ideas to the audience.
Attending the talk with me were two additional colleagues. All three of us decided not to stay for the full session. Why? Well, some initial discussion points such as automation, developer adoption and adaptation to modern development landscapes were touched. The discussion points were touched a bit too briefly in my opinion and there was room for more insights to be delivered by the panel. Aside from that, as I am slightly familiar with at least two of the products the three speakers represent I felt that they were discussing challenges which are a concern which, to the best of my knowledge, are not fully addressed by their offerings, for example the ability to analyze small chunks of code in CICD environments without significantly impacting the development process timelines.
As mentioned, I may have missed the more productive part of this panel. We left after approximately 20 minutes with a slight feeling that the content discussed by the three experts could have been much more detailed.
To sum it up, I usually believe that panel discussions can deliver better information than one-man presentations. This time,however, that was not the case.
Kudos to Laksh Raghavan on a well presented case study of one of the more interesting and significant development organizations globally.
Laksh presented a step-by-step case study of Paypal’s enormous Application security implementation and a shift from waterfall to agile development. It’s always interesting to hear an insider’s point of view rather than a vendor talking about the theory.
Let’s start with the challenges Laksh brought up:
- Multiple product teams
- Various time zones
- Different priorities
- Multiple programming languages
- Agile vs Waterfall
- User Stories vs. Comprehensive Documentation
- Minutes/Days vs. Weeks/Months
All of the above make the task of shifting the organization’s processes and standards very difficult – if not impossible – especially in a large organization like PayPal.
The fact that PayPal decided to go through this process with one shot is admirable and seems a bit presumptuous however the rest of this summary will consist of a list of items which point to how it was made possible by PayPalis.
- Embed security champions in each scrum team – Ideally these champions should be dedicated to the security task rather than a developer receiving additional responsibilities on top of their daily tasks.
- Automate and test your automation – In agile development, features and functionalities are developed based on defined user stories. PayPal took this one step forward and created an automated method to allow developers to understand the security stories. This increases developer understanding of their code’s impact on the products security and helps them address security as an integral part of development. Security controls should be enforced on the development process and disabling them should not be an option.
- Avoid introduction of new tools for the developers – Don’t create frustration by changing developer routines. Integrate in a seamless manner and help the developer help security teams.
- No Manual ticketing – Automate vulnerability reporting and create metrics to assist the process
- Assess your program – Without proper metrics you will never know what needs to improve and what has been successful. Run constant analysis on your security and compliance results and understand the trends.
The above is a very high level summary. I don’t know if the RSA Conference will deliver recordings of the talks, however if they do, I strongly recommend getting your hands on this one if you are in the process or thinking about performing a security shift within your development organization.
So it seems that the application security and development world are on the right track, with plenty of room for improvement on both teams. We need to close the cultural gap and remove tension between the teams. Security engineers should understand developer pain points and developers should understand that security vulnerabilities are not less and maybe even more important that functionality bugs.