Assurance

[Steven Carmody <>]

On 4/10/13 5:32 PM, Capehart,Jeffrey D wrote:
> Steven,
>
> We have not been working from a SOC2 report, but here's my take on the matter:

Jeff - thanks very much for this informed, detailed response.

I suspect, tho, that most of us will first encounter this issue if the 
campus has outsourced email to Google or Office365, and has passwords 
stored there. I suspect that dealing with a generic remote data center 
is a valid use case, but somewhat less likely.

We do have a SOC2 audit report from Google -- has any campus started 
thinking thru whether relying on a SOC2 would be sufficient?

And whether the contents of the google report indicate whether their 
practices meet the Silver criteria ?

thanks!

> 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!