Would this be something that can be used as a study resource? https://www.futurelearn.com/courses/teaching-cybersecurity?utm_campaign=raspberry_pi_teaching_cybersecurity_june_2019&utm_medium=organic_web&utm_source=rpwebsite <https://www.futurelearn.com/courses/teaching-cybersecurity?utm_campaign=raspberry_pi_teaching_cybersecurity_june_2019&utm_medium=organic_web&utm_source=rpwebsite>
Met vriendelijke groeten, Marco Verleun [email protected] www.marcoach.nl 06-44 55 22 70 Certified Master Trainer LPI Certified BTW: NL-191980882B02 KvK: 54438519 DUNS: 49-041-7366 Registered with CRKBO: https://www.crkbo.nl/Register/Docenten > Op 24 jun. 2019, om 16:31 heeft DB Clinton <[email protected]> het volgende > geschreven: > > 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] > <mailto:[email protected]>> wrote: > > > On Fri, Jun 21, 2019 at 9:53 AM DB Clinton <[email protected] > <mailto:[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 > <http://www.linkedin.com/in/bjsmith> > E-mail: b.j.smith at ieee.org <http://ieee.org/> or me at bjsmith.me > <http://bjsmith.me/> > _______________________________________________ > lpi-examdev mailing list > [email protected] <mailto:[email protected]> > https://list.lpi.org/mailman/listinfo/lpi-examdev > <https://list.lpi.org/mailman/listinfo/lpi-examdev>_______________________________________________ > lpi-examdev mailing list > [email protected] > https://list.lpi.org/mailman/listinfo/lpi-examdev
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ lpi-examdev mailing list [email protected] https://list.lpi.org/mailman/listinfo/lpi-examdev
