Meeting the InCommon Assurance profile criteria using Active Directory

[Ron Thielen <>]

Well I intend to submit an Alternative Means statement supporting the notion that an Internal Network may address the same risks as a Protected Channel under certain circumstances.  We have a back-net between some of our IDMS components.  It is a non-routable VLAN that is not accessible from any system that is not part of the IDMS infrastructure, that is it has no inter-VLAN connectivity and no switched virtual interface defined for it.   We do not encrypt on that network, because there is no way for the traffic to be seen outside of that VLAN.

 

I think I’ve mentioned this on some of our calls.  PCI DSS has an equivalent concept.  PCI is very stringent about encrypting cardholder data on the network; however, there is no requirement to encrypt cardholder data on Internal Networks.  Infamously, payment processors like Heartland Payment Systems don’t have to encrypt traffic in their data centers.

 

Of course in either case, PCI or my Alternative Means, access to the network infrastructure would have to be managed in accordance with the relevant standards.  So, the credentials used for switch maintenance would have to adhere to Silver standards.

 

Ron

 

From: [mailto:] On Behalf Of Capehart,Jeffrey D
Sent: Wednesday, May 15, 2013 8:15 AM
To:
Subject: RE: [AD-Assurance] Protected Channels and the IAP

 

Although it seems like it should be straightforward to determine whether any particular type of communications is over a network or local to a particular system, sometimes it is not obvious just from the name, or from what IT tells you.

 

As an example, if you have three separate domain controllers, and they communicate amongst themselves with password changes, then that is over the network.  For Active Directory, they have to be on the network to do their job and they have to be accessible.

 

But, if there is some communications channel where passwords are synchronized and that channel isn’t a protected channel, then that could be a problem.  However, encrypting the secret would be OK, right?  Well, as long as the box that the secret is decrypted on is the same one doing the synch/update, then yes it would be local (i.e. not network).  Otherwise, if the process/protocol just unwraps the encryption and then RPC’s it or Kerberizes it out to the other domain controllers, then we’re back to needing secure communication and most likely a protected channel.

 

Does anyone see any allowance for the communications to be on the internal network being different than those outside the internal network?  How about communications behind a switch with all components physically on the same circuit that do not go outside the room/building?  Both still qualify as “network” communications.

 

Draw your own insight from NIST’s Glossary of Key Information Security Terms (NIST IR 7298 Rev 1)

http://csrc.nist.gov/publications/nistir/ir7298-rev1/nistir-7298-revision1.pdf

 

Internal Network –

A network where: (i) the establishment, maintenance, and provisioning of security controls are under the direct control of organizational employees or contractors; or (ii) cryptographic encapsulation or similar security technology provides the same effect. An internal network is typically organization-owned, yet may be organization-controlled while not being organization-owned. SOURCE: SP 800-53

A network where 1) the establishment, maintenance, and provisioning of security controls are under the direct control of organizational employees or contractors; or 2) cryptographic encapsulation or similar security technology implemented between organization-controlled endpoints provides the same effect (at least with regard to confidentiality and integrity). An internal network is typically organization-owned, yet may be organization-controlled while not being organization-owned. SOURCE: CNSSI-4009

 

Local Access –

Access to an organizational information system by a user (or process acting on behalf of a user) communicating through a direct connection without the use of a network. SOURCE: SP 800-53; CNSSI-4009

 

Network –	Information system(s) implemented with a collection of interconnected components. Such components may include routers, hubs, cabling, telecommunications controllers, key distribution centers, and technical control devices. SOURCE: SP 800-53; CNSSI-4009
Network Access –	Access to an organizational information system by a user (or a process acting on behalf of a user) communicating through a network (e.g., local area network, wide area network, Internet). SOURCE: SP 800-53; CNSSI-4009

 

Secure Communication Protocol –	A communication protocol that provides the appropriate confidentiality, authentication, and content integrity protection. SOURCE: SP 800-57; CNSSI-4009
Secure Communications –	Telecommunications deriving security through use of NSA-approved products and/or Protected Distribution Systems. SOURCE: CNSSI-4009

 

 

Jeff

 

From: [] On Behalf Of David Walker
Sent: Tuesday, May 14, 2013 7:26 PM
To: InCommon AD Assurance Group
Cc: DHW
Subject: [AD-Assurance] Protected Channels and the IAP

 

Everyone,

As we discussed on Friday, here are the places Protected Channels are required in the IAP that could affect what we're doing:

4.2.5.3 (S) (B) SECURE COMMUNICATION (part of 4.2.5 AUTHENTICATION PROCESS)

Communication of unencrypted Authentication Secrets between Subject and IdP must use a Protected Channel.

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 when communication includes Authentication Secrets or personally identifiable information, or when a lack of message integrity could practically result in incorrect information being associated with a Subject.

The passages in red are my words, indicating what I think is really important/intended in the requirement.  I don't think we have a problem with 4.2.5.3, but we've been wrestling with 4.2.8.2 for a while now.  Do any of us know enough about internal communication among MS IAM products to know if my red words would help?

David