Okta Logging, Monitoring, and Alerts

ACM.166 Be aware of and investigate security problems on Okta

Part of my series on Automating Cybersecurity Metrics. The Code.

Free Content on Jobs in Cybersecurity | Sign up for the Email List

In the last post I took a look at Okta’s MFA options:

In this post, I want to know what kind of logging, monitoring, and alerting capabilities Okta offers. One of the most important things will be understanding when my Okta account is under attack. That may be identified by the following, in part:

• Someone is trying to log in from an unauthorized IP address. (Possible stolen credentials.)
• Someone has unsuccessfully authenticated a number of times. (Potential brute force attack.)
• May different accounts have unsuccessful logins in succession. (A potential password spraying attack.)
• In my case, since I’m only one person, I want to know every time an administrator logs into my account — because if it is not me, something is wrong! A small organization might want to monitor every administrator login.
• Any other sort of policy violation — global and application specific policies. (User enumeration, brute force, attempt to use stolen credentials, credential stuffing, or a successful phishing attack but the attacker got stopped by other policies.)
• Another thing I want to know is any time a user is granted admin privileges in Okta or any time those privileges for existing users changes. (The account has been compromised and an attacker is attempting to create a back door or escalate privileges, or a malicious insider is trying to do the same.)

I also want to know the following:

• Who can view the logs
• Can the logs be altered?
• Can the logs be deleted?
• Can I import the logs into a SIEM (Security Incident and Event Monitoring system)?

Okta Logs

First, make sure you are looking at the Identity Engine, not the Classic documentation as I noted in a different post. The two are quite different. It seems like Okta needs to adjust the metadata for the classic engine so the Identity Engine shows up first in search results.

Here we can see that Okta has a number of different options for monitoring and reporting.

The dashboard presents a few pieces of information that are interesting:

View Okta service status: You can view the status of the Okta service in case you are having problems authenticating. In that case, it could be Okta, your local network, or the system to which you are trying to login. That information will help you troubleshoot the problem.

Monitor your org’s security: This sounds interesting. Okta is trying to identify and report suspicious behavior. You can define permissions for who can and cannot view this information in Okta. I may add this permission to my Access Admin for now since I have a very small team. :-) You might grant this permission to your security team or SOC (Security Operations Center) in a larger organization.

Monitoring your apps: Monitoring the number of logins for statistical anomalies could be useful and that information is likely used by Okta’s suspicious activity monitoring above.

Monitoring your rate limits: If you are having system problems you will want to know if you have exceeded any rate limits. This also is helpful for troubleshooting purposes. If you choose to use Okta you’ll want to understand your capacity needs and ensure that Okta can meet them with whatever service you elect to purchase.

I’m not using agents at the moment so that doesn’t apply to me but it would be helpful for organizations that are.

Reports

Okta has a number of reports that organizations should review on a regular cadence. This is very nicely laid out and simplified for those who need to show they are reviewing these reports in conjunction with various compliance needs.

Usage report (Apps, MFA, SMS, Telephony)

Security Reports

• Password report (to help identify issues with passwords)
• App Password report (to help identify issues with application passwords, if used)
• SAML Capable Report: This report is very nice. It shows you which applications are integrated using SWA that can be converted to SAML. SAML is a more secure option as I explained in these two posts:

• Current Assignment report: how often an app integration is being used (assigned, logged in, password changes) over a specified time range. Also good information when reviewing usage activity for anomalies.
• Recent Unassignments Report: Who has been unassigned from an app. Only visible if unassignments exist for the time period.
• Proxy IP Report: Trusted proxy IP addresses can be configured in Okta Networks. Shows proxy IPs for any failed or successful logins in the past 30 days.
• Suspicious Activity Report: As it sounds, anomalous activities in your logs. You can find a list of suspicious events here:

• Deprovision details report: Information about users or apps that have been deprovisioned.
• Admin assignment report: Any new admin assignments.
• Application access: When users accessed an applications.

It appears that you can view these reports in the console or request them via email. Okta recommends requesting them in email to avoid hitting the rate usage. It does not appear that the reports can be scheduled, which would be a nice feature to add.

System Log

Besides the precompiled reports above, you can query the system log directly. The documentation does not provide a view of what is in the logs so you’ll need to login and take a look at those logs if evaluating Okta to see that they meet your needs and the information you require.

I think that the above reports require a lot of use cases but you might need more detail in the event of a security incident. Note the comments about IP chaining in the network logs and make sure you can understand which IP addresses were involved in a particular incident — before you have one and need to figure that out. Also test all networking rules thoroughly and make sure the corresponding events you expect show up in the system log for high security organizations. I’m not going to do that right at this moment.

The Okta documentation mentions quotas for the system logs. Make sure the quotas meet your needs in the event of an incident where you need to inspect a lot of data. You may instead want to pull that information into a SIEM or at least download the data for offline processing.

Log Streaming

Regarding the note above about SIEMs, you can send Okta logs to your SIEM for processing using log streaming. For example, you could ingest the logs into Splunk or into AWS using Event Bridge. This is another point where AWS Private Link would be a preferred method of network integration so that streaming data remains on the AWS network, if that is the source and destination. I wrote about that in my post on Okta networking and I don’t see that option here.

Alerts

What about alerts? The reports are nice for a periodic review but how can I get an alert if something suspicious is happening in my Okta account? Depending on the activity I want to know right away so I can investigate.

I found some email options for admin users here but this is not exactly what I am seeking.

I’ve spent a fair amount of time looking for the ability to get email alerts when suspicious activities occur — from Okta system logs, not end users. Initially when writing this post I couldn’t find any such options but later I did notice the ability to configure some email settings here which I haven’t fully explored yet:

One way to resolve that problem of not getting the alerts you want would be to import logs into your SIEM and generate alerts from there. If you take the approach of using your own SIEM you will want to have a way to validate that you are getting the complete logs from Okta at all times and get an immediate notification if logging fails.

It seems like Okta could provide this capability. Perhaps they want to stay out of the email business because a lookalike Okta alert could be leverage by an attacker in a phishing attack. However, I appreciate the alerts I can configure on Gmail related to suspicious activity in my accounts.

Perhaps you could create an alert somehow with Okta workflows, but that seems a little overly complicated compared to simply specifying which administrators should get an email alert for suspicious activity. This is a very interesting capability, however, which we will probably want to explore more later.

Another thing you can do to receive alerts is to allow users to review their activity on their own account and send the appropriate administrators an email when they notice something suspicious. You are wise to customize the related template to make it harder for attackers to copy a generic email and use it in a phishing attack as I just noted.

Well, that gives me a lot of insight and things to monitor for suspicious activity in my Okta account.

Next up, I want to start the integration process, but I am going to recreate my organizational accounts with a generic script that I can use for all new accounts. Using a generic script will help me bake in security to my new account configurations.

Follow for updates. Part of my series on Automating Cybersecurity Metrics. The Code.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2023

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab