Assurance

["Rank, Mark" <>]

Wouldn't it also factor into maintaining a protected channel especially if 
the credential store is also used as a verifier for non-IdP apps? Thus parts 
of 4.2.3 and 4.2.5 would apply?

Just curious what others think?

Mark


--------------------------------------------------
Mark Rank
Project Manager - Identity & Access Mgt
UCSF Information Technology Services (ITS)
email: 

phn:414-331-1476
--------------------------------------------------

________________________________________
From: 

 
[]
 on behalf of Capehart,Jeffrey D 
[]
Sent: Wednesday, April 10, 2013 2:32 PM
To: 

Subject: RE: [Assurance] silver, passwords in remote centers, SOC2

Steven,

We have not been working from a SOC2 report, but here's my take on the matter:

The 4.2.8 "Technical Environment" would be the area to consider for the SOC2. 
 These only apply to Silver.

#1: 4.2.8.1 - Software Maintenance
#2: 4.2.8.2 - Network Security
#3: 4.2.8.3 - Physical Security
#4: 4.2.8.4 - Reliable Operations

As a pre-condition, the locations where the passwords are stored need to be 
covered in the SOC2 report.  If they aren't, then there is a risk that weak 
security could allow password exposure which would also be non-compliance 
with Silver.

Now, if the remote data center is one of several data centers and only has a 
password database say for Active Directory, and 4.2.8 has already been 
evaluated for the local data center, then the only risks left are probably 
physical access and logical access.  The SOC2 should address both of those.

If the remote data center is the only data center, then here's a method for 
evaluating each criteria:

#3 is pretty straightforward and you should find something in the SOC2 report 
about physical access controls.
"IdMS Operations shall employ physical access control mechanisms to restrict 
access to sensitive areas, including areas such as leased space in remote 
data centers, to authorized personnel."

#1 may be covered only in a general sense.  You probably want to test the 
specific software to find the right version numbers.  Stuff like Apache web 
servers, Linux/*nix OS, Oracle database, Shibboleth IDP, may be some of the 
key software to see if it is "up-to-date".

#2 has two parts***.  You would have to look very carefully in the SOC report 
to see if specific IdMS elements are covered.  They may not be.  You will 
need to check specifically for protected channels between IdMS operations 
systems.  Having the systems behind the same router may not be the same thing 
as a Protected Channel per the NIST definition.  Having Protected Channels is 
critical if the network channels cross over core/central routers.  The second 
part about login access for IdMS operations personnel may not be covered by 
the SOC2.  The elements could be the both physical (data center) and logical 
(the database, the identity management app, proofing app, administrative 
access to IdMS servers) etc.  The physical access part would most likely be 
covered.

#4 sounds simple, but it isn't limited to just power outages, flooding, fire, 
etc.  That's the first part of system failures.  The SOC2 probably would 
cover that under Environmental Security as an IT general control.  But, the 
part about "employ techniques to ensure that any failures are not likely to 
result in inaccurate Assertions being sent to SPs" is likely NOT going to be 
in the SOC2 report.  That will need some specific management assurance from 
the Shib IT guys, as well as understanding how everything works in sending 
assertions, to know that "techniques" have been employed.  For example, if an 
account management transaction fails, and the user should be been dropped 
from Silver to Bronze (or neither), is there something in place to monitor 
and catch that?  Or if the authentication database isn't working, does the 
program logic drop through and fail access or does it do the reverse?    
These types of "failures" are not likely to be in the SOC2 report.

***4.2.8.2 (S) NETWORK SECURITY
1. Appropriate measures shall be used to protect the confidentiality and 
integrity of network communications supporting IdMS operations. Protected 
Channels should be used for communications between systems.
2. All personnel with login access to IdMS Operations infrastructure elements 
must use access Credentials at least as strong as the strongest Credential 
issued by the IdPO.

p.s. if you also wanted to have the SOC2 cover 4.2.3.4 - 4.2.3.6 that would 
be a real stretch.  Good luck!  These need very careful evaluation especially 
now with the v1.2 IAP, Approved Algorithms, and Protected Channel 
requirements.

Jeff


-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Steven Carmody
Sent: Wednesday, April 10, 2013 4:32 PM
To: 

Subject: [Assurance] silver, passwords in remote centers, SOC2

Hi,

Our local Silver team will be meeting tomorrow.

About a month ago there was some discussion on this list of possibly using a 
SOC2 audit report as evidence that a remote data center holding campus user 
passwords was actually being operated in compliance with the Silver standards.

I'm writing to ask whether anyone has pursued this idea. And, if yes, what 
conclusions you came to. Would your campus consider a SOC2 audit report to be 
sufficient evidence ?

Thanks very much!