Lets talk about Chewbacca. Not the Wookie, but the malicious program attacking point-of-sales computers (tills or cash registers in old fashioned parlance) across the world right now. bbc.co.uk/news/technology-25978460 Its pretty easy in cases like this to point the finger at Windows security flaws, and whilst theres some truth in that accusation, youll notice a large group of people arguing that Windows only suffers more security breaches because it is popular and therefore targeted. Theres truth in that too (though not as much as those people would like you to believe). More diversity in the platforms in use is actually helping to protect occurrences like this, but its not the whole story. The real answer is not particularly to do with operating systems, its to do with human incompetence. Most software and network engineers today are simply not experienced enough or qualified enough to build truly secures systems. Let me clear - thats not entirely their fault - its the fault of businesses continuously de-prioritising security behind other concerns (mainly numbers of available features and ease of use). Why do they do that? Because customers demand those things more loudly than they demand security. Whats worse is that computer systems get more and more complex every year. New tools and frameworks get built on top of old ones. Layers and layers of complexity are added to allow more and more to be done with less and less human effort (though usually with more and more computer power required). To the engineers putting together these lego bricks of code, they often seem opaque, but to the enlightened hacker looking to find a way through they are complex webs of moving parts. The engineers commonly superglue the bricks together with passwords, firewalls an encryption, leaving no open gaps between the stones. The hackers though dont always need those cracks, they can work through the machinery itself, looking for flaws, and the bricks with the bricks. The hackers have an incentive to do so. The engineers typically are only pressured to get the job done as quickly as possible. So, when you see an article that tells you that despite their Unix and Linux underpinnings, Mac OS X and Android are just as insecure as Windows dont be surprised. Equally so when it turns out your bank has security flaws, or that in-house system you commissioned from a low-cost off-shore vendor. *You* made it that way. You want it to change? Demand security. Make it front and centre in how you choose the systems you use, and the systems you buy, and in the system backing the services you use. If you work in a company that buys software engineering services, or develops software, listen to the engineers who raise security concerns instead of dismissing those ideas. When balancing security concerns against new features, particularly ease of use, try to imagine the actual impact on your company of a major security breach - what will your customers do if you loose their credit card data, or something even worse? Invest in training your staff - dont expect them to be competent by magic - most of them will never have worked in a company that actually cares about security. Learn the difference between security theatre and real security. If youre designing or programming systems be really careful about your platforms - personally Id caution against large frameworks and toolkits - they make things faster at first, but they loose you in complexity when you hit a problem. My golden rule: dont ever use a library that you wouldnt feel comfortable wading into and fixing yourself (even if that requires significant interaction with the maintainers). Never use unmaintained code. Avoid indirection in your code - if you cant trace the paths through your program youve lost the game. Dont buy into abstraction as good design - abstraction, particularly in OOP is a way to hide information from yourself and shouldnt be a design goal, merely a tool to enhance understanding of higher level workflows. Never ever use proprietary code. Never tie your codebase specifically to a platform that isnt itself open and under continuous maintenance. Dont add artificial barriers to upgrading systems - like relying on systems that have a cost associated with upgrades. Do peer review of all code you write. Make security review a required part of that peer review. Make security testing a mandatory procedure before any software is released. Automate as much testing as possible and run it every time some code changes. Keep it simple. Care about what you do.
Posted on: Sat, 01 Feb 2014 07:00:17 +0000
Trending Topics
Recently Viewed Topics
© 2015