Assurance

[Tom Scavo <>]

Jeff, this is a very nice contribution that should probably be
captured in the wiki. If you're willing, let me know offline and we'll
get you access to the wiki (if you don't have it already).

Thanks,
Tom

On Wed, Apr 10, 2013 at 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:
>
> 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!
>
>