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.

There are some important good things about top ten lists that are worthy of mention. The notion of knowing your enemy is essential in security (as it is in warfare), and top ten lists can help get software people started thinking about attacks, attackers, and the vulnerabilities they go after. These days almost any attention paid to the problem is good attention, and the fact that the technical media is paying attention to software security at all is a good thing. Top ten lists help in that respect.

But I have some serious concerns about these kinds of lists that I wrote about in my informIT article this month:

Top Eleven Reasons Why Top 10 (or Top 25) Lists Don’t Work

Here are the reasons, stripped of history and commentary which you can find in the article:

1. Executives don’t care about technical bugs.
2. Too much focus on bugs.
3. Vulnerability lists help auditors more than developers.
4. One person’s top bug is another person’s yawner.
5. Using bug parade lists for training leads to awareness but does not educate.
6. Bug lists change with the prevailing technology winds.
7. Top ten lists mix levels.
8. Automated tools can find bugs–let them.
9. Metrics built on top ten lists are misleading.
10. When it comes to testing, security requirements are more important than vulnerability lists.
11. Ten is not enough.

Don Rippert’s comments were (in summary) that by the time you got to any level of specificity in the model that the complexity of the models made them harder to follow than code.

I’ve been using Enterprise Architect to reverse engineer code by loading the code into EA and looking at the generated UML. I’ve given up and gone back to emacs.

The book, however, is a little dated. To prove one of his points, Brooks describes as “extravagant” the use of and additional “10 bytes” to implement leap year support in OS 360′s date code. Now, 10 bytes “back in the day” was indeed extravagant, but for a programmer that has been brought up coding in today’s environments, 10 bytes is less than the guy’s email signature.

As I pondered these 10 bytes, I reminisced about some code I had to maintain in the RSTS/E kernel. The code was:

CMP (PC), 4(SP) ;Is 4 off of SP 4? Saves 2 bytes

This took me and another guy more than a couple of minutes to figured out, but sure enough it saved those precious two bytes. So, just how precious were those two bytes?

Adjusting for the fact that these two bytes were on a 16-bit architecture and today’s machines are 32-bit, I figured that those two bytes are equivalent to 128K. What would you do to save 128K in a space sensitive area of your system or perhaps that application you’re writing for your mobile phone?

So, what does this have to do with software security? Nothing. But, after all, I was on vacation.

One of my favorite books is Engineers of Dreams: Great Bridge Builders and the Spanning of America by Henry Petroski, the wonderful writer on engineering. It is a book about extraordinary success – the construction of the great bridges of America, but it is as much about failure as success. Bridges fall down throughout the book, but each failure shines light on another aspect of bridge design and the limits of the materials. The heroes (the great engineers) learn from their experience and continually build better and longer bridges. What I took from this book, beyond an appreciation of the bridge builder’s art, science, and mastery of the political (all big projects involve politics) is that that failure is something to be treasured once you get past the pain.

My one entrepreneurial failure was in a company that did desktop publishing around 1980. My partners and I bought two NBI 3000’s, very early, very expensive word processors. Businesses in and around Boulder, CO, some students and professors came to us with hand written drafts which we turned into beautiful printed documents. The machines were complicated, temperamental, and difficult to use, though they defined the state-of-the art at the time. Only trained operators could manage them. Word Processing was a task for pros.

Of course the company failed. Things went well for a year or so, but then the first practical PCs and word processing software came out. People began to do their own word processing, even on crude, small, expensive machines. When the IBM PC came out and legitimized PCs, everyone started writing on computers and doing their own desktop publishing. The stream of customers dried up and we closed the doors.

My first thought about Document Control (the company) was that our technology was simply made obsolete — that we were selling slide rules in the age of calculators. I think though, that we were really swept aside by a more fundamental imperative – the human urge to do things themselves. In the Pharaohs days literacy was regarded as something for specialists, and the leading classes hired scribes to perform that difficult task. When the telephone was invented we needed operators; when cars were invented they were often driven by mechanics. Over time in each case the difficult became simple and the rare became commonplace. For the things that count, people would rather do something themselves than have it done for them if it is within their ability and comfort zone.

This principle pertains as much in IT as in other arenas. IT was once entirely the province of the professionals operating in glass houses, who accepted data on cards from the acolytes and returned them manna in the form of green bar. It was inconceivable in those days that computing would become the province of the everyman but, of course, it has.

I am not referring to people using personal computers to access the Internet, using email, and writing newsletters for the PTA. That is really too obvious for comment. What I am referring to is the continuing trend in all sorts of organizations to empower the individual. Individuals prefer simple hosted applications like Saleforce.com to complex CRM from central IT and they use desktop tools like the Microsoft Office Suite to build very complex applications. The things they build are not tightly integrated like the applications built by professionals. Processes may still involve many manual steps that a pro could program in a few hours (after a week of committee and budgeting meetings, another week of design review, and two weeks or so of testing). We pros can do it better – complete automation, all sorts of bells and whistles the rubes would never think of, audit trails, better security, and all that good stuff, but the users prefer the stuff they build (or discover) themselves. It does what they want and they understand it. More than that, it empowers them. They feel in control. In the end, DIY always wins.

Going into word processing was not a mistake. The machines were great and they did things that simply weren’t previously possible. The mistake was in persisting even after the first personal computer showed up. The was on the wall, and it read that in the end, DIY always wins.

In building our enterprise applications we must be cognizant of this same imperative towards DIY. There will always be central IT applications for things like basic accounting – accounts payable, accounts receivable, etc., but organizations are dynamic – buying businesses and being bought in turn, reorganizing, opening and closing business lines, launching new products and dropping others, doing studies and projects. The central IT department is always running behind but the DIY community filling the gap with their jury-rigged lash ups. Giving the pros (i.e. us) a break, though, real IT is hard.

I know that this informal IT – the IT that takes place outside the purview of the IT organization – is already and important part of every business. I suspect that in many organizations these home grown applications may actually be as or more important than the official stuff. My wife who works in the accounting business, for example, is tracking the company’s backlog and progress in an Excel spreadsheet as the tax deadline approaches even though her company uses the best accounting software in the business.

As IT tools have improved, everyone has become a practitioner to some degree, just as our ancestors learned to drive cars and make calls and our ancient ancestors learned the arcane art of reading. A challenge for us as professionals is to give the non-professionals the tools they want and need so that they can define how they do their work, and then work with them, not against them, to improve these informal processes and bring them up to “professional grade.” DIY is a powerful imperative and much of the IT that we now regard as the realm of the professional will inevitably move into the hands of users. We should not resist this, but enable it. I would love to see what users could do if they could have a real-time access, with Excel as a front end, to a company’s core data in real time. What would they build? I know that they would build better tools for their personal work, but they might just go beyond that to provide new insights into the way the company operates and models for how the company’s processes can be improved.

[tags]diy, it[/tags]

We talked a lot about “how much trust do I get for how much analysis and testing” and “how much trust do I need for certain scenarios, like allowing a computer to automatically downgrade data from Top Secret to Secret.” These kinds of concepts ended up in capability maturity models, testing models, and risk models.

I took Ken’s words to heart and quickly made up my mind that we could really only move the trust bar up slightly (like from 10% to 20%), even with enormous expense. It was immediately obvious that getting up to, say, 75% would require so much calendar time that no one would wait for the result (and I think later experience with Orange Book evaluations, Common Criteria evaluations, and related programs have borne this out). Between hardware, software, firmware—and the completely unpredictable human factors—we really had no idea how even the most reviewed code would operate in relatively controlled environments (e.g., in a government facility where everyone was cleared), much less how it would operate in a hostile environment (hostile mobile code was not really a problem yet) where people might actively be up to nefarious deeds.

Why should you care about my reminiscing? Well, because I think a flavor of trust is still a major problem today and it’s costing everyone a bunch of money that could be put into real long-term solutions.

As I talk with my operations friends these days, I’m seeing a subtle shift in their thinking. They’re thinking more and more about appliances (web application firewalls, IDS and stuff like that), but not for direct security value. They seem to be thinking that since the software they install, whether purchased or built internally, will certainly have security problems, they have to install more bells and whistles so that operations can protect itself. This is beyond healthy paranoia; it’s an unhealthy distrust of people who should be active partners, even if it’s been earned by years of spectacular failures.

Then I started wondering why so many development organizations throw out requirements documents from product managers and just start over. Is it only because the requirements are so bad, or is it also because the developers just don’t trust the managers to know what they’re talking about?

And why do so many managers try to tell development organization how to create applications, instead of simply what the creation must accomplish? Do they simply not trust the developers to be aware of business objectives, or do they just not understand the creative processes involved?

And so on.

What an enormous amount of wasted cycles that could be used to greater organizational good.

We may never get to the point where we can implicitly trust software. But, can’t we at get to the point where we can trust each other?

[tags]software security, software quality[/tags]

It’s customary start a blog with administrivia, and this one should be no exception. Justice League will be a joint production of all of the Principal Consultants at Cigital. So, yes, it’s a corporate blog (wah wah waaah) but we promise that it will not suck. We’ll be passing the baton around like a hot potato. “No after you.” “Please, after you.” Somehow I ended up with the potato first.

I guess it’s my job to set the stage and introduce your cast. Many of you know me from my external speaking and writing. I’m Gary McGraw, CTO of Cigital, author of a big pile of books on software security, and host of the Silver Bullet Security Podcast. In my secret other life I am the fiddler for Where’s Aubrey.

Joining me to produce this blog will be <insert drumroll here>:

• Pravir Chandra. Pravir joined the Cigital team from Secure Software where he was Co-Founder and Chief Security Architect. Pravir is best known for his work on CLASP and for running an Operations Security group at AOL. Slightly lesser known is that Pravir was once a research associate at Cigital about a million years ago. In addition to being one of the top minds in the world in software security, Pravir is super nice, brilliant, and loads of fun.
• Scott Matsumoto. The great thing about Scott is that he brings 20 years of hard core commercial development experience to the team. Scott has served as CTO of both Spring Street Networks and Xtremesoft (where he was a co-founder as well). Scott is a seasoned software architect and a database guru. Scott is as self-effacing as he is experienced, but don’t let him fool you—he’s sneaky, clever, patient, and has attained the Buddha calm.
• Sammy Migues. Sammy has a long storied career in security stretching back before I was born (ok, not really). Sammy contributed to the infamous Rainbow Books (thanks, man), helped to invent the concept of software assurance, and has been applying knowledge management techniques to computer security for a decade. Sammy was the Chief Scientist of iDefense and Principal Scientist at Cybertrust before he joined Cigital. Sammy escaped from Louisiana in a similar fashion to my escape from Tennessee-we both found a pair of shoes and slipped across the border.
• Craig Miller. Craig really does have computer science bone fides stretching back to before I was born! In fact, he is the most seasoned technical veteran in the firm. Craig has been Chief Scientist of SAIC, CTO of Proxicom, North American CTO and Global Chief Architect of Dimension Data, and a bunch of other things. Like me, he’s a Dr. of something or other. He’s also a music fanatic, a yarn teller, and a jolly good fellow.
• John Steven. The infamous John Steven (or jS as I call him) has been with Cigital for many years. John is my right hand man, and is one of the main reasons that my job rocks. John’s knowledge of Java goes as deep as the inner workings of the VM and gets as lofty as architectural patterns for MVC’s in J2EE. John is intense, intelligent, and introspective. He also has just a few opinions.

Together, we plan to cover lots of ground in software security and software quality in this blog. We’re hoping for a dialog, so please tell us what you like, call us on the baloney, throw us the occasional bone, and generally enjoy yourself. We aim to have fun with this blog in an open interactive way.

My friends who run blogs—including my girlfriend from high school, all my buds at Fortify Software and my friend Jon Udell (who has been blogging basically forever)—all keep their entries short and personal. We’ll try to emulate them.

For the first few weeks, expect a new post every 2-3 days. First up is John Steven. Hey man, catch the potato…

[tags]software security[/tags]