You simply can’t test your applications secure. It’s a mantra preached to software quality audiences many times over, and a concept well understood by seasoned information security professionals. What can be done to advance the security state of modern applications? Today, more than ever before, the volume of applications being churned out by a typical enterprise is reaching epic proportions. Despite all the negative press from security breaches, applications are being deployed with more security defects than ever before – even with all the available tools, published processes and best-practices. Why? Or more importantly, how can this trend be stopped and even reversed?
The secret lies in the way that software is built. The problem is that in many cases security teams are doing most of the work. All the effort is happening right before the application is released to production environments, which is long after the software has been built and tested. Often, security teams still find themselves testing applications after they’ve gone into production only to find bugs no one can realistically act on quickly – if at all .
It doesn’t have to be this way. What we’re learning through building software security assurance (SSA) programs is that while every organization handles development, testing and release differently, every single development project still fundamentally buds from one basic tenet. Whether the development organization is holding steadfast to the waterfall development methodology, has jumped to Agile, or is using its own “hybrid” thereof, at the core of every development cycle is one basic principle – the requirements. Requirements are the most basic building block of any application. Requirements are what drives the development process forward and, more importantly, links the business needs to an application’s purpose. It is in these requirements that security should be embedded.
While there are different types of requirements- business and technical requirements, functional and non-functional-the basic idea is that without requirements there is no reason to write code. Below, we look at how the overall security of an application can be greatly increased by simply injecting security upfront in the requirements management stage of the application lifecycle. While this is certainly no trivial task, the idea is to create a process where security teams are no longer struggling to “bolt on” security as an afterthought.
Business Requirements
The business will not say that security unimportant to the organization, but it is one thing to say that and another to make security a business requirement in application development. Security as a business requirement is undoubtedly a challenging conversation if the organization does not view security as a core tenet of the business. On the other hand, there are many other ways to see security as a business requirement – for example, compliance with industry and governmental regulations. You do not have to work for the Department of Defense, or other Federal agencies to have security as a core requirement. If we look at a few of the industry-mandated regulations such as the Payment Card Industry (PCI) and Health Insurance Portability and Accountability Act (HIPAA), the goal of many information security teams may be to make the applications “more secure.” However, other organizations may simply want to meet these compliance requirements. When organizations prioritize security, the appropriate business requirements can be properly implemented into the application development phase, which can lead to security as a measure of compliance.
A very simple business requirement may read, “Meet PCI compliance regulations” for an application, but that quickly translates to a much more technical need once that business requirement gets translated to technology requirements. The key is to make security requirements at the business level “high level” enough to where they provide business value (such as the ability to process credit cards as a result of being PCI compliant), but also able to provide value downstream as technical requirements.
Technical Requirements
Technical requirements are the embodiment of the business requirement, in a way that can be executed within the framework of your testing organization. Meeting PCI requirements may be a business goal (business requirement) but that’s hardly anything that can easily be acted upon to determine pass/fail status. Translating business requirements into more detailed, technical requirements must be done effectively and it takes some practice.
Typically each high-level business requirement breaks down into several technical requirements that can then be acted upon and linked directly to tests. In other words, there is a many to one mapping between technical and business requirements. For example, if we look at PCI as a [compliance] business requirement there would be several technical requirements. In a waterfall application development lifecycle, all code would have required a pre-determined level of assurance (via testing) before being allowed to move from development into testing. In the Agile development world, each high-level business requirement must be tackled by an associated sprint that seeks to meet the technical requirements during that phase.
The key to having solid technical security requirements is two-fold. First, they must easily map into the business security requirements. Second, they must be actionable in an automated or semi-automated fashion using established tools and processes.
For example, being able to trace a business requirement to associated technical security requirements to a pass/fail requirement state should be considered a necessity in any mature, risk-averse software development organization. Further, having the ability to trace from high-level requirements at the business level all the way to test execution, results and ultimately feed back into a subsequent requirements gathering process is critical. Completing the feedback loop from results back to requirements feeds continuity and keeps security from being a “bolt on”.
Functional and Non-Functional Requirements
Distinguishing between functional and non-functional security requirements is also crucial. While functional requirements may define features, non-functional requirements define concepts that development organizations must adhere to when writing code. Both of these are critical when it comes to understanding security, and creating software with minimal security defects.
For example, a non-functional requirement may be defined as follows: “No critical security defects as defined by information security development policy.” This non-functional requirement dictates criteria that can be used to judge the function of the application. Conversely, a functional requirement may be defined as follows: “Implement sanitization method A on all input functions (data sources).” Both of these are technical requirements and can be tested against for a pass/fail status.
Striking the right balance between being high-level enough to make the requirement viable across the organization and technical enough to make it useful when mapping it to a testing strategy for pass/fail is critical. When executed well, this balance acts as a brilliant business-based mechanism to ensure that applications are developed with minimal security defects. Well-defined security requirements can be an organization’s most effective tool to produce better quality applications at the code level. Having the ability to directly impact the motivation behind a development process ensures that security is not an afterthought.
Closing the Loop
One issue remains in developing security into the requirements management phase.
It is inevitable that defects will slip though the process only to be caught after development, despite everyone’s best efforts. At this time a key decision must be made – does the defect stop the application from going live? A decision needs to be made at this moment, and while the details of that decision are not the subject of this article, the result is one of three outcomes: fix, accept or defer the defect. If the defect is to be fixed, the application release halts while the defect is ultimately fixed, re-tested and certified before the application goes live. If the defect is accepted, a risk-based decision is made to simply enter the defect as part of acceptable risk. Everyone then moves on knowing the defect will not be fixed (at least not at this time). If the defect is deferred, it means that it will be fixed at a later date, but that it is scheduled to be fixed. It is as this point that requirements management is critical again.
Closing the loop here is extremely important. It demonstrates the power of proper requirements management by feeding the deferred defects back into a future iteration of the development. That defect is then able to be formally assigned, measured and tracked to successful closure at an appropriate future release of the application code. Tracking and measuring defects in such a way is an achievement for maturing development organizations. It demonstrates not only an acceptance of security principles, but also a deeper responsibility at the business level to release more risk-averse applications.
As a best practice, building security into the requirements stage of the application lifecycle is very powerful for security professional’s toolbox. It is only fitting; therefore, that this is a core principle of a typical software quality organization. QA teams in IT organizations have been managing requirements, testing them and reporting on their success or failure for as long as software has been tested. It is through integrating and utilizing these methodologies that information security organizations in the enterprise can achieve measurable gains in software security assurance.
EBOOK: Lessons from IFSEC 2023 – Big Tech, Martyn’s Law and Drone Threats
Read IFSEC Insider’s exclusive IFSEC eBook and explore the key takeaways from the 2023 show!
Navigate the impact of Big Tech on access control, gain insights from Omdia’s analysts on video surveillance trends, and explore sessions covering topics like futureproofing CCTV networks, addressing the rising drone threat, and the crucial role of user proficiency in security technology.
There's also an exclusive interview with Figen Murray, the driver behind Martyn's Law legislation.
