Some might say that the information age is an extension of the industrial age, characterised by a focus on the production of physical goods. Today, most manufacturing efforts are augmented – and, in some cases, managed – by components of the information age.
With software, technical solutions to business problems are possible. With software, we can all be connected. While software – with its expression of extensive connectivity (via Internet) – has in fact made the world smaller, it has done little to make that same world more secure.
Extremely useful and productivity-enhancing software is persistently exploited from a security standpoint or has the potential to be exploited – a concern that’s true for both existing and newly developed releases. Few realise, however, that while some of the insecurity in software could be the result of the technology chosen, it’s important to note that software products are predominantly insecure due to two other elements – people and processes.
Any software is the result of a confluence of people, process and technology. Secure software is the result of educated and informed people implementing hack-resilient processes using inherently secure technologies to provide solutions for a defined business need.
Security as a process
It must first be recognised that security is a process to be woven into the software development lifecycle. Software products built today are primarily focused on business functionality and features. Even though the software development lifecycle may cover quality control planning and testing, seldom does it incorporate security holistically.
Adequate security controls are lacking while security requirements are, in many cases, non-existent. Use cases are not complemented with their inverse misuse cases. Developers are driven to deliver functionality with deadline and scope constraints, pushing the writing of secure code to the sidelines. Testers are very often inadequately trained to look for security vulnerabilities.
Finally, when developed and released to the public as commercial-off-the-shelf software, or deployed into production (as in the case of internal business software), software that doesn’t factor-in security through its lifecycle is often rife with vulnerabilities that practically implore an attacker to exploit them.
Core tenets of security
It’s a given that if the core tenets of security aren’t included as requirements, then the software when designed is probably not going to have them. The business must be engaged during the requirements-gathering stage to address security aspects and assist in the understanding of the risk or protection requirements. It must:
– respect established policies and standards for the organisation and be compliant with audit requirements. Software requirements must also take into consideration the regulatory (legal), compliance and privacy requirements at a local and international level
– reflect confidentiality, integrity and availability objectives of the software. Is the data or information open for viewing by all, or should it be restricted (confidentiality requirement)? What are the factors that allow for authorized alterations, and who is allowed to make them (integrity requirement)? What is the accessibility of the software and what is the allowable downtime (availability requirement)?
– consider the software authentication aspect (proving of claims and identities), the authorisation aspect (rights of the requestor) and the auditing aspect (accountability or building historical evidence).
If software is to be bought, rather than built in-house, developing the procurement requirements is important.
Managing the project
Even in cases where security requirements are determined, they often run the risk of being dropped from the feature specifications or being lost in translation due to the constraints of time and budget and/or a lack of understanding of their importance.
Project managers should plan and allow for time and budget to ensure security requirements aren’t ignored. From the vantage point of security, it’s not only important that the functionality of the software is depicted in use cases, but also critical that the inverse of the use cases (misuse cases) be modelled to understand and address the security aspects of the software.
The ‘security’ design and architecture reviews should be included when the teams are engaged in the ‘functional’ design and architecture review of the software. Threat modelling is useful for ensuring that the design complements the security objectives, making trade-off and prioritisation-of-effort decisions, besides reducing the risk of security issues during development and operations.
Contrary to popular opinion that software security is all about writing secure code – there’s no doubt it’s a very important and critical step – secure code writing is only one of the various steps necessary to ensure security in software. A security plan, generated during the design phase of the project, must also be revisited and adjusted if necessary.
Educating testers to become software security testers boosts the technical aptitude of the quality assurance organisation. In post-development situations, a risk assessment will help identify the risks that have been mitigated and the ones that still need to be addressed.
Pressure to reduce controls
All efforts to design and develop secure software are rendered futile if the software isn’t securely deployed and maintained. Software development that does not factor in least privilege often produces software that runs without any issues in a lax development environment. When deployed in a more tightly controlled and secure production environment, it fails.
In such situations, administrators are often forced to reduce the tight control or increase the rights with which the software will run, both of which are forms of insecure installation. Software should therefore be tested in environments simulating the production environment, be it a system integration testing environment or the user-acceptance testing environment.
Once deployed, change control and configuration control should be in place to ensure that only approved changes are made to the code base of the software. Versioning of software with auditable check-in and check-out procedures is essential, while direct access to production source code should be minimised with explicit authorisation and controlled scrutiny.
Other considerations include a process for recertification and reaccreditation, an incident management plan to establish and track reporting and management of incidents and both auditing and continuous monitoring to ensure that software security is not affected or reduced over time.
Archiving information for future retrieval
Finally, it’s vital to ensure that, when software is disposed of, information that would be needed at a later timeframe is archived for future retrieval by secure means. In cases where data and software is highly sensitive and no longer necessary, it must be physically destroyed.
With software deeply impacting our everyday lives, the need for it to be secure is an absolute necessity. The real cost of insecure software is not merely the quantifiable fines imposed on the negligent, but also the loss in customer confidence, reputational damage and brand failure. Losses that, in many cases, are irreparable.
When it comes to building secure software, people can be the strongest force or the weakest link. The client or customer should be aware of the need and importance of incorporating security into the software product they request. The requirements analyst should be trained to solicit and translate functional requirements into security requirements.
The project manager should be versed in making necessary project-related decisions and so on. A primary shift is necessary in the mindset of all Stakeholders in the process – one that makes security second nature in the software they are responsible for building.
Mano Paul is the software assurance advisor at ISC2
ISC2 will be exhibiting at Infosecurity Europe 2009 – Europe’s leading event dedicated to information security. Now in its 14th year, the show continues to provide an unrivalled education programme, the most diverse range of new products and services from over 300 exhibitors and attracts circa 12,000 visitors from every segment of the industry.
Running from 28-30 April at London’s Earls Court, the show is something of a ‘must attend’ event for all professionals involved in the information security space. See our dedicated link on the right hand panel of this page for more details
