Was AntiVirus; Now something Completely Different!

[Feathers McGraw]

Must have been a hard paper.

That was delightfully awful... hehe.

[SteveRiley]

spalling (outer layers flaking/popping off).

I'm going to have to incorporate this wonderful new word into my vocabulary. "Hey, Bob, your scalp is spalling!"

Sulphates are also present in sea water and they would still cause problems though. They react with the cementitious compounds and turn them into other compounds that won't hold the concrete together, and have a much higher volume, leading to internal tensile forces. I did my dissertation on the effect of sulphates on mass concrete, but I'll spare you the details!

Must have been a hard paper.

[Feathers McGraw]

If you're saying that salinity and compression won't affect concrete, I say prove it

I would have to be mad to make such a claim! Although most of those salts have a much greater effect on the rebar than the concrete itself (so mass concrete would do OK)... and I doubt you'd get crystallisation at the bottom of the ocean, so there goes one part of the problem!

In general, concrete loves a bit of compression, but that pumping action you get when vehicles drive over it doesn't help because it pushes the salt further inside.

Incidentally, one of the worst places you can put reinforced concrete is in the splash zone by the sea... much worse than permanently underwater because you get an unlimited supply of salt drawn up through capillary action, which crystallises under the surface and causes spalling (outer layers flaking/popping off).

Sulphates are also present in sea water and they would still cause problems though. They react with the cementitious compounds and turn them into other compounds that won't hold the concrete together, and have a much higher volume, leading to internal tensile forces. I did my dissertation on the effect of sulphates on mass concrete, but I'll spare you the details!

[SteveRiley]

I used to live in Ohio, where applying salt to roads, sidewalks, and driveways to remove snow is a routine procedure. Such applications resulted in regular descrution of roads, sidewalks, and driveways. If you're saying that salinity and compression won't affect concrete, I say prove it

[Feathers McGraw]

A potential definition of a "secure" computer is one that has no applications, no operating system, is encased in solid concrete, and sunk to the bottom of the ocean! This same computer could also be defined as "useless." But even here, the computer and its concrete casing are vulnerable to corrosion from saltwater and destruction from the intense pressures on the ocean floor.

Careful there Steve, you wouldn't want to start a conversation about concrete with a Civil Engineer!

[SteveRiley]

Yeah. And to those who claim the Internet never forgets, Microsoft has somehow made my TechEd talks disappear. The various places where you could watch recordings from prior years are all just gone. Sigh.

[vinnywright]

nice talk ,,,,,shame on them for censoring and removing some of it from the DVD's ,,,,,,,,,,,,,,,,,,,,,,,,,, O ya ,,,we cant have the truth out their .

VINNY

[SteveRiley]

I was told once, that the only "true" way to protect ones data is to have it isolated from everything else.

A potential definition of a "secure" computer is one that has no applications, no operating system, is encased in solid concrete, and sunk to the bottom of the ocean! This same computer could also be defined as "useless." But even here, the computer and its concrete casing are vulnerable to corrosion from saltwater and destruction from the intense pressures on the ocean floor.

As Feathers astutely observes, one must always make trade-offs. You connect your computer to a network not because there exist risks but because there exists rewards -- rewards that, presumably, outweigh the risks. You can further alter the risk:reward ratio by taking appropriate steps to minimize the risk; these have the nicely coincidental benefit of likely helping to maximize the rewards as well.

In 2007, I delivered a talk at the various Microsoft TechEds around the world on exactly this topic: security trade-offs. It got some press coverage. Not all commenters on the various pieces expressed positive reactions. Nevertheless, I stand by my assertions. Security decisions always involve trade-offs. It doesn't matter whether you're trying to protect a computer from an attacker, an airplane from a jihadist, or a nation from its enemies -- the requirement to balance risks, threats, rewards, and access always applies. Those who argue otherwise do so from bias or emotion, not from rational assessment.

http://arstechnica.com/information-t...rity-overkill/
http://apcmag.com/too_much_security_..._microsoft.htm
http://blogs.msmvps.com/alunj/2007/0...ley-at-teched/ -- I agree with Alun's mild rejoinder
http://www.theinquirer.net/inquirer/...y-is-bad-thing
http://slashdot.org/story/07/08/08/1...r-is-overblown -- such a variety of reactions; most people get off the rails
http://www.crn.com.au/Tools/Print.aspx?CIID=24546

[Feathers McGraw]

Yeah, fair enough...

I suppose the key thing is that when it's a business decision, not personal, you can't just choose a sensible selection of apps, some MBA makes that decision for you... so you probably end up with the shiniest one, or the one whose company can afford "hospitality".

As for the business case, the guy in that video you posted was right... companies should have a legal obligation to fix security bugs when they are disclosed... or open the source and let users people do it (this doesn't necessarily mean making it freely distributable). Not doing so is negligent.

[SteveRiley]

Yes but people don't do it on purpose! You might as well say WAFs exist because humans are fallible and it's useful to have a second line of defence. This is surely different to knowing about a bug and choosing not to fix it.

Ah, the idealism of youth. When you grow up, Feathers (tee hee), you'll surely encounter situations like the following:

1. For reasons beyond your control, your organization has standardized on $THIRD_PARTY_WEB_APP
2. This application must be made available over the Internet, even though it requires authentication (scenario: traveling employees/partners)
3. The provider of this application contractually prohibits you from modifying the code -- even though it's plain HTML on the server
4. The provider is slow to fix bugs

So, Mr. Smartypants, whatyagonnado?

[Feathers McGraw]

You're right, WAF <> anti-virus. I was responding to your statement, "if you know there are security bugs in your code you should fix the bugs instead of writing another program to look for people trying to exploit them." WAFs exist primarily because people have to run web applications with known bugs and they can't fix the bugs.

I also made the point that you only get this kind of problem if you use programs that are crappy (have known security bugs) that you can't fix (proprietary). If you're using a free software app that has a security hole you'd be better off spending your time fixing it than creating some new app that requires just as much maintenance as the original app.

For example: SQL injection attacks would disappear if all input were validated and the application used only parameterized stored queries to interact with the database. Obviously, people don't do this, and the result is insecure code that can be used to leak information from databases.

Yes but people don't do it on purpose! You might as well say WAFs exist because humans are fallible and it's useful to have a second line of defence. This is surely different to knowing about a bug and choosing not to fix it.

[Feathers McGraw]

I was told once, that the only "true" way to protect ones data is to have it isolated from everything else. A standalone computer that is not connected to anything, and accepts no external input other than the from the keyboard by a trusted operator. Even then, the vulnerability is the operator and his/her computer and programing skills.

Sounds like a true statement, but the problem is a computer that is isolated from everything has very little utility. So, I guess it's always a trade-off of utility against security, a problem that isn't unique to IT, but applies to pretty much everything worth doing.

[Snowhog]

I was told once, that the only "true" way to protect ones data is to have it isolated from everything else. A standalone computer that is not connected to anything, and accepts no external input other than the from the keyboard by a trusted operator. Even then, the vulnerability is the operator and his/her computer and programing skills.

[SteveRiley]

You're right, WAF <> anti-virus. I was responding to your statement, "if you know there are security bugs in your code you should fix the bugs instead of writing another program to look for people trying to exploit them."

WAFs exist primarily because people have to run web applications with known bugs and they can't fix the bugs. For example: SQL injection attacks would disappear if all input were validated and the application used only parameterized stored queries to interact with the database. Obviously, people don't do this, and the result is insecure code that can be used to leak information from databases.

[Feathers McGraw]

I'd argue that ModSecurity (or any other WAF) is different to an antivirus because it's looking for general patterns of bad behaviour rather than exploits for specific bugs that you could just fix. I know a lot of the rules were written by learning from previous known exploits, but the point is that the community also fixed the bugs in that software (like the Joomla JCE exploit, which still has bots running around on the internet)... the rule is then there to catch generic "bugs like this" that you don't know exist yet.

For example, many of the ModSecurity rules are broad, and look for shell commands in POST data or limit the amount of PCRE allowed, because these are general indicators of naughtiness.