No one currently working in IT can escape the carnage wreaked by hackers, as their exploits are increasingly designed to target specific vulnerabilities in the software applications that run our businesses. For that reason, attention is progressively more focused on the application development community; the industry is asking itself how it can build more secure software.

Those leading the charge have found the key is to select a few practical activities that can be as simple as a series of small tasks at each step in the software development lifecycle. However, even this approach is easier said than done; the inertia against change can be so great that it is easy to become paralyzed, which prevents security from being addressed sufficiently at any step-not in design, development, testing, nor production.

This document proposes seven practical steps that development groups can employ today to deliver more secure software. Although not a silver bullet, they will generate measurable results in the near term. The key is to start now.

Step1: Quickly evaluate the current state of software security and create a plan for dealing with it throughout the development lifecycle
This step does not need to be a comprehensive, multi-month effort; the best way to start is by simply creating lists of activities currently undertaken those you'd like to implement.

A plan-no matter how brief or short-term-is critical for getting buy-in within the organization, and should address three elements:

• the infrastructure that surrounds each development project,
• specific security activities each project team chooses to undertake, and
• how found vulnerabilities will be managed.

Step 2: Specify the risks and threats to the software so they can be eliminated before they are introduced
Security is all about risk mitigation. Software applications that store customers' private information are more sensitive than an internal application for scheduling conference rooms, so it's a good idea to determine the risk associated with a piece of software and the threats to its safety.

Risk analysis can be found in commercial solutions and standards-based approaches. Although varied in their implementation, these types of approaches involve a significant investment of time. A simpler technique, threat analysis, helps avoid security mistakes in the design and focuses code reviews and testing on the most vulnerable components of the application. Threat analysis can be divided into two phases:

1. Identify the assets of an application that must be protected and evaluate which are most important. This task can be tricky as the nature of assets varies from application to application. Examples include records of private information (e.g. credit card numbers), resources an organization provides to others (e-mail), as well as intangible resources (a company's reputation).
2. Understand the application itself and the dangers it faces from attackers. Organizations should develop a high-level model of the application's components and dataflow paths, map its attack surface and identify interfaces that accept input from users or interact with other systems. Teams should note any points on the attack surface that allow an exploit to compromise the integrity, availability or confidentiality of an asset. Finally, rank the threats based on importance of the asset affected and the likelihood of exploit.

1

• Next

Home
Webinars
Blogs
ebizQ Forum
All Topics
Subscriptions
White Papers
Analyst Corner
Follow us on Twitter
Fan us on Facebook

Goals

Enabling Business Agility and Reuse
Improving Business Processes
Leveraging Information and Intelligence
Optimizing Business/IT Management
Leveraging the Connected Web
Securing Enterprise Applications
Supporting Industry Solutions

About Us
Editorial Calendar
Feedback
FAQ
Advertise With Us
Site Map
Privacy Policy
Unsubscribe