Practicing the handling of large-scale incidents through exercises and simulations on a regular basis; such incidents happen rarely, so incident response teams often lack experience in handling them effectively.
See also appendix B, "Incident Handling Scenarios".
This also effectively says "You WILL do it like this" to the federal agencies.
First of all: the word is "shall", and second: no, it doesn't say that at all. It's a guide, and quite clear about it. Recent FISMA requirements are causing CSIRTs to spring up in many government agencies, and the guide was created to assist new CSIRTs in devising procedures and policies that are more or less consistent with best practices. Believe it or not, developing a security program can be a pretty complex task, not only in technical terms, but even more so in terms of acquiring the necessary authority and budget. A document such as this helps acquaint managers with generic practices so they can develop a good team, and so they have some idea of what they're getting into. See for example the paragraphs on morale and cost in section 2.4.2.
To address some of the disparaging nonsense people have posted about.gov IT people: as a member of a.gov incident response team, I can tell you that the U.S. government is well stocked with talented IT people. When it comes to security, too often it is the vendors who provide poorly configured, insecure software to the government. This is one of the major reasons that.gov sites occasionally get hacked*: the.gov folks have to rely on a lot of vendors to provide software, and many of these vendors employ lots of idiots who don't know jack about security.
Furthermore, U.S. government sites don't really get hacked all that often, even though they are heavily targeted. I encourage those who think otherwise to compare the statistics over on zone-h.org. (zone-h is down at the time of this posting -- I'm sure they'll be back soon.)
* Yes, I know about "hack" and "crack". It's a language; it changes. Deal with it.
This also effectively says "You WILL do it like this" to the federal agencies.
First of all: the word is "shall", and second: no, it doesn't say that at all. It's a guide, and quite clear about it. Recent FISMA requirements are causing CSIRTs to spring up in many government agencies, and the guide was created to assist new CSIRTs in devising procedures and policies that are more or less consistent with best practices. Believe it or not, developing a security program can be a pretty complex task, not only in technical terms, but even more so in terms of acquiring the necessary authority and budget. A document such as this helps acquaint managers with generic practices so they can develop a good team, and so they have some idea of what they're getting into. See for example the paragraphs on morale and cost in section 2.4.2.
To address some of the disparaging nonsense people have posted about.gov IT people: as a member of a.gov incident response team, I can tell you that the U.S. government is well stocked with talented IT people. When it comes to security, too often it is the vendors who provide poorly configured, insecure software to the government. This is one of the major reasons that.gov sites occasionally get hacked*: the.gov folks have to rely on a lot of vendors to provide software, and the many of these vendors employ lots of idiots who don't know jack about security.
Furthermore, U.S. government sites don't really get hacked all that often, even though they are heavily targeted. I encourage those who think otherwise to compare the statistics over on zone-h.org. (zone-h is down at the time of this posting -- I'm sure they'll be back soon.)
* Yes, I know about "hack" and "crack". It's a language; it changes. Deal with it.
Let us know when there's a decimal point between your eyeballs and the monitor you're reading this on. (In other words, you completely missed the point. Go back and read it again.)
These are the same people who tried to cut France into equal-sized, equally populated regions. Never mind that population is not distributed equally.
Indeed. These bozos also tried to eliminate the 7-day week in France and replace it with "decades" of ten days. Again, it's the unhealthy preoccupation with ten -- one of the dumbest mistakes in human history. We would be a lot further along if eight or sixteen had been the chosen base for modern counting. We don't need to perpetuate this absurdity into areas where counting is the fundamental operation.
Ah... sounds like the cry of an English units bigot. Merry Christmas:).
No, I think the English system has horrible naming problems. But the metric system is inherently flawed because it is so deeply invested in base 10, and there's almost nothing in nature, mathematics, or philosophy that has anything to do with base 10. The idea we would extend the foolish base-10 bigotry to computing, where it is obviously inappropriate, is outright ridiculous. Happy new year.
Reading through nearly all of the ranting and raving about this new standard simply proves the need for it, IMHO.
The so-called ranting and raving itself -- not your act of reading it -- might prove the need for a standard, but not the idiotic one that is before us.
Let me predict the outcome based upon past events: with the exception of the USA, the entire world will make the switch to the official standard. Half of the US scientific community will switch and half won't. The 2014 first manned mission to Mars will fail because the the navigation computer design team specified 100gibs of RAM, but the implementation team only installed 100gigs of RAM and it is unable to perform course corrections---the crew and ship are lost in space.
Confused? Then see SEPTEMBER 30, 1999 Likely Cause Of Orbiter Loss Found The peer review preliminary findings indicate that one team used English units (e.g., inches, feet and pounds) while the other used metric units for a key spacecraft operation.
You make the typical, laughable, metric-centric error of assuming that the failure of the Mars Orbiter had something to do with the system of units, i.e. English vs. metric. The fact is that the two teams were not using the same units; it doesn't matter what systems their respective units came from. They could all have been using metric units, but one team could have been using meters and the other kilometers -- they still would have screwed up. Metric proponents point to this example and crow and have no idea what asses they're making of themselves. Even the synopsis you cite has this bias in it; it should say "The peer review preliminary findings indicate that the two teams used differing units for communicating measurements for a key spacecraft operation."
Since there is no "deci-binary", I assume it means "deka-binary". (What the hell would "deci-binary" mean? 1/1024 of a byte?)
Who knows? I didn't come up with this idiotic naming convention. Maybe it would mean 1/8 or 1/16, since they are the closest powers of two to 1/10. Or maybe it would mean 2^(10/3) to reflect that when raised to the third power it would come out mibi (i.e. milli/binary).
And yes, fractions of a bit or byte are used. Try studying signal theory, specifically entropy, for one example. In any case, the SI system is supposed to be a general naming convention; now they're defining crappy infixes that might pertain only to certain prefixes? I thought the point of the prefix system was to be orthogonal.
There's no difference in efficiency between mallocing 1048576 bytes and mallocing 1000000 bytse. Powers of 2 are useful for efficiency now only because they match multiples of the register size of the CPU (but 1000000 does that too).
That's certainly incorrect. Read up on memory management algorithms, especially the McKusick-Karels allocator, and you'll see that allocations of powers of two are much more efficient because the address of the allocated block can implicitly encode its size.
Unfortunately, the malloc() call usually prefixes the allocated memory with a data structure, thus a malloc of 1048576 bytes is really an allocation of 1048592 bytes or so.
The more fundamental problem, in my mind, is the notion of perpetuating the idiotic reliance on base 10 into computing, where at least a reasonable base is already employed. This base-10 nonsense is the fatal flaw in the metric system. Ten is not an intuitive number. You cannot mentally subdivide an area or length into tenths, or even fifths. You cannot easiliy use a set of identical containers to subdivide a liquid volume into equal measures of tenths. Decimal fractions in general do not have exact representations in IEEE floating point format -- I was aghast when the U.S. stock market converted from eighths to tenths, thus introducing new rounding errors into nearly every calculation. Eighths have an exact IEEE representation; tenths do not. And for what conceivable reason? only the misguided and unsavory predilection with the number ten.
The English system, despite its arcane collection of names, is at least superior to the metric system in that given a foot you can fairly trivially determine an inch; given a gallon you can trivially determine a quart. Why? Because the English system is based principally on divisions of two and three, which are easier to visualize, easier to perform in real life, and more appropriate to common use. In decimal, if you wish to add a significant digit to the quality of a measurement, you must refine your measuring apparatus by a factor of ten. In decimal, if you wish to take advantage of the naming system in building something, you must scale its dimensions by a factor of ten. Meanwhile in real life, people *double* recipes that make insufficient portions, people build third-scale models, etc.
We have the opportunity to rely on a sensible base for computing, and the adoption of mega- and giga- prefixes is merely a convenience that reflects the closeness of 2^10 and 10^3. It makes no sense at all to contort the existing naming convention into a poorly chosen base. We should instead establish a suitable base-2 naming convention that corrects the inherent problems in the metric system, and kilo-, mega-, giga-, tera-, peta-, etc. should be initial members of that system.
(Another minor flaw in the metric system: deci- is too easily confused with deka-, hence deci- is rarely used, and deka- is not used at all.)
The whole point of the vulnerable program (Oracle Application Server) is to act as a webserver, not as a database server. This is so you can build web-accessible functions right on the Oracle box. Obviously then you will plan to expose port 80. Just because you can separate the database from the webserver doesn't mean that people will -- in some applications the immediate locality of the database will provide a substantial performance boost.
Regarding CatherineCornelius's remark that any database that carries useful information must be secure, bzzt, sorry, wrong answer: any exposed service must be secure. The attackers aren't interested in what you have on your box -- that's just gravy. What most of them are trying to acquire is bandwidth for building their DDoS networks (and relays for bouncing IRC off of), and they don't bother to check what you're doing with your hardware before they attack it. All they need to know is that you have bandwidth and a vulnerable service.
On the other matter of the prevalence of internal attacks, I think the huge number of automated attacks running now has rendered the famous 70% mark long obsolete. Think of Nimda & Code Red. The vast majority of attacks are indiscriminate and external.
For specific attacks against this particular service, these might be carried out by locating Oracle 9i Apache servers using netcraft, or by searching inventories already collected by potential intruders.
The important thing to remember about firewalls is that they don't take the place of host-based security. Once someone finds a way to compromise a host behind the firewall, your entire network is exposed, so if you're not taking care to secure the hosts anyway, you're facing a potential total meltdown.
BTW, protecting against this particular vulnerability might be a good application of Hogwash.
There's no way an RDBMS-backed database will perform adequately to support the root and GTLD zones. You're talking about adding IPC and process overhead, not to mention a huge and complex codepath, within the nameserver, along with the potential for locking up the whole system if the RDBMS goes down or gets blocked.
And all that for zero gain -- data is data. No one needs to do joined subselects of.com on the GTLD servers. The updates don't need to occur frequently or on the fly. We certainly don't want record locking in the root zone. And securing an RDBMS on top of the nameserver itself is a horrible prospect.
Sure, an RDBMS might be fine for backing your Win2k active directory. Let's not deploy it on the root servers, okay?
There is no difference between hacker and cracker, although if you use cracker, most non-geeks will think you're talking about a saltine.
The language changes, ESR notwithstanding. Get over it. There's nothing sillier than geeks trying to be pedantic about usage. (Oh, and let's not forget what a geek is.)
First, 43 times is a lot more than the absurd "twice" claimed by the original poster. Your retort is anemic at best.
Second, 305 is about 600% more than 43. You can say it's 7 times as many, if you're trying to be honest.
Third, the U.S. government maintains far more hosts on the 'Net than the U.K. government does. Netcraft records only 1073 web sites in gov.uk, and 6290 -- that's nearly 5.86 times as many -- hosts in.gov. And that's just web servers.
I don't claim the U.S. is a whole lot better at securing their hosts than the U.K., but the converse is certainly unsupported by the evidence.
Slashdot Mirror
Page ES-4:
See also appendix B, "Incident Handling Scenarios".
First of all: the word is "shall", and second: no, it doesn't say that at all. It's a guide, and quite clear about it. Recent FISMA requirements are causing CSIRTs to spring up in many government agencies, and the guide was created to assist new CSIRTs in devising procedures and policies that are more or less consistent with best practices. Believe it or not, developing a security program can be a pretty complex task, not only in technical terms, but even more so in terms of acquiring the necessary authority and budget. A document such as this helps acquaint managers with generic practices so they can develop a good team, and so they have some idea of what they're getting into. See for example the paragraphs on morale and cost in section 2.4.2.
To address some of the disparaging nonsense people have posted about .gov IT people: as a member of a .gov incident response team, I can tell you that the U.S. government is well stocked with talented IT people. When it comes to security, too often it is the vendors who provide poorly configured, insecure software to the government. This is one of the major reasons that .gov sites occasionally get hacked*: the .gov folks have to rely on a lot of vendors to provide software, and many of these vendors employ lots of idiots who don't know jack about security.
Furthermore, U.S. government sites don't really get hacked all that often, even though they are heavily targeted. I encourage those who think otherwise to compare the statistics over on zone-h.org. (zone-h is down at the time of this posting -- I'm sure they'll be back soon.)
* Yes, I know about "hack" and "crack". It's a language; it changes. Deal with it.
First of all: the word is "shall", and second: no, it doesn't say that at all. It's a guide, and quite clear about it. Recent FISMA requirements are causing CSIRTs to spring up in many government agencies, and the guide was created to assist new CSIRTs in devising procedures and policies that are more or less consistent with best practices. Believe it or not, developing a security program can be a pretty complex task, not only in technical terms, but even more so in terms of acquiring the necessary authority and budget. A document such as this helps acquaint managers with generic practices so they can develop a good team, and so they have some idea of what they're getting into. See for example the paragraphs on morale and cost in section 2.4.2.
To address some of the disparaging nonsense people have posted about .gov IT people: as a member of a .gov incident response team, I can tell you that the U.S. government is well stocked with talented IT people. When it comes to security, too often it is the vendors who provide poorly configured, insecure software to the government. This is one of the major reasons that .gov sites occasionally get hacked*: the .gov folks have to rely on a lot of vendors to provide software, and the many of these vendors employ lots of idiots who don't know jack about security.
Furthermore, U.S. government sites don't really get hacked all that often, even though they are heavily targeted. I encourage those who think otherwise to compare the statistics over on zone-h.org. (zone-h is down at the time of this posting -- I'm sure they'll be back soon.)
* Yes, I know about "hack" and "crack". It's a language; it changes. Deal with it.
Huh? Just move the decimal point.
Let us know when there's a decimal point between your eyeballs and the monitor you're reading this on. (In other words, you completely missed the point. Go back and read it again.)
These are the same people who tried to cut France into equal-sized, equally populated regions. Never mind that population is not distributed equally.
Indeed. These bozos also tried to eliminate the 7-day week in France and replace it with "decades" of ten days. Again, it's the unhealthy preoccupation with ten -- one of the dumbest mistakes in human history. We would be a lot further along if eight or sixteen had been the chosen base for modern counting. We don't need to perpetuate this absurdity into areas where counting is the fundamental operation.
Ah... sounds like the cry of an English units bigot. Merry Christmas :).
No, I think the English system has horrible naming problems. But the metric system is inherently flawed because it is so deeply invested in base 10, and there's almost nothing in nature, mathematics, or philosophy that has anything to do with base 10. The idea we would extend the foolish base-10 bigotry to computing, where it is obviously inappropriate, is outright ridiculous. Happy new year.
Reading through nearly all of the ranting and raving about this new standard simply proves the need for it, IMHO.
The so-called ranting and raving itself -- not your act of reading it -- might prove the need for a standard, but not the idiotic one that is before us.
Confused? Then see SEPTEMBER 30, 1999 Likely Cause Of Orbiter Loss Found The peer review preliminary findings indicate that one team used English units (e.g., inches, feet and pounds) while the other used metric units for a key spacecraft operation
You make the typical, laughable, metric-centric error of assuming that the failure of the Mars Orbiter had something to do with the system of units, i.e. English vs. metric. The fact is that the two teams were not using the same units; it doesn't matter what systems their respective units came from. They could all have been using metric units, but one team could have been using meters and the other kilometers -- they still would have screwed up. Metric proponents point to this example and crow and have no idea what asses they're making of themselves. Even the synopsis you cite has this bias in it; it should say "The peer review preliminary findings indicate that the two teams used differing units for communicating measurements for a key spacecraft operation."
Since there is no "deci-binary", I assume it means "deka-binary". (What the hell would "deci-binary" mean? 1/1024 of a byte?)
Who knows? I didn't come up with this idiotic naming convention. Maybe it would mean 1/8 or 1/16, since they are the closest powers of two to 1/10. Or maybe it would mean 2^(10/3) to reflect that when raised to the third power it would come out mibi (i.e. milli/binary).
And yes, fractions of a bit or byte are used. Try studying signal theory, specifically entropy, for one example. In any case, the SI system is supposed to be a general naming convention; now they're defining crappy infixes that might pertain only to certain prefixes? I thought the point of the prefix system was to be orthogonal.
BTW, if you can't remember what the prefix is, remember: first two letters of the SI unit, then 'bi' for binary. A kilo-binary-byte = Kibibyte.
Brilliant. Now SI includes inherently ambiguous prefixes: what will "debi" mean? Will it be "deci-binary" or "deka-binary"?
There's no difference in efficiency between mallocing 1048576 bytes and mallocing 1000000 bytse. Powers of 2 are useful for efficiency now only because they match multiples of the register size of the CPU (but 1000000 does that too).
That's certainly incorrect. Read up on memory management algorithms, especially the McKusick-Karels allocator, and you'll see that allocations of powers of two are much more efficient because the address of the allocated block can implicitly encode its size.
Unfortunately, the malloc() call usually prefixes the allocated memory with a data structure, thus a malloc of 1048576 bytes is really an allocation of 1048592 bytes or so.
The more fundamental problem, in my mind, is the notion of perpetuating the idiotic reliance on base 10 into computing, where at least a reasonable base is already employed. This base-10 nonsense is the fatal flaw in the metric system. Ten is not an intuitive number. You cannot mentally subdivide an area or length into tenths, or even fifths. You cannot easiliy use a set of identical containers to subdivide a liquid volume into equal measures of tenths. Decimal fractions in general do not have exact representations in IEEE floating point format -- I was aghast when the U.S. stock market converted from eighths to tenths, thus introducing new rounding errors into nearly every calculation. Eighths have an exact IEEE representation; tenths do not. And for what conceivable reason? only the misguided and unsavory predilection with the number ten.
The English system, despite its arcane collection of names, is at least superior to the metric system in that given a foot you can fairly trivially determine an inch; given a gallon you can trivially determine a quart. Why? Because the English system is based principally on divisions of two and three, which are easier to visualize, easier to perform in real life, and more appropriate to common use. In decimal, if you wish to add a significant digit to the quality of a measurement, you must refine your measuring apparatus by a factor of ten. In decimal, if you wish to take advantage of the naming system in building something, you must scale its dimensions by a factor of ten. Meanwhile in real life, people *double* recipes that make insufficient portions, people build third-scale models, etc.
We have the opportunity to rely on a sensible base for computing, and the adoption of mega- and giga- prefixes is merely a convenience that reflects the closeness of 2^10 and 10^3. It makes no sense at all to contort the existing naming convention into a poorly chosen base. We should instead establish a suitable base-2 naming convention that corrects the inherent problems in the metric system, and kilo-, mega-, giga-, tera-, peta-, etc. should be initial members of that system.
(Another minor flaw in the metric system: deci- is too easily confused with deka-, hence deci- is rarely used, and deka- is not used at all.)
The whole point of the vulnerable program (Oracle Application Server) is to act as a webserver, not as a database server. This is so you can build web-accessible functions right on the Oracle box. Obviously then you will plan to expose port 80. Just because you can separate the database from the webserver doesn't mean that people will -- in some applications the immediate locality of the database will provide a substantial performance boost.
Regarding CatherineCornelius's remark that any database that carries useful information must be secure, bzzt, sorry, wrong answer: any exposed service must be secure. The attackers aren't interested in what you have on your box -- that's just gravy. What most of them are trying to acquire is bandwidth for building their DDoS networks (and relays for bouncing IRC off of), and they don't bother to check what you're doing with your hardware before they attack it. All they need to know is that you have bandwidth and a vulnerable service.
On the other matter of the prevalence of internal attacks, I think the huge number of automated attacks running now has rendered the famous 70% mark long obsolete. Think of Nimda & Code Red. The vast majority of attacks are indiscriminate and external.
For specific attacks against this particular service, these might be carried out by locating Oracle 9i Apache servers using netcraft, or by searching inventories already collected by potential intruders.
The important thing to remember about firewalls is that they don't take the place of host-based security. Once someone finds a way to compromise a host behind the firewall, your entire network is exposed, so if you're not taking care to secure the hosts anyway, you're facing a potential total meltdown.
BTW, protecting against this particular vulnerability might be a good application of Hogwash.
There's no way an RDBMS-backed database will perform adequately to support the root and GTLD zones. You're talking about adding IPC and process overhead, not to mention a huge and complex codepath, within the nameserver, along with the potential for locking up the whole system if the RDBMS goes down or gets blocked.
.com on the GTLD servers. The updates don't need to occur frequently or on the fly. We certainly don't want record locking in the root zone. And securing an RDBMS on top of the nameserver itself is a horrible prospect.
And all that for zero gain -- data is data. No one needs to do joined subselects of
Sure, an RDBMS might be fine for backing your Win2k active directory. Let's not deploy it on the root servers, okay?
There is no difference between hacker and cracker, although if you use cracker, most non-geeks will think you're talking about a saltine.
The language changes, ESR notwithstanding. Get over it. There's nothing sillier than geeks trying to be pedantic about usage. (Oh, and let's not forget what a geek is.)
First, 43 times is a lot more than the absurd "twice" claimed by the original poster. Your retort is anemic at best.
.gov. And that's just web servers.
Second, 305 is about 600% more than 43. You can say it's 7 times as many, if you're trying to be honest.
Third, the U.S. government maintains far more hosts on the 'Net than the U.K. government does. Netcraft records only 1073 web sites in gov.uk, and 6290 -- that's nearly 5.86 times as many -- hosts in
I don't claim the U.S. is a whole lot better at securing their hosts than the U.K., but the converse is certainly unsupported by the evidence.