Paradoxically, productivity-enhancing software that is embraced often invariably houses large amounts of sensitive data, both personal and corporate writes Mano Paul of (ISC)2.
The infamous release-and-patch cycle of software security management can no longer be the modus operandi or tolerated. A growing community of professionals, supported by the global information security professional certification body (ISC)2®, understand that escaping this vicious cycle requires a systemic approach.
Given below is a compilation of ten best practices for secure software development that reflect the experience and expertise of several stakeholders of the software development life-cycle (SDLC). These stakeholders include analysts, architects, coders, testers, auditors, operational personnel and management.
1. Protect the brand your customers trust
As cyber criminals evolve, so must the defenders. It's the defenders and their organisations that need to stay a step ahead of the cyber criminals as they will be held responsible for security breaches.
Breaches leading to disclosure of customer information, denial of service, and threats to the continuity of business operations can have dire financial consequences. Yet the real cost to the organisation will be the loss of customer trust and confidence in the brand.
Such a loss may be irreparable and impossible to quantify in mere monetary terms. Fundamentally, the recognition that the organisation is obligated to protect the customers should powerfully motivate the organisation in creating more secure software.
2. Know your business and support it with secure solutions
The answer to the question - 'Why were brakes invented?' could be answered in two ways, 'To prevent the vehicle from an accident' or 'To allow the vehicle to go faster'. Similarly, security can prevent the business from a crash or allow the business to go faster.
One must work with a thorough understanding of the business, to help in the identification of regulatory and compliance requirements, applicable risk, architectures to be used, technical controls to be incorporated, and the users to be trained or educated.
3. Understand the technology of the software
A thorough understanding of the existing infrastructural components such as: network segregation, hardened hosts, public key infrastructure, to name a few, is necessary to ensure that the introduction of the software, when deployed, will at first be operationally functional and then not weaken the security of the existing computing environment.
Understanding the interplay of technological components with the software is essential to determine the impact on overall security and support decisions that improve security of the software. Further, when procuring software, it is vital to recognise vendor claims on the 'security' features, and also verify implementation feasibility within your organisation.
4. Ensure compliance to governance, regulations and privacy
An industry that is not regulated is today an exception to the norm. Governance, risk and compliance (GRC) is a means to meeting the regulatory and privacy requirements.
One must understand the internal and external policies that govern the business, its mapping to necessary security controls, the residual risk post implementation of security controls in the software, and the compliance aspects to regulations and privacy requirements.
5. Know the basic tenets of software security
When it comes to secure software, there are some tenets with which one must be familiar: protection from disclosure (confidentiality), protection from alteration (integrity), protection from destruction (availability), who is making the request (authentication), what rights and privileges does the requestor have (authorisation), the ability to build historical evidence (auditing) and management of configuration, sessions and exceptions.
Knowledge of these basic tenets and how they can be implemented in software is a must have while they offer a contextual understanding of the mechanisms in place to support them. Some of these mechanisms include encryption, hashing, load balancing and monitoring, password, token or biometric features, logging, configuration and audit controls, and the like.
6. Ensure the protection of sensitive information
Any information upon which the organisation places a measurable value, which by implication is not in the public domain, and would result in loss, damage or even business collapse, should the information be compromised in any way, could be considered sensitive. While it may be easy to identify the sensitivity of certain data elements like health records and credit card information, others may not be that evident.
One must consider data classification and protection mechanisms against disclosure, alteration or destruction. Data classification is the conscious decision to assign a level of sensitivity to data as it is being created, amended, stored, transmitted, or enhanced, and will determine the extent to which the data needs to be secured. Software that either transports, processes or stores sensitive information must build in necessary security controls.
7. Design software with secure features
When someone is exclusively focused on finding security issues in code, they run the risk of missing out on entire classes of vulnerabilities. Security issues in design and other concerns, such as business logic flaws need to be inspected by performing threat models and abuse cases modeling during the design stage of the software development life-cycle.
Threat modeling, an iterative structured technique is used to identify the threats by identifying the security objectives of the software and profiling it. Attack surface analysis, a subset of threat modeling can be performed by exposing software to untrusted users.
8. Develop software with secure features
It is imperative that secure features not be ignored when design artifacts are converted into syntax constructs that a compiler or interpreter can understand. Once developed, controls that essentially address the basic tenets of software security must be validated to be in place and effective by security code reviews and security testing. This should complement and be performed at the same time as functionality testing.
Definition of the scope of what is being reviewed, the extent of the review, coding standards, secure coding requirements, code review process with roles and responsibilities and enforcement mechanisms must be pre-defined for a security code review to be effective, while tests should be conducted in testing environments that emulate the configuration of the production environment to mitigate configuration issues that weaken the security of the software.
9. Deploy software with secure features
Secure deployment ensures that the software is functionally operational and secure at the same time. It means that software is deployed with defence-in-depth, and attack surface area is not increased by improper release, change, or configuration management.
It also means that assessment from an attacker's point of view is conducted prior to or immediately upon deployment. Software that works without any issues in development and test environments, when deployed into a more hardened production environment often experiences hiccups.
Post mortem analyses in a majority of these cases reveal that the development and test environments do not simulate the production environment. Changes therefore made to the production environment should be retrofitted to the development and test environments through proper change management processes.
Release management should also include proper source code control and versioning to avoid a phenomenon one might refer to as "regenerative bugs", whereby software defects reappear in subsequent releases.
The coding defect (bug) is detected and fixed in the testing environment and the software is promoted to production without retrofitting it into the development environment. Further, vulnerability assessment and penetration testing should be conducted in a staging pre-production environment and if need be in the production environment with tight control.
10. Educate yourself and others on how to build secure software
As Charles Dickens once eloquently said: 'Change begets change.' When one who is educated in turn educates others, there will be a compound effect on creating the security culture that is much needed-to create a culture that factors in software security by default through education that changes attitudes. IT security is everyone's job.
