Building Secure Systems
Hardly a month has gone by in recent years without the news of a cybersecurity disaster. The scales are
staggering – 117 million (LinkedIn), 145 million (eBay), 143 million (Equifax) etc. This must keep CEOs,
CIOs, CTOs up at night in tenterhooks. This first article in a series attempts to cut through noise clamoring
for a CXOs attention with simple, specific, and actionable steps to reduce their company’s cybersecurity
vulnerability and their own anxiety. These articles are based on my experience writing code for twenty-five
years, fifteen writing security software.
At the heart of recent hacks and vulnerabilities, to take just a fewrepresentative hacks,
2014 Heartbleed – single line of defective code
2014 Sony Pictures – help from insider
2016 DNC – phising malaware
2017 Equifax – single unchecked parameter in web URL
lies human behavior – behavior of personnel, users, and attackers. To take an example, this one line of
memcpy(bp, pl, payload);
in OpenSSL, used by millions of web servers world-wide, opened up a serious vulnerability via which it was
possible to steal sensitive information. By simply lying about length of memory in pl, i.e. by providing an
actual payload less than the payload sent, an attacker could read the web server memory; such memory can
contain security keys, personal information – essentially game’s up at this point.
But, and here lies the silver lining, human behavior is not static. It can be influenced, something that
should resonate with CXOs who are masters at influencing behavior.
In this article, I focus on influencing the behavior of the greatest weapon in the arsenal of a CXO in
taking on the cybersecurity challenge head-on – the technical staff that delivers his or her solutions. Future
articles will focus on influencing the behavior of users and attackers.
1 The Technical Team
The right technical team, operating in a supportive and empowering environment, can be charged with the
lofty but achievable goal of making hardened and resilient security systems.
1.1 Who Should Work on Your Security Problems?
Whether security solutions are developed in-house or procured, CXOs msut take cognizance of the fact that
pure mathematics and theoretical computer science have become the most prized skills in almost every single
business; number theory, abstract algebra, topology, analysis, probabilistic algorithms, algorithmic analysis,
long since key components of cryptography, are now even more critical. Armed with nearly infinite computing
power and budgets, state actors can wreak havoc with a torrent of attacks. It is through mathematical,
algorithmic, and implementation ingenuity that there is any hope of thwarting these attacks and building
hardened and resilient systems.
1.1.1 Team Composition
CXOs should ensure that the team that builds their security solutions has the following composition:
Mathematicians: Cryptographers and cryptologists who are also competent programmers
Computer Scientists: Algorithm designers who are also competent programmers, and have substantial
System Designers: Business savvy systems engineers who are also competent programmers,
and have substantial math background;
System Administrators: Programmers who have a deep understanding of operating systems, internet
and security protocols; they must also be algorithms and math savvy;
Engineers: Programmers who have a substantial math and theoretical computer science
Typically the team will have advanced degrees in Pure or Applied Math, Computer Science, Electrical
Engineering, and Physics from reputable universities with reliable references; it will likely be led by a System
Desginer who straddles math, computer science, engineering, and business functions comfortably.
1.2 What Environment Will Galvanize the Team?
Genuine Security experts are some of the brightest minds you can find anywhere – they work on multidimensional
problems simultaneously optimizing mathematical accuracy, algorithmic efficiency, implementation
correctness, and user-convenience. The first step CXOs can take to fire up the team and elicit their
loyalty, commitment, and attention is to take cognizance of their immense gifts. Additionally, they should
Decision Making make the security team a key part of the decision-making process; with deeply analytical
and creative minds they are apt to surprise CXOs by their ingenuity, even in devising
solutions to problems outside their focus area;
Conferences make sure they attend tier-1 security conferences; this will give them an opportunity to
form alliances and working relationships with the best security minds in the world;
Tools make sure they have the best hardware and software at the office and at their homes –
this includes the latest workstations and laptops, multiple large montors, smart phones,
tablets, test equipment, and software they need to write code, run simulations and diagnostics;
No Distractions make sure they don’t have any distractions; when security staff are distracted with unimportantmeetings
and events, it comes at a non-trivial cost; firstly, it takes time to return to
the same dense context they had prior to the meeting, and secondly, it increases the probability
of a defect creeping in – that distraction may just have cost the company a very
large sum of money; security staff should not be subjected to unplanned and impromptu
activities, and have long stretches of time to concentrate; companies that provide food,
beverages, an exercise facility, concierge services etc. reap the benefits of high productivity
and low context-loss.
1.3 What Lofty Goals Should CXOs make Team Track to?
As someone who has been writing code for twenty-five years, of which the latter twenty years writing correct
and defect-free code, and fifteen years writing security software, I assert that that it is possible to write correct
systems and systems known to adhere to the best security practices. Once aworld-class teamis assembled or
identified, CXOs can and should charge it to build correct and secure systems the first time around; it is easier
to maintain a high standard of correctness and security from inception than to introduce them mid-stream.
Hardware standards insist on building software to hardware standards; a hardware mistake takes weeks
to fix, making hardware engineers naturally careful; a mistake in software takes less
time to fix, and a miniscule amount of time to build – this makes software engineers
sloppy – when software is built to hardware standards, far fewer defects will arise;
High fidelity insist on high fidelity representation of facts by team i.e. every assertion, every claim
made by team must be verifiable; a culture of high-fidelity representation takes time
to build, but once built, CXOs are armed to act confidently with their customers and
Extreme diagnostics insist that no failure, during development, testing, or deploymentmust be unknowable
– if somethingfailed, teammust be able to tell exactlywhere and why it failed quickly;
this is possible only with a culture that practices extreme diagnostics;
High visibility insist that every activity of the team must be visible within the team and visible to
middle-managers and CXOs via
• granular and specific goals whose completion can be objectively measured;
• clear relationship between individual goals(stories)and larger goals (epics);
• unwaveringand relentless process for trackingprogress and taking corrective
1.4 How can CXOs Cross-check Team’s Process andWork Products?
CXOs should adopt the trust, but verify approach – create, promote, or identify a security team according to
the principles laid out in this document, charge it with a lofty goal, but also verify their progress and output
via external and independent audits. Care must be taken that the necessity for external and independent audits
is bought-in by the security team.
Rate this article
Please rate this article to publish more quality articles.
Subscribe to our newsletter and receive the latest research and insights from Draup.