Not reacting immediately to advanced, targeted intruders is standard tactics, and recommended by most experts in the field. This is news to Slashdot because folks here usually only deal with mass criminal attacks, which are a different beast entirely.
This isn't a DHS conspiracy, not even one for new funding. It's just the government advocating reasonable measure even though I'm sure they knew they'd get pilloried for it. I rarely respect the DHS, but in this case I may make an exception.
An architecture is superior for a given purpose, or judged by a particular standard. There isn't some magic score card which can declare an architecture to be plainly superior.
HURD will be clean. Plan9 was clean (and I have a fondness for it). I also prototype some logic in Haskell but know full well why most production code isn't written in it.
Linux is a bit of a mess. So is BSD. So is every general purpose operating system that has ever been fielded for a significant period. The warts come from being adapted to serve many different purposes, and working around many real world problems that clean-room architecture gets to just ignore. And getting some of it wrong and only fixing some of it halfway because it turns out that in real deployments (not just "the market"), clean isn't the most important thing people need from an OS.
Building a fresh OS, even over two decades, is impressive. Most Slashdotters couldn't do it. But, seriously, many research OS's have been written and shelved since HURD was started, and none of them have run around insisting they were the second coming. HURD has some neat ideas. But it's getting mocked because it's been presented with the kind of pretension and arrogance you only get away with if you deliver perfectly and on time.
This is an old problem in high assurance systems. As other posters have pointed out, as some point you have to trust someone. But you can still "trust but verify".
The standard solution is "division of privilege". Over time folks have learned that the key is a system which audits everything the admin does, and the one thing the admin can't do is modify or delete the audit trail. A separate person or team has the role of auditor.
This is one of the requirements of a B2 level system in the old Orange Book model, and you'll see if it as a requirement if you need to provide systems for most countries' military or intelligence organizations. It's rarely used elsewhere because more or less noone else is willing to pay the staffing costs. The solution there is trust someone, and be ready to fire, sue, and/or prosecute if they violate that trust.
If she had broken and entered, destroyed some property, changed locks, sabotaged, say, manufacturing systems so they would need repair before normal business operations could continue, and falsified documents (fraud), you think she would have gotten a _smaller_ sentence?
I'm at a very different moment in life than you are, but several years ago I had a severe panic attack "out of the blue" while managing a large project. Once I'd understood what was going on, I responded like a good little geek and checked out the research on panic attacks.
While you should definitely seek the help of a professional, as you can dangerously misdiagnose yourself, the most likely cause is a high level of stress that you haven't been managing. Anxiety disorders in general become progressively harder to treat the longer you live with them, so don't try to just tough this out.
If you need it, a psychiatrist may be able to prescribe medication which can provide short term relief. Far more effective over the long term will be to engage in some cognitive therapy and learn to recognize the early symptoms that you are not managing stress and respond to them before your stress results in anxiety.
I would recommend the site www.anxieties.com as a good place to start. It's run by a respected clinician in the field, and while the site advertises plenty of materials you could pay for, it has a fair amount of information and advice available for free.
The good news is that if you take this seriously, respond quickly, and learn to comprehensively manage your stress, then your odds of avoiding a chronic anxiety disorder are quite good.
Tying agreements were made illegal in the US by the Clayton Act of 1914 (I believe this predates most European anti-trust law, but I'm hardly an expert here). That doesn't mean, of course, that anti-trust is enforced in a way which does what a non-laywer would expect based on the language of the statute. There's been almost a century for complicating and confusing case law to build up.
I work in a coding shop where the average age is over 40. We work in an industry where bugs have more significant repercussions than in most. Management responds to this by making sure to hire people who have had a chance to learn how to write quality code, and how to compensate for their own weaknesses, whatever those are.
When faced with a choice between a bright recent grad from a top engineering school with great interships and a can-do attitude vs. a forty-something engineer who's been around the block, worked on various architectures, at various levels of the system, held various roles in a team, and had to pick herself up and dust herself off after a failure or two (and who wants more money than the new grad), my VP will take the experienced programmer almost every time.
I'm under 40, and I love having all of this wisdom around to learn from. Our best, most productive coder is over 60, and he thinks so clearly and with such accumulated wisdom at an architectural level than he can see problems during the first design sketch that a clever new grad would figure out only while thinking over why he was unemployed after his product failed in the market. The young men and women on our team are very, very sharp, but brains is no substitute for brains and experience.
For those of you who haven't done Common Criteria, a few clarifications:
EAL stands for "Evaluation Assurance Level". Your EAL level describes the degree to which you demonstrated your claims. It says almost nothing about what those claims are. It's an exaggeration to say you could get EAL 4 on a brick by claiming that it would stay put when you dropped it, but not a big one.
The claims are contained in your Security Target (ST), which is a series of claims about the Target of Evaluation (ToE). Your ST doesn't necessarily have to include many claims relevant to good security, and your ToE can exclude many subsystems and capabilities of the system being certified. To use a pre-CC example, Windows NT got an Orange Book certification by specifying that the certified system could not be connected to a network.
If you want to adhere to a standard that tries to verify that your ToE includes capabilities that make your device useful and that your ST makes claims which really mean something about the security properties of device, you demonstrate compliance with a published Protection Profile (PP). In the US, there are a series of PP's published . These PP's describe relevant capabilities and security properties for systems used in various roles (for example, a traffic filter firewall for low risk environments).
Without a PP, the only way to know what that EAL 4+ actually means is to closely read the ToE and the ST to figure out just how thin they sliced the salami.
Having said all that, a tiny bit of research confirms that Microsoft actually certified these systems against the Controlled Access PP. This is a basic robustness standard (by comparison, Red Hat Linux 5 is also certified against the Labeled Security PP and the Role Based Access Control PP, which assert more robust security capabilities), but it's quite a bit more than nothing, and quite a bit more than many companies do to get their "we do Common Criteria" marketing claim.
Of course, some of us recall when 10/8 was MILnet. Every time I configure something in net 10 I feel like I should look over my shoulder for the kid with the M-16 telling me to get back behind the flight line.
Okay, you're saying that your company was willing to spend $2M to develop this, but no other company would pay more than $10K to acquire it? If you really mean that, you must think your management are complete morons to have paid you to do this. Reversing it, if it was worth $2M to your company, why is it so inconceivable that it might be worth a quarter that to someone else? I'll assume here that you hadn't really thought about it that way, and go a different direction.
Assume you're right and it's only worth $10K. Sell it to 50 customers at that price and you've made $500K. You seem to be saying that because that's less than it cost to develop, it isn't worth selling. Clearly, it wouldn't be worth developing the software from scratch for the sole purpose of selling it if those figures were accurate. But you've already made the software, and $500K is a lot more than $0, which is what you propose to earn from the software.
Your next argument is probably "it will cost us more than $500K to support it". Okay, says the VP, either we sell it as is, or we sell support contracts to cover the cost of support, or we offer support on a time and materials basis.
Basically, any way you do the analysis, if the software really can't be sold to make any money than either 1) your company was stupid to spend this much making it or 2) most of the capital value from that investment is unique to your company's business and it's worth holding onto the competitive advantage of sole use. In case 1), selling it is trying to recoup from a mistake. In case 2), selling it is a mistake, but giving it away would be an even worse one.
The clauses you're worried about may actually mean what the PHB says they mean. They may mean what you think they mean. They may mean something else. They may be entirely unenforcable in your jurisdiction, and thus not worth arguing about. I don't know, and neither do you, because YANAL.
What a contract actually means is determined not by common sense, but by relevant contract law (which you don't know) and case law (which you don't know). If you really care about what a contract is actually enforcably commiting you to, hire a lawyer.
Asking employees what they want from their manager is something any good manager should do. But it is important to remember that what they're telling you is what it looks like from their side. Listen for what frustrates them more than for what they think you should do, because frequently it's as much about how you do something as what you do.
For example, my team was frequently frustrated by sudden changes of plans from their previous manager. When I was on the team, so was I. When I asked what I should do differently, "stick with the first plan" was a frequent answer. Once I was in the hot seat it became clear to me why we frequently had to make certain changes. Since I couldn't just stop the change, instead I started explaining to people why I was asking them to do things.
This frequently takes a lot of time, and frequently involves a lot of discussion while they go over the same ground that led me to the decision. They come with a reason to change my mind much less frequently than they probably would have supposed. The upshot of this, however, is that now they see why we need to make these decisions, they have a chance to change the decision when it was really as dumb as it looked at first glance, and so they feel a little less like it is something that is done to them by unreasoning powers.
The point here, again, is that I didn't change what I was doing all that much, but I changed how I was doing it a lot.
Having taken a couple products through Common Criteria (CC) certification, I can tell you that every CC certificate out there applies only to a very specific set of patches (that's a requirement of the certiication process), and that every Protection Profile (PP) I've read is either full of holes or so tight as to make a system useless without violating the configuration spec. Admittedly, some are more full of holes than others, but your presentation makes it sound like the flaws inherent in the process are specific to Microsoft.
Another reply to this thread seemed to confute Orange Book and CC. While a CC PP can be defined to focus on protection of confidential data (and even to mimic Orange Book style MLS), that is not a basic limitation of CC. Most firewalls that are certified, for example, have PP's that cover protecting the security policy from alteration by unauthorized entities.
In fact, as a supplier of firewalls to the DoD, I can verify that they are insisting that all suppliers demonstrate IPv6 capabilities by the end of 2004. We may be only be completing our IPv6 code because the DoD demands it, but once it's in the product we'll happily sell it to all comers.
The shortage of IP addresses has been a "crisis" for over a decade now. CIDR and NAT have pretty much kept it under control, and could continue to do so for a while yet. As people have been pointing out, we only need a unique address for each personal accessory if we need end-to-end connectivity from my left shoe's inflation co-processor to every networked nipple ring in Norway.
Nonetheless, IPv6 is moving forward, and for a much simpler reason: money. The US military recently placed a deadline on IPv6 deployment, and they will no longer buy anything unless it's ready for IPv6 or its vendor promises it will be soon. Many of the key companies in the networking market need to sell to one part or another of the US DoD.
This requirement is putting IPv6 support on the development schedules of many companies that had been perpetually putting it off. Expect the US military and government to push ISPs for stronger IPv6 support so they can interoperate with their suppliers in their preferred fashion.
In other words, if you don't have a killer ap, get a killer user.
There are two numbers mentioned in the study. First, that two thirds of scientists stop significant contributions after age 30. Second, that one quarter of scientists stop significant contribution after marriage.
How did someone get from that data to the idea that marriage stops genius? Just those two pieces of data almost suggest the opposite -- if you want a 3/4 probability of continuing to contribute after 30, you'd better go get married, otherwise you'll only have a 1/3 chance.
I realize I'm playing fast and loose with the number, but I think my conclusions are much more supportable than those of the researcher or the poster.
The core of selinux was coded by Secure Computing Corporation and Network Associates. While the research divisions that coded them are composed primarily of US citizens, both companies also employ foreign nationals. So the situation for selinux is very similar to that discussed by the whistleblower in this case.
If I understand correctly (I'm not Austrailian), the sites in question are not prisons which contain Austrailian citizens who have committed crimes, but rather detention centers for unclassified immigrants who may or may not be refugees. The Austrailian government policy towards immigrants is a fairly contentious issue in Austrailian politics, which goes a long way to explain why an arts group might choose to create a game like this.
> What's the problem? It would require the owners of > all those routers to cooperate with each other. I > think that's enough to kill it right there. (Yes, > there are some technical issues as well)
Yeah, that sure sounds impossible. It's not like the owners of all those routers could even cooperate on anything as simple as passing IP traffic or maintaining distributed routing information for a world wide network with millions of hosts.
Come on people, think before you mod things up. If someone wants to give specific examples of why it's cooperation between vendors that's the problem, that's interesting, but cynical quips aren't.
Go read the IETF working group mailing lists on multicast topics from the beginning and I think you'll see that it's the geeks who've had a hard time agreeing, not the businesses.
3Com's Embedded Firewall was completed in January, before Secure Computing even started negotiations with Network Associates (who bought TIS a while back) to buy Gauntlet. So when the product was being developed, Secure Computing's sole firewall product was Sidewinder.
Not that it matters much, since EFW was developed from the ground up without use of Sidewinder source code. Much that engineers at Secure Computing have learned from being in the firewall business since 1992 informed the development process, but it is a new product, not a repackaging of Sidewinder or Gauntlet.
How do I know this? I'm an engineer on Sidewinder and spent some time on loan to the EFW project.
I manage a somewhat larger project (35 developers at two sites), and we have very few issues of the type you describe, despite aggressive development schedules. The key is in architecture and planning. If developers are really performing tasks so different from each other that they aren't already in close communication with one another, you need to ask yourself how they happen to be working in the same source file. With proper architecture and modularization, discrete tasks will naturally land in different parts of your source tree.
There will always be some cases where there's a little overlap, but if your architecture makes these overlaps rare, it becomes relatively easy to see them coming when you lay out your schedule and plan around them.
selinux was a shared project of the NSA and Secure Computing Corporation (where I am a developer on a different project). The type enforcement model used in the policy engine was originally developed at Secure, and is one of the core technologies of our BSD-based firewall, Sidewinder. While there were people inside the NSA who wanted this code to see the light of day, I'm not confident that it would have been released if the NSA had not been under a contractual obligation (to Secure) to do so. Like I said, though, I'm on a different project, and I may be being too cynical.
The BSD type enforcement code, meanwhile, is stuck in a lovely Catch 22 I'm sure it shares with lots of useful code -- there's not enough demand to release it as a discrete product, but at the same time it's valuable enough that management doesn't want to just release it to the public.
What the story in the WSJ didn't say which would explain whether this was social engineering or not was how the trojan was run from the e-mail. If it was in an attachment which needed to be extracted and run by concious choice of the user, then x0n is right that this is just an education issue for Microsoft employees.
But another likely scenario is that one of the numerous design flaws in Outlook that make it possible to execute foreign code on a machine without user action was used here. In this case blame for the incident rests firmly on Microsoft's consistently careless security design of their products, and all of this "Microsoft sucks" chanting has some specific backing here.
Which is to say that, yes, I thought before I posted this, and microsoft sucks.
It's probably worth pointing out that when Schneier wrote Applied Cryptography, which pushed crypto as the solution to security problems, he was making his living as a crypto consultant. Now he publishes Secrets & Lies, which says there is no security and the only comfort is in eternal vigilance, he's making his living running a company that sells monitoring services.
Personally, I think Bruce is an upright guy, and that what's happening here is that at each point in time he both writes about and works to address the problem he actually believes in. But it always pays to pay attention to the potential biases of your sources.
Slashdot Mirror
Not reacting immediately to advanced, targeted intruders is standard tactics, and recommended by most experts in the field. This is news to Slashdot because folks here usually only deal with mass criminal attacks, which are a different beast entirely.
This isn't a DHS conspiracy, not even one for new funding. It's just the government advocating reasonable measure even though I'm sure they knew they'd get pilloried for it. I rarely respect the DHS, but in this case I may make an exception.
Nonsense.
An architecture is superior for a given purpose, or judged by a particular standard. There isn't some magic score card which can declare an architecture to be plainly superior.
HURD will be clean. Plan9 was clean (and I have a fondness for it). I also prototype some logic in Haskell but know full well why most production code isn't written in it.
Linux is a bit of a mess. So is BSD. So is every general purpose operating system that has ever been fielded for a significant period. The warts come from being adapted to serve many different purposes, and working around many real world problems that clean-room architecture gets to just ignore. And getting some of it wrong and only fixing some of it halfway because it turns out that in real deployments (not just "the market"), clean isn't the most important thing people need from an OS.
Building a fresh OS, even over two decades, is impressive. Most Slashdotters couldn't do it. But, seriously, many research OS's have been written and shelved since HURD was started, and none of them have run around insisting they were the second coming. HURD has some neat ideas. But it's getting mocked because it's been presented with the kind of pretension and arrogance you only get away with if you deliver perfectly and on time.
This is an old problem in high assurance systems. As other posters have pointed out, as some point you have to trust someone. But you can still "trust but verify".
The standard solution is "division of privilege". Over time folks have learned that the key is a system which audits everything the admin does, and the one thing the admin can't do is modify or delete the audit trail. A separate person or team has the role of auditor.
This is one of the requirements of a B2 level system in the old Orange Book model, and you'll see if it as a requirement if you need to provide systems for most countries' military or intelligence organizations. It's rarely used elsewhere because more or less noone else is willing to pay the staffing costs. The solution there is trust someone, and be ready to fire, sue, and/or prosecute if they violate that trust.
If she had broken and entered, destroyed some property, changed locks, sabotaged, say, manufacturing systems so they would need repair before normal business operations could continue, and falsified documents (fraud), you think she would have gotten a _smaller_ sentence?
I'm at a very different moment in life than you are, but several years ago I had a severe panic attack "out of the blue" while managing a large project. Once I'd understood what was going on, I responded like a good little geek and checked out the research on panic attacks.
While you should definitely seek the help of a professional, as you can dangerously misdiagnose yourself, the most likely cause is a high level of stress that you haven't been managing. Anxiety disorders in general become progressively harder to treat the longer you live with them, so don't try to just tough this out.
If you need it, a psychiatrist may be able to prescribe medication which can provide short term relief. Far more effective over the long term will be to engage in some cognitive therapy and learn to recognize the early symptoms that you are not managing stress and respond to them before your stress results in anxiety.
I would recommend the site www.anxieties.com as a good place to start. It's run by a respected clinician in the field, and while the site advertises plenty of materials you could pay for, it has a fair amount of information and advice available for free.
The good news is that if you take this seriously, respond quickly, and learn to comprehensively manage your stress, then your odds of avoiding a chronic anxiety disorder are quite good.
Here is a pretty good site on US anti-trust law.
I work in a coding shop where the average age is over 40. We work in an industry where bugs have more significant repercussions than in most. Management responds to this by making sure to hire people who have had a chance to learn how to write quality code, and how to compensate for their own weaknesses, whatever those are.
When faced with a choice between a bright recent grad from a top engineering school with great interships and a can-do attitude vs. a forty-something engineer who's been around the block, worked on various architectures, at various levels of the system, held various roles in a team, and had to pick herself up and dust herself off after a failure or two (and who wants more money than the new grad), my VP will take the experienced programmer almost every time.
I'm under 40, and I love having all of this wisdom around to learn from. Our best, most productive coder is over 60, and he thinks so clearly and with such accumulated wisdom at an architectural level than he can see problems during the first design sketch that a clever new grad would figure out only while thinking over why he was unemployed after his product failed in the market. The young men and women on our team are very, very sharp, but brains is no substitute for brains and experience.
For those of you who haven't done Common Criteria, a few clarifications:
EAL stands for "Evaluation Assurance Level". Your EAL level describes the degree to which you demonstrated your claims. It says almost nothing about what those claims are. It's an exaggeration to say you could get EAL 4 on a brick by claiming that it would stay put when you dropped it, but not a big one.
The claims are contained in your Security Target (ST), which is a series of claims about the Target of Evaluation (ToE). Your ST doesn't necessarily have to include many claims relevant to good security, and your ToE can exclude many subsystems and capabilities of the system being certified. To use a pre-CC example, Windows NT got an Orange Book certification by specifying that the certified system could not be connected to a network.
If you want to adhere to a standard that tries to verify that your ToE includes capabilities that make your device useful and that your ST makes claims which really mean something about the security properties of device, you demonstrate compliance with a published Protection Profile (PP). In the US, there are a series of PP's published . These PP's describe relevant capabilities and security properties for systems used in various roles (for example, a traffic filter firewall for low risk environments).
Without a PP, the only way to know what that EAL 4+ actually means is to closely read the ToE and the ST to figure out just how thin they sliced the salami.
Having said all that, a tiny bit of research confirms that Microsoft actually certified these systems against the Controlled Access PP. This is a basic robustness standard (by comparison, Red Hat Linux 5 is also certified against the Labeled Security PP and the Role Based Access Control PP, which assert more robust security capabilities), but it's quite a bit more than nothing, and quite a bit more than many companies do to get their "we do Common Criteria" marketing claim.
Color me impressed.
Of course, some of us recall when 10/8 was MILnet. Every time I configure something in net 10 I feel like I should look over my shoulder for the kid with the M-16 telling me to get back behind the flight line.
Okay, you're saying that your company was willing to spend $2M to develop this, but no other company would pay more than $10K to acquire it? If you really mean that, you must think your management are complete morons to have paid you to do this. Reversing it, if it was worth $2M to your company, why is it so inconceivable that it might be worth a quarter that to someone else? I'll assume here that you hadn't really thought about it that way, and go a different direction.
Assume you're right and it's only worth $10K. Sell it to 50 customers at that price and you've made $500K. You seem to be saying that because that's less than it cost to develop, it isn't worth selling. Clearly, it wouldn't be worth developing the software from scratch for the sole purpose of selling it if those figures were accurate. But you've already made the software, and $500K is a lot more than $0, which is what you propose to earn from the software.
Your next argument is probably "it will cost us more than $500K to support it". Okay, says the VP, either we sell it as is, or we sell support contracts to cover the cost of support, or we offer support on a time and materials basis.
Basically, any way you do the analysis, if the software really can't be sold to make any money than either 1) your company was stupid to spend this much making it or 2) most of the capital value from that investment is unique to your company's business and it's worth holding onto the competitive advantage of sole use. In case 1), selling it is trying to recoup from a mistake. In case 2), selling it is a mistake, but giving it away would be an even worse one.
The clauses you're worried about may actually mean what the PHB says they mean. They may mean what you think they mean. They may mean something else. They may be entirely unenforcable in your jurisdiction, and thus not worth arguing about. I don't know, and neither do you, because YANAL.
What a contract actually means is determined not by common sense, but by relevant contract law (which you don't know) and case law (which you don't know). If you really care about what a contract is actually enforcably commiting you to, hire a lawyer.
Asking employees what they want from their manager is something any good manager should do. But it is important to remember that what they're telling you is what it looks like from their side. Listen for what frustrates them more than for what they think you should do, because frequently it's as much about how you do something as what you do.
For example, my team was frequently frustrated by sudden changes of plans from their previous manager. When I was on the team, so was I. When I asked what I should do differently, "stick with the first plan" was a frequent answer. Once I was in the hot seat it became clear to me why we frequently had to make certain changes. Since I couldn't just stop the change, instead I started explaining to people why I was asking them to do things.
This frequently takes a lot of time, and frequently involves a lot of discussion while they go over the same ground that led me to the decision. They come with a reason to change my mind much less frequently than they probably would have supposed. The upshot of this, however, is that now they see why we need to make these decisions, they have a chance to change the decision when it was really as dumb as it looked at first glance, and so they feel a little less like it is something that is done to them by unreasoning powers.
The point here, again, is that I didn't change what I was doing all that much, but I changed how I was doing it a lot.
Having taken a couple products through Common Criteria (CC) certification, I can tell you that every CC certificate out there applies only to a very specific set of patches (that's a requirement of the certiication process), and that every Protection Profile (PP) I've read is either full of holes or so tight as to make a system useless without violating the configuration spec. Admittedly, some are more full of holes than others, but your presentation makes it sound like the flaws inherent in the process are specific to Microsoft.
Another reply to this thread seemed to confute Orange Book and CC. While a CC PP can be defined to focus on protection of confidential data (and even to mimic Orange Book style MLS), that is not a basic limitation of CC. Most firewalls that are certified, for example, have PP's that cover protecting the security policy from alteration by unauthorized entities.
In fact, as a supplier of firewalls to the DoD, I can verify that they are insisting that all suppliers demonstrate IPv6 capabilities by the end of 2004. We may be only be completing our IPv6 code because the DoD demands it, but once it's in the product we'll happily sell it to all comers.
Tata Consulting Services doesn't hire Americans? I need to call an American friend of mine who works at TCS and tell her she should stop showing up.
The shortage of IP addresses has been a "crisis" for over a decade now. CIDR and NAT have pretty much kept it under control, and could continue to do so for a while yet. As people have been pointing out, we only need a unique address for each personal accessory if we need end-to-end connectivity from my left shoe's inflation co-processor to every networked nipple ring in Norway.
Nonetheless, IPv6 is moving forward, and for a much simpler reason: money. The US military recently placed a deadline on IPv6 deployment, and they will no longer buy anything unless it's ready for IPv6 or its vendor promises it will be soon. Many of the key companies in the networking market need to sell to one part or another of the US DoD.
This requirement is putting IPv6 support on the development schedules of many companies that had been perpetually putting it off. Expect the US military and government to push ISPs for stronger IPv6 support so they can interoperate with their suppliers in their preferred fashion.
In other words, if you don't have a killer ap, get a killer user.
There are two numbers mentioned in the study. First, that two thirds of scientists stop significant contributions after age 30. Second, that one quarter of scientists stop significant contribution after marriage.
How did someone get from that data to the idea that marriage stops genius? Just those two pieces of data almost suggest the opposite -- if you want a 3/4 probability of continuing to contribute after 30, you'd better go get married, otherwise you'll only have a 1/3 chance.
I realize I'm playing fast and loose with the number, but I think my conclusions are much more supportable than those of the researcher or the poster.
The core of selinux was coded by Secure Computing Corporation and Network Associates. While the research divisions that coded them are composed primarily of US citizens, both companies also employ foreign nationals. So the situation for selinux is very similar to that discussed by the whistleblower in this case.
If I understand correctly (I'm not Austrailian), the sites in question are not prisons which contain Austrailian citizens who have committed crimes, but rather detention centers for unclassified immigrants who may or may not be refugees. The Austrailian government policy towards immigrants is a fairly contentious issue in Austrailian politics, which goes a long way to explain why an arts group might choose to create a game like this.
> What's the problem? It would require the owners of
> all those routers to cooperate with each other. I
> think that's enough to kill it right there. (Yes,
> there are some technical issues as well)
Yeah, that sure sounds impossible. It's not like the owners of all those routers could even cooperate on anything as simple as passing IP traffic or maintaining distributed routing information for a world wide network with millions of hosts.
Come on people, think before you mod things up. If someone wants to give specific examples of why it's cooperation between vendors that's the problem, that's interesting, but cynical quips aren't.
Go read the IETF working group mailing lists on multicast topics from the beginning and I think you'll see that it's the geeks who've had a hard time agreeing, not the businesses.
Addressing some errors of fact:
3Com's Embedded Firewall was completed in January, before Secure Computing even started negotiations with Network Associates (who bought TIS a while back) to buy Gauntlet. So when the product was being developed, Secure Computing's sole firewall product was Sidewinder.
Not that it matters much, since EFW was developed from the ground up without use of Sidewinder source code. Much that engineers at Secure Computing have learned from being in the firewall business since 1992 informed the development process, but it is a new product, not a repackaging of Sidewinder or Gauntlet.
How do I know this? I'm an engineer on Sidewinder and spent some time on loan to the EFW project.
I manage a somewhat larger project (35 developers at two sites), and we have very few issues of the type you describe, despite aggressive development schedules. The key is in architecture and planning. If developers are really performing tasks so different from each other that they aren't already in close communication with one another, you need to ask yourself how they happen to be working in the same source file. With proper architecture and modularization, discrete tasks will naturally land in different parts of your source tree.
There will always be some cases where there's a little overlap, but if your architecture makes these overlaps rare, it becomes relatively easy to see them coming when you lay out your schedule and plan around them.
selinux was a shared project of the NSA and Secure Computing Corporation (where I am a developer on a different project). The type enforcement model used in the policy engine was originally developed at Secure, and is one of the core technologies of our BSD-based firewall, Sidewinder. While there were people inside the NSA who wanted this code to see the light of day, I'm not confident that it would have been released if the NSA had not been under a contractual obligation (to Secure) to do so. Like I said, though, I'm on a different project, and I may be being too cynical.
The BSD type enforcement code, meanwhile, is stuck in a lovely Catch 22 I'm sure it shares with lots of useful code -- there's not enough demand to release it as a discrete product, but at the same time it's valuable enough that management doesn't want to just release it to the public.
What the story in the WSJ didn't say which would explain whether this was social engineering or not was how the trojan was run from the e-mail. If it was in an attachment which needed to be extracted and run by concious choice of the user, then x0n is right that this is just an education issue for Microsoft employees.
But another likely scenario is that one of the numerous design flaws in Outlook that make it possible to execute foreign code on a machine without user action was used here. In this case blame for the incident rests firmly on Microsoft's consistently careless security design of their products, and all of this "Microsoft sucks" chanting has some specific backing here.
Which is to say that, yes, I thought before I posted this, and microsoft sucks.
It's probably worth pointing out that when Schneier wrote Applied Cryptography, which pushed crypto as the solution to security problems, he was making his living as a crypto consultant. Now he publishes Secrets & Lies, which says there is no security and the only comfort is in eternal vigilance, he's making his living running a company that sells monitoring services.
Personally, I think Bruce is an upright guy, and that what's happening here is that at each point in time he both writes about and works to address the problem he actually believes in. But it always pays to pay attention to the potential biases of your sources.