PowerShell Slow to Load and AutoFill

I had this problem on a server for a while – when first launching PowerShell, it would take ~20 seconds or so to accept input. Also, when pressing tab to auto-complete a command, it would again take ~20 seconds to start, like it was freezing. These were one time problems when launching PowerShell, after that it would work fine until a new session was launched.

A lot of searching didn’t help me work it out, so I logged a Microsoft case. After a few task manager executable dumps, they worked out the delay was on a path I had in an environment variable. Somehow in my account’s user variable, I had a github desktop path that was mapping to a network share, using a PC name that was decommissioned (e.g. ;\\pcname\c$\Users\AdamFowler\AppData\Local\GitHubDesktop\bin.

I expect that this name was timing out, and PowerShell was waiting a while before giving up. In case you have the same symptoms as me, check the environment variables – user variables paths if it’s only your account affected, or the system variables if it’s all users. Click on the path value, then click edit, and remove anything that shoudn’t be there (take a backup of the text if you aren’t sure, it’s easy to put back in if you keep a copy).

To get to Environment Variables, depending on the OS version, get to System Properties, the Advanced tab, and then the Environment Variables button:

Hope that helps someone else with the same problem!

Device Limit Reached – Intune Company Portal App

Device limit reached – You have added the maximum number of devices allowed by your company support. Plesae remove a device from the Azure portal or get help from your company support.

There’s a limit to the amount of devices you can register for the Intune Company Portal app.

To fix this, yes you’ll need to remove a device attached to your account. This is not done via Outlook for Web, where you can remove devices – that’s purely for Outlook. It’s also not done via https://myaccount.microsoft.com/device-list as it’s not removing it from Azure.

As per Microsoft Documentation , there’s Intune device limits, and Azure device limits. Intune / EndPoint Manager has a maximum of 15 devices, where Azure has a default of 20, but can be changed to a few different values, including ‘unlimited’.

Intune / Endpoint Manager Device Limits
Azure Device Limits

To remove devices from a user, and admin should use Azure Active Directory and go to Users > Find the user > then under Manage, choose ‘Devices’. Any old device (check by the activity date) can be selected and deleted.

After removing enough devices here, you should be able to register the new device via the Intune Company Portal app again – and in my testing, this was next to instant.

Best Practices to Maintain Application Security across Platforms

Application security is the process of finding and fixing security vulnerabilities in applications for enhancing their security.

With application security, the goal is to prevent code or data within applications from getting hacked or stolen. Though this process was hardly popular a decade ago, application security has become a crucial part of today’s software development lifecycle.

Nowadays, it has become one of the top priorities for businesses, thanks to the ever-changing and ever-growing digital ecosystem.

Also, it has become one of the major challenges for software developers and security professionals since today’s software have become more complex than ever and cybercriminals are continuously improving their efforts and skills to find vulnerabilities and compromise applications.

Why is application security the top priority cybersecurity work for businesses? According to Verizon’s 2020 Data Breach Investigations Report, web applications top the list of hacking vectors used in the popular breaches in 2020.

That is, the report confirms that cybercriminals mostly target applications’ vulnerabilities to compromise an organization’s networks and systems and wreak havoc on their target organization. Moreover, the report predicts that this trend of attackers targeting web application vulnerabilities is not going away anytime soon. S

What made application security so lucrative to attackers?

According to The Increasing Risk to Enterprise Applications by Ponemon Institute, “Investment in application security is not commensurate with the risk. An average of 16 percent of the overall IT budget is dedicated to data protection and security. There is a significant gap between the level of application risk (33 percent of total risk) and what companies are spending to protect their applications (20 percent of annual spending in IT security). However, the level of risk to networks is much lower (18 percent) than the investment in network security (35 percent),” states the report about the investment vs. risk ratio of application security.

That means organizations are not doing enough to mitigate application security risks. The report states that 74 percent of respondents reported that it is difficult to prevent online attacks targeting application vulnerabilities because their organizations are unable to monitor and prevent attacks at the application level, unfortunately. And one of its major reasons is the shift to cloud computing, which resulted in the loss of control and visibility over business-critical apps, as reported by 81 percent of respondents. Moreover, the information technology industry quickly adopted remote working in 2020 due to COVID-19, which left decision-makers with no to little time for performing the security planning.

Nowadays, organizations are not restricted to one cloud provider, but they mostly opt for a multi-cloud architecture for their mission-critical applications.

The reason being this architecture provides better reliability and speed for their applications, however, it hampers its security because of its complexity. Also, the popularity of mobile applications has skyrocketed in recent years, making organizations of all sizes to launch mobile versions of their applications, and thus providing more attack surface to the hackers and increasing the probability of attacks.

How to maintain application security across many platforms?

First of all, organizations must follow application security best practices starting with the industry-leading practices around multi-cloud security. They must synchronize their policies and settings across their cloud setups, use multiple security policies (one per application or service).

Automate as much as possible, choose the right security tools, configure a monitoring strategy to keep track of all cloud setups, opt for efficient compliance tools, simplify security by bringing all controls under a single dashboard, and minimize point security solutions that do not integrate with each other or the all-in-one centralized dashboard.

Secondly, organizations should understand the threats of APIs. They must perform regular security testing of their APIs, monitor third-party applications using their APIs, follow the industry best practices for APIs, add solid support for authentication and authorization, double-secure the data at the backend like databases and data lakes, and opt for security tools and gateways for APIs.

With regular security testing of the codebase as well as third-party applications and libraries, organizations can decrease the chances of attacks on their apps.

Thirdly, organizations must secure their mobile applications from the ground up by writing secure code and encrypting all data on mobile devices.

As with any software, developers must cautiously utilize third-party libraries as open-source libraries can be extremely insecure and vulnerable, providing access to the apps in the hands of attackers, deploy proper authorization and authentication along with session handling, utilize the principle of least privilege, and opt for the best cryptography and security tools and techniques along with regular testing.

Lastly, organizations should understand the risk of bots.

In recent years, hackers have gained unprecedented resources for compromising millions if not billions of devices to perform their bidding. Though web application firewalls may offer crucial security capabilities to detect and prevent complex attacks, they are not enough against bot traffic. That is why businesses must opt for bot management tools to build a robust defense posture against bots and attacks like DDoS.

Microsoft Forms now has a shorten URL option

Such a basic thing, but great to see. As per this Forms Uservoice suggestion, Microsoft Forms now has a ‘shorten URL’ option. It’s still rolling out right now (March 2021) but it turned up in my tenants. You’ll find it under the Share menu, and then under ‘Send and collect responses’ :

The tick box is called ‘Shorten URL’:

Before ticking this box, the Forms URL for sharing looks like this:

https://forms.office.com/Pages/ResponsePage.aspx?id=gp6jfCyryEOFjHcqjfOQaicaufj5P4hCmrpZg_pruFhUNUFYSUlQMFEwRjVRNkZPUDBLOFYwUUtRVy4u

After ticking the box, it takes about a second or so to update, then looks like this:

The resulting link is of course, shorter. It also looks a lot nicer:

https://forms.office.com/r/Qca3qTjcMu

It’s nice to see a much more usable URL come out of Microsoft Forms, and still on the forms.office.com domain without having to resort to a third party URL shortener service.

Impersonation Protection delivers emails to Junk Folder

Impersonation Protection in Microsoft Defender for Office 365 is part of the Anti-phishing policies, designed to take action if an external email comes in with a match, or near match, to the display name of an employee.

The actions you can take when a match is made are:

  • Redirect message to other email addresses
  • Move message to the recipient’s Junk Email folders
  • Quarantine the message
  • Deliver the message and add other addresses to the Bcc line
  • Delete the message before it’s delivered
  • Don’t apply any action

What I wanted to do, was deliver the message and add other addresses to the bcc line. This could be used to send a copy of the email to helpdesk for investigation, as Impersonation Protection tends to get a lot of false positives from services that like to use people’s actual names from emails they generate, or from people using a personal account to email other employees.

What I found was that the action was applied, but the email was then delivered to the Junk Email folder. If I wanted that to happen, I would have selected the ‘Move message to the recipient’s junk email folders’ option. After logging a case with Microsoft, I found out why.

Any time an email is detected as an Impersonation Protection, and the mail is still allowed to flow through, it will set the header as SCL 5. As per Office 365 standards, this will deliver the email to the recipient’s junk mail folder.

It makes the choices on what actions to take in the Impersonation Protection settings rather misleading; but there is one option that’s still reasonable – Quarantine the message. This should trigger a fairly quick quarantine digest to the recipient for review, allowing them to review and decide if it should be released. If released, it will then deliver to the Inbox rather than Junk Mail.