A few more objectives that might be important for the Security Essentials: - Stealth mode browsing - Configuring and using system monitoring - Configuring monitoring alerts - Resource isolation (even for end users - using throwaway email accounts, for instance)
How could the cert be made more practical and less theoretical? Given that it's meant to be OS-neutral, that can get tricky. But perhaps you could require general domain knowledge (the common, underlying principles of firewalls and NACLs, for instance) and allow trainers to use whatever tools they like to teach them (AWS EC2 security groups, for instance). Wherever cross-platform tools are available (nmap, Wireshark...), they, of course, could be required. Any thoughts? David Clinton On Fri, Jun 21, 2019 at 12:14 PM Bryan Smith <[email protected]> wrote: > > > On Fri, Jun 21, 2019 at 9:53 AM DB Clinton <[email protected]> wrote: > >> >> - Similarly, we could add awareness of authentication solutions like >> FreeRADIUS, LDAP, and AD. >> >> I'd counter that, Security-wise, people need to be aware that AD (2016+ > **) with SSSD, Winbind and 'free [beer] connectors' are _Security > Findings_, as IETF RFC2307bis POSIX attributes are locally enumerated and > _not_ stored/controlled centrally. > > Either they need to ... > > A) buy proprietary connectors -- which is what proprietary vendors do, > they offer 'free' then 'bait'n switch' when it's a Security Finding -- and > those are costly (and often modify AD schema), or ... > > B) go IPA which offers an AD Forest Trust** > > We should _never_ cover AD itself (again, 2016+ **), and any 'awareness' > should be of how proprietary vendors 'get in the door' and how IPA is the > 'way out' of costly 'vendor locking' for most companies. > > Many solutions that support AD (AD-LDAP/AD-modified MIT Kerberos) also > support IPA (389-LDAP/MIT Kerberos) as well, as it acts similarly, only > storing IETF RFC2307bis POSIX attributes natively instead of NT SAM > attributes. > > I actually wrote a complete FAQ for this as part of the Linux Essentials > Section 5.1 that I'm finishing up now, exactly how AD doesn't work and will > be an audit finding without proprietary solutions, many of which modify AD > schema, which Microsoft (and most AD engineers) does not prefer. > > - bjs > > **P.S. For those that don't know, Microsoft deprecated Identity > Management for UNIX (IDMU) in 2012R2 and no longer supports it in 2016+. > This was because less than 1% of AD shops were populating the IETF RFC2307 > attributes. It was always a subset of IETF RFC2307bis any way, and > Identity, Policy, Audit (IPA) offers a superset of it with various security > functionality. Microsoft prefers the IPA approach, as it removes the need > for AD admins to be involved, while still offering AD Forest Trust level of > functionality. > > E.g., IPA Groups in AD Domain Local Groups for Windows Resources, AD > Security Groups in IPA Groups for Linux Resources, etc... little different > than Windows Servers in AD Forests. > > > -- > Bryan J Smith - http://www.linkedin.com/in/bjsmith > E-mail: b.j.smith at ieee.org or me at bjsmith.me > _______________________________________________ > lpi-examdev mailing list > [email protected] > https://list.lpi.org/mailman/listinfo/lpi-examdev
_______________________________________________ lpi-examdev mailing list [email protected] https://list.lpi.org/mailman/listinfo/lpi-examdev
