When Convenience Trumps Security
Security is always a retrofit. Those true geniuses who invented new ways for us to do things better are not the same people who built in the security and safety measures. The inventor of the wheel almost certainly didn't invent brakes. Locks likely came long after doors.
Demand for security in new things usually follows the invention quickly enough. However, for Infosec, the dangers to the user of poor or no security are not so apparent to users as an unlocked door is, or as a vehicle with no brakes. Serious Infosec only came along after computers were widespread.
What should you learn next?
Everyday Risk-Takers
Even Infosec-first people may be tempted by the speed of delivery offered by insecure online services. My bank recently asked me to email them private information to support a request, including my SSN details. I was tempted. Though I would be giving up my security for greater speed of delivery what, I reasoned, were the chances of a person-in-the-middle getting hold of my emailed private details? You might call that a risk-management choice, though it is true that name features a lot in Infosec: it is called - convenience.
In this case, the better angels of my Infosec nature took over, and I took a little extra time to ask the bank about a secure online service for uploading private documents. Though it was not advertised, they had one, so I used it. However, many customers would not have sought it out or, even if they were aware of it, would still have risked using normal email.
Big Government/Big Risk
The astounding growth of media available to all for sending, receiving and storing large amounts of data is the major Infosec challenge for government and corporate security. Over the past 15 years, consumer equipment has evolved to give computing powers to almost anyone. The market has very effectively and efficiently responded to consumer demand for increased computing power and, in meeting it, did not (and really cannot) stop to take account of security. To quote the Open Web Application, Security Project (OWASP [1]), "our ability to invent technology has seriously outstripped our ability to secure it."
When IT was less widespread and more expensive, its development could be controlled by governments and corporate interests. This enabled governments to add effective security controls, such as encryption, while those pre-internet times also made government systems much less vulnerable to persistent and widespread technical attack that is a feature of the Internet. However, the natural security defenses offered by those less accessible, expensive (and thus more controllable) IT systems have been overwhelmed by a tide of consumer-owned miniaturization, with ever-increasing computing and communications power. Governments have tried to keep up with this 'democratization' of IT. I recall the development of encryption technologies in the 1990s that were set to rely upon developing commercial communications technology. However, that public- facing technology developed much more rapidly than the governments, which meant that its encryption capabilities had to play catch-up.
For the government, the risks from insecure computing are huge. At stake is lots of information that does not 'belong' to it, and nearly all of which qualifies for some form of legal tagging to ensure it will eventually fall under public scrutiny. Combine this with an automatic assumption by citizens that the state will take extraordinary precautions with the data entrusted to it and we can see that the stakes are much, much higher than a private citizen deciding whether to risk sending their personal details over insecure email. However, lawmakers and their officials are hard-pressed to keep up their flow of decision-making. They too will be used to the idea of accepting risk in private transactions. However, when they decide to trade in caution for speed with privileged government-held data, the results may be explosive.
Recent Cases
There have been two recent (2016) high-profile examples of the use of consumer devices which conflate private use of IT with existing government security models. Both are at root about convenience over secrecy. Firstly, the Hillary Clinton email affair (dating back to 2009), where (former Secretary of State) Clinton deployed a private email server, primarily as a means of overcoming a simple problem: having to carry a dedicated (and government-controlled) cell phone for matters of state [2]. This is not a place for taking political sides (though I say quite neutrally that the worst case would have been for Mrs. Clinton to ignore the separation of public/private and just use her private cell phone for everything). On the other side of the political divide, House Speaker Paul Ryan recently let slip that he had frequently spoken to President-elect Trump via cellphone ("I.. probably shouldn't say that on TV", he added [3]). It is probably going too far to suggest that both men would find common cause with Mrs. Clinton over their reasons for departing from government security protocol: but the fact is politicians of any persuasion will not want restrictions on how they use their cell phone.
Having worked in government, I am aware of the pressure to keep your country moving forward and am not unsympathetic, even when staff get voluble over their frustration with security requirements. In these cases, the higher the paycheck of the complainant, the harder security rules can be to justify. My own experience of top level push to adapt new IT came when senior managers sought to use a popular commercial mobile email device, which had become highly visible but had not been adapted for government use. In retrospect, the experience of helping to achieve the necessary adaptation was pleasant enough. Though senior managers were very vocal about security preventing them from using time-saving technology, the fact that they were in dialogue with the Infosec side before using the commercially available version is the sort of little victory that Infosec professionals should not underestimate. Solutions for meeting security requirement in these cases can sometimes seem pragmatic and transitory, but the willingness of senior people to engage with security enablers is important.
Convenience is then a factor in Infosec risk management though it does not bear the name in any methodology I have seen. However, if this elephant in the room could be better defined, perhaps regarding ease of use, of achieving organizational best practice and, where possible, in the cause of getting more things done more quickly, then the risk of taking short-cuts with technology will be more apparent to users. That is essential for the new model of security management now becoming commonplace: i.e. an increased emphasis on user responsibility and decreasing emphasis on the building of walls - both procedural and technological - to prevent security breaches. Also with an increased emphasis on recovery of services when things do go wrong.
[1] Though put in the context of code, the quotation continues: "[M]any of the technologies in use today simply have not received any security scrutiny." https://www.owasp.org/index.php/Code_Review_Introduction#Why_Does_Code_Have_Vulnerabilities.3F
[2] For a succinct and balanced summary of this complex event, see BBC News - www.bbc.com/news/world-us-canada-31806907
What should you learn next?
[3] See CBS 'Sixty Minutes' – December 4, 2016 - www.cbsnews.com/news/60-minutes-paul-ryan-on-partnership-with-donald-trump/