afongen

The Minneapolis/Saint Paul OWASP chapter is organizing two events that I want to tell you about.

First, Jeremiah Grossman is speaking at the September 9 chapter meeting. This will be a reprise of his talk at Black Hat, “Get Rich or Die Trying”:

Forget Cross-Site Scripting. Forget SQL Injection. If you want to make some serious cash on the Web silently and surreptitiously, you don’t need them. You also don’t need noisy scanners, sophisticated proxies, 0-days, or ninja level reverse engineering skills — all you need is a Web browser, a clue on what to look for, and a few black hat tricks. Generating affiliate advertising revenue from the Website traffic of others, trade stock using corporation information passively gleaned, inhibit the online purchase of sought after items creating artificial scarcity, and so much more. Activities not technically illegal, only violating terms of service.

You may have heard these referred to as business logic flaws, but that name really doesn’t do them justice. It sounds so academic and benign in that context when the truth is anything but. These are not the same ol’ Web hacker attack techniques everyone is familiar with, but the one staring you in the face and missed because gaming a system and making money this way couldn’t be that simple. Plus IDS can’t detect them and Web application firewalls can’t black them. If fact, these types of attacks are so hard to detect (if anyone is actually trying) we aren’t even sure how widespread their use actually is. Time to pull back the cover and expose what’s possible.

Slides of the talk are posted on his blog. Grossman does good presentations. This promises to be excellent.

Second, on October 21, we’re planning a one-day conference at the Saint Paul campus of the University of Minnesota. Details are still being worked out, but speakers include Jeff Williams (CEO of Aspect Security and an OWASP founder), Brian Chess (Fortify Software), and Richard Stallman.

Yes, Richard Stallman. I didn’t expect that! Looking forward to it. (No, that link doesn’t explain who he is. It’s just damn funny.)

Registration for the October conference hasn’t opened yet, but from what I understand we’re going to be able to make it free of charge. Wow.

I’ll let you know when there’s more information.

Gunnar Peterson will be speaking at Monday’s OWASP meeting in Minneapolis.

SOA and Web services promise wonderful interoperability, but distributed systems create lots of room for fantastic failures. This session will explore the gory details of unique vulnerabilities at each layer of the SOA stack – from the WSDL interfaces to XML processing (XSD, XPath and XQuery), to the implementation languages liike Java and C#, to new security standards like WS-Security and SAML.

I’ve been looking forward to this. See you there?

Brian Chess, who gave the above talk with Gunnar at the 2008 RSA Conference, will be speaking in September.

And if you missed Gary McGraw interview Gunnar for the Silver Bullet Security Podcast, go have a listen. It’s a good conversation.

Based on a recommendation from Gunnar, I read The Starfish and the Spider by Ori Brafman and Rod Beckstrom. I spent all but the last couple chapters wishing that I were not reading it, but in the end it was worth it.

For most of the book, the core message is, “Look! Decentralized organizations that work!” Spiders die, starfish regenerate. Based on the reaction of the few intrigued people I talked to about the book, I’m sure this is a revelation to many, but since I’ve been interested in decentralized organizations since, oh, forever, this observation alone isn’t all that compelling. Certainly not enough to build an entire book around. They provide decent examples — the Apaches, Alcoholics Anonymous, Wikipedia (of course), Burning Man, P2P filesharing — but not a terribly nuanced examination of why decentralization works, or in what scenarios it can be successfully applied, or where it doesn’t work well.

Or so I thought. As I explained the book to my mother (one of the aforementioned intrigued people) I realized that they had provided an interesting analysis of factors that help decentralized organizations succeed in the face of increasingly centralized opposition. When facing a decentralized threat, whether it’s file sharing, terrorist cells, or botnets, one would do well to pay attention to the failures of centralized models. Becoming more centralized tends not to work.

I was surprised to find no mention of Dee Hock, Visa, and chaordic organizations, but that might stretch beyond the narrow confines of the authors’ intent.

In the final chapters, Brafman and Beckstrom at least begin to explore what I had hoped would be the meat of the book: merging decentralized organizational models with centralized ones. Or rather, using decentralized structures within a centralized organization. As with the rest of the book, there’s a rapid-fire series of examples, and a longer exploration of how this plays out in one company (GM). These are just a couple chapters in a short, easily read book, so I’m still a little disappointed by the depth of the analysis. But if you’ve got yourself a bus ride, you could do worse than to spend a little of that time in the last third of this book. If you are completely puzzed by the very idea of decentralized organizations, then you should definitely read it.

Now I’m working my way through the rest of Gunnar’s recommendations.

For the last few years, my employer has been working on a project for system-wide — dare I say “enterprise”? — identity and access management. As I have more than a casual interest in digital identity and identity management, I’ve been watching the project out of the corner of my eye. For the past year or so it’s been increasingly clear that progress is being made and they will release something valuable to the organization and ultimately to our students. One of the important activities this year is to hire staff to work on the project. They posted positions, and a few weeks ago I joined the team.

So what will I be doing? According to the position description, my first responsibility “is to be the senior IAM technical security engineer involved in the design, development, and implementation of MnSCU’s enterprise, multi-campus IAM system.” I will also have “primary responsibility for the daily support of MnSCU’s enterprise IAM system – including the development, QA, and production environments.”

Holy frell, what have I taken on?

If you look at an org chart — which does not show the exceptional people from other groups that participate in the project team — I’ll be the developer on a team consisting of an architect, a business analyst, and a developer. But on such a small team, being a developer means more than just writing code. I need a broad and deep grasp of everything we do, from requirements through to the hardware. It also means day-to-day support of our software and a rapidly growing user base.

It means I’m really damn busy.

After years of being underchallenged, I am at last facing a serious challenge, trying to make sense of all the work that’s been done — in the past year especially — while still trying to contribute in a meaningful way. I am being pushed, and to be honest, I feel a wee bit overwhelmed. Every now and then the scale of what we’re trying to do hits me, and the feeling that I am up to my eyeballs in work is replaced by the sense that I am so far underwater it’s not even funny.

I’m loving it. And I’m hoping that my coworkers won’t strangle me too soon.

It took me a few days to notice that Tim tagged me. I am supposed to “Pick up your nearest book and go to page 123. Find the fifth sentence, and post on your blog the next three sentences. Acknowledge who tagged you, and then tag five more people.”

There are two books equidistant from my chair — and as it turns out, the same would be true were I at home or work: the second edition of Ross Anderson’s classic Security Engineering, and Adam Shostack and Andrew Stewart’s The New School of Information Security. I’ll choose the latter because it isn’t so damn big and doesn’t hurt my arm so much to pick it up.

Most children who go missing do so in custody disputes and are taken by someone they know and trust. The advice to “never talk to strangers” doesn’t address the main cause of children going missing, and it puts them at risk when they become lost. In 2005, 11-year-old Brennan Hawkins got lost in the Utah mountains.

I don’t want to leave the next sentence off because it’s a good point: “For four days, he avoided searchers because he was afraid to talk to strangers.”

Shostack’s book announcement gives a good overview of the book, and Gary McGraw’s recent interview with him on the Silver Bullet Security Podcast should give you a better idea of where they’re coming from.

I’m not going tag five more people. Just cuz.

When last I wrote, I was busy working on a few talks. They went reasonably well.

MinneWebCon was a lot of fun, an engaging, upbeat conference. There were almost 250 attendees, about two-thirds of which were from the University of Minnesota, which put on the conference. Eric Meyer delivered a keynote in which he discussed craftsmanship in the web professional. How very relevant. Amy Kristin Sanders’s midday keynote offered useful insights about internet law that I cannot do justice to. In Mark Heiman’s enchantingly engaging talk about the search for a social networking tool for Carleton College alumni, I learned about Elgg, an open source social networking platform that looks pretty damn good. I’ll have to take a closer look.

The smartest bit of scheduling was to put unconference sessions immediately after lunch. Rather than nodding off on a full stomach, we got engaged in animated discussion, keeping energy high for the afternoon. Brilliant. The social networking session largely highlighted Twitter, which fit in well with the active back-channel Twitter chatter going on. Tony Thomas wrote a little about that.

My own presentation on JavaScript went almost as well as I hoped, although I ended up not being able to touch on Ajax except immediately afterward in a quick response to a question as I was unplugging from the projector. My emphasis was on taking functional pages and layering helpful behaviors onto them with unobtrusive JavaScript. Video will be available at some point, and I’ll be making my presentation notes available here (and there) soon.

And by the way: in case you didn’t know, jQuery is fantastic.

Many thanks to the MinnWebCon organizers for putting on a great conference and for allowing me to participate. I’m looking forward to next year.

Unfortunately, I was having so much fun preparing for my MinneWebCon talk that I gave short shrift to prepping for the two presentations I had scheduled at the MnSCU IT conference this past week. Thankfully I deliberately chose topics on which I could speak extemporaneously if need be. They turned out okay, but (as always) not as good as I had hoped. My first session explored the limits we’re bumping into with Ajax, especially user interface challenges, nontrivial client-server data communication problems, and the fallacies of distributed computing — setting the stage for the emergence of rich internet application technologies like Flex, AIR, and Silverlight. None of these technologies actually solve the problems, except making it easier to create better-looking UIs, but they should be watched closely. Hell, I’d use Flex in a heartbeat for certain things like, oh, an ERP.

I also spent a few minutes pointing toward all the activity going on around programming languages, concurrency, and flexible approaches to databases (non-relational, sharding, etc.), all related to rising expectations of what software should be able to do and how quickly we should be able to create said software. I talk about this stuff all the time, but hardly anyone seems to believe me. I hope that I at least planted a seed or two that will bear fruit in future discussion, and was heartened upon my return from the conference to see Tim Bray take it up:

Near as I can tell, we’re simultaneously at inflection points in programming languages and databases and network programming and processor architectures and Web development and IT business models and desktop environments. Did I miss anything? What’s bigger news is that we might be inflection-point mode pretty steadily for the next few years.

I don’t know whether I’ll put together notes. I suppose I ought to.

I was a little worried about the session on software security principles, since I had completely changed course on what I wanted to do the night before, but it turned out to go quite well. I wanted to start a discussion, examining common software development scenarios where I often find vulnerabilities, letting the group identify security principles that should guide development. WIth the help of a few security-minded individuals and a lot of people not afraid to put themselves out there even when they weren’t sure of themselves, we did just that. It was a good, active conversation. I was a concerned that one guy who brought up a quite valid point — that by moving our ERP from Win32 client-server to a web application, we’ve increased exposure and risk — was discouraged by the response. I talked with him today, though, and found that he wasn’t at all discouraged and that he had learned what I wanted people to learn:

• the threat is no longer amateur;
• software is rarely designed with security in mind, and that’s where the attacks are taking place;
• there are core principles that should help guide software design and development, such as not trusting input, using least privilege, and so on.

For people like him for whom this is all new, next time I will prepare handouts. If you’re looking for a preview or something to use now, I suggest you start with the excellent resources from the Microsoft patterns and practices group, including Guidance Share. It is not all Microsoft-specific, and there are some real treasures. For a quick run-down of security principles, see this blog entry by J.D. Meier, which lays them out nicely against Microsoft’s security frame.

To my mind, the highlight of the conference was Mike Janke‘s whirlwind tour of the MnSCU network and data centers. We really need to see more of that. Watching his presentation leaves no question of the scale and complexity of the problems of doing IT for an organization the size of ours, and the tremendous job that Mike and his team have done.

The real conference is of course not the sessions but the connections made with people there. Many good conversations were had, but I still didn’t connect with everyone I had hoped to. Folks, you know who you are. Let’s not wait until next year, okay?

Whew! My conference season is pretty much over, so excuse me while I go tackle that growing stack of books.

Earlier this year David Litchfield published a paper about what he calls lateral SQL injection (PDF), in which he demonstrates how to exploit PL/SQL procedures that don’t take user input. It’s a rather clever bit of work that shows that data types such as DATE and NUMBER, normally considered safe from injection, are in fact not.

But what caught my attention was his inspiration:

Whilst watching an episode of ‘Bones,’ something happened in it that made me think of not accepting something believed to be true, i.e., in this case that it’s not possible to SQL inject via DATE or NUMBER data types.

I love it.

I’m busy preparing for three talks that I’ll be giving in April.

The first will be at MinneWebCon, a web conference at the University of Minnesota.This is their first time putting on this conference, and even were I not speaking at it I would probably attend. The sessions on user experience, social networking, and online video look interesting, and I read today that there will be unconference sessions, too. My talk will be an introduction to JavaScript. The MinneWebCon organizers don’t expect the audience to be hardcore developers — a glance at the sessions makes that clear — so I’m keeping it basic but still trying to make it useful and get across important ideas. I always try to stress a few concepts whenever I talk about JavaScript:

• The importance of unobtrusive JavaScript — playing nicely with web standards and writing JavaScript that injects itself into a page to layer on behavior.
• JavaScript is not a toy language. It’s frequently dismissed as a cute little trinket, but its importance in web apps nowadays argues that although it has its warts, it has a certain quiet strength. I deal with a lot of Java developers who eschew JavaScript as “nothing like Java” but who then make the mistake of writing JavaScript code as if it were Java Lite. JavaScript is not a less powerful Java: it is best used on its own terms.
• Security. JavaScript is so ubiquitous and it is so easy to make security mistakes, I would be remiss not to discuss security. Especially since I’ll be bringing in a little Ajax.

We’ll be looking at JavaScript from the perspective of introducing basic enhancements to page behavior, illustrating those three concepts along the way. In an hour can’t get too deeply into JavaScript syntax, especially for non-programmers, but I will be showing how to leverage libraries, especially jQuery.

The next two sessions will be at the annual IT conference for Minnesota State Colleges and Universities. (There’s not a good link right now, sigh.) This is a gathering of IT staff from our colleges across the state, staff development, networking, and so on.

The first session is on software security principles. In the years that I’ve been working with developers on software security — coaching, training, giving talks at conferences like this — I’ve focused a lot on common flaws and vulnerabilities: how to test for them, how to prevent them through early design analysis and development techniques. It’s become clear, though, that there’s something fundamental missing. Understanding of vulnerabilities and their exploits is incomplete unless a developer also understands basic principles of software security. Until a developer — or architect, or project manager — has a foundation in the core principles that guide secure software development, they are likely to make the same sorts of mistakes that lead to security problems, even if specific vulnerabilities are planned for.

Basically, I don’t want to keep finding myself in arguments about whether or not it’s worth doing input validation. So I’ll cover principles like “input is evil,” least privilege, defense in depth, secure failure, that sort of thing. Since an hour of theoretical mumbo-jumbo isn’t likely to do anything except put people to sleep, I’ll be sure to explore how these principles play out in the software development process, and how common vulnerabilities such as the OWASP Top Ten can be addressed by keeping the principles in mind.

Yeah, I get a little ambitious.

My second session at the MnSCU IT conference is called “Beyond Ajax.” When I first conceived of the talk, it was more along the lines of “Why Your Software Sucks.” (I had an angry few months, what can I say?) It then morphed into an exploration of rich internet application technologies starting to rise to the fore: Flex, AIR, Silverlight, even JavaFX. Then, thinking about the two sessions that I’ve outlined above, I realized that I didn’t have enough time to learn Flex and Silverlight well enough to do a kick-ass presentation. Besides, for an audience that for the most part is maybe just now getting into Ajax development, I need to develop more background of what’s driving the adoption of non-Ajax RIAs.

So instead, the talk will be about why creating a well-designed Ajax app has proven difficult or unsatisfying:

• We’re still stuck with the limitations of browser user interfaces.
• Writing cross-browser code is still hard.
• Creating compelling cross-browser UIs is even harder.
• Many developers don’t understand JavaScript like they should.
• Security has grown more complex.
• Ajax accessibility is still largely unknown and misunderstood.
• Although the client-side part of an app can now do more (and be more complex!), without a lot of work application workflows have not changed much and are still hampered by HTTP.
• Architecture of data flow between client and server is a significant challenge, often falling victim to the fallacies of distributed computing and resulting in a degraded user experience.
• There is a strong inclination to use Ajax to create non-browserlike experiences, often to the detriment of the user.

I don’t know yet whether I’ll bring mobile devices into the picture.

Into this setting come Flex, AIR, Silverlight, and so on. I can’t get too deeply into them, much as I’d like to. Still, the focus of the talk is on rich internet apps — mostly why, not so much how. Look for that next year. :)

I also hope to spend a few minutes (lightning talk style?) discussing parallel industry trends that will have impact on in RIA development in the near future: cloud computing, approaches to concurrency, non-relational data stores, and a panoply of new languages and platforms to address these concerns. This is all stuff that’s been rolling around in my head for the last year or two, and I’m tempted by a bit of self-indulgent examination of how it’s all connected.

Like I said: I get a little ambitious. That last bit is likely to get cut as not contributing to the core message.

So if you don’t hear from me for the next month or so, know that I am busy. But I am having fun.

Mike Janke has blog. About damn time.

When I fled the dark days of human resources (don’t ask) and joined IT, one of the best things about my new job was that I got to work for Mike. (No, I no longer do.) I can’t tell you how many times I’ve heard someone ask, “what the hell is he doing working for the State?” He not only knows his shit, he thinks deeply about it.

He has written some of my favorite email ever.

Yesterday was a rather disappointing day.

It appears as though a large number of highly paid, competent ITS professionals succumbed to the ID10t factor, and clicked on an instant messenger worm. The IT staff who got the message with the worm were asked by their desktop if they wished to run the virus. Most of them said yes & ran the executable code.

It gets better than that, but I really shouldn’t share the good bits.

He’s also responsible for something that still makes me laugh whenever I think of it.

During a bit of a crisis last fall, a few of our network and server admins were gathered around the phone on a support call with Microsoft.

“Sorry if we don’t do this right,” I heard one of them say. “We’ve been a Novell shop for 20 years and have never had to call tech support. We don’t know how.”

His inaugural post, Tethered, is one reason I’ve been hoping he would start a blog. Without calling out the Sun slogan by name, he explores how the network is the computer and where the iPhone and the Zonbu fit in. Zonbu, you ask? So did I. It’s pretty damn cool. If you go read the post, I promise I’ll get off my ass and finally write a response.

Later posts will appeal to the systems management dorks among you. (<cough>Coté</cough>).

I mentioned to Kiara that Mike’s blogging. She’s met him maybe once or twice. Her response? “About damn time.” Yeah.