> * Should "022.2 Web Encryption" be "022.2 Website Encryption" (to differentiate it from the "024 Network and Service Security" domain)?
More generally should there be a discussion of the "web sites" that people visit with their browser and the "web services" that software uses - primarily SOAP and REST APIs. At an introductory level they don't need to know details beyond the fact that there's the C2B services that they're familiar with and the B2B services behind the scenes that use many of the same technologies. Bear On Tue, Jun 25, 2019 at 12:49 AM Marco Verleun <[email protected]> wrote: > 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 > > 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]> 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 > > > _______________________________________________ > 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
