Why software quality assurance and IT security need to work together
The unification of software quality assurance (QA) and IT security results in a symbiotic relationship, yet only a few organizations have started to realize the benefits of these two separate teams working together. The alliance of quality assurance and IT security is natural, because IT security is a form of quality assurance at its basic level. A security exposure in any form is a quality assurance issue.
Both IT security and quality assurance are concerned with removing risks. IT security teams work to remove security risks, and quality assurance teams work to remove risks to quality. So, this alignment needed to happen years ago. This article explains the natural behavioral integration points between the two departments, as well as how integration among the IBM® Rational®, Information Management, WebSphere®, and Tivoli® Security families of software products could help.
The first area of interest between quality assurance and IT security is related to access control. Access control is forever changing and evolving, based on internal organizational standards and external regulatory compliance changes or for IT security policy reasons. Typically, access control has been left to the software development team. It is treated like any requirement and has to compete with other requirements to be realized in an application. This practice has caused difficulty for IT security and audit teams in tracing and changing access control policies as quickly as the regulatory compliance requirements, such as SOX, HIPAA, PCI, and others change.
When access control policies are written into the application, these policies must contend for the same resources as application enhancements and improvements. Application owners are more likely to want to spend money on application improvements and enhancements than on updating the access control policies. Ultimately, this creates the need to externalize the access control policies from the application. In addition, the changing nature of compliance further complicates the need for external access controls. Organizations realize that externalizing access control cannot happen without consequences.
How, then, do we externalize access control from the application? IT security needs to get involved in the software development life cycle (SDLC).
The policies need to be approved in the same way as any other requirements. The security policy needs to be listed in the requirements document, ideally by using IBM® Rational® DOORS®, Rational® RequisitePro®, or Rational® Requirements Composer. This is important because, as security policies change, so will the access control. Understanding and tracking these changes is a best practice. The quality assurance team works with the application owners all of the time and could be able to provide this level of support for access control policies.
The emerging standard in access control today is Extensible Access Control Markup Language, or XACML, which is a reusable XML-based standard used for access control. XACML is all about giving the right people the right information at the right time. Many companies adopt XACML without considering the process needed to be successful in implementing it. By building your XACML process into your SDLC, you build cohesiveness with the software development team. This approach is excellent for organizations that already have application policy management security built into the application.
Organizations considering an XACML approach for security policy management are often inhibited by the notion that removing all of the existing security policies from the legacy applications and recreating them with XACML would be impractical. This approach gives organizations the ability to keep their existing security policies in place while creating new security policies in XACML. By working with the quality assurance team, you are, in fact, embedding your XACML process into the SDLC, which means that changes can be made to both the application and the XACML architecture if necessary. This removes the need to take out all of the security policies from a legacy application and enables you to take a more flexible approach. You can then decide whether to change the legacy policy or to use or a new, reusable XACML policy.
If you're considering using IBM® Tivoli® Security Policy Manager as an XACML policy-authoring tool, software such as IBM® Rational® ClearCase® and IBM® Rational Team Concert™ could be used as source control for the access control assets. The Tivoli Security Policy Manager assets are XML-based and can easily be stored in either tool. Automated tests can be created using IBM® Rational® Functional Tester and IBM® Rational® Performance Tester. You can then automatically test the behavior of the XACML scripts when you release new versions of products. In addition, tools such as DOORS, RequisitePro, and Rational Requirements Composer allow traceability from the requirements to the Tivoli Security Policy Manager assets. Figure 1 represents Rational Requisite Composer housing nonfunctional XACML requirements for a system.
The IBM® WebSphere® ILOG has functionality that allows the business rules management systems to feed both the Rational Requirements Composer engine and the Tivoli Security Policy Manager products to allow for a high level of abstraction and greater traceability throughout the enterprise. Using the products together not only allows an organization to externalize their access control but do it in a repeatable, sustainable, and natural way that allows for growth and change.
Figure 1. Rational Requirements Composer view of nonfunctional requirements
Organizations today tend to develop applications without any thought of security until the application is fully developed. This is the typical "let's throw it over the wall to the IT security team" scenario. The problem with this scenario is that any security problems identified just before deployment will cause either the development team or the IT security team big headaches. Either the product is going to be deployed with security holes or the application is going to be delayed, because it needs more cycles through the SDLC to remediate the security risk.
QA teams figured out a long time ago that quality assurance professionals need to get involved in the early stages of the software development life cycle for several reasons. The first reason is that finding quality issues just before a deployment causes big headaches. But QA also discovered that finding problems during the requirements-gathering phase is much easier and cost-effective to correct during the requirements phase than after developers has written something. Being involved early in the SDLC is also helpful so that quality assurance teams can start building test cases and test scripts ahead of the software builds.
Security needs to be doing the same thing, working hand in hand with the QA team, systems analysts, and developers to help the systems analysts gather requirements and build the security design in the software design. IT security analysts need to also design the types of tests that need to be run at each stage. IT security professionals, in conjunction with the quality assurance team, needs to write test cases and test plans for each test that the IT security team wants.
Over the last half-decade, hackers have started attacking web applications because quality assurance teams and IT security teams didn't work together, leaving huge holes in applications. This action from the hacking community has forced another collaboration point between QA and IT security. The idea here is to start the security testing earlier in the software development life cycle. The QA and security teams will define nonfunctional requirements that developers will need to adhere to. These nonfunctional requirements are the foundation for building security-minded development teams, and the QA team needs to work hand in hand with the IT security team at the outset. The IT security team, in conjunction with the quality assurance team, could help build a center of excellence to define the standard security coding practices and security testing, as well as to define the programmer's education levels and security training.
The simple truth is that catching security holes earlier costs an organization less to remediate, which makes good business sense. On the other hand, waiting for an application to be deployed or to be near deployment before catching security holes is a bad practice. Quality assurance teams have struggled with building security testing because security tests are different from functional and performance tests. In functional and performance testing, the expected results are documented before the test begins, and the quality assurance team looks at how well the expected results match the actual results. In security testing, the quality assurance team is concerned only with unexpected results and testing for the unknown. IT security teams can help the QA team build these tests. The IBM® Rational® AppScan® family of security software can be extremely helpful in jump-starting a QA team into application vulnerability testing. Rational AppScan can be run against applications to find security holes at the application or infrastructure level.
Enterprise single sign-on
Many organizations today have started to go down the path of enterprise single sign-on, because it offers both a cost savings, in terms of a reduction in the time needed to access data, and improved security, in terms of password management. One of the challenges of enterprise single sign-on is profiling the clients to work with the various applications within the organization. Due to the dynamic nature of login screens, the enterprise single sign-on ESSO client could have a difficult time recognizing the screens and fields used by IBM® Tivoli® Access Manager for Enterprise Single Sign-On (TA MESSO).
Security teams could turn to the quality assurance automation team for help with the more difficult profiles. The process of creating an advanced profile is similar, in many ways, to the process of creating an automated test script. Quality assurance teams that work with automated scripts have a greater understanding of how the windowing systems work, so they could provide insight into how screens behave. In addition, because automated software testers spend multiple hours a week understanding the behavior of application screens, the tester can offer a pragmatic approach to debugging a complicated login screen.
In addition, tools such as IBM® Rational® Functional Tester and IBM® Rational® Robot could be used in troubleshooting to find out why a screen is misbehaving. Validation point checks in the functional testing tools can be extremely helpful in understanding what properties are changing in a given field. Figure 2 is a screen capture of Rational Functional Tester displaying vital login window properties through a property validation check and highlighting a property that is changing. The information displayed in Figure 2 would be difficult for a security team to figure out, but easy for a tool like Rational Functional Tester to identify. Automated software testers have many tricks, such as WinSpy and other tools that can be extremely helpful in debugging changing windows. Organizations could leverage the same resources for automated testing and enterprise single sign-on.
Figure 2. Rational Functional Tester property validation example
Test data management
Another challenge in testing is data security in nonproduction environments. Many organizations today populate the development and testing staging environments with copies of production data. The problem with this practice is that loading the test and dev environments with production data exposes the test and development areas to personally identifiable information (PII) such as Social Security numbers and dates of birth. When PII is loaded onto a nonproduction system, systems must comply with all of the regulations of SOX, HIPAA, PCI, and so forth, and are subject to the same audit exposures and fines. This practice has caused many organizations to fail security audits and has resulted in many fines.
Another intersection point for IT security is to help quality assurance teams build repeatable processes to populate cleansed data into nonproduction environments in the company. The IT security team needs to help build scripts that will sanitize the PII before it enters the test and development environments. The IT security team can help the development team build a repeatable process for populating data and ensuring that the sanitized data is used.
IBM Rational, Information Management, and Tivoli software can help take this a bit further by providing tool-level support for creating this environment. IBM® Optim™ Integrated Data Management could be incorporated into the Rational Quality Manager product to allow for freshly sanitized data to populate the system before a test begins. This process also helps the quality assurance team by creating a stable test bed to ensure an application state that will allow quality assurance teams to create automated test scripts easier. Tivoli® Security Information and Event Manager could also be used to monitor the sanitation process to help ensure that systems are being loaded with proper sanitized data and send warnings if errors are detected in the process.
IT security and quality assurance teams need to work together on application security, access management, enterprise single sign-on, and test data management. The two business units working together are exponentially more powerful. The result will be a more security-oriented QA department and a more quality-oriented IT security department, which will help remove more risk and provide better continuity.
- Check the WebSphere, Tivoli, and Information Management product overview pages for more information about software mentioned in this article.
- Evaluate IBM software.