Information Technology Reference
In-Depth Information
A Counter-Intuitive Approach from Field Sports
An interesting lesson that information security can learn from sports is to
know what exactly to defend and how to act when an attacker has entered
a secure perimeter. In soccer or field hockey, for example, if the ball is
lost to the other team, the quickest way to recover is to simply run straight
back toward one's own goal. Defenders have the singular objective to
protect the ball from crossing their goal line. They need to assemble and
create a cordon around that area. The defensive danger zone is recognized
as the area in front of the goal. In that zone, defense players are coached
to clear the ball quickly, to kick the ball hard and far — this is not the
place to dribble. Similarly, if there is a breach in one's software system,
focus on protecting the key assets before trying to repair the breach.
The Human Perspective
Human factors are critical to security. They impact security in at least two
ways — once during development and the other during operations.
Software development lies in the domain of individuals. The programmer
is supposed to be conscientious in his or her coding practices. To a large
extent, writing “secure code” has not been their highest priority. It cannot
be assumed that developers know how to write secure code to begin with.
This is no different from the fact that developers cannot be presumed to
know how to deliver systems tuned for performance. Most coding is done
to meet functionality, by which is meant business functionality, while
security and performance do not get delivered automatically.
Recognizing this situation, an organization should evolve security cod-
ing guidelines for developers to follow. These coding guidelines should
include technology-specific suggestions because vulnerabilities differ
between technologies. Guidelines should cover all aspects of the devel-
opment life cycle. It should include the use of tools such as software
configuration and source code management (SCM) so that access to the
code can be controlled and traced. One should also introduce peer reviews
of code and documents to determine potential security vulnerabilities.
People can introduce security flaws in systems — sometimes unknow-
ingly, and at other times with malicious intent. People have been known
to join organizations just to find the security systems used. Breaches in
banks have occurred with the connivance of staff members.
Most IT organizations now believe that an overwhelming majority of
their developers use their computers irresponsibly and do not follow
instructions of their IT staff. They download open source modules or
“objects” from unsafe places, install unauthorized software, and are almost
borderline casual in sharing “company confidential” programs to others
