Involvement with Development Groups

The certification and accreditation pieces discussed earlier are there to ensure a piece of development software meets expectations and can be used in operations. But security should be involved from the beginning of a development project. Utilizing secure processes, such as quality assurance and auditing, ensures the organization ends up with a more secure end product.

The security process used is based on constant involvement at all levels of operations within the organization. This includes normal day-to-day system operations and maintenance, as well as the development of both new systems and new applications.

Quality Assurance, Audit, and InfoSec Need to be Involved

Quality assurance (QA) techniques ensure that requirements for the project are defined up front. Those requirements should include security requirements as well as functional operating requirements. Secure programming methodologies and communication techniques can be stated in the beginning to drive the development process. Each requirement is documented and is specific to a final objective. For example, "The software cannot transmit sensitive customer data via clear-text across the network. Secure encryption techniques must be employed for all transmission routines."

These requirements can be technical in nature or strictly from a legal- or customer service-oriented angle. Regardless of where the requirements come from, they are tracked continuously through the process of development and/or maintenance to ensure they are met. The QA process ensures that every application meets the high standards required for secure operation. Possible areas of concern include logic bombs, boundary errors that could result in buffer overflows, simple mistakes in code, and code that could be opening other means of communication, either intentionally or unintentionally.

The functional components and security mechanisms of the product are defined at the beginning of the process. A logical comparison of these functions occurs within the QA team to help determine if there are issues with the proposed layout of the product. The testing plans for the product are also determined. Testing is developed that will determine both the functional stability of the software and the effectiveness of security mechanisms.

Ensuring that Policies, Laws, and Contractual Obligations are Respected

One great thing about quality assurance is that these requirements are tracked and audited throughout the various development cycle phases to ensure they are correctly included into the final product. It also ensures that other variables that influence the final product are also considered and included. These other considerations include:

• Organizational Policies   Organizational policies include those things that define quality of service (QoS), expectations for coding practices, and inclusions of security. These are normally internal policies defined by the organizational leadership and are considered company standards. Lack of adherence to these considerations will not necessarily bring hefty fines or other penalties.

• Regulations and Laws   The requirements defined by laws and regulations typically carry a penalty if they are not adhered to. For instance, healthcare regulations state that patient privacy is very important in the implementation of any new or existing system that transports, stores, or processes patient information. Developers should understand these requirements. Quality assurance techniques ensure that all of the legal obligations are met throughout the process.

• Contractual Obligations to the Customer of the Product   Contractual obligations are those requirements placed on the project by the customer who will be using the product. These may include Service Level Agreements (SLAs) or QoS statements. Again, developers must keep these things in mind while working on a project and the QA team will ensure that the final product meets these requirements as well.

Certifying the Security Functionality

As the project meets each of its major milestones and at the end of the initial development process, the product undergoes extensive testing for security functionality. A complete code review is also common at this point. Some basic questions about security functionality must be addressed at this point:

• How sensitive is the information being processed by the product?

• What are the risks to that information?

• Are all defined security requirements included in the final product?

• Do the security implementations function properly and do they adequately mitigate the risks identified earlier?

• How much loss of this information is considered acceptable to the organization?

• Do the security implementations function as expected?

• What additional security requirements can be recognized now that the product is at this stage?

These questions help the QA team check for the validity of proposed security implementations and make recommendations for changes based on the performance of the security functionality of the product. It is best to address these concerns at this point rather than have potential vulnerabilities sneak into the final product. Developers are also kept very involved in this process because they can help address any recommended changes or flaws in the product.

Certifying Processing Integrity

Another key function of the QA process is checking for the integrity of processes within the product. Although most functions do what they were designed to do, they may also be capable of other operations which were never intended. Intense testing in this area will aid the developers and testing team in defining potential trouble spots that were not intended. Some of these trouble spots include additional unknown functionality within the program or software flaws that could allow an intruder to run commands on the system via the software.

Operational Testing

Once these preliminary tests are complete, a full operational test can be undertaken. The product is placed into an operational environment and utilized similarly to how it should be used. Any issues that crop up during this time will be noted and tracked until a new version of the product is released. The QA team is looking for any other issues within the product that may have slipped by the other testing. Operational testing also tends to bring problems to light because, up until now, the product has not actually been "used" as an operational system. This testing process puts the product under realistic strain to see how it reacts and performs.