The "RISKY BUSINESS" Blog

Have noted a gradual and interesting change over the last few years.  Our security assessment “read-out” meetings where we discuss our findings in detail with the client have gradually become more strategic in nature.  We still spend quite a bit of time talking about the more tactical elements of risk mitigation (e.g., what configuration changes need to be made, what patches need to be deployed, what coding changes need to happen) however, we are now spending more time discussing the root cause of the issues and  what upstream changes are necessary to reduce the likelihood that the identified problems re-appear.

Even more interesting to me is that we are having conversations even further up the tactical/strategic continuum at initial meetings with our clients.  The momentum around ISO-27001 is remarkable.  There is a much smaller, but still notable buzz around OWASP as well.    Clearly, information insecurity is evolving. 

Personally, I’m excited by the change.  To me it represents a very significant inflection point – one where we stop looking for technical “silver bullets” to our pain points and we begin apply a more structured methodical system to being secure and proving we are compliant.  Leveraging the most open and trusted standards possible – especially those that are well vetted and widely recognized is common sense.

There are many implications to this shift up the continuum, I’m optimistic that the most notable will be that the process will become simpler resulting in a significant improvement in security postures.

Thought that Errata Security's recent survey mapped well to what we have seen regarding Application Security Practices:

• While 50% of software development companies say "security is 'always' a concern ..." only half of those firms have a formal Systems Development Life Cylce (SDLC) in place.
• Software developers usually wait for a security incident to occur before calling in a security expert. Companies then look to to integrate secure coding practices as a response.

It's very interesting to me that while the vast majority of developers/application owners recognize the importance of security, SDLC's are usually non-existent, do not adequately integrate security, or are not complied with. This would imply that it is a resource constraint: time and/or knowledge. 

Time constraints are illusory in that the failure to address security adequately in early solution stages is well understood to ultimately cost more time than it saves. 

This infers that it is a knowledge constraint (perhaps exacerbated by a time constraint).  This "feels" consistent with what we see during security assessments or during incident response.  What may be surprising is that it is often business management's lack of knowledge relating to application security that is most impactful, as they "own" the responsibility to ensure that an SDLC is in place and operating as intended.

We recorded an on-demand webinar around OWASP that addresses this knowledge constraint.  Enjoy.

"Leveraging OWASP to Reduce Web App Data Breach Risks"

Fair warning -- this blog takes place from the top of my soap-box, so continue at your own risk!

We all know that application security, especially web application security is real complex, and can only be addressed by equally complex technical solutions like web application firewalls, virtual system patching, ... NOT ....

Having been involved in one too many breach incident responses the last few weeks, I'm increasingly convinced that my belief that complex challenges demand simple responses is the right path. My challenge is convincing others .. so it's up onto the soap-box. As a pure assessment firm we often end up leveraging root cause analysis post incident. Invariably, the perceived root cause "we were vulnerable to SQL injection" is actually the symptom of much more fundamental causes: "we failed to conduct proper tests before deploying", "our developers were not sufficiently knowledgeable of web application attacks", "we failed to understand the risks to the application", etc.

Raise your hand if you have an SDLC. Not too bad, now; keep it up only if your SDLC:

• Is current (has been updated within the last year,
• Includes security touch-points throughout the life-cycle,
• Includes OWASP Top 10 touch points for management, developers, & testers,
• Is enforced by an IT Steering Committee (or equivalent) and includes milestones for key phases.

I could add another ten bullets ... but being everyone's hand is down by now ... I think you get my point.

The good news is that there is some new and very well done guidance on integrating security into the SDLC. OWASP's Software Assurance Maturity Model (SAMM) is a terrific new resource. Rather than define SAMM ... I'll steal the high level description from OWASP's site:

The Software Assurance Maturity Model (SAMM) is an open framework to help organizations formulate and implement a strategy for software security that is tailored to the specific risks facing the organization. The resources provided by SAMM will aid in:
• Evaluating an organization's existing software security practices
• Building a balanced software security assurance program in well-defined iterations
• Demonstrating concrete improvements to a security assurance program
• Defining and measuring security-related activities throughout an organization

One of the things I like best about SAMM is that it was targeted at non-security personnel and non-application developers which means that it can be governed by normal business folk. SAMM helps make an S-SDLC a simple solution to a complex problem.

Remember simple ≠ simplistic ... (time to climb off the soap-box and get a new cup of coffee!)

We have an on-demand webinar that talks to this specific issue, SAMM, and OWASP as a whole that I recommend you look at if this blog piqued your interest.