best practices build better systems: identity assurance (237195106)

8/11/2019 Best Practices Build Better Systems: Identity Assurance (237195106)

http://slidepdf.com/reader/full/best-practices-build-better-systems-identity-assurance-237195106 1/34

BEST PRACTICES BUILD BETTER

SYSTEMS: IDENTITY ASSURANCERon Thielen, University of Chicago

Ann West, Internet2

Security Professionals ConferenceMay 7, 2014



Agenda

• Brief Intro to the Identity Assurance Profiles

• Chicago Story: Shining a Light

• There’s a Community out there….



BRIEF INTRO



Federated Transactions

Services Relying on ExternalIdentities:

• I need to trust you to manage onlineidentities for me?

• What are my risks?• What are the odds and the degree of

harm?

Parties need agreed-upon criteria for

identity assurance

Trust. Measuring and balancing:cost, risk, adoption.

4



InCommon Identity Assurance Profiles

1. Business, Policy and Operational Criteria

2. Registration and Identity Proofing

3. Credential Technology

4. Credential Issuance and Management5. Authentication Process

6. Identity Information Management

7. Assertion Content

8. Technical Environment

5



We have MFA,Why Worry About Passwords?• Do you use passwordsto protect sensitivedata?

•Not every risk is aboutphishing…

Strategy and choices

• Use stronger credentialswhere you can

• Improve passwords untilyou no longer need them

6



Provenance: InCommon Profiles

• US GovernmentFICAM

• Based on NIST 800-63

• Assesses comparability

• Profiles

• Developed for HE

• Address FICAMrequirements with HEflexibility

12/12/12 7



Due Diligence

• What standard do youuse now?



BEST PRACTICES BUILDBETTER SYSTEMS: IDENTITY

ASSURANCENotes from the field – Chicago lessons learned so far



Compliance vs. Security

• Sometimes you implement a control to achievecompliance

• Sometimes you implement a control to improve

security• Hopefully they’re both aimed at the same target,mitigating risk

• However, one is not necessarily a condition of the

other• Fortunately, working to achieve Silver compliancehas led us to see several ways in which securitycould be improved



Assurance Terms of Art1

• Identity Provider - The IdMS system component thatissues Assertions

• Credential Store - Contains Authentication Secrets for allSubjects

• Verifier - Validates the correctness of offeredauthentication material

1Identity Assurance Assessment Framework

APPENDIX C: DEFINED TERMS

http://www.incommon.org/docs/assurance/IAAF.pdf






Assurance Terms of Art

• Protected Channels - A communicationmechanism that provides message integrity andconfidentiality protection by use of an Approved

Algorithm

• Approved Algorithm - Any implementation of analgorithm or technique specified in a FIPSstandard or NIST recommendation, or anyalgorithm or technique that conforms to analternative means identified by InCommon asapproved for specified IAPs.(see NIST Special Publication 800-131A)



Issues with these terms

• SSL vs TLS for LDAP Service• Need to use Approved Algorithms and Protected Channels for

• Web page where users manage their accounts, e.g. change passwords

• Web pages used by IDMS staff to manage systems

• ssh to IDMS servers• Java libraries used for web services supported by IDMS

• Shibboleth, Grouper, etc.

• Mostly a lot of grunt work

• Active Directory



Active Directory & Silver

• Internet2 / InCommon Assurance Community Contribution – AD Silver Cookbook

https://spaces.internet2.edu/display/InCAssurance/AD+Silver+Coo

kbook

• Years in the making• Finding information difficult

• Much parsing of the assurance spec required

• So take your time digesting

• Key is to understand how your particular case fits

https://spaces.internet2.edu/display/InCAssurance/AD+Silver+Cookbook








Active Directory



Active Directory

• Challenges at Chicago• Our LMCompatabilityLevel set to 4, so still accepting NTLMv1

• Unsigned and unencrypted LDAP BINDs, mostly it seems fromMacintoshes

• Bitlocker not supported under VMWare so Cookbookrecommended solution for encrypting the password store is not anoption

• Are these Compliance or Security Issues?

• Response• Combination of technical controls and

• One or more Alternative Means statements



4.2.3.6 Strong Protection of AuthenticationSecrets• 4.2.3.6.2 “Whenever Authentication Secrets used by the

IdP (or the IdP’s Verifier) are sent between services forverification purposes (for example, an IdP to a Verifier, orsome non-IdP application to a Verifier), Protected

Channels should be used…” • 4.2.3.6.3 “If Authentication Secrets used by the IdP (or the

IdP’s Verifier) are exposed in a transient fashion to non-IdP applications (for example, when users sign on tothose applications using these Credentials), the IdPO

must have appropriate policies and procedures in place tominimize risk from this exposure.”

• How does this apply to NTLMv1? Unsigned LDAPBINDs?



NTLMv1

• Since our LMCOMPATABILITYLEVEL = 4 we still acceptsome NTLMv1 credentials

• But NTLMv1 isn’t the IDP’s Authentication Secret, so who

cares?

• Well there’s always this …



NTLMv1 -> password for $34



NTLMv1

• Given how weak NTLMv1 credentials are this is a securityissue, not a compliance issue

• First thought was, let’s turn our shields up to 5

•Turns out that may not be possible for a very particularreason



RADIUS

• MS-CHAPv2 is cryptographically equivalent to NTLMv1

• EAP-MS-CHAPv2 is fairly ubiquitous

• EAP-PEAP uses TLS to protect the MSCHAPv2

credential, so client->RADIUS server is fine• If your RADIUS is one of those using SAMBA code,

specifically WINBIND and ntlm_auth, then RADIUSserver->Domain Controller is NTLMv1



RADIUS

• Solutions• Move off 802.1x EAP-PEAP to EAP-TLS

(requires certificate management for all client devices, i.e. not goingto happen soon)

• Move to NPAS (Network Policy and Access Services) on WindowsServer 2008 or later

• Create Protected Channels between all RADIUS servers andDomain Controllers

• Could be something like IPSEC tunnels

• Could be private, non-routable VLANs (IMHO)• Could use RADIUS proxies on DCs and something like radsec to create

TLS connection between wireless infrastructure RADIUS and DCRADIUS proxies



Monitor and Mitigate

• Not everything can be easily fixed by a technical controleven when a suitable technical control exists• Politics

• Resistance to change

• Etc.

• Still have LMCOMPATABILITYLEVEL set to 4

• Could still accept an NTLMv1 credential from somerandom connected non-RADIUS system

• While we will implement a technical control to manage theRADIUS issue, we will use Monitor & Mitigate to addressany non-RADIUS NTLMv1



NTLMv1 with Monitor & Mitigate

• Event 4624 is generated for logon events

• NTLM logons generate “Package Name” field which tells

you which version of NTLM, e.g V1

• Recommend filtering since 98% might be for user ANONYMOUS

• BTW - RADIUS AuthN apparently does not generate a4624 event



NTLMv1 with Monitor & Mitigate

• PowerShell script currently filters and write 4624 eventsto flat files on a share - Will probably replace with nxlog(http://nxlog.org/)

Sample

4624,some_DC,05/03/2014 16:42:52,S-1-0-0 - - 0x0 S-1-5-21-1644491937-

1604221776-725345543-62358 some_user some_domain 0xc190e973 3 NtLmSspNTLM some_system {00000000-0000-0000-0000-000000000000} - NTLM V1 128 0x0 – some_ip_address 2189,(System.Diagnostics.EventLogEntry.message)

• Daily Perl script processes the log files, creates reports,removes Silver capability for any ID found, and opens a

helpdesk ticket in that event• This may be good enough for compliance but doesn’t do

much for security

• The next step is to go fix the problem at the source

http://nxlog.org/

http://nxlog.org/



LDAP BINDs in the clear -> DCs

• By default Active Directory provides LDAP services and ishappy to accept BINDs in the clear

• You can• turn on LDAP signing; or

• you can require LDAP to use SSL or TLS; or

• IPSEC for everyone!

• Requiring LDAPS is likely a non-starter since it reportedlyimpacts Windows clients

• LDAP Data Signing• encrypts the payload

• Prevents MITM attacks

• Is likely to break some non-Windows clients (Macs and Samba)



4.2.3.4 (S) STORED AUTHENTICATION SECRETS

• 4.2.3.4 requires that the Authentication Secrets used bythe IDP and its verifier be• Stored using a salted hash, or

• Encrypted using and Approved Algorithm and decrypted as

needed, or• Protected using a method consistent with NIST SP 800-63 LOA 3

or 4

• Active Directory does none of these by default

• AD Silver Cookbook recommends using some encryptiontechnology like BitLocker to encrypt the AD passwordstore




• Bitlocker is not supported under VMWare

• Most of our DCs are virtual machines

• Other encryption solutions exist, but we don’t have any of

these so there’s an adoption speed bump

• We’re going to try a different approach

• We’re doing a Threat/Risk analysis and developing

Alternative Means to mitigate the risks we believe 4.2.3.4means to address




• Example Controls:• White-listing applications

• Physical media management controls already audited for FISMA(medium)

• MFA for administrative access using bastion hosts• Alarming on unusual netflows for DCs

• Basically, anything reasonable that might mitigate data exfiltrationor rogue processes on the DCs



End-to-end Security for LDAP AuthN

• Remember 4.2.3.6.3 “IdPO must have appropriatepolicies and procedures in place to minimize risk fromthis exposure”

• LDAP service (the IDP’s Verifier) is locked down, but • Anyone on our campus can use our LDAP service for AuthN

• We encourage the use of Shibboleth so

• We know it’s reasonably secure • They don’t have to create forms or code for AuthN

• However there’s still lots of forms based AuthN fromweb pages on campus



Securing LDAP frontend points

• No a priori way to be sure that they all have properlyconfigured SSL certs, or any SSL for that matter

• Created scripts to go through LDAP logs• Identify IP addresses for sources of BINDs

• Nmap those addresses to identify likely ports through which userscould be submitting credentials

• Crawl over the high risk sources looking for insecure pages askingusers for passwords (Risk is based on volume or velocity of

AuthNs)

• Create ticket for someone (me) to look at the system in questionand motivate remediation

33



Questions? Answers.

Framework and Profiles

• Identity Assurance Assessment Frameworkwww.incommon.org/docs/assurance/IAAF.pdf

• Identity Assurance Profiles

www.incommon.org/docs/assurance/IAP.pdf

Resources

• Monthly Call:First Wed of the month Noon ET

• Website, discussion list and Implementerswiki: assurance.incommon.org

• Community Contribution – AD Silver

Cookbookspaces.internet2.edu/display/InCAssurance/AD+Silver+Cookbook



http://www.incommon.org/docs/assurance/IAP.pdf


http://localhost/var/www/apps/conversion/tmp/scratch_8/assurance.incommon.org





http://localhost/var/www/apps/conversion/tmp/scratch_8/assurance.incommon.org











Thank you!

Ron Thielen• [email protected]

• Security, IT Risk andCompliance

• University of Chicago

Ann West

• [email protected] • InCommon Assurance

and Community

• Internet2

mailto:[email protected]





best practices build better systems: identity assurance (237195106)

Documents