yahoi writes "Companies around the world are leaving themselves wide open to Web- and client-side attacks, according to a new report released today by the SANS Institute that includes real attack data gathered from multiple sources. SANS found that most organizations are focusing their patching efforts and vulnerability scanning on the operating system, but they're missing the boat: 60 percent of the total number of attacks occur on Web applications, and many attacks are aimed at third-party applications such as Microsoft Office, and Adobe Flash and other tools. Exacerbating the problem, they're taking twice as long to patch Microsoft Office and other applications than to patch their operating systems."
I find it hard to trust the credibility of the report, after a statement like this:
SANS' Ullrich says patching third-party applications isn't easy. "Third-party applications can be tough. There's no good system" for patching them, he says. The key is inventorying third-party Web applications, which the report shows are a major attack vector, Ullrich says.
It's called apt. It's already widely deployed in Debian and Ubuntu, and has been for a long time. The problem is solved.
I guess we're one of the approximations.;) Our office is more Ubuntu than Windows and people, astonishing to the Windows faithful, don't have any trouble getting their work done.
Almost any office could replace many, if not most, of their desktops with Ubuntu with very little difficulty. The level of effort increases to another level if you want to try replacing all of them.
Imagine having APT for a large percentage of your desktops. A couple keystrokes to run a script
As with operating systems, it tends to be the commercial vendors who don't produce and distribute packages in the standard way, instead preferring to use their own nonstandard installer which doesn't integrate with the existing mechanisms for keeping things up to date. I would consider lack of integration with the standard update system to be a big black mark against something when evaluating it relative to possible other options.
Incidentally, Nokia use apt on their maemo platform, which includes the new N90
Yeah, and if they were honest and serious that's were they would have said, "third-party applications can be tough. There are very good systems for patching them, like Debian's APT, but sadly most vendors of proprietary software have made practically no progress in this area in two decades".
The claim that there is no good system is just the sort of claim that gets quoted out of context, and when it happens, supposedly expert technical people will be the ones making the mistakes. Think of it like politics. Someone writes a story specifically about the Democratic party in Ohio. Five paragraphs in, they say "There are no particularly distinguished front runners for the upcoming election.". What happens when that gets quoted by itself - is there much chance at all that someone
Did you forget to read the top of the figure where it says "Microsoft OS" and not "Linux"?
No, I didn't forget to read it. It wasn't there. "Microsoft OS", "Windows", these were not mentioned in the article nor in the report. Things that were mentioned were things like Flash, Acrobat Reader and Microsoft Office. I get my updates to Flash and Acrobat through apt, so I think it's pretty relevant. My office suite is also updated via apt, although it wasn't made by Microsoft.
It's ok to use apt and derivatives for control, even it if it's not perfect, and it isn't.
The domain that's vulnerable is Windows. As shown apt isn't very useful there, as few vendors participate in a delivery structure that keeps things up to date.
Altiris/Symantec do a respectable job-- when the patches are available, across multiple platforms. There are others.
All of those, however, are dependent on the patches being available.
All of that need is incumbent on the need to patch, meaning poor quality softwa
As a long time sysadmin and also as a programmer, I know that sysadmins generally try to draw their line of responsibilities or at least what they will take care of just below the "user installed software" level. I do have general knowledge of some of these applications and know which ones have vulnerabilities, but I usually ask that the programmer or user of the software maintain it. Although they seldom do and then ask for help when something gets hacked.
Perhaps the responsibility for these apps should be in the hands of the sysadmin as well, but the number of apps you have to maintain as you go up to that level increases exponentially. Plus, since they are usually not part of the OS, your OS company is not going to provide you with an easy way to maintain them, so you either need an application administrator or you need to train the programmer/user. Companies probably don't see the point.
I was thinking of server side stuff, but that may be a good client side program.
Actually, something like that for web applications would be nice. Probably is already something, just hard to find among the barrage of apps out there.
Cassandra [purdue.edu] is probably the best resource for that, you can build a profile of the software you use, and it will alert you when a vulnerability is fixed in that software.
Also, vulnerability management/discovery software like NeXpose or Nessus also can find many similar problems, especially if you give them access credentials.
Plus, you eventually end up with a system where all applications have to be approved by the BOFH. Then, when a developer/techie who knows what he's doing needs to use a new tool to solve a problem it ends up in a 6-month queue for "approval".
Plus, you eventually end up with a system where all applications have to be approved by the BOFH. Then, when a developer/techie who knows what he's doing needs to use a new tool to solve a problem it ends up in a 6-month queue for "approval".
What actually happens is that the user complains to Heap Big Boss (board-level or equivalent) and they instruct the poor BOFH to approve their pet project immediately or find another job. It's a really bad idea to be the person who says "no" to another person doing their job, especially if they have the ear of higher up (and most users will only deliberately use a new app if it is something dictated from on high; the rest of the time they'll cling to old stuff far more than a BOFH would).
My place of employment is lucky to have our "patch management" guy. He is absolutely fanatical about keeping up-to-date on patches for OS and apps, anti-virus updates, and anti-malware updates. I make sure that I tell upper management about him every chance I get so he continues to be properly compensated. He would be difficult to replace. In fact, I doubt I would find another person with his level of dedication, which is kind of sad.
I run a network of linux machines (debian/ubuntu/gentoo) and find it very easy to keep everything up to date, every midnight our mirror server pulls down the latest package lists for the 3 distros, every 3am every box pulls the latest package list from our mirror server (and we log any boxes that fail to do so), then at 8am every box is polled by nagios to see if it requires any updates and an email alert is sent... By the time i get to work at 9am, there may or may not be a list of systems and packages whi
every box pulls the latest package list from our mirror server (and we log any boxes that fail to do so), then at 8am every box is polled by nagios to see if it requires any updates and an email alert is sent...
That is nice and all, but gathering the latest updates is the easiest part. There are tools for every major OS to do that, often many different tools. The difficult part, and the reason many companies have difficulty keeping up with patch releases are the logistics involved with applying updates - the testing (you _will_ be bit eventually, this pays off), keeping them consistent, rebooting them, restarting apps, outage notifications, failover preparations, etc. There are always gotchas in a large environ
No, no, nooooo. I just appreciate him for his - uh - skills in the patch managem...dammit. If any of you douchers says "bromance" I'm kicking your ass. Now I'm off to the Monster Truck rally.
I had this discussion -- and yes, it was civil -- on deadly.org a while ago. Pointing out that web servers were like the circus coming to town. Setting up Linux was like using strong wooden poles to hold the tent, and using OpenBSD was like using steel poles.
Neither really mattered because people who wanted to cause trouble would simply be slitting the fabric (the apps) or cutting the ropes. Thus, a lot of the nit picky little stuff that OpenBSD fanboys focus on vs Linux doesn't really matter. The issue isn't Linux or OpenBSD or Windows, it is now mostly.ASP,.PHP and other homebrew web code where people didn't sanitize input, do bounds checking, etc.
That's a really great post. It reminds me that any OS which grants their users freedom for their apps to do what they like also grants the freedom for some app running on them to do bad things, whether it effects the OS or not. It will always be like that.
The only solutions I can think of are to 1) create programming languages that result in really secure code through lots of input restrains etc. 2) create a lot of transparency to see what's going on. And even those don't do enough: A language with too much
A language with too much checking will be slow (Java has a much better security name in this department than C for instance)
The best way to do this is to have all the requirements and guarantees written in the code, right down to the low-level, and then to have a compiler that can remove explicit checks once it proves that they're not necessary. This is the sort of idea behind a language like Eiffel. (And the cost of checking at runtime for buffer overflow and other things like that is actually not that high. A lot of the time, you can compensate by building/using a proper high-quality buffer management lib rather than rolling y
when PHP gets popped (is there really any other culprit these days?), the OS is still untouched
So what?
Today, the PHP service that got popped was running on the... PHP server. Is the OS important when someone snarfs up your web app and all data it had access to? Are you keeping unnecessary sensitive data on your PHP server? I hope not, but sure.. MAYBE it would be protected if your OS was secure.
In your analogy, it's like the tent poles of the "windows" tent are made of cardboard tubes... they might hold up due to the imbalance of newly torn cloth, or they might not.
You're completely missing the point. If someone tears through your tent, its game over, circus down. Nobody gives a damn about tearing your poles down, they have better ones at home.
Is the OS important when someone snarfs up your web app and all data it had access to?
Depends on how long you want to spend in doing recovery. If I have incremental copies (in addition to normal backup/DR actions) and a live copy of the DB transaction logs sitting on the local box outside of the chroot jail (and thus remain untouchable)? It is a lot easier and faster to disable the offending script (or apply the needed patch), copy over the last known good data, and be up and running - with a very short downtime.
If the OS is untrusted, you get to rebuild the entire - which means you get to r
Today, the PHP service that got popped was running on the... PHP server. Is the OS important when someone snarfs up your web app and all data it had access to?
Yes, it's very important. To extend your analogy a little, with Microsoft all the goodies are sitting on open tables inside the big tent so a tear in the big tent generally allows complete access to all the goodies. With linux there are locked covered cubicles inside the tent that you can keep the goodies in. If the goodies are kept in the cubicles, as they should be, it's much harder to get at them even after you tear through the outside tent. With OpenBSD there are steel cubicles for the goodies.
The security model of PHP in Windows is still pretty bad.
The default install of PHP can let a user put files in a web site that can compromise or infect the operating system.
Plus, a lot of third party add-ons for PHP want you to add "read/execute" to CMD.exe and put it in the PATH to the PHP services to piggy back their apps into working. Which, is well, stupid.
Maybe on Linux PHP is no harm to the OS, but on MS boxes that is not a safe assumption to make.
Maybe on Linux PHP is no harm to the OS, but on MS boxes that is not a safe assumption to make.
PHP is a problem, but if you're properly paranoid you can avoid most of the problems. Removing from your production webserver all things like wget that can download a rootkit is a good start. You also don't want to have compilers on those systems. It also helps if you crucify any web developer who puts an "email a friend" form up. (Careful firewalling can help detect when such idiots have been about; you don't have to wait for your server to appear in one of the spam blacklists...)
SANS found that most organizations are focusing their patching efforts and vulnerability scanning on the operating system, but they're missing the boat
They make it sound as if it's the fault of the client companies. In fact they probably apply all the security patches they get from their suppliers. If most of them come from the O/S vendors and relatively few come from the application vendors - you can hardly blame their cleints.
Maybe SANS should, instead, be asking why application vendors are so tardy about providing fixes for the vulnerabilities that SANS seem to think are the most exploited? Of course, the answer would be that the baddies focus their efforts on the weakest link, which is why more attacks target the (weak) applications than the better supported operating systems.
They did also mention vulnerability scanning to the patching when saying companies were focusing in the wrong place. This means a company can say "We scanned that box with X app and found no X OS holes" when in all reality they are running vulnerable versions of Y and Z apps and the companies scan didn't pick that up because they were focusing on OS vulnerabilities.
There are also many companies that while being diligent on patching their OS's, they are not so quick to apply application patches when they ar
I don't think the problem is lack of application patches being provided, but the lack of them being delivered well.
The problem as I see it is there is no good method of application patch delivery on Windows (And Mac for that matter). On Linux and BSD, you have package managers built into the distro that handles everything from the repositories (either the distro repositories or the application's repositories). On Windows, there is no such thing (Yes, there package managers available, but they are not included stock and aren't widely used) and every application has to handle things itself, either by checking on startup or adding yet another background process taking up resources, both of which are decidedly non-optimal solutions.
In the former, with infrequently used apps (Stuff like Adobe Reader comes to mind), you're going to have infrequent (and thus large) updates, which would result in something like "What? A 15MB update? I don't have time for that, I need to read this PDF." with the obvious consequences or the file being opened before the update option is presented, with the same result.
Usually the "lowly" task of patching is sloughed off onto the sysadmins, while the developers in their hubris think there's nothing wrong with anything they wrote. OS/app patches are easily obtained and applied because many people use them. In house apps take a lot more resources to analyze and patch, and add the previously-mentioned hubris and you have a situation where resources will never be spent patching the in-house apps, because it's not their problem anyway.
Most companies I have worked for will overly lock down one area of security (ex. overly tight settings on web browsing)and completely ignore all other forms of security (ex. employee ability to install unlicensed SW on local PC). I can't say I've ever seen any of them install a patch for MS Office unless I did it myself on an individual machine. I'm sure the cost of manpower hours far outweighs the risk in most CFO's minds (CIOs probably look at it differently but don't get the final say). I've also noticed
Patching msoffice is a pain, installing updates can actually break document compatibility with unpatched versions... Also unless you install something like wsus, you can't patch them easily.. Third party apps are another big problem, because there is no standard centralised way to patch them at all that doesn't cost a lot of money.
These are just some of the hidden costs of running windows, that are often overlooked and cause problems as a result (by contrast, linux typically has such functionality out of the
Always telling you what you're doing wrong, never telling you how to do it right.
How do you serve up the content and services end-users expect without the security risks? Simple answer: You can't.
Unless you're writing your own operating system and rolling your own PDF viewers and office suite and publishing your own flash-like plug-in that no one will ever want to install, you'll end up running around like a chicken with it's head cut off every once in a while because of fucking adobe, fucking bill, fucking
The problem is that while there are solutions, they often won't be considered for various reasons...
There are expensive patch management systems for windows, but they are often extremely expensive and typically complex to manage.
There is the option of moving to linux, where on any modern distro it's easy to keep all your applications up to date with patches, but people are either locked in to windows applications, afraid to try something new or simply have no knowledge of linux.
I would say that the benefits are a lot more than the 1.9% you mention, and if done correctly actually requires *less* work... I keep a small network of linux boxes fully up to date and spend very little time doing so, while other people managing a similar sized windows network tend to lag behind badly (especially on third party apps). I have the package manager update its package list daily, and alert me if theres any needed updates.
If a medium is presented that interacts with something it must be patched! The more prevalent the medium, the higher the level of patching required.
Whether that medium is email, your browser, the OS, office or the like should not matter. It doesn't matter if a new killer app comes out, if it interacts with your computers, you need to patch it for security issues on a routine basis.
Really, the OS, vendor, and the rest don't matter, what matters is that routine patching is done. At first people were surprised
This would have been so much easier to understand with a proper/. car analogy.
Here you go:
It's like locking your car doors and keeping up with the manufacturer recall notices, but ignoring that the remote start system you had installed uses an unencrypted signal.
Patching Windows is the main focus because it is the best bang for the buck. There are many tools to automate this process (Active Directory, Group Policy, SUS). There are no tools to automatically discover XSRF, XSS, and Injection attacks in your custom web apps, then write patches for them, then deploy and manage those patches. That's orders of magnitude more expensive.
When you have limited resources, you will just go for the lowest-hanging fruit. Obviously.
People are the ultimate vulnerability. And that goes from applying the same solution for all problems (that desktop environment looks nice for personal trusted use, lets use it to let it run for hundreds of untrusted ones), to opening attachments, to confusing authority with knowledge (i am the boss and want full access to internet and all the corporate servers) to admins and thousands of etcs. The security suite to solve it is education and common sense. One takes too long to get, while the other could take
A lot of the "professionals" are fairly incompetent, and you can bet that big vendors (especially ms) would corrupt the process to ensure that you can only be licensed if you only install their products.
I've found through the years, that enthusiasts who taught themselves, learned through experience and had a genuine interest in computing tend to be very good at what they do, whereas people who attended training courses and got certifications generally were only interested in the money they could earn from a
Most type of exploit is 'other' (Score:3, Funny)
Re: (Score:2, Insightful)
SANS' Ullrich says patching third-party applications isn't easy. "Third-party applications can be tough. There's no good system" for patching them, he says. The key is inventorying third-party Web applications, which the report shows are a major attack vector, Ullrich says.
It's called apt. It's already widely deployed in Debian and Ubuntu, and has been for a long time. The problem is solved.
Re: (Score:2)
Protip - we're talking about business computers. Business Computers == WindowsXP (to a first approximation).
Re: (Score:3, Interesting)
Business Computers == WindowsXP
I guess we're one of the approximations. ;) Our office is more Ubuntu than Windows and people, astonishing to the Windows faithful, don't have any trouble getting their work done.
Almost any office could replace many, if not most, of their desktops with Ubuntu with very little difficulty. The level of effort increases to another level if you want to try replacing all of them.
Imagine having APT for a large percentage of your desktops. A couple keystrokes to run a script
Re: (Score:2)
It's called apt. It's already widely deployed in Debian and Ubuntu, and has been for a long time. The problem is solved.
What proportion of third party vendors distribute their software using apt ?
Re: (Score:2)
As with operating systems, it tends to be the commercial vendors who don't produce and distribute packages in the standard way, instead preferring to use their own nonstandard installer which doesn't integrate with the existing mechanisms for keeping things up to date.
I would consider lack of integration with the standard update system to be a big black mark against something when evaluating it relative to possible other options.
Incidentally, Nokia use apt on their maemo platform, which includes the new N90
Re: (Score:3, Interesting)
Yeah, and if they were honest and serious that's were they would have said, "third-party applications can be tough. There are very good systems for patching them, like Debian's APT, but sadly most vendors of proprietary software have made practically no progress in this area in two decades".
Re: (Score:3, Interesting)
The claim that there is no good system is just the sort of claim that gets quoted out of context, and when it happens, supposedly expert technical people will be the ones making the mistakes.
Think of it like politics. Someone writes a story specifically about the Democratic party in Ohio. Five paragraphs in, they say "There are no particularly distinguished front runners for the upcoming election.". What happens when that gets quoted by itself - is there much chance at all that someone
Re: (Score:2)
I also forgot to read all the disclaimers that tell me that no one is responsible for anything.
Re: (Score:3, Informative)
No, I didn't forget to read it. It wasn't there. "Microsoft OS", "Windows", these were not mentioned in the article nor in the report. Things that were mentioned were things like Flash, Acrobat Reader and Microsoft Office. I get my updates to Flash and Acrobat through apt, so I think it's pretty relevant. My office suite is also updated via apt, although it wasn't made by Microsoft.
Re: (Score:2)
It's ok to use apt and derivatives for control, even it if it's not perfect, and it isn't.
The domain that's vulnerable is Windows. As shown apt isn't very useful there, as few vendors participate in a delivery structure that keeps things up to date.
Altiris/Symantec do a respectable job-- when the patches are available, across multiple platforms. There are others.
All of those, however, are dependent on the patches being available.
All of that need is incumbent on the need to patch, meaning poor quality softwa
From the "No Duh" department... (Score:5, Funny)
Wait, let me get this straight... Attackers are going after the things that aren't getting fixed as quickly? Who would have guessed!
The problem is in job responsibility (Score:5, Insightful)
As a long time sysadmin and also as a programmer, I know that sysadmins generally try to draw their line of responsibilities or at least what they will take care of just below the "user installed software" level. I do have general knowledge of some of these applications and know which ones have vulnerabilities, but I usually ask that the programmer or user of the software maintain it. Although they seldom do and then ask for help when something gets hacked.
Perhaps the responsibility for these apps should be in the hands of the sysadmin as well, but the number of apps you have to maintain as you go up to that level increases exponentially. Plus, since they are usually not part of the OS, your OS company is not going to provide you with an easy way to maintain them, so you either need an application administrator or you need to train the programmer/user. Companies probably don't see the point.
Parent
Re:The problem is in job responsibility (Score:5, Informative)
For commonly used applications that make the CSV lists I find the Personal Software Inspector an excellent tool.
http://secunia.com/vulnerability_scanning/personal/ [secunia.com]
Amazing how many userland applications out there have some kind of exploit against them : /
Parent
Re: (Score:2)
I was thinking of server side stuff, but that may be a good client side program.
Actually, something like that for web applications would be nice. Probably is already something, just hard to find among the barrage of apps out there.
Re: (Score:3, Informative)
Cassandra [purdue.edu] is probably the best resource for that, you can build a profile of the software you use, and it will alert you when a vulnerability is fixed in that software.
Secunia of course offers commercial tools, but I've never used them, so not sure how useful they are.
http://secunia.com/advisories/business_solutions/ [secunia.com]
Also, vulnerability management/discovery software like NeXpose or Nessus also can find many similar problems, especially if you give them access credentials.
Re: (Score:2)
Of course, none of the above finds publicly unknown bugs such as you'd have in custom apps, that's a whole different suite of tools/professionals..
Re: (Score:2)
Re: (Score:3, Interesting)
Plus, you eventually end up with a system where all applications have to be approved by the BOFH. Then, when a developer/techie who knows what he's doing needs to use a new tool to solve a problem it ends up in a 6-month queue for "approval".
What actually happens is that the user complains to Heap Big Boss (board-level or equivalent) and they instruct the poor BOFH to approve their pet project immediately or find another job. It's a really bad idea to be the person who says "no" to another person doing their job, especially if they have the ear of higher up (and most users will only deliberately use a new app if it is something dictated from on high; the rest of the time they'll cling to old stuff far more than a BOFH would).
We are just lucky I guess (Score:3, Informative)
Re: (Score:3, Funny)
Re: (Score:3, Funny)
Re: (Score:2)
That's awesome, man. Good on him for doing his job, and good on you for making sure that management knows it.
I think that, all too often, people who don't work in tech don't understand how much work there can be in tech.
Re: (Score:2)
I run a network of linux machines (debian/ubuntu/gentoo) and find it very easy to keep everything up to date, every midnight our mirror server pulls down the latest package lists for the 3 distros, every 3am every box pulls the latest package list from our mirror server (and we log any boxes that fail to do so), then at 8am every box is polled by nagios to see if it requires any updates and an email alert is sent... By the time i get to work at 9am, there may or may not be a list of systems and packages whi
Re: (Score:2)
every box pulls the latest package list from our mirror server (and we log any boxes that fail to do so), then at 8am every box is polled by nagios to see if it requires any updates and an email alert is sent...
That is nice and all, but gathering the latest updates is the easiest part. There are tools for every major OS to do that, often many different tools. The difficult part, and the reason many companies have difficulty keeping up with patch releases are the logistics involved with applying updates - the testing (you _will_ be bit eventually, this pays off), keeping them consistent, rebooting them, restarting apps, outage notifications, failover preparations, etc. There are always gotchas in a large environ
Re:We are just lucky I guess (Score:5, Funny)
Parent
OpenBSD vs Linux (Score:5, Insightful)
I had this discussion -- and yes, it was civil -- on deadly.org a while ago. Pointing out that web servers were like the circus coming to town. Setting up Linux was like using strong wooden poles to hold the tent, and using OpenBSD was like using steel poles.
Neither really mattered because people who wanted to cause trouble would simply be slitting the fabric (the apps) or cutting the ropes. Thus, a lot of the nit picky little stuff that OpenBSD fanboys focus on vs Linux doesn't really matter. The issue isn't Linux or OpenBSD or Windows, it is now mostly .ASP, .PHP and other homebrew web code where people didn't sanitize input, do bounds checking, etc.
Re: (Score:3, Interesting)
That's a really great post. It reminds me that any OS which grants their users freedom for their apps to do what they like also grants the freedom for some app running on them to do bad things, whether it effects the OS or not. It will always be like that.
The only solutions I can think of are to 1) create programming languages that result in really secure code through lots of input restrains etc. 2) create a lot of transparency to see what's going on. And even those don't do enough: A language with too much
Re: (Score:2)
A language with too much checking will be slow (Java has a much better security name in this department than C for instance)
The best way to do this is to have all the requirements and guarantees written in the code, right down to the low-level, and then to have a compiler that can remove explicit checks once it proves that they're not necessary. This is the sort of idea behind a language like Eiffel. (And the cost of checking at runtime for buffer overflow and other things like that is actually not that high. A lot of the time, you can compensate by building/using a proper high-quality buffer management lib rather than rolling y
Re: (Score:2)
Setting up Linux was like using strong wooden poles to hold the tent, and using OpenBSD was like using steel poles.
Linux + GRSec [grsecurity.org] + RBAC + PIE + SSP + etc etc = much much tougher.
Re: (Score:3, Insightful)
when PHP gets popped (is there really any other culprit these days?), the OS is still untouched
So what?
Today, the PHP service that got popped was running on the... PHP server. Is the OS important when someone snarfs up your web app and all data it had access to?
Are you keeping unnecessary sensitive data on your PHP server? I hope not, but sure.. MAYBE it would be protected if your OS was secure.
In your analogy, it's like the tent poles of the "windows" tent are made of cardboard tubes... they might hold up due to the imbalance of newly torn cloth, or they might not.
You're completely missing the point. If someone tears through your tent, its game over, circus down. Nobody gives a damn about tearing your poles down, they have better ones at home.
Re: (Score:2, Informative)
Is the OS important when someone snarfs up your web app and all data it had access to?
Depends on how long you want to spend in doing recovery. If I have incremental copies (in addition to normal backup/DR actions) and a live copy of the DB transaction logs sitting on the local box outside of the chroot jail (and thus remain untouchable)? It is a lot easier and faster to disable the offending script (or apply the needed patch), copy over the last known good data, and be up and running - with a very short downtime.
If the OS is untrusted, you get to rebuild the entire - which means you get to r
Re: (Score:3, Informative)
Today, the PHP service that got popped was running on the... PHP server. Is the OS important when someone snarfs up your web app and all data it had access to?
Yes, it's very important. To extend your analogy a little, with Microsoft all the goodies are sitting on open tables inside the big tent so a tear in the big tent generally allows complete access to all the goodies. With linux there are locked covered cubicles inside the tent that you can keep the goodies in. If the goodies are kept in the cubicles, as they should be, it's much harder to get at them even after you tear through the outside tent. With OpenBSD there are steel cubicles for the goodies.
Re: (Score:3, Interesting)
The default install of PHP can let a user put files in a web site that can compromise or infect the operating system.
Plus, a lot of third party add-ons for PHP want you to add "read/execute" to CMD.exe and put it in the PATH to the PHP services to piggy back their apps into working. Which, is well, stupid.
Maybe on Linux PHP is no harm to the OS, but on MS boxes that is not a safe assumption to make.
Re: (Score:2)
Maybe on Linux PHP is no harm to the OS, but on MS boxes that is not a safe assumption to make.
PHP is a problem, but if you're properly paranoid you can avoid most of the problems. Removing from your production webserver all things like wget that can download a rootkit is a good start. You also don't want to have compilers on those systems. It also helps if you crucify any web developer who puts an "email a friend" form up. (Careful firewalling can help detect when such idiots have been about; you don't have to wait for your server to appear in one of the spam blacklists...)
Can only apply the patches you get (Score:3, Interesting)
SANS found that most organizations are focusing their patching efforts and vulnerability scanning on the operating system, but they're missing the boat
They make it sound as if it's the fault of the client companies. In fact they probably apply all the security patches they get from their suppliers. If most of them come from the O/S vendors and relatively few come from the application vendors - you can hardly blame their cleints.
Maybe SANS should, instead, be asking why application vendors are so tardy about providing fixes for the vulnerabilities that SANS seem to think are the most exploited? Of course, the answer would be that the baddies focus their efforts on the weakest link, which is why more attacks target the (weak) applications than the better supported operating systems.
Re: (Score:2)
There are also many companies that while being diligent on patching their OS's, they are not so quick to apply application patches when they ar
Re:Can only apply the patches you get (Score:4, Interesting)
I don't think the problem is lack of application patches being provided, but the lack of them being delivered well.
The problem as I see it is there is no good method of application patch delivery on Windows (And Mac for that matter). On Linux and BSD, you have package managers built into the distro that handles everything from the repositories (either the distro repositories or the application's repositories). On Windows, there is no such thing (Yes, there package managers available, but they are not included stock and aren't widely used) and every application has to handle things itself, either by checking on startup or adding yet another background process taking up resources, both of which are decidedly non-optimal solutions.
In the former, with infrequently used apps (Stuff like Adobe Reader comes to mind), you're going to have infrequent (and thus large) updates, which would result in something like "What? A 15MB update? I don't have time for that, I need to read this PDF." with the obvious consequences or the file being opened before the update option is presented, with the same result.
Parent
pointing fingers (Score:2)
Security through head in sand (Score:2)
Most companies I have worked for will overly lock down one area of security (ex. overly tight settings on web browsing)and completely ignore all other forms of security (ex. employee ability to install unlicensed SW on local PC). I can't say I've ever seen any of them install a patch for MS Office unless I did it myself on an individual machine. I'm sure the cost of manpower hours far outweighs the risk in most CFO's minds (CIOs probably look at it differently but don't get the final say). I've also noticed
Re: (Score:2)
Patching msoffice is a pain, installing updates can actually break document compatibility with unpatched versions... Also unless you install something like wsus, you can't patch them easily..
Third party apps are another big problem, because there is no standard centralised way to patch them at all that doesn't cost a lot of money.
These are just some of the hidden costs of running windows, that are often overlooked and cause problems as a result (by contrast, linux typically has such functionality out of the
Insecurity Experts (Score:2, Insightful)
Always telling you what you're doing wrong, never telling you how to do it right.
How do you serve up the content and services end-users expect without the security risks?
Simple answer: You can't.
Unless you're writing your own operating system and rolling your own PDF viewers and office suite and publishing your own flash-like plug-in that no one will ever want to install, you'll end up running around like a chicken with it's head cut off every once in a while because of fucking adobe, fucking bill, fucking
Re:Insecurity Experts (Score:4, Insightful)
The problem is that while there are solutions, they often won't be considered for various reasons...
There are expensive patch management systems for windows, but they are often extremely expensive and typically complex to manage.
There is the option of moving to linux, where on any modern distro it's easy to keep all your applications up to date with patches, but people are either locked in to windows applications, afraid to try something new or simply have no knowledge of linux.
I would say that the benefits are a lot more than the 1.9% you mention, and if done correctly actually requires *less* work... I keep a small network of linux boxes fully up to date and spend very little time doing so, while other people managing a similar sized windows network tend to lag behind badly (especially on third party apps). I have the package manager update its package list daily, and alert me if theres any needed updates.
Parent
IE6 (Score:4, Funny)
It's really simple (Score:2)
If a medium is presented that interacts with something it must be patched! The more prevalent the medium, the higher the level of patching required.
Whether that medium is email, your browser, the OS, office or the like should not matter. It doesn't matter if a new killer app comes out, if it interacts with your computers, you need to patch it for security issues on a routine basis.
Really, the OS, vendor, and the rest don't matter, what matters is that routine patching is done. At first people were surprised
Too confusing (Score:2)
Re: (Score:2, Interesting)
This would have been so much easier to understand with a proper /. car analogy.
Here you go:
It's like locking your car doors and keeping up with the manufacturer recall notices, but ignoring that the remote start system you had installed uses an unencrypted signal.
duh? (Score:3, Insightful)
Patching Windows is the main focus because it is the best bang for the buck. There are many tools to automate this process (Active Directory, Group Policy, SUS). There are no tools to automatically discover XSRF, XSS, and Injection attacks in your custom web apps, then write patches for them, then deploy and manage those patches. That's orders of magnitude more expensive.
When you have limited resources, you will just go for the lowest-hanging fruit. Obviously.
PEBKAC (Score:2)
The security suite to solve it is education and common sense. One takes too long to get, while the other could take
Re: (Score:3, Insightful)
A lot of the "professionals" are fairly incompetent, and you can bet that big vendors (especially ms) would corrupt the process to ensure that you can only be licensed if you only install their products.
I've found through the years, that enthusiasts who taught themselves, learned through experience and had a genuine interest in computing tend to be very good at what they do, whereas people who attended training courses and got certifications generally were only interested in the money they could earn from a