This is the first part of my BlackHat interview with Barmak Meftah, Sr. VP, Products & Services at Fortify.  In this installment, Mr. Meftah shares his perspective on application security and the need for a rigorous risk modeling approach.

Perimeter security is inadequate

“The majority of IT security spending is focused on perimeter security. These measures are reactive in nature,” said Mr. Meftah.   Given the cross-perimeter scope of modern applications, this approach is ineffective.  “With the advent of Web Services and SOA, the attack surface is more exposed and is getting more complex.  The more complex a system is, the easier it is to compromise.”  This view was echoed in a SANS Institute webcast that shows perimeter defenses were not designed to counter the threat vectors that attempt to compromise software applications.

While the business of application delivery focuses on the assurance of functional use cases, the security of these applications must address the related abuse cases.  This approach is possible if a focused, proactive testing framework is applied throughout the SDLC, not just at the release stage.  According to Meftah, “security should be considered early in the software development process.”  Software, like any other product, must go through a quality assurance process that looks for vulnerabilities. 

Software design must address risk

Software, according to Meftah, “must have security built into it rather than being addressed as an after-thought.”  Mr. Meftah pointed out that established industries take risk into account when designing and producing their products.  “This is not the case with software.  Software developers are typically concerned with delivering their product on time and with the desired set of features.  They typically don't think of security measures.”

Meftah stresses that a rigorous assessment of risk is critical to scoping these tests appropriately. “You can't blindly identify problems inside of code without taking the risk element into account.”  It is easy to think of risk conceptually – it is the impact of an exercised vulnerability on a business.  The difficulty lies in perceiving risk in a context shared by management, communicating it to other stakeholders, and using that understanding productively.

Risk must be modeled in a business-centric way

There are many threat modeling approaches available to aid businesses and individuals in assessing applications.  The Open Web Application Security Project (OWASP) highlights methods to characterize threats by their effect on an environment and by the types of exploits that could exercise them.  While this information is helpful, risk assessment must focus on the implications of vulnerabilities on business continuity.   According to Mr. Meftah, “how you assign risk has more to do with how you run your business than any technology issues you may find.”  He highlighted three groups that should be involved in defining application risk. 

1. Engineering

Engineers have a granular understanding of code that is shared by few other stakeholders in an organization.  This insight makes them critical in remediating code vulnerabilities.  This insight can also be a liability, however. Given their intense focus, engineers may not consider the business issues that drive the use of their applications.  This is where business analysts and management step in to communicate this information

2. Line-of-business management

According to Meftah, these stakeholders are able to communicate the business value of the applications in use and the processes their support.  “Without their help, the whole risk assessment initiative will fail," he said.  Their role is especially relevant in organizations with multiple lines of business.  While these departments work for a common company, their organizational goals and politics will vary.  I have seen the same application have a different risk profile accross different internal organizations due to usage patterns.  These differences require organizing leadership in order to create a cohesive understanding of risk.

3. CISO/CSO

The engineering and middle management perspectives must be aligned to address the strategy of the organization.  This responsibility must be championed by a C-level executive that can balance the need for security against the competitive drivers of the company.  As I discussed in The Art of CIO Success, this leader must be able to balance the needs of individual business units against the strategic demands of the company.

The next installment will share Barmak Meftah’s view on how to evangelize security and make it part of the corporate culture.