6th European Conference - Academic Conferences

Mecealus Cronkrite et al.
from possible internet damage. Stuxnet thwarted this final defence and achieved an attack through a
series of weaknesses in software practices. (Falliere, et. al. 2010)
Malware can get into vulnerable systems without detection from anti-virus measures because it exploits
trusted software. Bad programming practices result in most of the preventable malware attack.
(Goertzel et. al.2007) The Software Engineering Institute estimates that 90 percent of reported security
incidents result from exploits against defects in the design or code of software. (Mead, et. al,
2009) The defects exploited, stemmed from a relatively small number of known programming errors
such as failing to check data input before adding it to a database, hard-coding, or developing applications
dependent on over privileged accounts to run. (MITRE & SANS, 2010)
Malware has this additional hidden impact cost to the economy because the true costs of the “zeroday”
malware effect are extremely difficult to measure since they are undetectable. When software
with vulnerabilities releases on its “zero-day,” during this time attackers activities cannot be blocked or
detected. The delay between the developer knowing and making a fix available to when administrators
install it on all affected systems can lag for years. Even with patches available, the zero-day risk
is still a threat to CI when organizations or consumers are unaware of the risk or patch. Patching is a
failed program of reactive repairs.
3. Software risks to the Critical Cyber Infrastructure (CCI) and proposed mitigations
To assess potential damage caused by cyber threats, and find ways to strengthen the resilience and
defence of the CCI. “Stuxnet demands that we look not just to the security community but also to the
system designers, planners, engineers, and operators of our essential technology and physical infrastructures.”
(Assante, 2010)
One of the first rules of defence is deterrence, so approaches for enhancing the current level of CCI
defence are going to be through fixing the preventable errors. Software assurance is a way of deterrence
because it is the practice of providing high levels of software quality free of known defects.
(Wang, et. al, 2008) Techniques such as coding standards can improve deterrence by making simple
attacks fail and increase the resources needed for successful attacks.
3.1 Mitigation: Developer non-repudiation
By requiring CI software developers and publishers module code signing creates an accountability
process. To implement code signing a system similar to the web domain registration system, with a
‘WhoIS’ style lookup, could be combined with a Public Key Infrastructure (PKI) like the SSL registration
systems. Developers can start to sign all code modules or apps to an individual developer and
publisher. Major popular IDE can also support a PKI plug-in system to support code-signing development.
Certificates for code signing are already a plug-in in many IDEs.
Developer abstraction can be handled at a level similar to engineering, for example, if the senior developer
signs the code, then they are accountable for security issues later, just like an architect or
engineer is. The company management should sign the final code again so they also have tangible
accountability for the software quality. Similar to the US Sarbanes-Oxley (SOX) law requires the
CEO/CFO to sign off on the accuracy public financial records
Customer systems could be configured to disallow anonymous code to run. By forcing all software to
present credentials to run we can start to establish a trace for code that is working or failing.
3.2 Mitigation: Create development tools to assist and automate security
The government and major Integrated Development Environment IDE developers should collaborate
to create security test suites to identify common errors automatically, even to the complier level. IDEs
should check code similar to how W3C validation engines corrected for common HTML errors. This
will help programmers improve without additional cost. IDE automated test tools will transition legitimate
developers and publishers to comply with that new level of quality. With free tools for checking
code, code compliance becomes easier at all layers of development, the success of this approach
being W3C, and the rare occurrence today of unreadable HTML pages. HTML code validation is now
70