The BSIMM project describes and measures the work of 786 SSG members, who together with a satellite of 1750 people, have direct impact on the work of 185,316 developers. (Download a copy today and get your firm involved in the BSIMM Project.)

The BSIMM is mostly about SSDL activities and governance. However, third-party software plays a major role in all of the BSIMM firms and is an important risk factor that must be managed. In addition to talks from member firms, the BSIMM Community Conference also featured a workshop on third-party software and security.

Sammy, Brian, and I wrote up the results in an informIT article that was posted today.

The interesting aspect of our workshop was that it was made up approximately of 50% software vendors and 50% financial services firms. This made for a very interesting conversation around vendor control.

My philosophy of software security and security in general has plenty of room for the art of the exploit. The icon that I have adopted to “brand” my work, the yin/yang with cowboy hats includes a black hat for a reason! Here’s what I said about the icon in the Preface of Software Security:

Fundamental material is covered under this icon (which also adorns the cover of the book). The Yin/Yang is the classic Eastern symbol describing the inextricable mixing of standard Western Polemics (black/white, good/evil, Heaven/Hell, create/destroy, et cetera). Eastern philosophies are described as holistic because they teach that reality combines polemics in such a way that one pole cannot be sundered from the other. In the case of software security, two distinct threads—black hat activities and white hat activities (offense/defense, construction/destruction)—intertwine to make up software security. A holistic approach, combining yin and yang (mixing black hat and white hat approaches) is what is required.

The White Hat + Black Hat approach informs three of my books and the entire Addison-Wesley Software Security Series:

Building Secure Software (BSS), the white hat book, seems to have touched off a revolution. Security people who once relied solely on firewalls, intrusion detection, and anti-virus mechanisms came to understand and embrace the necessity of better software. BSS provides a coherent and sensible philosophical foundation for the blossoming field of software security.

Exploiting Software (ES), the black hat book, provides a much needed balance, teaching about how to break software and how malicious hackers write exploits. ES is meant as a reality check for software security, ensuring that the good guys address real attacks and invent and peddle solutions that actually work. The two books are in some sense mirror images.

Software Security unifies the two sides of software security—attack and defense, exploiting and designing, breaking and building—into a coherent whole. Like the yin and the yang, software security requires a careful balance.

It may come as a surprise to you that I have never attended the famed Blackhat conference until this year. There are a couple of reasons for this, not the least of which my two time co-author Greg Hoglund has “covered” Blackhat most admirably for a decade. More generally, I guess my bias is definitely toward building systems properly and security engineering than it is towards penetration testing and throwing rocks at existing systems.

Blackhat and its sister con Defcon have always had reputations as “hackerboy” conferences populated by l33t “researchers” bent on breaking systems in spectacular fashion. I suppose Blackhat has over the years evolved into something more commercial, with a major shift in emphasis coming when it was purchased by UBM. Many of my associates in security have said that Blackhat attendance has shifted toward the corporate end of the spectrum and that it was looking more like the RSA Conference attendance-wise. As a consultant to large corporations taking software security seriously, this perceived shift is not to be ignored. That’s why I went to see for myself what’s up with Blackhat.

(I suppose I should throw in a quick aside here to point out that in my view being sentenced to spend time in Las Vegas is second only to the pain of spending time in Orlando. Just not my bag and a definite personal bias.)

Bottom line? Blackhat appears to be populated by plenty of security vendors mostly presenting to each other. I found a handful of Cigital customers at the show, but far more security practitioners who work for vendors than any other category of attendee. That probably makes Blackhat a reasonable show to attend if you’re interested in hiring pen testers and understanding something about the latest flavors of attacks. There were certainly some very superb people presenting at the show (Litchfield, Laurie, and Russinovich pop immediately to mind), but Blackhat seems to be more about after hours parties than security content—especially when it comes to engineering. That leaves me feeling conflicted about its value.

At this point in the life of software security as a field, I think we need to spend less time thinking about breaking systems and finding vulnerabilities than about fixing systems and mitigating vulnerabilities. (Not none, mind you, just less.) There were a couple of presentations and panels on the agenda that touched on software security basics, but a vast majority of the content is about (gleefully) breaking things. Incidentally, that’s why it was interesting to me that Microsoft announced its new security engineering Bluehat prize at the show. Seems like they might get better traction with that at Usenix Security, ISOC NDSS, or even RSA?!

There is certainly networking to be done at Blackhat, but nowhere near at the same scale or caliber as the networking at RSA (the security tradeshow that absolutely everybody attends). If you’re not up for late nights, loud dance music, bad well drinks, and club-based Vegas mayhem, Blackhat may not be your scene. Maybe I’m just getting old.

Before the panel, we came up with a number of questions to help drive conversation and discussion. Since this is a blog, I will reproduce the original questions with my somewhat quirky short form answers in full below. Note that Cigital Principal Consultant Scott Matsumoto who heads up Cloud Security at Cigital was instrumental in helping to formulate these thoughts. You want some cloud security? We got some.

For more on the panel and on cloud security see a complete video of the panel and read my informIT article Partly Cloudy with a Chance of Security

The title of this panel is whether we can ever trust the cloud. Starting with a big general question: in a nutshell, -what- can we reasonably trust the cloud to do, or not to do?

The question of trusting the cloud should be the same as asking the question “can I trust distributed architectures (as opposed to a mainframe architecture)”. Put this way, it’s a silly question. A better question might be “what is the cost of creating a secure computing environment for <insert cloud platform name here>?”

There are two components to worry about:

1. One of the main drivers for Cloud is cost. Creating a secure computing environment requires some level of cost to compensate for security that may well be different from one’s current computing environment.

2. The answer to the cost question can only be answered WRT a specific platform since the nature (pros and cons) of the platform-provided secure controls and the weaknesses (not necessarily vulnerabilities) both vary across the plethora of platforms lumped under “Cloud.”

Remembering the answer to the last question, how does that compare with how we can reasonably trust traditional shrink wrapped software?

Wrong analogy. This probably should be (as stated above) can you trust distributed architectures over mainframe architectures?

A security perimeter is a well-known idea from computer and network security; it’s a boundary with an inside and an outside and a regulated access point; e.g., you can’t access the systems inside my security perimeter unless you are allowed by my firewall rules. From a customer’s view, how can we have meaningful security perimeters in a cloud?

Could you ever really trust the perimeter? Trusting the perimeter was an urban myth. Will that help this discussion go somewhere useful?

To the extent that a cloud is an aggregation of many very similar systems under one administrative authority, there seems to be an opportunity for an expert security team to use automated techniques to implement more consistent security practices than are likely outside a cloud. Do you buy that? Is it possible that cloud security policies may be better?

This is a good question.

The analogy to COTS software may well apply to this question. While the Cloud provider may get a boost from a critical mass of humans working on a common set of problems; it means that the solution must be generalized to apply to the broadest number of use-cases. With COTS software you get a more cost-effective solution IFF the solution designed by the COTS solves your problem. You also get a lot of other people’s baggage.

Prediction:
Cloud-Bloatware.

From the 1970s we have the concept of the reference monitor. It is a protective layer that regulates access to resources, like data stored in a cloud. As traditionally formulated in the seminal Anderson report, a reference monitor can be trustworthy because it is: 1) protected from tampering, 2) non-bypassable, and 3) simple. Can there be reference monitors in the cloud? Or is this just an outdated concept?

This is also a useful question.

From the NIST cloud definition, in a public cloud, “the cloud infrastructure is made available to the general public or a large industry group and is owned by an organization selling cloud services.” For a private cloud, “the cloud infrastructure is operated solely for an organization. It may be managed by the organization or a third party and may exist on premise or off premise.” So a private cloud -could- be behind a protective firewall. In your view how do public and private clouds compare security wise?

Private VS Public should probably be evaluated through Single-tenant VS Multi-tenant.

As software people, we know that complexity is the enemy of security, and that, traditionally, for every thousand lines of good code we should expect multiple flaws. For similar features delivered to customers, are clouds more complex, less complex, about the same?

It’s the type of code that’s the issue (as opposed to LOCs). What the Web should have taught us is that we don’t want application programmers writing security controls like authentication/authorization, session mgmt., etc. We’ve become ever so slightly more secure as these controls have been sunk back into the application infrastructure (app-servers, middleware, etc) and pulled out of the apps.

Cloud means that some of security controls required to compensate for platform weaknesses are pushed into the application. That is a problem.

What is even more worrisome is that for SaaS, the controls push through the application layer and into the legal agreements. Lawyers… draw your own conclusions.

Generally, cloud-based applications depend on reliable and secure networking. Anecdotally, I seem to experience more network glitches than local freeze-ups, and networks need working DNS, routers, etc. A few thousand smartphones suddenly turned on in a conference center is also an issue. Can the network really be as reliable as the local client?

Meh.

Search engines sometimes seem to know us better than we know ourselves. They aggregate data from our searches. With a scale of aggregation in the data center that is perhaps unique to cloud computing, malicious insiders in the data center might pose a unique and sobering threat to privacy. How concerned should we be?

Also meh. Expect everybody to watch everything. Act accordingly.

The Cloud Security Alliance lists account hijack as one of the top 7 threats for the cloud. For most people, the browser is the access point to the cloud, but browsers seem always to be getting smacked down at contests. E.g., see http://cansecwest.com/, with a macbook already owned this week and more likely on the way. Can we be confident that our cloud accounts are safe?

Weakest link, yadda yadda.

Multi-tenancy is a high-profile feature of clouds. It seems similar to process separation in operating systems, which has a checkered history security wise. What should give us confidence that cloud-implemented multi-tenancy will keep customer workloads really separated.

goto QUESTION 6

Considering the data replication practiced by some cloud providers and the inherent difficulty of erasing data authoritatively even when the local storage device is in hand, can we have real data delete in the cloud? Do you think it matters much?

Deletion is the most important part of backup.

What is your number 1 most important security challenge or opportunity in the cloud?

Software security uber alles.

In order to combat the FUD angle all too often used to peddle computer security solutions (especially by defense contractors), we have done what we can to address the field in a manner that emphasizes building security in. One of my first attempts to counter some of the persistent Cyber war drumbeat we hear was an informIT article co-authored by Core CTO and founder Ivan Arce: Cyber Warmongering and Influence Peddling (November 24, 2010). When I ran that article up the policy flagpole in DC, the reaction was decidedly mixed. Maybe a bit too technical and a bit too raw was the verdict.

So, a complete rewrite of the core concepts with the help of Center for a New American Security CEO Nathaniel Fick was in order. I’m happy to say that the result looks good and has been included in the recent CNAS report on Cyber Security called “AMERICA’S CYBER FUTURE: SECURITY AND PROSPERITY IN THE INFORMATION AGE VOLUMES I AND II” (sorry for yelling, that’s how the policy people do it). In volume II as chapter 3, you will find the paper I wrote with Nate. The new title? “Separating the Threat from the Hype: What Washington Needs to Know About Cyber Security” You can download the complete report from the CNAS website here (volume II here).

In other policy-related writing, my current informIT article Computer Security and International Norms (May 30, 2011) discusses the recently-released White House “International Strategy for Cyberspace.”

I would love to see us turn the sound and the fury from cyber war to cyber crime where it belongs. What do you think?

Dr. Markus Schumacher has served as CEO and Co-Founder of Virtual Forge GmbH since 2006. The company specializes in the security of SAP applications. Dr. Schumacher was previously a representative of the Fraunhofer Institute for Secure Information Technology (SIT) and worked at SAP as a Security Product Manager (NetWeaver). Focus topics were secure development, security testing, security response, product certification (Common Criteria) as well as awareness events for the development crew. Before SAP, Dr. Schumacher, was a member of the scientific staff at the IT Transfer Office (ITO), Department of Computer Science, Darmstadt University of Technology, where he managed projects for customers such as T-Systems Nova, Siemens AG, SAP Corporate Research, and Fujitsu Laboratories. Dr. Schumacher earned his doctorate in computer science field. He has published numerous articles and books (most recently: Secure ABAP Programming at SAP Press) and speaks regularly at international conferences.

Markus met with Gary during his latest stay in Germany. After talking about software security in certain nice places in Heidelberg, the idea came up to capture some insights about software security testing in an interview. Here’s the interview as recorded on Wednesday, April 6, 2011.

Markus: Gary, we talk about software security today, in particular about finding bugs by thorough security testing. How should tests be conducted? Manually or with a tool? And which approach is better?

Gary: This is a little bit like comparing apples and oranges because both approaches can be very useful. But generally speaking, if you can automate a paticular test that means that you’ll be able to apply that test consistently in the future—maybe even across your entire code base. So I’m a big fan of automating as much of testing as you can automate.

Security testing is good, but if people treat it as a ‘security meter’ that can lead to real problems. That is, confused people sometimes think that if they run automated tests and don’t find any problems that the software is free of bugs. But we both know that a result like this just means that you haven’t found anything interesting during a given test. You have to be very careful when you apply automated testing that you know what you are doing and that in the end you know what the results are.

Does that make sense to you?

Markus: That makes perfect sense. You have observed the software security tools market for many years. We see black box scanning tools and code scanning tools out there today; what are the trends that you have observed?

Gary: When it comes to software security, there are basically two kinds of automation. One kind does black box testing and requires that your software be run. We call that dynamic testing. The idea is to test your program automatically while it’s running by providing input and see if you can maliciously break it. There are such tools aimed at Web applications, IBM AppScan for example. The second type of tool is a code scanning tool that does a static analysis. A code scanning tool looks at your code instead of running your program. That is, it looks for bugs that are observable in the code itself.

Both of the two types of tools are the biggest sellers in the software security space today. What happened over the last few years is that the code scanning tools became a lot better and they’ve begun to find widespread use. In fact they accelerated past the black box testing tools in terms of adoption a year or two ago. The reason for that is that black box tools only work for Web applications (they work only over http) while the source code tools work for any kind of software. As you know, there are even specialty white box tools that look over particular languages—like the languages that are built into highly popular systems like SAP.

The ABAP tool that you guys have built is a way of looking at your ABAP code to find bugs and produce security results. In my view it’s really better to focus as early in the lifecycle as you can to find bugs and any static analysis tool can really help to do that. Bottom line: here are many advantages using such static tools over and above dynamic tools.

Markus: Because you build security in from day one.

Gary: That’s part of the idea. Of course you have to think about your design as well. But we haven’t figured out how to automate looking for design flaws yet!

Markus: Don’t write software – then you are good.

Gary: <laughs> Sadly, that’s true.

Markus: Code analysis tools are obviously a good choice. But what are their limitations?

Gary: There are a couple of things that are problematic. One is that people think that the tool will find all possible bugs and then fix the bugs for you. That can be an issue. The thing about these tools is mostly they help you finding possible vulnerabilities and then you have to be smart about determining whether what has been found is a real problem or not. But even more important than that, thinking about how to fix vulnerabilities is a serious problem. If current tools have a limitation it’s that they don’t fix the code, and certainly not automatically! So they are great at finding bugs but it’s up to you to fix them. If you just use these tools to find bugs, pile them up somewhere, and not fix them that doesn’t help security at all.

The other problem with these tools is that because they are doing static analysis they do have the tendency to sometimes find false positives—things that the tool thinks are a problem but it turns out when you think about data flow more carefully (or whatever) they are not a problem. Plenty of people worry about the false positives problem, but I have seen the number of false positives that static tools produce over the last 5 or 7 years drop dramatically. It’s in an acceptable range now I believe.

Markus: I have talked to different clients about false positives. One of them said, ‘tools find issues – some might be false positives, others not – we review them and fix the bugs.’ Others say, ‘for many reasons – I can’t have any false positives even if the tool is sometimes finding real bugs.’ For them it’s better to not see a real bug in favor of a low false positive rate. What would you say to the latter?

Gary: “I’m with the first guys. It’s much better to have a few false positives and find all of your security problems than it is to have no false positives and miss real security problems. This is because security problems are serious and they need to get fixed!

The notion of a code scanning tool sprang from a whole bunch of experience with manual code reviews—digging through code by hand and looking for security bugs. We were doing a lot of that in 1998 and 1999 and we began to figure out a ways to automate parts of that. We created the first code scanning tool for security called ITS4. Things have come a very long way since then, but remember that ITS4 was just using grep-like technology looking for very simple patterns and sometimes you can get simple patterns completely wrong.

Things have improved a huge amount since those days. I think when people talk about false positives in some sense they are using thinking that is about 10 years old (from the ITS4 days). Today the false positive rate has dropped enough that using these tools is something you really just have to do.

Markus: Our strategy of lowering the false positive rate is to apply data-flow analysis consistently, doing many sanity checks like type checking, looking for authority checks, etc. That way we classify the findings – there are certain findings where we are pretty sure will always find real bugs while others are probably not as certain and get a lower rating …

Gary: I think that’s a very good idea.

Markus: … Is this approach a good strategy? That is, starting with the findings that have a very high rating first?

Gary: Yes.

Everyone has a limited amount of time to fix their code. The most important thing is not finding the bugs, but fixing them as I have told you before. If you have a way of helping people prioritize the fixing so that they are fixing stuff that really needs to be fixed, that’s fantastic!

What we see in the field is a lot of people find a lot of bugs but not enough people do enough to fix the bugs. There’s not enough remediation going on. Let’s be clear: it does no good to find bugs if you are not going to fix them. And so I think a focus on telling people ‘this is a bug for sure, and you should fix this one because you won’t waste any of your valuable time’ is a very, very clever strategy.

Markus: We know people who say that such ‘very high’ findings are very likely true positives and consider all others with a lower rating as a false positive because they need to invest too much time on finding out whether they are bugs or not. Accordingly they claim that the false positive rate is too high and a tool might be useless because it doesn’t deliver 100% hits only. Why is it not a good idea to shoot at this false positive thing only?

Gary: If these people are fixing all of the bugs that you are telling them are bugs for sure and have extra time left over, then they can worry about that problem! <laughs> But so far I haven’t seen anybody who has the luxury of that much time. That means their whole point is sort of a moot point. The answer should be: fix the ones that you know are a problem, and when you are done with that we’ll talk.

Markus: Good answer, next question.

Many people get frustrated when they start security testing because of the high amount of findings as result of initial scans. How should people approach this?

Gary: The best way to do this is to turn the things that you are looking for on and off inside the tool. When you try to get people to adopt a tool for the first time, it’s better to have the tool looking for certain categories of bugs (I recommend this be as few as possible). The idea is to make sure that the tool doesn’t just overwhelm the user with a big ‘red screen of death.’

There are a couple of clever ways of doing this. We help many companies adopting such tools wisely throughout their whole development team. One very good trick is to tie the tools to code that the users want to use already. So you have a middleware framework and you want people to use that, then you build some enforcement rules to talk about the use of that particular code, and you focus on that instead of focusing on looking for all bugs at all time throughout the entire code base.

Another way of putting this notion is: tighten the focus of the tool so that it isn’t overwhelming at first, and then loosen that focus up, add more rules, add more kinds of bugs you are looking for over time. Start small. As the code base improves and people get better in using the tool, do more.

Markus: We have a customer following a similar strategy. They did an initial scan with all checks turned on. Then they identified all checks that lead to no findings and made those tests mandatory. Meaning: they are good in this area and they won’t get worse. And then they tightened the focus as you have described it. Like it?

Gary: That’s a good idea, because it’s sort of belts and suspenders approach (so to speak). The idea of working for certain categories of bugs should also be complemented by understanding your code base. If you run a bunch of static analyses, you should amass enough data to determine what your number one bug is. Note that your number one bug may different than somebody else’s number one bug! Then you can set out on a bug eradication mission based on real data from a tool run over your code base, and that’s a very helpful thing.

Remember, if you are finding bugs in your code that means somebody is typing in those bugs— somebody actually wrote that bug. The best thing is to get to that person and teach them not to do it that way. The closer you can get this to the developer’s head (and fingers) the better off you’ll be in my experience.

Markus: But that could be the reason for the resistance. Somebody blames the bug writer for their bad code, their (broken) piece of work. And probably companies do not have a well-developed way of dealing with accidental mistakes.

Gary: That’s right. One problem in security that we have is that developers like their code and treat it like it’s their baby. Then you come along and say, ‘That’s the ugliest baby I’ve ever seen!’ And that makes the developers angry. You really shouldn’t call somebody’s baby ugly, but in security we run around doing that all the time.

We have to understand that people are very sensitive about their code, and we have to be gentle about security problems and teach them that it’s in everybody’s best interest to find and fix these things. The good news is that most developers actually really want to build good stuff. If you say, ‘This is for helping you build better stuff. It’s not something to smack you around and make you look like an idiot, in fact it makes you build better code,’ that fits into the development culture way better.

Markus: Stay away from the ugly-baby guys and support the better developer. I like that.

Another thought on false positives. Sometimes people say that a certain finding is a false positive because there’s no data path to the vulnerability or the code touches non-critical data only. Think of a SQL injection in code that handles temporary data only. A tool cannot make a good decision here. What’s you view on this?

Gary: The answer is a bit convoluted. Because of code reuse and because people will repurpose code in surprising ways, it’s always better to fix those problems. Even if you think that in a particular situation a particular vulnerability might not lead to a security issue. Because odds are high that someone will just cut-and-paste it and use it somewhere else. And then it will be a real problem.

Markus: Cut-and-paste is one thing, another is code that is part of an API, function, or report, that might be used by someone else in a different context.

Gary: Absolutely right. That happens an awful lot.

It’s the same as putting a watchdog in code. I have seen people put a watchdog way at the beginning of code looking for certain kinds of input because there’s a vulnerability way down low in the code and they say, ‘if we strip the input so it never gets down there everything will be fine.’ But then later somebody comes along and creates a new execution path to the same vulnerability with the watchdog so far up there that the flow is no longer controlled by the watchdog anymore. Then you’re screwed. That’s sort of the same idea. Bottom line: if you have a bug in your code, you should fix it.

Markus: Period – nothing to add here, just fix it.

Final question. You’re currently work on BSIMM3. What can we expect in the new version?

Gary: We have continued to grow the size of the BSIMM study. We now have now 33 firms in the study and we have done 60 measurements.

What happened last year was kind of surprising. Many of the firms that were already participating in the BSIMM asked us to measure their major divisions. For example we did six measurements inside of Bank of America. If you know that the Bank of America includes Merrill Lynch, Countrywide, and a bunch of other large financial organizations, that’s not such a big surprise. That meant we spent an awful lot of time doing BSIMM analysis inside firms that were already in the BSIMM.

So we have grown the dataset considerably—doubled it, in fact, since BSIMM2.

The other thing that we have started doing is re-measuring firms that we have already measured in the past. We have measured 10 firms already again. So now we have data that show what happens to a software security initiative over time, and we can talk about what changed between the first and the second measurements. That’s incredibly cool, very powerful data.

Our plan for BSIMM3 is to try to get up to 40 firms and then release the longitudinal data (that is, the data over time) and the new data set with 40 firms all at the same time. I’m hoping to do that in the early summer.

Markus: Is there hope? Are things getting better?

Gary: Things are getting better. 15 years ago nobody really cared about software security. When Viega and I wrote Building Secure Software everybody thought we were crazy. A lot has changed since then. Now, developers are beginning to understand that what they do does have a clear impact on security. And a lot of firms are realizing that their customers are expecting the code to be secure. Customers may not really be explicitly saying ‘this has to be secure’ but they do (implicitly) believe that it already is secure! So it’s really important that firms meet the implicit security expectations of their customers. A lot of firms are realizing that.

As a field we have made a huge amount of progress. The other thing that happened in the past 10 years is the rise of static analysis tools that actually work and can be adopted in large enterprises. And finally the BSIMM project is a relatively new venture—we have only been doing the study for a couple of years. The BSIMM is a scientific approach that relies on effective measurement of a firm and its peer group. That way you can compare and track what different many diverse firms are doing. That’s a very, very powerful thing. So we built a community of like-minded firms who are all working very hard and building up software security and are making great progress. We figured out a way to measure that progress and show it in no-uncertain terms. That’s pretty cool.

Markus: Agreed. And we continue supporting BSIMM by translating it to German.

Next time we will talk about our joint invention, the NoMoRed (No More Red traffic lights) tool that deletes all bugs by just clicking a button. <laughs> I’m looking forward to that. Thank you for your time today.

Transcribed in Heidelberg on April 6, 2011.

Cast (in order of appearance)

• Markus Schumacher, CEO of Virtual Forge GmbH
• Gary McGraw, CTO of Cigital, Inc.
• One Web application scanner: IBM AppScan
• The ABAP tool that you guys have built
• The first code scanning tool for security: its4 (it’s the software stupid)
• The BSIMM
• Building Secure Software, Addison-Wesley Professional, 2001

This time, the article was sparked by a very interesting trend report from Dasient about the malware problem. The Dasient guys are approaching the problem from the server end. Founder Neil Daswani was on the Google software security team for a while and is now going after the problem more aggressively.

Dasient produced a video introducing the problem of serving seemingly simple web pages that comes about when advertising is present.

(via)

I wrote about Stuxnet at the time and since then much analysis has been published. But most of the coverage continues to be weak on the payload part of Stuxnet (in my view spending too much effort fretting about the more mundane delivery mechanism).

Ralph has spent more time and effort than anyone analyzing the Stuxnet payload and we get into some detail regarding its technical workings during the podcast. Have a listen: http://www.cigital.com/silverbullet/show-059/

If you ever wondered what a cyber war weapon might look like, Stuxnet is it. It is obvious that Stuxnet was specifically constructed as a targeted attack against the Natanz nuclear centrifuges in Iran.

Sadly, Cyber War is here to stay.

Yesterday at RSA, Invincea was named the most innovative startup as part of the competition in the RSA Innovation Sandbox. Here is a BusinessWire release with some facts.

I did a software security whiteboarding session for a standing room only crowd of over 300. This was my first sandbox showing, and I must say that Innovation Sandbox is a dynamic, energetic and entertaining part of RSA. I will be participating again for sure.

This video, produced by Invincea (whose software Cigital helped to secure), gently introduces some of my views on the malicious code problem.

Howard started his career as a policeman, and his approach to cyber security is informed by that experience. Don’t get me wrong, I think that’s an OK thing. I would much rather see a law enforcement angle focused on cybercrime than a warrior angle focused on the chimera of cyberwar. Of course, given my druthers, I would choose an architect (especially a software architect) over a law enforcement person to be in charge of cyber security. One of these years…

Howard’s talk was fine. Nothing earth shattering and no major revelations unless you’re a government employee about to be bound by HSPD 12. Howard emphasizes deterrence (especially using economics and harsh punishments to deter cyber crime), accountability (focused mostly on criminality and sentencing), resilience (where his story needs some more work and could do with a good dose of technology), and privacy. I would like to see more emphasis on building security in in the first place, but the government still has some basic blocking and tackling to do.

I wish I had a nickel for every time the political types say “public private partnership.” That dog failed to hunt long ago. Time for a new dog. Even making a joke out of it invokes groans. No more political pandering with public private partnerships please.

I still believe that the government is WAY behind when it comes to cyber security. I also think that the Obama administration has made important progress since the days of the at-first-classified CNCI. They may have caught up to 1996! Only 14 years to go.

Take home message from me: not one mention of cyber war the entire time, only a little about cyber espionage and IP, and plenty of focus on cyber crime. At least our executive branch is sane!

Thanks for dragging me out of the sticks, Tom.