could an organisation that was threatened with such a blackmail attempt do something like this:
1) duplicate your web infrastructure on a number of different networks 2) lower the TTL on your DNS records to something more responsive 3)/if/ you are attacked, update DNS records to point to your alternate hosting (..repeat as necessary until you run out of sites or they give up)
This is under the assumption that such an attack once launched would be hard to stop and/or redirect, which is quite probably not the case, I guess.
Pretty much exactly as you said. The "momentum" of such an attack once launched is very low; a botnet-generated DDoS can be retargeted fairly quickly (in general). Worse yet, the cost to the bad guy is near-zero to add more bots or to retarget, while the cost for a threatened organization is definitely *not* zero.
For one thing you state that "you can get in from all but the most severely locked down internet kiosks". I guess you look at that as a feature, while I look at it as a malfunction. You've now extended your boundary and your risk to every poorly managed internet kiosk that any of your users use. So, you've never seen an internet kiosk in a hotel or other location that has questionable software, even obvious malware, installed?
Then, you claim "there's no risk to the corporate network". I don't know what sort of company you use, but if you think that providing a full desktop via Citrix, with access to all a user's regular internal documents and resources, to an endpoint that cannot be proved to be secure, is a "no risk" proposition then I would recommend you reconsider.
Not saying that Citrix doesn't have a place--but the authentication/authorization needs to be two-factor (not just a re-usable username/password combo) and the authenticated user should ideally only have read access and then only to less sensitive files. If someone needs the ability to modify files, or to access particularly sensitive ones, then the Citrix client just can't be proved to be providing enough assurance that the underlying OS/hardware isn't compromised. And *that* is why I have three separate laptops from three separate organizations just to be able to get my job(s) done...
Because SSL (or any kind of encryption) "costs" CPU cycles. Same reason that many sites use cookies to track what you're doing and even what you're putting into a shopping cart, but they don't turn on SSL until you're getting ready to check out.
In some long-ago world, that might have been adequate as a "risk reduction" method even though there's a significant residual risk. (Back when most folks had dial-up connections to ISPs, and ISPs were at least vaguely trust-able, and there was little routine use of wireless.) At this point, though, almost anything where there's sensitive data which is ever part of the datastream (e-commerce, user authentication, private info, etc.) needs to be encrypted the whole time--or expect that someone is capturing the data.
Much better than "an ipchains knockoff". More like "the original Application Layer Gateway". Most anything you can install today that really earns the descriptor "firewall" owes at least some debt to FWTK/Gauntlet.
My personal best day in a Tower Records was walking into the Newbury Street (Boston) location when it was almost brand spankin' new, and seeing a pallet of boxes containing the new U2 CD (waiting to be unloaded) with a sheet of paper taped to the stack...and on the paper, lo, it said, "Paddle My Bum".
I did laugh, for lo, at least 30 seconds.
Tower was good for a while there but others responding to this article have already pointed out the inability to do a useful search in B&M stores that favors Amazon (for non-top-sellers at least). Having the ability to comparison shop without leaving a chair, combined with *reviews* that might actually help, means that I haven't bought a CD at a B&M shop in 5 years other than as a Black Friday/special sale/ohcrapIforgot$specialOccasion item. Yes, I do still buy CDs in addition to MP3s from allofmp3, but not by wandering around a store hoping...
Good luck to Tower, but I wouldn't buy stock in B&M stores that can't match the advantages I noted above (and I'm not aware of any that do.)
Short answer, as a security guy by trade: It's not that simple. If one changes things to allow userland processes to bind to low-numbered ports, then that might help one part of the problem (vulnerable local processes are running with root privs) but doesn't address other parts of the problem (untrusted local users may now be able to bind to low-numbered ports [that may cause their own set of local or remote trust issues] + remote folks relying on historical practice of "privileged ports are a useful differentiator").
If it were me, I'd rather either do something combining chroot jails and dropping of capabilities, which still requires root privs for process initialization but then drops privs soon thereafter.
Overall, I note that you posted this as an AC. I'd love to know why you think that this is such a huge problem (given that there are ways to deal with it today) and why you cast aspersions at "people who don't understand what security is" when I'm not sure you do either. Ah well, I guess I'll never know. From my viewpoint, there are a lot of things that are much closer to crisis than "have we effectively removed the concept of privileged ports".
Important relevant questions: Did you read the article? Have you ever booted a fully-configured system with the SELinux extensions installed and operating? If so, what did the latter teach you about one way to deal with privileged ports?
...applies in this case, as it frequently does. Things that you don't actually need the privileges to do, you shouldn't have privileges for. You *needed* (I expect) access to the production database as part of your work. OTOH, by default I expect that most people in that organization did not actually need admin privileges on their desktops.
In general your IT department should have tried to figure out a way to empower you (give you privileges) to be able to defrag your hard disk, but part of the problem is the non-obvious ways that Windows expects privileges to be assigned. After many years of always having admin privileges for my regular work account on my company-provided laptop, I've been trying for the last several months to work with only "Power User" privileges and then use the "runas" command in a window to do things with admin privileges. It's inordinately painful.
In this case, your IT department's intentions were probably good, although the implementation leaves something to be desired...
Congrats. First sentence. You mis-spelled mis-spelling. And then you fell prey to the (unfortunately) common misconception that "alot" is one word. I'm sorry, but since your native tongue appears to be gibberish I'm not sure how to have a discussion with you.
And no, I'm not a grammar fascist and I might in fact be a knob...but your polemic above doesn't do you much credit. Did you actually read my previous post? Just curious.
This is the short-form explanation. If you somehow decide to care about this more seriously, aside from seeking professional help I would recommend that you consult the Book of Armaments...er...the *real* CC site: http://csrc.nist.gov/cc/
Each of the areas that Common Criteria cares about has an extensive set of "things in this area about which we care" that is the source of the ADO_IGS.1 (&c) items above. For a software item such as an OS, think of those as "claims".
For any area, the EAL just shows the level to which a "claim" has been examined and therefore can be proven. EAL 1 is basically "I read your marketing puff piece, and it sounds really good!". At a different extreme, EAL 5 is pretty close to "I did everything I could to review your code and attack your system, and I still couldn't get in". Unsurprisingly, most software falls somewhere in between. Surprisingly (or not), some software (particularly OSs) might go at EAL 3 or 4 but will still have holes. Why, one might ask? (!)
Unfortunately, it's because CC actually expects (but does not assume) that software authors did their jobs thoroughly--including not injecting unintentional bugs. Any bug that does not match the stated intent of a chunk of code, and which doesn't get caught on a code review (which might or might not happen during CC eval, but if it does should only repeat processes in place at the software vendor) would look to most of us like a HOLY CRAP VULNERABILITY -- but the CC process doesn't directly account for it in evaluating and certifying software. Is that a flaw? Yes. At the same time, if one wants to go out and procure an OS that supports an essential set of features related to user authentication, CC is more likely to provide an OS that implements that set. It doesn't mean that a CC-evaluated OS is the most secure, but it has a specific set of functions that can be shown to work.
I know that probably sounds like a steaming pile to some folks...but for one set of evaluation criteria, the above means that CC evaluation is good and nothing else quite takes the place. In an ideal world, CC evaluation would be only one data point in a decision to procure a product, along with other measures of effectiveness that can more truly show fitness of particular software for a particular purpose.
You appear to be a knob. You can't spell Criteria, you don't know what CC certification actually means, and you speak of "CCS Profiles" as though that's something useful...when in fact, Protection Profiles are what's useful and both *NIX and Windows can in fact comply with Protection Profiles that have been evaluated and approved (usually the evaluation of PPs is done with some support from NSA or one of the other entities interested in CC evaluation).
After further consideration: Yes! You, sir, are a knob. Please feel free to follow up if you actually have useful content to add...but I'm guessing you're just hoping for karma by posting non-useful comments like this. I'm not saying the world of Common Criteria is a particularly pretty one, but folks who don't know what things mean don't benefit anyone by posting their opinions about it.
Oh, and...I strongly prefer Solaris, Linux, and OpenBSD for important things (says he, from Windows box on network with all of the above), but I hate to see posts like this get bonus points for clueless bashing.
Please don't get me started on laws related to alcoholic beverages in the US. Let's just agree that they're not grounded in reality. At the same time, given current culture in this country and legal liabilities, I'm not going to argue that there should be a methodology to ensure that beer/wine/etc. doesn't get shipped directly to 14-year-olds without some ability by the parent to figure out what happened. (Note: If your 14-year-old child has their own credit card, and you don't look at the statements, then you should be disqualified as a parent...but that's a whole different discussion about responsiblity and accountability.)
The hard part is finding a sensible middle ground. It doesn't look as though this new USSC decision makes that happen, since the non-useful middlemen (distributors/retailers) make money out of the current situation, apparently still have a decent lobbying force, and can affect (read as: cancel) any idealistic changes to existing laws.
This ruling might be good news for some folks in the long term, but in the short term at least it doesn't help folks in Maryland (and from what I can tell most other states). The existing state laws here don't contradict the USSC requirements.
Status of Maryland state laws is that individual wineries have to pay a $10 annual license fee, and that only allows them to ship wines that aren't otherwise available locally, and then they still have to use the three-tier system (so they have to ship to a distributor/wholesaler who then ships to a retailer near me).
That's a pretty painful process, and it's not obvious that it produces a useful result. (If the wine is sold anywhere in the state, then it's not eligible for this shipping method AFAICT, even if there's nowhere within an hour's drive that stocks the wine...)
Needless to say, it's more likely that I'd have such a wine shipped to a friend in a nearby state, or just find a store in DC/VA with a better selection where I can actually buy that wine. But that doesn't address things like "wine of the month" clubs which might be nice but which simply can't comply with Maryland restrictions.
Slashdot Mirror
could an organisation that was threatened with such a blackmail attempt do something like this:
1) duplicate your web infrastructure on a number of different networks /if/ you are attacked, update DNS records to point to your alternate hosting (..repeat as necessary until you run out of sites or they give up)
2) lower the TTL on your DNS records to something more responsive
3)
This is under the assumption that such an attack once launched would be hard to stop and/or redirect, which is quite probably not the case, I guess.
Pretty much exactly as you said. The "momentum" of such an attack once launched is very low; a botnet-generated DDoS can be retargeted fairly quickly (in general). Worse yet, the cost to the bad guy is near-zero to add more bots or to retarget, while the cost for a threatened organization is definitely *not* zero.
Okay...I'll ask...
For one thing you state that "you can get in from all but the most severely locked down internet kiosks". I guess you look at that as a feature, while I look at it as a malfunction. You've now extended your boundary and your risk to every poorly managed internet kiosk that any of your users use. So, you've never seen an internet kiosk in a hotel or other location that has questionable software, even obvious malware, installed?
Then, you claim "there's no risk to the corporate network". I don't know what sort of company you use, but if you think that providing a full desktop via Citrix, with access to all a user's regular internal documents and resources, to an endpoint that cannot be proved to be secure, is a "no risk" proposition then I would recommend you reconsider.
Not saying that Citrix doesn't have a place--but the authentication/authorization needs to be two-factor (not just a re-usable username/password combo) and the authenticated user should ideally only have read access and then only to less sensitive files. If someone needs the ability to modify files, or to access particularly sensitive ones, then the Citrix client just can't be proved to be providing enough assurance that the underlying OS/hardware isn't compromised. And *that* is why I have three separate laptops from three separate organizations just to be able to get my job(s) done...
Boy do I wish I had mod points...mod parent up.
Because SSL (or any kind of encryption) "costs" CPU cycles. Same reason that many sites use cookies to track what you're doing and even what you're putting into a shopping cart, but they don't turn on SSL until you're getting ready to check out.
In some long-ago world, that might have been adequate as a "risk reduction" method even though there's a significant residual risk. (Back when most folks had dial-up connections to ISPs, and ISPs were at least vaguely trust-able, and there was little routine use of wireless.) At this point, though, almost anything where there's sensitive data which is ever part of the datastream (e-commerce, user authentication, private info, etc.) needs to be encrypted the whole time--or expect that someone is capturing the data.
Much better than "an ipchains knockoff". More like "the original Application Layer Gateway".
Most anything you can install today that really earns the descriptor "firewall" owes at least
some debt to FWTK/Gauntlet.
I wish there were a "+10, ridiculously insightful" rating.
/.
This comment is the most insightful thing I've seen on
in over a month. And me without mod points, so I'm
posting.
My personal best day in a Tower Records was walking into the Newbury Street (Boston) location when it was almost brand spankin' new, and seeing a pallet of boxes containing the new U2 CD (waiting to be unloaded) with a sheet of paper taped to the stack...and on the paper, lo, it said, "Paddle My Bum".
I did laugh, for lo, at least 30 seconds.
Tower was good for a while there but others responding to this article have already pointed out the inability to do a useful search in B&M stores that favors Amazon (for non-top-sellers at least). Having the ability to comparison shop without leaving a chair, combined with *reviews* that might actually help, means that I haven't bought a CD at a B&M shop in 5 years other than as a Black Friday/special sale/ohcrapIforgot$specialOccasion item. Yes, I do still buy CDs in addition to MP3s from allofmp3, but not by wandering around a store hoping...
Good luck to Tower, but I wouldn't buy stock in B&M stores that can't match the advantages I noted above (and I'm not aware of any that do.)
"...made no snese..."
Gesundheit.
Short answer, as a security guy by trade: It's not that simple. If one
changes things to allow userland processes to bind to low-numbered ports,
then that might help one part of the problem (vulnerable local processes
are running with root privs) but doesn't address other parts of the
problem (untrusted local users may now be able to bind to low-numbered
ports [that may cause their own set of local or remote trust issues]
+ remote folks relying on historical practice of "privileged ports are
a useful differentiator").
If it were me, I'd rather either do something combining chroot jails and
dropping of capabilities, which still requires root privs for process
initialization but then drops privs soon thereafter.
Overall, I note that you posted this as an AC. I'd love to know why
you think that this is such a huge problem (given that there are
ways to deal with it today) and why you cast aspersions at "people
who don't understand what security is" when I'm not sure you do
either. Ah well, I guess I'll never know. From my viewpoint, there
are a lot of things that are much closer to crisis than "have we
effectively removed the concept of privileged ports".
Important relevant questions: Did you read the article? Have you
ever booted a fully-configured system with the SELinux extensions
installed and operating? If so, what did the latter teach you
about one way to deal with privileged ports?
...applies in this case, as it frequently does. Things that you don't actually need the privileges to do, you shouldn't have privileges for. You *needed* (I expect) access to the production database as part of your work. OTOH, by default I expect that most people in that organization did not actually need admin privileges on their desktops.
In general your IT department should have tried to figure out a way to empower you (give you privileges) to be able to defrag your hard disk, but part of the problem is the non-obvious ways that Windows expects privileges to be assigned. After many years of always having admin privileges for my regular work account on my company-provided laptop, I've been trying for the last several months to work with only "Power User" privileges and then use the "runas" command in a window to do things with admin privileges. It's inordinately painful.
In this case, your IT department's intentions were probably good, although the implementation leaves something to be desired...
Congrats. First sentence. You mis-spelled mis-spelling. And then you fell prey to the (unfortunately) common misconception that "alot" is one word. I'm sorry, but since your native tongue appears to be gibberish I'm not sure how to have a discussion with you.
And no, I'm not a grammar fascist and I might in fact be a knob...but your polemic above doesn't do you much credit. Did you actually read my previous post? Just curious.
This is the short-form explanation. If you somehow decide to care about this more seriously, aside from seeking professional help I would recommend that you consult the Book of Armaments...er...the *real* CC site: http://csrc.nist.gov/cc/
Each of the areas that Common Criteria cares about has an extensive set of "things in this area about which we care" that is the source of the ADO_IGS.1 (&c) items above. For a software item such as an OS, think of those as "claims".
For any area, the EAL just shows the level to which a "claim" has been examined and therefore can be proven. EAL 1 is basically "I read your marketing puff piece, and it sounds really good!". At a different extreme, EAL 5 is pretty close to "I did everything I could to review your code and attack your system, and I still couldn't get in". Unsurprisingly, most software falls somewhere in between. Surprisingly (or not), some software (particularly OSs) might go at EAL 3 or 4 but will still have holes. Why, one might ask? (!)
Unfortunately, it's because CC actually expects (but does not assume) that software authors did their jobs thoroughly--including not injecting unintentional bugs. Any bug that does not match the stated intent of a chunk of code, and which doesn't get caught on a code review (which might or might not happen during CC eval, but if it does should only repeat processes in place at the software vendor) would look to most of us like a HOLY CRAP VULNERABILITY -- but the CC process doesn't directly account for it in evaluating and certifying software. Is that a flaw? Yes. At the same time, if one wants to go out and procure an OS that supports an essential set of features related to user authentication, CC is more likely to provide an OS that implements that set. It doesn't mean that a CC-evaluated OS is the most secure, but it has a specific set of functions that can be shown to work.
I know that probably sounds like a steaming pile to some folks...but for one set of evaluation criteria, the above means that CC evaluation is good and nothing else quite takes the place. In an ideal world, CC evaluation would be only one data point in a decision to procure a product, along with other measures of effectiveness that can more truly show fitness of particular software for a particular purpose.
You appear to be a knob. You can't spell Criteria, you don't know what CC certification actually means, and you speak of "CCS Profiles" as though that's something useful...when in fact, Protection Profiles are what's useful and both *NIX and Windows can in fact comply with Protection Profiles that have been evaluated and approved (usually the evaluation of PPs is done with some support from NSA or one of the other entities interested in CC evaluation).
After further consideration: Yes! You, sir, are a knob. Please feel free to follow up if you actually have useful content to add...but I'm guessing you're just hoping for karma by posting non-useful comments like this. I'm not saying the world of Common Criteria is a particularly pretty one, but folks who don't know what things mean don't benefit anyone by posting their opinions about it.
Oh, and...I strongly prefer Solaris, Linux, and OpenBSD for important things (says he, from Windows box on network with all of the above), but I hate to see posts like this get bonus points for clueless bashing.
Please don't get me started on laws related to alcoholic beverages in the US. Let's just agree that they're not grounded in reality. At the same time, given current culture in this country and legal liabilities, I'm not going to argue that there should be a methodology to ensure that beer/wine/etc. doesn't get shipped directly to 14-year-olds without some ability by the parent to figure out what happened. (Note: If your 14-year-old child has their own credit card, and you don't look at the statements, then you should be disqualified as a parent...but that's a whole different discussion about responsiblity and accountability.)
The hard part is finding a sensible middle ground. It doesn't look as though this new USSC decision makes that happen, since the non-useful middlemen (distributors/retailers) make money out of the current situation, apparently still have a decent lobbying force, and can affect (read as: cancel) any idealistic changes to existing laws.
This ruling might be good news for some folks in the long term, but in the short term at least it doesn't help folks in Maryland (and from what I can tell most other states). The existing state laws here don't contradict the USSC requirements.
Useful links:
Wine Institute pages on interstate wine shipping:
http://www.wineinstitute.org/shipwine/
US Wine shipping laws, state-by-state, from Wine Institute data
http://wi.shipcompliant.com/Home.aspx
Status of Maryland state laws is that individual wineries have to pay a $10 annual license fee, and that only allows them to ship wines that aren't otherwise available locally, and then they still have to use the three-tier system (so they have to ship to a distributor/wholesaler who then ships to a retailer near me).
That's a pretty painful process, and it's not obvious that it produces a useful result. (If the wine is sold anywhere in the state, then it's not eligible for this shipping method AFAICT, even if there's nowhere within an hour's drive that stocks the wine...)
Needless to say, it's more likely that I'd have such a wine shipped to a friend in a nearby state, or just find a store in DC/VA with a better selection where I can actually buy that wine. But that doesn't address things like "wine of the month" clubs which might be nice but which simply can't comply with Maryland restrictions.