The "RISKY BUSINESS" Blog

My mother always used to say “you should never discuss religion or politics with others”.  As I’m not very knowledgeable in either, nor do they appeal to me very much,  it’s been pretty easy to comply with mom’s guidance. 

Over the last few weeks I’ve learned that there is one more item to add to that list – “Penetration Testing”.   I wrote a blog on Penetration Testing that was intended to stimulate discussion.  The hope was that it would move the conversation forward on an industry subject that sorely needs open and candid conversation that can inch us towards a more standard definition of the same.  Instead, what I got was highly negative feedback that was delivered with a fervor reminiscent of a religious zealot.  The more rationally I attempted to explain my position the more irrational the response – finally I gave up.  My argument was pretty simple – scale the test to ensure that the testing activities are  proportional to the risks the client is looking to validate; that is, controlled to an acceptable level.

While I understand the value of a black-box penetration test, ongoing vulnerability research, and writing custom exploit code,  I find it remarkable that there are practitioners that insist that unless a test includes the same – that it is not a penetration test.  To suggest that the right penetration test for the CIA is the same as the right penetration test for a widget manufacturer, ignores basic risk assessment principles.  The cost of the control should not exceed the cost of the risk it mitigates.  Where a compromised server at a widget manufacturer may be a mildly business impacting  nuisance - a compromised server at the CIA may result in thousands of lost lives.  Clearly, the extent and rigor of the testing for the CIA should exceed that of the widget manufacturer.  I have yet to meet the widget manufacturer who wants to protect himself from custom written exploit code – it’s a risk that they are simply willing to accept. 

I have been following a similar debate on another blog this week that I think is interesting and illustrates my point.  And no …. I am not either of the folks in the conversation :>)

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.

I spoke this week at an event where I was discussing how globalization is impacting information security and used the McDonald's at the Louvre in Paris as a very sad example of how we are unfortunately losing our regional cultures. On the plus side, that same McDonald's and the 31,000 other McDonald's around the world can teach us a lot about information security.

As a person who enjoys dining and tries to eat healthy - I'm not a really big fan of eating at McDonald's.  That being said, I'm amazed by any company that can feed 47,000,000 (that's million!) people per day in 31,000 restaurants across 120 countries and have their dining experiences all be so remarkably consistent.  When you consider the cultural differences, supply chain logistics, and the fact that over 1,500,000 employees are involved in the process ... it's an incredibly remarkable feat (especially when you consider that the vast majority of their employees don't have a lot of education).  How do they do it?

McDonalds has developed nearly flawless, continuously improving, systems for EVERYTHING.  How burgers are cooked, the way the combo meals are packaged, the ratio of ice to soda in each cup, nothing is left to chance.  They have identified every possible process that could be systematized and then they've gone through the process of creating, documenting, implementing, and continuously improving each of those systems.  So what does this have to do with information security?  Everything.

We would all significantly benefit from developing an Information Security "playbook" like McDonald's has for their business that defines the "system" that we need to put in place and the information security processes that we need to operate and optimize.  Fortunately, the basic framework exists: ISO-27001.  It's an Information Security Management System supported by ~ 134 key processes (ISO-27002) that an organization needs to account for when securing their information and critical processes.  Better yet, it's a system that has already been vetted by thousands.

So the next time you are struggling with the challenges of knowing you're secure and proving you're compliant ... think about McDonald's.  Is your challenge more daunting than serving 47,000,000 people every day in  31,000 restaurants in 120 countries? 

Had an interesting (and familiar) call with a potential client yesterday regarding a Penetration Testing proposal. 

"We really like your proposal, but honestly, we are trying to figure out why you are so much cheaper than the other firm that we are looking at ... "    

While it is not always true, I generally believe that there is some credence to the axiom, "you get what you pay for".  It was obvious the client was of the same mind - so our notably lower price put us at a disadvantage  We had a rather lengthy discussion about the issue, and as it is a conversation that I have had many times prior (as the higher priced vendor as well), and I have to assume others are experiencing the same issue, I figured it's a conversation worth sharing.

We agreed that there are 3 probable reasons for pricing to be "significantly" different across different vendors:

1. Project Approach - Unfortunately, there is really no standard definition for a Penetration Test or Vulnerability Assessment. Very frequently we find notable differences in approach that have a very significant impact on the time required to perform a test.
2. Personnel Cost - The hourly rate of the personnel conducting the testing are dependent upon a number of factors including organizational size, sales/marketing/project management costs, cost of the personnel.
3. Equipment/Materials Cost - Every pen testing organization incurs costs for the tools and equipment (vulnerability assessment tools, laptops, pen testing tools, etc.) that they need to "recapture" across projects.

Project Approach

As we don't want to compare Apples & Pomegranates, it is critical that you really understand how each vendor defines a Vulnerability Assessment/Penetration Test. To help clients understand our definition, we have published very specific details of what each class of testing includes.  In the conversation above we found that both our Vulnerability Assessment and Penetration Test were more comprehensive than our competitors.  However, as our methodology employs statistical sampling (validated by 9 years of testing experience) we were going to actively attack less systems than our competitor.  When we explained our rationale, the client agreed, and was satisfied that our approach would fully achieve their objectives.

Personnel Cost

We run a pretty lean organization.  We don't employ a sales team; we prefer to have our consultants who actually perform or manage the work, work with clients to find the best approach.  We are also lucky that the content on our website, recurring clients, and client referrals provide enough leads that we don't need to spend a lot of money on expensive marketing mechanisms (brochures, trade-shows, etc.).  Because we don't need to pay for salespeople and trade-show exhibits the hourly rate we charge for our consultants' time is often a bit lower than our competitors.

Materials  Cost

We don't use "junior" consultants; the least amount of experience that any of our current consultants has is 11 years. So, we don't need to employ expensive "automated" tools (e.g., Core Impact) to compensate for a lack of experience.  Accordingly, we don't need to pass the ~$40,000 per year per consultant in license costs along to our clients. 

So what do patios have in common with penetration testing?  We recently had a patio built in our backyard.  When I collected three proposals, two were very close in price, and the third was almost 40% lower.  I was tempted to dismiss the lowest proposal, but instead asked the contractor to explain the price difference:

1. Project Approach: He had structured the proposal assuming that we could make a slight change to the skirting on our current deck that would allow him to use a less expensive retaining wall in one part of the design as it would no longer be visible.
2. Personnel Cost: He explained that as a smaller company they didn't employ separate designers and project managers. This means less "lost" time.  Further, the designer who laid out the project would actually be the person onsite which also ensured that "nothing would be lost in translation".
3. Materials Cost: They were using pavers that were sourced locally (NJ) where both competitors were sourcing them from Canada. The pavers were indistinguishable from each other and we wouldn't have to pay for the cost to ship thousands of pounds of pavers all the way from Canada.

Once I was comfortable that I was comparing  "apples and apples" , it was time to "Trust, but Verify".  I met with three references where the work looked great and the owners were all extremely satisfied.

Right now I'm a happy camper - adult beverage in hand, notebook on lap, feet resting on a patio that we are absolutely thrilled with (built by the lowest bidder!).  I guess sometimes you can get more than you pay for!

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"

Hopefully, this will be the last time I write about Zeus the banking Trojan.  However, when the New York State Department of Homeland Security releases a five page cyber information security advisory -- its a little hard to ignore it.

It’s a very comprehensive document that provides good guidance, although I was a bit disappointed they didn’t discuss using a non-windows platform and/or running off a live bootable cd or usb.

That being said, I really liked their idea of using the on screen keyboard (osk.exe invokes it) for entering in your password.  It’s a tiny bit awkward ... but it virtually eliminates your password from being stolen via Zeus or similar malware.

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.

Ever have one of those really intriguing moments ... where for the rest of the day your mind keeps circling back and considering the possibilities? I had one yesterday.

A client asked us to help them on a SIEM Proof of Concept leveraging OSSIM (Open Source Security Information Manager). We had tried OSSIM a few years ago with minimal success, but had been intrigued by Alien Vault's stewardship of the project, so we were excited to participate. We figured the best way to get started was to deploy OSSIM in our environment.

Just a few hours later our SIEM Practice Manager grabbed me by the arm with a big smile, "you gotta see this!"

Remarkably, our network had been auto-discovered, a Vulnerability Assessment had been run, net-flows were being captured, we had real-time visibility to network traffic, a snort ids sensor with an appropriate signature set had been deployed, and basic network monitoring functionality was in place.

Now if OSSIM doesn't sound like a conventional SIEM, it isn't. OSSIM integrates a diverse array of existing Open Source security tools into a unified whole which is notably more valuable than the sum of its parts. Surfing our security related data gave me greater insight into our operations and our information security posture. Very quickly we had a comprehensive view of our environment, with one notable exception, we were not yet monitoring device logs (which is really the lynch-pin of SIEM).

It took another 10 minutes or so and OSSIM was receiving logs from one of our more chatty Cent-OS boxes. After updating Snare on our 2008 Active Directory box OSSIM happily consumed our AD logs, although, the regex's will need a bit of fine-tuning to handle a few of the event types we want to capture.

So would Devin Woodcomb proclaim that OSSIM is "awesome"? Not sure yet, but I am intrigued as hell at its ability to provide significant value right out of the box. BTW, I wonder if mentioning that everything we have tested to this point is part of the open source version (free!) would tip his opinion ...

Sadly the ABA's warnings regarding small businesses' use of online banking has not been well heard. Most small businesses have not yet changed their information security practices to protect themselves from banking malware.

King & Little, a NY based marketing firm faces bankruptcy after it was victimized by the Zeus banking trojan.  Over a very short period the attacker emptied the bank account of $164,000.

Understandably (but still way disconcerting), TD Bank advised King & Little that because the theft occurred because one of King & Little's computers was infected with malware that TD Bank is not responsible for the loss.

What is most disappointing is that the online banking sites do not yet have the controls necessary to protect from this type of attack.  For example, requiring out of band (e.g., text message) validation for certain types of events (e.g., new payee added, payments above a user definable threshold, etc.)

I have long been a fan of online banking and had taken precautions, most notably not using a windows based machine for my online banking.  Post this incident, I built an Ubuntu based machine that is only turned on when I am doing banking.  Further, I have restricted outbound and inbound access to HTTPS to the specific banking sites I use. The user account that I use to do the banking has limited rights as well.

To this point I am not aware of Zeus, URLZone, Clampi, or SilentBanker targeting Ubuntu. Should that change .. it may be time to find my old checkbook ...  

* * * * * * * * * * *

Check out our Techno-Blog for a safe, simple solution!

Lost in the glow of Operation Aurora was the American Bankers Association (ABA) recommendation “that small to midsized businesses only conduct online banking on dedicated work-stations”.  On first blush,  sounds like sound information security advice; so why is it that I find this so significant?

Because the banking industry  finally “gets it”. 

When the ABA (dedicated to enhancing the competitiveness of the nation's banking industry and strengthening America's economy) suddenly throws a wet blanket onto online banking we have reason to be concerned.  In short, what they are saying is that online banking is only as secure as the end-point that it is conducted on and that the viruses, spyware, Trojans and identity-stealing key-loggers that regularly infect computers are something they no longer can pretend they can control.

They finally get that HTTPS, strong passwords, and two-factor authentication can’t keep us safe from ourselves and the increasing risk posed by organized crime.

Unfortunately, the proposed solution, while it may be the best we have, is insufficient.  Even a dedicated workstation is vulnerable to malware infection, even if “safe” web practices are followed (comically, AVG just reported that I happened upon a malware loading site following  a link on organized crime and online banking while researching this post).  What we need is a trusted, fully immutable, computing device – I have to think someone really smart is working on this right now.

In the meantime, I’m not worried enough to give up on online banking.  However, I won’t do it from a windows machine any longer.  Right now, I’m only using my iMac, but plan on moving to either a dedicated Ubuntu machine or a bootable USB Linux. 

I thought this blog post on “more secure” options for online banking was well done.