Information Technology Reference
In-Depth Information
card information. The ingenuity of the Perl scripts also provided a clear evidence of
suspects' in-depth understanding of the operation of the email, PayPal and Ebay web
servers. All of these systems had been carefully analyzed and effectively reverse
engineered by the suspects. Not only were the systems understood in terms of
implementation technology but also in terms of business level transactions and the
relation between these systems and others with which they had interaction.
The nature of the computer intrusion attack methodology is also noteworthy. We
frequently hear that attacks follow an intelligence and reconnaissance phase. Intrusion
Detection Systems typically report sensor events during reconnaissance probes (e.g.,
port scans). The intelligence phase of these attacks consisted of assembling a long list
of potential target systems. There was no need to initiate reconnaissance probes. One-
click “attack/compromise/subvert” scripts were developed. These scripts targeted
known and “as-yet unknown” (i.e., unpublished) vulnerabilities and fully automated
the installation of trojan-horse software, root kits, web proxies/relays as well as the
search, gathering and retrieval of information contained on the compromised system
and the network to which it was attached to. The targeting of the “as-yet unknown”
vulnerabilities highlights the limitations of today's IDS and anti-virus systems which
primarily based on the “20-20 hindsight” band-aid approach and working at the
wrong level of abstraction. It also highlights the fallacy that there is benefit in keeping
unpublished security vulnerabilities secret until patches are available.
The case was prosecuted in Seattle US Federal Court in 2001. The Federal
Prosecutors successfully presented the cased by showing the reconstructing the fraud
transaction scenario. The effort eventually led to multiple criminal convictions.
5.1 Check-List Mentality
Modern day system development has become increasingly complex and this has led to
the common approach of relying heavily on the integration of “off-the-shelf”
components. When systems are constructed in this manner, security functionalities, if
addressed at all, also frequently end up being simply “off-the-shelf”, component-
based castles-and-moats solutions. This “checklist-mentality” is incapable to address
the distributed collaborative nature of the new online business paradigm. It treats
security as a second-class citizen and defines IA merely as the sum of security
functionalities of all products to be integrated into the system. However, is the sum of
parts equal to the total? Protecting the castles (firewall, IDS, encryption, security file
system, virus checking, user authentication, PKI, etc.) offers little protection to the
true values (the inter-castle transactions) in this new business paradigm.
5.2 IA System Engineering Process
For the purpose of expediency and convenience, security is usually not tightly
integrated into overall system architecture from the start. One critical question must
be asked — Can IA be simply treated as a last minute add-on or should it be part of
the entire solution and thus be integrated into the system engineering process from the
very beginning? Software development utilizes software engineering process. In
contrast, there is no IA engineering process where the security requirement is defined,
analyzed, architected and then finally implemented, tested and maintained in the
