Thanks Peter, like Benjamin said hypothesizing is fun :) :) I think we are supposed to uphold the values, we should focus on how things are supposed to be and that those lines of defense should exist. (well, if some Bank thinks its not necessary, then that's their problem, also recall some folks on the list are respected teachers,professors, lecturers yet if their students argue out points giving such examples, then one of the major cornerstones of ethics (protect society and society's common wealth) is broken)
But even then, are u sure, there is a Bank that will allow the use of unsecured DNS? You know something, you could be playing about with their honey pots..... Can you let an unknown host join the network, run in promiscuous mode, have access to other segments and services of the corporate network, etc? Some corporates even go the extent of saying for example (just an example): traffic from IBM should not pass through certain Microsoft routers even if they are the best path available, let alone that from Iraq passing via Pentagon routers... That said, undesirable intruders are very dangerous people, and can capitalize on so many things to attack and break through, (remember what the guy of the Titanic said, not even God could sink it, only to find out later that the Titanic was gone). But that should not stop us from always keeping the advocacy for best practice. :) > Davis, > > Your input was a defense strategy wasn't it? And it assumed certain > security measures being in place that I know don't exist in several > corporations I could name. Also, in those corporations, sysadmin and > security admin are more or less synonymous! :-) Even when they're not, or > when PWC does an "IT Audit", they're mostly concerned with external > security/firewall/TLS/SSL/IDS, not internal. > > P. > > -- > Evolution (n): A hypothetical process whereby infinitely improbable events > occur with alarming frequency, order arises from chaos, and no one is > given > credit. > > > > On 16 July 2012 14:54, <[email protected]> wrote: > >> Hi Peter, >> >> my input is not an attack strategy at all. My input assumes Simbwa has >> successfully gotten to those lines of defense and is then faced with >> resolving the questions at hand. >> >> Also, this is not the jurisdiction of the corporate sys admin we are >> discussing, rather that of the security admins and managers. >> >> >> >> > Davis' plan is actually flawed from the outset. >> > >> > Phillip's attack is NOT at the bank (stanbic in his example) >> > >> > The attack is at a corporate client of Stanbic's who uses stanbic's >> online >> > banking interface. >> > >> > And his attack isn't completely hypothetical. Both him and I have >> worked >> > at >> > one such corporate client and helped to install the said stanbic >> software. >> > And the IT security at this company was non-existent on the internal >> > network. >> > >> > This paragraph actually made me chuckle. Is this Uganda we're talking >> > about? I've done aircrack cracks on a number of corporate wireless >> > networks >> > and there's a lot of WEP and WPA1 out there. And I know many corporate >> > system administrators who wouldn't be able to expand a single one of >> the >> > abbreviations in this paragraph. Yes, even SSL. >> > >> > "Goodness, in the corporate world, security does not mean passwords, >> > actually PAP is the least secure, leverage schemes like CHAP, >> DIAMETER, >> > RADIUS, TACACS/TACACS+ yet even at the port level you have EAP, >> security >> > goes even to the physical level to leverage Quantum cryptography; PKI, >> > RSN, TLS/SSL, DNSsec, IPsec, PGP, etc are all there for you to use. >> You >> > have so many strategies for protection, forget the days of GSM and WEP >> or >> > even DES for that matter. At the human interface you have a range of >> > multi-factor authentication schemes, Biometrics is also cheap nowadays >> > (assume FAR is a myth, yet even if not, you could leverage the multi >> > factor scheme)" >> > >> > >> > P. >> > >> > -- >> > Evolution (n): A hypothetical process whereby infinitely improbable >> events >> > occur with alarming frequency, order arises from chaos, and no one is >> > given >> > credit. >> > _______________________________________________ >> > The Uganda Linux User Group: http://linux.or.ug >> > >> > Send messages to this mailing list by addressing e-mails to: >> > [email protected] >> > Mailing list archives: http://www.mail-archive.com/[email protected]/ >> > Mailing list settings: http://kym.net/mailman/listinfo/lug >> > To unsubscribe: http://kym.net/mailman/options/lug >> > >> > The Uganda LUG mailing list is generously hosted by INFOCOM: >> > http://www.infocom.co.ug/ >> > >> > The above comments and data are owned by whoever posted them >> (including >> > attachments if any). The mailing list host is not responsible for them >> in >> > any way. >> >> >> _______________________________________________ >> The Uganda Linux User Group: http://linux.or.ug >> >> Send messages to this mailing list by addressing e-mails to: >> [email protected] >> Mailing list archives: http://www.mail-archive.com/[email protected]/ >> Mailing list settings: http://kym.net/mailman/listinfo/lug >> To unsubscribe: http://kym.net/mailman/options/lug >> >> The Uganda LUG mailing list is generously hosted by INFOCOM: >> http://www.infocom.co.ug/ >> >> The above comments and data are owned by whoever posted them (including >> attachments if any). The mailing list host is not responsible for them >> in >> any way. >> > _______________________________________________ > The Uganda Linux User Group: http://linux.or.ug > > Send messages to this mailing list by addressing e-mails to: > [email protected] > Mailing list archives: http://www.mail-archive.com/[email protected]/ > Mailing list settings: http://kym.net/mailman/listinfo/lug > To unsubscribe: http://kym.net/mailman/options/lug > > The Uganda LUG mailing list is generously hosted by INFOCOM: > http://www.infocom.co.ug/ > > The above comments and data are owned by whoever posted them (including > attachments if any). The mailing list host is not responsible for them in > any way. _______________________________________________ The Uganda Linux User Group: http://linux.or.ug Send messages to this mailing list by addressing e-mails to: [email protected] Mailing list archives: http://www.mail-archive.com/[email protected]/ Mailing list settings: http://kym.net/mailman/listinfo/lug To unsubscribe: http://kym.net/mailman/options/lug The Uganda LUG mailing list is generously hosted by INFOCOM: http://www.infocom.co.ug/ The above comments and data are owned by whoever posted them (including attachments if any). The mailing list host is not responsible for them in any way.
