Category Archives: Applications

Security Testing Is Dead. Rest In Peace? Not!

Posted on by

Apparently, some Google presenters are claiming that we can do away with the testing cycles in our software development life cycles? There’s been plenty of reaction to Alberto Savoia’s Keynote in 2011. But I ran into this again this Spring (2013)! So, I’m sorry to bring this up again, but I want to try for a security-focused statement…

The initial security posture of a piece of software is dependent upon the security requirements for that particular piece of software or system. In fact, the organizational business model influences an organization’s security requirements, which in turn influence the kinds of testing that any particular software or system will need before and after release. We don’t sell and deliver software in a vacuum.

Google certainly present a compelling case for user-led bug hunting. Their bounty programme works! But there are important reasons that Google can pull off user-led testing for some of their applications when other businesses might die trying.

It’s important to understand Google’s business model and infrastructure in order to understand a business driven bounty programme.

  • Google’s secured application infrastructure
  • Build it and they might come
  • If they come, how to make money?
  • If Google can’t monetize, can they build user base?

First and foremost, Google’s web application execution environment has got to have a tremendous amount of security built into it. Any application deployed to that infrastructure inherits many security controls. (I’ll exclude Android and mobility, since these are radically different) Google applications don’t have to implement identity systems, authorization models, user profiles, document storage protection, and the panoply of administrative and network security systems that any commercial, industrial strength cloud must deploy and run successfully. Indeed, I’m willing to guess that each application Google deploys runs within a certain amount of sandboxed isolation such that failure of that application cannot impact the security and performance of the other applications running on the infrastructure. In past lives, this is precisely how we built large application farms: sandbox and isolation. When a vulnerable application gets exploited, other applications sharing the infrastructure cannot be touched.We also made escape from the sandbox quite  difficult in order to protect the underlying infrastructure. Google would be not only remiss, but clueless to allow buggy applications to run in any less isolating environment. And, I’ve met lots of very smart Google folk! Scary smart.

Further, from what I’ve been told, Google has long since implemented significant protections for our Google Docs. Any application that needs to store documents inherits this document storage security. (I’ve been told that Google employ some derivation of Shamir’s Threshold Scheme such that unless an attacker can obtain M of N  stored versions of a document, the attacker gains no data whatsoever. This also thwarts the privileged insider attack)

My simple point is that Google is NOT entirely relying upon its external testers, its bug bounty programme. A fair amount of security is inherent and inherited by Google’s web application experiments.

And, we must understand Google’s business model. As near as I can tell from the outside, Google throws a lot of application “spaghetti” onto the Web. If an application “sticks”, that is, attracts a user base, then Google figure out how to monetize the application. If the application can’t be monetized, Google may still support the application for marketing (popularity, brand enhancement) purposes. Applications that don’t generate interest are summarily terminated.

In my opinion, Google’s business model leaves a lot of wiggle room for buggy software. Many of these experiments have low expectations, perhaps no expectation at the outset? This gives Google time to clean the code as the application builds user base and penetration. If nobody is dependent upon an application, then there’s not a very high security posture requirement. In other words, Google can take time to find the “right product”. This is entirely opposite for security function that must deliver protection independent of any support (like on an end point that can be offline). Users expect security software to be correct on installation: the product has to be built “right”, right from the start.

And, the guts of Google are most likely protected from any nasty vulnerabilities. So, user testing makes a lot of business sense and does not pose a brand risk.

Compare this with an endpoint security product from an established and trusted brand. Not only must the software actually protect the customer’s endpoint, it’s got to work when the endpoint is not connected to anything, much less the Internet (i.e., can’t “phone home”). Additionally, security software must meet a very high standard for not degrading the posture of the target system. That is, the software shouldn’t install vulnerabilities that can be abused alongside the software’s intended functionality. Security software must meet a very high standard of security quality. That’s the nature of the business model.

I would argue that security software vendors don’t have a great deal of wiggle room for user-discovery of vulnerabilities. Neither do medical records software, nor financials. These applications must try to be as clean as possible from the get go. Imagine if your online banking site left its vulnerability discovery to the user community. I think it’s not too much of a leap to imagine the loss in customer confidence that this approach might entail?

I’ll state the obvious: different businesses demand different security postures and have different periods of grace for security bugs. Any statement that makes a claim across these differences is likely spurious.

Google, in light of these obvious differences, may I ask your pundits to speak for your own business, rather than assuming that you may speak for all business models, rather than trumpeting a “new world order”? Everyone, may I encourage us to pay attention to the assumptions inherent in claims? Not all software is created equally, and that’s a “Good Thing” ™.

By the way, Brook Schoenfield is an active Google+ user. I don’t intend to slam Google’s products in any manner. Thank you, Google, for the great software that I use every day.

cheers

/brook

 

 

 

Agile & Security, Enemies For Life?

Posted on by

Are Agile software development and security permanent enemies?

I think not. In fact, I have participated with SCRUM development where building security into the results was more effective than classic waterfall. I’m an Secure Agile believer!

Dwayne Melancon, CTO of Tripwire, opined for BrightTALK on successful Agile for security.

Dwayne, I wish it was that simple! “Engage security early”. How often have I said that? “Prioritize vulnerabilities based on business impact”. Didn’t I say that at RSA? I hope I did?

Yes, these are important points. But they’re hardly news to security practitioners in the trenches building programmes.

Producing secure software when using an Agile menthod is not quite as simple as “architect and design early”. Yes, that’s important, of course. We’ve been saying “build security in, don’t bolt it on” for years now. That has not changed.

I believe that the key is to integrate security into the Agile process from architecture through testing. Recognize that we have to trust, work with, and make use of the agile process rather than fighting. After all, one of the key values that makes SCRUM so valuable is trust. Trust and collaboration are key to Agile success. I argue that trust and collaboration are keys to Agile that produces secure software.

In SCRUM, what is going to be built is considered during user story creation. That’s the “early” part. A close relationship with the Product Owner is critical to get security user stories onto the backlog and critical during user story prioritization. And, the security person should be familiar with any existing architecture during user story creation. That way, security can be considered in context and not ivory tower.

I’ve seen security develop a basic set of user stories that fit a particular class or type of project. These can be templated and simply added in at the beginning, perhaps tweaked for local variation.

At the beginning of each Sprint, stories are chosen for development from out of the back log, During this process, considerable design takes place. Make security an integral part of that process, either through direct participation or by proxy.

Really, in my experience, all the key voices should be a part of this selection and refinement process. Quality people can offer why a paticular approach is easier to test, architects can offer whether a story has been accounted for in the architecture, etc. Security is one of the important voices, but certainly not the only one.

Security experts need to make themselves available throughout a Sprint to answer questions about implementation details, the correct way to securely build each user story under development.  Partnership. Help SCRUM members be security “eyes and ears” on the ground.

Finally, since writing secure code is very much a discipline and practice, appropriate testing and vulnerability assurance steps need to be a part of every sprint. I think that these need to be part of Definition of Done.

Everyone is involved in security in Agile. Security folk can’t toss security “over the wall” and expect secure results. We have to get our hands dirty, get some implementation grease under the proverbial fingernails in order to earn the trust of the SCRUM teams.

Trust and collaboration are success factors, but these are also security factors. If the entire team are considering security throughout the process, they can at the very least call for help when there is any question. In my experience, over time, many teams will develop their team security expertise, allowing them to be far more self-sufficient – which is part of the essence of Agile.

Us security folk are going to have to give up control and instead become collaborators, partners. I don’t always get security built the way that I might think about it, but it gets built in. And, I learn lots of interesting, creative, innovative approaches from my colleagues along the way.

cheers

/brook

Pen Testers Cannot Scale To Enterprise Need!

Posted on by

As reported in Information Week, several Black Hat researchers have noted that humans must qualify application vulnerability scanning results. It’s hard to find this statement as “news” since I’ve been saying this publicly, at conferences for at least 4 years. I’m not the only one. Ask the vendors’ Sales Engineers. They will tell you (they have certainly told me!) that one has to qualify testing results.

“At the end of the day, tools don’t find vulnerabilities. People do,” says Nathan Hamiel, one of the researchers. 

Yes, Nathan, this has been the state of affairs for years.

The status quo is great for penetration testers. But it’s terrible for larger organizations. Why? Pen testers are expensive and slow.

I agree with the truisms stated by the researchers. If there were 10’s of thousands of competent penetration testing  practitioners, the fact the the tools generally do NOT find vulnerabilities without human qualification would not matter.

But there are only 1000s, perhaps even less than 3000 penetration testers who can perform the required vulnerability qualification. These few must be apportioned across 10s of millions of lines of vulernable code, much of which is exposed to the hostile Public Internet.

Plus which, human qualified vulnerability testing is slow. A good tester can test maybe 50 applications each year. Against that throughput, organizations who have a strong web presence may deploy 50 applications or upgrades each quarter year. Many of the human qualified scans become stale within a quarter or two.

Hence this situation is untenable for enterprises who have an imperative to remove whatever vulnerabilities may be found. Large organizations may have 1000s of applications deployed. At $4-500/hour, which code do you scan? Even the least critical application might hand a malefactor a compromise.

This is a fundamental mis-match.

The pen testers want to find everything that they can. All fine and good.

But enterprises must reduce their attack surface. I would argue that any reduction is valuable. We don’t have to find every vulnerability in every application. Without adequate testing, there are 100% of the vulnerabilities exposed. Reducing these by even 20% overall is a big win.

Further, it is not cost effective to throw pen testers at this problem. It has to either be completely automated or the work has to be done by developers or QA folk who do not have the knowledge to qualify most results.

Indeed, the web developer him/herself must be able to at least test and remove some of the attack surface while developing. Due to the nature of custom code testing, I’m afraid that the automation is not yet here. That puts the burden on people who have little interest in security for security’s sake.

I’ve spoken to almost every vulnerability testing vendor. Some understand this problem. Some have focused on the expert tester exclusively. But, as near as I can tell, the state of the art is at best hindered by noisy results that typically require human qualification. At worst, some of these tools are simply unsuitable for the volume of code that is vulnerable.

As long as so much noise remains in the results, we, the security industry, need to think differently about this problem.

I’m speaking at SANS What Works in Security Architecture August 29-30, Washington DC, USA. This is a gathering of Security Architecture practioners from around the world. If your role includes Architecture, let me urge you to join us as we show each other what’s worked and as we discuss are mutual problem areas.

cheers

/brook

What Is Our Professional Responsibility?

Posted on by

What Is Our Professional Responsibility?Four times within about a month, I’ve had to deal with “security issues” that were reported as “emergencies”. These appeared as high priority vulnerabilities requiring immediate “fixing” from my team.

Except, none of these were really security issues. Certainly none of these was an emergency.

None of these were bugs or vulnerabilities. In fact, if the security engineer reporting the issue had done even a modicum of investigation, these would never have been reported. False positive.

In one instance, a security engineer had browsed information on a few web pages of a SaaS application and then decided, without any further investigation that the web product had “no security”. She or he even went to far as to “ban” all corporate use of that product. Wow! That’s a pretty drastic consequence for a product who’s security controls were largely turned off by that customer’s IT department. Don’t you think the security engineer should have checked with IT first? I do.

A few days later a competitor of that product pointed a security engineer to an instance that was also configured with few security controls by the customer. The competitor claimed that the “product has no security”. The engineer promptly reported a “security deficiency”.

Obviously, a mature product should have the capability to enforce the security policies of its users, whatever those happen to be. That’s one of the most important tenants of SaaS security: give the customer sufficient tools to enact customer policies. Do not decide for the customer what their appropriate policies must be; let the customer implement policy as required.

Since the customer has the power to enact customer policies, the chosen posture may be wide open or locked down. The security posture depends upon the business needs of each particular customer. Don’t we all know that? Isn’t this obvious? (maybe not?)

In both the cases that I’ve described (and the other two), I would have thought that the engineer would first investigate?

  • What is the actual problem?
  • How does the application work?
  • What are the application’s capabilities?
  • Is there a misconfiguration?
  • Is there a functionality gap?
  • Is there a bug?

When I was a programmer, the rule was, “don’t report a bug in infrastructure, library, or compiler until you have a small working program that positively demonstrates the bug1”. In other words, we had to investigate a problem, thoroughly understand it, isolate it, and provide a working proof before we could call technical support.

Apparently, some security engineers feel no compulsion for this kind of technical precision?

I went to the CSO and asked, “If I failed to investigate a problem, would you be upset? If I did it repeatedly, would you fire me?” Answer: “Yes, on all counts.”

Security managers, what’s our accountability? Are your engineers accountable for the issues that they report?

Are we so hungry for performance metrics that we are mistakenly tracking “incidents reported”? (which is, IMHO, not a very good measure of anything). To what are we holding security investigators accountable?

My understanding of my professional ethics requires me to be as sure as I possibly can before running an issue up the flag pole. Further, I like to present all unknowns as clearly as I can. That way, false positives are minimized. I certainly wouldn’t want to stake the precious trust that I’ve carefully built up on a mere assumption which easily might be a mistake.

Of course, it’s always possible to believe one has discovered a vulnerability that turns out to be misunderstanding or misconfiguration. That can happen to any one of us. Securing multiple technologies across multiple use cases, across many technologies is difficult. Mistakes are far too easy to make. Because of the ease of error, I expect to get one or two of poorly qualified vulnerabilities each year. But four in a month? What?

Let’s all try to be precise and not get carried away in the excitement of the moment. That holds true whether one thinks one has discovered a vulnerability or is taking a bug report. I believe that information security professionals should be seen as “truth tellers”. We must live up to the trust that is placed in us.

By the way, there’s a very exciting conference upcoming at the end of August (2011), Security Architecture: Baking Security into Applications and Networks 2011. This conference is particularly relevant for Security Architects and any practitioner who must design security into systems, or who is charged with building a practice for security architecture and designs. I’ll write more about this conference later. Stay tuned.

cheers,

/brook

1) The small program could not include any of the functionality required by the program that was being written. It had to demonstrate the bug without any ancillary code whatsoever. That meant that one had to understand the bug thoroughly before reporting.

What’s Wrong With Customer Support?

Posted on by

I know that it’s been a while since I’ve posted. Let me apologize for that. I’ve got a lot of topics that I want to start covering here soon. Stay tuned.

Still, this morning’s reply from Intuit customer support was just too rich to pass up. Let me offer this little laugh to you to brighten you day. And then, I want to say a few words about why these interchanges are endemic to customer support as practiced by most companies.

I’ve heard support folks called “case closing machines”. Not very nice. But unfortunately, far too true. These are the metrics upon which customer support are rated: how many support cases can be moved through the queue within a time period.

The result of this rating, of course, is that the support person is far more interested in responding quickly to dispose of a request than in actually understanding what has been requested. And that, I find, wastes everyone’s time.

Let me give some context. I use Quicken 2oo7 on Macintosh for my home accounting. I’ve been a Quicken and Intuit customer for years. I was having trouble updating transactions to account from my financial institution. Heck, first thing to do is always update the software, right?

OK. I ran the R2 installer and got a weird error message claiming that I had “no valid copy” of the the software. Huh? Since I was in a hurry (first mistake!), I fired off a support ticket. 10 minutes later, I checked the running version of my software and low and behold, I’d already installed R2. Uh, oh! Bad ticket, no need for support.

Well, there wasn’t any way to recall the issue. So I let it grind through support while I installed the R3 updater successfully. (this didn’t solve the original problem, unfortunately. but that’s another story)

When I received the response to my ticket from Quicken, at first I was just going to ignore it. But the activist in me just can’t let lie!

I wrote back a quick note suggesting that the error message in the R2 updater might be just a little misleading.

Here’s my reply to Quicken Support. I’ll follow that with the first couple of lines of the second reply from Quicken Support:

“Yes – I figured your suggestion out about 15 minutes after putting in
the ticket. Sorry about that.

But, I would suggest that your error message could say something of the
nature:

“your quicken is already upgraded to R2”

Rather than “no valid quicken found” (or whatever the error says).

these are very different messaging. I would have had no need to file a
ticket (that’s money in intuit’s pockets, yes?)

Your programmers and QA staff need to do better, I think!

thanks”

I’ll admit that my suggestion might be a bit terse. It does say, I hope clearly, that I found my solution, yes? I even apologize for the submitting the ticket: “Sorry about that”

then I go on to make a suggestion, “Change your error message. It’s misleading”

Here’s what I got back from “Karuna, Quicken Customer Care”:

“Brook, in this case I would advise you to uninstall and reinstall Quicken using the download link which I am providing you with. The download link contains the complete software with the updated patch. Please follow the steps mentioned below to uninstall Quicken…”

The email interchange goes on in detail on how to accomplish the reinstallation of Quicken 2007, including a download of the entire installer! If I had followed these instructions, it would have wasted hours of my time; I wouldn’t be writing this post, smile.

It is true that filing the issue was my mistake; there wasn’t anything really wrong.

My mistake was based upon a very poorly written error message in the R2 installer for Quicken 2007 which suggested that I had no valid copy of Quicken 2007. Which, of course, I do**.

Intuit support didn’t understand my note – probably the person working the issue didn’t really read it? Can you spell “scan”?

My response to Intuit required no reply whatsoever. Rather I suggested action on the part of Intuit Product Management and perhaps the development teams, should there be merit in my suggestion.
Quite obviously, keeping ridiculous metrics like “cases closed/time period” forces a support team to actually waste huge amounts of time sending useless and inappropriate replies to people who don’t need them and can’t use them. All in the  name of productivity.

Most companies do it this way. It’s rare that I actually get a first reply that is on target demonstrating true understanding! Support don’t actually read what’s been written. I get asked all the time to “please supply the version and machine information” which I have already very carefully listed in the request. How absurd is that?

Support assume:

  • the incompetence of the request
  • the poor articulation of the requester

Support prioritize:

  • speed of delivery over understanding
  • delivering an answer, any answer
  • the first lines of the question (which are often only context)
  • any answer that can found in existing the knowledge base, no matter how inappropriate

If the support person had only truly read what I wrote s/he would have fully known that:

  • I didn’t need a reply
  • I had made a suggestion to be passed to Product Management
  • my problem was solved before the first reply from Quicken last week

Scanning the email (esp. if the scanner’s English is a 2nd or 3rd language) is highly prone to this kind of misunderstanding.

Ugh!

I think I’ll try to find out who’s the executive in charge of Intuit’s support operations and talk to that person. Because this is just too ridiculous to let go. We in the software industry need to get a lot more professional if customers are going to trust us.

Treating our support people as “case closing machines” is demeaning and dehumanizing. Instead of valuing and training problem solvers, we’ve created a situation whereby the competent use the support role only as a stepping stone on the way to another position. Who’s left behind? Those with low self-esteem, low expectations, those who don’t care about the job. Is that who you want responding to your customers?

And, of course, these sorts of email interchange and frustration go back and forth every day wasting everyone’s time with useless solutions to problems that don’t exist.

cheers

/brook schoenfield

**I pay for my software – it’s ethical. And, as John Caron used to say to me, “People don’t pay for software. They register the software because of the bugs for which they’ll need support” Tee, hee. all too true, John.

Missed Points, Wrong Message?

Posted on by

Today, as every day, I was bombarded with articles to read. You, too?

Today, Testing for the Masses: More affordable assessment services reveal a new focus on application security caught my eye.

As some of my readers may know, I’ve spent a lot of time and effort on re-creating the customer web application security testing viewpoint. And, of course, Markus and I often don’t agree. So, I trundled off to read what he’d opined on the subject.

Actually, it’s great to see that ideas that were bleeding edge a few years ago are now being championed in the press!

* Build security in the design
* Code securely
* Verify both the design and the code

The “design” part of the problem requires reasonable maturity of a security architecture practice.

And, web application code must be tested and fixed before deployment, just as this article suggests. All good. If we could achieve these goals on a broad scale it would be a much better world that what we’ve got, which has been to deploy more than 100 millon lines of vulnerable code to the web (see Jeremiah Grossman’s white papers on this topic)

Further, the writers suggested that price points of web application testing tools must fall. And here’s where the ball got dropped. Why?

The question of price is related to one of the main limitations on getting at least the simple and egregious bugs out of our web code.

The tool set has until recently been made for and focused to people like Markus Ranum – security experts, penetration testing gurus. These tools have emphasized broad coverage and deep analysis. And that emphasis has been very much at the expense of:

* tool cost
* tool complexity
* noisy results that must be hand qualified by an expert

There aren’t that many Markus Ranum’s in the world. In fact, as far as I know, only one! Seriously, there are not that many experienced web application vulnerability analysts. My estimate of approximately 5000 was knocked down by some pundit (I don’t remember who?) at a SANs conference at which I was speaking. His guesstimate? 1500. Sigh. Imagine how many lines of code each has to analyze to even make a dent in those 100 million lines deployed.

Each of the major web application vulnerability scanners assumed that the user was going to become an expert user in the tool. User interfaces are complex. Setting the scope and test suite are a seriously non-trivial exercise.

And finally, there is the noise in the results – all those false positives. These tools all assume that the results will be analyzed by a security expert.

Taken together, we have what I call the “lint problem”. For those who remember programming in the C language, there is a terrifically powerful analyzer called “lint”. This tool can work through a body of code and find all kinds of additional errors that the compiler will miss. Why doesn’t everyone use lint, then? Actually, most C programmers never use lint.

Lint is too hard and resource intensive to tune. For projects that are more complex than one of two source files, the cost of tuning lint far out weighs it’s value. So, only a few programmers ever used the tool. On a 3 month project, just about the time the project is over is when lint is finally returning just the useful results. Not very timely, I’m afraid.

And so, custom web application vulnerability testing has remained in the hands of experts, people like Markus Ranum, who, indeed, makes his living by reviewing and fixing code (and rumour has it, a very good living, indeed).

So, of course, Markus probably isn’t going to suggest the one movement that will actually bring a significant shift this problem.

But I will.

The vulnerability check must be put into the hands of the developer! Radical idea?

And, that check can’t be a noisy, expert driven analysis.

* The scan must be no more difficult to run than a compiler or linker. (which are, after all, the tools in use by many web developers every day)
* The scan should integrated seamlessly into the existing workflow
* The scan must not add a significant  time to the developer’s workflow
* The results must be easy to interpret
* The results must be as accurate as a compiler. E.g., the developer must be able to trust the results with very high confidence

Attack these bugs at the source. And, to achieve that, give the developer a tool set that s/he can use and trust.

And, the price point has to be in accordance with other, similar tools.

I happen to know of several organizations that have either experimented with this concept or have put programs into place based on these principles (can’t name them, sorry. NDA) And guess what? It works!

Hey, toolmakers, the web developer market is huge! There’s money to be made here, folks.

Markus, I think you missed a key point, and are pointing in the wrong direction (slightly)

cheers

/brook

Nuance’s IBM Via Voice for Macintosh is a Disaster

Posted on by

I hadn’t meant for this forum to be about all things computer related – certainly not my personal struggles with software. But there is really no other forum for lambasting a product for truly terrible behavior. Couple this with a complete lack of customer support and frankly, I’m pretty upset. I’m hoping that by posting here, I can get it out of my system and get on with my work.

I make extensive use of voice recognition speech-to-text capabilities. My hands simply cannot type as much on a computer as I need to do in any given week. Getting speech transcription working has been a huge boon to me to be able to get my work done without having to spend my weekends recovering with ice packs and ibuprofen.

When I used Windows, I was directed to Dragon Naturally Speaking. After a modest amount of training, that product allowed me to cut my keystrokes by more than half. While it’s not perfect, it does work, even to the ability to pick up on my quirky manner of speech which is part Americanisms and part Britishisms and filled with technical jargon. After every transcription session, Dragon can reanalyze what it has learned, the corrections, it mistakes to get a little more accurate.

All well and good, this was clearly a success for me.

Then, I switched to a Macintosh. There are many reasons for me to use a mac for my work, most notably: it’s a UNIX variant that allows me to run that tool set when I need them natively. This is a wonderful addition for me: no dual boot, no libraries on top of the OS (cygwin), just native UNIX (BSD) when I need it, which is fairly often. And, I don’t forget which OS I’m in, mistakenly typing “ls” when I need “dir” – smile.

To be fair, I do run Dragon in my Macintosh hosted XP virtual machine. But, that doesn’t help with native mac editing – most notably, I run native mac email, Thunderbird. Grump. So, I set out to get speech-to-text running on my mac. Oh, boy.

In my research, IBM Via Voice seemed to be the best alternative for mac transcription. To be fair, I haven’t tried MacSpeech. But I may yet, considering.

I run OS X 10.4.10 on a recently purchased Intel dual-core Macbook. IBM Via Voice hasn’t been updated since OS X 10.3! It doesn’t find the USB microphone no matter how one sets the sound preferences. Ugh! Nuance (current the supporter of Via Voice) simply told me to return the software. In other words, unless you’re running a relatively ancient version of the OS, you’re unsupported. Are they really “supporting” this product, or just hoodwinking uninformed consumers such as myself into purchasing something that cannot work?
However, before returning the software (wish that I had!), I trolled online forums and discovered that the software will start if the sound preferences are open as it comes up. OK. That works. Now to use the thing.

Ah, but unlike Dragon, all the nice macros like “correct” and “select” that allow hands free operation only work in the Via Voice Text Pad, not in all entry areas (like, uh, email, Word, you know, all the software that one might actually use to create documents on a mac. Uh, oh.) OK, I can do my own editing if this thing will just transcribe reasonably accurately? Read on, no such luck.

Via Voice ships with a USB headset from Andrea, their NC-7100. It is NOT recommended for speech recognition! They have pricier models for that. Ah, a follow on sale, uh? Using the shipped headset delivers poor recognition. Plus, setting it to the correct volume is very difficult. I used the headset not just for Via Voice, but also, my soft phone. I’ve gotten beaucoups complaints about being muddy, too loud, distorted, inaudible on phone conferences. By the way, I live or die on phone conferences. Ok, crappy headset. No wonder Via Voice doesn’t work, right?

This wouldn’t be so bad unless I had already used Dragon, which ships with a cheapo non-USB (standard 1/8″ stereo plugs) headset that works fine. Comparisons make Via Voice look just awful. I could use almost anything for Dragon and it would work acceptably. Obviously, better headsets make a difference.

So, maybe I should get a better headset?

Oh, did I mention that unlike Dragon, Via Voice will not even start (much less use) a headset that does not deliver audio through USB? I, in my other life as a musician, have access to really good microphones. One of the tests that I ran was to try improving recognition by using studio level microphones. No dice! If it’s not USB, Via Voice cannot make use, no matter how fine the sound.

Why in heck would you design a product to a particular sound input, considering the gazillion ways there are for computers to take in audio? What if I wanted to increase success by using a studio grade A/D converter (I own several!) to deliver audio quality at a level way above speech recognition needs? It’s a silly design to tie oneself to a technology that may be superceded. Let the user choose. Keep your product alive as technology changes. Pretty basic design principle.

One very good reason to use a cheap, light headset is when traveling. I may not want to carry a relatively heavy USB headset when on the road. Or, maybe I have a really nice bluetooth headset that I want to use, allowing me to break the wire tether to my machine. Let me choose, Via Voice. The mac supports all of the above well. I’ve tested them all. Via Voice, however, fails miserably.

Did the new headset improve things? I bought the VXi Parrot Translator. My web research shows this head set as one of the favorites for speech-to-text recognition. This headset, while noticeably better, does not take Via Voice to the realm of Dragon – not even vaguely.

“OK” says I, always up for a challenge, “perhaps I need to do a lot more training with my new headset?”

Bringing up the Via Voice training software is a nightmare (on Elm Street?) The program doesn’t analyze my speech. Instead, as near as I can tell, it’s purpose is to train me to speak like it expects. It has particular trouble with the beginning of phrases and especially the very common words: the, a, in, or, for, if.

I would expect (and this is the way that Dragon works) that after a few iterations, the machine would start to recognize my particular manner of enunciating the articles (and other words being analyzed, right?) Not on your life.

What the analyzer does is complain at you and refuse to move on until it gets something that it can understand. I’ve been on the same “short story, 30 minutes” for 3 days. I’ve repeated “a” and “the” and “if” hundreds of times to no avail. All I get is an error telling me to start at the underlined place. Ugh! This isn’t training, this is torture.

Mind you, my rating as a speaker at the conference mentioned in my last post was 5th out of 24 (from the top). Not bad. And, my audience must have been able to understand most of what I said, yes? While I can mangle the English language pretty badly (even worse in French and worse yet in Spanish!), I do produce pretty well articulated English language articles, I’m guessing?

My speech mannerisms, no matter how quirky, must be widely understandable. And they are, to Dragon. But Via fails most often at these simple, common articles, often entering text so far off as to be laughable. If I wasn’t trying to get something done efficiently, I would laugh. But it’s darn frustrating, I can assure you.

I still haven’t finished the “30 minute” story. It’s stuck on an “it” at 71%. What a lousy piece of software. When writing software, upon encountering the same user error continuously, one must assume that something else is wrong and take corrective action. I’ve written a lot of software. And the first rule is to expect the impossible and deal with it gracefully for the user. Via Voice just gets bogged down and collapses. If I force it, it will refuse to recognize anything except words one-at-a-time. Not sentences, not phrases, words one at a time. I type at 70-80 words per minute. Speaking one word at a time is incredibly laborious.

So, my considered recommendation is: don’t try Via Voice. Maybe MacSpeech is better? I don’t know. I’ll let you all know if I try it.

I will send this link to Nuance for their consideration.

frustrated, with hurting hands after typing this missive.

cheers

/brook

The SANS Application Security Summit

Posted on by

Two days, about 20 speakers, all the major tool makers, pundits, researchers, penetration testers, this summit was almost a who’s who of application security. SANS wanted to kick-off their new GIAC application coding certification. And, along with that, they wanted to take a pulse of the industry. I was privileged to be included on a couple of panels – there were frighteningly smart people speaking – country mouse playing with the city cats, definitely!

A couple of my colleagues sat for the exam. I once held GIAC Intrusion Detection certification (#104?) but I let it lapse. (It’s not really relevant to what I do now) My buddies said it was a reasonable exam. The exam covered implementing security controls from the language APIs (java – JAAS calls) and coding securely.

The larger issue is what can we make out of this certification? How much effect will it have? Will getting coders certified change the landscape significantly?

There was plenty of FUD from the toolmakers. Yes, the entire web is vulnerable, apparently. Ugh! You probably knew that already, huh?

The numbers of applications out there is staggering. Estimates were running in the 100 millions. That’s a lot of vulnerable code. And, considering that my work’s DMZ takes a 6 million attack pounding every 24 hours, it’s not too far a stretch to assume that at least a few of those attacks are getting through. We only know about the incidents that are reported or that cause damage (as pointed out in the Cenzic report released at the Summit)

And, it seems like the financial incentives for exploiting vulnerabilities are maturing? (a google search will reveal dozens of financially motivated hack reports) If so, cash incentives will likely increase the number of incidents for all of us. Another big sigh.

One of the most interesting speakers to me at the conference was Dinis Cruz, CTO of Ounce Labs. A couple of times, he pointed out that while yes, we are being hacked, there’s no blood on the floor. Nobody’s been killed from a web hack (thank goodness!) We (inductries that use the web heavily) are losing money doing damage control, making up losses (especially, the financial industry), and doing remediations. Absolutely true.

But has anyone done an analysis of what the risk picture looks like? Is web exposure worth it? Are we making more than we’re losing? So much more that, like actuaries, the risks are worth it?

I know this question may seem crazy for someone from inside the information security industry to ask? But, anyone who knows me, knows that I like to ask the questions that aren’t being asked, that perhaps might even be taboo? We security folk often focus on reducing risk until we feel comfortable. That “warm and fuzzy”. Risk is “bad”, and must be reduced. Well, yeah. I fall into that trap all too often, myself.

It’s important when assessing a system to bring its risk down to the “usual and acceptable” levels of practice and custom of one’s organization. That’s at least part of my daily job.

But appropriate business risk always includes space for losses. What’s the ratio? Dinis definitely set me to considering the larger picture.

My work organization takes in more than 90% of its revenue through web sites. As long as loss is within tolerable limits, we should be ok, right? The problem with this statement comes with a few special classes of data compromise. These can’t be ignored quite so easily (or, the risk picture needs to be calculated more wholistically)

• Privacy laws are getting tougher. How does one actually inform each of 38 States Attorneys-General first? And, the Japan law makes this problem seem trivial.
• Privacy breaches are really hard on customer goodwill. Ahem
• Internet savvy folks are afraid of identity theft (again, a personally identifying information (PII) issue). The aftermath from identity theft can last for years and go way beyond the $50 credit card loss limit that makes consumer web commerce run.

I’ve got friends working for other companies that are dealing with the fall-out from these sorts of breaches. It ain’t pretty. It’s bad for organizations. The fall-out sometimes dwarfs the asset losses.

And, if I think about it, about all the vulnerabilities out there, are we each just one SQL injection exposure away from the same? Forget the laptop on the car seat. PII is sitting on organization database servers that are being queried by vulnerable web applications.

Considering this possibility brings me back to the importance of application security. Yes, I think we have to keep working on it.

And, our tool set is immature. As I see it, the industry is highly dependent upon people like Dinis Cruz to review our code and to analyze our running applications. I don’t think Dinis is a cheap date!

So, what to do?

I’ll offer what John Chambers, CEO of Cisco Systems, Inc., told me. (no, I don’t know him. I happened be in the same room and happened to have him take my question and answer it. Serendipitous circumstances). “Think architecturally”

That is, I don’t think we’re going to train and hire our way out of the vulnerability debt that we’ve dug for ourselves with 100 million apps on the web being vulnerable. Ahem. That’d take a lot of analysis. And, at the usual cost of $300/hour, who’d have the resources?

I’ll offer that we have to stop talking about and to ourselves about the problem and get it in front of all the stake holders. Who are those?

• The risk holders (i.e., executive management)
• Our developer communities (SANS certification is certainly a start. But I think that security has to be taught as a typical part of proper defensive programming. Just like structuring code or handling exceptions, input must be validated.)
• Security as an aspect of system design and architecture. Not that cute box along the side labeled “security” in the logical architecture diagram. Rather, we need to treat each security control as components of the system, just like the other logical functions.

Which brings me back to the SANS Summit.

My sense of this summit is that we haven’t yet reached the tipping point. I didn’t speak to everyone there. But I spoke to a fair share (I won’t call it a sample. My conversations were hardly statistical in nature!)

Most folks with which I chatted were like me, in the trenches. We had a few formidable notables in the room, and, of course, I think there were a few beginners, as well. My guess is that most branches of the industry were represented: tool makers, consultants, Information security folk, with a sprinkling of governmental folk thrown in. The folks that I spoke to understood the issues.

If I could hazard a guess, the folks who made the time to come are the folks concerned and/or charged with, or making money out of, application security. In other words, the industry. We were talking to ourselves.

That’s not necessarily a bad thing. I’m guessing that most of us have been pretty lonely out there? There’s validation and solidarity (leftists, please forgive me for using that term here – but it does fit!) when we get together. We network. We test our ideas and our programs. That’s important. And, I heard a few really great ideas that were fresh to me.

But I think we need to take this out a good deal further, to a “tipping point” if you will, in order to move the state-of-the-art. And, I don’t think we’re there yet. Consider, if you will, how many programmers are writing web code right now?

What do you think?

cheers

/brook

A Beginning

Posted on by

Sitting on a plane from Washington DC, USA, to my home in Oakland, California, I’m thinking about the SANS Application Security Summit that I just attended. What are the implications of this gathering, at this time? This seems like a propitious time to open a personal blog on information security. Some new winds may be bBrook, in the Netherlandslowing? Perhaps this summit is a the beginning of a sea change?

I’ve repeatedly thought that I’d like to share thoughts on the development of my industry. It’s exciting to me, certainly frustrating, sometimes even frightening.

Perhaps like many of you readers who work in Information Security, I spend my days  helping folks manage their digital risks? And probably, like you, I’m not always successful? Perhaps IT can’t field the technology required? Or, providing security requirements is seen by as an undue burden that cannot be borne at this time?

Still, when I understand that the stake holders feel that due diligence has been served, that an appropriate risk posture has been taken, it’s a good day. Small victories, even though our technologies are often immature or mis-applied, our processes insufficient, and our art, developing. And, of course, very occasionally, I help to identify and eventually close a major gap. Job satisfaction, absolutely.

Does any of this ring any bells or resonate for you?

Occasionally, a flash of incite will come to me. And clear as mud, I suddenly sense a possibility for us to perhaps advance our art just a wee bit. I’ll share those here for your consideration and comment. While I do occasionally publish papers and speak at conferences (as I did these last 2 days), I intend to use this forum for my tentative possibilities, not for my certainties, which are generally few, anyway.

Months will go by in the daily round of meetings, risk assessments, security requirements, system architectures, and design comments. During these periods, I may choose to be quiet, waiting for some inspiration to strike. Please stay tuned.

Perhaps you’ll appreciate knowing that I’m working through the same issues as you? Or, maybe you’ll comment that I’m way off course? I don’t know. I welcome the interchange, in any event. Through dialog, I learn as much, probably more, than I give.

I’ll write more about the SANS Summit in a subsequent entry. But, here’s a beginning…

cheers,

/brook