Network World has named Veracode to their 10 IT Security Companies to Watch. Sim Simeonov has some commentary on this is his blog.

Recently I got a message from Kelley Jackson Higgins of Dark Reading. She was looking for some comments on Fortify Software’s new paper on “Cross Build Injection” or “XBI”. I had read the paper and, while I think the issues are real, the way they are framed they miss the big picture. So I figured I would partake in a little “XPI”, that’s “Cross Publicity Injection”, and take this opportunity to talk about the larger issue of accepting code into the build process. The Dark Reading article is here.

Whenever externally developed code of an uncertain security posture is made part of software, it adds an unknown amount of risk to that software. The external code could be an open source framework or it could be a commercial binary library. This external code needs to be treated as radioactive until proven otherwise. Why take the effort to build your software with a secure design process, threat modeling, and secure coding just to have it all fall apart because of a backdoor or critical vulnerability in a library?

Security testing is a partial solution because when you test you are analyzing the entire program, including the external code, but it typically isn’t good enough. It won’t find backdoors and testing coverage is a perennial problem. A good solution is to use static analysis on the external code before you decide to use it. This way, if it has poor security quality and the vendor won’t fix it you can select another library or framework.

Making security part of the acceptance testing process is gaining support in the financial community, which is often on the leading edge of information security. BITS’s FISAP is being used by financial institutions to evaluate their IT service providers. Veracode has customers who are using our Vendor SecurityReview to evaluate the security quality of COTS products before they purchase them. We now have ISVs who use externally sourced binary libraries and other binary components as part of their applications coming to us to get this code reviewed.

Just because you didn’t write the code doesn’t mean you aren’t responsible for its security quality when you include it in your software. If you have a secure SDL for your developed code, but you aren’t analyzing the external code in your application, you still have unknown risk you are shipping to customers or accepting yourself to run your business.

Think of the big picture of external code. Sure “XBI” is real. It is foolish to automatically pull down code from an external site every time you run your build. But just setting up an internal repository for external code won’t solve the problem. The real solution to external code risk is vetting that code before you use it.

XKCD has a funny web security theme today:

We were more than pleased to read a new report by John Pescatore of Gartner recommending that security managers adopt the use of the Common Vulnerability Scoring System (CVSS) to support more repeatable, fast-acting vulnerability management processes.

This recommendation backs up the decision made by our CTO, Chris Wysopal, more than a year ago to adopt the CVSS standard as a part of the Veracode rating system.

Another interesting recommendation in the report is: “Enterprieses should ensure that processes are in place to detect, assess, and manage each software vulnerability class.” You’ll need a combination of static, dynamic and manual testing to do it all.

Gartner requires you to have a login to read the entire article.

On a side note, we are now linking to Technorati:
Technorati Profile

Sometimes when you are deep in the forest looking at one branch of one tree, trying to reduce false negative rates for detecting a specific class of software vulnerability, it is useful to step back and look at the forest of what is going on in criminal hacking.

Today we were throwing some ideas around the office about hacking techniques we had seen reported. This got the discussion flowing towards extrapolating and using techniques in new areas. The following is a list of old and new.

Gaining network access

• Popping open the TNI box outside someone’s house and running a phone cable from the test plug at their house to another location to steal their phone line when it’s not in use.
• Cloning ESNs on analog cell phones to steal cell phone access (Oki 900)
• Getting a job somewhere just to explore and use the computer and phone system. (Local Phone Co Central Office, Data Entry jobs, janitor),
• Piggybacking behind someone with a badge
• Printing your own visitors badge (with Bold Unescorted label)
• Getting tours of facilities to learn more about their computers and phones
• RFID skimming to get into a facility
• Walking onto college campuses to use open labs
• Hooking up a wireless access point onto someone else’s network while inside their building, or paying someone else to do it
• Bouncing/proxying traffic through multiple countries and jurisdictions
• Free wireless hotspots!

Compromising Machines for Identity theft

• Parking lot wireless attacks (TJX)
• Access point spoofing, commonly in airports, conferences, or other public areas
• ATMs with hacked circuit boards that transmit track data over 802.11 or GSM
• Jump on IRC and pay someone to set up a phishing attack
• Using USB keys to load remote access and keystroke loggers on computers you have physical access to at retail stores, schools, doctor’s office, etc.

What old hacker tricks have you seen and how would you apply the old to the new?