Overall, I agree with another respondant that the article as written is about as informative as an (overly long) abstract. With editting to bring focus to the piece, it would be of value as either an introduction to a longer, more technical piece, or as an executive overview.
Introductory paragraphs: Author loses focus addressing CBRN and CT issues together. The technical, logistical, and organizational hurdles have little in common. At the present time, the result of attacks will be far different.
Modivation: Modivational thresholds used for CBRN are crossed quickly if used when planning CT attack. An additional threshold may be the perceived lack of punch in a CT atttack. In addition, a CT attack leaves a greater likelihood for discovery of the source, if it doesn't successfully deal with the number of access logs and other tracing methods built into the telecommunications and I.T. systems an attacker must work through.
Organization: Setting aside my previous cultural bias, I find that the crucial element for successful CT, expertise, seems to be widely available in the developing world. Organizations in almost any nation can come in contact with a number of trained local programmers and system engineers. By focussing on the use of I.T. for normal and secure comm by organizations when planning CBRN attacks, the author may cause decision makers to ineffectually concentrate on controlling public access to cryptology, rather than on the issues regarding CT attacks themselves.
Funding: Unlike CBRN, little capital is required to obtain and situate a CT "lab" or "labs". Hardware is readily available and inexpensive worldwide. The setting can be innocuous. Office automation and software developmenttools and reference works can be had for little cost, even if purchased legitimately at retail. The largest potential costs come from connecting to a local telecommunications provider. This can be mitigated by a) isolating training and rehersal exercises within a closed lab network, and illegally tapping into off-site telecom trunk systems where the opportunity presents itself, and/or b) state telecom subsidies.
State Sponsors: As with CBRN, a state sponsor can provide telecom advisors with detailed knowledge of typical trunking systems. The state can provide ready access to high bandwidth connections to the Internet, although this leads to traceability/deniability issues after executing an attack. The state may provide a more realistic training ground, if it allows rehersal attacks within the national I.T. network.
External Hurdles: Given wide disemination of programming and telecom knowledge, and the dispersion of expatriot technical professionals, there are few technical hurdles to CT, even if the organization that desires CT capability is based in an area with few technical resources. The main hurdles would remain perception: "does CT do anything for us?"; and security, in that it is more difficult to cover one's tracks.
Q: Using CT, how easy or otherwise is it to bring down or attack vital systems? A: This has been addressed elsewhere. Q: What sort of skills would be needed to do so, and are they common/teachable? A: This requires a more detailed response, which will be posted separately. Q: Commercial-off-the-shelf software: can it really do CT? A: The most common s/w used for attacking I.T. systems is a terminal emulator. Value is added by the operator typing into it. An attack using a terminal emulator can be automated using the built-in programmability of most widely-used operating systems.
There are a number of s/w packages that are available for free download, which are starting to provide COTS ease-of-use with built-in CT capabilities. At the moment, the vast majority of these only search for or create a security breach in an I.T. system ('Back Orifice', 'nmap'). An experienced operator is still required to exploit such a breach. Q: Which systems are actually attackable? A: Any system directly or indirectly connected to a public network can be attacked. Any such system is vulnerable to denial of service (can't get out or in) attacks or spoof (network traffic intercept) attacks. UNIX-based or Windows-based systems are most susceptable to penetration attacks because of the large number individuals familiar with methods of penetration, which are then widely published. Q: Can a recovery be made from such attacks? A: This has been addressed elsewhere. Q: Is it likely to improve/get worse? A: This has been addressed elsewhere. Q: What sort of preventitive work would you recommend them to carry out? A: This has been addressed elsewhere.
I believe that the tort system, as it applies to product liability today, has (like medical mal-practice) lost any corrective function it had. Any unfavorable result is assumed to be reasonably preventable, and the participants therefore liable. Yes, it's nice to have someone to kick in the butt, but what's the point?
Speaking of "COW"s, "it's been done with Solaris, NT,... " and MacOS, of all things, as shown by the UCLA Appleseed project (http://exodus.physics.ucla.edu/appleseed/applesee d.html). Sure, having a manditory GUI slows things down a bit, but if it's not EXERCISED on the majority of processing nodes, then not by much.
Slashdot Mirror
Overall, I agree with another respondant that the article as written is about
as informative as an (overly long) abstract. With editting to bring focus to the piece, it
would be of value as either an introduction to a longer, more technical piece,
or as an executive overview.
Introductory paragraphs:
Author loses focus addressing CBRN and CT issues together. The technical,
logistical, and organizational hurdles have little in common. At the present
time, the result of attacks will be far different.
Modivation:
Modivational thresholds used for CBRN are crossed quickly if used when planning
CT attack. An additional threshold may be the perceived lack of punch in a CT
atttack. In addition, a CT attack leaves a greater likelihood for discovery of
the source, if it doesn't successfully deal with the number of access logs and other tracing
methods built into the telecommunications and I.T. systems an attacker must
work through.
Organization:
Setting aside my previous cultural bias, I find that the crucial element
for successful CT, expertise, seems to be widely available in the
developing world. Organizations in almost any nation can come in contact with a
number of trained local programmers and system engineers. By focussing on the
use of I.T. for normal and secure comm by organizations when planning CBRN attacks, the author may cause
decision makers to ineffectually concentrate on controlling public access to
cryptology, rather than on the issues regarding CT attacks themselves.
Funding:
Unlike CBRN, little capital is required to obtain and situate a CT "lab" or "labs". Hardware
is readily available and inexpensive worldwide. The setting can be innocuous. Office automation and software developmenttools and reference works can be had for little cost, even if purchased
legitimately at retail. The largest potential costs come from connecting
to a local telecommunications provider. This can be mitigated by a) isolating
training and rehersal exercises within a closed lab network, and illegally
tapping into off-site telecom trunk systems where the opportunity presents
itself, and/or b) state telecom subsidies.
State Sponsors:
As with CBRN, a state sponsor can provide telecom advisors with detailed knowledge of typical
trunking systems. The state can provide ready access to high bandwidth
connections to the Internet, although this leads to traceability/deniability issues
after
executing an attack. The state may provide a more realistic
training ground, if it allows rehersal attacks within the national I.T. network.
External Hurdles:
Given wide disemination of programming and telecom knowledge, and the
dispersion of expatriot technical professionals, there are few technical
hurdles to CT, even if the organization that desires CT capability is based in
an area with few technical resources. The main hurdles would remain perception:
"does CT do anything for us?"; and security, in that it is more difficult to
cover one's tracks.
Q: Using CT, how easy or otherwise is it to bring down or attack vital systems?
A: This has been addressed elsewhere.
Q: What sort of skills would be needed to do so, and are they common/teachable?
A: This requires a more detailed response, which will be posted
separately.
Q: Commercial-off-the-shelf software: can it really do CT?
A: The most common s/w used for attacking I.T. systems is a terminal
emulator. Value is added by the operator typing into it. An attack
using a terminal emulator can be automated using the built-in
programmability of most widely-used operating systems.
There are a number of s/w packages that are available for free
download, which are starting to provide COTS ease-of-use with built-in
CT capabilities. At the moment, the vast majority of these only search
for or create a security breach in an I.T. system ('Back Orifice',
'nmap'). An experienced operator is still required to exploit such a breach.
Q: Which systems are actually attackable?
A: Any system directly or indirectly connected to a public network can be
attacked. Any such system is vulnerable to denial of service (can't get
out or in) attacks or
spoof (network traffic intercept) attacks. UNIX-based or Windows-based systems
are most susceptable to penetration attacks because of the large number
individuals familiar with methods of penetration, which are then widely
published.
Q: Can a recovery be made from such attacks?
A: This has been addressed elsewhere.
Q: Is it likely to improve/get worse?
A: This has been addressed elsewhere.
Q: What sort of preventitive work would you recommend them to carry out?
A: This has been addressed elsewhere.
My gullibility needed an outlet, and it turns out that zoning on Star Trek Rev X.X is a lot cheaper than Scientology.
I believe that the tort system, as it applies to
product liability today, has (like medical mal-practice) lost any corrective function it had. Any unfavorable result is assumed to be reasonably preventable, and the participants therefore liable. Yes, it's nice to have someone to kick in the butt, but what's the point?
Speaking of "COW"s, "it's been done with Solaris, NT, ... " and MacOS, of all things, as shown by the UCLA Appleseed project (http://exodus.physics.ucla.edu/appleseed/applesee d.html).
Sure, having a manditory GUI slows things down a bit, but if it's not EXERCISED on the majority of processing nodes, then not by much.