Blog

The latest in Dark Rhino Security news

3 Ways To Keep Your Data Secure

3 Ways To Keep Your Data Secure

Avoid using social media messaging services

When you’re using a messaging service provided by a social media company, there is no such thing as privacy. That social media company can see everything you message. So, if you’re using Facebook Messenger, or WhatsApp, or Instagram, Facebook can see everything you message. If you’re using DMs on Twitter, Twitter can see everything you say.

Emails and regular texts, on the other hand, are protected by privacy laws, meaning that a private company can’t root around them at will. If you’ve got something to say to someone, you’re better off emailing or texting.

Generate & store your passwords securely

Good password security has two components:

  1. Generating unique passwords for every login you have
  2. Storing those passwords somewhere they won’t get stolen

The first part, generating unique passwords for every login, is critical. The websites you log in to sometimes get hacked, and those stolen passwords are sold on the black market and used to break into your other accounts. If you have the same password for every internet account, you are just one hack away from being completely vulnerable.

Want to know if your passwords have already been hacked? Check for free on haveibeenpwnd.com

The second part, storing those passwords, is equally as important. It doesn’t matter how unique and secure your passwords are if your list of passwords can be easily stolen. And unfortunately the ways most people store their passwords, such as making a list in their notes app or writing them down in a notebook, are notoriously insecure.

In order to store your passwords properly, you want to use a password vault. Most major browsers come with their own password vault, but we recommend LastPass or 1Password.

Store your data on the cloud

Data loss doesn’t just come from hackers; data loss can come from natural disasters. If your data is stored locally on your laptop or on an external drive, flooding or a fire can wipe out your personal data just as quickly as a hacker can. Data that’s stored on the cloud, on the other hand, is impervious to these natural disasters.

Most major hardware providers have their own cloud storage solution. Google offers Google Drive, Apple offers iCloud Drive, and Microsoft offers OneDrive. There are also third-party solutions available, such as Dropbox or the encrypted alternative Sync.com. The best part is that most of these solutions are free — meaning there’s no excuse for you not to use them.

4 Common Misconceptions About CCPA Compliance

4 Common Misconceptions About CCPA Compliance

Correcting these misconceptions could save you thousands in fees

1. “We will be compliant once we update our privacy policies.”

A published privacy policy is great marketing for a company. It communicates to customers that you care about their privacy and security.

That being said, merely having a privacy policy is not enough. For a privacy policy to matter, you need to ensure that…

  1. The company privacy policy is up to date with what leadership wants. Many companies take a “set it and forget it” approach to their privacy policy. Having an out-of-date privacy policy published means customers are being scared away by privacy policies that do not take the current security climate into account. Having an out-of-date privacy policy published also means employees are not clear on the privacy target at which they should be aiming.
  2. The company privacy policy is actually being followed. In many companies, privacy policies are often ignored in favor of creating convenient employee workarounds (i.e. carrying flash drives of customer information around the office.) These workarounds may be convenient for employees, but they expose customer information to a lot of abuse, and the CCPA was written with this in mind.

2. “CCPA is IT’s problem.”

While technology is vital to CCPA compliance, it is not the only component of CCPA compliance. As mentioned above, many employees often create workarounds for their personal workflows that compromise customer information. These workflows are not an IT problem, these are an Operations problem, and so plugging these holes requires participation from Operations. Many customers also contact companies through their helpdesk and social media and provide personal information through these channels; CCPA requires companies have the processes in place to delete these sources of customer information as well. All of the holes in your company must be plugged in order to be CCPA compliant.

3. “We are already adding an Opt Out button on our privacy page.”

There are two misconceptions at play here. The first is that an opt-out button on the privacy page is adequate. It is not. The opt-out button must be on the home page for CCPA compliance. The second is the efficacy of the opt-out button:

  • Does the act of “opting out” trigger information removal from multiple systems?
  • Does it communicate this request to 3rd party affiliates?
  • Does this produce a report about what steps were taken to remove the information & send it back to the requesting party?

To be compliant with CCPA, the opt-out button on your home page must do all these things.

4. “We did this all for GDPR two years ago, so we are good!”

While GDPR and CCPA were both passed for similar political reasons and have many similar requirements, they are not the same. Relying on your GDPR compliance for your CCPA compliance will most likely result in your company not being CCPA compliant at all.

DLP Piper deep dives into the differences:

In some respects, however, the CCPA does not go as far as GDPR. Most crucially, the CCPA does not require businesses to have a “legal basis” (a justification set forth in GDPR) for collection and use of personal information. The CCPA also does not restrict the transfer of personal information outside the US, or require that businesses appoint a data protection officer and conduct impact assessments. In addition, California residents’ right to access personal information is limited to data collected in the past 12 months. CCPA also places fewer obligations on service providers.

In other respects, the CCPA differs or goes beyond the scope of GDPR:

  • The CCPA’s definition of personal information specifically includes household information.
  • While both the CCPA and GDPR require detailed privacy notices, the required content of those notices differs. A privacy policy that meets the requirements of the GDPR will likely not satisfy the CCPA’s requirements.
  • Under GDPR, a business does not necessarily need the individual’s consent to collect and use data, in which case the individual does not have a general opt-out right. But CCPA grants individuals an absolute right to opt out of the sale of their personal information and obligates businesses to add a “Do Not Sell My Personal Information” link on websites and mobile apps.
  • Although both the CCPA and GDPR prescribe provisions that must be included in contracts with service providers, the requirements differ, and GDPR data processing agreements will likely not meet CCPA requirements.
  • Finally, the GDPR and CCPA take different approaches to children’s privacy rights. GDPR requires that parents provide consent for the processing of their children’s personal information in an online environment — but only where the legal basis for processing is consent. Children are defined as under 16, although member states can lower the age to 13. The CCPA, in contrast, addresses the sale of children’s information — not all processing — and requires that businesses first obtain opt-in consent. Parents must provide consent for kids under 13; teens 13–15 can provide their own consent.
How To Configure Okta’s Flexible Security Policies For Your Environment

How To Configure Okta’s Flexible Security Policies For Your Environment

One of the nice things about working with Okta’s SSO platform is that even though they aren’t a tried and true security company, they have built a lot of security tools into their product. When leveraged correctly, these tools really help lock down employee access to enterprise applications and give the security folks at your company helpful insight into how employees access governed cloud services.

No matter how powerful the software, though, if it is configured incorrectly, it poses a security risk. The most secure system is one implemented by a competent system administrator.

This guide will explain the different security policies in Okta — and, hopefully, help you become competent with Okta yourself.

Sign On Policies

Okta allows admins to configure sign-on policies at two different points during the user experience. The first is initial sign-on to Okta, when a user tries to log in to Okta directly from the http://www.w3.org/2000/svg\">"); background-size: 1px 1px; background-position: 0px calc(1em + 1px); background-repeat: repeat no-repeat;">https://yourdomain.okta.com URL, and the second is when they try to access an SSO application from their Okta end-user dashboard.

This means you have two places you could configure your MFA policies: at the front door, or prior to accessing specific applications. (I don’t recommend configuring your policies in both places, or doubling up, because there is nothing end users hate more.)

Let’s look at two scenarios and investigate how these different approaches might fit into your environment.

Scenario 1:

Company A

  • 500 Users
  • 2 Office locations with 200 employees apiece
  • 100 remote users (contractors & sales)
  • 5 mission critical applications in Okta, nothing else.

Info:
Company A has been configured by admins to only allow SSO into 5 big-ticket applications, O365, Salesforce, Box, Tableau & AWS. All of these application contain very sensitive information pertinent to the day-to-day operations of Company A, as well as a lot of valuable IP.

How would you configure security policies for Company A?
There are a few ways you could approach this, but I’ll explain the approach that is the simplest while still being secure.

First, I would whitelist the external IP’s users inside Company A’s offices that will be accessing Okta. This allows these IPs to skip being challenged for Okta if they are operating from inside the office. Some people would contest that this is not secure, but unless the company has compliance requirements they need to meet (like MFA for all content-sharing apps), I generally try to leave the Okta user-experience as simple and straightforward as possible.

This is especially helpful when introducing Okta to them for the first time. If users see Okta as a convenience, rather than a hindrance, Okta projects run much more smoothly.

The only other policy you would need to configure is the front-door policy for remote users. You can configure this under the “Security” > “Authentication” tab, and then under the “Sign-on” sub-tab. A front-door policy is the best policy here because configuring 5 separate policies for each app creates unnecessary overhead on the part of the user.

Lastly, I would configure a session timeout. This means that if someone‘s laptop were to get stolen, company information would still be secure.

Scenario 2:

Company B

  • 50 Users, 1 office
  • Startup company with a highly mobile workforce. Over half of the employees are remote
  • 2 Apps, Github & Dropbox
  • User self-service is active

Info:
Company B has been using Okta since it’s inception. It’s employees use Okta to access Company B’s Github and Dropbox environments via SAML, but they also use Okta as a store for whichever apps they see fit thanks to user self-service. In addition to Github and Dropbox, they have added personal accounts to various websites and disparate email services added to their end-user dashboards as well.

How would you configure security policies for Company B?
Since Company B is a startup and have yet to lock down which applications their employees use for official business purposes (outside of Github and Dropbox), I would recommend configuring MFA only for Dropbox and Github. These are the only applications which need secured from a company perspective, so it is more convenient to leave the sign-in to Okta free from MFA.

The central issue in this scenario is not really Okta security policies, but company policies themselves. Startups often use many different applications, most of which do not support sophisticated integration with Okta. Until Company B decides which services to officially support, they should just focus on putting MFA on their business critical applications and leave the rest untouched.

If you as an admin are concerned about users adding MFA to their personal accounts, a better way of enforcing it is setting it up app-side. Applications like Twitter and Facebook have their own MFA. If you know your users heavily use the self-service features of Okta, a company-wide email about setting up MFA individually in these applications is a smarter move, because I know from experience if you don’t have these applications configured with SAML and you put an MFA policy on it, end-users will just navigate to the site’s regular login in order to bypass MFA.

In Conclusion

That’s it for now, configuring security policies in Okta can only hold my attention for so long and I’m sure any readers feel similarly. Thanks and stay tuned for more.

How Can Organizations Attract and Retain Qualified Professionals?

How Can Organizations Attract and Retain Qualified Professionals?

How can organizations attract and retain qualified professionals?

It is a seller’s market right now when it comes to IT employment. Especially in the security and risk field. Consider this, information security has had 0% unemployment for the last three years running and ISACA projects a shortage of 2 million security practitioners next year. Cybersecurity Ventures believes that number will reach 3.5 million by 2021. That’s a lot of unfilled jobs! Not to mention, burnout for security professionals working in an enterprise environment is common to say the least. So, how can organizations attract and retain qualified professionals?

Having spent the last 6 years of my career in IT recruiting, I’ve seen my fair share of approaches.

Ping pong tables, video games, and kegs on premises for the fun and casual work environment.

Flexible schedules, discretionary paid time off, and remote work capabilities to help strike a strong work-life balance.

Clear growth paths and consistent advancement with continuing education. Etc.

These are all well and good, but in my experience, the companies who are offering high salaries and stable employment win out more often than not. Another route many companies take is to train less experienced IT employees into the security field, but this too comes with its own unique set of obstacles…

First, you need to already have at least some security and risk expertise within your organization, as well as the time and the resources available for them to train someone. This is a tall order in an industry that has 1 job vacancy for every 2 employees.

Second, this doesn’t directly address the challenge of balancing employee salaries and company budgets. Sure, you could pay a lower starting salary as one develops his or her skills, but what is to stop them from leaving for greener pastures once they are up to speed?

Unfortunately for employers, this means that the cost of full time employment is steadily rising, as is the prevalence of contracted and project-based hiring. Because of this, finding a balance between offering potential employees the salaries they want, while staying within the company’s budget is becoming more and more difficult.

Enter Dark Rhino Security. As a managed provider, we are separate from your organization, its people, and its politics. We leverage the best industry standards and practices to objectively assess, investigate, and manage your information’s security and risk. With a managed provider, you no longer have to concern yourself with where to find the right people or how to keep them in your organization. We have an expert team of highly dedicated security specialists, supported by strategic and emerging technology partners, who are laser focused on information security for our customers. Combine that with our focus on culture and personal growth, and you’ve found yourself a stable, go-to partner for risk and security.

The Two Key Benefits of Tying O365 To Okta

The Two Key Benefits of Tying O365 To Okta

Most businesses's that we work with utilize Office 365 to varying degrees. No matter which mix of the O365 services that a business uses, you can pretty much guarantee that Email is at the centerpiece of every environment. After performing a few O365 & Okta integrations, I have seen two key benefits of tying in O365 to Okta that aren't immediately apparent.

First off, Office 365's logging features, they exist but the problem is that they are somewhat limited. You can view user metrics such as number of emails sent, last login, app usage, etc. but where do you look for failed or unusual logins? Does a run-of-the-mill IT admin have any indication when their accounts are being bruteforced? If you enable audit logging you then have access to logs of admin access, but these reports are designed to show when an admin accesses a user's account so that you can maintain a paper trail and have record of possible internal leaks. They are not meant to track the actions of external bad actors.

Immediately after doing an O365 integration with one of our customers, we noticed a fair amount of their users were locked out overnight. Okta's reporting features showed us that these users had hundreds of attempted logins to [portal.office.com] from a province somewhere in China. It appeared that they were attempting to bruteforce the accounts, but with no user lockout feature or logging of that capacity, the admins we were working with had NO IDEA that their user accounts were being hammered like that! We also retrieved a nice list of suspect IP's that they were able to cross-reference on their firewall & SIEM to investigate further.

The second way Okta helped was through Dynamic IP Black/Whitelisting. By default, in O365, an admin can maintain an IP address block list within the ‘Exchange Online’ admin center that allows you to configure rules under the 'Connection Filter' section. Unfortunately, the IP addresses you configure here are not dynamic, you are required to maintain the list of IPs yourself. This can be done if you manually update a host file already, but it can not effectively block logins from specific locations like countries or states.

The customer we worked with here was able to apply company-wide GeoIP settings from Okta to O365. Now, a service which previously had spotty access control, was completely barring users that attempted to login from anywhere outside the US. Instead they were redirected to Okta and subjected to the sign-on policies configured there.

These two features help provide improvement and insight into any O365 environment that hasn't already invested heavily into configuring Microsoft's security tools and provided a uniform access policy across ALL of their cloud apps.

Troubleshooting O365 Provisioning Errors in a Cloud-Based Infrastructure

Troubleshooting O365 Provisioning Errors in a Cloud-Based Infrastructure

As simple as it sounds, there are many pitfalls when it comes to integrating your directory with Office 365. The bulk of these issues stem from the provisioning side of the integration by not matching up the correct unique identifiers in both of the user accounts. In some cases, Office 365 is not listing an Immutable ID for an end user or Office 365 is not recognizing a certain account from your cloud-based directory.

While this solution will only work for certain use cases, like the ones I mentioned above, this error is a common problem that you’ll run into if you’re finding provisioning issues to Office 365. I’ll walk you through the process of manually setting an Immutable ID in Powershell and your source directory so that the two accounts can correctly match up.

By manually setting an Immutable ID for certain end users, your source directory and Office 365 will be able to successfully recognize the user and provision him or her directly to Office 365.

1: Open Powershell and run it as an administrator

2: If you haven’t already, you’ll need to install the Office 365 powershell cmdlet. You can do that by running the following command: “Install-Module MSOnline”. If prompted, type “Y” to finish the installation.

3: Run “Connect-MsolService” to connect Powershell to your Office 365 tenant. You’ll then see a screen asking you to sign into your Office 365 Tenant. If your domain is already in a federated state, I highly recommend logging in with a .onmicrosoft.com domain global administrator account.

4: After that, have a list ready of your problematic users that aren’t syncing correctly with Office 365. For these users, you’ll first need to change the User Principal name before you change the Immutable ID. The reasoning for this step is because you cannot alter an immutable ID for a user that’s a part of a federated domain. Run the following command to change the UPN from @domain.com to @tenantname.onmicrosoft.com:

Set-MsolUserPrincipalName -UserPrincipalName This email address is being protected from spambots. You need JavaScript enabled to view it. -NewUserPrincipalName This email address is being protected from spambots. You need JavaScript enabled to view it.

5: Once the user’s UPN is changed to a .onmicrosoft domain, you’ll now be able to alter or create an immutable ID manually. To accomplish this, I recommend visiting  https://www.guidgenerator.com/ to generate your unique Immutable ID value. This is similar to what a Source directory would do to map the Immutable ID attribute.

Note: Make sure Base 64 encoding is checked before you generate your GUID

6: Now that you have your randomly generated GUID value, you can change the Immutable ID. Go ahead and run this script:

Set-Msoluser -UserPrincipalName This email address is being protected from spambots. You need JavaScript enabled to view it. -ImmutableID <GUID Value Here>

7: Since you’ve successfully changed the user’s Immutable ID, you’ll now need to change the user’s UPN back to its original state. Modify the command from step four to make it so you’re changing the UPN from the .onmicrosoft domain to the federated domain.

Set-MsolUserPrincipalName -UserPrincipalName This email address is being protected from spambots. You need JavaScript enabled to view it. -NewUserPrincipalName This email address is being protected from spambots. You need JavaScript enabled to view it.

8: At this point, you can now verify that the new Immutable ID is showing up in the user’s office profile via Powershell. Run “Get-MsolUser -UserPrincipalName This email address is being protected from spambots. You need JavaScript enabled to view it. | select *” to make sure the Immutable ID is correctly showing up in the user’s profie.

While we completed the Office 365 portion of this configuration, we’ll still need to make the necessary changes in the cloud directory (I’ll be using Okta as my cloud directory example).

9: In Okta, you’ll need to make sure that the provisioning Options (Create, Update, Deactivate, Sync Password) are all disabled. If the user is assigned to Office 365 currently, go ahead and unassign the user from Office 365.

10: Next, Reassign the user to Office 365. After you click assign, you’ll be prompted for a space to manually input the newly created Immutable ID. Feel free to copy/paste the value into the Immutable ID textbox.

All that’s left to do now is to assign the correct licenses and roles to the end user inside Okta and you should be all set. You’re now able to turn back on the provisioning features inside Okta to master all of your O365 users in one central location. Test authentication with the problematic user and verify that the authentication flow is successful.

Although manually setting/resetting a problematic user’s Immutable ID is not always the fix to a provisioning solution, it’s a good place to start when it comes to diagnosing certain provisioning problems. These steps offer a great way to rule out any chance that your error is stemming from a unique ID issue.  If the Immutable ID fix did not correct the user synchronization, there is likely something else deeper at play. Look for other attributes that could be causing the Sync to fail, and then resync the values between Office 365 and Okta.

News

Subscribe to Our Newsletter

Image
Image

Address (United States)

5695 Avery Road
Dublin, OH 43016

Address (United Kingdom)

31 Sapphire Rd
Bishop's Cleeve
Cheltenham
Glos GL52 7YT

Talk to us

+1 (614)-401-3025

Support