Creating a Secure Development Framework

Successful Implementation

A Secure Development Programme should be integrated with all phases of the organisation's software development lifecycle. It ensures that security is a consideration at all stages of a development project – from risk analysis of the business objectives through design and implementation to deployment in production environments.

Secure Development involves the systematic analysis of the security controls already in place in the organisation's lifecycle. It will typically involve the integration of phased security workshops, reviews and assessments during the development process.

Drawing on Expertise

Application security, and insecurity, is a rapidly evolving area. In order to successfully integrate security to the development process a comprehensive understanding of the potential issues and failures is required, together with intrinsic knowledge of the existing development processes.

The objectives of quality assurance and user acceptance testing are often at odds with those of security testing. Acceptance testing is performed with a mind to ensuring that the application behaves as it was designed to, from the point of view of a user. Tests from the point of view of a user with malicious intent, are often not carried out and form the core of the security testing mindset.

Through drawing on a security specialist to provide knowledge and experience to complement internal skills, a successful balance may be achieved. Once the processes are defined and integrated, the security role becomes a periodic one, providing knowledge sharing and assessment consultancy when required.

Agreeing Deliverables

As with all risk management, development of secure applications requires a delicate balance between investment and tangible return. As mentioned before, applications can be secured before, during and after development, but re-architecting to remove serious flaws discovered in production systems may be prohibitively expensive.

Figure 2 below illustrates how the security phases may integrate with a simple recursive waterfall development model. It is assumed that a Business Risk Audit will have been conducted during the business requirements phase.

Figure 2

4.1.1 Security Architecture Review

The Security Architecture Review is a logical review of the high-level designs and processes associated with the project and how it integrates with the existing environment and third parties. Through this phase, process design flaws and intrinsic security risks are identified and presented to the business in order to find resolutions prior to implementation. Systems and software architects are primarily concerned with the functionality of the application and whether or not it meets the business needs. Security considerations, and particularly, defending data from users with malicious intent is often overlooked.

4.1.2 Security Workshop and Review

The next phase occurs during the technical specification development phase, and consists both of logical reviews of designs and interactive workshops with the project stakeholders. Potential security issues and design flaws can be engineered out of the technical design specification prior to the costly implementation phase. The workshops also raise security awareness in the project team prior to decisions being made which may be difficult to reverse later.

4.1.3 Secure Programming Workshops

Early in the implementation phase, secure programming workshops provide the developers with specific advice relating to typical insecure implementation practice and common flaws. These workshops are tailored to the specific project and environment, e.g. the type of software being developed and the development technologies.

Workshops include discussion on defining the data sets and common security libraries and routines that will be used by the application. Possible attack scenarios and areas of risk within the application are identified and mitigation techniques planned.

4.1.4 Application Security Assessments

The preceding phases have focussed on logical reviews of processes and designs, together with knowledge share workshops. Subsequent testing phases involve technical security assessments of the software components and system as a whole.

An Application Security Assessment is designed to identify and assess threats to the organisation through bespoke, proprietary applications or systems. These applications may provide interactive access to potentially sensitive materials, for example. It is vital that they be assessed to ensure that, firstly, the application doesn't expose the underlying servers and software to attack, and secondly that a malicious user cannot access, modify or destroy data or services within the system. Even in a well-deployed and secured infrastructure, a weak application can expose the organisation's crown jewels to unacceptable risk.

4.1.5 Component Security Testing

Typically, each component of the application will be rigorously tested as it is completed. Security testing of the component interfaces and functionality will also be performed on each discrete piece of software.

4.1.6 System Security Testing

After the components and system integration have been completed, further security testing of the system as a whole is undertaken. This takes into account interaction between the completed system and the existing environment.

4.1.7 Interface Security Testing

During UAT and/or Load-Testing phases, security testing is undertaken from the user's perspective. An Application Security Assessment should be undertaken concurrently with user acceptance testing to ensure that changes made to the security of the application do not adversely impact the business requirements of the application. The assessment will produce a more accurate map of the risks associated with the application if real (or as close to real as possible) data is used in the testing environment. Providing a testing environment that closely matches the live environment will ensure that maximum benefit is gained from this phase of testing.

In less mature security models UAT testing is often the only form of application testing undertaken (if any). Typically, problems identified at this phase without the preceding phases having been undertaken may be difficult, prohibitively costly or impossible to engineer out of the application.

4.1.8 Production Security Assessment

The final stage of security testing is undertaken once implemented in the production environment. This involves re-testing of the user interface to validate fixes applied as a result of earlier advice, and identifies any new security problems introduced as a result of migration to the production environment.

4.1.9 Security Health Checks

Security, attacks and vulnerability types are constantly evolving and changing. As such, regular security health checks will be performed on production applications. This ensures that the applications are tested for resilience against new attack techniques, and provides assurance that changes within the application or environment as a whole have not adversely affected security within the organisation. Given the structured secure development process, this maintenance phase testing is likely to demonstrate that the strong security implementation has provided a stable and secure platform resilient to existing and future attacks.

Application Security Timeline

In practice, the phases will be performed in a largely linear timeline as shown in Figure 3 below.

Figure 3

Preparation Prior to Implementation

One of the first steps to ensure that your project is a success is in preparing your organisation for the process; the second will involve determining which supplier to use.

4.1.10 Transforming Organisational Attitudes

• Prepare Software Managers for the program; they should appreciate the value of the process and understand the importance of allocating time in the schedules for the software developments team participation in certain aspects of the phased security assessments.

• Build phased security assessments into the project schedule and remember to factor in time for the inevitable rework that will follow each phase.

• Inform the participants and if appropriate your customer on the benefits of secure development implementation.

• Encourage a team culture of mutual respect; the process of secure development should be seen as non-threatening. Some developers are concerned that the process might be used against them at performance appraisals time. Assure them that this won't be the case. Teams should recognise that a secure development program can support both individual and team efforts for continuous improvement. Further, that learning can be enhanced as knowledge is automatically exchanged about programming language features, coding and commenting style, program architecture, design notations, ways to document requirements and all other aspects of the software development process.

• Have local champion who preaches the merits of a security development program, trains others as they get started and strives to improve the overall software development process.

4.1.11 Choosing your Secure Development Partner

When considering a security supplier, first outline your goals for the project and your expectations of the supplier. You will want to choose a supplier with experience in your industry and one that has all the expertise you require. Speak to at least two references; both those that have worked with the supplier and those that are still working with the supplier.

In order to assist in your secure development program, the supplier must have experience of integrating security controls with organisations existing development processes. They must have extensive experience of assessing and auditing application security at all levels – from design and architecture through prototyping and coding to analysis of full production environments.

Equally important is the supplier's understanding of the relationship between business demands and security concerns, and how to mitigate risk within the boundaries set down, including required functionality and time-scales.

Detailed below are several questions to ask your potential suppliers; the information gained will help you determine whether they are appropriate. The reasons for asking these questions will be explained accordingly.

1. Is the supplier a specialist first and foremost, or is the security practice a secondary concern?

2. Does the supplier offer a comprehensive suite of services, tailored to your specific requirements?

3. Do the supplier's methodologies follow and exceed those such as OWASP?

4. Does the supplier have a policy of employing ex hackers?

5. Are the supplier's staff experienced security professionals, holding recognised certifications such as CISSP, CISA and CHECK?

6. Can they distinguish and articulate between infrastructure and application testing?

7. How many technical consultants does the supplier have that work on security and assessments, and how many of those are dedicated solely to security?

8. Does the supplier present the deliverables, such as the final report, in an informed manner, with concise and practical information for technical and non-technical parties?

9. Is the supplier a recognised contributor within the security industry?

10. Are references available to attest to the quality of past work performed?

4.1.12 Checking the Quality of your Supplier's Consultants

The quality of the security assessment service that you will receive is the direct result of the quality of the consultants that will be supplied for the project.

A phased security assessment of software development will examine design and implementation, and assess the impact on both the technical and business infrastructure. This requires the consultancy team to possess a broad spread of experience and also detailed knowledge of the areas under scrutiny. It is clear that these kinds of skills cannot be obtained without years of experience in a variety of complementary IT fields, such as development, systems administration or consultancy.

When considering a security assessment supplier, a good measure of their worth is to qualify how they contribute to research and development within the security industry. Research demonstrates a profound understanding of current technologies and a proven ability of the supplier's team to assess, review and audit infrastructure and provide trusted solutions. What is more supplier's that operate in this way are able to deliver real value-add by identifying, remedying and disseminating details of new security flaws discovered; allowing their customers the opportunity to gain both increased security and gain an instant competitive advantage.

A commonly heard complaint when embarking on a security assessment project is that a high-level consultant will come to the pre-project meetings, but when the project starts a junior consultant or trainee is used. To avoid this kind of issue when choosing a security assessment partner, insist on being provided with the CV's of all the consultants that will be working on your project, prior to commencing.