Monday, March 24, 2008

Why Hacking Changed


If you are an old school hacker or old school security
professional, I'm going to be upfront with you. Old school hacking is
dead, network hacking is dead, firewalls are useless and AV software is
a mere redundant software package that underlines your frustration and
ignorance about contemporary hacking. Defense in depth is deceased
since the nineties and it will never come back. The Internet is
operated with knowledge that stems from the late eighties and nineties.
All you learned about the Internet from the seventies 'till the late
two thousandths is dead. It is no longer the landscape we work on. It
is no longer the Internet of today, it is certainly not the Internet of
tomorrow. It belongs into history books and nothing more. It is crucial
to understand this. If we do not agree, the security field stays behind
the facts of today.

Source: http://www.0x000000.com/?i=536
The
author argues that information security should focus much more on
software-based attack vectors, instead of concentrating on network and
operating system attacks.



"Today everything is software, even in the form of virtual hardware" is a very accurate observation. "Security appliances", such as Cisco system's MARS platform, or really self-contained Linux machines with Oracle
10 and other proprietary software on the inside. Many security
administrators are aware of the fact that most Oracle installation are
behind on patches, and Oracle itself only releases patches four times a
year. Yet we choose appliances that rely on invisible software for our critical security operations.



"If
you can define hacking today, it no longer means telnetting into
servers or blowing whistles, but exploiting the application layer.
"
And that is exactly the level at which most of us are not very good. I
sometimes dabble a little in scripting myself, and I was recently
notified that one of my code fragments was potentially vulnerable to an
SQL-injection type of attack. I know what those attacks are, what
causes them, and what effect they can have. Yet, security-conscious as
I am, I missed this one.



I think it is safe to assume that most developer still as insufficiently aware of this type of problems. SQL-injection, cross-site scripting, cross-site request forgery,
etc., are all known attack vectors and well documented. Yet, I venture
to state that very few applications exist that are immune to them.



When
thinking of the six steps of incident response (Prepare, Identify,
Contain, Eradicate, Recover, Lessons Learned), it is time that we start
building our applications to facilitate them. Prepare by building good code, and code that produces adequate, and reliable logging. Identify attacks by closely monitoring the way your applications behave, including the logging they produce.



Analyze the logging with automated tools, and ensure that the logging
stored appropriately and in line with an existing log retention policy.
Don't forget to protect the logging at the same level as the
application it produces; like backups, logging may contain very
interesting facts that may just give an attacker enough information to
exploit your system.

No comments:

Post a Comment

Please share your view and opinions on what I wrote. In order to maintain quality, all comments will be moderated for merit. Contributions that call me out on statements that appear unfounded, wrong, or simply with which you disagree are highly appreciated and are even encouraged. Spam and 'me too' answers will be ignored.