Re: Information Security Considerations for Use Case Modeling

["John Steven" <jsteven () cigital com>]

Gunnar, All, (long I apologize)

As I sat down to write (the fairly languished) Enterprise Security
Architecture book I realized that process tie-in was essential. I realized
that hope of configuring your containers let alone developing a secure
application were lost unless the security goals were well laid out. The
first two chapters I wrote, as a result, focused on distilling solid
security requirements and tracing them into the high-level architecture and
subsequently low level design. In short: I agree whole-heartedly that
without solid security requirements, you're screwed. I also agree: anchoring
such requirements in use (and abuse) cases is a good start to prevent
dementia.

Below you'll find some additional "guides" beyond the advise to do use/abuse
cases and wring security requirements out of them. Some of this guidance is
contentious... I've found it works well for large organizations who fancy
themselves "users" of software (despite their 1000-3000 person development
teams ;))

** Involve both security and business folk with use / abuse case
generation**
While your organization's security guys have hopefully immersed themselves
in "thinking like an attacker", they don't often understand the real
business impact of potential malicious behavior. Pairing business and
security personnel together and using a risk management approach allows you
to get at the doomsday and other high-value loss scenarios that threats
might perpetrate against your business through a particular application.

For instance:
We deal a lot w/ credit card protection. Security guys always focus on the
theft of credit card information. But, for most merchants the real pain
point is an increased percentage surcharge on credit card transactions. This
can create a reduction in margin far beyond the fine or PR loss associated
with simple theft. With this impact in mind, what new business risks exist
in your organization? How does this change the focus of your security
efforts in the SDLC?

** Think about the partners, extranets, and the /real/ deployment when doing
misuse**
Several threat models, misuse, and abuse cases I've seen are done as purely
pencil-and-paper exercises and don't take into account the interesting
aspects of the application's real deployment. Overlooked items can include:
partner networks, reporting and other batch interfaces, collocated (and
sometimes more highly trusted) systems/components, administrative and other
system-level interfaces, and so forth.

Attacking the system is as easy as subverting its weakest interface,
remember. And in doing so, an attacker might be able to pull the tablecloth
(config, permissions, and data files, etc.) out from under an otherwise
pristine use case.

** Consider specifics when doing misuse and abuse**
When analysts do use cases, I've found they tend to simply users and roles.
Does your organization think about data sensitivity classifications,
collocated systems (from previous), roles, delegation of privilege, and
entitlement when doing use, misuse, or abuse cases? With declarative access
control coming more bolding into the picture (through Java and .NET) this
becomes a terrible quagmire to overlook. Because most organizations don't
even do this much, I'll omit some of the more specific follow-on guidance.

** Differentiate security requirements from security mechanisms**
"Use SSL to encrypt Internet-based communications" is a terrible
requirement, IMO. While it's important to think about security mechanisms
for a variety of reasons, noting about the quoted statement indicates how to
specifically protect data and from what threats. Thinking about the
available mechanisms will help with feasibility, but it skips a few steps:
1) what are you trying to protect against and 2) what software and design
must accompany the prescribed mechanisms in order to actually serve as
protection.

The easiest example of this is encrypted logs. Standard crypto foo, simply
applied doesn't prevent duplicate log entries from outputting the same
cipher text. This may be all the attacker needs to probe application state.
Also: how does "use cipher XXX" assure that the developer will protect logs
against truncation, partial deletion, and so forth. Are those requirements
of the your system?

** Handle resolution of constraints separate from security goals**
Requirements management meetings can turn into design meetings fast, relying
on elements of design and feasibility to pin down requirements. There's
something lost in these discussions: namely the stakeholder's security
goals. Agreement as to the goals should occur first. Then comes distillation
of requirements, then design.

While organizations benefit from involving a gifted architect in
requirements review, this person often can't bite their tongue when
appropriate (to avoid sliding into design constraints land). Keep
communication between architects and requirements analysts high, but remain
formal about their hand off. Let analysts own requirements def., and keep
them focused on the user's/system's security goals. Hand off to designers to
get them to "sign up" to system construction, and only then deal with
constraints. To go further into the particulars here, I'd have to inject a
ton of change management text... So I punt here.

This, IMO, leads to much more intelligent testing than "Is SSL enabled?"
Check. By specifying requirements that speak to security goals and attack
resistance, you've given testers more wherewithal as to how to stress the
system, as an attacker would.

***Specific Tip: Leave no goal unexplored before beginning to architect. Do
not use architecture definition as a mechanism for exploring software
security goals.

***Specific Tip: Use your goals and high-level security requirements to
excise security mechanisms or expenditure that goes well above-and-beyond
your risks

**Use Risk Analysis and Threat Modeling to Curb Security Requirements
Explosion*
 Just as threat modeling and risk analysis can create security requirements,
they can be used to constrain their unbounded growth as well. Risk analysis
is particularly useful in determining whether or not you have too many (or
onerous) security requirements) initially. Threat modeling, which requires
at least initial design at its core, can help with requirements work during
change management activities.

Purely focusing on their requirements pruning potential, these two
activities allow a development team to prioritize what attacks will possess
the highest impact, and focus on requirements and design to address only
these issues.

So, this is just a sampling from a larger laundry list. But, hopefully it
provides some more guidance to those whose appetites are whet from Gunnar
and Johan's posts.

-----
John Steven
Principal, Software Security Group
Technical Director, Office of the CTO
703 404 5726 - Direct | 703 727 4034 - Cell
Cigital Inc.          | [EMAIL PROTECTED]

4772 F7F3 1019 4668 62AD  94B0 AE7F EEF4 62D5 F908


> From: Gunnar Peterson <[EMAIL PROTECTED]>
>
> When I coach teams on security in the SDLC, I ask them to first see
> what mileage they can get out of existing artifacts, like Use Cases,
> User Stories, and so on. While these artifacts and processes were not
> typically designed with security in mind, there is generally a lot of
> underutilized properties in them that can be exploited by security
> architects and analysts.
>
> The Use Case model adds traceability to security requirements, but
> just as importantly it allows the team to see not just the static
> requirements, rather you can the requirements in a behavioral flow.
> Since so much of security is protocol based and context sensitive,
> describing the behavioral aspects is important to comprehensibility.
>
> At the end of exploring existing artifacts, then there needs to be a
> set of security-centric artifacts like threat models, misuse cases,
> et. al. The output, e.g. design decisions, of these security-centric
> models are fed back into the requirements in an iterative fashion.
>
> Security analysts and architects cannot do all the work that goes
> into secure software development by themselves. There may be a
> handful of security people supporting hundreds of developers. This is
> why we need to educate not just developers on writing secure code,
> but also business analysts on security Use Cases, requirements, etc.
> (the main purpose of my article), testers on how to write/run/read
> security test cases, an so on.




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------