management

1. Software Risk Management
The most important prerequisite to software risk Management is adopting a high-
quality software engineering methodology that enables good risk management
practices, the premier methodology is spiral model, the spiral model posits that
development is the best performed by doing the same kinds of things over and
over again, instead of running around in circles. However, the idea is to spiral in
towards the final goal, which is usually a complete robust product. Much of the
repetition in the spiral model often boils down to refining your product based on
new experiences.
In the spiral model the first activity is to derive a set of requirements, Requirements
are essential. From the point of view of security, you need to be sure to consider
security when requirements are derived. We recommend spending some time
talking about security as its own topic, to make it gets is due.
The second activity is to identify your largest risk, and evaluate strategies for
resolving those risks. Identifying risk is accomplished though risk analysis. Clearly,
practitioners will do a lot better in terms of security if they keep security
requirements in mind when performing a risk analysis. At this stage, as well as
during the requirements phase. We find it good to perform a complete security
analysis to make sure that security is addressed.
A risk management exercise may begin anytime during the overall software life
cycle, although it is most effectively applied as early as possible, for any given
project, there is likely some pint in the life cycle beyond which software risk
management gets very expensive. However, it’s never too late.
At the pint in the life cycle when software risk management begins, all existing
artifacts and involved stakeholder can be used as resources in identifying software
risk. Requirements documents. Architecture and design documents, models, any
existing code, and even test cases all make useful artifacts.
Next, risks are addressed, often through prototyping, and some validation may be
performed to make sure that a possible solution manages risks appropriately, given
the business context. Any such solution is then integrated into the current state of
affairs; perhaps the code will be modified. Perhaps the design and the
requirements will be updated as well. Finally, the next is planned.
The key to the spiral model is that it is applied in local iterations at each milestone
during software life cycle phases. Each local software risk management cycle
involves application of the same series of steps, Local iterations of the cycle
management risk at a more refined level, and applies specifically to the life cycle

2. phase during which they are performed. As a result projects become more resilient
to any problems that crop up along the way. This model is in sharp contrast to the
older waterfall model, which has all development happening in order, with little
looking back or cycling back to address newly identified concerns.
Software engineering is based on an attempt to formalize software development,
injecting some sanity into what is often perceived as too creative an endeavor.
Building secure software leans heavily on the discipline of software engineering,
liberally borrowing methods that work and making use of critical engineering
artifacts. Be cautioned , however, that some practitioners of software engineering
overemphasize process to the detriment of understanding and adapting software
behavior, We think process is a food thing, but analysis of the end product (the
software itself) is an essential practice .
The Rol of Security Personnel
Approaching security as risk management may not come easily to some
organizations, One of the problems encountered in the real world involves the
disconnect between what we call “roving bands of developers” and the security
staff of information technology (IT) department. Although we have said that security
integrates in a straightforward manner into software engineering methodologies, it
still requires time and expertise. One workable approach to bridging the gap is to
make software security somebody’s job. The trick is to find the right somebody.
Two major qualifications are required for a software security lead: (1) a deep
understanding of software development and (2) an understanding of security. Of
these two, the first qualification is probably the most important.
The previous statement may sound strange coming from a couple of security
people. Suffice it to say that we were both developers (and programming language
connoisseurs) before we got into security. Developers have highly attuned radar.
Nothing bothers a developer more than useless meeting with people who
seemingly don’t “get it”. Developers want to get things done, not worry about
checking boxes and passing reviews.
Unfortunately, most developers look at security people as obstacles to be
overcome, mostly because of the late life cycle “review” based approach that many
organizations seem to use.
This factor can be turned into an advantage for software security. Developers like
to listen to people who can help their job done better. This is one reason why real
development experience is a critical requirement for a successful software security
person. A software security specialist should act as resource to the development

3. staff instead of an obstacle. This means that developers and architects must have
cause to respect the body of knowledge the person brings to the job. A useful
resource is more likely to be consulted early in a project (during the design and
architecture phases), when the most good can be accomplished.
Too often, security personnel assigned to review application security are not
developers. This causes them to ask questions that nobody with development
experience would ever ask. And it makes developers and architects roll their eyes
and snicker. That’s why it is critical that the person put in charge of software
security really knows about development.
Knowing everything there is no know about software development is, by itself, not
sufficient. A software security practitioner needs to know about security as well.
Right now, there is no substitute for direct experience.
Once a software security lead has been identified, he or she should be the primary
resource for developers and architects or, preferably, should build a first-tier
resource for other developers and architects or preferably, should build a first-tier
resource for other developers. For example is a good practice to provide a set of
implementation guidelines for developers to keep in mind when the security lead
isn’t starting over their shoulders (this being generally a bad idea, of course).
Building such a resource that developers and architects can turn to for help and
advice throughout the software life cycle takes some doing. One critical factor is
understanding and building knowledge of advanced development concepts and
their impact on security.
On many projects, having a group of security engineers may be cost-effective.
Developers and architects want to make solid products. Any time security staff help
the people on a project meet this objective without being seen as a tax or hurdle,
the process can work wonders.
Software security personnel in the life cycle.
Another job for the software is that he or she should be responsible for making
sure security is fairly represented during each phase of the software life cycle. This
engineer could be lead or it could be another individual. During each phase, you
should the best available person (or people) for the job.
Risk Assessment
An effective risk-based approach requires an expert knowledge of security. The
risk manager needs to be able to identify situations in which known attacks could
potentially be applied to the system, because few totally unique attacks ever rear
their head. Unfortunately, such expert knowledge is heard to come by.

4. Risk identification works best when you have detailed specification of a system
work from. It is invaluable to have a definitive resource to answer questions about
how the system is expected to act under particular circumstances. When the
specifications is in the developer head, and not in paper, the whole process
become much more fuzzy, It is all too easy to consult your mental requirements
twice and get contradictory information without realizing it.
Once risks have been identified the next step is to rank the risks in order of
severity. Any such ranking is a context-sensitive undertaking that depends on the
needs and goals of the system.
Some risks may not be worth mitigating. Ranking risks is essential to allocating
testing and analysis resources further down the line, because resource allocation is
a business problem, making good business decisions regarding such allocation
require sound data.