OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Comments on Security Threat Model


A security specialist will review a system to
determine if the goals and requirements for
confidentiality, integrity, authentication,
authorization, and non-repudiation are incorporated
into a computing system/environment.  Joe mentioned
this aspect of security in the conference call today. 
You will see these goals repeated in many different
security documents.  

Core Security Patterns, Chapter 2, page 49-53

W3C Web Services Architecture, Web Services Security
Requirements, 3.6.3
http://www.w3.org/TR/ws-arch/#security

Security Design Patterns, The Open Group Security
Forum, Section 8.1 Protected System Patterns, pages
46-51 (I found the concepts for the Protected System
Patterns useful when modeling high assurance
applications)
http://www.opengroup.org/online-pubs?DOC=9299969899&FORM=PDF

FIPS PUB 199, Standards for Security Categorization of
Federal Information and Information Systems
http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf

You can Google for confidentiality, integrity, etc for
much more information.

Our Security goal in Goals, Critical Success Factors
and Requirements could be represented by a symbol that
is similar to a UML component that could then expand
to a more detailed representation of Security goals
and requirements.

Fundamental security principals for a SOA can include
Integrity, Policy, Auditing, Management, Availability,
Compliance, Logging, PKI, Labeling, Authentication,
Authorization, Confidentiality.  See core Security
Patterns, chapter 8, page 441 to 443 for more
information.  

I track some of the standards related to these
principals on my SOAModeling.org web site. 

http://www.soamodeling.org/techmapping.html

Select Size: 50  and Category: Security and press the
Search button to see a list of hyperlinks and short
descriptions to some of the related standards.

The threat model is one aspect of security for
determining who would most likely attack a system and
what possible ways an attacker could compromise the
system.  See core Security Patterns, Chapter 2, Threat
Modeling, page 81-83 for more information.  As a side
comment not related to the SOA RA, NIST provides a
National Vulnerability Database that can be used to
help identify and mitigate cyber security
vulnerabilities in an implementation. 
http://nvd.nist.gov/  Very cool.

Our architecture Threat Model contains aspects of a
threat profile or the identification and list of
threats and vulnerabilities.  For example, our SOA RA
threat profile contains espionage (unauthorized
probing of content, unauthorized disclosure), and
sabotage (unauthorized access, malicious code),
viruses, worms, trojans, denial of service, theft,
fraud, and could also contain arbitrary code
execution.  Ken also mentioned services or parts of
services that were once good but have gone bad.  See
core Security Patterns, Chapter 8, page 494 for more
information.  Security design patterns and a tool like
the National Vulnerability Database can be used to
help mitigate threats identified by the threat
profile.  I also track some of the patterns related to
SOA and security on my SOAModeling.org web site. 

http://www.soamodeling.org/techmapping.html

Click "Patterns Catalog” and then select Size: 50 and
Category: Security and press the Search button.   I
still have several SOA related security patterns to
add to this list.

Dave mentioned the Trust Model in today's conference
meeting and I concur with his assessment.  The Trust
Model will be a critical element of most professional
SOAs and should probably be added next to the Threat
Model in our Goals, Critical Success Factors, and
Requirements.   The trust model provides mechanisms
that establish a central authority of trust among the
components of the security architecture and that
verify the identity of participating user entities and
their credentials.  I am regurgitating from core
Security Patterns, Chapter 8, page 495 but we went
through the same process for an Assured Information
Sharing architecture for the Global Information Grid. 


The RA Threat Model section also references policy. 
Architecting policy in a SOA is a complex task.  This
may be a good topic that is at the same level as
Threat Model and Trust Model.   Discussing the PDP and
PEP in the security section seems to infringe on the
Policy section of the RA.  The security section could
state policies in terms of identity policies, access
control policies, content-specific policies, network
and infrastructure policies, regulatory policies, and
advisory and informative policies.   See core Security
Patterns, Chapter 8, pg 496 to 497.  This level of
policy identification might not be abstract enough for
our SOA RA.   
 
I would like to add to Dave's comment about
accreditation.  Accreditation to me means achieving
something like a Common Criteria Certification. The
Common Criteria is an international standard that
defines a set of testable standards a product needs to
be verified against to prove its worth.  Based on the
Common Criteria Certification, an Evaluation Assurance
Level is assigned from 1 to 7 showing a measure of
strength.  The highest levels of accreditation involve
mathematically proven software, security of the
hardware, security in the life cycle processes,
environmental security, etc.  One year ago or so, the
Green Hills Real Time Operating System was one of the
most advanced operating systems shooting for an EAL 7
rating that I was aware of.  As I recall, Green Hills
claimed that they could mathematically prove up to
10,000 lines of executable code.  Green Hills has been
developing real time operating systems for systems
like air trafficking control.  The Green Hills RTOS is
also incorporated into many DoD systems as well. 
Microsoft Windows has achieved an EAL 4+ rating.  An
EAL 5+ rating is considered to be high assurance. 
FIPS 200 references Certification and Accreditation. 
I see accreditation as having more to do with proving
and assigning a level of security strength to a
computing system than it has to do with a particular
technology like SOA.

Danny


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]