Mano Paul, CISSP, MCAD, MCSD, CompTIA Network+, ECSA Software Assurance Advisor, (ISC)²
One can consider the information age as an extension of the industrial age, characterized by the focus on 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. And while software, with its expression of extensive internetworking connectivity (Internet), has in fact made the world smaller, it has done little to make it secure.
Extremely useful and productivity-enhancing software is persistently exploited from a security standpoint or has the potential to be exploited—a concern that is 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 is 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 to a business need.
It must first be recognised that security is a process to be woven into the software development life cycle (SDLC). Software products built today are primarily focused on business functionality and features. Even though the SDLC 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 often inadequately trained to look for security vulnerabilities. Finally, when developed and released to the public as commercial-off-the-shelf (COTS) software, or deployed into production, as in the case of internal business software, software that does not factor in security through its life cycle is often rife with vulnerabilities that practically implore an attacker to exploit them.
Defining Requirements
- It’s a given that if the core tenets of security are not 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 aid 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 (CIA) 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), Authorization aspect (rights of the requestor), and Auditing aspect (accountability or building historical evidence).
- If software is to be bought, rather than built in-house, developing the procurement requirements is important.
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 are not 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 prioritization-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, and although it is a very important and critical step in the SDLC, 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, 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 is not 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. But when deployed to a more tightly controlled and secure production environment, fails. In such situations, administrators often are 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 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 minimized 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, auditing and continuous monitoring to ensure that software security is not affected or reduced over time. Finally, it is vital to ensure that when software is disposed, 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, the loss in reputational damage and brand, loss that, in many cases, is 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 of the stakeholders in the SDLC process, one that makes security second nature in the software they are responsible for building.
Mano Paul is the Software Assurance Advisor for (ISC)², the global leader in information security education and certification, representing and advising the organisation on software assurance strategy, training, education and certification. His information security and software assurance experience includes designing and developing security programs from compliance-to-coding, security in the SDLC, writing secure code, risk management, security strategy, and security awareness training and education. The International Information Systems Security Certification Consortium, Inc. [(ISC)²®] is the globally recognized Gold Standard for certifying information security professionals. Founded in 1989, (ISC)² has certified over 60,000 information security professionals in 138 countries.
Infor
(ISC)² is exhibiting at Infosecurity Europe 2009, the No. 1 industry event in Europe held on 28th – 30th April in its new venue Earl’s Court, London. The event provides an unrivalled free education programme, exhibitors showcasing new and emerging technologies and offering practical and professional expertise. For further information please visit www.infosec.co.uk
Source: Infosecurity PR
<>
Seed Newsvine