(Original creator: bolarotibi)

Guest contributors, Bola Rotibi and Ian Murphy from analyst firm Creative Intellect Consulting

Secure software delivery: who really owns it?

Fighting back: An important role for Quality Assurance (QA) and testing

Inside the IT department, many see QA as being responsible for catching problems. As a result they are often seen as being the least prone to errors in the way that they work, but they are certainly not blameless. What is needed is more integrated approaches to the way that testing and Quality Assurance is carried out and processes were the teams can contribute to the discussion for better security and in reducing the bug count earlier. One of the weaknesses in QA and testing has been the "last minute" approach that many organizations adopt. When projects are running late, QA is the first thing to get squeezed in terms of time. There is also a significant cost associated with QA and testing with test tools often being seen as too expensive and too hard and complex to understand and implement. However, the costs of poorly developed software must surely outweigh the costs of getting it right? Besides which, the costs have rapidly decreased with new players on the scene and the availability of on-demand elastic delivery models of Cloud and Software as a Service (SaaS) offerings. There are also vendors with tools and services that look to improve and simplify the testing process across heterogeneous infrastructure and application platforms. A security perspective added to the testing strategy of such solutions will do much to address the security holes as a result of the complex environments many applications now operate across. Clearly, the earlier software security is addressed the better. Addressing security from the outset should have significant impact on the security quality further downstream. Strategies that look to promote continuous testing throughout the process, especially for security issues, will help strengthen the overall quality goals. Improving the foundations is a good basis for secure software delivery. Team review processes and handover policies also serve as good security check points as does the build and source configuration management process where continuous integration can be employed.

A better process for securing software required:  10 guiding points

To minimise the risk of insecure software entering the enterprise software stack, there is a need to rethink how the software development process works. This is not just about the developer but about the entire business, architects developers, operations, security and even users.

1. Board level commitment: No enterprise wide process can be effective without board level commitment. Any security breach resulting in the loss of money, data or intellectual property (IP) will raise questions as to governance. This is a role owned by the board and every C-level executive must engage and understand the risks.
2. Secure enterprise: At the heart of any secure software process is an enterprise wide secure by design philosophy. This requires an understanding of how software will work and a solid security framework for data and access. Responsibility for this lies with architects, security and operations.
3. Processes: A lack of proper process is the wide open door a hacker is looking for. Testing, version control, change control, staging, patch management - these are all essential processes that have to be implemented to create a secure environment.
4. Encryption: All data inside the enterprise should be encrypted irrespective of where it is stored. Encryption of data in transit is also a requirement. Software must be able to ensure that when it uses data, it does not then store it unencrypted, even in temporary files.
5. Secure architecture: Software architects are responsible for making sure that all software is designed securely. Validate all technical and functional requirements and ensure that the software specification for the developers is clear and unambiguous.
6. Unit tests: This is an area that has grown substantially over recent years but one where more needs to be done. Security teams need to engage fully with developers and software testing teams to identify new risks and design tests for them. The ideal scenario would be for the security team to have their own developers focused on creating unit tests that are then deployed internally.
7. Maintain coding skills: One of the reasons that software is poorly written is a failure to maintain coding skills. This is often caused by the introduction of new tools and technologies and the failure to establish proper training for developers. Providing "how-to" books or computer based training (CBT) is not enough. Developers need training and it should be part of an ongoing investment and quality improvement programme.
8. Test, test, test: When a project runs late, software testing is often reduced or abandoned in favour of "user testing". The problem with this is that proper test programmes look at a much wider range of scenarios than users. In addition, once software is in use, even as a test version, it rarely gets completely withdrawn and fixed properly. Instead it gets intermittent and incomplete patching which creates loopholes for hackers.
9. Implementation: As software delivery timescales reduce, there is pressure on operations to reduce their acceptance testing of applications. Unless operations are part of the test process, unstable applications will end up in production exposing security risk. This is an area that has always been a bottleneck and poorly planned attempts to reduce that bottleneck increase the risk to enterprise data.
10. Help desk should be part of software development: This is an area that is rarely dealt with properly. Most help desk interaction is about bug and issue reporting with a small amount of new feature work. Help desk has a view across all enterprise software and has an operational and user view of risk. Using that data to reduce the risk of making repetitive mistakes will improve software quality.

The above is not an exhaustive list of steps that can be taken to harden the software security process. However, it does provide a framework against which an enterprise can assess where it has weakness.

Are there differences between small and large software code providers?

A worrying issue voiced by small consultancies attending the CIC secure development forum was that one of the biggest challenges to software security came from the fact that almost everyone is expecting someone else to tackle and deal with any of the concerns and requirements. There is clearly a divide between what developers in smaller firms can expect to achieve from a secure software perspective, against those within larger teams and larger enterprise organizations. A small consultancy that does not specialize in software security can only expect to focus on what it can do within the context of its remit if clients are not willing to pay for the “bank” grade security they might desire or their marketing messages all too often claim. Such firms rarely use any tools or processes over and above the normal mechanics of their job or that of their competitors. This doesn’t mean they are entirely bereft of secure software principles or education. On the contrary, a number of these firms discuss security processes and issues regularly (quarterly for the most part) and review policies annually.  That said, some expressed a desire to do more to provide better education and training within a realistic and pragmatic framework for continual improvements. Current governance models are loosely based on internal standards that developers are encouraged to follow. Quality is checked and maintained through peer reviews. But it is not enough. The development teams within large organizations are not without such challenges either, because whilst code reviews are carried out, they are not always up to standard. Worse still is the lack of knowledge often found within the development team for tools that exist to help support the delivery of secure software applications for a broad spectrum of deployment environments. Nor is this helped by the fact that equipping all the developers of a large team with software security tools such as static analyzers can be significantly costly and time consuming to implement and train.

The communication hurdle

There is a challenge of communication that is no less different for larger enterprise organizations with the resources to employ and assign dedicated software security specialists than it is for smaller ones without the expertise. At the heart of the communication issue is language and process, where the language used by software security roles is not couched in terms recognizable to the software development and delivery teams. Nor is it clearly couched in terms of business risk or business issues that would then allow a level of prioritisation to be applied. The process issue is one of lack of insight into the workflows across the application lifecycle where intervention can have the significant impact. There is often a need to translate the security concepts within the context of the development process before a software security risk or vulnerability can be addressed sufficiently. For too many, the disconnect between the language of the security experts and those responsible for, involved in or governed by the development process, is a significant barrier.

Because I have to...not because I want to

Whilst organizations within the financial sector generally tend to put in more effort in focusing on secure software strategies and are for the most part open to addressing and fixing the issues, they are driven to do so by regulations and the regulatory bodies. Or, as one organization so succinctly stated: If we didn't have to comply with the PCI standards, we wouldn't be as far along in our capabilities for addressing software security and implementing the necessary prevention measures and checks as we are.

Accountability for all

Software security is not all about the code. The way an application is architected, the choice of platforms, tools, and even methodology, all impact the way the code is written. Despite this, we still resort to blaming the developer when it all goes wrong. The main reason for this is because the other roles, tools, and elements of the development process are often invisible to the software owner or end-user client. This makes the developer an easy target for derision. For a short period of time in the late 1980's and early 1990's we tried to make each developer a one-person team (analysts, developer, DBA, QA). As a result placing the majority of the blame on the developer had some limited relevance, but this is not the case today. As we can see, ownership of blame when it comes to secure software delivery lies in many quarters and for many reasons. Developers are far from being the weakest link in the secure software chain of defense. There are many layers that you can use to improve the security of software and the application lifecycle process, one of which is to go beyond code development, and to look to empowering developers to become more involved and accountable for secure software strategies. They need to be better educated in the language of security vulnerability and the processes that lead to it as well as being and more aware of the operational and business consequences. They need support in their endeavours. Good quality code is a must. There is still much needed focus on well developed quality code to combat the occurrences of security breaches. But so long as securing software is dealt with as a separate channel and a siloed functionality abstracted from the wider development and delivery workflow, and laid solely as an issue for the developer, delivering secure software will be a challenge hard to overcome. Ultimately, businesses determine the risks they can accept. The job of the IT organization is to provide the language that can detail their risks in terms that business owners understand i.e. predominantly financial, and or economic, both of which underpin competitive goals and growth aims. Only when they do will the business owner understand what the risks truly equate to and thereby act and support accordingly. Understanding the security vulnerabilities within the development and delivery process from a business risk perspective will be a crucial first step in that direction.