Goodness. If every bank in this part of the world has equally dismal security policies, I will seriously reconsider opening an account here.
Why is it like this? It is perfectly possible to achieve good security with free software and free information. Why do some security admins insist on sucking at what they are doing? Note that Phillip's attack and Davis's defence both are more-or-less conjecture at this point, Peter's anecdote notwithstanding. It is perfectly possible that Phillip's attack would be doomed from the get-go; it is also perfectly possible that the security of the target (let's call it Hypothetical Bank or HB, so no external eyes are mistakenly led to believe we're actually planning something, eh) is lacking due to human oversight. There's really no way to tell for sure, short of a security audit or an actual intrusion attempt. Have you ever played wargames? Basically, at a LAN party or similar, a person or a team sets up a computer on the network and secures it. The level of security depends on the level of the wargame, of course. Then other people are supposed to try to hack that computer through the network and demonstrate this, often by doing some kind of defacement (once the objective was to deface the projector showing game stats, once we had indicator lights and sound, &c.) showing off your prowess. Have you done any similar games here in Uganda? It's great fun, and good security training for both the attacking and the defending team. On 16 July 2012 20:40, Peter C. Ndikuwera <[email protected]> wrote: > 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.
