Subject: [sacm] SCAM Use Case 5 "Define Security Policy"

From: Shawn Mullen <[email-masked]>
Date: Mon, 23 Jul 2012 08:48:07 -0500

During the Washington DC 7/18/12 Open Group Conference Steve Hanna,
John Banghart, and Kathleen.Moriarty presented the SACM overview and 
called for participation.  In particular they ask for review and 
contributions to the use case definition.  Therefore I am proposing the
following.

Looking at this form how a enterprise would roll-out or implement a 
SACM environment, I belive the first use case is a simple way to define or
author a security policy.  This defined policy bridges the organization's
security principles and goals into a policy that form that can be applied 
to a
system or used to check a system, e.g. XML.  Formally  stated I suggest 
UC5 as
follows.

3.5 UC5 Define Security Policy

   This use case provides a method for IT security principles and 
requirements
   to be expressed in a common  descriptive  language such as XML. This 
common
   descriptive  language will define the  organizations  security  policy. 
The
   security  policy  definition  will  be  at a  sufficiently  high  level 
 to
   facilitate  simplicity  and ease of use, It will not  require the 
author to
   specify the configuration methods and commands to implementation the 
policy
   on the differing IT devices. However it will be possible for the IT 
devices
   to bridge this high security policy into actionable configuration 
settings.
 
Given the above use case, a CIO or CSO can express the security and 
governance
requirements in a single common secruity policy xml file.  This single 
file 
can be applied to all IT devices such as servers,  clients,  network 
devices,
etc.  Given this state, UC1 can be attained,  That is we now have a common
security policy which can be assessment and enforced against. 

A single security policy also facilitates UC4 making GRC reporting 
common no matter  the  device  being  assessed.  That is high  level 
security
policy not only bridges the  organization  security  principles  into a 
device
configuration  it also provides the inverse for reporting  devices 
assessment
back up to the CIO/CSO level. 

My other comment is on  simplicity.  Just like security should be built in 
and
not bolted on.  Simplicity  should be clearly defined and built in. 
Complexity
is the enemy of security.  Not only does simplicity  increase adoption it 
also
eliminates the number of components to be trusted and reduces attack 
surfaces.

--------- existing Use cases for reference -----------

3.1.  UC1: Assessment and Enforcement of Acceptable State

   Controlling access to networks and services based on the assessment
   and analysis of host and/or network state based on machine
   processable content.

3.2.  UC2: Behavioral Monitoring and Enforcement

   Controlling access to networks and services based on the detection
   and analysis of host and/or user behavior using automatable
   information from various sources.

3.3.  UC3: Security Control Verification and Monitoring

   Continuous assessment of the implementation and effectiveness of
   security controls based on machine processable content.

3.4.  UC4: Secure Exchange of Governance, Risk and Compliance (GRC)
      Information

   Sharing security and/or operationally relevant information within and
   across trust boundaries using secure, automated communication
   channels and formats.

Shawn Mullen 
Power Software Security  Architect

cell -  (512) 914-8134
11400 Burnet Road internal 9551 
Austin, TX 78758-3493
office (512) 286-7683
(T/L: 363-7683)

---

From: <[email-masked]>
Date: Mon, 23 Jul 2012 10:20:38 -0400

Shawn,

Thank you for chiming in!  Would you see the proposed UC5 as a new UC1 since policy is a building block?  This would just mean we have another Use case to build out the full picture.  Your suggestion makes perfect sense.

>From a conversation last week, we may want to have a use case on configuration management as well, before we get to enforcement, reporting, and remediation.  It would be a building block along with the policy information suggested by Shawn.  Any thoughts?

Thanks,
Kathleen

From: [email-masked] [mailto:[email-masked]] On Behalf Of Shawn Mullen
Sent: Monday, July 23, 2012 9:48 AM
To: [email-masked]
Cc: Stephen Whitlock; [email-masked]
Subject: [sacm] SCAM Use Case 5 "Define Security Policy"

Looking at this form how a enterprise would roll-out or implement a
SACM environment, I belive the first use case is a simple way to define or
author a security policy.  This defined policy bridges the organization's
security principles and goals into a policy that form that can be applied to a
system or used to check a system, e.g. XML.  Formally  stated I suggest UC5 as
follows.

   This use case provides a method for IT security principles and requirements
   to be expressed in a common  descriptive  language such as XML. This common
   descriptive  language will define the  organizations  security  policy. The
   security  policy  definition  will  be  at a  sufficiently  high  level  to
   facilitate  simplicity  and ease of use, It will not  require the author to
   specify the configuration methods and commands to implementation the policy
   on the differing IT devices. However it will be possible for the IT devices
   to bridge this high security policy into actionable configuration settings.

Given the above use case, a CIO or CSO can express the security and governance
requirements in a single common secruity policy xml file.  This single file
can be applied to all IT devices such as servers,  clients,  network  devices,
etc.  Given this state, UC1 can be attained,  That is we now have a common
security policy which can be assessment and enforced against.

A single security policy also facilitates UC4 making GRC reporting
common no matter  the  device  being  assessed.  That is high  level  security
policy not only bridges the  organization  security  principles  into a device
configuration  it also provides the inverse for reporting  devices  assessment
back up to the CIO/CSO level.

My other comment is on  simplicity.  Just like security should be built in and
not bolted on.  Simplicity  should be clearly defined and built in. Complexity
is the enemy of security.  Not only does simplicity  increase adoption it also
eliminates the number of components to be trusted and reduces attack surfaces.

--------- existing Use cases for reference -----------

Shawn Mullen

cell -  (512) 914-8134

---

From: "Baker, Jon" <[email-masked]>
Date: Tue, 24 Jul 2012 01:08:22 +0000

How does the use case discussion you provided below align with the work the opengroup has done on ACEML?

Jon

============================================
Jonathan O. Baker
G022 - IA Industry Collaboration
The MITRE Corporation
Email: [email-masked]<mailto:[email-masked]>

--------- existing Use cases for reference -----------

Shawn Mullen

cell -  (512) 914-8134

---

From: Shawn Mullen <[email-masked]>
Date: Tue, 24 Jul 2012 08:00:14 -0500

Jon,

I believe it aligns exactly with the issues faced by industry CIO/CSOs. 
Yes, this is what we tried to address with ACEML.  I equally believe the 
IETF process is perfectly suited to address this problem and vet the 
solution.  I also still believe that a blend of SCAP/ACEML/other will be 
the optimal and probable solution.

As to Kathleen's comment/questions...
> From a conversation last week, we may want to have a use case on 
configuration management as well, before we get to enforcement, reporting, 
and remediation.  It would be a building 
> block along with the policy information suggested by Shawn.  Any 
thoughts?
 
Yes I believe there is a foundational necessity for SACM to address of 
expressing security and IT governance principles in a policy that can be 
implemented and enforced by technology solutions.  I'm currently on tour 
of Asia Pacific financial companies and this is a reoccurring theme. 

Shawn Mullen 

cell -  (512) 914-8134

From:   "Baker, Jon" <[email-masked]>
To:     Shawn Mullen/Austin/IBM@IBMUS, "[email-masked]" <[email-masked]>
Cc:     Stephen Whitlock <[email-masked]>, 
"[email-masked]" <[email-masked]>
Date:   07/23/2012 08:08 PM
Subject:        RE: [sacm] SCAM Use Case 5 "Define Security Policy"

How does the use case discussion you provided below align with the work 
the opengroup has done on ACEML? 
 
Jon
 
Email: [email-masked]
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
Shawn Mullen
Sent: Monday, July 23, 2012 9:48 AM
To: [email-masked]
Cc: Stephen Whitlock; [email-masked]
Subject: [sacm] SCAM Use Case 5 "Define Security Policy"

 

--------- existing Use cases for reference ----------- 

Shawn Mullen 

cell -  (512) 914-8134

---

From: "Banghart, John" <[email-masked]>
Date: Tue, 24 Jul 2012 09:10:50 -0400

Shawn,

That certainly makes a lot of sense to me.

-John

From: Shawn Mullen <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 24, 2012 9:00 AM
To: "Baker, Jon" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Stephen Whitlock <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sacm] SCAM Use Case 5 "Define Security Policy"

Jon,

I believe it aligns exactly with the issues faced by industry CIO/CSOs.  Yes, this is what we tried to address with ACEML.  I equally believe the IETF process is perfectly suited to address this problem and vet the solution.  I also still believe that a blend of SCAP/ACEML/other will be the optimal and probable solution.

> From a conversation last week, we may want to have a use case on configuration management as well, before we get to enforcement, reporting, and remediation.  It would be a building
> block along with the policy information suggested by Shawn.  Any thoughts?

Yes I believe there is a foundational necessity for SACM to address of expressing security and IT governance principles in a policy that can be implemented and enforced by technology solutions.  I'm currently on tour of Asia Pacific financial companies and this is a reoccurring theme.

Shawn Mullen

cell -  (512) 914-8134

From:        "Baker, Jon" <[email-masked]<mailto:[email-masked]>>
To:        Shawn Mullen/Austin/IBM@IBMUS, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc:        Stephen Whitlock <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date:        07/23/2012 08:08 PM
Subject:        RE: [sacm] SCAM Use Case 5 "Define Security Policy"
________________________________

Jon

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Shawn Mullen
Sent: Monday, July 23, 2012 9:48 AM
To: [email-masked]<mailto:[email-masked]>
Cc: Stephen Whitlock; [email-masked]<mailto:[email-masked]>
Subject: [sacm] SCAM Use Case 5 "Define Security Policy"

--------- existing Use cases for reference -----------

Shawn Mullen

cell -  (512) 914-8134

---

From: "Waltermire, David A." <[email-masked]>
Date: Tue, 24 Jul 2012 12:41:17 -0400

I am inclined to create subsections under the current use case sections.  Within these subsections, we can flesh out the "building blocks" such as what Shawn has provided.  Does this sound like a reasonable way to organize the material?

Sincerely,
Dave

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, July 23, 2012 10:21 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [sacm] SCAM Use Case 5 "Define Security Policy"

Shawn,

Thanks,
Kathleen

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Shawn Mullen

--------- existing Use cases for reference -----------

Shawn Mullen

cell -  (512) 914-8134