This course covers a wide variety of IT security concepts, tools, and best practices. It introduces threats and attacks and the many ways they can show up. We’ll give you some background of encryption algorithms and how they’re used to safeguard data. Then, we’ll dive into the three As of information security: authentication, authorization, and accounting. We’ll also cover network security solutions, ranging from firewalls to Wifi encryption options. Finally, we’ll go through a case study, where we examine the security model of Chrome OS. The course is rounded out by putting all these elements together into a multi-layered, in-depth security architecture, followed by recommendations on how to integrate a culture of security into your organization or team.
At the end of this course, you’ll understand:
● how various encryption algorithms and techniques work as well as their benefits and limitations.
● various authentication systems and types.
● the difference between authentication and authorization.
● how to evaluate potential risks and recommend ways to reduce risk.
● best practices for securing a network.
● how to help others to grasp security concepts and protect themselves.

TE

Thank you to all the instructors. I learned concrete and useful IT skills from the courses and especially from the projects. After completing this course, I feel I want to learn more and more.

DS

Jan 30, 2019

Filled StarFilled StarFilled StarFilled StarFilled Star

Course 1 and 5 are probably my favorite of the courses because i feel i learned a lot in these two the most, all are great i just really wanted to learn more about security which was course 5

レッスンから

AAA Security (Not Roadside Assistance)

In the third week of this course, we'll learn about the "three A's" in cybersecurity. No matter what type of tech role you're in, it's important to understand how authentication, authorization, and accounting work within an organization. By the end of this module, you'll be able to choose the most appropriate method of authentication, authorization, and level of access granted for users in an organization.

講師

Google

字幕

Single Sign-On or SSO is an authentication concept that allows users to authenticate once to be granted access to a lot of different services and applications. Since reauthentication for each service isn't needed, users don't need multiple sets of usernames and passwords across a mix of applications and services. SSO is accomplished by authenticating to a central authentication server, like an LDAP server. This then provides a cookie, or token that can be used to get access to applications configured to use SSO. Kerberos is actually a good example of an SSO authentication service. The user would authenticate against the Kerberos service once, which would then grant them a ticket granting ticket. This can then be presented to the ticket granting service in place of traditional credentials. So, the user can enter credentials once and gain access to a variety of services. SSO is really convenient. It allows users to have one set of credentials that grant access to lots of services, making it less likely that passwords will be written down or stored insecurely. This should also reduce the overhead for password assistance support and removes time spent re-authenticating throughout the workday. So, what's the downside? Well, an attacker that manages to compromise an account has a lot more access under an SSO scheme. User credentials will grant access to all applications and services that that account is permitted to access. So, a big plug here for using multifactor authentication in conjunction with an SSO scheme. But this opens a new channel of attack, theft of SSO session cookies or tokens. Instead of targeting credentials directly, attackers can try to steal the SSO tokens directly which will permit wide access if even for a short amount of time. Stealing these tokens, also lets an attacker dodge multifactor authentication protections since the session token permits access without requiring full authentication until the token expires. An example of an SSO system is the openID, the centralized authentication system. This is an open standard that allows participating sites known as Relying Parties to allow authentication of users utilizing a third party authentication service. This allows sites to permit authentication without requiring the site itself to have authentication infrastructure, which can be tricky to implement and maintain. It also lets users access the site without requiring them to create a new account, simplifying access management across a wide variety of sites. Instead, a user just needs to already have an account with an identity provider. To ask for authentication, first a relying party looks up the openID provider, then establishes a shared secret with the provider if one doesn't already exist. The shared secret will be used to validate the openID provider messages. Then, the user will be redirected or asked to authenticate in a new window through the identities provider's log and flow. Once authenticated, the user will be prompted to confirm if they trust the relying party or not. Once confirmed, credentials are relayed to the relying party, typically in the form of a token not actual user credentials which indicates the user is now authenticated to the service. Now it's time for practice quiz on authentication.