AppSecUSA 2015

Human human behavior can be reasonably measured by economic theory. Incentives and Penalties are huge drivers that motivate people to behave in certain and predictable ways. The larger the economic benefits, the more coercible is a person to behave in a desired way.When looked from this economic perspective, the security battle seems to be hard to win. due to the skew in economic for various stakeholders in this game
Opponents
1) Perception – Security benefits typically fly under the radar when it’s working well. A good security program prevents incidents and breaches which over time can lead to complacent attitudes by management and finance.
2) Budget - A security professional has a cost or expense budget that cannot be exceeded - hackers have no marginal cost
3) Time - A security assessment has a definite deadline for completion, usually release timelines, etc. No such artificial barriers for a hacker.
Collaborators - Developers, product management
1) Developers have a different goal that they are measured on, usually on delivery – and security issues interfere with their objectives.
2) Product managers are racing against deadlines and competitors to release the product - Any delays have an immediate financial impact, compared to a theoretical exploit scenario.
Application Security professionals
1) An enormous number of false positives in automation (code reviews specifically) due to context differences, wastes a lot of scarce bandwidth.
2) The effort needed on security is continuous, whereas a point in time insecurity can be easily exploited.
3) Application security is still heavy on manual effort- No commercial tools can find functional issues like indirect object reference, privilege escalation, etc.
4) Performing security assessments is expensive- usually billed by the hour. When an assessment doesn’t find anything to report, the cost can be perceived as “wasted”.
Solutions
I propose some practical and tested methods that increase the chances of success. I have listed a few here
1) Have a dedicated application security team. Developers doing security reviews will always have a conflict of interest.
2) The cost of fixing issues identified during Code reviews/penetration testing) is highly expensive , and may even be in feasible to correct without architectural changes. Avoiding bugs is better than fixing bugs. A few of the known techniques(which work) are
a. Developer Training - On Joining as well as on regular(annual) basis
b. Security should be integrated with SDLC - Involvement at the requirements and design review stage can preempt most architectural issues
3) Befriend Developers - relationships typically supersede economic considerations. – Some of our application security engineers (Ex developers) build a very cordial relationship with developers, often aiding them in non-security situations .
4) Incentivize developers, especially when a high severity issue is fixed with urgency, with Rewards, gift certificates, etc. Tap into your company’s incentive program – or start one.
5) Automation - While commercial/open source tools may not have the context to find functional issues, you may customize or build your own tools to reduce manual effort. For example, static analyzers like Fortify have custom rules that can automate human knowledge.
6) Continual Security - Track CVE/NVD for known issues. Tools like OWASP dependency checker can make your life easy.
7) Cost of vulnerability assessments/Penetration testing
a. If you are a B2C organization - Bug bounty programs can help keep costs in control.
b. If you are a B2B service - Encourage your clients to run their own penetration tests on your service. Never miss an opportunity to get free consulting.