The BSIMM study focuses attention on software security in large organizations and just at the moment covers the work of 1554 full time employees working every day in 26 software security initiatives. One phenomenon we observed consistently in the BSIMM is that every large initiative has a Software Security Group (SSG) to carry out and lead software security activities.

I wrote about our observations around SSGs in my December informIT article.

Simply put, an SSG is a critical part of a software security initiative in all companies with more than 100 developers. (We’re still not sure about SSGs in smaller organizations, but the BSIMM Begin data (now hovering at 75 firms) may be revealing.)

Cigital’s SSG was formed in 1997 (with John Viega, Brad Arkin, and me as founding members). Since its inception, we’ve helped plan, staff, and carry out ten large software security initiatives in customer firms. One of the most important first tasks is establishing an SSG.

A short one ‘real quick’:

I get simultaneously nostalgic and aspirational as holidays and year-end planning bear down on me. Wondering how to innovate and how to get that innovation into use takes a fair amount of my attention. I wrote a blog post in ‘07 on how to get some of that innovation stuff in your own security group.

McGraw collaborated with Routh recently on an article (“Lifestyle Hackers”) for CSO Online. While the article focuses on what a CSO must do to more intelligently deal with social-media savvy employees, it also elucidates what we all know implicitly: consumers and those building sites to cater to them directly are driving innovation faster than the big guys (who used to do the bulk of this driving out of their research labs) are.

This was driven home by a recent “Daily Chart” from the Economist. Microsoft is #2 in spend. I might argue we’ve gotten a lot of value as an industry out of their security initiative too. CAS has always seemed dead-on-arrival to me but, I don’t see progress as a result of research that’s taking us in a fundamentally different direction in Software Security (look at their stated areas of interest for both “Security and Privacy” and “Software Development”). IBM made the list too, but is last (see my last post, in which I discuss my impression of how quickly IBM will adopt innovations like O2).

Other than IBM and Microsoft, you’ll not find software companies on the chart at all. And, while communities might bring together experts and provide progress, I fear it will be all-too incremental. Security is plainly in the hands of consumers. Yet, as the bevy of Facebook security/privacy concerns indicate, their demands too leave us well short of the goal line.

As I drove Dinis to the final day of AppSecDC he (as often is the case) had his laptop open. We traded ideas regarding the future of O2, support, and other broader issues about the future of software security. As we discussed or machinated over word choice, I found myself in near-complete agreement with him: not an unusual circumstance.

In his post RSnake muses:

I’ll be curious to see if any big companies step up to the plate here and takes ownership. It’s a bit unclear about Dinis’ fate within IBM – I think he’s a bit on the fence.

I characterize O2 as a platform that facilitates a highly-experienced or expert-reviewer in understanding software. While Dinis has taken a few runs at automation and work-flow support (before with his WCF stuff and now with his XRules) I think the principal benefit of his current state of development remains unshackling the reviewer from limitations of a SA tool often in terms of data-flow across language boundaries and through framework / generated code. So important is this concept to myself and Cigital that we’ve built our own framework which we call ‘The Factory‘. We use it for a similar purpose as one might use O2. As Dinis consistently reminds me though it is not open source. And, yes, there’s a lot of other wicked-cool stuff in O2 (the Visual Studio debugger integration is my favorite).

Cigital believes in O2 enough that we’ve conducted hands-on O2 training with a bunch of our guys even after Ounce training. I personally believe in the technical value to code reviewers of O2 enough that I put a modicum of code towards it when Dinis needed it in a pinch. I’ve also agreed to build and publish O2 training for the masses; ‘training that makes it seem less scary.

Taking a step back for a second, there’s a large leap between where the world is and the world Dinis describes in his recent blog post. Unfortunately, I see a lot of organizations doing software assessment driven by (and in pursuit of) compliance only.

So, it doesn’t shock me that IBM hasn’t dived head-first into the O2 pool, regardless of the opportunity it may represent. I believe they will fully embrace it when the market can support it. In the meantime, O2 can continue to find hospitality and support in the welcome arms of assessment experts like Cigital.

I’ve been thinking about this for a while and the tone of this year’s OWASP Global Summit has brought the topic to the forefront. OWASP, as many of you know, is a fiercely open source community. At times, participants defend its open and freeness a bit aggressively for my taste. Sure, open and free are founding principals of the community. I think these principals are essential, valuable, and worth protecting. However, I also believe the community-more broadly-would benefit from an evolved perspective.

Specifically, I believe OWASP should welcome branded security vendors and named individual practitioners into its arms openly. There are three reasons and as I outline them, think to yourself about what vendors like RedHat did for the Linux community.

First – Commercial entities can provide professional and enterprise-level support for OWASP projects to willing commercial entities. Code-based projects (like AppSensor, ESAPI, or other) are easier to imagine the impact of than others.

Second – Large entities seeking to participate within OWASP need assurances which the OWASP community hasn’t itself provided. Things I’ve heard loud-and-clear include:

1. Anonymous participation for industry players working for sensitive organizations
2. Structured feedback, steering, and funding for OWASP projects

Vendors do not uniquely possess the ability to provide these capabilities. The community could provide this value but has not prioritized it nor has it been able to convince industry it could appropriately address their security/anonymity concerns or provide tangible value. Vendors have much better luck in these regards.

Third, finally, and most Importantly – vendors desiring to enter the space should be seen as a welcome sign of maturity to the space. Maturity, to me, will mean key advancements:

1. Larger and less ad-hoc budgets within organizations for application security
2. The emergence of higher and more explicit standards for quality for the community’s free and open software/tools
3. Convergence of the security community’s message, which will allow it to be taken more seriously

To facilitate this, I suggest the OWASP board do the following things:

1. Explicitly endorse vendor participation, as long as it meets the community’s code of ethics and conduct
2. Stop ‘the crank’ over people’s personal / corporate emails being used on OWASP lists
3. Protect a commitment to technical quality by avoiding vendor pitches at conferences in chapter meetings, and in posting

I really don’t mind when people use their corporate email addresses when they mail public lists (OWASP or otherwise). As a chapter leader, I don’t (personally) mind when presenters show up with their company’s slide stock though I push them to use the chapter template. To me, corporate emails and slide stock help audience members identify and appropriately couch bias. Given my own profession and employer, my own biases should be evident.

On the community front, my roles spanning the gamut between OWASP Member, Chapter Leader, and invited industry advisor. I see my professional life and my community involvement as being mutually reinforcing and beneficial, rather than conflicts of interest. I enjoy having two outlets for my time and work. And, while, Yes there’s bad individual behavior out there, I’d like to see people more comfortable with their dual-roles. Again, I think their professional career, their volunteer community, and the industry as a whole will benefit.

Today we officially launch BSIMM Europe, a study of 9 EU firms’ software security initiatives. We continue to focus our inital data gathering on large-scale software security initiatives at major software firms. Firms in the study include: Nokia, Standard Life, SWIFT, Telecom Italia, and Thomson Reuters.

An informIT article can be found here.

The article describes our findings regarding European software security by contrast with the original BSIMM. Overall, we have tripled the size of the BSIMM study to 27 firms with several more under way. We hope to reach 30 firms by year end.

We released BSIMM v1.5 as part of the BSIMM Europe push. The document (released under the Creative Commons) is available for download and now includes an appendix about BSIMM Europe. The original document (v1.0) has been translated into Italian (by Minded Security) and German (by Virtual Forge).

We are very excited about BSIMM progress and look forward to sharing more real data with the community. No more faith based software security!

After what must have been an incredible amount of leg-work a cabal of folk from the DC OWASP chapter are putting on the AppSec DC conference. The conference will also play host to the ‘09 OWASP Global Summit. I hope to see you there. Especially those of you practitioners from within organizations’ security groups–I feel like you provide essential perspective from the trenches of our security war.

Elections
Elections will be held to add another board member to OWASP and I’m anxious to see how the process plays out. Knowing all four announced candidates, I imagine different outcomes based on who receives the nod. In an odd turn of events, I actually like all the candidates; I think they’re great guys. In particular, I’ve known Pravir for many years, I’ve worked with him off-and-on, and respect him deeply.

I’d like to point out Eoin Keary’s bid in particular, because I like his focus on quality and governance. I perceive OWASP be at an inflection point in its development and growing pains are already evident. Selecting particular projects on which to focus, placing them under more rigorous quality control, and working towards maturity criteria others have begun to define can really increase the reach and impact of OWASP. This idea is essential to Mr. Keary’s platform.

Tesauro and Chandra, contributors to project assessment criteria, appear to place importance on this as well. Consider the draft criteria their committee is working on.

Again, I think quality is an ever-more-important imperative as the OWASP community grows and I’d like to see the assessment criteria expand to contain some more explicit and rigorous technical quality gates for a project. As I look at popular existing projects, I am beginning to feel a pressing need for outside review/revision.

Talks
As the Java EE persona of the ESAPI project nears release, I’m anxious to see a more hands-on, more technical, and more developer-focused presentation on the project at AppSec DC. Recent presentations/commentary has felt a bit more like cheerleading to me.

Of course, I’ll be dying to know what Dinis has added to O2 recently and it appears he’ll be presenting on this topic.

Threat Modeling
I’ll be presenting on Threat modeling on Wednesday but I’m also very interested in discussing the topic with the guys from SecurityCompass, who will be giving all-day training on the topic. Rohit in particular, has made what I consider to be top-notch start on his Java EE Security Patterns document and I’m anxious to see the methodology that back-ended their work.

Interacting with academia is an important part of what I do as CTO of Cigital. Though I have been known to lecture at Stanford, CMU, Cornell, Harvard, NC State, Purdue and a bunch of other places, I have a special place in my heart for the University of Virginia (where I studied Philosophy as an undergraduate) and Indiana University (where I earned a dual Ph.D. in computer science and cognitive science).

Alf Weaver, a CS professor at UVa recently asked me to lecture to his Electronic Commerce Technologies course. I was happy to oblige. When I asked what I should lecture about, I got back a one word answer—startups.

Not quite sure of what to do, I decided to draw on my own experience at Cigital. In 1995 when I joined Cigital, it was known as Reliable Software Technologies (or RST) and had a grand total of seven employees. I’m proud to say that today Cigital has over 120 employees and offices in Virginia, NY, Boston, Silicon Valley, India, and Amsterdam.

Helping Cigital evolve has been both hard work and a joy. Here is a list of seven lessons I’ve learned through my own startup years, each boiled down to four words or less:

1. Think and write.
2. Build a network.
3. Follow the Categorical Imperative.
4. Achieve the Buddha calm.
5. Develop a rhythm.
6. Follow your passion.
7. Build great stuff.

The original powerpoint from the CSCS 4753 “Electronic Commerce Technologies” lecture can be found here.

An article version of the talk can be found here.

This is a guest post by Cigital’s resident songwriter, Paco Hope.

In an effort to go down in history as the “Weird Al Yankovic” of Software Security, I’ve released my latest single: This time it’s “White Hat Hacker Man” to the tune of Billy Joel’s “Piano Man.”

And here are the lyrics:

It’s five o’clock on a Saturday
The developers are trying again
The release manager waits in his cubicle
for the build scripts and smoke tests to run

He says how will we do this by Monday?
The security tests haven’t begun
It’s buggy and brittle
and does just a little
of what the sales guys downtown say it can

NIST 800-53, FIPS 140-2, PCI….

Chorus:
Break our new app white hat hacker man
Break our new app tonight
Cause we’re all scared to death of the auditor
But you’ll make us feel alright.

Now Bob down the hall is a friend of mine
He uses tools right off the shelf
He can do just a scan
or maybe try something canned,
but he’s better than doing it yourself.

He says “why do we need these consultants?
I can do all this stuff just the same.”
He doesn’t realize, when the hackers come,
Who the management’s going to blame.

CISSP, MSCE, SANS GIAC

Chorus:
Break our new app white hat hacker man
Break our new app tonight
Cause we’re all scared to death of the auditor
But you’ll make us feel alright.

Now Dave’s the development manager
And security’s a pain in his ass
Cause he knows first and foremost
Features get him his bonus
So security always comes last

Chorus:
Break our new app white hat hacker man
Break our new app tonight
Cause we’re all scared to death of the auditor
But you’ll make us feel alright.

Well it’s been a long day in security
The dev manager gives a sad smile
He knows this release
Despite all their pleas
Will miss their deadline by a mile

And metasploit overflows buffers
And the shell code runs on servers galore
And they burned another sprint
Instead of building security in
So assessments will go on some more

CCIE, OWASP, PMP

Chorus:
Break our new app white hat hacker man
Break our new app tonight
Cause we’re all scared to death of the auditor
But you’ll make us feel alright.

It really feels like software security, as a discipline, has made great progress over the last decade. To begin measuring what firms are actually doing to make software security happen, Gary McGraw, Brian Chess, and I last year interviewed the executives running nine software security initiatives, using the twelve practices of the Software Security Framework as our guide. We used the resulting data to guide construction of the Building Security In Maturity Model (BSIMM). A maturity model is appropriate because improving software security almost always means changing the way an organization works–people, process, and automation are all required. While not all organizations need to achieve exactly the same set of software security goals, our experience is that all successful software security initiatives share common ideas and approaches. Regardless of the details of your software development lifecycle, there is much to learn from the practical experience of others.

Since the original surveys, we’ve continued to gather data in formal interviews. And, of course, more data is always better.

But, we’d really like lots more data. In that light, I’d like to announce the BSIMM Begin survey sponsored by Cigital. BSIMM Begin is a questionnaire designed to probe a firm’s progress relative to the level one BSIMM activities. It is also an experiment in self-reporting. While we exercise great care when performing in-person formal interviews, we realize that approach doesn’t scale into the hundreds in any reasonable time frame. We’re hoping that self-reported data allows for the level of analysis that will provide meaningful results to everyone in the community and, perhaps more importantly, to those participating in the survey.

If you would like to participate on behalf of your firm, please go to http://bsi-mm.com/begin/.

Thank you very much.

This is a guest post by Amit Sethi, Senior Consultant at Cigital.

When generating random numbers in Java for cryptographic purposes, many developers often use the java.security.SecureRandom class. And while the java.security.SecureRandom class is designed to generate cryptographically secure random numbers, there are a few subtleties in the API, and if it is used improperly the output can become predictable. At Cigital we have witnessed a number of cases where this is true. The following is a guide to the proper use of Java’s java.security.SecureRandom class.

First, let’s take a quick look at how the java.security.SecureRandom API works. The java.security.SecureRandom class does not actually implement a pseudorandom number generator (PRNG) itself. It uses PRNG implementations in other classes to generate random numbers. A number of actual PRNGs may actually be used when an instance of java.security.SecureRandom is created. The PRNGs are part of Java cryptographic service providers (CSPs). In Sun’s Java implementation, the SUN CSP is used by default. On Windows, the SUN CSP uses the SHA1PRNG implemented in sun.security.provider.SecureRandom by default. On Solaris and Linux, the SUN CSP default is to use sun.security.provider.NativePRNG which simply provides the output of the /dev/urandom PRNG provided by the operating system. If however, on Solaris/Linux, the java.security configuration file in the JRE is modified such that securerandom.source is set to something other than file:/dev/urandom, then the SHA1PRNG implemented in sun.security.provider.SecureRandom is used, as on Windows. Of course, an application can choose not to use the defaults, and can always specify a particular PRNG implemented by a particular cryptographic provider. In Cigital’s experience, most Java applications that use java.security.SecureRandom actually use the SHA1PRNG provided by the SUN CSP under the cover.

Now, an application will end up with an instance of SHA1PRNG implemented in sun.security.provider.SecureRandom using the following calls:

// The following will create SUN SHA1PRNG on Windows with
// default configuration and Sun JRE, and on Solaris/Linux
// if securerandom.source is modified in java.security
SecureRandom sr1 = new SecureRandom();

// The following will create SUN SHA1PRNG if the highest
// priority CSP is SUN
SecureRandom sr2 = SecureRandom.getInstance("SHA1PRNG");

// The following will always create SUN SHA1PRNG
SecureRandom sr3 = SecureRandom.getInstance("SHA1PRNG", "SUN");

Note that according to Sun’s documentation, the returned java.security.SecureRandom instance is not seeded by any of these calls. If after one of these calls, java.security.SecureRandom.nextBytes(byte[]) is called, then the PRNG is seeded using a secure mechanism provided by the underlying operating system (starting with JRE 1.4.1 in Windows and JRE 1.4.2 in Linux and Solaris). If java.security.SecureRandom.setSeed(long) or java.security.SecureRandom.setSeed(byte[]) is called before a call to java.security.SecureRandom.nextBytes(byte[]), then the internal seeding mechanism is bypassed, and only the provided seed is used to generate random numbers.

For those who are not familiar with the inner workings of cryptographic PRNGs, their job is to take a relatively small random seed and use it to produce deterministic output that seems random to anybody that does not know what the seed is. The PRNG tries to ensure that the output does not reveal any information about the seed, and that somebody observing the output cannot predict future outputs without knowing the seed.

By bypassing the internal secure seeding mechanism of the SHA1PRNG, you may compromise the security of your PRNG output. If you seed it with anything that an attacker can potentially predict (e.g. the time when the PRNG instance was created), then using java.security.SecureRandom may not provide the level of security that you need.

Finally, regardless of how well the PRNG is seeded, it should not be used indefinitely without reseeding. There are two approaches that can be used for longer-term security of PRNG output:

• Periodically throw away the existing java.security.SecureRandom instance and create a new one. This will generate a new instance with a new seed.
• Periodically add new random material to the PRNG seed by making a call to java.security.SecureRandom.setSeed(java.security.SecureRandom.generateSeed(int)).

In summary, keep the following in mind when using java.security.SecureRandom:

• Always specify the exact PRNG and provider that you wish to use. If you just use the default PRNG, you may end up with different PRNGs on different installations of your application that may need to be called differently in order to work properly. Using the following code to get a PRNG instance is appropriate:
  SecureRandom sr = SecureRandom.getInstance("SHA1PRNG", "SUN");
• When using the SHA1PRNG, always call java.security.SecureRandom.nextBytes(byte[]) immediately after creating a new instance of the PRNG. This will force the PRNG to seed itself securely. If for testing purposes, you need predictable output, ignoring this rule and seeding the PRNG with hard-coded/predictable values may be appropriate.
• Use at least JRE 1.4.1 on Windows and at least JRE 1.4.2 on Solaris and Linux. Earlier versions do not seed the SHA1PRNG securely.
• Periodically reseed your PRNG as observing a large amount of PRNG output generated using one seed may allow the attacker to determine the seed and thus predict all future outputs.