Overcoming Objections to an Application Security Program

Today a large percentage of security professionals truly “get” application security. They understand the importance, the best-practices, the value, etc. What inhibits their success the most in building an effective application security program is a lack of buy-in from the business and support from development groups. Justifying the investment remains extremely challenging and many security professionals tend to encounter the same objections. I brought this up to Jeff Williams who agreed that assisting people overcome the most common objections with packaged language would be useful. Jeff then helped me develop the content below. Please, if you find any of this useful, by all means steal away! Nothing would be a bigger compliment to the authors.


The business says an Application Security Program is unnecessary because:

"There have been no security problems in the past, nor is there any evidence we’ll be attacked in the future."

It is very fortunate nothing bad has happened, that is known of. But, relying on luck is not a reliable security strategy for the future. Nor is luck a legally defensible position in the event of an intrusion. Assurance is required, as is visibility into the type and frequency of Web attacks, to understand the current security posture. It is possible the website was previously compromised, but this can’t be known for certain without being proactive. The fact is virtually every industry report says Web security is the #1 digital threat organizations face and the vast majority of websites have serious vulnerabilities. The Web Hacking Incident Database (WHID) has catalogued organizations that have experienced unfortunate Web application related incidents. Many lost customer data, intellectual property, were infected with malware, suffered fines, etc. A true Application Security Program helps organizations manage their risk.


"Security is an IT problem. They have firewalls, patch & configuration management systems, and SSL currently in place protecting us."

These security measures are designed to defend at the network/host layers of the infrastructure, and they’ve done a really good job. So much so that today’s attacks have moved up the software stack to the application layer where traditional security controls offer little to no protection:

• Firewalls specifically allow port 80 & 443 Web traffic to pass, including malicious attacks, unencumbered through to the website.
• Patch management keeps commercial off the shelf and open source software up-to-date, but anything custom, developed in-house or out-sourced is simply not covered. Secure code must be internalized.
• SSL assures the confidentiality and integrity of data while in transit, but does not safeguard applications that are under attack directly.

To get real application security, the focus must be on the application itself.


"We need new features first and there is no discretionary budget left to allocate towards security."

Fortunately, the resources necessary to implement an effective application security program do not have to be large or operationally disruptive. If done properly, a program can be cost-effectively structured where security assurance can be realized, resulting in higher quality code with negligible additional costs and development time. By implementing a program incrementally, and being sensitive to IT operations and capital expense budgets, coordinated investments can be offset by consistent savings. What is also well understood is the costs relating to an intrusion, which include downtime, legal liability, regulatory fines, downtime, customer revolt, etc. are far less to add security up front.


"Hackers can't break in because our Web application can't be accessed externally."

It is true an external attacker cannot directly attack an internally-facing Web application remotely, but this is not the only threat model that must be considered. Incredibly common in today’s environments are malware infected machines located within the corporate network, can be a launching pad for intranet attacks. These machines can be remotely controlled, individually or collectively, when they connect out to an external central control system. Malicious JavaScript located on blogs, social networks, or infected websites can be leveraged in the same way as conventional desktop malware. JavaScript can instruct a browser to scan and attack other machines on the internal network, particular weakly defended Web applications. There is also the ever present insider threat. With economic conditions as they are, there are those with motive and opportunity within the network that can cause significant financial damage.


"We outsource our software development and the vendor is responsible for making sure the code is secure."

Third-party software vendors should not be implicitly trusted to deliver secure code without any requirements to do so. Experiences shows software vendors and their clients often possess very different views on what has been agreed to. To prevent conflict and disappointment, software development agreements should require vendors to specify how their code is tested for security. Ask them to describe their internal process or perhaps have the code tested by a third-party firm before customer acceptance. Also to prevent long standing risk, vendors should be required to fix identified vulnerabilities within a certain amount of time before and after acceptance and as long as the software is relied upon.


The development manager says the existing Application Security Program is enough because:

"We use penetration-testing services. We fix or accept the risk of any issues found, which keeps us safe."

Penetration-testing simulates an actual attack, measure true exploitability, and determine an organizations defense readiness with all protective measures in place. The results of which are predominantly a list of vulnerabilities, poorly defended systems, and open avenues of attacks. This is invaluable intelligence, but does not specifically measure what has been done to assure the security of an application. Penetration-tests show when something is wrong, but not what is right. Properly documenting the stages of architectural design, access controls, code implementation, quality assurance, and deployment must be done separately.


"We passed our most recent compliance audit and not required to do anything more."

Compliance-based security, even under the best of circumstances, only establishes a very minimum baseline of risk reduction. The Payment Card Industry Data Security Standard (PCI-DSS) is the most direct regulation affecting Web security. Compliance, or validation of compliance, with PCI-DSS may prevent an organization from receiving fines, but certainly not from being compromised. There are numerous well-publicized examples of organizations that passed compliance audits, such as TJX, Heartland, and Network Solutions, who subsequently suffered major breaches. While compliance may help improve security where none previously existed, the fact is these standards are slow moving and have difficulty adjusting to a shifting threat landscape. True, if the organization trusts a generic compliance standard with the ongoing safety and viability of their business, then no additional security is required. However, if doubts remain, additional security measures are warranted to properly mitigate risk.


"We trust our developers and they already know how to develop secure code after completing the training course."

Security cannot be assured through trust, it must be achieved through verification. While having developers well versed in security is of tremendous value, the lack of formal processes and technology prevents an efficient and effective application security program. The proper application of process and technology ensures code is securely built, implemented, measured, and consistently improved. These are fundamental tenants of software security maturity models such as OpenSAMM and BS-IMM, but also recommended by basically every Secure Development Lifecycle (SDL) program recommended in the industry.


"We already have scanning tools. Doing more will slow down the development process, inhibit innovation, and add large unnecessary costs."

True. Just adding scanning tools, including free and open source products, to the development process will undoubtedly cause disruption. Adding “more security” this way will not work. However, by implementing an application security project incrementally with a thoughtful combination of people, process, and technology – development speed, quality, and security can be improved significantly without disruption.