Ah, yes. Attitude. Spot on, Bernard. (Although I must say, in reply to the second example, that the ATM should be able to stand up to attack on its own. A bank preferably shouldn't rely on a third party for IT security, especially if that third party is neither in the security business nor at all paid to maintain your security!)
On 17 July 2012 18:35, Bernard Wanyama <[email protected]> wrote: > Hi Benjamin, > > IT Security is a strange thing - not technical, not academic, not social: > > A company buys a state-of-the-art firewall and the network admin > deploys it with the default login credentials, or with a permit any > any..... > > A bank leases a Wimax link for its ATM and the ISP does not prevent > direct communication between different customers on the same base > station.... > > I read somewhere that in Israel, the state security agency (Shin Bet?) > supervises IT security for banks because the financial system is > considered a part of the critical national infrastructure, and it > works because majority of citizens are security oriented courtesy of a > mandatory stint in the army. Many of my colleagues on this list would > scream murder if they heard of this happening in UG or elsewhere... > > My thinking is that security is an ongoing effort that everybody, > including we the consumers of services, should give sufficient > attention to. Most of the time, it boils down to attitude. > > > Kind regards, > Bernard > > On 17 July 2012 14:26, Benjamin Tayehanpour <[email protected]> > wrote: > > Believe it or not, I actually got that bit. But the banking interface is > > part of the bank, as far as I'm concerned. What Phillip described is in > > effect a MITM attack, and that type of attack would not be possible if > the > > Java web start strap were served over HTTPS using a good CA. So far, the > > bank is still at fault, since it provides no way of actually verifying > that > > the files downloaded are the ones intended. So, yes, I suppose the > intrusion > > is being done through a fault in the security of the corporation, but > then > > through another flaw in the banking interface. Both flaws make this > attack > > possible. > > > > Also, surely, surely the ATMs do not run their communication through the > > Internet at all, but rather through dedicated cables? Or at the very > least > > with some kind of precautions to prevent MITM attacks? Luckily, I have it > > set-up so that I need to approve manually (by independent means) every > > transaction on my card before my issuer grants the withdrawal, so a leak > > would not do very much at all, but you're still giving me the chills! > > > > > > On 17 July 2012 13:40, Peter C. Ndikuwera <[email protected]> wrote: > >> > >> Ok, seems to be some confusion. > >> > >> Phillip's attack is against a corporation running an insecure banking > >> interface. This way, the banking and account transactional information > of > >> the corporation is vulnerable to his attack. This doesn't mean that the > bank > >> is being hacked. No. It's the corporate entity. > >> > >> My security examples are for the corporation, not the bank. Haven't > dealt > >> with any banks so can't speak for their security. > >> > >> So Benjamin, apart from the Windows-based ATM interfaces that are > >> vulnerable to some basic man-in-the-middle attacks, banks are pretty > safe! > >> > >> Seriously, though, from informal discussions with my few banking > friends, > >> I believe most banking fraud in Uganda is insider dealing, not external > >> hacking. > >> > >> > >> 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 17 July 2012 13:18, Benjamin Tayehanpour < > [email protected]> > >> wrote: > >>> > >>> 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. > >> > >> > >> > >> _______________________________________________ > >> 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. > > > > -- > Bernard Wanyama > Technical Manager > SYNTECH ASSOCIATES Ltd > Kampala, Uganda > Cell: +256 712 193979 > Fixed: +256 414 251591 > Web: www.syntechug.com > Email: [email protected] > _______________________________________________ > 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.
