assurance - RE: [Assurance] silver, passwords in remote centers, SOC2
Subject: Assurance
List archive
- From: "Rank, Mark" <>
- To: "" <>
- Subject: RE: [Assurance] silver, passwords in remote centers, SOC2
- Date: Wed, 10 Apr 2013 21:41:44 +0000
- Accept-language: en-US
- Authentication-results: sfpop-ironport01.merit.edu; dkim=neutral (message not signed) header.i=none
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!
- [Assurance] silver, passwords in remote centers, SOC2, Steven Carmody, 04/10/2013
- RE: [Assurance] silver, passwords in remote centers, SOC2, Capehart,Jeffrey D, 04/10/2013
- RE: [Assurance] silver, passwords in remote centers, SOC2, Rank, Mark, 04/10/2013
- Re: [Assurance] silver, passwords in remote centers, SOC2, Tom Scavo, 04/10/2013
- Re: [Assurance] silver, passwords in remote centers, SOC2, Steven Carmody, 04/12/2013
- RE: [Assurance] silver, passwords in remote centers, SOC2, Capehart,Jeffrey D, 04/10/2013
Archive powered by MHonArc 2.6.16.