The "RISKY BUSINESS" Blog

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.

Last week I bemoaned Axe Shower Gel's packaging and noted that we were working on some changes to our Penetration Testing service offerings to better meet our client's assurance objectives.

Over the last 9 years we have found you can generally divide our Penetration Testing clients up into a few broad "stereotypes", clients who:

1. View a penetration test as a necessary evil (e.g., small banks and smaller SAAS providers who conduct them to satisfy a regulatory or customer requirement).

2. Are pretty confident that they have things "screwed down tight" but just want a quick test to make sure.

3. Have a business driver (e.g., regulations, client attestation) and consider penetration testing to be integral to their security program (e.g., larger banks and SAAS providers).

4. Operate in a high threat/high impact environment where penetration testing is viewed as critical (e.g., critical infrastructure, law enforcement, eGovernment).

Recognizing that "one size" doesn't fit all, we have tried to align our Penetration Testing offerings to provide assurance consistent with our clients' varying objectives:

• An Investigative Pen Test - emulates an attacker that doesn't have a lot of time, and doesn't have a lot of tools, and may not even be targeting you specifically. He may stumble upon an interesting portion of your infrastructure during a broader sweep and will leave  relatively quickly if he doesn't find an obvious security problem. Attackers that get in through a blank or default password on an administrative account are Investigative Attackers.

• An Intentioned Pen Test - emulates an attacker that has more time, and a few more tools than the Investigative attacker. More importantly, she has intent. She is targeting you and wants to find a weakness in your network. Attackers that get in by exploiting an unpatched vulnerability in an operating system or network service are Intentioned Attackers.

• A Tenacious Pen Test - emulates an attacker that has time, tools, intent, and determination. She is willing to go the extra mile to make it past your defenses. She may even attempt social engineering to find a way beyond your perimeter defenses. She will do it quietly, though, and take care to go unnoticed. Attackers who convince your help desk to reset an account password for them are Tenacious Attackers.

• A Zealous Pen Test - The primary difference between a Tenacious Attacker and a Zealous Attacker is that a Zealous Attacker won't try to stay under the radar. He will do things that get noticed. He may even intentionally disable access to services to see what happens. More than intent and determination, he has a belief that he needs to breech or damage your systems, one way or another. If he has any worries about covering his tracks, they are secondary to the success of the attack itself. Attackers who crash your mail server and deface your website are Zealous Attackers.

Just as packaging matters when it comes to shower gel, we believe it also matters when it comes to security testing. So choose wisely, and dispense exactly what you need. Remember, "one size does not fit all!"
 

We are fortunate enough to work extensively with across both government and private sector clients. The two biggest differences we notice are that government entities are much more risk-intolerant and that most government entities employ some form of Security Certification & Accreditation (SC&A) process.

Figuring out why most government entities run SC&A is pretty straight forward. Being risk intolerant, means that you are going to spend whatever dollars are necessary to mitigate the biggest risks. Large projects (e.g., moving your core accounting application off the main-frame to a 3 tier J2EE architecture) that embody significant change embody significant risk, hence, lets ensure that the application is secure before we deploy it (SC&A). Another driver, is the federal government advocating (or mandating) SC&A (e.g., NIST 800-37) for federal entities, which has trickled down to many states and larger cities.

What is not as clear to me is why private sector companies don't have formal SC&A processes. Any information security professional worth their weight in salt knows that change = risk. So why are so many systems deployed without sufficient testing? I wish this was where I came up with a clever answer, but I have none. I'm hopeful that advances like SAMM will change the situation.

On my flight back from Phoenix I had an interesting experience that reminded me that what we do is still as much an art as it is a science.

I was asked to review “Managements Response” to the findings & recommendations we provided during the Security Certification and Accreditation process for a very large, mission critical, application for a government client. In doing so, I often referred back to our original reports to ensure that the responses/schedule that they proposed were reasonable, appropriate, and likely to achieve the security objectives that management had defined for the project.

During the review I suddenly felt a little queasy. Unfortunately, the blame was mine (not the gourmet airline cuisine); in reviewing our findings and recommendations it became apparent that we had failed to identify a (perhaps significant) risk. There’s still a little five year old left in me – as the first thought that popped into my head was “If I don’t tell anyone …”.

As you might imagine not missing security risks is pretty important for an Information Assurance firm. To that end we have formalized our processes wherever possible, including at least one Quality Assurance review by a second consultant. In this particular case I had provided QA and had missed the same issue that the primary security consultant had.

Thoughts swirled …. Why on review did this issue suddenly become apparent? What can we do to reduce the likelihood that this happens again? More importantly what can we do to prevent this from happening again? Even more importantly – what did we need to do to prevent this issue from delaying the deployment of business significant changes to this critical application?

First the great news – after considerable angst on our part we determined that the “new risk” was fully mitigated by an existing technical control. The application rolled out to everyone’s satisfaction on schedule. The good news – we have made several subtle changes to our QA process to make this less likely to happen. We also sampled a number of our previous Certification projects to ensure that this was an isolated incident. The less than good news – the reminder that despite progress, Information Assurance is still as much an art as it is a science.

On both sides of the fence (build versus assess) there have been some significant Information Assurance advances over the last five years that have moved us more towards a “science”. Dozens of major universities are now offering excellent programs. OSSTMM is a very intriguing methodology for security testing that we are increasingly leveraging elements of. We utilize elements of prevailing logical frameworks and/or good practices (ISO 27001 and 27002, COBIT, CIS, NIST, and OWASP) which allow us to take as consistent and methodical approach as possible . Unfortunately, as new technologies emerge (e.g., flash, Web Services/SOA) the frameworks are still alrgely applicable but good pratices often trail.

So for now, my goal will have to be more Leonardo Davinci than Albert Einstein — as comfortable with a paint brush as I am with a telescope.