-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy paththe-child-that-grew-too-fast.html
More file actions
103 lines (99 loc) · 7.17 KB
/
the-child-that-grew-too-fast.html
File metadata and controls
103 lines (99 loc) · 7.17 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
<!DOCTYPE html>
<html lang="en">
<head>
<title>meandering journey</title>
<meta charset="utf-8" />
<link href="./theme/css/main.css" type="text/css" rel="stylesheet" />
<link href="http://meandering.journey.sk/feeds/all.atom.xml" type="application/atom+xml" rel="alternate" title="meandering journey Full Atom Feed" />
<link href="http://meandering.journey.sk/feeds/misc.atom.xml" type="application/atom+xml" rel="alternate" title="meandering journey Categories Atom Feed" />
</head>
<body id="index" class="home">
<div class="all">
<div class="extra-info">
<aside>
<h3>About the blog</h3>
A platform to practice my written communication skills.
The range of topics tends to surprise even myself.
</aside>
<aside>
<h3>About the author</h3>
My name is Ján Hušták. I live near
<a href="http://maps.google.com/maps?q=bratislava&z=6">Bratislava</a>.
I've been developing software professionally since 1998.
The Java platform has served me well but I don't dwell on it.
</aside>
<aside>
<h3>Links</h3>
<a href="http://www.journey.sk">Main site</a>,
<a href="http://coding.journey.sk">projects page</a>,
<a href="https://github.com/codingjourney">GitHub</a>.
Sorry, no social networks. I do read mail sent to
coding at journey.sk.
</aside>
<aside id="tags">
<h3>Tags</h3>
<a href="./tag/motivation.html">motivation</a>
- <a href="./tag/htpc.html">HTPC</a>
- <a href="./tag/openbsd.html">OpenBSD</a>
- <a href="./tag/qt.html">Qt</a>
- <a href="./tag/upsheet.html">upsheet</a>
- <a href="./tag/python.html">Python</a>
- <a href="./tag/kde.html">KDE</a>
- <a href="./tag/cloud-computing.html">cloud computing</a>
- <a href="./tag/caldav.html">CalDAV</a>
- <a href="./tag/howto.html">howto</a>
- <a href="./tag/jetty.html">Jetty</a>
- <a href="./tag/craftsmanship.html">craftsmanship</a>
- <a href="./tag/meta.html">meta</a>
- <a href="./tag/music.html">music</a>
- <a href="./tag/it-misadventures.html">IT misadventures</a>
- <a href="./tag/algorithms.html">algorithms</a>
- <a href="./tag/android.html">Android</a>
- <a href="./tag/cups.html">CUPS</a>
- <a href="./tag/security.html">security</a>
- <a href="./tag/html5.html">HTML5</a>
</aside>
<aside class="links">
<h3>Recent articles</h3>
<a href="./much-more-fun-with-planning-poker.html">Much more fun with Planning poker</a>
<a href="./the-child-that-grew-too-fast.html">The child that grew too fast</a>
<a href="./mare-nostrum-at-konzerthaus.html">Mare Nostrum at Konzerthaus</a>
<a href="./too-much-fun-with-planning-poker.html">Too much fun with Planning poker</a>
<a href="./long-time-no-blog.html">Long time no blog</a>
<a href="./what-i-did-last-summer.html">What I did last summer</a>
<a href="./october-2013-is-here.html">October 2013 is here</a>
<a href="./october-2013.html">October 2013</a>
</aside>
</div><!-- /.extra-info -->
<div class="main-column">
<header id="banner" class="body">
<h1><a href=".">meandering<img src="./theme/images/logo.png"/>journey</a></h1>
</header><!-- /#banner -->
<section id="content" class="body">
<header>
<h3>
<a href="the-child-that-grew-too-fast.html" rel="bookmark"
title="Permalink to The child that grew too fast">The child that grew too fast</a></h2>
</header>
<footer class="post-info">
Published on <abbr class="published" title="2015-04-29T05:00:00"> Wed 29 April 2015 </abbr> under
<a href="./tag/security.html">security</a> </footer><!-- /.post-info -->
<div class="entry-content">
<p>The story of IT is rapidly morphing into the story of IT security. One could describe it as a farce made up of many little tragedies. No people have been dying recently due to getting hacked (at least none that we the public know about) but the employees of Sony Entertainment or the many victims of ransomware could attest to the costs of an attack to its victim. The Snowden revelations, as well as several high-profile vulnerabilities and instances of blatant disregard for customer privacy by household names (Samsung? Lenovo?) have highlighted a curious trend: The more we rely on technology, the less trustworthy we find it.</p>
<p>What might look like a paradox is actually the result of a very simple dynamic. Rising IT usage means higher stakes: more attack opportunities and juicier targets. The software infrastructure is undergoing its first real stress test, yielding lots of interesting (if unsettling) data points. Testing is mostly done by people who have the most to gain from weaknesses: spies, criminals and hacktivists. It is still not clear how much there is to lose for the rest of the ecosystem, which is why its response has been somewhat lethargic so far.</p>
<p>The problem has complex economic and social facets. In particular, there are many instances of mis-aligned incentives: those with the means to prevent an attack don't bear the brunt of it when it comes. A coder who leaves a buffer overflow somewhere in Web-facing logic is not liable for the damage incurred by users once they get hacked. Or, from a completely different perspective, employees at signals intelligence agencies don't get fired when constitutional freedoms they are ostensibly protecting get eroded by their very actions. For yet another example, a skilled hacker faces a relatively low risk of being caught and punished.</p>
<p>Optimizing incentives has been the perpetual challenge of every society since the dawn of time, of course. It would be great if the problem could be solved technologically but it's becoming obvious the new tools are no different from those before: empowering attackers and defenders, thieves and detectives, opressors and the oppressed alike.</p>
<p>Having said that, the attacking side clearly has the upper hand at this point in the game, and not just due to its intrinsic asymmetric advantage. It is simply too easy to build systems without security considerations and too difficult to build with them. That is to say, even the industry's culture and tools work against the defenders.</p>
<p>It is, fortunately, within the remit of IT to make difficult tasks easier and expensive propositions cheaper. It should be possible to use IT to make robust IT more affordable. There are, in fact, many exciting developments in this area and I hope to write about some of them in more detail in the future. As for making the disregard of security more expensive, that's a completely different can of worms...</p>
</div><!-- /.entry-content -->
</section>
<footer id="contentinfo" class="body">
<address id="about" class="vcard body">
Proudly powered by <a href="http://getpelican.com/">Pelican</a>,
which takes great advantage of <a href="http://python.org">Python</a>.
</address><!-- /#about -->
</footer><!-- /#contentinfo -->
</div><!-- /.main-column -->
</div><!-- /.all -->
</body>
</html>