Whatever you do, don't use metases

Read [link|http://www.zdnet.com/eweek/stories/general/0,11011,2800177,00.html|this] then come back for discussion.

Finished?

Okay, now let's count the ways she's wrong. You may have to borrow a few fingers from your coworkers to count that high, but we'll try anyway.

In fact, so frequent are these incidents [web-server-attacking worms] that, for many of the victims, just keeping up with the server software fixes seems to be too much to handle.

But, as annoying as such defacements are, in my opinion the more serious threat comes from security vulnerabilities in badly written home-grown Web applications-Common Gateway Interface scripts, server-side executables, active scripting and so forth ... These are the holes that are most likely to expose customer or business proprietary data.

Isn't it wounderful that she's able to predict that with such certainty! I mean, we have a room full of people whose job is to ensure the security of the products we write, but she knows that we are actually the problem here. I guess we should just fire everyone, give copies of FrontPage to our clients' managers, and tell them to rely on the industrial-strength security of Microsoft's products.

Of course, we'll still need those full-time people running each server, making sure the latest patches are installed. And that the new patches don't break anything else. And that the patches don't introduce any new vulnerabilities. Oh wait, since those full-time people won't have access to the source even for the patches, there's no way they can know any of those things excpet through trial and error. Could that be why: (from a [link|http://www.informationweek.com/thisweek/story/IWK20010803S0020|different publication])

In most corporate IT environments, even after a software vendor sends out an alert, the patch job might languish. "Security often takes a backseat to other projects that management deems more important, and the resources aren't always made available to put patches into place immediately--or even within weeks," says a network administrator at a major medical company, who asked not to be identified.

Sounds to me like getting the server software right just may be slightly more critical. After all, changing a single CGI will probably only affect that CGI, or maybe a single application. But having to patch a server because someone hacked it -- or could -- is sure to affect just about everything to some degree.

So much business is moving onto the Internet that we can't wait for evolution to produce better code (an approach that has failed in every other area of software development).

Yes, we're hearing from Jody again. Apparently she's never heard of Linux, Apache, Bind, Sendmail ... Okay, listing all the success is getting tedious. Do these professional pundits and consultants go out of their way to stay uninformed, or is it a conscious effort to disparage anything they can't make a buck on?

So what's her solution?

Remember, security should be baked in, not painted on. Security should be an integral part of your software life cycle process, beginning with design and continuing through development and testing.

Good advice. But is she really suggesting that Microsoft's products have followed this path? Really? I'd like to find a list of her formmer clients. They should be in need of some help after the recent rash of Code Red attacks. I imagine they're getting hit pretty hard, if they actually followed advice like hers.

At least that's what the article is trying to say.

Couple of problems with the article. First, in terms of sheer quantity, there are a number of off the shelf virii that any two bit script kiddie can distribute. It takes much more work to find an exploit for software that runs on a limited number of servers. The custom software may (or may not) be as vulnerable as MS software, but it would take some work by a true cracker to expose the weakness, rather than some bored teen.

Second, security should involve concepts of layers of rings. An application that somehow exposes it's specific information is not nearly as damaging as an internal Operating System malfunction. The damage from an errant application is limited to the exposure implicit within the application. A penetration into the OS, however, amounts to any and all information within the server becoming available - as well as all the information in which the server has trusted domain within the network. Why spend time trying to figure out a custom app when you can bypass that work and just directly go for the least-common-denominator?

Post #4,509 by drewk 8/10/01 10:00:33 AM Reply	Whatever you do, don't use metases Read [link\|http://www.zdnet.com/eweek/stories/general/0,11011,2800177,00.html\|this] then come back for discussion. Finished? Okay, now let's count the ways she's wrong. You may have to borrow a few fingers from your coworkers to count that high, but we'll try anyway. In fact, so frequent are these incidents [web-server-attacking worms] that, for many of the victims, just keeping up with the server software fixes seems to be too much to handle. But, as annoying as such defacements are, in my opinion the more serious threat comes from security vulnerabilities in badly written home-grown Web applications-Common Gateway Interface scripts, server-side executables, active scripting and so forth ... These are the holes that are most likely to expose customer or business proprietary data. Isn't it wounderful that she's able to predict that with such certainty! I mean, we have a room full of people whose job is to ensure the security of the products we write, but she knows that we are actually the problem here. I guess we should just fire everyone, give copies of FrontPage to our clients' managers, and tell them to rely on the industrial-strength security of Microsoft's products. Of course, we'll still need those full-time people running each server, making sure the latest patches are installed. And that the new patches don't break anything else. And that the patches don't introduce any new vulnerabilities. Oh wait, since those full-time people won't have access to the source even for the patches, there's no way they can know any of those things excpet through trial and error. Could that be why: (from a [link\|http://www.informationweek.com/thisweek/story/IWK20010803S0020\|different publication]) In most corporate IT environments, even after a software vendor sends out an alert, the patch job might languish. "Security often takes a backseat to other projects that management deems more important, and the resources aren't always made available to put patches into place immediately--or even within weeks," says a network administrator at a major medical company, who asked not to be identified. Sounds to me like getting the server software right just may be slightly more critical. After all, changing a single CGI will probably only affect that CGI, or maybe a single application. But having to patch a server because someone hacked it -- or could -- is sure to affect just about everything to some degree. So much business is moving onto the Internet that we can't wait for evolution to produce better code (an approach that has failed in every other area of software development). Yes, we're hearing from Jody again. Apparently she's never heard of Linux, Apache, Bind, Sendmail ... Okay, listing all the success is getting tedious. Do these professional pundits and consultants go out of their way to stay uninformed, or is it a conscious effort to disparage anything they can't make a buck on? So what's her solution? Remember, security should be baked in, not painted on. Security should be an integral part of your software life cycle process, beginning with design and continuing through development and testing. Good advice. But is she really suggesting that Microsoft's products have followed this path? Really? I'd like to find a list of her formmer clients. They should be in need of some help after the recent rash of Code Red attacks. I imagine they're getting hit pretty hard, if they actually followed advice like hers. This is my sig. There are many like it, but this one is mine.
Post #4,510 by ChrisR 8/10/01 10:16:57 AM Reply	Custom software sucks. Buy it from the vendor. At least that's what the article is trying to say. Couple of problems with the article. First, in terms of sheer quantity, there are a number of off the shelf virii that any two bit script kiddie can distribute. It takes much more work to find an exploit for software that runs on a limited number of servers. The custom software may (or may not) be as vulnerable as MS software, but it would take some work by a true cracker to expose the weakness, rather than some bored teen. Second, security should involve concepts of layers of rings. An application that somehow exposes it's specific information is not nearly as damaging as an internal Operating System malfunction. The damage from an errant application is limited to the exposure implicit within the application. A penetration into the OS, however, amounts to any and all information within the server becoming available - as well as all the information in which the server has trusted domain within the network. Why spend time trying to figure out a custom app when you can bypass that work and just directly go for the least-common-denominator?
Post #4,516 by wharris2 8/10/01 11:30:45 AM Reply	Secure snicker I mean, we have a room full of people whose job is to ensure the security of the products we rite, but she knows that we are actually the problem here Actually, I have known and worked with people with less conception of security than her. People who never figured on wanting a web server on a different computer from the main corporate database fer instance. French Zombies are zapping me with lasers!
Post #4,552 by tuberculosis 8/10/01 5:01:03 PM Reply	She's just pitching for some work. Trying to scare some poor IS manager into parting with a few sheckles to have his custom software audited I'm sure.

Welcome to IWETHEY!